Subject: [sasl] I-D Action:draft-ietf-sasl-scram-08.txt

From: [email-masked]
Date: Fri, 2 Oct 2009 10:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title           : Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-08.txt
	Pages           : 36
	Date            : 2009-10-02

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 Simple Authentication and
Security Layer (SASL, RFC 4422) 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-ietf-sasl-scram-08.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.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 Oct 2009 21:54:24 +0200

This version seems fine in general, but re SASLprep on password it says:

  o Normalize(str): Apply a Unicode normalization algorithm to a UTF-8
    [RFC3629] encoded "str". The resulting string is also in UTF-8.
    Implementations SHOULD use the SASLPrep profile [RFC4013] of the
    "stringprep" algorithm [RFC3454] as the normalization algorithm.

That text does not resolve whether Normalize() should be invoked with
unassigned code points permitted or not.  There were different
suggestions on what clients and servers should do in earlier
discussions, so I believe the text has to be explicit on what clients
and servers needs to do.

I don't care strongly, but my preference is to disallow unassigned code
points everywhere where a string is hashed.  Allowing unassigned code
points introduce uncertainty in the algorithm, and I find that to rarely
be useful in practice.  My experience is that allowing unassigned code
points is useful when the string is transferred to the other side for
comparison, but when the string is hashed that is no longer the case.  I
am aware that others have different preferences.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 15:00:03 -0500

> am aware that others have different preferences.

Here we must treat passwords as storage strings.  SASLprep doesn't
distinguish between query and stored strings, but it does reference
Stringprep, which does.  And Stringprep has this to say about stored
strings: "[s]tored strings using the profile MUST NOT contain any
unassigned code points".

New text:

   o  Normalize(str): Apply a Unicode normalization algorithm to a UTF-8
      [RFC3629] encoded "str".  The resulting string is also in UTF-8.
      Implementations SHOULD use the SASLPrep profile [RFC4013] of the
      "stringprep" algorithm [RFC3454] as the normalization algorithm.
----> Note that, for SCRAM, passwords are "stored strings", which means
----> that unassigned codepoints in SCRAM passwords are prohibited (see
----> RFC3454, section 7).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 Oct 2009 22:42:43 +0200

> ----> RFC3454, section 7).

+1

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 02 Oct 2009 21:44:07 +0100

>>----> RFC3454, section 7).
Fine with me. I can post -09 later today (or over the weekend).

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Oct 2009 00:22:21 +0100

>----> RFC3454, section 7).
Applied to my copy. I've reworded the text not to say "password", as 
this is a generic definition of the Normalize function.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Oct 2009 07:51:49 +0200

> this is a generic definition of the Normalize function.

I don't think that works, unassigned codepoints should only be
disallowed for passwords, not for usernames.  Elsewhere SCRAM says

         Before sending the username to the server, the client SHOULD
         prepare the username using the "SASLPrep" profile [RFC4013] of
         the "stringprep" algorithm [RFC3454] treating it as a query
         string (i.e., unassigned Unicode code points are allowed).

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Oct 2009 11:29:41 +0100

>         string (i.e., unassigned Unicode code points are allowed).
The Normalize(str) function is only being used for passwords, so I don't 
see a problem.

If we are to change the document to start using this function elsewhere, 
then the text would need to be moved.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Oct 2009 13:08:49 +0200

Alexey Melnikov <[email-masked]> writes:

> The Normalize(str) function is only being used for passwords, so I
> don't see a problem.

Ah right!  Never mind.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 8 Oct 2009 11:03:59 -0500

>          string (i.e., unassigned Unicode code points are allowed).

That's fine with me.  It's important that the server not re-encode the
client's first message when verifying the ClientSignature.

Nico
--