IFX Mail Archive: IFX> RE: SM> IPPFAX Security issue

IFX Mail Archive: IFX> RE: SM> IPPFAX Security issue

IFX> RE: SM> IPPFAX Security issue

From: Wagner,William (WWagner@NetSilicon.com)
Date: Wed Jan 28 2004 - 18:35:32 EST

  • Next message: Gail Songer: "IFX> 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 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@sharplabs.com]
    Sent: Wednesday, January 28, 2004 5:58 PM
    To: 'ifx@pwg.org'; 'sm@pwg.org'
    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@sharplabs.com

    This archive was generated by hypermail 2b29 : Wed Jan 28 2004 - 18:35:52 EST