SM> IPPFAX Security issue

SM> IPPFAX Security issue

SM> IPPFAX Security issue

Gail Songer gail.songer at
Wed Jan 28 20:46:29 EST 2004


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

Gail Songer
Peerless Systems Corp
gsonger at

-----Original Message-----
From: Wagner,William [mailto:WWagner at] 
Sent: Wednesday, January 28, 2004 3:36 PM
To: McDonald, Ira; ifx at; sm at
Subject: RE: SM> IPPFAX Security issue


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

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]
Sent: Wednesday, January 28, 2004 5:58 PM
To: 'ifx at'; 'sm at'
Subject: SM> IPPFAX Security issue


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."


- 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

More information about the Sm mailing list