OK, lets say that Operating System XYZ provides user-level access
control via a username and a password. Typically the username is
stored as cleartext, but the password is encrypted. The encryption
varies, but the most prevalent ones are 1-way hashes like the UNIX
crypt().
With Digest authentication you can end up with a very hard to spoof
method of authentication based upon an MD5 sum of the username,
password, realm, a server-defined nonce value, and (with some HTTP
implementations) the document data in the HTTP request. This
necessarily requires that the server either store the password as
cleartext or keep an MD5 sum of the username, password, and possibly
the realm in its password file in order to perform authorization.
Now, since the operating system only stores the encrypted password,
it is impossible for the HTTP server to use that password unless it
has been "encrypted" using an MD5 sum!
In order to support existing non-MD5 based operating system access
control, we need to allow Basic authentication as a valid method and
not force Digest for all authentication. Certainly we should urge
implementers to support Digest, but to force it will make IPP-based
products unnecessarily difficult to administrate, especially since IPP
(and HTTP) do not define a standard administration interface.
While Basic authentication is definitely *not* spoof-proof, it is
perfectly adequate for closed or restricted-access networks where you
have a known set of users. Any spoof attack can be quickly tracked to
the real user, and attacks on other network resources (user accounts,
etc.) can similarly be tracked.
In summary, IPP should allow for as little or as much security as is
required, with the emphasis (short of a mandate) on more security. It
should be sufficient to require Basic and Digest support in all IPP
clients and recommend Digest support in IPP servers for
authentication. That way clients will be able to function with all
servers, and servers will be able to implement the most appropriate
or convenient method of authentication as desired by the
administrator.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com