IPP Mail Archive: Re: IPP> FW: IESG/AD reviews of IPP notifi

Re: IPP> FW: IESG/AD reviews of IPP notifications documents

From: Michael Sweet (mike@easysw.com)
Date: Wed Apr 10 2002 - 09:34:28 EDT

  • Next message: Michael Sweet: "[Fwd: Re: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15]"

    Carl wrote:
    > Hi,
    >
    > It seems that Ned is not subscribed to the IPP DL so his recent messages
    > have bounced.
    >
    > Here the input we got from Ned for the recent IETF meeting.

    My comments follow...

    > ...
    > draft-ietf-ipp-indp-method-06.txt (IESG review)
    >
    > All of the Security Mechanisms articulated are MAY, so it appears to be
    > possible to build an implementation without any security mechanism and still
    > be
    > conformant. The IESG doesn't believe this is what we should be doing. There
    > should be at least one mandatory security mechanism.

    It might be appropriate to require support for TLS with some form of
    HTTP authentication, since (most likely) authentication will be required
    when delivering notifications via the Send-Notifications operation.

    > There seems to be some potential that indp requests could be directed
    > at a third party that is not prepared to receive them. Some discussion of
    > this issue in the security considerations section would be useful.

    Might be simple enough to mention that recipients that do not support
    indp will return a server-error-operation-not-supported error, so the
    primary danger in this case is a DoS attack.

    > draft-ietf-ipp-notify-mailto-03.txt (AD review)
    > ...
    > This document currently does not discuss support for SASL authentication
    > in the context of SMTP. This is probably something that should be added,
    > especially since it probably requires additional printer configuration
    > capabilities.

    I again voice my objection to requiring specific mail transports or
    authentication mechanisms when deliverying mail - doing so will
    *ensure* non-compliant implementations which otherwise look, feel,
    and taste compliant to a user, so specifying something that is
    outside the scope of IPP mailto is useless and inappropriate.

    If SASL is so important, then it should be required by the SMTP spec
    (RFC 2821), but it is not. Instead, it is addressed in an older
    extension spec (RFC 2554) and specifically only addresses one issue
    relavent to mailto notifications:

      (3) it authenticates the message submission, not authorship of the
               message content

    That said, wording along the lines of "if SMTP is used to deliver
    messages, then SASL SHOULD be supported" would be an appropriate
    pointer/message for IPP mailto implementations.

    Making SASL a MUST with SMTP would open up many more security
    issues which the IESG is not able/prepared to address, like:

         1. What standard protocol is used to load authentication
            information into an embedded device?

         2. How is this authentication information protected from
            disclosure?

         3. How is the authentication information authenticated?
            (by this I mean, how do we authenticate the new
             authentication information if no authentication
             information has been initialized?)

    #2 and #3 obviously are questions that might be answered by
    #1, but I would hazard a guess that most people would not
    find a single solution acceptable in all environments.

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Wed Apr 10 2002 - 09:34:58 EDT