RE: New draft for Digest Authentication

John said:

] I think we have agreed that
] it is only useful for PUT or POST transactions, not GET transactions.
] It is unnecessary for most but not all POST transactions if the
] message-digest is used (which it has to be for any kind of security).

I think it would be useful for most  fill-out forms that leave 
information on the server, and for posting to news groups or sending 
mail via HTTP (where spoofing is an existing problem). It isn't just 
for admin requests -- that's just what prompted me to want it.
It's not a large percentage of the requests _today_, in part because 
you can't do them securely; the percentage would surely go up if POSTs 
could be secure. New HTTP 1.1 methods -- PUT, DELETE, LINK, UNLINK -- 
will all want authentication.

Just imagine that you're propagating a ton of stuff from one site to 
another in order to mirror it -- PUT, DELETE, LINK, UNLINK would all be 
heavilty used, and slowing each one down by a round trip could cause a 
significant increase in the time the propogation takes.  A cross 
country round trip is 50-100ms, about the same time it takes to 
transfer a 10k byte entity over a 1 megabit/sec connection -- a 
slowdown of a factor of 2. And trying to fix the problem by buying a 
faster link would only make the slowdown factor worse...

What I'm saying is that we shouldn't just design it for today's access 
patterns, but consider plausible future scenarios, and utilize 
experience with other authentication protocols to make this one 
efficient so that it can be used without excessive cost.

] >
] > ]
] > ] 2) Nonce incrementing breaks current implementations.
] >
] > No it doesn't, as my previous mail explained. Reproduced below.
] >
] > ] Making it
] > ] optional to maintain backwards compatibility would make it useless for
] > ] security as any attacker would simply use the old version of the
] > ] protocol.
] >
] > No it doesn't. An existing client that doesn't send in an incremented
] > nonce will get a new challenge with a new nonce. Ditto for an attacker.
] >
] You do not address the fact that   new client <--> old server
] transactions are broken. If the client increments a nonce from
] an server not expecting it the transaction will fail.

You're right, it wasn't explicitly addressed. I'd hoped the pattern was 
clear by that point.  The answer is that  the server would issue 
another challenge. If you really believe that round trips are so cheap, 
this shouldn't bother you.

] Look, we can come up with a hack that doesn't break anything if we
] work long enough.  But it will be just that, a hack, and it doesn't
] buy much -- the elimination of one nonce negotiation on a small
] fraction of transactions.

It didn't take me long to come up with it, and Ned came up with the 
same idea independently.  And it isn't a hack -- incrementing nonces 
has been standard practice in authentication protocols since at least 
Needham and Schroeder in 1978, not to mention Kerberos.

It is taking a while to demonstrate that it works and is an incredibly 
small change to the spec, though.


Received on Friday, 23 February 1996 16:43:29 UTC