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