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

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

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

Michael Sweet mike at easysw.com
Wed Apr 10 09:34:28 EDT 2002

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

     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 at easysw.com
Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list