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