Subject: CRAM-MD5 stringprep text

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 12 Jan 2004 14:34:09 -0700

--On 2003-12-1 11:39 PM +0100 Simon Josefsson <[email-masked]> wrote:

> Hello, I have read the document.  Some comments:
>
> ,----
>|      The client MUST prepare the user name and shared secret strings
>|      using the [SASLPrep] profile of the [StringPrep] algorithm.  The
>|      resulting values MUST be encoded as UTF-8 [UTF8].
> `----
>
> I suggest adding:
>
>       The server MUST prepare the shared secret string using the
>       [SASLPrep] profile of the [StringPrep] algorithm.  The resulting
>       value MUST be encoded as UTF-8 [UTF8].  The server may store the
>       prepared string instead of, or as well as, the unprepared
>       string, so that it does not have to prepare it every time it is
>       needed for computation.  However, if the original, unprepared
>       string, is not stored, it may render the computed secret to be
>       incompatible with a future revisions of SASLPrep that support
>       currently unassigned code points (compare section 7 of
>       [StringPrep]).  It is therefor recommended to store the
>       unprepared string in the database.

There was quite a bit of discussion over this suggestion, but I don't 
think we reached any consensus about including the additional text. I'm 
about to push a new draft, and would appreciate a hum over whether or 
not it should be added.

--lyndon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Jan 2004 17:38:26 -0500

I'd like to hear from people who believe we should allow unassigned
codepoints in cram-md5.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Jan 2004 14:34:35 -0800

At 01:34 PM 1/12/2004, Lyndon Nerenberg wrote:

>There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added.

The suggestion seems quite odd to me.  If SASLprep were to revised, that
revision would allow for an expanded set of inputs (and likely with an
expanded set of outputs). Or to put it another way, an input string which
fails today's SASLprep might not fail tomorrow's SASLprep (producing
either a new output or an old output).

I would think it far better to recommend that servers refuse to
store input strings and/or their prepared output of the input strings
if the current SASLprep fails.  Instead, they should report a error.
This because it makes little sense to store a string which is useless
day (in SASL).

Kurt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 12 Jan 2004 16:43:05 -0700

> I'd like to hear from people who believe we should allow unassigned

Taking off my editor's visor, I personally think this whole issue is 
out of scope for the CRAM document, and needs to be addressed in the 
base SASL document, or not at all (i.e. let the stringprep document 
says what needs to be said, if anything).

--lyndon

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 13 Jan 2004 00:29:07 -0500

> says what needs to be said, if anything).

I agree.

As for whether or not unassigned points may be sent? yes.   May they be 
stored? no.
This is to prevent interoperability problems if SASLprep was to be 
updated to support a newer
version of Unicode. 

Jeffrey Altman

P.S. - the only possible exception would be the private use area for 
internal use.  but
as was demonstrated during the last IETF meeting, while it is 
theoretically possible for
private use area characters to be treated as assigned internal to an 
organization, the
hoops that would have to be gone through to make it work hardly seem 
worth it.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Jan 2004 22:53:20 -0500

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> --On 2004-1-12 5:38 PM -0500 Sam Hartman
    Lyndon> <[email-masked]> wrote:
    >> I'd like to hear from people who believe we should allow
    >> unassigned codepoints in cram-md5.

    Lyndon> Taking off my editor's visor, I personally think this
    Lyndon> whole issue is out of scope for the CRAM document, and
    Lyndon> needs to be addressed in the base SASL document, or not at
    Lyndon> all (i.e. let the stringprep document says what needs to
    Lyndon> be said, if anything).

I'm currently sitting on a plane, and while I have my personal mail, I
don't seem to have comments only addressed to the SASL list.
Apologies if this is already addressed.

I disagree and believe that the choice of encoding and normalization
for the authentication identity is entirely a matter of choice for the
mechanism document and is out of scope for normative comments from the
base spec.  The base spec can and does give advice on what best
practice is with regard to these issues.

For example the GSSAPI document cannot say to use UTF8 or any
particular normalization; both these issues are matters for the GSSAPI
mechanism document to decide.  Some existing mechanisms do not
currently support UTF8 but do support internationalized GSSAPI names.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Jan 2004 22:05:01 -0800

> practice is with regard to these issues.

Fair enough. I'm not convinced there is consensus either for or against 
adding Sam's proposed text. Could the WG chairs please conduct a 'hum' 
over whether the text should be added to the draft? This is the last 
outstanding issue, and as soon as it's resolved we can get this 
document into last call.

--lyndon

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Jan 2004 15:31:41 -0500

I think it should be common to all mechanisms, and thus belongs in the 
base spec.

	Tony Hansen
	[email-masked]

Lyndon Nerenberg wrote:

> outstanding issue, and as soon as it's resolved we can get this document 
> into last call.
> 
> --lyndon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 13:04:48 -0800

At 03:43 PM 1/12/2004, Lyndon Nerenberg wrote:

>Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything).

Depends on what you mean by "whole issue".  The unassigned
code point handling is certain germane to the preparation
of strings in CRAM-MD5.  However, CRAM-MD5 should just
rely on SASLprep to cover the particulars of that handling.

Now, if you mean this bit:
      However, if the original, unprepared
      string, is not stored, it may render the computed secret to be
      incompatible with a future revisions of SASLPrep that support
      currently unassigned code points (compare section 7 of
      [StringPrep]).  It is therefor recommended to store the
      unprepared string in the database.

I would agree that this text should mot be included in the document.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 13:31:53 -0800

At 10:05 PM 1/20/2004, you wrote:
>Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text.  Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call.

Last CRAM-MD5 text I saw proposed was from Simon, not Sam.
  http://www.imc.org/ietf-sasl/mail-archive/msg01371.html
If you were asking about some other suggested text, please
send me a URL to the post suggesting it.

I note that the WG has already achieved, I believe,
consensus that:
 1) form of authentication identities are, by their very
 nature, mechanism specific,
 2) mechanisms whose authentication identities are in the
 form of a simple user name should use SASLprep, and
 3) mechanisms whose shared secrets are in the form of a
 simple password should use SASLprep.

I do not think there is significant contention here.  In
particular, I don't see anyone voicing concern regarding this
portion of the suggested text:

      needed for computation. 

What is in contention is whether the above text should be
followed by this additional text:

I would like to hear comments as why this additional text should
or should not be added.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jan 2004 17:41:51 -0500

>       unprepared string in the database.

It is true, IF the server's database is allowed to contain secrets derived 
from a password containing an unassigned code point.  This brings us back 
to the original point -- a "storage" string should not be allowed to 
contain unassigned code points.

This _is_ a mechanism-specific issue.  SASLprep can't specify globally 
whether unassigned code points are permitted or not, because the answer 
depends on context -- they are permitted in "query" strings, but not in 
"storage" strings, and it is up to each specific user of SASLprep to 
specify whether unassigned code points are permitted.

It cannot even be decided globally for SASL -- SASL doesn't deal in 
"usernames" and "passwords"; it deals in "authentication identities" (whose 
form is necessarily mechanism-specific) and "authorization identities" 
(whose form is necessarily application-specific).  Since most SASL 
mechanisms are and will be built on otherwise existing authentication 
technologies, it is inappropriate for SASL to dictate the form of 
authentication identities or how they should be prepared.  I believe we 
already have concensus on this issue.

Returning to the present question...
IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords 
stored by the server are permitted to contain unassigned code points.  If 
that is not permitted, then alternate (but very similar) text should be 
included stating such.

It should be pointed out that storing the unprepared string is not a 
solution to the server's problem.  Unless the server and client agree on 
the normalization mapping for every character in the client's password, the 
authentication will fail.  It is intended that for code points which both 
sides believe are assigned, this cannot happen.  However, if one side 
believes a code point is unassigned, and the other believes it should be 
mapped to something else, then you lose.

In this scenario, it does not matter whether the server prepared the string 
when it was stored in the database, or when the client made the request. 
That only matters when you upgrade the server.  If strings are prepared at 
storage time, upgrading the server has no effect.  If they are prepared 
when a request is received, then upgrading the server will fix problems for 
some clients (those which were newer than the server), and create new 
problems for other clients (those which are now older than the server). 
_THIS_ is an example of why unassigned code points should not be permitted 
in storage strings.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 16:13:51 -0800

At 02:41 PM 1/21/2004, Jeffrey Hutzelman wrote:
>On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" <[email-masked]> wrote:
>It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point.  This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points.
>
>This _is_ a mechanism-specific issue.  SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted.

Er, right, it's up to the mechanism specification to state whether,
and if so how, SASLprep is used.  CRAM-MD5 says SASLprep is used.

Is this issue simply which the server provided shared secret is
a "storage" string or not?

To answer that, can we just ask, is the client provided shared
secret a "query" string?   If yes, then the server provided
shared secret must be a "storage" string.  Right?

>It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific).  Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared.  I believe we already have concensus on this issue.

This is, I think, is basically in line with what I said.

>IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points.  If that is not permitted, then alternate (but very similar) text should be included stating such.

Sounds like your asking for a clear indication in the document
as which strings are "query" strings, which are "storage" strings,
and what that implies.  That seems quite reasonable.

>It should be pointed out that storing the unprepared string is not a solution to the server's problem.  Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail.  It is intended that for code points which both sides believe are assigned, this cannot happen.  However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose.
>
>In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server.  If strings are prepared at storage time, upgrading the server has no effect.  If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings.

As I understand it, this suggested additional text allows what is
an invalid password representation (contains unassigned characters)
in server to become a valid password representation (those characters
are now assigned) upon some future update of that server.

This seems really odd to me.  It would seem far wiser to refuse
to accept invalid representations (due to unassigned characters)
as one has no clue at the time of implementation whether or not
a particular invalid representation will ever come valid in the
future.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jan 2004 04:33:49 -0500

>>>>> "Tony" == Tony Hansen <[email-masked]> writes:

    Tony> I think it should be common to all mechanisms, and thus
    Tony> belongs in the base spec.

    Tony> 	Tony Hansen [email-masked]

    Tony> Lyndon Nerenberg wrote:

    >>> I disagree and believe that the choice of encoding and
    >>> normalization for the authentication identity is entirely a
    >>> matter of choice for the mechanism document and is out of
    >>> scope for normative comments from the base spec.  The base
    >>> spec can and does give advice on what best practice is with
    >>> regard to these issues.
    >> Fair enough. I'm not convinced there is consensus either for or
    >> against adding Sam's proposed text. Could the WG chairs please
    >> conduct a 'hum' over whether the text should be added to the
    >> draft?  This is the last outstanding issue, and as soon as it's
    >> resolved we can get this document into last call.  --lyndon

It seems like you are disagreeing fairly strongly with what I'm
saying.  I assert (and attempted to justify in text that was trimmed)
why authentication identifier encoding must be a mechanism matter.

You assert disagreement.

Would you please describe why you think I'm wrong or how you think I'm
unclear or otherwise explain how you think it would work to treat this
as a global issue?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jan 2004 04:36:54 -0500

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> --On 2004-1-15 10:53 PM -0500 Sam Hartman
    Lyndon> <[email-masked]> wrote:

    >> matter of choice for the mechanism document and is out of scope
    >> for normative comments from the base spec.  The base spec can
    >> and does give advice on what best practice is with regard to
    >> these issues.

    Lyndon> Fair enough. I'm not convinced there is consensus either
    Lyndon> for or against adding Sam's proposed text. Could the WG
    Lyndon> chairs please conduct a 'hum' over whether the text should
    Lyndon> be added to the draft? This is the last outstanding issue,
    Lyndon> and as soon as it's resolved we can get this document into
    Lyndon> last call.

I don't recall proposing any text.  I may be confused here.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 12 Jan 2004 14:34:09 -0700

--lyndon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Jan 2004 17:38:26 -0500

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 Jan 2004 14:34:35 -0800

Kurt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 12 Jan 2004 16:43:05 -0700

--lyndon

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 13 Jan 2004 00:29:07 -0500

I agree.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Jan 2004 22:53:20 -0500

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Jan 2004 22:05:01 -0800

--lyndon

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Jan 2004 15:31:41 -0500

Tony Hansen
	[email-masked]

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 13:04:48 -0800

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 13:31:53 -0800

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jan 2004 17:41:51 -0500

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 16:13:51 -0800

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jan 2004 04:33:49 -0500

You assert disagreement.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jan 2004 04:36:54 -0500