IFX Mail Archive: RE: IFX> IPPFAX Security issue

IFX Mail Archive: RE: IFX> IPPFAX Security issue

RE: IFX> IPPFAX Security issue

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Jan 29 2004 - 11:13:57 EST

  • Next message: Gail Songer: "IFX> Next meeting Feb 4"


    Well since my note stimulated universal negative responses,
    I'll try to reply.

    One of the most important security threats than any protocol
    must defend against (the IETF, ITU, ISO, and W3C all require
    that specs explicitly address security threats) is called
    "Denial of Service".

    The reason for this security principal about 'least secure
    protocol' (I'll be glad to cite primary sources, but it
    really is industry standard among security professionals)
    is that the secure/reliable service (for example IPPFAX)
    can be completely driven out of the box by connection
    starvation, traffic overload, etc. on the _other_ less
    secure services.

    To answer Bill Wagner's question, a "host" is a single
    network connected whole system (in a box). Multi-processor
    "hosts" are always treated as single-processor for purposes
    of security analysis.

    Some background - recall that IPPFAX has ALWAYS made the
    use of TLS/1.0 with required Server Authentication during
    the TLS Handshake required for implementation and USE by
    all IPPFAX Clients (Senders) and IPPFAX Servers (Receivers).
    This is to guarantee data integrity over the wire, i.e.,
    what the original Sender sent is absolutely guaranteed
    to arrive unmodified at the authenticated Receiver.

    So, are you still all opposed to this IPPFAX security
    wording? If so, I seriously suggest we abandon IPPFAX
    entirely, because it can't even reliably reproduce a
    simple PSTN fax service without this requirement on the

    - 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

    -----Original Message-----
    From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]
    Sent: Thursday, January 29, 2004 9:08 AM
    To: ifx@pwg.org
    Subject: Re: IFX> IPPFAX Security issue

    So does this go before or after the requirment for opening a
    port in the firewall...........:)

    I don't agree with putting security criteria for implementations in a
    protocol specification.

    Are we then going to put requirements on access to the output bin or the
    panel of the device...??

    We should certianly describe how the "pipe" can be secured but anything
    about the security of the device should be in left to a security
    recommendation standard.

    I wonder how many https servers also accept simultaneous http

    Jerry Thrasher

    "McDonald, Ira" <imcdonald@sharplabs.com>@pwg.org on 01/28/2004 05:57:36 PM

    Sent by: owner-ifx@pwg.org

    To: "'ifx@pwg.org'" <ifx@pwg.org>, "'sm@pwg.org'" <sm@pwg.org>
    Subject: IFX> 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 : Thu Jan 29 2004 - 11:14:13 EST