[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCRAM-04 questions


Frank Ellermann wrote on 6/16/07 19:58 +0200:

Hi, I tried to implement SCRAM-04 based on MD5.  Some problems:

1 - The I-D uses B64 as specified in RFC 2045, but the example
    strings s=PxR/wv+epq and c=QWBv+XbwcaI/wp are "ambiguous",
    compare RFC 4648.

    Do you mean s=PxR/wv+epqA= and c=QWBv+XbwcaI/wpA= ?

    For n= and a= names the I-D encodes '=' as '=3D', and maybe
    you tried to avoid B64 '=' padding using the UTF-7 version.

    IMO you could just use hex. instead B64 for s=, c=, p=, and
    v= (at least for p= and v= the encoded length is irrelavant).
The examples are placeholders and don't contain valid data yet. This is fairly preliminary -- more about circulating the idea than "implement now" level. I'm hoping it will merge with the HEXA proposal and add channel bindings. But that decision will be made by the primary editor (not me). 


2 - The terms in the algorithm overview confused me.  There's a
    StoredKey = H( ClientKey ) with ClientKey = H( SaltedPw ),
    but the server needs ServerKey = HMAC( SaltedPw, salt ).  So
    apparently the server has to "store" the SaltedPw, while a
    client likely doesn't store any password at all, it gets the
    original password as input.

    If that's correct I propose to rename the terms:

    StoredKey := Hi( HMAC( password, salt )) /* was SaltedPw */
    ClientKey := H( StoredKey )
    ServerKey := HMAC( StoredKey, salt )
    ServerSig := HMAC( ServerKey, Msg )
An attacker who gets the saltedPw has the ability to impersonate the client, so having the server store that would remove a nice security property of SCRAM. The server should instead store the quad { username, salt, H(ClientKey), ServerKey} (ServerKey is only necessary if mutual authentication is performed). The ClientKey can't be derived from that quad so the stored information can't be used to impersonate the client by itself. This is a difference from DIGEST-MD5 where the server stored information is plaintext equivalent and sufficient to impersonate the client in that realm. 


6 - As always annotated examples with a known password will help.


Agreed.


    Before I try to tackle v= I'd like to know if the following
    result for p= is still correct (using MD5 as hash):


MD5 is sufficiently broken that it's unwise to use in new protocols.

               - Chris