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

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Feb 2009 10:47:30 +0000

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.

Subject: I-D Action:draft-newman-auth-scram-10.txt
From: [email-masked]
To: [email-masked]
Date: Sun, 22 Feb 2009 02:45:01 -0800 (PST)
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-10.txt
	Pages           : 18
	Date            : 2009-02-22

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 22 Feb 2009 16:59:27 -0800

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

> C and one in Python), in particular an error in ABNF production name

The draft says:

 >      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.

When I see Hi(str, salt), I get confused every time, i is an input  
parameter, but is still part of the function name ?

Why is ClientProof  the result of ClientKey XOR ClientSignature ? That  
does that accomplish ?

Love

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Feb 2009 11:03:55 +0000

Love Hörnquist Åstrand wrote:

> >      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  and

If somebody can verify that independently, then I will change the text ;-).

> 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).

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Feb 2009 08:59:44 -0800

> If somebody can verify that independently, then I will change the  

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.

> (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