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

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

From: Carl (carl@manros.com)
Date: Fri Apr 12 2002 - 06:57:54 EDT

  • Next message: Carl: "FW: IPP> FW: IESG/AD reviews of IPP notifications documents"

    As the script updates to the DL don't seem to have been done yet, I forward
    this one to the DL.

    Carl-Uno

    -----Original Message-----
    From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
    Sent: Friday, April 12, 2002 12:39 AM
    To: Michael Sweet
    Cc: Carl; ipp@pwg.org
    Subject: Re: IPP> FW: IESG/AD reviews of IPP notifications documents

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

    First of all, I only suggested that mandatory-to-implement SASL might be a
    way
    forward. I never insisted on it. However, I think that at least the
    infrastructure for SASL needs to be standardized, for the simple reason that
    situations exist where you need to SASL in order to be able to send mail.

    This is less of a security consideration than it is an operational concern.

    > If SASL is so important, then it should be required by the SMTP spec
    > (RFC 2821), but it is not.

    RFC 2821 is concerned with message transfer, not submission. Submission
    is described in RFC 2476. And RFC 2476 discusses submission authorization
    in some detail (section 3.3). Of the methods discussed, the only one that
    seems appropriate for use in this context is SASL.

    > Instead, it is addressed in an older
    > extension spec (RFC 2554) and specifically only addresses one issue
    > relavent to mailto notifications:

    The fact that it is older doesn't mean it is obsolete. All RFC 2821
    is concerned with is updating the core SMTP specification.

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

    It is the only relevant issue as far as I can see.

    > 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:

    The IESG isn't the group that needs to address this. This is a problem
    for this WG.

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

    IMO it needs to be part of the configuration information for the printer.

    > 2. How is this authentication information protected from
    > disclosure?

    By the same means other critical information is protected.

    > 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?)

    This is exactly the sort of thing I've been trying to get at. Even a SHOULD
    in
    the mailto notification specification needs to be implementable.

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

    It is up to the WG to find such a solution.

                                    Ned



    This archive was generated by hypermail 2b29 : Fri Apr 12 2002 - 06:59:56 EDT