Re: questions regarding draft-ietf-http-authentication-01

> >>>>> "PL" == Paul Leach <paulle@MICROSOFT.com> writes:
[snip]
> >> 8) Section 3.2.3: no words prohibit the server from sending, say, a qop
> >> attribute but not a rspauth attribute. Also, while the cnonce is
> >> required to be the same as used in the request, the nonce-count isn't.
> >> Hence I propose the following change in wording:
[snip]
> 
>   This was a cut-and-paste error, I think; the nc-value is not used in
>   the construction of the response-digest, so it need not be in the
>   syntax for the Authentication-Info header at all.

I beg to differ. The response-digest is the same as the request-digest
except that A2 is computed differently, and the request-digest uses the
nc-value in the computation.

>   From client to
>   server the requests may be pipelined, so we needed the nonce count
>   to prevent replay, but each response is to exactly one unique
>   request, so no count is needed or used.
>
> >> 9) Section 3.2.3: Actually, why are the cnonce and nonce-count attributes
> >> sent in the Authorization-Info header? Or put differently, what makes
> >> these two attributes special, as opposed to the nonce and uri (which
> >> aren't sent back)?
> 
>   See above for nonce-count; I thought that returning the cnonce value
>   might make implementation in the client easier; the client can then
>   use the same kind of self-validation that servers can with nonces so
>   that they need not be actually stored while waiting for the response.

The nonce-count, nonce, and uri have to be kept anyway, so I'm not sure
how much easier it makes things (I just compare the received nc-value
and cnonce against the ones in the request and puke if they don't
match). However, there may well implementations which do this indirect
validation and which would profit from an explicit cnonce, so I think
it can be left in.


  Cheers,

  Ronald

Received on Sunday, 29 March 1998 14:18:46 UTC