- 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
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. Paul
Received on Tuesday, 27 February 1996 14:04:35 UTC