


From: Paul Leach <paulle@microsoft.com>
Date: Fri, 26 Apr 1996 18:21:49 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960427012149Z-14978@tide19.microsoft.com>
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
>stated the spec means that if you change the keyed digest algorithm you
>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
>This is bad practice cryptographically, (mea culpa). The shared secret 
>generation step uses only the one way property of MD5. The
>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
>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

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 EDT
