Re: more on Digest Auth

----------
] From: John Franks  <john@math.nwu.edu>
] To: Paul Leach
] Cc:  <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Re: more on Digest Auth
] Date: Wednesday, February 21, 1996 4:57PM
]
] On Wed, 21 Feb 1996, Paul Leach wrote:
]
] >
] > The draft also says that the nonce is a "server specified integer
] > value". (It _doesn't_ say if it's *HEX or *DIGIT...) 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.
] >
] > 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.
] >
]
] Well, now I'm confused.  I have been talking about
] draft-ietf-http-digest-aa-02.txt my version of which is dated
] Dec. 20, 1995 and does not contain the word "increment."

So have I. Part of the change is to add the word "increment", in line 
with Ned's suggestion, which is not possible to implement given the 
current spec.
The other part is to make it be hex, so it is easier to convert to 
large  binary number(s) to be able to contain all the other info Ned 
and Dave suggest as needing to be covered by the digest.

]
] What it does say is:
]
]      "<nonce>
]          A server-specified integer value which may be uniquely 
generated each
]          time a 401 response is made.  Servers may defend themselves against
]          replay attacks by refusing to reuse nonce values.  The nonce 
should be
]          considered opqaue (sic) by the client."
]
] Being considered "opaque" by the client means that clients don't increment
] it.

If the client doesn't change the nonce each time, there's no replay 
protection without a challenge each time.  So,  the third part  of the 
suggestion is to make the last 32 bits of the nonce not be opaque.

Does that help?

Paul

Received on Wednesday, 21 February 1996 16:09:11 UTC