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

Re: more on Digest Auth

From: Ned Freed <NED@innosoft.com>
Date: Wed, 21 Feb 1996 16:56:14 -0800 (PST)
To: Paul Leach <paulle@microsoft.com>
Cc: dmk@allegra.att.com, ned@innosoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> ] For the material you've selected to work it should be used as the nonce
> ] value. This is included in the digest and will have the effect you're trying
> ] to achieve.

> The draft also says that the nonce is a "server specified integer
> value". (It _doesn't_ say if it's *HEX or *DIGIT...)

Interesting point. The nonce is described as an integer but is used as  an
opaque string. This really needs to be clarified.

> If it included all
> the material Dave uses, it would be a pretty big integer, and clients
> probably wouldn't know how to increment it.

It would only be a hash of all that stuff. But even so, it will probably be
pretty long... In any case, since the specification doesn't talk about
incrementing the nonce anywhere (at least not that I can find) I don't see how
having a long nonce value would break anything. I did mention the concept
of incrementing the nonce myself, but only in passing.

> Changing the spec to say it's *HEX, and that the last 32 bits is the
> part that clients must increment each time they return it in a request,
> would enable the implementation of your suggestions.

I don't think it is necessary that this be done, but I agree that this
should be clarified.

> The draft also isn't very specific about what "<message-body>"
> includes.  Does it mean entity-body, or does it include the headers as
> well?  The latter is preferable.

I haven't considered the case where digests are used to authenticate
returned content, but you're right, this also needs to be tightened up.

Received on Wednesday, 21 February 1996 17:05:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC