- From: John Franks <john@math.nwu.edu>
- Date: Mon, 26 Feb 1996 16:16:28 -0600 (CST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Mon, 26 Feb 1996, Paul Leach wrote: > On Saturday, February 24, 1996 8:20AM, John suggested "one-time > response digests". > > It didn't dawn on me until you made this latest suggestion, but the > recommended nonce includes the URI of the requested entity. > This will require a at least one challenge for each document requested. > This latest suggestion achieves that lower bound. > Yes, including the URI in the recommended nonce was a mistake. I was aware of this and I have removed it. Re-using nonces is current practice and will continue to be by far the most common type of transaction. It was my mistake to add URI to the recommended nonce calculation. BTW, over the weekend, I modified my prototype implementation to use the recommended nonce (minus URI). It works fine with at least MSIE 2.0b2. If anyone would like to try a browser supporting digest authentication with it the URL is http://hopf.math.nwu.edu/simp2/index.html with username "Mufasa" and password "CircleOfLife". > However: incrementing nonces only require one challenge per *session*, > which is much more efficient, especially for long sessions. (This won't > matter for sites where most information doesn't require authentication, > but subscription based sites are an important case that lots of people > want to support and they would have almost all pages be authenticated > if it were cheap enough.) Yes, but I thought we had agreed that for a subscription service there is no reason not to re-use nonces. Re-using the nonce is even cheaper than incrementing them. > When using persistent connections, the next expected nonce on that > connection can be kept in a per-connection data structure (which > the server probably already has and where the authenticated user > name would also be kept), and directly accessed, without the > overhead of a hash table. If you don't keep a hash table how do you prevent a replay attack? The replay would, of course, be in a different session. I thought that defending against replay was the point of all this. You haven't yet described how you would implement aging and recycling your hash table. If what you want is one challenge per session, a good way to implement it would be a global hash table of session nonces together with a very small per session hash of the response digests kept in the per session data structure you mention. The nonce would not change throughout the session. > > Lastly, incrementing nonces are compatible with all existing > implementations. A server that wasn't expecting the (new) client > to modify the nonce will fail to authenticate and reissue the > challenge. (A clever client could even notice this and stop > incrementing the nonce after a couple of challenges to see if that helped.) > The Microsoft browser I use for testing my implementation of Digest Authentication responds to a re-issued challenge by asking the user to re-enter the username and password. This is appropriate since it assumes that I have mistyped my password. I wouldn't want to do this whenever I contact a new server though. Thus, at the very least, a new-server would have to prevent that by recognizing that it was talking to an old-client (i.e. the nonce had not been incremented). Likewise, a new-client would also need a way to distinguish whether the re-issued challenge was due to a mis-typed password or an old-server. John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Monday, 26 February 1996 15:12:25 UTC