RE: Some comments on Digest Auth

> ----------
> From: 	Scott Lawrence[SMTP:lawrence@agranat.com]
> Sent: 	Wednesday, January 21, 1998 7:07 AM
> To: 	Paul Leach
> Cc: 	http-wg@cuckoo.hpl.hp.com
> Subject: 	Re: Some comments on Digest Auth
> 
> 
> >>>>> "PL" == Paul Leach <paulle@MICROSOFT.com> writes:
> 
> PL> If the servers keep no state, and just accepts the nonce that the
> client
> PL> quotes back at it, then you get no replay protection at all.
> 
>   This is something of a digression, but it _is_ possible for the
>   server to construct nonces which are not reusable and which require
>   no per-nonce state in the server.
> 
Its not a digression. If we had such an algorithm, then that's what we'd
describe in the draft.

> PL> But I think we should specify that it MUST contain a timestamp, if
> PL> that's all the replay protection we're going to have. And we could
> PL> specify that the client include a timestamp in the nonce...
> PL> [description of nonce generation rules using timestamps]
> 
>   First, I must repeat my favorite refrain: Not all HTTP
>   implementations have clocks - you can't require the use of
>   timestamps.
> 
I apologize for being loose. We may need to describe more than one algorithm
-- one for systems with clocks, and one without.

>   More important for the current discussion... the standard should not
>   specify how nonces are constructed.  There are very good reasons for
>   this:
> 
>     - Any specified algorithm (no matter how clever) tells an attacker
>       how the nonce space is limited, thereby weakening the security.
> 
If it's "limited" to a space of, say, 128 bits, that's adequate to cause
brute force attacks to take millions of years. Not a problem.  Besides
which, I carefully said that the nonce _contains_ a time stamp, not that it
_is_ a timestamp; any server can always include any additional random bits
that it wants to make the space as big as it would like.

>     - RFC 2069 specifies that the nonce may be constructed in any way
>       the server chooses, and specifies that the client just uses that
>       value. Any change that requires specific algorithms for either
>       will break existing deployed implementations.
> 
I'm not talking about requiring different algorithms. We need to describe at
least ONE way to build a secure implementation. (Maybe one for with and
without clocks.) Implementers should be free to try to do better, but
history shows that without that guidance, they will often do worse.

Also, we need to display at least one good solution just to convince
ourselves that one is possible given the protocol. And it needs to be
closely examined -- for example, the suggestion about IP addresses in the
nonce that is currently in the draft breaks with proxy farms. If its only a
"suggestion", people tend to ignore it, because they tink "that's not how
I'm going to implement it".

>   If we are going to break existing implementations, then it seems to
>   me that we should just forget the current spec altogether and go on
>   to digest-ng (which I don't think we can get done soon enough to
>   make the IESG happy with advancing 1.1).
> 
Which is why we aren't going to go straight to digest-ng. If there is any
change needed to the protocol, then it should be small so that the change to
existing implementations can be slight. 

Paul

Received on Wednesday, 21 January 1998 11:03:46 UTC