IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

Keith Moore moore at cs.utk.edu
Wed Apr 7 22:26:52 EDT 1999


> > 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.



More information about the Ipp mailing list