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

Re: more on Digest Auth

From: John Franks <john@math.nwu.edu>
Date: Wed, 21 Feb 1996 20:42:00 -0600 (CST)
To: Paul Leach <paulle@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960221200928.10682B-100000@hopf.math.nwu.edu>
On Wed, 21 Feb 1996, Paul Leach wrote:

> I thought your comments about replay were quite valuable and on target: 
> I wasn't really grokking all the implications or unencrypted replies 
> and snooping.
> But your scenario only considers GET.
> I was actually thinking about exposing some admin functions on my 
> server via POSTs of form-data.  In which case, I definitely DO care 
> about replay. And about end-to-end integrity of the form-data.

Well, if you're interested in a real application and this is not just
an adademic discussion perhaps a reality check is in order. Let me
emphasize though that this is just my opinion.

1. The current draft is implemented in a lot of Microsoft and NCSA browsers.
I conclude that any change which would break these browsers (like 
incrementing the nonce before digesting) is unlikely to happen no matter
how good an idea it is.

2. The current draft is not implemented in any Netscape browser and
there is no evidence that it is likely to be.  Unless this changes I
would conclude that discussion of the revising the protocol may be
moot as it is unlikely to be widely used.  It could be useful for
"intranet" applications though.

3. I believe that the current Microsoft (really Spyglass) and NCSA
implementations do not support the client providing a <message-digest>
for POST or PUT data.  I don't know their future intentions, but this
could be problematic for your purposes unless you create or modify
your own client.  If you do that and modify your server you can, of
course, do whatever you want.

> I just don't see that the suggested changes are very big, and they make 
> the protocol much more secure, and perhaps able to be used in 
> circumstances beyond what was originally intended -- PUT, DELETE, as 
> well as POST.
> If this were a really hard set of changes to the draft, I'd give up.  
> But they aren't.

I didn't carefully follow your nonce incrementing proposal, but the
only way I can immediately see to make it useful in preventing replay
attacks is for the server to keep a data base of used nonces and the
number of times each has been used.  Otherwise the server wouldn't
know if the nonce had been properly incremented each time.  Keeping
this data would constitute a "very big change" for a large heavily
loaded server.  The tradeoff would be a good one for what you have in
mind but not so good for say the NY Times which wants to have many
thousands of subscribers who "login" every time the want to read the
paper.  (I think this is pretty stupid of them as long as they don't
charge for access, but that is another story).

John Franks 	Dept of Math. Northwestern University
Received on Wednesday, 21 February 1996 18:43:57 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC