ned.freed at mrochek.com wrote:
> ...
> This is less of a security consideration than it is an operational
> concern.
Exactly, and its (SASL's) use (or even presence) could influence
whether mailto is even allowed to be used at specific sites.
> ...
>> 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.
Dissemination of authentication information is far beyond the
scope of this WG. Sure, we could add a "Set-Authentication"
operation to IPP, but then what do we do to authenticate and
protect the new authentication information? And then when
another protocol comes along needing the same thing, what then?
>> 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.
It may well be, or it might be stored remotely. The fact is,
*loading* the information in the printer is a problem - most
printers don't have keyboards, and any security-conscious
network administrator will disable the network-based config
interfaces before even hooking the printer to the network.
> ..
> 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.
A typical embedded implementation does not provide any security
mechanisms at all, aside from maybe a very limited IP-based
access control system. These implementations already support
status notification via syslog servers, SNMP, etc., and I
would guess that adding ippget and mailto notifications would
not be terribly difficult. The IP address of the SMTP server
can (fairly) easily be entered via a simple control panel, but
entering SASL authentication info can't. Some printers support
configuration files via BOOTP, but IIRC those configuration files
are downloaded via TFTP and thus are not safe from prying eyes.
Moreover, most (all?) embedded implementations do not support TLS
and thus are unable to safely retrieve this information any other
way, either.
Thus, most embedded solutions probably won't be able to provide
the kind of security you desire, and in most cases *they don't
need to*.
OTOH, a typical non-embedded implementation like CUPS (the
same can probably be said for the Windows and Novell IPP
implementations) has a multitude of options to load the
authentication information and configure things accordingly.
In *that* case, implementing SASL with SMTP is entirely
feasible and desirable.
*However*, in the case of a non-embedded solution, the notifier
will likely use the OS-supplied mail API to send messages, so
such configuration is outside the scope of the IPP
implementation anyways!
In short, requiring SASL will prevent mailto's use on embedded
devices and is overkill for non-embedded solutions which will
likely use conforming software to submit mail, rather than
direct SMTP submissions.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com