> > Proposed solution: As the HTTP WG is deprecating the Basic
> > Authentication feature, it does not make sense to mandate that, but
> > we still have to make it clear that support for Digest Authentication
> > is a MUST for all IPP clients and printers (unless you want to make
> > TLS a MUST for everybody) in IPP/1.1.
> > ...
>> I've said this before, but let me say it again - if you mandate
> Digest authentication then it will be impossible to use the existing
> authentication systems provided by most operating systems.
This is quite true. Unfortunately, we do not know of a good way of
authenticating requests that is:
- compatible with existing authentication databases
- lightweight and easy to implement
- secure (doesn't expose the password to trivial attack)
- exportable from countries that restrict use of encryption
(exportable versions of SSL/TLS expose the password - it takes
very little time to break RC4-40)
The choice of digest as a mandatory-to-implement algorithm for HTTP (and
IPP) is a compromise. It certainly doesn't serve everyone's needs, but
neither does it cost much to implement, and requiring every conforming
client and server to implement digest will at least provide one way for
users to authenticate to printers without compromising their passwords.
This certainly seems better than requiring everyone to implement basic -
which would not only require users to expose their passwords to
eavesdroppers, it would *encourage* use of the same passwords for HTTP
(and hence IPP) as for other services!
To put it another way: To make basic authentication "safe" you need
to protect the entire network over which such credentials might
be transmitted. To make digest authentication "safe" you need
only to protect the server that stores the credentials. It's usually
easier to protect a single server machine, than the network that
supports the same number of users.
However, a bit of clarification may be in order: although support for
digest authentication is required for HTTP/1.1, nothing says that digest
authentication must be available for all principals under all conditions.
A server may support both basic and digest authentication, as well as
other methods, and it may even be configurable on a per-principal basis
to allow (or require) a different authentication method for each. Thus a
server could be configurable to allow basic authentication (perhaps
protecting the data stream with TLS when possible), for users whose
passwords were stored in a one-way-hashed password file, and support
digest authentication for a different set of users (with separately
maintained passwords).
To take an example from a different protocol: Qualcomm's popular
'qpopper' POP server supports both APOP (challenge-response, similar
to http digest) and USER/PASS (cleartext password) authentication,
with the former using a separate password database and the latter
using the UNIX passwd file.
Eventually I hope that we'll all be able to use TLS with strong
encryption, or some similar technology, to do authentication.
Keith
p.s. for those interested in an incremental refinement to HTTP
digest which has a bit more flexibility, draft-leach-digest-sasl-02.txt
describes a SASL mechanism derived from HTTP digest which supports
some additional features - in particular, use of a authentication server
which is separate from the HTTP server. This potentially allows better
protection for the authentication credentials, and better scaling.