Hi,
Well since my note stimulated universal negative responses,
I'll try to reply.
One of the most important security threats than any protocol
must defend against (the IETF, ITU, ISO, and W3C all require
that specs explicitly address security threats) is called
"Denial of Service".
The reason for this security principal about 'least secure
protocol' (I'll be glad to cite primary sources, but it
really is industry standard among security professionals)
is that the secure/reliable service (for example IPPFAX)
can be completely driven out of the box by connection
starvation, traffic overload, etc. on the _other_ less
secure services.
To answer Bill Wagner's question, a "host" is a single
network connected whole system (in a box). Multi-processor
"hosts" are always treated as single-processor for purposes
of security analysis.
Some background - recall that IPPFAX has ALWAYS made the
use of TLS/1.0 with required Server Authentication during
the TLS Handshake required for implementation and USE by
all IPPFAX Clients (Senders) and IPPFAX Servers (Receivers).
This is to guarantee data integrity over the wire, i.e.,
what the original Sender sent is absolutely guaranteed
to arrive unmodified at the authenticated Receiver.
So, are you still all opposed to this IPPFAX security
wording? If so, I seriously suggest we abandon IPPFAX
entirely, because it can't even reliably reproduce a
simple PSTN fax service without this requirement on the
implementations.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]
Sent: Thursday, January 29, 2004 9:08 AM
To: ifx@pwg.org
Subject: Re: IFX> IPPFAX Security issue
So does this go before or after the requirment for opening a
port in the firewall...........:)
I don't agree with putting security criteria for implementations in a
protocol specification.
Are we then going to put requirements on access to the output bin or the
operator
panel of the device...??
We should certianly describe how the "pipe" can be secured but anything
further
about the security of the device should be in left to a security
recommendation standard.
I wonder how many https servers also accept simultaneous http
connection.....??
Jerry Thrasher
"McDonald, Ira" <imcdonald@sharplabs.com>@pwg.org on 01/28/2004 05:57:36 PM
Sent by: owner-ifx@pwg.org
To: "'ifx@pwg.org'" <ifx@pwg.org>, "'sm@pwg.org'" <sm@pwg.org>
cc:
Subject: IFX> IPPFAX Security issue
Hi,
This topic came up during today's ongoing review of the
IPPFAX Protocol spec. It affects implementing IPPFAX/1.0
along with any other protocol on the same device or server.
Given the basic network security principal:
"The actual security level of a given service instance
depends on the _least_ secure protocol interface of
_any_ service on the same host system."
I propose that the IPPFAX/1.0 Protocol spec should say:
"A host system with an enabled IPPFAX/1.0 Receiver (as
defined in this document) MUST NOT enable any other
protocol configured with less security than IPPFAX/1.0
(i.e., less secure than TLS/1.0 [RFC2246] with required
server authentication and optional client authentication).
Note: Equivalent security to IPPFAX/1.0 can be achieved
by the object security defined in S/MIME [RFC2633], or
by the stream security defined in Secure Shell Protocol
[draft-ietf-secsh-architecture-15.txt - in IESG queue],
or by many other strong security mechanisms. But such
protocols as SNMPv1 [RFC1157] or IPP/1.1 without TLS/1.0
MUST NOT be enabled on a host system with a currently
enabled IPPFAX/1.0 Receiver."
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
This archive was generated by hypermail 2b29 : Thu Jan 29 2004 - 11:14:13 EST