W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Digest Auth: mutual? (was Digest Auth (I think we have a deal!))

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 27 Feb 96 14:04:30 PST
To: hallam@w3.org
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, john@math.nwu.edu
Message-Id: red-16-msg960227215743MTP[01.52.00]000000b1-117604
Phil said, Tuesday, February 27, 1996 4:05PM:
] Could someone please consider the  following:-
] 1) Will the next-nonce proposal interact with existing servers in a failsafe
] 	manner. ie will a new client interacting with an old server simply
] 	do a failure round trip?

Old servers won't send nextnonce; so clients (old or new) won't update 
their nonce.
So this won't even cause a failure round trip.
Old clients will ignore nextnonce when received from a new server,  and 
this will cause an extra round trip. Old-old and new-new are OK, of course.

] 2) Is there an easy and backwards compatible mechanism whereby a server could
] 	authenticate itself to a client?

At first blush, the current protocol is mutually authenticating.  If 
the server computes message-digest, and returns it in 
Digest-MessageDigest, and the client verifies it, then it has proven 
that it knows the shared secret.  This could be a replay, of course.
(Is this why there is a "nonce" in D-MD? So it can be different each 
time (and different from the client's nonce) so that the client gets 
authentication of the server?  If so, the need for nextnonce is 
marginal -- the client could just use nonce instead.) There's also 
man-in-the-middle to worry about...

If the message-digest parameter isn't in D-MD, then I don't think there 
is server->client authentication. A possibility: add 
"response=<digest>", computed the way as the client computes the 
same-named field (from username, realm, nonce, and the password), as an 
optional parameter to D-MD, so that authentication can be done without 
the expense of digesting the whole message-body.

Received on Tuesday, 27 February 1996 14:04:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC