Ira,
I'm not sure that I like your proposed wording. Making the kind of
statement you propose seems way too restrictive to me. I believe that we
should allow IPPFax to exist on devices that are "less secure" than
IPPFax, and add the same kind of note that TLS adds in its security
section. (We are only as secure as the weakest link).
Now making allowances to turn off all the other protocols seems
reasonable to me for those cases where you want the ulta-high-secure
device.
Gail Songer
Peerless Systems Corp
gsonger at peerless.com
-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Wednesday, January 28, 2004 3:36 PM
To: McDonald, Ira; ifx at pwg.org; sm at pwg.org
Subject: RE: SM> IPPFAX Security issue
Ira,
Sounds like one more reason we need to think up a special market for
IPPFAX. The original notion was to include IPPFAX in a multifunction
unit much as IETF FAX and PSTN FAX are presently put into
printer/copiers. It would appear that, with this constraint, an IPPFAX
device must be a single purpose machine (or perhaps an IPPFAX/TLS IPP
printer). I think this is not going to encourage extensive
implementation.
Of course, I do not understand the premise of the basic network security
principle in this application. Going by the words, presumably, if I had
two processors implementing two 'hosts', but each driving one marking
engine, the problem would not exist? If I have one processor
implementing two hosts, would the problem exist? What determines what a
host is? And does any of this make sense in this application? The idea
is not who gets access to the device but who can get access to an IPPFAX
product. Looking at the security objectives as authentication of source
and destination, delivery of complete and unaltered contents, and
limited access to contents, I don't see how the "principle" applies
(except that there probably should be some unique mark on the IPPFAX
copy to preclude spoofing output).
Bill Wagner
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Wednesday, January 28, 2004 5:58 PM
To: 'ifx at pwg.org'; 'sm at pwg.org'
Subject: SM> 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 at sharplabs.com