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: Gail Songer (gail.songer@peerless.com)
Date: Wed Jan 28 2004 - 20:46:29 EST

  • Next message: thrasher@lexmark.com: "Re: IFX> IPPFAX Security issue"


    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

    -----Original Message-----
    From: Wagner,William [mailto:WWagner@NetSilicon.com]
    Sent: Wednesday, January 28, 2004 3:36 PM
    To: McDonald, Ira; ifx@pwg.org; sm@pwg.org
    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@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 - 20:47:25 EST