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