Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 02 Mar 2009 10:37:33 -0800

Ping ?

23 feb 2009 kl. 08:59 skrev Love Hörnquist Åstrand:

>>>>    This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF   
>>>> and
>>>>    with dkLen == output length of HMAC() == output length of H().
>>>
>>> If it is PBKDF2 is should say so and not be fuzzy.
>>
>> If somebody can verify that independently, then I will change the  
>> text ;-).
>
> Just write that it uses PBKDF2 with HMAC and output keysize = sizeof 
> (H(), put the description in an non normative appendix.
>
> It looks like PBKDF2 to me.
>
>>> When I see Hi(str, salt), I get confused every time, i is an input
>>> parameter, but is still part of the function name ?
>>
>> Yea. It Should be <Something>(str, salt, i)
>>
>>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>>> That  does that accomplish ?
>>
>> The server is able to calculate ClientSignature. From the ClientProof
>> and that it can recover ClientKey, apply hash function once to get
>> StoredKey and can verify that the client really knows the StoredKey
>> (i.e. it knows the password).
>
> If the client can calculate ClientSignature = HMAC(H(H(PBKDF2 
> (password, salt, i))), AuthMessage),
> I would not be worried about it not knowing the password, why do you  
> need the extra step ?
>
> Chris, this was in -00 of the draft, why did you do it this way ?
>
> Right now the client and server key differences is:
>
> ClientKey = H(SaltedPassword)
> ServerKey = HMAC(SaltedPassword, salt)
>
> Why are the derived by two different methods ? (why not XKey = HMAC 
> (SaltedKey, "X key")
>
> Love
>

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 02 Mar 2009 10:37:11 -0800

> (i.e. it knows the password).

What accomplishes that that HMAC(stored-key, auth-message) doesn't  
already.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 02 Mar 2009 10:35:30 -0800

22 feb 2009 kl. 02:47 skrev Alexey Melnikov:

> This contains some minor fixes discovered by Dave Cridland and myself
> while implementing the spec (actually 2 separate implementations,  
> one in
> C and one in Python), in particular an error in ABNF production name.

No test vectors, specificly for the string2key function (which  
probably not is going to change).

Love

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 2 Mar 2009 23:55:53 +0100

> What accomplishes that that HMAC(stored-key, auth-message) doesn't  

If clients could send that to authenticate, stored-key would be
password-equivalent.  That is, someone with access to stored-key could
impersonate the user.  Sending ClientKey XOR ClientSignature makes that
one step harder:  You need both stored-key and to have listened to an
auth session.

-- 
Hallvard

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 02 Mar 2009 15:25:04 -0800

> one step harder:  You need both stored-key and to have listened to an

Thank you for explain this, this need to go into the draft.

Love

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Mar 2009 23:31:52 +0000

> probably not is going to change).

Ok, I can add that once we have 2 independent implementations.

---

From: Chris Newman <[email-masked]>
Date: Mon, 23 Mar 2009 13:13:56 -0700

--On February 23, 2009 8:59:44 -0800 Love Hörnquist Åstrand <[email-masked]> 
wrote:
> Why are the derived by two different methods ? (why not XKey =
> HMAC(SaltedKey, "X key")

I just realized I hadn't mentioned publicly that I think this would be a 
good change.

Specifically:

 ClientKey = HMAC(SaltedPassword, "Client Key")
 ServerKey = HMAC(SaltedPassword, "Server Key")

I think this actually makes the algorithm description a bit easier to 
understand.  What do others think?

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Mar 2009 08:15:42 +0100

Chris Newman <[email-masked]> writes:

> --On February 23, 2009 8:59:44 -0800 Love Hörnquist Åstrand
> <[email-masked]> wrote:
> I just realized I hadn't mentioned publicly that I think this would be
> a good change.
>
> Specifically:
>

I had the same thought when I reviewed the protocol, but didn't bring it
up before.  I would support this change.  I think it actually makes the
protocol stronger, because HMAC's have different cryptographic
properties than hashes.  For example, HMAC-MD5 is still secure even
though MD5 is considered broken.  That is a good property to have in a
protocol like this, especially when we chose SHA-1 for the hash.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Mar 2009 06:26:36 -0700

> understand.  What do others think?

I don't really care. I've already implemented the old way, but changing 
my implementation wouldn't be difficult.