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
Received on Fri Jul 11 2003 - 18:17:27 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:16 MST