Subject: I-D ACTION:draft-ietf-sasl-plain-05.txt

From: [email-masked]
Date: Tue, 26 Oct 2004 17:04:44 -0400

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		: The Plain SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-plain-05.txt
	Pages		: 9
	Date		: 2004-10-26
	
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-plain-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-plain-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 26 Oct 2004 19:46:42 -0700

In this revision, aside from minor editorial changes, the
message clarified to be a string of UTF-8 encoded Unicode
characters and the use of %x00 for NULL (U+0000) was
clarified to be the UTF-8 encoding of the NULL character. 

I believe this document should now be progressed to the IESG.

-- Kurt

PS: the double blanklines in the I-D is a new Secretariat'ism
which seems to be inflicted on new I-Ds.

At 02:04 PM 10/26/2004, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-plain-05.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-plain-05.txt>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 11:30:34 +0200

Why is SHALL used instead of MUST in the paragraph below?  Are there
known situations where PLAIN will be used without SASLPrep?  Why
shouldn't a failed string preparation always lead to verification
failure?

Further, please make it explicit which strings are query strings and
which are stored strings, and mention the value of the AllowUnassigned
flag for each string using MUST.  It seems the intention is that all
strings received from the client are query strings, and the password
(whether stored in unprepared, prepared or hashed form) is a stored
string.  If you don't see why this is necessary, I can elaborate.

  The presented authentication identity and password strings are not to
  be compared directly with stored strings.  The server SHALL first
  prepare authentication identity and password strings using the
  [SASLPrep] profile of the [StringPrep] algorithm.  Per Section 7 of
  [StringPrep], unassigned code points may appear in prepared presented
  (query) strings but are prohibited in stored strings.  If preparation
  fails or results in an empty string, verification SHALL fail.  If the
  server stores only the hash of expected string, the string MUST be
  prepared before generation of the hash.

Thanks.

---

From: Philip Guenther <[email-masked]>
Date: Wed, 27 Oct 2004 03:08:34 -0700

Simon Josefsson <[email-masked]> writes:
>Why is SHALL used instead of MUST in the paragraph below?

Per RFC 2119, SHALL and MUST have the same meaning:
---
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
---

Philip Guenther

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 15:35:45 +0200

>    definition is an absolute requirement of the specification.

Oops, what a thinko.  Thanks.

Still, making explicit which strings are to be considered query
strings and stored strings still seem useful.

Sorry,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 11:09:47 -0700

At 02:30 AM 10/27/2004, Simon Josefsson wrote:
>which are stored strings,

Personally, I think the current text is sufficiently clear.
However, adding:
   The presented strings are to be regarded as "query"
   strings [StringPrep].
as the 3rd sentence of the quoted paragraph could further
clarify which strings are to regarded as "query" strings.
I do not see any ambiguity as to which strings are to
be considered "stored" strings.

>and mention the value of the AllowUnassigned
>flag for each string using MUST.

I cannot find the term "AllowUnassigned flag" anywhere in
the specification (including normative references).

The text does, however, not only says that strings SHALL
be prepared in accordance with StringPrep, it describes
what that means in regards to unassigned code points
and the two classes of strings.

>It seems the intention is that all

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 20:42:10 +0200

> be considered "stored" strings.

A password that the server receive from some online external database
(i.e., not "stored" locally) could be considered a query string (from
the database) into the verification process.  From the server's point
of view, it is "querying" whether the password it knows is the same as
the one provided by the client.  So I see an ambiguity.

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 12:26:57 -0700

At 11:42 AM 10/27/2004, Simon Josefsson wrote:

>the database) into the verification process. 

 From a SASL PLAIN perspective, any such database as to be
viewed as part of the server implementation.  Whether the
database is "internal" or "external" is simply an
implementation detail.  From this perspective, the
password stored is a stored string.  It's irrelevant
whether the server stores in a local or remote database.

(I'm getting a sense of "deja vu" here, didn't we already
discuss this issue?  If so, is there a particular reason
why we should repeat that discussion?)

> From the server's point

It seems you are saying:
        From the server's point of view, the server is
        "querying" whether the password the server knows
        is the same as the one provided by the client.

Er, in this case, I think server is "determining" would
be a more appropriate verb as its not clear who the
server would be querying to do a comparison between
the password it knows (e.g., stored string) and the one 
provided by the client (e.g., the presented string).

But as this makes little sense in the context of the above
discussion, so you must have meant to say something else.
Please clarify.

Thanks, Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:34:29 -0400

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> At 02:30 AM 10/27/2004, Simon Josefsson wrote:
    >> Further, please make it explicit which strings are query
    >> strings and which are stored strings,

    Kurt> Personally, I think the current text is sufficiently clear.
    Kurt> However, adding: The presented strings are to be regarded as
    Kurt> "query" strings [StringPrep].  as the 3rd sentence of the
    Kurt> quoted paragraph could further clarify which strings are to
    Kurt> regarded as "query" strings.  I do not see any ambiguity as
    Kurt> to which strings are to be considered "stored" strings.

In my mind adding this text makes the draft more confusing and does
not add anything.

It's my opinion that the working group has already reached consensus
on this draft.  If people believe that the draft does not reflect that
consensus, please bring forward that disagreement.  However the bar
for opening new issues should be very high at this point.

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Oct 2004 00:08:43 +0200

> whether the server stores in a local or remote database.

I don't think this follow from the specification.

What I am looking for is text that say that the PLAIN server code
should treat the local password as a stored string.  Currently, it
seems to me that you and the PLAIN document only assume that the
password can only be viewed as a stored string.  It would be better if
the document was explicit about it.

The problem is rooted in that StringPrep (SASLPrep) do not define in
who's view strings should be considered query or stored strings.  What
is a stored string from one point of view, may be considered a query
string from another point of view.  So any document using SASLPrep
must define which strings are query strings, and which are stored
strings.  It does not follow implicitly.

In lesser words, please modify your proposed sentence into the
following and add it:

    The presented strings are to be regarded as "query" strings
    [StringPrep], and the local strings as "stored" strings.

> why we should repeat that discussion?)

I don't recall what the conclusion was of any earlier discussion, if
any, and I believe the current document should be improved.

> discussion, so you must have meant to say something else.

To my reading, your explanation describe what I mean.

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 15:50:48 -0700

>I don't think this follow from the specification.

It follows from SASL PLAIN being a client/server protocol
specification.  Everything on side is referred the client.
Everything on the other is referred to as the server.
The architecture of the client and server are irrelevant
to the protocol.  It matters not whether the peer is
constructed from many components which interact in some
way or the peer is constructed as a monolith, because
the peers obligations to the other peer is the same
regardless.

>should treat the local password as a stored string.

What's a "local password"?

>Currently, it
>password can only be viewed as a stored string.

The presented string is compared against a stored string
(or equivalent).  What the document doesn't say, and shouldn't
say, is in which component that comparison is made or
in what component of the server stored values are fetched
from or any other implementation detail.

>It would be better if
>who's view strings should be considered query or stored strings.

Stringprep relies on incorporating specifications to detail
their view as to what is to be regarded as a query string
and what is to be regarded as a stored string.  

>What

The PLAIN ID does detail what is a query string and
a stored string.  It uses the term "stored" string
repeated.  And it uses the term "presented string"
in a manner which makes it clear that these are
query strings.

>    [StringPrep], and the local strings as "stored" strings.

What's a "local" string?  And why are why defining it to
the same as a "stored string".  Now, you could say:
stored strings are regarded as "stored" strings [StringPrep],
but that is stating the obvious (IMO).

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Oct 2004 01:49:56 +0200

> What's a "local password"?

I was trying to come up with a descriptive word for it, but I guess I
failed.  What I meant by "local password" was the input password that
the server end up using, after string preparation, in comparing the
password provided by the client.  The client provided password is the
"presented" password, and the other password is "local" in the server.

> (or equivalent).

Right.  What is missing is that the password should be considered as a
stored string from the point of view of SASLPrep too, i.e., unassigned
code points are not allowed.

> What the document doesn't say, and shouldn't

Agreed.

> and what is to be regarded as a stored string.

Agreed.  And that detailing is what I believe could be improved in
PLAIN.

> in a manner which makes it clear that these are

It seems we are agreeing on the intention, but not what the document
is saying.

> but that is stating the obvious (IMO).

I think the terminology here is poor.

I want to differentiate between the "stored string" in the
StringPrep/SASLPrep sense, and the "local password" which the server
uses as input to the string preparation, and eventually uses to
compare with the presented password.

Calling the latter "local password" a "stored string" implicitly
assume that SASLprep has already been applied to the string.  And that
unassigned code points are forbidden in the output.  But that cannot
be assumed, it is something that must be described by the document.

To be more concrete: Here is the part of the document with normative
text regarding stored strings:

  Upon receipt of the message, the server will verify the presented
  authentication identity (authcid) and password (passwd) with the
  system authentication database, and verify the authentication
  credentials permit the client to act as the (presented or derived)
  authorization identity.  If both steps succeed, the user is
  authenticated.

An attempt to modify this into something I believe would be more
correct would be:

  Upon receipt of the message, the server will verify the presented
  authentication identity (authcid) and password (passwd) with the
  system authentication database, which contain the "local" password
  for the authentication identity.  Next, the server verify that the
  authentication credentials permit the client to act as the
  (presented or derived) authorization identity.  If both steps
  succeed, the user is authenticated.

  The presented authentication identity and password strings are not
  to be compared directly with local strings.  The server SHALL first
  prepare authentication identity, presented password, and local
  password using the [SASLPrep] profile of the [StringPrep] algorithm.
  Per Section 7 of [StringPrep], unassigned code points may appear in
  prepared presented (query) strings but are prohibited in local
  (stored) strings.  If preparation fails or results in an empty
  string, verification SHALL fail.

  If the server stores only the hash of the expected password string,
  the string MUST be prepared, as a stored string, before generation
  of the hash.

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 18:16:58 -0700

At 04:49 PM 10/27/2004, Simon Josefsson wrote:
>I was trying to come up with a descriptive word for it,

I think "stored" is pretty descriptive.

>What is missing is that the password should be considered as a

I guess we'll have to agree to disagree here.

I do not believe this is missing from the I-D.  I find the
paragraph you quoted is quite clear as to which strings are
to be considered "query" strings and which are to be considered
"stored" strings during string preparation.  The I-D also
provides pseudo-code and further discussion which reenforces
which strings are to be considered "query" strings and which
are to be considered "stored" strings during preparation.

>I think the terminology here is poor.

"local string" is a poor term.

>compare with the presented password.

Such a differentiation will, I think, lead to confusion.

I think the text you offer is not better than the current
text.  I think it it is much worse than the current text.
I think the current text is sufficiently clear.

>  for the authentication identity.

What's a local password?  Isn't the password shared with
the user?  Can't the password be stored remotely?
And are you only applying the term "local" to the password? 
Wouldn't there also be a "local" authentication identity
string as well.  But that said, I also dislike explicitly
describing the contents of the system authentication database.

>                            Next, the server verify that the
>  (stored) strings.

Is the stored authentication identity string a local string or
a query string?

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Oct 2004 20:10:04 -0400

> the specification (including normative references).

This term was apparently used in some drafts of nameprep, and is referred
to in RFC3490 and draft-hoffman-rfc3490bis-02.txt.  Unfortunately, those 
references claim that the term is defined in RFC3491 and 
draft-hoffman-rfc3491bis-01.txt, respectively, and neither document defines 
the term.  Neither do stringprep or saslprep.

This flag was used as a parameter to the preparation algorithm in IDN, to 
indicate whether unassigned code points are permitted; it is what 
distinguishes between storage and query strings.  The profile defined by 
SASLprep does make such a distinction, but does not use a formally defined 
"flag".

We should mention in each case whether unassigned code points are permitted 
(query strings) or not (storage strings).  But we should not use a 
reference to an "AllowUnassigned flag" which our stringprep profile does 
not have.

> and the two classes of strings.

Then this should be sufficient.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Oct 2004 14:44:48 +0200

> I think "stored" is pretty descriptive.

For what is intended here, I disagree.  "Stored string" is a
StringPrep/SASLPrep term that denote strings that have or will be
prepared in a way that disallow unassigned code points in the output.

Talking about the strings that PLAIN servers should apply SASLPrep to
as "stored strings" does not give any clues which these strings are.

That is why I believe PLAIN must say which strings should be
considered as "stored strings", in the SASLprep point of view.  I
don't think this is clear now.

> are to be considered "stored" strings during preparation.

The pseudo-code hide all SASLPrep preparation of the "local password"
inside FetchPasswordHash, so it is clarified at all, in my opinion.

I agree the draft make it clear which strings are "query strings", but
I don't think it is clear which strings are "stored strings".

> What's a local password?

I believe I explained this in my last post.

The local password is the password the server has stored for the user,
whether in the form of a unprepared UTF-8 string, a SASLPrep prepared
string, or a hash of a SASLPrep prepared string.

> Isn't the password shared with the user?

Right.  But the server must have a copy (in some form), to compare
with what the user presents.

> Can't the password be stored remotely?

Of course.  But at some point, the server must have access to it,
that's why I argue it can be considered "local".

If you have a better term, that would be great.

> Wouldn't there also be a "local" authentication identity string as
> well.

That depend on the implementation.

I think most servers implement some form of database that map <authid>
to <password>.  It isn't efficient to prepare every <authid> in the
database using SASLPrep, to get a "local <authid>", and then compare
them with the presented <authid>.  So instead they look up the client
presented string in the database, and hope to find something.

> But that said, I also dislike explicitly describing the
> contents of the system authentication database.

If the term is to mean anything at all, there must be some meaning to
what a "system authentication database" is.

Describing that it contain <authid> and <password>, where the
<password> may be in raw, prepared, hashed or other forms that can be
used in verifying the client presented data doesn't preclude some
design, does it?  Currently, the term is used with no definition.

> Is the stored authentication identity string a local string or

It depends on the implementation.

I think some implementations take the presented <authid>, look it up
in a database, and hopefully get a password (in whatever form) back.
This assume that the database has been populated with prepared strings
with no unassigned code points.

Alternatively, if the database store unprepared strings, the
implementation may prepare the presented <authid> using SASLPrep with
no unassigned code points in the output, and then look up that string
in the database.

Thanks.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Oct 2004 15:05:15 +0200

> reference to an "AllowUnassigned flag" which our stringprep profile does 

I agree completely.  I further believe it is critical that it is clear
how to prepare every involved string.  Merely referring to SASLPrep is
not sufficient.  Documents must enforce _how_ SASLPrep is used on each
individual input string.    I.e., documents have to say whether or not
unassigned code points should be permitted in the output or not.

>> The text does, however, not only says that strings SHALL be
>> prepared in accordance with StringPrep, it describes what that
>> means in regards to unassigned code points and the two classes of
>> strings.
>

It would, although I appear to disagree with Kurt that the text is
not ambiguous about this.

I believe my opinion on this should now be clear, and that it is not
useful to carry on this discussion.  If everyone else who understand
the issue believe the documents are clear, then there shouldn't ever
be problems with the use of SASLprep in PLAIN, and all will be fine.

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 08:06:44 -0700

>I believe I explained this in my last post.

But you didn't explain it in the text that you offered
for consideration.  My questions in regards to the
offered text are written from the point of view of someone
who doesn't have any knowledge of your prior comments.
That is, my questions are from the point of view of
an independent developer reading the offered text as
if it was included in PLAIN's TS.

It makes no sense to me to say the password in 
local to the server when that password is clearly
shared with the client which presented it.  It's not
at all obvious that local password are refers to the
stored copy of the shared password at the server.

Kur

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Oct 2004 13:54:32 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> It would, although I appear to disagree with Kurt that the
    Simon> text is not ambiguous about this.

    Simon> I believe my opinion on this should now be clear, and that
    Simon> it is not useful to carry on this discussion.  If everyone
    Simon> else who understand the issue believe the documents are
    Simon> clear, then there shouldn't ever be problems with the use
    Simon> of SASLprep in PLAIN, and all will be fine.

Speaking as chair, I do not believe there is a working group consensus
to reopen this issue.

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 26 Oct 2004 19:46:42 -0700

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 11:30:34 +0200

Thanks.

---

From: Philip Guenther <[email-masked]>
Date: Wed, 27 Oct 2004 03:08:34 -0700

Philip Guenther

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 15:35:45 +0200

Sorry,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 11:09:47 -0700

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 20:42:10 +0200

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 12:26:57 -0700

It seems you are saying:

Thanks, Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:34:29 -0400

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Oct 2004 00:08:43 +0200

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 15:50:48 -0700

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Oct 2004 01:49:56 +0200

Agreed.

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 2004 18:16:58 -0700

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Oct 2004 20:10:04 -0400

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Oct 2004 14:44:48 +0200

Thanks.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Oct 2004 15:05:15 +0200

Thanks.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 08:06:44 -0700

Kur

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Oct 2004 13:54:32 -0400

--Sam