Re: HTTP/1.1 + Digest

On Tue, 27 Aug 1996, Larry Masinter wrote:

> Servers can choose not to accept or request basic authentication. As
> has been pointed out in many cases, Basic authentication is as safe as
> Digest if used in conjunction with some other one-time password system
> (SKey, SecurID, etc.).
> 

Actually HTTP is very ill suited for use with one-time passwords,
because every transaction is re-authenticated.  It is not impossible,
just extremely cumbersome.  I seriously doubt that basic + one-time
passwords will ever see widespread use.

Basic authentication can be very useful under SSL, however.  In fact,
this is the one way that it is quite reasonable to tie authentication
to a regular system password file.  That is maybe the only use of
basic authentication that digest authentication can't do better.

The drawbacks of basic + SSL are the export/patent hassles of SSL and
the overhead of SSL.  It has occurred to me that it wouldn't be hard
to overcome the overhead problem with a kind of "cookie
authentication".  The initial transaction under SSL would do basic
authentication, issue a "ticket" in the form of a cookie and then
redirect to the real (non-SSL) document.  The ticket would essentially
be an expiration time, the client's IP address, and perhaps the
"realm", all signed by the server.

This would meet many of the objectives of digest, would be nearly as
secure.  Most importantly, it requires no new client support and no
new protocol support.  Don't get me wrong, I am still a strong
advocate of digest authentication -- we really need it.  I'm just
thinking about a fall-back position.

Speaking of protocol change, one thing I would like to see at some
point is authenticating a *connection* rather than every transaction.
Of course, we need per transaction authentication too.



John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 28 August 1996 07:26:46 UTC