Subject: [sasl] Implementing SCRAM (2)

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Sep 2009 16:01:34 +0200

The document doesn't say whether unassigned code points are allowed in
SASLprep'ed usernames, i.e., whether the strings are considered stored
or query strings.  The stringprep algorithm (and consequently SASLprep)
behaves different depending on which mode is requested.  See section 7
of RFC 3454.  To get interoperability and a consistent user experience I
think the document should clarify this.

I don't care strongly if unassigned code points are permitted or not,
and pending any argument for permitting unassigned code points, my
preference it to disallow them and treat the username as a stored
string.  Does anyone else care strongly?

Thus my suggestion would be:

OLD:
         Before sending the username to the server, the client MUST
         prepare the username using the "SASLPrep" profile [RFC4013] of
         the "stringprep" algorithm [RFC3454] 
...
         Upon receipt of the username by the server, the server SHOULD
         prepare it using the "SASLPrep" profile [RFC4013] of the
         "stringprep" algorithm [RFC3454].

NEW:
         Before sending the username to the server, the client MUST
         prepare the username using the "SASLPrep" profile [RFC4013] of
         the "stringprep" algorithm [RFC3454] treating it as a stored
         string (i.e., unassigned code points are forbidden).
...
         Upon receipt of the username by the server, the server SHOULD
         prepare it using the "SASLPrep" profile [RFC4013] of the
         "stringprep" algorithm [RFC3454] treating it as a stored
         string (i.e., unassigned code points are forbidden).

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 9 Sep 2009 07:18:42 -0700

> string.  Does anyone else care strongly?

The client should prepare as query strings.  The server should prepare  
as stored strings.

-- Kurt

> _______________________________________________
> sasl mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sasl

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 11:11:04 -0500

> The client should prepare as query strings.  The server should prepare  

Strongly agreed!

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Sep 2009 18:40:39 +0200

>> The client should prepare as query strings.  The server should prepare  

My updated suggestion would then be:

OLD:
         the "stringprep" algorithm [RFC3454].

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

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Sep 2009 21:44:28 +0100

>         string (i.e., unassigned code points are forbidden).
Changed.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 09 Sep 2009 10:23:35 -0400

--On Wednesday, September 09, 2009 07:18:42 AM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> The client should prepare as query strings.  The server should prepare as
> stored strings.

Almost right.

The client should prepare as query strings.
The server, in a SASL exchange, should prepare as query strings.
The process that maintains the database should prepare as storage strings 
before updating the database.

The point is to avoid putting anything into the database if you're not 100% 
sure what its canonical form is.  Otherwise, the canonical form could turn 
out to be something else, and then nothing will ever find that entry, and 
upgrading the software that stored the incorrect entry won't fix it.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 21:30:02 +0100

Jeffrey Hutzelman wrote:

> The process that maintains the database should prepare as storage 
> strings before updating the database.

After thinking more about this I agree with you.

> The point is to avoid putting anything into the database if you're not 
> 100% sure what its canonical form is.  Otherwise, the canonical form 
> could turn out to be something else, and then nothing will ever find 
> that entry, and upgrading the software that stored the incorrect entry 
> won't fix it.

This is true. But I am not sure whether we need to say anything about 
this and if we should, in which document.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 10 Sep 2009 16:36:04 -0400

> this and if we should, in which document.

We should, in stringprep.  Given that stringprep is already published, it's 
fortunate that it covers this issue in a fair amount of detail. :-)