On Saturday 12 July 2003 00.29, Robert Collins wrote: > I don't recall coding it up. Let me check... no. > No - we don't provide full cnonce support.
What of cnounce does we not support? > We don't support response auth, nor response auth-integrity. No, but this is not cnonce related las time I looked. Just another feature of the Digest protocol to make it even more secure by having the server authenticate to the client. response-auth is probably a good thing to have and should get done but auth-int does not make much sense in a proxy I think, not to mention the buffer requirements to implement auth-int without HTTP/1.1 trailer support.. > We do put a client nonce into the HHA1 calculation where > appropriate, and squid can create a md5-sess HHA1 although > the code is disabled - as you note > we don't have a helper interface for it. (It's a relatively small > patch to enable that though). Yep. > Uhm, yeah. Chosen nonces would at worst - assuming no sanity checks > on nonce length by the directory, expose MD5(user:realm:password). > Having the client choose the nonce could be useful (say if the > client wanted to use a constant cnonce for memory efficiency - not > a compelling reason though:}), but there is a risk as you say. Note: Having the client use a constant cnonce does not save you any significant amount of memory. Unlike servers clients does not need to keep a memory of past nonces as session reuse is initiated by the client, not server. Only one nonce pair per active digest session is needed to be kept track of by the client, and there should never be a need to support more than a handful active digest sessions (one per concurrent connection in case of proxy authentication, one per concurrent message in case of www authentication) Regards Henrik
