- From: Paul Leach <paulle@microsoft.com>
- Date: Fri, 26 Apr 1996 18:21:49 -0700
- To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'hallam@w3.org'" <hallam@w3.org>
- Cc: "'fielding@avron.ics.uci.edu'" <fielding@avron.ICS.UCI.EDU>
>---------- >From: hallam@w3.org[SMTP:hallam@w3.org] >Sent: Friday, April 26, 1996 5:14 PM > >Paul writes: > >>Digest Auth already has the algorithm as a parameter. The name >>"Content-MD5" can't be changed for historical reasons. > >The problem with digest auth that I hadn't anticipated is that as >presently >stated the spec means that if you change the keyed digest algorithm you >also >need to exchange a separate shared secert. Not really. The shared secret is the password, not its hash. Giving H(A1) to a server is just a way a group of servers can be given the password without needing to have them all have the password in plaintext. How they get it betwen themselves is outside the scope of the spec. > >This is bad practice cryptographically, (mea culpa). The shared secret >generation step uses only the one way property of MD5. The >authentication >function uses the collision resistance funtion and the one-wayness. Its >only the >collision resistance that is compromised, not the one-wayness. Ie >refering to >the spec where we have > >Digest = H ( H(A1), nonce, H(a2)) > >A1 = username : realm : password >a2 = Method : URI > >The password file stores H(a1), so it is convenient to use a single >digest >function for all keyed digests ie we have > > >Digest = SHA ( MD5(A1), nonce, SHA(a2)) And if we do nothing, it will be Digest = SHA(SHA(A1), nonce, SHA(A2)) Doesn't seem like a big deal. Servers that want to support both MD5 and SHA will have to have SHA(A1) and/or MD5(A1) entries in a table for each user. In your scheme, servers that only want to support SHA would have to have an implementation of MD5 available -- and they might not have a license from RSA DSI. >
Received on Friday, 26 April 1996 18:24:53 UTC