Re: Digest mess

On Tue, 6 Jan 1998, Scott Lawrence wrote:

> 
> >> I would like to be able to implement it in a single parsing pass
> >> over the message, which is certainly impossible if arbitrary
> >> headers may be included by an attribute in a field that may be sent
> >> in a trailer.
> 
> >>>>> "JF" == John Franks <john@math.nwu.edu> writes:
> 
> JF> I see no problem with a single pass.  Remember the actual message
> JF> headers are irrelevant for authentication purposes.  Conversely, the
> JF> "origin-headers" play no role as HTTP headers, but are used only for
> JF> authentication.[...]  A point worth emphasizing is that
> JF> the actual HTTP headers never get used in any way in the authentication
> JF> process.
> 
>   If this is the case then the mechanism has not accomplished
>   anything.
> 

The origin-headers are used in deciding whether the transaction was in
fact authenticated properly.  

Examples:

(1) The client gets a response whose digest checks out, but with an
origin-header with outdated Expires.  It knows its proxy is broken or
lying or the server is broken.  A sensible thing to do would be try
again and if the origin-header Expires is still outdated, then
authentication fails.  The HTTP transactions were fine -- the
authentication process failed.

(2) If the client sees the proper response code in the origin-headers,
it knows its PUT succeeded whatever the HTTP status code was.  

It is easy to think up other examples.  These are useful things.  They
don't require more than one pass and something valuable has been
accomplished.

> 
> >> Getting back to the original problem - the prevention of the replay
> >> of a valid message in response to a different request.  The server
> >> can already prevent replay of a past client message by changing the
> >> nonce value included in the challenge.
> 
> JF> I don't understand this.  Why wouldn't a man-in-the-middle replay
> JF> an earlier challenge with a valid, but old, nonce?  In fact the
> JF> MIM would have to do this for the replay attack to work.
> 
>   It can, but then the client generates a request including a
>   client-generated nonce of its own.  

Sigh.  Yes, a client nonce can protect against a replay attack.  We've
discussed it before.  This would be a *big* change.  It breaks all
existing implementations -- including the widely deployed Apache
server implementation and all existing client implementations.

The other changes which have been recently discussed affect only the
optional Authentication-info header which is not in the Apache
implementation.  I know there are a few implementations, but I know of
none which are widely deployed.

I'm getting discouraged.

John Franks
john@math.nwu.edu

Received on Tuesday, 6 January 1998 09:33:43 UTC