Subject: SASL Agenda for IETF#61

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 31 Oct 2004 18:43:33 -0800

Simple Authentication and Security Layer (SASL)
Tuesday, 9 November 2004  1545-1645
===================================

Chairs:
  Sam Hartman <[email-masked]>
  Kurt Zeilenga <[email-masked]>

Agenda:
  Introductions and Agenda Bashing
    - Chairs (5 minutes)
  Review of SASL Base last call
    - Chairs/Alexey (15 minutes)
  Digest MD5 (draft--ietf-sasl-rfc2831bis)
    - Alexey (10 minutes)
  GSSAPI (draft-ietf-sasl-gssapi)
    - Alexey (10 minutes)
  CRAM-MD5 (draft-ietf-sasl-crammd5)
    - TBD (10 minutes)
  Open mic
    - (remaining time) 

Date: Sun, 31 Oct 2004 18:43:33 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: SASL Agenda for IETF#61
Sender: [email-masked]

Simple Authentication and Security Layer (SASL)
Tuesday, 9 November 2004  1545-1645
===================================

Chairs:
  Sam Hartman <[email-masked]>
  Kurt Zeilenga <[email-masked]>

Agenda:
  Introductions and Agenda Bashing
    - Chairs (5 minutes)
  Review of SASL Base last call
    - Chairs/Alexey (15 minutes)
  Digest MD5 (draft--ietf-sasl-rfc2831bis)
    - Alexey (10 minutes)
  GSSAPI (draft-ietf-sasl-gssapi)
    - Alexey (10 minutes)
  CRAM-MD5 (draft-ietf-sasl-crammd5)
    - TBD (10 minutes)
  Open mic
    - (remaining time) 

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
From: Sam Hartman <[email-masked]>
Date: Fri, 29 Oct 2004 13:54:32 -0400
Sender: [email-masked]

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

Date: Fri, 29 Oct 2004 08:06:44 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Cc: [email-masked]
Sender: [email-masked]

At 05:44 AM 10/29/2004, Simon Josefsson wrote:
>>>  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.
>>
>> What's a local password?
>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 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Fri, 29 Oct 2004 15:05:15 +0200
Lines: 29
Cancel-Lock: sha1:0R0Zq7mtdr69ZaVrKlFMArTGP6I=
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

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

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.
>
> Then this should be sufficient.

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.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Fri, 29 Oct 2004 14:44:48 +0200
Lines: 146
Cancel-Lock: sha1:hwqVxsfayWnFp2Xwp9QIIWXqJbc=
Sender: [email-masked]

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

> At 04:49 PM 10/27/2004, Simon Josefsson wrote:
>>>>What I am looking for is text that say that the PLAIN server code
>>>>should treat the local password as a stored string.
>>> What's a "local password"?
>>I was trying to come up with a descriptive word for it,
>
> 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.

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

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

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

> And are you only applying the term "local" to the password?
> 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.

>>                            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.
>
> Is the stored authentication identity string a local string or
> a query string?

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.

Date: Thu, 28 Oct 2004 20:10:04 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Sender: [email-masked]

On Wednesday, October 27, 2004 11:09:47 -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

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

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.

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

Then this should be sufficient.

-- Jeff

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-04.txt
Date: Thu, 28 Oct 2004 11:12:52 -0400
Sender: [email-masked]

--NextPart

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 CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-04.txt
	Pages		: 10
	Date		: 2004-10-27
	
This document defines a simple challenge-response authentication
mechanism, using a keyed-hash digest, for use with the Simple
Authentication and Security Layer (SASL)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-04.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-crammd5-04.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-crammd5-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-crammd5-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-crammd5-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt
Date: Thu, 28 Oct 2004 11:12:43 -0400
Sender: [email-masked]

--NextPart

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		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2222bis-09.txt
	Pages		: 11
	Date		: 2004-10-27
	
The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-oriented protocols via replaceable mechanisms. It provides
   a structured interface between protocols and mechanisms.  The
   resulting framework allows new protocols to reuse existing mechanisms
   and allows old protocols to make use of new mechanisms.  The
   framework also provides a protocol for securing subsequent protocol
   exchanges within a data security layer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.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-rfc2222bis-09.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-rfc2222bis-09.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2222bis-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 27 Oct 2004 18:16:58 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Cc: [email-masked]
Sender: [email-masked]

At 04:49 PM 10/27/2004, Simon Josefsson wrote:
>>>What I am looking for is text that say that the PLAIN server code
>>>should treat the local password as a stored string.
>> What's a "local password"?
>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
>stored string from the point of view of SASLPrep too, i.e., unassigned
>code points are not allowed.

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.

>>>    The presented strings are to be regarded as "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).
>I think the terminology here is poor.

"local string" is a poor term.

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

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.

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

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

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

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Thu, 28 Oct 2004 01:49:56 +0200
Lines: 172
Cancel-Lock: sha1:mXCHkFFaOa24J2DwNYuf2DzDZGA=
Sender: [email-masked]

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

> At 03:08 PM 10/27/2004, Simon Josefsson wrote:
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> At 11:42 AM 10/27/2004, Simon Josefsson wrote:
>>>
>>>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>>>
>>>>> 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,
>>>>>
>>>>> 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.
>>>>
>>>>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 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 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.
>
>>What I am looking for is text that say that the PLAIN server code
>>should treat the local password as a stored string.
>
> 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.

>>Currently, it
>>seems to me that you and the PLAIN document only assume that the
>>password can only be viewed as a stored string.
>
> The presented string is compared against a stored string
> (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
> 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.

Agreed.

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

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

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

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

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

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.

  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.

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

Date: Wed, 27 Oct 2004 16:23:50 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: Re: CRAMing for last call
Sender: [email-masked]

--On 2004-10-27 5:57 PM -0400 Sam Hartman <[email-masked]> wrote:

>     Simon> Finally, RFC 2104 is INFORMATIONAL.  Can it be a normative
>     Simon> reference?
>
> Yes.  Recently a BCP on dealing with this was published.

Don't Panic!™

Due to a seemingly-imminent disk failure on my laptop, I pushed out a
preliminary version of the draft (as a backup measure more than 
anything).
There will be another rev after the IETF, containing the editorial 
changes
I've previously alluded to. The references will be fixed as part of 
that update.
(And, I hope, the presentation/stored strings issues.)

--lyndon

Date: Wed, 27 Oct 2004 15:50:48 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Cc: [email-masked]
Sender: [email-masked]

At 03:08 PM 10/27/2004, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> At 11:42 AM 10/27/2004, Simon Josefsson wrote:
>>
>>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>>
>>>> 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,
>>>>
>>>> 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.
>>>
>>>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 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 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.

>What I am looking for is text that say that the PLAIN server code
>should treat the local password as a stored string.

What's a "local password"?

>Currently, it
>seems to me that you and the PLAIN document only assume that the
>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
>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.

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

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.

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

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

>> (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?)
>
>I don't recall what the conclusion was of any earlier discussion, if
>any, and I believe the current document should be improved.
>
>>> 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.
>>
>> 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.
>
>To my reading, your explanation describe what I mean.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Thu, 28 Oct 2004 00:08:43 +0200
Lines: 82
Cancel-Lock: sha1:XO4jfXh1J93c9S3+sXyTDxTDUyE=
Sender: [email-masked]

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

> At 11:42 AM 10/27/2004, Simon Josefsson wrote:
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> 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,
>>>
>>> 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.
>>
>>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 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 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.

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

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

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

To my reading, your explanation describe what I mean.

Thanks.

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Summary of 2222bis WGLC
From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 18:04:53 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> 1). "indicate that re-keying is or will be needed
    Alexey> immediately".  The first question I have after reading
    Alexey> this sentence is "how?"  Because SASL framework doesn't
    Alexey> have any control channel or out-of-band mechanism, the
    Alexey> only answer to this question is "by transparently
    Alexey> including re-keying messages in the security layer". But
    Alexey> this is a part of what the subsequent sentence is saying!?

By returning some status to the application or setting a flag.  You
can generally tell you need to re-key without sending anything over
the wire.

--Sam

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: CRAMing for last call
From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:57:39 -0400
Sender: [email-masked]

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

    Simon> Finally, RFC 2104 is INFORMATIONAL.  Can it be a normative
    Simon> reference?

Yes.  Recently a BCP on dealing with this was published.

--Sam

To: [email-masked]
Subject: Sending anonymous and plain to the IESG
Date: Wed, 27 Oct 2004 17:37:54 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Hi.  It's my intent to do an id-nits review on plain and anonymous.
Assuming I see no problems I'll send them to the IESG early next week.
If there are resaons this should not happen please let me know before
then.

--Sam

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:34:29 -0400
Sender: [email-masked]

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

Date: Wed, 27 Oct 2004 12:26:57 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Cc: [email-masked]
Sender: [email-masked]

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

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> 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,
>>
>> 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.
>
>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 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
>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.

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 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Wed, 27 Oct 2004 20:42:10 +0200
Lines: 22
Cancel-Lock: sha1:Ud3K8wx8XSwuABa0BbPTfWwy0Ak=
Sender: [email-masked]

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

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

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.

Date: Wed, 27 Oct 2004 11:09:47 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Cc: [email-masked]
Sender: [email-masked]

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,

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

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Wed, 27 Oct 2004 15:35:45 +0200
Lines: 18
Cancel-Lock: sha1:mIZaNd32vnjtOx2B4CKBn3FDtNA=
Sender: [email-masked]

Philip Guenther <[email-masked]> writes:

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

Oops, what a thinko.  Thanks.

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

Sorry,
Simon

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt 
Date: Wed, 27 Oct 2004 03:08:34 -0700
Sender: [email-masked]

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

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt
Date: Wed, 27 Oct 2004 11:36:50 +0200
Lines: 15
Cancel-Lock: sha1:Jhj0urqIfmtxV2f3w+FxW6epL+k=
Sender: [email-masked]

For what it's worth, I reviewed the document and it looks good to me.

A small nit though.  The following paragraph

  The ANONYMOUS mechanism grants access to services and/or resources by
  anyone.  For this reason it should be disabled by default so the
  administrator can make an explicit decision to enable it.

might imply something that wasn't intended.  It seems some protocols
could be anonymous in nature (think NNTP).  Then it wouldn't make
sense to require administrators to explicitly enable ANONYMOUS.
ANONYMOUS logins to NNTP servers can be meaningful, think of the trace
information provided.

Thanks.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Wed, 27 Oct 2004 11:30:34 +0200
Lines: 23
Cancel-Lock: sha1:v0Tq52Rg8FxsYAYq6YR3k1Vb2UY=
Sender: [email-masked]

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.

Date: Tue, 26 Oct 2004 19:46:42 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-plain-05.txt
Sender: [email-masked]

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

Date: Tue, 26 Oct 2004 19:32:16 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-anon-04.txt
Sender: [email-masked]

In this revision, aside from editorial changes, the following
change was made:
  - The purpose of the mechanism was clarified.

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

Kurt

At 02:04 PM 10/26/2004, [email-masked] wrote:
>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 Anonymous SASL Mechanism
>        Author(s)       : K. Zeilenga
>        Filename        : draft-ietf-sasl-anon-04.txt
>        Pages           : 9
>        Date            : 2004-10-26
>        
>It is common practice on the Internet to permit anonymous access to
>various services.  Traditionally, this has been done with a plain text
>password mechanism using 'anonymous' as the user name and optional
>trace information, such as an email address, as the password.  As
>plaintext login commands are not permitted in new IETF protocols, a
>new way to provide anonymous login is needed within the context of the
>Simple Authentication and Security Layer (SASL) framework.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.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-anon-04.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-anon-04.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-anon-04.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: CRAMing for last call
Date: Wed, 27 Oct 2004 00:55:10 +0200
Lines: 70
Cancel-Lock: sha1:7HnbOMol+wB6oa5kJXxJLx9Ko/E=
Sender: [email-masked]

Hello.  Some comments on the latest cram-md5 draft.

In this post:

http://thread.gmane.org/gmane.ietf.sasl/1457

Kurt suggest to explain why the IANA USAGE field of CRAM-MD5 is
LIMITED.  I too believe this would be useful, to make readers realize
they might want PLAIN+TLS, DIGEST-MD5 or GSSAPI instead.

There are a few (minor, mostly editorial) suggestions in Kurt's post
that has not been addressed, that I believe make sense.

Next, I believe it would be useful to tighten up the language in the
following paragraph:

   The mechanism starts with the server issuing a challenge.  The data
   encoded in the challenge contains a presumptively arbitrary string of
   random data.

I suggest to remove "presumptively arbitrary" and add a reference to
RFC 1750 after the word "random".  Possibly it could be worded
differently, because there is quite some structure in the challenge,
not complete random data.  I read RFC 2104, but it does not say
anything about randomness or structure of the challenge text.  It may
be useful to find some other reference on the properties of challenge
strings in CRAM-MD5, or to ask the CFRG for guidance.

Next, there were discussion regarding SASLprep unassigned code points
in this thread:

http://thread.gmane.org/gmane.ietf.sasl/1342

I agree with Kurt that it should be clarified that the client copy of
the user name and shared secret should be defined as query strings.  I
think this would be achieved by adding after:

   The client MUST prepare the user name and shared secret strings using
   the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep
   [RFC3454] algorithm.

the following:

   The client MUST treat the user name and shared secret string as
   query strings, consequently unassigned code points should be
   allowed in the prepared output.  The server MUST treat the received
   user name, and the password (regardless of whether it is in
   unprepared, prepared or hashed form), as stored strings, and
   consequently disallow unassigned code points in the prepared output
   that is used as input to the keyed hash operation.

Without such text, there is an ambiguity how to invoke SASLPrep.  I
believe the text belong in CRAM-MD5, as string preparation is a
mechanism issue.  It does not seem to belong in SASLPrep or 2222bis.

Further, RFC 2279 has been obsoleted by RFC 3629:

   The resulting values MUST be encoded as UTF-8 [RFC2279] strings.

I suggest adding a paragraph break after the previous sentence, and
the generic recommendations on storing prepared strings.

Next, because CRAM-MD5 do not provide a security layer, it should have
a reference to TLS and some security consideration suggesting TLS, or
similar, if active attacks or privacy issues are a threat.  Compare
PLAIN.

Finally, RFC 2104 is INFORMATIONAL.  Can it be a normative reference?

Thanks.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-05.txt
Date: Tue, 26 Oct 2004 17:04:44 -0400
Sender: [email-masked]

--NextPart

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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-plain-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-plain-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-anon-04.txt
Date: Tue, 26 Oct 2004 17:04:25 -0400
Sender: [email-masked]

--NextPart

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 Anonymous SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-anon-04.txt
	Pages		: 9
	Date		: 2004-10-26
	
It is common practice on the Internet to permit anonymous access to
various services.  Traditionally, this has been done with a plain text
password mechanism using 'anonymous' as the user name and optional
trace information, such as an email address, as the password.  As
plaintext login commands are not permitted in new IETF protocols, a
new way to provide anonymous login is needed within the context of the
Simple Authentication and Security Layer (SASL) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.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-anon-04.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-anon-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-anon-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-anon-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Summary of 2222bis WGLC
From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 15:04:35 -0400
Sender: [email-masked]

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

    Kurt> My view on re-keying is that its just another layer security
    Kurt> service that a mechanism can offer.  In regards to the SASL
    Kurt> framework specification, how it does so (on the wire) is
    Kurt> something for the mechanism specification to detail.  And
    Kurt> how an developer of an application protocol provides support
    Kurt> for this mechanism is an implementation detail.  The
    Kurt> framework simply should not concern itself with such
    Kurt> The design of any SASL API is limited by which mechanism
    Kurt> aspects and protocol aspects which were accounted for in the
    Kurt> design.  If a new mechanism has aspects not previously
    Kurt> considered by designers of a particular SASL API, then the
    Kurt> designers of that SASL API might want to redesign their API
    Kurt> to account for the new aspect... or decide that they simply
    Kurt> cannot support that mechanism (or aspect of that mechanism).

    Kurt> While we could constraint future mechanisms to currently
    Kurt> known aspects, I think that's unwise and counter to
    Kurt> character of SASL.

It's been my experience in other IETF work that it is strongly
desirable for framework documents to enumerate the aspects of
mechanisms of the framework that are generally applicable at the time
the framework document is written.  Doing so is useful to API and
implementation designers.

However I cannot claim today that support for this service (re-keying)
is generally available in today's SASL mechanisms.  So I agree that
this revision of the framework should not concern itself with that
service.

--Sam

Date: Mon, 25 Oct 2004 11:38:12 -0700
To: Nicolas Williams <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Life of a security layer and error handling
Cc: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 10:20 AM 10/25/2004, Nicolas Williams wrote:

>On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote:
>> I don't think there is current WG consensus to support something as
>> strong as a requirement.
>
>Well, yeah, technically it's hard to impose requirements on future
>protocol work :)

And its even harder to impose a particular kind of solution to
a security consideration.  Rekeying is a possible solution to a
security consideration.  It's not the only viable solution to that
security consideration.

The framework specification should elaborate on the security
consideration regarding the life of the layer and leave it to
mechanism designers to determine how to best address these
issues.  It might be okay to suggest the designer consider
particular solutions, but I do not think it appropriate
to recommend a particular solution be used in all future
mechanisms.

Kurt 

Date: Mon, 25 Oct 2004 12:20:37 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
Mail-Followup-To: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

On Mon, Oct 25, 2004 at 12:51:45PM -0400, Sam Hartman wrote:
> I don't think there is current WG consensus to support something as
> strong as a requirement.

Well, yeah, technically it's hard to impose requirements on future
protocol work :)

I must have been hoping that some verbiage to that effect would make it
easier to force the matter later when new mechs/mech revisions come
along.  But I think you're right.

IOW, I will settle for Security Considerations text on this.

> I believe Kurt's summary is consistent with this position.
> 
> I would certainly encourage you to make sure all new SASL mechanisms
> support rekeying; I certainly plan to try and do the same.

Thank you.  I will.

Nico
-- 

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 12:51:45 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman
    Nicolas> wrote:
    >>  I think Nico and some others would argue there is a problem
    >> with the SASL framework: it doesn't support rekeying at the
    >> SASL level.  It clearly could be changed to do so; we as a a
    >> working group have decided not to do so.  I think we made that
    >> decision for a lot of good reasons.

    Nicolas> I agree that existing SASL mechanisms' lack of re-keying
    Nicolas> support should be grandfathered.

    Nicolas> Going forward though I see no good reason not to require
    Nicolas> support for re-keying (or re-key-less ciphers/modes) in
    Nicolas> new/revised SASL mechanisms, that includes the revised
    Nicolas> GSS mechs draft.

I don't think there is current WG consensus to support something as
strong as a requirement.

I believe Kurt's summary is consistent with this position.

I would certainly encourage you to make sure all new SASL mechanisms
support rekeying; I certainly plan to try and do the same.

Date: Mon, 25 Oct 2004 11:19:07 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
Mail-Followup-To: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

On Mon, Oct 25, 2004 at 10:11:51AM -0400, Sam Hartman wrote:
> 
> I think Nico and some others would argue there is a problem with the
> SASL framework: it doesn't support rekeying at the SASL level.  It
> clearly could be changed to do so; we as a a working group have
> decided not to do so.  I think we made that decision for a lot of good
> reasons.

I agree that existing SASL mechanisms' lack of re-keying support should
be grandfathered.

Going forward though I see no good reason not to require support for
re-keying (or re-key-less ciphers/modes) in new/revised SASL mechanisms,
that includes the revised GSS mechs draft.

(If SASL were a new proposal today, would a spec w/o re-keying get past
WG, IETF and IESG reviews?  I rather doubt it.)

> If you want to rework the text, I'd recommend making it be
> fault-agnostic.  Simply describe the effect without trying to claim
> any of the specs involved are broken.

Heh.  But see above.

Nico
-- 

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 10:11:51 -0400
Sender: [email-masked]

I think Nico and some others would argue there is a problem with the
SASL framework: it doesn't support rekeying at the SASL level.  It
clearly could be changed to do so; we as a a working group have
decided not to do so.  I think we made that decision for a lot of good
reasons.

If you want to rework the text, I'd recommend making it be
fault-agnostic.  Simply describe the effect without trying to claim
any of the specs involved are broken.

Date: Mon, 25 Oct 2004 14:37:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
Sender: [email-masked]

Sam Hartman wrote:

>    Alexey> Imagine that support for re-keying can be done without
>    Alexey> changing (extending) GSS API. 
>
>I did.  Unfortunately, Nico convinced me that my fantasy had no basis
>in reality.  You cannot guarantee that both parties are sending, which
>is required for rekeying.  ALso, you have bad interactions with
>gss_wrap_size_limit.
>  
>
Then we need to update the SASL GSSAPI document (suggestions are welcome).

>    Alexey> In this case the SASL GSSAPI
>    Alexey> spec doesn't have to be updated.  In which case the
>    Alexey> following text can be removed from 2222bis:
>
>    Alexey> In practice one likely effect of administrative security
>    Alexey> layers lifetime limits is that applications may find that
>    Alexey> security layers stop working in the middle of application
>    Alexey> protocol operation, such as, perhaps, during large data
>    Alexey> transfers.
>
>I agree that implementations that work this way are broken.  Nico does
>not.  Nor does the IETF; RFC 1964 mandates this behavior.
>  
>
The paragraph as written may suggest that there is a problem with SASL 
framework, when there is none. The text has to be rewritten to clarify that.

Alexey

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:24:47 -0400
Sender: [email-masked]

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

    Kurt> But, without that qualification, I would have to disagree.
    Kurt> For instance, an application protocol can certainly detail
    Kurt> how authentication identities are to represented in
    Kurt> identity-assumption policy information carried by the
    Kurt> protocol, and associated semantics.
    >>  I agree that they can do so in the sense that if the IESG
    >> approved it, it would be a protocol action.

    Kurt> LDAP and IMAP ACLs.

    Kurt> What's good is a standardize access control policy if the
    Kurt> standard does say how identities used in the authentication
    Kurt> exchange relate to identities appearing in the policy?

    Kurt> Say an administrative client has created a Kerberos
    Kurt> principal for a user and then wants to authorize that user
    Kurt> to access an object on an LDAP server.  What DN should the
    Kurt> administrative client use as the subject of the LDAP access
    Kurt> control statement?

I was thinking too narrowly.

--Sam

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 09:21:01 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Sam Hartman wrote:
    Nicolas> Should existing mechanisms' layers expire when the
    Nicolas> session key material's useful lifetime (in terms of time
    Nicolas> or use) is exceeded?
    >>  I believe that SASL mechanisms should try to avoid expiring
    >> the connection when key lifetime is exceeded because doing so
    >> creates an unacceptable user experience.
    >> 
    Alexey> I concur.

    >> There exist mechanisms that will expire though like some
    >> implementations of the GSSAPI mechanism.
    >> 
    >> 
    Alexey> Are we talking about GSSAPI in general or a particular
    Alexey> implementation of GSSAPI?

We're talking about RFC 1964 and most implementations of that spec.

    Alexey> Imagine that support for re-keying can be done without
    Alexey> changing (extending) GSS API. 

I did.  Unfortunately, Nico convinced me that my fantasy had no basis
in reality.  You cannot guarantee that both parties are sending, which
is required for rekeying.  ALso, you have bad interactions with
gss_wrap_size_limit.

    Alexey> In this case the SASL GSSAPI
    Alexey> spec doesn't have to be updated.  In which case the
    Alexey> following text can be removed from 2222bis:

    Alexey> In practice one likely effect of administrative security
    Alexey> layers lifetime limits is that applications may find that
    Alexey> security layers stop working in the middle of application
    Alexey> protocol operation, such as, perhaps, during large data
    Alexey> transfers.

I agree that implementations that work this way are broken.  Nico does
not.  Nor does the IETF; RFC 1964 mandates this behavior.

--Sam

Date: Mon, 25 Oct 2004 12:17:55 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>>For comparison, here is part of the old text:
>>
>>  Any normalization of the authentication identity is defined by a
>>  particular SASL mechanism, the protocol profile doesn't influence it.
>>    
>>
>
>Though I think this needs to be slightly reworded, I agree
>with the intent of the statement to say that protocol
>profiles should leave of aspects of credentials and their
>verification to the mechanism.  However, this in no way
>implies that an application protocol specification, or
>its implementations, cannot detail the form of authentication
>identity the application protocol (or implementation) might
>use otherwise.  For instance, an application protocol
>specification could detail how to represent authentication
>identities in an identity assumption authorization policy.
>  
>
I've updated the existing sentence as follows (I am still not satisfied 
with how it looks):

Any normalization of the authentication identity (for the purposes
of conducting authentication exchange) is defined by a particular
SASL mechanism, the protocol profile doesn't influence it.
Note, that the mechanism specification doesn't control how
authentication identity information is represented elsewhere.

I think we need to expand on "elsewhere" part.

Date: Mon, 25 Oct 2004 11:39:18 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re-keying (was Re: Life of a security layer and error handling)
Sender: [email-masked]

Alexey Melnikov wrote:

> Sam Hartman wrote:
>
>>    Nicolas> Should
>>    Nicolas> existing mechanisms' layers expire when the session key
>>    Nicolas> material's useful lifetime (in terms of time or use) is
>>    Nicolas> exceeded?
>>
>> I believe that SASL mechanisms should try to avoid expiring the
>> connection when key lifetime is exceeded because doing so creates an
>> unacceptable user experience.
>
> I concur.
>
>>  There exist mechanisms that will expire
>> though like some implementations of the GSSAPI mechanism.
>
> Are we talking about GSSAPI in general or a particular implementation 
> of GSSAPI?
>
> Imagine that support for re-keying can be done without changing 
> (extending) GSS API. In this case the SASL GSSAPI spec doesn't have to 
> be updated.
> In which case the following text can be removed from 2222bis:
>
> In practice one likely effect of administrative security layers
> lifetime limits is that applications may find that security layers
> stop working in the middle of application protocol operation, such
> as, perhaps, during large data transfers.
>
> ?
> (or at least it has to be reworded to talk about "broken" or "old" 
> implementations)

I've kept the paragraph for now, here is the latest text about re-keying 
in Security considerations (as there is very little time before the 
draft submission deadline, I am going to send the updated 2222bis now):

The secure or administratively permitted lifetimes of SASL
mechanisms' security layers are finite.  Cryptographic keys weaken as
they are used and as time passes; the more time and/or ciphertext
that a cryptanalyst has after the first use of the a key, the easier
it is for the cryptanalyst to mount attacks on the key.

Administrative limits on security layers lifetime may take the form
of time limits expressed in x.509 certificates, Kerberos V tickets,
or in directories, and are often desired.
In practice one likely effect of administrative security layers
lifetime limits is that applications may find that security layers
stop working in the middle of application protocol operation, such
as, perhaps, during large data transfers.  As the result of this
the connection will be closed (see section 3.3), which will result
in unpleasant user experience.

Re-keying (key renegotiation process) is a way of addressing
the weakening of cryptographic keys. SASL framework does not provide
for re-keying.  SASL mechanisms may; all future SASL mechanisms that
provide security layers should provide for re-keying.

Applications that wish to re-key SASL security layers where the
mechanism does not provide for re-keying should reauthenticate the
same IDs and replace the expired or soon-to-expire security layers.
This approach requires support for re-keying in the application
protocols.  See section 6.3.

Alexey

Date: Mon, 25 Oct 2004 11:26:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
Sender: [email-masked]

Sam Hartman wrote:

>    Nicolas> Should
>    Nicolas> existing mechanisms' layers expire when the session key
>    Nicolas> material's useful lifetime (in terms of time or use) is
>    Nicolas> exceeded?
>
>I believe that SASL mechanisms should try to avoid expiring the
>connection when key lifetime is exceeded because doing so creates an
>unacceptable user experience.
>
I concur.

>  There exist mechanisms that will expire
>though like some implementations of the GSSAPI mechanism.
>  
>
Are we talking about GSSAPI in general or a particular implementation of 
GSSAPI?

Imagine that support for re-keying can be done without changing 
(extending) GSS API. In this case the SASL GSSAPI spec doesn't have to 
be updated.
In which case the following text can be removed from 2222bis:

In practice one likely effect of administrative security layers
lifetime limits is that applications may find that security layers
stop working in the middle of application protocol operation, such
as, perhaps, during large data transfers.

?
(or at least it has to be reworded to talk about "broken" or "old" 
implementations)

Alexey

Date: Sun, 24 Oct 2004 19:40:18 -0700
To: Nicolas Williams <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Summary of 2222bis WGLC
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

My view on re-keying is that its just another layer security
service that a mechanism can offer.  In regards to the
SASL framework specification, how it does so (on the
wire) is something for the mechanism specification to detail.
And how an developer of an application protocol provides
support for this mechanism is an implementation detail.
The framework simply should not concern itself with such
details.

The design of any SASL API is limited by which mechanism
aspects and protocol aspects which were accounted for in
the design.  If a new mechanism has aspects not previously
considered by designers of a particular SASL API, then
the designers of that SASL API might want to redesign
their API to account for the new aspect... or decide
that they simply cannot support that mechanism (or
aspect of that mechanism).

While we could constraint future mechanisms to currently
known aspects, I think that's unwise and counter to
character of SASL.

At 02:17 PM 10/24/2004, Nicolas Williams wrote:

>On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote:
>> 
>> Kurt D. Zeilenga wrote:
>> 
>> >1) Re-keying of security layers 
>> >
>> >Nico indicated that the I-D did not discuss Re-keying of
>> >security layers and suggested text in this area be added.
>> >The WG discussed a number of specific suggestions in this
>> >area, with the following text being the last version
>> >submitted for WG consideration:
>> >   SASL mechanisms that support re-keying SHOULD:
>> >   - indicate that re-keying is or will be needed immediately;
>> >   - provide re-keying messages or transparently include re-keying
>> >     messages in the security layers; the latter can happen without
>> >     application involvement, but only as long as the application is
>> >     engaged in timely bidirectional exchanges with its peer.
>> >
>> After rereading this text multiple times it is clear to me that either 
>> the text is [partially] redundant, or I don't understand what it is 
>> trying to say (or maybe both).
>> 
>> 1). "indicate that re-keying is or will be needed immediately".
>> The first question I have after reading this sentence is "how?" Because 
>> SASL framework doesn't have any control channel or out-of-band 
>> mechanism, the only answer to this question is "by transparently 
>> including re-keying messages in the security layer". But this is a part 
>> of what the subsequent sentence is saying!?
>
>See below.
>
>> 2). "provide re-keying messages or transparently include re-keying 
>> messages in the security layers;"
>> 
>> I think this sentence specifies requirements on SASL APIs and I am not 
>> sure whether RFC2222bis is the proper place for that.
>
>The answer is: by providing interfaces for the purpose of indicating key
>layer expiration and providing for re-key message exchanges (where mechs
>support it).  Layer expiration, for existing mechs, should be advisory
>only; for new mechs I think we should insist that it be mandatory.
>
>Whether you like it or not it is possible to derive an abstract API from
>a protocol specification, at least a sufficiently complete and
>unambiguous spec :)
>
>IMO abstract API requirements/recommendations are more than Ok to
>include in rfc2222bis.  The key word there is "abstract."
>
>> I also assume that "provide re-keying messages" is not the same thing as 
>> "transparently include re-keying messages in the security layers".
>
>Correct.  I'm not sure that any existing mechs could do either, but new
>mechs should definitely provide for the former.
>
>> I think the former is trying to say that the SASL API should be able to 
>> signal to the application that rekeying is (or will be shortly) needed, 
>> once a rekeying message is received. It also tries to say that the 
>> application should be able to say to SASL API: "send rekeying request now".
>
>Yes.
>
>> The latter is trying to say that the SASL API doesn't have to expose 
>> re-keying messages to the application, it should generate/process them 
>> automatically.
>
>Yes.  This approach is less than ideal.  IIRC Sam favors it, at least in
>that it may be workable in some cases that we care about.
>
>Cheers,
>
>Nico
>-- 

Date: Sun, 24 Oct 2004 19:16:13 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:13 PM 10/24/2004, Sam Hartman wrote:

>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote:
>    >> The syntax and semantics of authentication ID's are determined
>    >> entirely by the authentication mechanism;
>
>    Kurt> If you were to say the syntax and semantics of any
>    Kurt> authentication identity information carried in the exchange
>    Kurt> is specified by the mechanism's specification, I would
>    Kurt> agree.
>
>    Kurt> But, without that qualification, I would have to disagree.
>    Kurt> For instance, an application protocol can certainly detail
>    Kurt> how authentication identities are to represented in
>    Kurt> identity-assumption policy information carried by the
>    Kurt> protocol, and associated semantics.
>
>I agree that they can do so in the sense that if the IESG approved it,
>it would be a protocol action.

LDAP and IMAP ACLs.

What's good is a standardize access control policy if
the standard does say how identities used in the
authentication exchange relate to identities appearing
in the policy?

Say an administrative client has created a Kerberos
principal for a user and then wants to authorize that
user to access an object on an LDAP server.  What DN
should the administrative client use as the subject
of the LDAP access control statement?

Without a standard of some kind here, it is not possible
to independently develop such a client.

>Application protocols should not say
>anything about authentication identities though, because doing so
>would tie them to a particular mechanism.

No, it would require an update of the application protocol
specification to state how to manage identities associated
with that particular mechanism relate to identities in
the application protocol.  (This doesn't mean that one
cannot use new mechanisms in the protocol in absence of
this update, it says that one cannot use certain policy
features of that mechanism until its updated to deal
with the new mechanism.)

Kurt 

Date: Sun, 24 Oct 2004 20:10:53 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Oct 24, 2004 at 04:17:34PM -0500, Nicolas Williams wrote:
> The answer is: by providing interfaces for the purpose of indicating key
> layer expiration and providing for re-key message exchanges (where mechs
> support it).  Layer expiration, for existing mechs, should be advisory
> only; for new mechs I think we should insist that it be mandatory.

And, of course, the GSS-API does not provide [yet] for advisory security
context expiration, so neither can SASL GSS mechanisms [yet].

It'd be a shame to add advisory security context expiration to the
GSS-APIv3 work at KITTEN just for SASL, but perhaps we should.

Also, there is a mitigation for this problem: use ciphers that don't
require re-keying :)  (I'm thinking AES-256 in some counter mode).

Nico
-- 

To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:21:17 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Where does this leave us w.r.t. re-keying?  Will it be
    Nicolas> possible for future mechanisms or extensions to existing
    Nicolas> ones to provide for something better than this?  

Yes.  If you believe the text does not support future work in this
direction please describe.

    Nicolas> Should
    Nicolas> existing mechanisms' layers expire when the session key
    Nicolas> material's useful lifetime (in terms of time or use) is
    Nicolas> exceeded?

I believe that SASL mechanisms should try to avoid expiring the
connection when key lifetime is exceeded because doing so creates an
unacceptable user experience.  There exist mechanisms that will expire
though like some implementations of the GSSAPI mechanism.

Date: Sun, 24 Oct 2004 16:17:34 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Oct 23, 2004 at 08:39:16PM +0100, Alexey Melnikov wrote:
> 
> Kurt D. Zeilenga wrote:
> 
> >1) Re-keying of security layers 
> >
> >Nico indicated that the I-D did not discuss Re-keying of
> >security layers and suggested text in this area be added.
> >The WG discussed a number of specific suggestions in this
> >area, with the following text being the last version
> >submitted for WG consideration:
> >   SASL mechanisms that support re-keying SHOULD:
> >   - indicate that re-keying is or will be needed immediately;
> >   - provide re-keying messages or transparently include re-keying
> >     messages in the security layers; the latter can happen without
> >     application involvement, but only as long as the application is
> >     engaged in timely bidirectional exchanges with its peer.
> >
> After rereading this text multiple times it is clear to me that either 
> the text is [partially] redundant, or I don't understand what it is 
> trying to say (or maybe both).
> 
> 1). "indicate that re-keying is or will be needed immediately".
> The first question I have after reading this sentence is "how?" Because 
> SASL framework doesn't have any control channel or out-of-band 
> mechanism, the only answer to this question is "by transparently 
> including re-keying messages in the security layer". But this is a part 
> of what the subsequent sentence is saying!?

See below.

> 2). "provide re-keying messages or transparently include re-keying 
> messages in the security layers;"
> 
> I think this sentence specifies requirements on SASL APIs and I am not 
> sure whether RFC2222bis is the proper place for that.

The answer is: by providing interfaces for the purpose of indicating key
layer expiration and providing for re-key message exchanges (where mechs
support it).  Layer expiration, for existing mechs, should be advisory
only; for new mechs I think we should insist that it be mandatory.

Whether you like it or not it is possible to derive an abstract API from
a protocol specification, at least a sufficiently complete and
unambiguous spec :)

IMO abstract API requirements/recommendations are more than Ok to
include in rfc2222bis.  The key word there is "abstract."

> I also assume that "provide re-keying messages" is not the same thing as 
> "transparently include re-keying messages in the security layers".

Correct.  I'm not sure that any existing mechs could do either, but new
mechs should definitely provide for the former.

> I think the former is trying to say that the SASL API should be able to 
> signal to the application that rekeying is (or will be shortly) needed, 
> once a rekeying message is received. It also tries to say that the 
> application should be able to say to SASL API: "send rekeying request now".

Yes.

> The latter is trying to say that the SASL API doesn't have to expose 
> re-keying messages to the application, it should generate/process them 
> automatically.

Yes.  This approach is less than ideal.  IIRC Sam favors it, at least in
that it may be workable in some cases that we care about.

Cheers,

Nico
-- 

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:13:15 -0400
Sender: [email-masked]

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

    Kurt> At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote:
    >> The syntax and semantics of authentication ID's are determined
    >> entirely by the authentication mechanism;

    Kurt> If you were to say the syntax and semantics of any
    Kurt> authentication identity information carried in the exchange
    Kurt> is specified by the mechanism's specification, I would
    Kurt> agree.

    Kurt> But, without that qualification, I would have to disagree.
    Kurt> For instance, an application protocol can certainly detail
    Kurt> how authentication identities are to represented in
    Kurt> identity-assumption policy information carried by the
    Kurt> protocol, and associated semantics.

I agree that they can do so in the sense that if the IESG approved it,
it would be a protocol action.  Application protocols should not say
anything about authentication identities though, because doing so
would tie them to a particular mechanism.

Date: Sun, 24 Oct 2004 16:09:24 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Sam Hartman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling         (was Re: Summary of 2222bis WGLC)
Mail-Followup-To: Alexey Melnikov <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Sam Hartman <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Where does this leave us w.r.t. re-keying?  Will it be possible for
future mechanisms or extensions to existing ones to provide for
something better than this?  Should existing mechanisms' layers expire
when the session key material's useful lifetime (in terms of time or
use) is exceeded?

IMO, SASL must at least point out the key expiration problem and should
allow for future mechs/extensions that provide for re-keying.

Nico
-- 

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Making forward progress
From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 17:03:03 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:

    >> I've seen no objections to Kurt's new summary of the identities
    >> issue nor to his proposed text for section 3.

    Simon> I raised some issues with the new summary in:

    Simon> http://thread.gmane.org/gmane.ietf.sasl/1687

Sorry I was not clear on this.  I believed you and Kurt were agreeing
with each othe; I still believe that is true after reading the
exchange again.

--Sam

To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Life of a security layer and error handling
From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 12:16:19 -0400
Sender: [email-masked]

OK.  My interpretation of the third paragraph was that it was saying
that a layer might force a connection close.

Date: Sat, 23 Oct 2004 22:20:03 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Sam Hartman <[email-masked]>, SASL WG <[email-masked]>
Subject: Life of a security layer and error handling  (was Re: Summary of 2222bis WGLC)
Sender: [email-masked]

[I am CCing my reply to the mailing list as discuss. I believe I've
quoted enough context.]

Kurt D. Zeilenga wrote:

>>   >>> 2). The following text is in the Security Considerations
>>   >>> section (as per off the list discussion with Nico):
>>   >>> 
>>   >>> The secure or administratively permitted lifetimes of SASL
>>   >>> mechanisms' security layers are finite.  Cryptographic keys
>>   >>> weaken as they are used and as time passes; the more time
>>   >>> and/or ciphertext that a cryptanalyst has after the first use
>>   >>> of the a key, the easier it is for the cryptanalyst to mount
>>   >>> attacks on the key.
>>   >>> 
>>   >>> Administrative limits on security layers lifetime may take the
>>   >>> form of time limits expressed in x.509 certificates, Kerberos
>>   >>> V tickets, or in directories, and are often desired.
>>   >>> 
>>   >>> In practice one likely effect of administrative security
>>   >>> layers lifetime limits is that applications may find that
>>   >>> security layers stop working in the middle of application
>>   >>> protocol operation, such as, perhaps, during large data
>>   >>> transfers.
>>   >>> 
>>   >>> SASL does not provide for re-keying.  SASL mechanisms may; all
>>   >>> future SASL mechanisms that provide security layers SHOULD
>>   >>> provide for re-keying.
>>   >>> 
>>   >>  See above comments regarding this recommendation.
>>   >> 
>>   Alexey> You have to be more specific than that. I think the first
>>   Alexey> paragraph should stay, as it explains why rekeying is
>>   Alexey> needed. It should probably be reworded to state this
>>   Alexey> explicitly.  I think the second paragraph should stay as
>>   Alexey> well, although I am not so sure.  The third paragraph
>>   Alexey> should be dropped. The last paragraph should stay,
>>   Alexey> although it will have to be reworded (and maybe drop
>>   Alexey> SHOULD?).
>>
>>What's wrong with the third paragraph?  It does tell you the
>>application writer that life may be annoying, but I believe that is a
>>practical statement of reality.    
>>
>
>A problem I see with the third paragraph is that it attempts to
>redefine the lifetime of the layer.  A layers life lasts until
>either a) a new layer is installed or b) the connection closes.
>There no way that a layer's life can end otherwise.  If the
>mechanism is no longer able to generate buffers, the connection
>must be closed.  It is impossible to re-key or to install a new
>layer without generating buffers to accomplish that re-keying
>or installation.
>
>This should be made clear in the document.

I agree.

Section 3.3 had the following sentence:

If use of a security layer is negotiated by the authentication
protocol exchange, the security layer is applied to all subsequent
data sent over the connection (until another security layer is negotiated (
see also section 6.3)).

I've added "or underlying connection is closed" to the text in the
parentheses.

>>I hope to convince mechanism designers/implementers not to have mechanisms fail mid transfer, but some mechanisms today do fail that way.    
>>
>
>SASL doesn't allow anything else.  If the mechanism is not
>able to produce a buffer, the connection must be closed.
>That can happen anywhere within the application protocol
>stream.
>
>This should be made clear as well.  If the mechanism layer
>failure results in termination of the connection.  While at
>the protocol and SASL layers, that termination is abrupt,
>implementations should attempt to gracefully close lower
>level layers (such as TLS and TCP).
>
Agreed.

I've changed the existing text in 3.3:

   Once the security layer is in effect the protocol stream is processed
   by the security layer into buffers of protected data.  Each buffer of
   protected data is transferred over the connection as a stream of
   octets prepended with a four octet field in network byte order that
   represents the length of the following buffer.

To:
  Once the security layer is in effect the
  protocol stream is processed by the security layer into buffers of
  protected data.  If the security layer is not able to produce a buffer,
  the connection MUST be closed. If the security layer is not able to
  decode a received buffer, the connection MUST be closed.  In both
cases the
  underlying connection SHOULD be closed gracefully.

(Inserted 3 sentences here and broke the paragraph into 2).

  Each buffer of protected data is
  transferred over the connection as a stream of octets prepended with a
  four octet field in network byte order that represents the length of
  the buffer. ...

(I've dropped the word "following" in the last sentence.)

Alexey

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Making forward progress
Date: Sun, 24 Oct 2004 15:18:22 +0200
Lines: 41
Cancel-Lock: sha1:JfSljjmgLX14oVcphSilJMk1kXg=
Sender: [email-masked]

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

> At 04:24 PM 10/23/2004, Simon Josefsson wrote:
>
>>Sam Hartman <[email-masked]> writes:
>>
>>> I've seen no objections to Kurt's new summary of the identities issue
>>> nor to his proposed text for section 3.
>>
>>I raised some issues with the new summary in:
>>
>>http://thread.gmane.org/gmane.ietf.sasl/1687
>>
>>There were additional discussion, even some disagreement on (what I
>>perceive as) terminology issues.  I proposed a change to the proposed
>>new text, to which Kurt acknowledged that his proposed text was not a
>>direct replacement, and that further work was needed.  Has there been
>>a more recent proposal?  I cannot seem to find it.
>>
>>> I think we should move forward with that change.
>>
>>For the record, I again object to removing the paragraphs below, at
>>this late stage.  Kurt's new summary appear, to me, to propose to
>>remove them.
>
> I believe I posted a clarification that it was not my intent
> to suggest these statements be removed.  At the time I
> submitted the suggested text, I presumed they would placed
> elsewhere in the specification.
>
> At this time, I think the majority of my "identity concept"
> text should be placed in an introductory section.
>
> Additionally, these statements need some clarification
> (as I indicated in follow-ups).

Thanks.  I was confused by the resolution to move forward with a
change that had not yet been fleshed out.

Regards,
Simon

Date: Sat, 23 Oct 2004 17:23:05 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Making forward progress
Cc: [email-masked]
Sender: [email-masked]

At 04:24 PM 10/23/2004, Simon Josefsson wrote:

>Sam Hartman <[email-masked]> writes:
>
>> I've seen no objections to Kurt's new summary of the identities issue
>> nor to his proposed text for section 3.
>
>I raised some issues with the new summary in:
>
>http://thread.gmane.org/gmane.ietf.sasl/1687
>
>There were additional discussion, even some disagreement on (what I
>perceive as) terminology issues.  I proposed a change to the proposed
>new text, to which Kurt acknowledged that his proposed text was not a
>direct replacement, and that further work was needed.  Has there been
>a more recent proposal?  I cannot seem to find it.
>
>> I think we should move forward with that change.
>
>For the record, I again object to removing the paragraphs below, at
>this late stage.  Kurt's new summary appear, to me, to propose to
>remove them.

I believe I posted a clarification that it was not my intent
to suggest these statements be removed.  At the time I
submitted the suggested text, I presumed they would placed
elsewhere in the specification.

At this time, I think the majority of my "identity concept"
text should be placed in an introductory section.

Additionally, these statements need some clarification
(as I indicated in follow-ups).

>The paragraphs could be reworded for clarity, as they
>are critical in getting the boundaries between normalization
>procedures in an implementation.  But I have yet to see any argument
>to why they are technically wrong, and should be removed.

Because I don't believe anyone has argued that they should be removed.

>   Any normalization of the authentication identity is defined by a
>   particular SASL mechanism, the protocol profile doesn't influence it.

This statement needs to be clarified.  In particular,
the intent here is that the mechanism specification is
solely responsible for stating how any authentication
identity information is transferred as part of the exchange.

However, the mechanism specification does not necessarily
have any responsibility for stating how authentication
identity information is represented elsewhere.

For instance, an application protocol specification is
free to define how authentication identities appearing
in an identity-assumption policy statement are to
be normalized.

>   The mechanism MUST preserve Unicode codepoint when transferring
>   authorization identity (e.g. the mechanism cann't apply any form of
>   normalization).
>
>Thanks,
>Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Making forward progress
Date: Sun, 24 Oct 2004 01:24:22 +0200
Lines: 33
Cancel-Lock: sha1:ignQ0G4Dj5sxyEDyi7FGWkbOcpg=
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> I've seen no objections to Kurt's new summary of the identities issue
> nor to his proposed text for section 3.

I raised some issues with the new summary in:

http://thread.gmane.org/gmane.ietf.sasl/1687

There were additional discussion, even some disagreement on (what I
perceive as) terminology issues.  I proposed a change to the proposed
new text, to which Kurt acknowledged that his proposed text was not a
direct replacement, and that further work was needed.  Has there been
a more recent proposal?  I cannot seem to find it.

> I think we should move forward with that change.

For the record, I again object to removing the paragraphs below, at
this late stage.  Kurt's new summary appear, to me, to propose to
remove them.  The paragraphs could be reworded for clarity, as they
are critical in getting the boundaries between normalization
procedures in an implementation.  But I have yet to see any argument
to why they are technically wrong, and should be removed.

   Any normalization of the authentication identity is defined by a
   particular SASL mechanism, the protocol profile doesn't influence it.

   The mechanism MUST preserve Unicode codepoint when transferring
   authorization identity (e.g. the mechanism cann't apply any form of
   normalization).

Thanks,
Simon

Date: Sat, 23 Oct 2004 21:05:25 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Sender: [email-masked]

Alexey Melnikov wrote:

> Kurt D. Zeilenga wrote:
>
>> 1) Re-keying of security layers
>> Nico indicated that the I-D did not discuss Re-keying of
>> security layers and suggested text in this area be added.
>> The WG discussed a number of specific suggestions in this
>> area, with the following text being the last version
>> submitted for WG consideration:
>>    SASL mechanisms that support re-keying SHOULD:
>>    - indicate that re-keying is or will be needed immediately;
>>    - provide re-keying messages or transparently include re-keying
>>      messages in the security layers; the latter can happen without
>>      application involvement, but only as long as the application is
>>      engaged in timely bidirectional exchanges with its peer.
>
> After rereading this text multiple times it is clear to me that either 
> the text is [partially] redundant, or I don't understand what it is 
> trying to say (or maybe both).
>
> 1). "indicate that re-keying is or will be needed immediately".
> The first question I have after reading this sentence is "how?" 
> Because SASL framework doesn't have any control channel or out-of-band 
> mechanism, the only answer to this question is "by transparently 
> including re-keying messages in the security layer". But this is a 
> part of what the subsequent sentence is saying!?
>
> 2). "provide re-keying messages or transparently include re-keying 
> messages in the security layers;"
>
> I think this sentence specifies requirements on SASL APIs and I am not 
> sure whether RFC2222bis is the proper place for that.
>
> I also assume that "provide re-keying messages" is not the same thing 
> as "transparently include re-keying messages in the security layers".
> I think the former is trying to say that the SASL API should be able 
> to signal to the application that rekeying is (or will be shortly) 
> needed, once a rekeying message is received. It also tries to say that 
> the application should be able to say to SASL API: "send rekeying 
> request now".
>
> The latter is trying to say that the SASL API doesn't have to expose 
> re-keying messages to the application, it should generate/process them 
> automatically.

Having said that, here is a draft variant of the text I propose:

A SASL mechanism supports re-keying if it is able to generate/process 
messages that request immediate re-keying and it is able to carry out 
re-keying exchange.
(a single message that does both is Ok) SASL mechanisms that support 
re-keying MAY also be able to indicate that re-keying will be needed in 
the future.
A re-keying exchange can be conducted transparently by the mechanism, or 
the mechanism should be able to provide/accept re-keying messages 
to/from the application. The former can happen without application 
involvement, but only as long as the application is engaged in timely 
bidirectional exchanges with its peer.

Date: Sat, 23 Oct 2004 20:39:16 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>1) Re-keying of security layers 
>
>Nico indicated that the I-D did not discuss Re-keying of
>security layers and suggested text in this area be added.
>The WG discussed a number of specific suggestions in this
>area, with the following text being the last version
>submitted for WG consideration:
>    SASL mechanisms that support re-keying SHOULD:
>    - indicate that re-keying is or will be needed immediately;
>    - provide re-keying messages or transparently include re-keying
>      messages in the security layers; the latter can happen without
>      application involvement, but only as long as the application is
>      engaged in timely bidirectional exchanges with its peer.
>
After rereading this text multiple times it is clear to me that either 
the text is [partially] redundant, or I don't understand what it is 
trying to say (or maybe both).

1). "indicate that re-keying is or will be needed immediately".
The first question I have after reading this sentence is "how?" Because 
SASL framework doesn't have any control channel or out-of-band 
mechanism, the only answer to this question is "by transparently 
including re-keying messages in the security layer". But this is a part 
of what the subsequent sentence is saying!?

2). "provide re-keying messages or transparently include re-keying 
messages in the security layers;"

I think this sentence specifies requirements on SASL APIs and I am not 
sure whether RFC2222bis is the proper place for that.

I also assume that "provide re-keying messages" is not the same thing as 
"transparently include re-keying messages in the security layers".
I think the former is trying to say that the SASL API should be able to 
signal to the application that rekeying is (or will be shortly) needed, 
once a rekeying message is received. It also tries to say that the 
application should be able to say to SASL API: "send rekeying request now".

The latter is trying to say that the SASL API doesn't have to expose 
re-keying messages to the application, it should generate/process them 
automatically.

>The chairs believes the WG supports addition of this text.
>
>  
>

Date: Sat, 23 Oct 2004 19:27:39 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>>[nothing in the abstract says that's the kind of mechanisms it is
>>talking about.]    
>>
>
>Mechanisms provide authentication and data security services
>to connection-oriented protocols through the SASL framework.
>
IMHO, this just follows from:

The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms.

So I think nothing has to be added/changed.

>>The same change would be nice in the Introduction section, though of
>>course the diagram there helps.
>>
>>Personally I would also have found an asymmetric definition easier to
>>relate to: SASL defines a common interface to authentication mechanisms
>>for protocols.  (Is that the right way to put it?)  But maybe that's not
>>at all the view SASL intends to convey.  Is the protocol profile the
>>common interface to protocols for authentication mechanisms?
>>    
>>
>
>The "protocol profile" is the part of the protocol's
>technical specification which details how it makes use
>of the SASL framework.
>  
>
The Introduction section currently have the following paragraph:

To use SASL, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions.  If the use
of a security layer is negotiated, that security layer is inserted
between the protocol and the connection.  Section 4 ("Protocol profile
requirements") profiles the requirements that a protocol specification
must fulfill to make use of SASL.

I've added the following sentence to the end:

A SASL protocol profile is a part of the protocol specification that 
satisfies the requirements of Section 4.

Comments?

Alexey

Date: Sat, 23 Oct 2004 19:13:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
Sender: [email-masked]

Jeffrey Hutzelman wrote:

>>>> s/user('s)/authentication identity('s)/.
>>>
>>> Since authentication identity is defined here as
>>> being the identity associated the credentials, would
>>> be effective saying:
>>>         s/user's credentials/credentials of the identity
>>>         associated with the credentials/
>>
>> Well, I'd still like to get rid of that 'user'.  'User' is used
>> elsewhere as merely one kind of identity.
>> Maybe s/user's credentials/presented credentials/,
>> or s/users's credentials/credentials/, s/user/authentication identity/?
>
> s/user/client/  and be done with it.

I've done the change.

Date: Fri, 22 Oct 2004 16:56:52 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
Sender: [email-masked]

On Friday, October 22, 2004 14:29:44 +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> The syntax and semantics of authentication ID's are determined
>> entirely by the authentication mechanism; the protocol has no say in
>> the matter.  All mechanisms are protocol-independent, and all protocol
>> profiles are mechanism-independent.
>>
>> A particular _implementation_ must be able to perform the
>> authorization check (can this authid use the requested autzid) and
>> must be able to derive an authorization ID from an authentication ID.
>> These operations depend on both the mechanism and protocol profile in
>> use, and their details are deliberately left to the implementation and
>> to local policy.
>
> Do I need to change anything in the document?

I'll answer a narrower question...
I'm not proposing any change to the document in relation to this item.
I was simply trying to clarify what looked like a point of confusion in
the ongoing discussion.

-- Jeff

Date: Fri, 22 Oct 2004 15:55:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: EXTERNAL description
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:  
>
>>Hallvard B Furuseth wrote:    
>>
>>>>7.    The EXTERNAL mechanism    
>>>>        
>>>>
>>>   The server uses information external to SASL to determine the
>>>   authentication identity and whether the authentication is to
>>>   succeed.
>>>      
>>>
>>Although this implies the same thing (if you take into consideration 
>>implied authorization step), I would prefer the original text.
>>    
>>
>
>[...]
>
>If I mix your text and mine a bit, does this cover all bases?
>
>  Some system external to SASL must authenticate the client.  If that
>  succeeds, the server determines the authentication identity from
>  information from this system.  If the requested authorization identity
>  is empty, the authorization identity is derived from the
>  authentication identity.  The server determines if the authentication
>  identity is allowed to act as the authorization identity.  Finally, it
>  indicates completion or failure of the authentication exchange.
>
>Or replace the last sentence with
>
>  If all that succeeds, the server indicates successful completion of
>  the authentication exchange; otherwise it indicates failure.
>
That would work for me.

>
> Sigh.  And this started with trying to make the text _shorter_:-)
>
It usually does :-).

Date: Fri, 22 Oct 2004 14:29:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
Sender: [email-masked]

Jeffrey Hutzelman wrote:

>> Well, what I wanted to address was what I mentioned in my original 
>> review:
>>
>>   >  Any normalization of the authentication identity is defined by a
>>   >  particular SASL mechanism, the protocol profile doesn't 
>> influence it.
>>
>>   That's a bit misleading from the protocol's point of view.  From
>>   discussions elsewhere I gather the protocol may normalize the ID as it
>>   pleases for its own use, including when it locates the server-side
>>   secret matching the authentication ID, as long as this does not affect
>>   the ID which the authentication mechanism sees.
>>
>> Your text doesn't seem to be clear on that.
>
> The syntax and semantics of authentication ID's are determined 
> entirely by the authentication mechanism; the protocol has no say in 
> the matter.  All mechanisms are protocol-independent, and all protocol 
> profiles are mechanism-independent.
>
> A particular _implementation_ must be able to perform the 
> authorization check (can this authid use the requested autzid) and 
> must be able to derive an authorization ID from an authentication ID.  
> These operations depend on both the mechanism and protocol profile in 
> use, and their details are deliberately left to the implementation and 
> to local policy.

Do I need to change anything in the document?

Date: Thu, 21 Oct 2004 16:13:56 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 03:25 PM 10/21/2004, Jeffrey Hutzelman wrote:
>The syntax and semantics of authentication ID's are determined entirely by the authentication mechanism;

If you were to say the syntax and semantics of any
authentication identity information carried in the
exchange is specified by the mechanism's specification,
I would agree.

But, without that qualification, I would have to
disagree.  For instance, an application protocol can
certainly detail how authentication identities are to
represented in identity-assumption policy information
carried by the protocol, and associated semantics.

>All mechanisms are protocol-independent, and all protocol profiles are mechanism-independent.

 From the perspective of the SASL framework, yes.

>A particular _implementation_ must be able to perform the authorization check (can this authid use the requested autzid) and must be able to derive an authorization ID from an authentication ID.

Which requires may involve deriving an authentication ID from
credential information.   It is not appropriate to assume the
particular form of authentication identity in the credentials,
are the form used to establish this authorization identity.
For instance, consider EXTERNAL with TLS X.509 authentication.
The authentication identity might be the subject DN, or it
might be viewed as being one of the altSubjNames, or something
derived from this (and possible other stuff).

>These operations depend on both the mechanism and protocol profile in use, and their details are deliberately left to the implementation and to local policy.

And possible aspects of the application-level protocol specification.

For instance, it is reasonable for an application-level protocol
specification to specify how mechanism-specific authentication
identity forms relate to protocol-specific authentication forms,
as necessary say to detail how mechanism-specific credentials
(or associated policies) are to managed using the application-level
protocol.  Of course, an application-level protocol specification
detailing such things should not unnecessarily preclude use of
the mechanisms not explicitly discussed in the application-level
protocol specification.

Kurt 

Date: Thu, 21 Oct 2004 18:25:53 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
Sender: [email-masked]

On Thursday, October 21, 2004 15:39:29 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

>>> No, authentication identity may not even have a syntax which is valid
>>> for an authorization identity.
>>> [...]
>>> The client is requesting that the
>>> authorization identity is derived from the authentication identity.
>>
>> Conceptionally, the client is requesting the act as the
>> identity associated with credentials.  This identity
>> might have many different representations.
>
> [...]
> But even so, authorization identities and authentication identities seem
> to me to be 'conceptually' different types of entities; defined by
> different standards and used in different ways.  So whether we talk of
> conceptual or represented identities, I'd still prefer to say that the
> authorization id is derived from the authentication id rather than it is
> the authentication id.

Agree.  Use the "is derived from" language; it's less likely to confuse 
people into thinking in terms of blindly copying strings around.

>>> s/user('s)/authentication identity('s)/.
>>
>> Since authentication identity is defined here as
>> being the identity associated the credentials, would
>> be effective saying:
>>         s/user's credentials/credentials of the identity
>>         associated with the credentials/
>
> Well, I'd still like to get rid of that 'user'.  'User' is used
> elsewhere as merely one kind of identity.
> Maybe s/user's credentials/presented credentials/,
> or s/users's credentials/credentials/, s/user/authentication identity/?

s/user/client/  and be done with it.

> Well, what I wanted to address was what I mentioned in my original review:
>
>   >  Any normalization of the authentication identity is defined by a
>   >  particular SASL mechanism, the protocol profile doesn't influence it.
>
>   That's a bit misleading from the protocol's point of view.  From
>   discussions elsewhere I gather the protocol may normalize the ID as it
>   pleases for its own use, including when it locates the server-side
>   secret matching the authentication ID, as long as this does not affect
>   the ID which the authentication mechanism sees.
>
> Your text doesn't seem to be clear on that.

The syntax and semantics of authentication ID's are determined entirely by 
the authentication mechanism; the protocol has no say in the matter.  All 
mechanisms are protocol-independent, and all protocol profiles are 
mechanism-independent.

A particular _implementation_ must be able to perform the authorization 
check (can this authid use the requested autzid) and must be able to derive 
an authorization ID from an authentication ID.  These operations depend on 
both the mechanism and protocol profile in use, and their details are 
deliberately left to the implementation and to local policy.

> Do you mean the OSI model application layer?

No; he's using the term in a generic sense and there does not need to be a 
reference to the OSI model, which in any case is only of limited use.  For 
example, if you look, you'll find that SASL does not correspond to any 
layer in the OSI model.

The distinction here is between SASL-using protocols (most of which are, in 
fact, "application" protocols in the narrower sense) as opposed to SASL 
itself or the underlying authentication mechanisms, all of which are also 
"protocols" in the generic sense.

The use of the phrase "application protocol" in this sense is common in 
discussions about security frameworks, and should not cause confusion.  In 
fact, I agree with Kurt that the use of the unqualified term "protocol" is 
confusing in this document, because in a document which defines a framework 
consisting of N+M+1 protocol components, the term is highly ambiguous, our 
definition notwithstanding.

However, I also agree that we need consistent usage throughout the 
document.  Either use "application protocol" everywhere, or not at all.

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

Date: Thu, 21 Oct 2004 13:11:23 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: [email-masked]
Sender: [email-masked]

At 12:03 PM 10/21/2004, Hallvard B Furuseth wrote:
>I'll be reading this - and the draft - later, but first:
>
>Kurt D. Zeilenga writes:
>> The problem is that, in the SASL framework, no identity
>> representation may be explicitly transferred.  However,
>> regardless of what's transferred.
>
>That last sentence seems to have been truncated.

I think I was going to note that regardless of identity
abstract (DN,Kerberos principal,other) and encoding
(for DNs: RFC 2253 string, RFC 2829 authzid, DCE DN
format, base64 of the DER encoding, other) used in
transfer, the transferred value refers to some identity.
Later, that identity may be represented using other
abstractions and/or encodings.

If we talk conceptually, we can say the authorization
identity value input of the user, the value transferred
by the SASL mechanism, the value used in determining
whether the user associated with the credentials may
act as specified identity, the value used in making
authorization identities, and the values used in
specifying identity assumption and/or authorization
policies are all refer to the same identity, the
identity to act as, the authorization identity.

If, however, we talk in terms of how this and other
identity concept is represented here and there, we'll
have to come up with numerous terms and over-specify
the details of identity management.  Most of the
details of identity management are simply beyond
the scope of the SASL framework.

Kurt

Date: Thu, 21 Oct 2004 11:40:50 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: [email-masked]
Sender: [email-masked]

At 06:39 AM 10/21/2004, Hallvard B Furuseth wrote:

>Sorry about the late replies; I thought I had addressed this.
>
>Kurt D. Zeilenga writes:
>>At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>> 3.2 Identity Concepts
>>>
>>>> The client provides its credentials and, optionally, a
>>>> string representing the requested authorization identity
>>>> as part of the SASL exchange.
>>>
>>>>                                When this string is not
>>>> provided, the client is requesting to act as the identity
>>>> associated with the credentials (e.g., the user is
>>>> requesting to act as the authentication identity).
>>>
>>>No, authentication identity may not even have a syntax which is valid
>>>for an authorization identity.
>> 
>> An identity can be represented in many different ways.
>> Here I am using the terms "authentication identity"
>> and "authorization identity" conceptional, and
>> generally without regards to how they might be represented
>> at any given time or place.  When I referred to a "string
>> representing the requested authorization identity", I
>> referred to a particular representation of an identity.
>> But when I said, "the client is requesting to act as the
>> [authentication identity]", I didn't talk about how that
>> identity would be represented.
>>
>>>The client is requesting that the
>>>authorization identity is derived from the authentication identity.
>> 
>> Conceptionally, the client is requesting the act as the
>> identity associated with credentials.  This identity
>> might have many different representations.
>
>I hadn't quite caught on to the 'conceptual' part, but it seems rather
>confusing to have the same names for 'conceptual' and 'represented'
>identities.

Would it help if the conceptional discussion was moved to the
Introduction?

The problem is that, in the SASL framework, no identity
representation may be explicitly transferred.  However,
regardless of what's transferred.

>But even so, authorization identities and authentication identities seem
>to me to be 'conceptually' different types of entities;

I disagree.  An identity (authorization or authentication) refers
to a human or application entity.  The qualification, authorization
or authentication, refers not to kind of entity, but to the usage
of the identity.

>defined by
>different standards and used in different ways.  So whether we talk of
>conceptual or represented identities, I'd still prefer to say that the
>authorization id is derived from the authentication id rather than it is
>the authentication id.

The 'derived' language is problematic.  Consider the authorization
identity (and when its explicitly transferred).  A user wishes
to act as some other user that it identifies as some particular
identity.  The user enters a representation of that identity
to the client which then, knowing the application protocol
requirements, translates the user provided identity string
into form required by the application protocol specification.
Then the server might take this form and translate it some
other representation of the identity to make identity assumption
policy decision, and then do some other translation of the
representation of the identity to produce the identity
representation actually used to make authorization decisions.

Regardless of the identity abstraction (DN, Kerberos principle,
etc.) and the encoding of values of that abstraction (LDAPDN,
DER DN, GSER DN, DCE DN) used here and there, there is
conceptional one authorization identity.

For instance, consider an LDAP client which offers an input
dialog allowing the user to input a character string
representing the desired authorization identity and
a indicator of the format of that string.  The user inputs
the string "[email-masked]" and selects the form identifier
marked "user name".  The LDAP client, knowing the requirements
of the LDAP's SASL profile, takes this information and constructs
the string "u:[email-masked]" and transfers it as the
authorization identity string in some mechanism (say EXTERNAL).
The server needs to determine whether the user associated
with the credentials is authorized to act as "u:[email-masked]",
but the server's identity assumption policy subsystem happens
to requires identities to represented as email addresses
with the domain part in upper case.  So, the server produces
the string "[email-masked]" and feeds this (and other
information) to the identity assumption policy subsystem.
Assuming success, the server now needs to produce an
representation suitable for use in making authorization
decisions.  That subsystem might happen to require identities
to be presented as DER encoded DNs.  So the server somehow
produces that.  And in the actual policy, maybe DNs are
presented using the LDAP DN string format.

That is, one identity concept in authorization identity:
        the identity to act as
with multiple identity representations.

If we were to try to name each of distinct identity
representations of the authorization identities that were
likely evident in any application (both client and server)
use of SASL, things will get confused.  Developers will
start to think that the form of the identity transferred
on the wire is the actual form used elsewhere and, in
particular, used in making authorization decisions.  That
is not necessarily so.

For instance, I know of no LDAP server implementation
that uses the particular form of authorization identity
required by LDAP SASL profile in making authorization
decisions.  They all map the LDAP authzId string (even
if the dnAuthzid variant is used) to some other format,
such as an LDAP DN string.

Kurt

>>>Also, I suggest /not provided/omitted or empty/.
>>>
>>>> The server is responsible for verifying the user's
>>>> credentials and verifying that the user is able to
>>>> act as the authorization identity.
>>>
>>>s/user('s)/authentication identity('s)/.
>> 
>> Since authentication identity is defined here as
>> being the identity associated the credentials, would
>> be effective saying:
>>         s/user's credentials/credentials of the identity
>>         associated with the credentials/
>
>Well, I'd still like to get rid of that 'user'.  'User' is used
>elsewhere as merely one kind of identity.
>Maybe s/user's credentials/presented credentials/,
>or s/users's credentials/credentials/, s/user/authentication identity/?
>
>>>> A SASL exchange
>>>> is successful if and only if both of these verifications
>>>> are successful.
>>>
>>>Security layer negotiation can also fail.
>>>Or something can just plain break a specification.
>> 
>> It may be better to reverse the statement:
>>         A SASL exchange fails if either (or both) of these
>>         verifications fails.
>
>Yes.
>
>>>  However, the
>> 
>> Noting my above note would apply here as well, I think
>> this suggestion is a good one.
>> 
>>>> precise form(s)
>>>
>>>  and semantics  
>>>
>>>> of the authentication identities (used
>>>> within the server in its verifications, or otherwise)
>>>> and the precise form(s)
>>>
>>>  and semantics
>> 
>> I have some concern here.  In particular, the mechanism
>> specification may cover some authentication identity
>> semantics.  Or, as you note below, the application
>> profile may detail matching semantics.   I think talking
>> adding "and semantics" will just confuse things.
>
>Well, what I wanted to address was what I mentioned in my original review:
>
>  >  Any normalization of the authentication identity is defined by a
>  >  particular SASL mechanism, the protocol profile doesn't influence it.
>
>  That's a bit misleading from the protocol's point of view.  From
>  discussions elsewhere I gather the protocol may normalize the ID as it
>  pleases for its own use, including when it locates the server-side
>  secret matching the authentication ID, as long as this does not affect
>  the ID which the authentication mechanism sees.
>
>Your text doesn't seem to be clear on that.
>
>>>> In
>>>> some circumstances, the precise identity forms used
>>>> outside of the SASL exchange may be dictated by other
>>>> specifications.  For instance, the authorization policy
>>>> specification for an application protocol may dictate the
>>>> precise form that an authorization identity is to be
>>>> represented in the authorization policy.
>>>
>>>Or the protocol profile may specify that authorization identities
>>>are to be checked e.g. in a case-insensitive manner.
>>>
>>>Finally, what is the word 'application' doing here?  What is an
>>>'application profile'?  Or an 'application protocol' as opposed to a
>>>protocol'?
>> 
>> I mean application-level protocol.   I generally find the
>> bare use of the term 'protocol' to be somewhat unclear.
>> I rather quality the term with 'application-level'.  However,
>> that likely should be done consistently or not at all. 
>
>Do you mean the OSI model application layer?  If so, it needs a
>reference to the OSI model.  If not, I'm still not sure what you mean.
>BTW, I notice that there are several other uses of 'application' in
>rfc2222bis which I'm not quite sure of, now that it's bought up.
>
>Also, I would have thought SASL could be used at the presentation layer
>as well.
>
>-- 
>Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: EXTERNAL description
Date: Thu, 21 Oct 2004 19:22:35 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>>7.    The EXTERNAL mechanism    

>>    The server uses information external to SASL to determine the
>>    authentication identity and whether the authentication is to
>>    succeed.
>
> Although this implies the same thing (if you take into consideration 
> implied authorization step), I would prefer the original text.

Well, SASL mechanisms are now supposed to set an authentication
identity, but EXTERNAL in the original or in your form doesn't.
(I wish I'd realized that before posting.)

OTOH, mixing rfc2222's paragraph 5 (authz id) into paragraph 3 was very
nice, and my text should not have lost the 'system' doing
authentication.

If I mix your text and mine a bit, does this cover all bases?

  Some system external to SASL must authenticate the client.  If that
  succeeds, the server determines the authentication identity from
  information from this system.  If the requested authorization identity
  is empty, the authorization identity is derived from the
  authentication identity.  The server determines if the authentication
  identity is allowed to act as the authorization identity.  Finally, it
  indicates completion or failure of the authentication exchange.

Or replace the last sentence with

  If all that succeeds, the server indicates successful completion of
  the authentication exchange; otherwise it indicates failure.

Sigh.  And this started with trying to make the text _shorter_:-)

-- 
Hallvard

Date: Thu, 21 Oct 2004 16:47:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: EXTERNAL description
Sender: [email-masked]

Hallvard B Furuseth wrote:

>>7.    The EXTERNAL mechanism    
>>
>>  The client sends a single message containing the UTF-8 encoding of
>>  the
>>    
>>
>
>Maybe add 'requested'?
>
Using "requested" here is Ok, IMHO.

>>  authorization identity. The message may be empty. The form of the
>>  authorization identity is further restricted by the application-level
>>  protocol's SASL profile.
>>    
>>
>
>s/is further/may be/.  (Further restricted than what?  Being empty?:-)
>
Ok.

>Though I'd move that last sentence to the last paragraph (below) so all
>handling of the authorization identity is in one place.
>
>These paragraphs can be shortened a bit now that 'authentication
>identities' have been introduced:
>  
>
>>  The server uses information, external to SASL, to determine whether
>>  the client is permitted to authenticate as the authorization
>>  identity.  If the client is so authorized, the server indicates
>>  successful completion of the authentication exchange; otherwise the
>>  server indicates failure.
>>    
>>
>
>    The server uses information external to SASL to determine the
>    authentication identity and whether the authentication is to
>    succeed.
>
Although this implies the same thing (if you take into consideration 
implied authorization step), I would prefer the original text.

>  It then indicates completion or failure of the
>    authentication exchange.
>
Here is the latest text for SASL EXTERNAL. This is not exactly what 
you've asked, but let me know what you think:

The mechanism name associated with external authentication is "EXTERNAL".

The client sends a single message containing the UTF-8 encoding of the 
requested authorization identity. The message may be empty. The form of 
the authorization identity may be restricted by the application 
protocol's SASL profile.

The server uses information, external to SASL, to determine whether the 
client is permitted to act as the authorization identity.  (If the 
requested authorization identity is empty, the authorization identity is 
to be derived from authentication credentials which exist in the system 
that is providing the external authentication.) If the client is 
permitted to do so, the server indicates successful completion of the 
authentication exchange; otherwise the server indicates failure.

The system providing this external information may be, for example, 
IPSec [IPSec] or TLS [TLS]. However, the client can make no assumptions 
as to what information the server can use in determining client 
authorization. For example, just because TLS was established, doesn't 
mean that the server will use the information provided by TLS.

Alexey

Date: Thu, 21 Oct 2004 16:23:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>>3.1.  Authentication protocol exchange
>>    
>>
>>   A SASL mechanism is responsible for conducting an authentication
>>   protocol exchange.
>>
>
>I don't think so.  It's the protocol which conducts the _exchange_,
>and (below) which transmits anything.
>
What about

A SASL mechanism is responsible for conducting an authentication exchange.

?
The mechanism is clearly "conducting" the exchange, but the protocols
carries it.

>[...] 
>
>>   The mechanism MUST preserve Unicode codepoint when transferring
>>   authorization identity (e.g. the mechanism cann't apply any form of
>>   normalization).    
>>
>
>The () part does not seem say the same as the preceding sentence: 'when
>transferring...' sounds like only the client-side part of the mechanism
>must preserve the ID, while the () sounds like the server side also must
>preserve it.

The text in () only talks about transfer (actually it also applies to
hashing and other similar uses). For the purposes of looking up
credentials, access control, etc. the server can do as it pleases. This
is out of scope for SASL.

Alexey

Date: Thu, 21 Oct 2004 15:36:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Kurt D. Zeilenga writes:
>  
>
>>At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote:
>>    
>>
>>>>Abstract
>>>>        
>>>>
>>>>   The Simple Authentication and Security Layer (SASL) is a framework
>>>>   for providing authentication and data security services in
>>>>   connection-oriented protocols via replaceable
>>>>        
>>>>
>>>authentication
>>>      
>>>
>>The sentence might be more clear if worded:
>>        The Simple Authentication and Security Layer (SASL) is
>>        a framework for providing authentication and data security
>>        services via replaceable mechanisms to connection-oriented
>>        protocols.
>>    
>>
>
>I don't think so; it looks a little strange to have the 'to...' after
>the 'via...'.  Maybe s/in/to/ would improve the original sentence.
>
>I've asked a coworker what he thought the Abstract meant: He got it more
>or less right, but was somewhat vague about it and thought it was a bit
>hard to get.  He did not think my suggested extra words would make a
>difference.
>  
>
Unless somebody objects, I am leaving the sentence as is.

Alexey

Date: Thu, 21 Oct 2004 14:51:51 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Kurt D. Zeilenga writes:
>  
>
>>1) Re-keying of security layers     
>>
>>    SASL mechanisms that support re-keying SHOULD:
>>    - indicate that re-keying is or will be needed immediately;
>>    - provide re-keying messages or transparently include re-keying
>>      messages in the security layers; the latter can happen without
>>      application involvement, but only as long as the application is
>>      engaged in timely bidirectional exchanges with its peer.
>>
>>The chairs believes the WG supports addition of this text.    
>>
>
>Please also explain what 're-keying' and 'timely bidirectional
>exchanges' are.
>
>(I'm guessing that re-keying is a SASL layer's equivalent of TLS
>ciphersuite renegotiation, but I don't know.
>
Correct me if I am wrong, but I understand rekeying as "renegotiation of 
the signing/encrypting key".
But I agree with you, those two terms must be explained. And I am not 
sure I can give a good definition for 'timely bidirectional exchange'

>  I don't know if I would
>have thought of that if I did not know of TLS.  I have no idea how a
>protocol or implementation can know that a peer will be engage in
>anything 'timely'.  I'm not sure what exactly 'bidirectional exchanges'
>are either, but from the context my guess would be that if one peer
>chooses to send a message, the other is expected to notice and send a
>response, and do so before sending (or also reading?) anything else on
>the connection.)
>  
>
Alexey

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Thu, 21 Oct 2004 15:43:58 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>>>>6.1.  Client sends data first
>>>>>
>>>>>   If the initial client response parameter is not given, or if a
>>>>>   protocol's profile does not permit the command which initiates an
>>>>>   authentication protocol exchange to contain an initial client
>>>>>   response, then the server issues a challenge with no data.  The
>>>>>   client's response to this challenge is then used as the initial
>>>>>   client response.  (The server then proceeds to send the next
>>>>>   challenge, indicates completion, or indicates failure.)
>>>>>        
>>>>>
>>>>Then protocols that support an initial response must be clear on how to
>>>>distinguish an absent initial response from a present but empty initial
>>>>response.  I expect their protocol profiles must also specify whether or
>>>>not the protocol _can_ distinguish the two, so the mechanism can tell
>>>>whether or not to send empty initial responses.
>>>>      
>>>>
>>> This is described in Section 4, bullet # 2.
>>
>>No...  First, it's only a SHOULD:
>>
>>   If the protocol allows for the initial response, the protocol profile
>>   SHOULD also describe how an empty initial response is encoded.
>>
> I've already changed SHOULD to MUST. This issue was raised during WGLC.
> 
>>Second, if that sentence is intended to address this issue, I can think
>>of two different things it can imply in order to do so.  It is not at
>>all clear to me that it means either:
>>
>>1) "If the protocol profile does not say how an initial response is
>>   encoded, then empty but present initial responses are not supported."
>>
>>2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
>>   MUST be possible to send an empty initial response which can be
>>   distinguished from no initial response."
>
> The intention was to say #2. I am not aware of any protocol profile that 
> supports initial response, but doesn't allow for it being empty.

Me neither, which is why I used an imaginary example.  But I've just
realized that your answer opens for a third possibility: Protocols that
do allow empty initial responses, but not absent initial responses.
(Again, an SMTP-like protocol which strips trailing whitespace could be
an example.)

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
Date: Thu, 21 Oct 2004 15:39:29 +0200
Sender: [email-masked]

Sorry about the late replies; I thought I had addressed this.

Kurt D. Zeilenga writes:
>At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> 3.2 Identity Concepts
>>
>>> The client provides its credentials and, optionally, a
>>> string representing the requested authorization identity
>>> as part of the SASL exchange.
>>
>>>                                When this string is not
>>> provided, the client is requesting to act as the identity
>>> associated with the credentials (e.g., the user is
>>> requesting to act as the authentication identity).
>>
>>No, authentication identity may not even have a syntax which is valid
>>for an authorization identity.
> 
> An identity can be represented in many different ways.
> Here I am using the terms "authentication identity"
> and "authorization identity" conceptional, and
> generally without regards to how they might be represented
> at any given time or place.  When I referred to a "string
> representing the requested authorization identity", I
> referred to a particular representation of an identity.
> But when I said, "the client is requesting to act as the
> [authentication identity]", I didn't talk about how that
> identity would be represented.
>
>>The client is requesting that the
>>authorization identity is derived from the authentication identity.
> 
> Conceptionally, the client is requesting the act as the
> identity associated with credentials.  This identity
> might have many different representations.

I hadn't quite caught on to the 'conceptual' part, but it seems rather
confusing to have the same names for 'conceptual' and 'represented'
identities.

But even so, authorization identities and authentication identities seem
to me to be 'conceptually' different types of entities; defined by
different standards and used in different ways.  So whether we talk of
conceptual or represented identities, I'd still prefer to say that the
authorization id is derived from the authentication id rather than it is
the authentication id.

>>Also, I suggest /not provided/omitted or empty/.
>>
>>> The server is responsible for verifying the user's
>>> credentials and verifying that the user is able to
>>> act as the authorization identity.
>>
>>s/user('s)/authentication identity('s)/.
> 
> Since authentication identity is defined here as
> being the identity associated the credentials, would
> be effective saying:
>         s/user's credentials/credentials of the identity
>         associated with the credentials/

Well, I'd still like to get rid of that 'user'.  'User' is used
elsewhere as merely one kind of identity.
Maybe s/user's credentials/presented credentials/,
or s/users's credentials/credentials/, s/user/authentication identity/?

>>> A SASL exchange
>>> is successful if and only if both of these verifications
>>> are successful.
>>
>>Security layer negotiation can also fail.
>>Or something can just plain break a specification.
> 
> It may be better to reverse the statement:
>         A SASL exchange fails if either (or both) of these
>         verifications fails.

Yes.

>>  However, the
> 
> Noting my above note would apply here as well, I think
> this suggestion is a good one.
> 
>>> precise form(s)
>>
>>  and semantics  
>>
>>> of the authentication identities (used
>>> within the server in its verifications, or otherwise)
>>> and the precise form(s)
>>
>>  and semantics
> 
> I have some concern here.  In particular, the mechanism
> specification may cover some authentication identity
> semantics.  Or, as you note below, the application
> profile may detail matching semantics.   I think talking
> adding "and semantics" will just confuse things.

Well, what I wanted to address was what I mentioned in my original review:

  >  Any normalization of the authentication identity is defined by a
  >  particular SASL mechanism, the protocol profile doesn't influence it.

  That's a bit misleading from the protocol's point of view.  From
  discussions elsewhere I gather the protocol may normalize the ID as it
  pleases for its own use, including when it locates the server-side
  secret matching the authentication ID, as long as this does not affect
  the ID which the authentication mechanism sees.

Your text doesn't seem to be clear on that.

>>> In
>>> some circumstances, the precise identity forms used
>>> outside of the SASL exchange may be dictated by other
>>> specifications.  For instance, the authorization policy
>>> specification for an application protocol may dictate the
>>> precise form that an authorization identity is to be
>>> represented in the authorization policy.
>>
>>Or the protocol profile may specify that authorization identities
>>are to be checked e.g. in a case-insensitive manner.
>>
>>Finally, what is the word 'application' doing here?  What is an
>>'application profile'?  Or an 'application protocol' as opposed to a
>>protocol'?
> 
> I mean application-level protocol.   I generally find the
> bare use of the term 'protocol' to be somewhat unclear.
> I rather quality the term with 'application-level'.  However,
> that likely should be done consistently or not at all. 

Do you mean the OSI model application layer?  If so, it needs a
reference to the OSI model.  If not, I'm still not sure what you mean.
BTW, I notice that there are several other uses of 'application' in
rfc2222bis which I'm not quite sure of, now that it's bought up.

Also, I would have thought SASL could be used at the presentation layer
as well.

-- 
Hallvard

Date: Thu, 21 Oct 2004 13:25:45 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Some editorial changes to RFC2222bis
Sender: [email-masked]

Hallvard has suggested to change "mechanism specific"/"protocol 
specific" to "mechanism-specific"/"protocol-specific".
If you have any opinion on this (or maybe you know what is the right 
way), please let me know by the end of Friday.

Alexey

Date: Fri, 15 Oct 2004 10:21:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

--------------050904030104050703090604
Content-type: text/plain; charset="us-ascii"

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>>  Made requirement to verify that an authorization identity is correct
>>>  by performing SASLprep a SHOULD, instead of a MUST.
>>>      
>>>
>>I've changed this to:
>>
>>   Made requirement to verify that an authorization identity is correct
>>   by performing SASLprep.
>>
>>Is this better?
>>    
>>
>
>No, because it's not a requirement:-)
>
Fine, but see below.

> Anyway, I think this paragraph can
>simply be deleted, since it's just part of the 'I-D revision history'.
>The appendix already covers SASLprep as RFC history:
>
>   Added text about SASLprep for authentication identities and
>   passwords.  Described where SASLprep preparation should take place.
>  
>
This doesn't cover authorization identities.

--------------050904030104050703090604
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hallvard B Furuseth wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Alexey Melnikov writes:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">  Made requirement to verify that an authorization identity is correct
  by performing SASLprep a SHOULD, instead of a MUST.
      </pre>
    </blockquote>
    <pre wrap="">I've changed this to:

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep.

Is this better?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, because it's not a requirement:-)</pre>
</blockquote>
Fine, but see below.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap=""> Anyway, I think this paragraph can
simply be deleted, since it's just part of the 'I-D revision history'.
The appendix already covers SASLprep as RFC history:

   Added text about SASLprep for authentication identities and
   passwords.  Described where SASLprep preparation should take place.
  </pre>
</blockquote>
This doesn't cover authorization identities.<br>
<br>
</body>
</html>

--------------050904030104050703090604--

Date: Thu, 14 Oct 2004 19:10:17 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: [email-masked]
Sender: [email-masked]

At 06:19 PM 10/14/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> 3.2 Identity Concepts
>
>> The client provides its credentials and, optionally, a
>> string representing the requested authorization identity
>> as part of the SASL exchange.
>
>>                                When this string is not
>> provided, the client is requesting to act as the identity
>> associated with the credentials (e.g., the user is
>> requesting to act as the authentication identity).
>
>No, authentication identity may not even have a syntax which is valid
>for an authorization identity.

An identity can be represented in many different ways.
Here I am using the terms "authentication identity"
and "authorization identity" conceptional, and
generally without regards to how they might be represented
at any given time or place.  When I referred to a "string
representing the requested authorization identity", I
referred to a particular representation of an identity.
But when I said, "the client is requesting to act as the
[authentication identity]", I didn't talk about how that
identity would be represented.

>The client is requesting that the
>authorization identity is derived from the authentication identity.

Conceptionally, the client is requesting the act as the
identity associated with credentials.  This identity
might have many different representations.

>Also, I suggest /not provided/omitted or empty/.
>
>> The server is responsible for verifying the user's
>> credentials and verifying that the user is able to
>> act as the authorization identity.
>
>s/user('s)/authentication identity('s)/.

Since authentication identity is defined here as
being the identity associated the credentials, would
be effective saying:
        s/user's credentials/credentials of the identity
        associated with the credentials/

>s/able/allowed/.

Okay.

>> A SASL exchange
>> is successful if and only if both of these verifications
>> are successful.
>
>Security layer negotiation can also fail.
>Or something can just plain break a specification.

It may be better to reverse the statement:
        A SASL exchange fails if either (or both) of these
        verifications fails.

>> While SASL mechanisms specify the form of credentials
>> used to authenticating users and SASL application
>> profiles specify the form of authorization identities
>> transferred as part of authentication exchange, the

I note that s/SASL mechanisms specify/SASL mechanism
specifications describe/, s/profiles specify/profiles
describe/.   That is, we need to be careful not to use
the term "mechanism" to refer to a mechanism's
specification. 

>This sentence needs to be broken up.
>
>  SASL mechanisms specify the form of credentials
>  used to authenticating users, and SASL application
>  profiles specify the form of authorization identities
>  transferred as part of authentication exchange.
>  However, the

Noting my above note would apply here as well, I think
this suggestion is a good one.

>> precise form(s)
>
>  and semantics  
>
>> of the authentication identities (used
>> within the server in its verifications, or otherwise)
>> and the precise form(s)
>
>  and semantics

I have some concern here.  In particular, the mechanism
specification may cover some authentication identity
semantics.  Or, as you note below, the application
profile may detail matching semantics.   I think talking
adding "and semantics" will just confuse things.

>> of the authorization identities
>> (used in making authorization decisions, or otherwise) is
>> beyond the scope of the SASL and this specification.
>
>> In
>> some circumstances, the precise identity forms used
>> outside of the SASL exchange may be dictated by other
>> specifications.  For instance, the authorization policy
>> specification for an application protocol may dictate the
>> precise form that an authorization identity is to be
>> represented in the authorization policy.
>
>Or the protocol profile may specify that authorization identities
>are to be checked e.g. in a case-insensitive manner.
>
>Finally, what is the word 'application' doing here?  What is an
>'application profile'?  Or an 'application protocol' as opposed to a
>protocol'?

I mean application-level protocol.   I generally find the
bare use of the term 'protocol' to be somewhat unclear.
I rather quality the term with 'application-level'.  However,
that likely should be done consistently or not at all. 

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
Date: Fri, 15 Oct 2004 03:19:42 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
> 3.2 Identity Concepts

> The client provides its credentials and, optionally, a
> string representing the requested authorization identity
> as part of the SASL exchange.

>                                When this string is not
> provided, the client is requesting to act as the identity
> associated with the credentials (e.g., the user is
> requesting to act as the authentication identity).

No, authentication identity may not even have a syntax which is valid
for an authorization identity.  The client is requesting that the
authorization identity is derived from the authentication identity.

Also, I suggest /not provided/omitted or empty/.

> The server is responsible for verifying the user's
> credentials and verifying that the user is able to
> act as the authorization identity.

s/user('s)/authentication identity('s)/.
s/able/allowed/.

> A SASL exchange
> is successful if and only if both of these verifications
> are successful.

Security layer negotiation can also fail.
Or something can just plain break a specification.

> While SASL mechanisms specify the form of credentials
> used to authenticating users and SASL application
> profiles specify the form of authorization identities
> transferred as part of authentication exchange, the

This sentence needs to be broken up.

  SASL mechanisms specify the form of credentials
  used to authenticating users, and SASL application
  profiles specify the form of authorization identities
  transferred as part of authentication exchange.
  However, the

> precise form(s)

  and semantics  

> of the authentication identities (used
> within the server in its verifications, or otherwise)
> and the precise form(s)

  and semantics

> of the authorization identities
> (used in making authorization decisions, or otherwise) is
> beyond the scope of the SASL and this specification.

> In
> some circumstances, the precise identity forms used
> outside of the SASL exchange may be dictated by other
> specifications.  For instance, the authorization policy
> specification for an application protocol may dictate the
> precise form that an authorization identity is to be
> represented in the authorization policy.

Or the protocol profile may specify that authorization identities
are to be checked e.g. in a case-insensitive manner.

Finally, what is the word 'application' doing here?  What is an
'application profile'?  Or an 'application protocol' as opposed to a
protocol'?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis Appendix C
Date: Fri, 15 Oct 2004 02:47:40 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>>   Made requirement to verify that an authorization identity is correct
>>   by performing SASLprep a SHOULD, instead of a MUST.
>
> I've changed this to:
> 
>    Made requirement to verify that an authorization identity is correct
>    by performing SASLprep.
> 
> Is this better?

No, because it's not a requirement:-) Anyway, I think this paragraph can
simply be deleted, since it's just part of the 'I-D revision history'.
The appendix already covers SASLprep as RFC history:

   Added text about SASLprep for authentication identities and
   passwords.  Described where SASLprep preparation should take place.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: EXTERNAL description
Date: Fri, 15 Oct 2004 02:26:02 +0200
Sender: [email-masked]

> 7.    The EXTERNAL mechanism

>   The client sends a single message containing the UTF-8 encoding of
>   the

Maybe add 'requested'?

>   authorization identity. The message may be empty. The form of the
>   authorization identity is further restricted by the application-level
>   protocol's SASL profile.

s/is further/may be/.  (Further restricted than what?  Being empty?:-)
Though I'd move that last sentence to the last paragraph (below) so all
handling of the authorization identity is in one place.

These paragraphs can be shortened a bit now that 'authentication
identities' have been introduced:

>   The server uses information, external to SASL, to determine whether
>   the client is permitted to authenticate as the authorization
>   identity.  If the client is so authorized, the server indicates
>   successful completion of the authentication exchange; otherwise the
>   server indicates failure.

    The server uses information external to SASL to determine the
    authentication identity and whether the authentication is to
    succeed.  It then indicates completion or failure of the
    authentication exchange.

>   If the client sends the empty string as the authorization identity,
>   the authorization identity is to be derived from authentication
>   credentials which exist in the system that is providing the external
>   authentication.

    If the requested authorization identity is empty, the authorization
    identity is to be derived from the authentication identity.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: Summary of 2222bis WGLC
Date: Fri, 15 Oct 2004 00:51:20 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:

> 1) Re-keying of security layers 

>     SASL mechanisms that support re-keying SHOULD:
>     - indicate that re-keying is or will be needed immediately;
>     - provide re-keying messages or transparently include re-keying
>       messages in the security layers; the latter can happen without
>       application involvement, but only as long as the application is
>       engaged in timely bidirectional exchanges with its peer.
> 
> The chairs believes the WG supports addition of this text.

Please also explain what 're-keying' and 'timely bidirectional
exchanges' are.

(I'm guessing that re-keying is a SASL layer's equivalent of TLS
ciphersuite renegotiation, but I don't know.  I don't know if I would
have thought of that if I did not know of TLS.  I have no idea how a
protocol or implementation can know that a peer will be engage in
anything 'timely'.  I'm not sure what exactly 'bidirectional exchanges'
are either, but from the context my guess would be that if one peer
chooses to send a message, the other is expected to notice and send a
response, and do so before sending (or also reading?) anything else on
the connection.)

> 4) Channel Binding

> Nico (...) suggest security consideration
> text that clients using SASL over TLS should verify
> the server's TLS identity to prevent MITM attacks.
> He also suggested (...)
> 
> The chairs conclude that the WG supports the former
> suggestion but not the latter.

Unless just that literal text will be used (except for expanding
"MITM"): Note that the draft does not explain what channel bindings
are, so either explain or avoid the term.

-- 
Hallvard

Date: Wed, 13 Oct 2004 22:23:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

--------------060000090909080107050306
Content-type: text/plain; charset="us-ascii"

Hallvard B Furuseth wrote:

>>>>5.    Mechanism profile guidelines   
>>>>
>>>>   SASL mechanisms
>>>>   must define which entity (or entities) must perform the preparation.
>>>>   If preparation fails or results in an empty string, the entity doing
>>>>   the preparation MUST fail the authentication exchange.
>>>>        
>>>>
>>>I expect preparation of an empty string should not fail, so:
>>>s/results in/turns a non-empty string into/.
>>>      
>>>
>> This text is talking about authentication identities and passwords. I am
>> not sure whether the empty string should be allowed.
>>    
>>
>
>I can see nothing which forbids it, neither in rfc2222 nor 2222bis.
>
>I have certainly set empty passwords on Unix boxes (off the net); if
>there is a SASL library which allows empty passwords then I assume
>people have found use for them with SASL too.
>
>I expect an empty authentication IDs would be messier, unless the
>authorization ID which is derived from that ID is non-empty.
>
>  
>
Ok, I have done the proposed change. Can anybody suggest a better wording?

--------------060000090909080107050306
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
<title></title>
Hallvard B Furuseth wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">5.    Mechanism profile guidelines   

   SASL mechanisms
   must define which entity (or entities) must perform the preparation.
   If preparation fails or results in an empty string, the entity doing
   the preparation MUST fail the authentication exchange.
        </pre>
      </blockquote>
      <pre wrap="">I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
      </pre>
    </blockquote>
    <pre wrap=""> This text is talking about authentication identities and passwords. I am
 not sure whether the empty string should be allowed.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.

  </pre>
</blockquote>
Ok, I have done the proposed change. Can anybody suggest a better
wording?<br>
<br>
</body>
</html>

--------------060000090909080107050306--

Date: Wed, 13 Oct 2004 17:03:33 -0700
To: =?iso-8859-1?Q?Jes=FAs?= =?iso-8859-1?Q?_Garc=EDa?= Crespo (aka  Sevein) <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused
Cc: [email-masked]
Sender: [email-masked]

Please note that this list is for discussing the standardization
of SASL and, in particular, undertaking the work of the IETF
SASL WG <http://www.ietf.org/html.charters/sasl-charter.html>.
Your post is off-topic here.

Issues specific to any particular SASL implementation should be
directed to forums specific to that implementation.  From your
message, I gather you are using the Cyrus SASL implementation.
Hence, I suggest you direct your comments to:
  <[email-masked]>
Information regarding how to subscribe to this list is available
at:
  http://asg.web.cmu.edu/sasl/#mailinglists

Thanks, Kurt - IETF SASL WG co-chair

At 04:37 PM 10/13/2004, aka Sevein wrote:
>Hi! I am a Linux user who is trying to configure his own server in Internet to give services like www, smtp, imap and that stuff. I have been trying to do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd with rimap to auth users against courier-imap (and authdaemond agains MySQL).
>
>But I thought that it could be better to configure sasl to connect directly to authdaemond socket. I tried it. But I got this error (always):
>
>[postfix/smtpd] warning: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused
>
>My configuration files:
>
>/etc/sasl/smtpd.conf
>^^^^^^^^^^^^^^^^^^^^
>pwcheck_method: authdaemond
>authdaemon_path: /var/lib/courier-imap/authdaemon/socket
>mech_list: plain login
>log_level: 7
>
>ls -li /var/lib/courier-imap/authdaemon/socket 
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>114898 srwxrwxrwx  1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdaemon/socket
>
>Moreover, I did this because I though about the Postfix chroot:
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/
>
>ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/courier-imap/authdaemon/socket
>
>I always restart Postfix when I make changes.
>
>
>Gentoo Linux
>courier-imap-3.0.7
>cyrus-sasl-2.1.19-r1 (with authdaemond support)
>postfix-2.1.3
>
>Do you know what could I do? I am tired of the same!
>
>
>-- 
>Jes�s Garc�a Crespo (aka Sevein)
>http://www.sevein.com
>[email-masked]
>
>GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org)
>
>

Date: Thu, 14 Oct 2004 01:41:24 +0200
From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) <[email-masked]>
To: [email-masked]
Subject: Fw: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused
Sender: [email-masked]

--Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi! I am a Linux user who is trying to configure his own server in Internet=
 to give services like www, smtp, imap and that stuff. I have been trying t=
o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi=
th rimap to auth users against courier-imap (and authdaemond agains MySQL).

But I thought that it could be better to configure sasl to connect directly=
 to authdaemond socket. I tried it. But I got this error (always):

[postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou=
rier authdaemond: Connection refused

My configuration files:

/etc/sasl/smtpd.conf
^^^^^^^^^^^^^^^^^^^^
pwcheck_method: authdaemond
authdaemon_path: /var/lib/courier-imap/authdaemon/socket
mech_list: plain login
log_level: 7

ls -li /var/lib/courier-imap/authdaemon/socket=20
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
114898 srwxrwxrwx  1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae=
mon/socket

Moreover, I did this because I though about the Postfix chroot:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/

ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri=
er-imap/authdaemon/socket

I always restart Postfix when I make changes.

Gentoo Linux
courier-imap-3.0.7
cyrus-sasl-2.1.19-r1 (with authdaemond support)
postfix-2.1.3

Do you know what could I do? I am tired of the same!

--=20
Jes=FAs Garc=EDa Crespo (aka Sevein)
http://www.sevein.com
[email-masked]

GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org)

--Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T
Content-Type: application/pgp-signature

--Signature=_Thu__14_Oct_2004_01_41_24_+0200_qMiQXHfh43S29S0T--

Date: Thu, 14 Oct 2004 01:37:10 +0200
From: =?ISO-8859-1?Q?Jes=FAs_Garc=EDa?= Crespo (aka Sevein) <[email-masked]>
To: [email-masked]
Subject: SASL authentication failure: cannot connect to Courier authdaemond: Connection refused
Sender: [email-masked]

--Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi! I am a Linux user who is trying to configure his own server in Internet=
 to give services like www, smtp, imap and that stuff. I have been trying t=
o do SMTP AUTH thanks to sasl library. Until now, I configured saslauthd wi=
th rimap to auth users against courier-imap (and authdaemond agains MySQL).

But I thought that it could be better to configure sasl to connect directly=
 to authdaemond socket. I tried it. But I got this error (always):

[postfix/smtpd] warning: SASL authentication failure: cannot connect to Cou=
rier authdaemond: Connection refused

My configuration files:

/etc/sasl/smtpd.conf
^^^^^^^^^^^^^^^^^^^^
pwcheck_method: authdaemond
authdaemon_path: /var/lib/courier-imap/authdaemon/socket
mech_list: plain login
log_level: 7

ls -li /var/lib/courier-imap/authdaemon/socket=20
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
114898 srwxrwxrwx  1 root root 0 Oct 14 00:39 /var/lib/courier-imap/authdae=
mon/socket

Moreover, I did this because I though about the Postfix chroot:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mkdir -p /var/spool/postfix/var/lib/courier-imap/authdaemon/

ln /var/lib/courier-imap/authdaemon/socket /var/spool/postfix/var/lib/couri=
er-imap/authdaemon/socket

I always restart Postfix when I make changes.

Gentoo Linux
courier-imap-3.0.7
cyrus-sasl-2.1.19-r1 (with authdaemond support)
postfix-2.1.3

Do you know what could I do? I am tired of the same!

--=20
Jes=FAs Garc=EDa Crespo (aka Sevein)
http://www.sevein.com
[email-masked]

GnuGP key ID: E2DB17E8 (pgp.escomposlinux.org)

--Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p
Content-Type: application/pgp-signature

--Signature=_Thu__14_Oct_2004_01_37_11_+0200_tY9iCG38VnEXDK9p--

Date: Wed, 13 Oct 2004 18:18:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

Hallvard B Furuseth wrote:

>RFC 2222 did not refer to UTF-8 at all.  OTOH, the new UTF-8
>MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned.
>
>   Replaced "buffers of security encoded data" with "buffers of
>   protected data" for clarity.
>  
>
This should read:

Replaced "buffers of cipher-text" with "buffers of protected data" for 
clarity.

>That first phrase does not occur in rfc2222.
>
>   Made requirement to verify that an authorization identity is correct
>   by performing SASLprep a SHOULD, instead of a MUST.
>  
>
I've changed this to:

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep.

Is this better?

>rfc2222 does not contain a single MUST.  And if that SHOULD is the one
>in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is
>correct, not that the ID itself is correct.
>  
>

Date: Wed, 13 Oct 2004 09:43:51 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis Appendix C
Cc: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:23 AM 10/13/2004, Alexey Melnikov wrote:
>The more precise questions are:
>1). Do we want to keep it (the answer I got so far is "yes")

Yes.  When revising an existing RFC, it is generally appropriate
to summarize the changes made.  This information is quite
useful to readers of the new RFC, especially to those who
implemented the existing RFC.

>2). Do we want to keep list of changes between drafts, as well as changes since RFC 2222? The former will be deleted before publication. 

First, if such a list is maintained, it must be maintained
separately from the above summary.

Anways, (as you note) such a list would not be subject to WG
review as it would be removed prior to publication.  Though
some WG find such lists useful, they are certainly not necessary.
Given that this document is already through WG last call, I
don't see how such a list could be useful to the WG
or during subsequent IETF and IESG review.  Personally, I
think our energy would be better spent ensuring the
summary of changes since RFC 2222 was of good quality.

So, no.

Kurt 

Date: Wed, 13 Oct 2004 17:23:14 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

--------------010105090404090300040408
Content-type: text/plain; charset="us-ascii"

Kurt D. Zeilenga wrote:

>At 07:17 AM 10/13/2004, Alexey Melnikov wrote:
>  
>
>>Jeffrey Hutzelman wrote:
>>    
>>
>>>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <[email-masked]> wrote:
>>>      
>>>
>>>>Hallvard B Furuseth wrote:
>>>>        
>>>>
>>>>>I think Appendix C (Changes since RFC 2222) includes an extract of
>>>>>changes between various rfc2222/rfc2222bis versions, rather than just
>>>>>changes since RFC 2222.
>>>>>          
>>>>>
>>>>That is correct.
>>>>
>>>>Question to the WG: should I clean up the Appendix C or should I wait
>>>>till the document is approved for publication?
>>>>        
>>>>
>
>As the WG must review and reach consensus as to content of
>Appendix before it submitted to the AD for consideration,
>it should be cleaned up now.
>  
>
Ok.

The more precise questions are:
1). Do we want to keep it (the answer I got so far is "yes")
2). Do we want to keep list of changes between drafts, as well as 
changes since RFC 2222? The former will be deleted before publication.

>>>This section is essentially a changelog.
>>>      
>>>
>>Yes.
>>    
>>
>
>When I think of an I-D changelog, I think of a log of changes
>between each revision of the I-D.  This is not that. 
>  
>
In practice it is kind of "in between". I was updating it each time a 
major change was done, but each change was only recorded once (even if 
multiple revisions had to deal with the same change).

Alexey

--------------010105090404090300040408
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Kurt D. Zeilenga wrote:<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">At 07:17 AM 10/13/2004, Alexey Melnikov wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Jeffrey Hutzelman wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">Hallvard B Furuseth wrote:
        </pre>
        <blockquote type="cite">
          <pre wrap="">I think Appendix C (Changes since RFC 2222) includes an extract of
changes between various rfc2222/rfc2222bis versions, rather than just
changes since RFC 2222.
          </pre>
        </blockquote>
        <pre wrap="">That is correct.

Question to the WG: should I clean up the Appendix C or should I wait
till the document is approved for publication?
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
As the WG must review and reach consensus as to content of
Appendix before it submitted to the AD for consideration,
it should be cleaned up now.
  </pre>
</blockquote>
Ok.<br>
<br>
The more precise questions are:<br>
1). Do we want to keep it (the answer I got so far is "yes")<br>
2). Do we want to keep list of changes between drafts, as well as
changes since RFC 2222? The former will be deleted before publication.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">This section is essentially a changelog.
      </pre>
    </blockquote>
    <pre wrap="">Yes.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
When I think of an I-D changelog, I think of a log of changes
between each revision of the I-D.  This is not that. 
  </pre>
</blockquote>
In practice it is kind of "in between". I was updating it each time a
major change was done, but each change was only recorded once (even if
multiple revisions had to deal with the same change).<br>
<br>
Alexey<br>
<br>
</body>
</html>

--------------010105090404090300040408--

Date: Wed, 13 Oct 2004 08:50:02 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis Appendix C
Cc: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:17 AM 10/13/2004, Alexey Melnikov wrote:

>Jeffrey Hutzelman wrote:
>
>>On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov <[email-masked]> wrote:
>>
>>>Hallvard B Furuseth wrote:
>>>
>>>>I think Appendix C (Changes since RFC 2222) includes an extract of
>>>>changes between various rfc2222/rfc2222bis versions, rather than just
>>>>changes since RFC 2222.
>>>
>>>That is correct.
>>>
>>>Question to the WG: should I clean up the Appendix C or should I wait
>>>till the document is approved for publication?

As the WG must review and reach consensus as to content of
Appendix before it submitted to the AD for consideration,
it should be cleaned up now.

>>This section is essentially a changelog.
>
>Yes.

When I think of an I-D changelog, I think of a log of changes
between each revision of the I-D.  This is not that. 

>>Normally, such sections are intended for use during the development of a document, and carry a note to the RFC-Editor asking that they be removed prior to publication.

If this appendix were a log of changes between each revision of
the I-D, I would agree.  But this appendix is not that.  It is
summary of changes made to RFC 2222.

>>I think that would be the apporpriate thing to do in this case.
>
>I disagree. I find such section quite useful when one has to quickly find out about changes since an older RFC.

Yes.  The purpose of this section is to provide useful information
to the reader of the RFC regarding changes since RFC 2222.

Kurt

From: Hallvard B Furuseth <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Wed, 13 Oct 2004 17:34:07 +0200
Sender: [email-masked]

Jeffrey Hutzelman writes:
>On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth 
><[email-masked]> wrote:
>>But back to rfc2222bis:
>>
>>> There is no "official" standard KERBEROS_V5 mechanism.
>>
>> Then it seems strange to me to remove KERBEROS_V4 without further
>> comment when there is no standard replacement
>
> Note that there is a distinct difference between SASL mechanisms and
> the underlying authentication technology.  The SASL KERBEROS_V4
> mechanism is obsolete because the underlying technology is obsolete.
> It is worth noting that Kerberos V4 is not and never has been an IETF
> standard.
>
> If you want to use Kerberos V5 with SASL, the mechanism you are
> looking for is named 'GSSAPI'.  It is described in
> draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms
> based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI"
> refers specifically to GSS krb5).

OK.  Still, it might still be worth mentioning this the draft.  I expect
what you say is well known to someone who comes to SASL via Kerberos,
but it would not be known to someone (like me) who comes to Kerberos via
SASL.  OTOH, if such a brief sentence could not be sufficiently helpful
to a 'kerberos newbie' for there to be any point to it, forget it.

-- 
Hallvard

Date: Wed, 13 Oct 2004 11:19:04 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

> But back to rfc2222bis:
>
>> There is no "official" standard KERBEROS_V5 mechanism.
>
> Then it seems strange to me to remove KERBEROS_V4 without further
> comment when there is no standard replacement

Note that there is a distinct difference between SASL mechanisms and the 
underlying authentication technology.  The SASL KERBEROS_V4 mechanism is 
obsolete because the underlying technology is obsolete.  It is worth noting 
that Kerberos V4 is not and never has been an IETF standard.

If you want to use Kerberos V5 with SASL, the mechanism you are looking for 
is named 'GSSAPI'.  It is described in draft-ietf-sasl-gssapi-01, which 
defines a family of SASL mechanisms based on GSSAPI mechanisms (note that 
the SASL mechanism name "GSSAPI" refers specifically to GSS krb5).

By contrast, the KERBEROS_V4 mechanism was defined _in the SASL base 
document_, which is why it is mentioned in the changelog.

-- Jeff

From: Hallvard B Furuseth <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Wed, 13 Oct 2004 17:08:33 +0200
Sender: [email-masked]

Jeffrey Hutzelman writes:
>On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth 
><[email-masked]> wrote:
> 
>> (...internet-draft KERBEROS_V5...)
>>
>> When I'm
>> walking through standards and definitions of something I'm working with,
>> it's always annoying when there is suddenly no reference to where to go
>> from there.
> 
> It is not necessary, appropriate, or even possible for the SASL base 
> document to include an exhaustive list of SASL mechanisms.

You have lost the context.  I was talking about a reference - formal or
informal - in the IANA registry, not rfc2222bis.

But back to rfc2222bis:

> There is no "official" standard KERBEROS_V5 mechanism.

Then it seems strange to me to remove KERBEROS_V4 without further
comment when there is no standard replacement - in particular since SASL
was born around Kerberos and S/Key, according to the mailinglist
archive.  I suggest to add a purely informational sentence or two about
why this was done and that an informal Kerberos5 exists.  And if V4-
support was removed because of a security flaw in that version, warn
that one really shouldn't keep support for it.  (Maybe the same applies
to S/Key, but I know even less about that than about Kerberos.)

-- 
Hallvard

To: Jeffrey Hutzelman <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2004 10:42:38 -0400
Sender: [email-masked]

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman
    Jeffrey> <[email-masked]> wrote:

    >>  I'm not really sure it's OK for a protocol to use no
    >> stringprep profile at all.
    >> 
    >> Especially for an IETF protocol I'm not sure I can think of
    >> situations where the right technical solution would not involve
    >> stringprep of some kind.

    Jeffrey> What an application's SASL profile says about the form
    Jeffrey> and preparation of authorization names will always depend
    Jeffrey> on what the application protocol does in a broader sense.
    Jeffrey> For applications which use some sort of string for
    Jeffrey> identity and authorization, the SASL profile should
    Jeffrey> specify use of the same string, with the same behaviours
    Jeffrey> and semantics.  That means if the application does not
    Jeffrey> use stringprep on authorization ID's used, say, in
    Jeffrey> manipulating ACL's, then it should not use it on SASL
    Jeffrey> authorization ID's either.

    Jeffrey> Also, I can think of a scenario in which the right
    Jeffrey> solution does not involve any form of stringprep.
    Jeffrey> Consider an application which does identity and access
    Jeffrey> control using UUID's rather than strings.  I do not
    Jeffrey> believe there is anything in SASL that would prevent this
    Jeffrey> use.

True.  But what you can do is somewhat constrained by the IESG for
standards-track documents.  I believe that MAY use no stringprep is
technically true but is also too strong of a statement.

--Sam

Date: Wed, 13 Oct 2004 10:22:48 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

> If there is a standard or "official document" or something for a
> mechanism, RFC or not, my vote is to at least mention it.

In the case of KERBEROS_V5, there is not.  There may be an internet-draft, 
though I expect it has expired by now if Simon is not still actively 
working on the mechanism.  Internet-drafts are by their nature ephemeral 
and therefore do not make stable references.  Published RFC's may not 
contain references to internet-drafts.

>  When I'm
> walking through standards and definitions of something I'm working with,
> it's always annoying when there is suddenly no reference to where to go
> from there.

It is not necessary, appropriate, or even possible for the SASL base 
document to include an exhaustive list of SASL mechanisms.  This is hardly 
the first "framework" document to include support for multiple mechanisms, 
and the normal practice is to make reference to specific mechanisms only 
when they are REQUIRED or RECOMMENDED, or when such a reference is needed 
to illustrate a concept described in the framework.

It is worth noting that as with any "framework" defined by the IETF, there 
_is_ an exhaustive list of all mechanisms, which is maintained by the IANA. 
IANA registries generally include a pointer to a contact person and/or to a 
published specification, if there is one.

There is no "official" standard KERBEROS_V5 mechanism.  I refer you to the 
following paragraph, which appears as part of the boilerplate at the top of 
every internet-draft:

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet Drafts are draft documents valid for a maximum of
   six months.  Internet Drafts may be updated, replaced, or obsoleted
   by other documents at any time.  It is not appropriate to use
   Internet Drafts as reference material or to cite them other than as
   ``work in progress''.

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

Date: Wed, 13 Oct 2004 15:17:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> Hallvard B Furuseth wrote:
>>
>>> I think Appendix C (Changes since RFC 2222) includes an extract of
>>> changes between various rfc2222/rfc2222bis versions, rather than just
>>> changes since RFC 2222.
>>
>> That is correct.
>>
>> Question to the WG: should I clean up the Appendix C or should I wait
>> till the document is approved for publication?
>
> This section is essentially a changelog.

Yes.

> Normally, such sections are intended for use during the development of 
> a document, and carry a note to the RFC-Editor asking that they be 
> removed prior to publication.  I think that would be the apporpriate 
> thing to do in this case.

I disagree. I find such section quite useful when one has to quickly 
find out about changes since an older RFC.

Date: Wed, 13 Oct 2004 10:14:27 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

On Wednesday, October 13, 2004 11:27:36 +0100 Alexey Melnikov 
<[email-masked]> wrote:

>
> Hallvard B Furuseth wrote:
>
>> I think Appendix C (Changes since RFC 2222) includes an extract of
>> changes between various rfc2222/rfc2222bis versions, rather than just
>> changes since RFC 2222.
>>
> That is correct.
>
> Question to the WG: should I clean up the Appendix C or should I wait
> till the document is approved for publication?

This section is essentially a changelog.  Normally, such sections are 
intended for use during the development of a document, and carry a note to 
the RFC-Editor asking that they be removed prior to publication.  I think 
that would be the apporpriate thing to do in this case.

-- Jeff

Date: Wed, 13 Oct 2004 10:11:13 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman <[email-masked]> 
wrote:

>
> I'm not really sure it's OK for a protocol to use no stringprep
> profile at all.
>
> Especially for an IETF protocol I'm not sure I can think of situations
> where the right technical solution would not involve stringprep of
> some kind.

What an application's SASL profile says about the form and preparation of 
authorization names will always depend on what the application protocol 
does in a broader sense.  For applications which use some sort of string 
for identity and authorization, the SASL profile should specify use of the 
same string, with the same behaviours and semantics.  That means if the 
application does not use stringprep on authorization ID's used, say, in 
manipulating ACL's, then it should not use it on SASL authorization ID's 
either.

Also, I can think of a scenario in which the right solution does not 
involve any form of stringprep.  Consider an application which does 
identity and access control using UUID's rather than strings.  I do not 
believe there is anything in SASL that would prevent this use.

I agree that when applications use strings to identify users, they should 
use some form of stringprep.  I agree that in many such cases, it would be 
appropriate to use SASLprep rather than constructing a separate stringprep 
profile for that application.  However, mandating the use of stringprep in 
application protocols is out of scope for this working group, and I believe 
that it is more important that SASL authorization ID's have the same 
semantics as those used elsewhere in the application than that they have 
the same semantics as other strings used in SASL.

-- Jeff

Date: Wed, 13 Oct 2004 11:27:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis Appendix C
Sender: [email-masked]

Hallvard B Furuseth wrote:

>I think Appendix C (Changes since RFC 2222) includes an extract of
>changes between various rfc2222/rfc2222bis versions, rather than just
>changes since RFC 2222.
>
That is correct.

Question to the WG: should I clean up the Appendix C or should I wait 
till the document is approved for publication?

>[...]
>
>Another detail:
>
>   The "SKEY" mechanism described in RFC 2222 is obsolete and has been
>   removed.  It has been replaced by the OTP mechanism [SASL-OTP].
>
>This is the only mention of [SASL-OTP] outside of the References
>section.  Is that intentional?
>  
>
[SASL-OTP] is mentioned in 10.2 (Informative references).

Date: Wed, 13 Oct 2004 10:56:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

--------------000907060501040307020905
Content-type: text/plain; charset="us-ascii"

Hallvard B Furuseth wrote:

>>>>6.1.  Client sends data first
>>>>
>>>>   If the initial client response parameter is not given, or if a
>>>>   protocol's profile does not permit the command which initiates an
>>>>   authentication protocol exchange to contain an initial client
>>>>   response, then the server issues a challenge with no data.  The
>>>>   client's response to this challenge is then used as the initial
>>>>   client response.  (The server then proceeds to send the next
>>>>   challenge, indicates completion, or indicates failure.)
>>>>        
>>>>
>>>Then protocols that support an initial response must be clear on how to
>>>distinguish an absent initial response from a present but empty initial
>>>response.  I expect their protocol profiles must also specify whether or
>>>not the protocol _can_ distinguish the two, so the mechanism can tell
>>>whether or not to send empty initial responses.
>>>      
>>>
>> This is described in Section 4, bullet # 2.
>>    
>>
>
>No...  First, it's only a SHOULD:
>
>   If the protocol allows for the initial response, the protocol profile
>   SHOULD also describe how an empty initial response is encoded.
>  
>
I've already changed SHOULD to MUST. This issue was raised during WGLC.

>Second, if that sentence is intended to address this issue, I can think
>of two different things it can imply in order to do so.  It is not at
>all clear to me that it means either:
>
>1) "If the protocol profile does not say how an initial response is
>   encoded, then empty but present initial responses are not supported."
>  
>
>2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
>   MUST be possible to send an empty initial response which can be
>   distinguished from no initial response."
>  
>
The intention was to say #2. I am not aware of any protocol profile that 
supports initial response, but doesn't allow for it being empty.

>>>>7.    The EXTERNAL mechanism
>>>>
>>>>   The client sends a single message containing the UTF-8 encoding of
>>>>   the authorization identity. The message may be empty.
>>>>        
>>>>
>>>s/message/response/ the first time,
>>>s/message/authorization identity/ the second time?
>>>      
>>>
>> I actually prefer to keep the informal term message here.
>>    
>>
>
>Well, I'll see how empty initial responses turn out...
>  
>
>>>See my comments above about empty initial response.
>>>      
>>>
>>>>Appendix C. Changes since RFC 2222
>>>>
>>>>   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
>>>>   been removed.   
>>>>        
>>>>
>>>I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
>>>has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
>>>registration only lists a person (Simon Josefsson).  The same is true
>>>for some other mechanisms.  Why is that?
>>>      
>>>
>> There is no reference, because there is no RFC. I think one can ask IANA
>> to add one.
>>    
>>
>
>If there is a standard or "official document" or something for a
>mechanism, RFC or not, my vote is to at least mention it.  When I'm
>walking through standards and definitions of something I'm working with,
>it's always annoying when there is suddenly no reference to where to go
>from there.  As with Kerberos5, Googling around will often find
>competing texts that may or may not be or reflect the "official"
>standard.  Or I can ask (if I knows where), but then I have to sit and
>wait for someone to answer, and sometimes there is no telling how
>reliable the respondent is.
>  
>
For KERBEROS_V5 registration you need to send a email to Simon, he is 
the authoritative source of information. It would be even better if you 
ask him to update the registration.

Alexey

--------------000907060501040307020905
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hallvard B Furuseth wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">6.1.  Client sends data first

   If the initial client response parameter is not given, or if a
   protocol's profile does not permit the command which initiates an
   authentication protocol exchange to contain an initial client
   response, then the server issues a challenge with no data.  The
   client's response to this challenge is then used as the initial
   client response.  (The server then proceeds to send the next
   challenge, indicates completion, or indicates failure.)
        </pre>
      </blockquote>
      <pre wrap="">Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.
      </pre>
    </blockquote>
    <pre wrap=""> This is described in Section 4, bullet # 2.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.
  </pre>
</blockquote>
I've already changed SHOULD to MUST. This issue was raised during WGLC.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."
  </pre>
</blockquote>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">
2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."
  </pre>
</blockquote>
The intention was to say #2. I am not aware of any protocol profile
that supports initial response, but doesn't allow for it being empty.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">7.    The EXTERNAL mechanism

   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
        </pre>
      </blockquote>
      <pre wrap="">s/message/response/ the first time,
s/message/authorization identity/ the second time?
      </pre>
    </blockquote>
    <pre wrap=""> I actually prefer to keep the informal term message here.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, I'll see how empty initial responses turn out...
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">See my comments above about empty initial response.
      </pre>
    </blockquote>
  </blockquote>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Appendix C. Changes since RFC 2222

   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.   
        </pre>
      </blockquote>
      <pre wrap="">I just noticed that <a class="moz-txt-link-rfc2396E" href="http://www.iana.org/assignments/sasl-mechanisms">&lt;http://www.iana.org/assignments/sasl-mechanisms&gt;</a>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?
      </pre>
    </blockquote>
    <pre wrap=""> There is no reference, because there is no RFC. I think one can ask IANA
 to add one.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.
  </pre>
</blockquote>
For KERBEROS_V5 registration you need to send a email to Simon, he is
the authoritative source of information. It would be even better if you
ask him to update the registration.<br>
<br>
Alexey<br>
<br>
</body>
</html>

--------------000907060501040307020905--

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis Appendix C
Date: Wed, 13 Oct 2004 10:07:41 +0200
Sender: [email-masked]

I think Appendix C (Changes since RFC 2222) includes an extract of
changes between various rfc2222/rfc2222bis versions, rather than just
changes since RFC 2222.  Examples:

   Replaced UTF-8 ABNF with the reference to the UTF-8 document.

RFC 2222 did not refer to UTF-8 at all.  OTOH, the new UTF-8
MUST/SHOULDs in sections 3.2.2 and 5 are not mentioned.

   Replaced "buffers of security encoded data" with "buffers of
   protected data" for clarity.

That first phrase does not occur in rfc2222.

   Made requirement to verify that an authorization identity is correct
   by performing SASLprep a SHOULD, instead of a MUST.

rfc2222 does not contain a single MUST.  And if that SHOULD is the one
in rfc2222bis 3.2.1, then it is about verifying that ID's _form_ is
correct, not that the ID itself is correct.

Another detail:

   The "SKEY" mechanism described in RFC 2222 is obsolete and has been
   removed.  It has been replaced by the OTP mechanism [SASL-OTP].

This is the only mention of [SASL-OTP] outside of the References
section.  Is that intentional?

-- 
Hallvard

To: Hallvard B Furuseth <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 18:39:24 -0400
Sender: [email-masked]

I'm not really sure it's OK for a protocol to use no stringprep
profile at all.

Especially for an IETF protocol I'm not sure I can think of situations
where the right technical solution would not involve stringprep of
some kind.

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Tue, 12 Oct 2004 23:49:39 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>Jeffrey Hutzelman wrote:
>><[email-masked]> wrote:
>>>Hallvard B Furuseth wrote:
>>>
>>>>>   Profiles whose authorization identities are simple user names
>>>>>   (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile [SASLprep]
>>>>>   of the "stringprep" algorithm [StringPrep] to prepare these
>>>>>   names for matching. The profiles MAY use a stringprep profile
>>>>>   that is more strict than SASLprep.
>>>>
>>>> That uppercase "MAY" gives the impression that this is the only other
>>>> option:  It may not a more lax stringprep profile, or an entirely
>>>> different way to prepare.
>>>>
>>> This MAY is just fine according to [KEYWORDS] (RFC 2119).
>>> I am not sure how this can be improved.
>>>
>>> The reason for having the MAY is to emphasize that this is actually
>>> considered a reasonable thing to do.
>>
>> Try this:
>>
>> Profiles MAY use a stringprep profile other than SASLprep, or none at 
>> all.
> 
> I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep 
> + additional restrictions) is a common case.

Profiles whose (...) SHOULD use SASLPrep or a stricter stringprep
profile, but MAY use other stringprep profiles or none at all?

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Tue, 12 Oct 2004 23:39:08 +0200
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>> 3.    Authentication mechanisms   
>>>
>>>    sasl-mech    = 1*20mech-char
>>>    mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
>>>                   ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
>>>                   ; and "_" from ASCII character set.
>>
>> In most standards, tokens like sasl-mech cannot start with a hyphen;
>> often they must start with a letter.  Prevents problems e.g. with
>> programs that are overeager about extracting command line arguments, or
>> utilities which notice token-like strings in general without an exact
>> idea of what kind of token it is (e.g. click&cut&paste).  Is there any
>> reason sasl-mech is different?
>>
>  I see your point, but at this time I would rather not change this. Just
>  in case somebody has designed and deployed a mechanism that starts with
>  "_" or "-".

OK.

>>> 5.    Mechanism profile guidelines   
>>>
>>>    SASL mechanisms
>>>    must define which entity (or entities) must perform the preparation.
>>>    If preparation fails or results in an empty string, the entity doing
>>>    the preparation MUST fail the authentication exchange.
>>
>> I expect preparation of an empty string should not fail, so:
>> s/results in/turns a non-empty string into/.
>
>  This text is talking about authentication identities and passwords. I am
>  not sure whether the empty string should be allowed.

I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.

>>> 6.1.  Client sends data first
>>>
>>>    If the initial client response parameter is not given, or if a
>>>    protocol's profile does not permit the command which initiates an
>>>    authentication protocol exchange to contain an initial client
>>>    response, then the server issues a challenge with no data.  The
>>>    client's response to this challenge is then used as the initial
>>>    client response.  (The server then proceeds to send the next
>>>    challenge, indicates completion, or indicates failure.)
>>
>> Then protocols that support an initial response must be clear on how to
>> distinguish an absent initial response from a present but empty initial
>> response.  I expect their protocol profiles must also specify whether or
>> not the protocol _can_ distinguish the two, so the mechanism can tell
>> whether or not to send empty initial responses.
>>
>  This is described in Section 4, bullet # 2.

No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.

Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."

2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."

>>> 7.    The EXTERNAL mechanism
>>>
>>>    The client sends a single message containing the UTF-8 encoding of
>>>    the authorization identity. The message may be empty.
>>
>> s/message/response/ the first time,
>> s/message/authorization identity/ the second time?
>
>  I actually prefer to keep the informal term message here.

Well, I'll see how empty initial responses turn out...

>> See my comments above about empty initial response.

>>> Appendix C. Changes since RFC 2222
>>>
>>>    The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
>>>    been removed.   
>>
>> I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
>> has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
>> registration only lists a person (Simon Josefsson).  The same is true
>> for some other mechanisms.  Why is that?
>
>  There is no reference, because there is no RFC. I think one can ask IANA
>  to add one.

If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.

-- 
Hallvard

To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 14:17:58 -0400
Sender: [email-masked]

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey
    Jeffrey> Melnikov
    Jeffrey> <[email-masked]> wrote:

    >> Hallvard B Furuseth wrote:
    >>>> Profiles whose authorization identities are simple user names
    >>>> (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile
    >>>> [SASLprep] of the "stringprep" algorithm [StringPrep] to
    >>>> prepare these names for matching. The profiles MAY use a
    >>>> stringprep profile that is more strict than SASLprep.
    >>>> 
    >>>> 
    >>>  That uppercase "MAY" gives the impression that this is the
    >>> only other option: It may not a more lax stringprep profile,
    >>> or an entirely different way to prepare.
    >>> 
    >> This MAY is just fine according to [KEYWORDS] (RFC 2119).  I am
    >> not sure how this can be improved.
    >> 
    >> The reason for having the MAY is to emphasize that this is
    >> actually considered a reasonable thing to do.

    Jeffrey> Try this:

    Jeffrey> Profiles MAY use a stringprep profile other than
    Jeffrey> SASLprep, or none at all.

I prefer the text currently in the draft to your proposed text.

Date: Tue, 12 Oct 2004 18:39:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> Hallvard B Furuseth wrote:
>>
>>>>   Profiles whose
>>>>   authorization identities are simple user names (e.g. IMAP [RFC 
>>>> 3501])
>>>>   SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
>>>>   algorithm [StringPrep] to prepare these names for matching. The
>>>>   profiles MAY use a stringprep profile that is more strict than
>>>>   SASLprep.
>>>
>>>
>>> That uppercase "MAY" gives the impression that this is the only other
>>> option:  It may not a more lax stringprep profile, or an entirely
>>> different way to prepare.
>>>
>> This MAY is just fine according to [KEYWORDS] (RFC 2119).
>> I am not sure how this can be improved.
>>
>> The reason for having the MAY is to emphasize that this is actually
>> considered a reasonable thing to do.
>
> Try this:
>
> Profiles MAY use a stringprep profile other than SASLprep, or none at 
> all.

I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep 
+ additional restrictions) is a common case.

>>>> 6.2.  Server returns success with additional data
>>>>
>>>>   Client implementors should be aware of an additional failure case
>>>>   that might occur when the profile supports sending the additional
>>>>   data with success. Imagine that an active attacker is trying to
>>>>   impersonate the server and sends faked data, which should be used to
>>>>   authenticate the server to the client, with success.  (A similar
>>>>   situation can happen when either the server and/or the client has a
>>>>   bug and they calculate different responses.) After checking the 
>>>> data,
>>>>   the client will think that the authentication exchange has failed,
>>>>   however the server will think that the authentication exchange has
>>>>   completed successfully.  At this point the client can not abort the
>>>>   authentication exchange; it SHOULD close the connection instead.
>>>>   However, if the profile did not support sending of additional data
>>>>   with success, the client could have aborted the exchange at the very
>>>>   last step of the authentication exchange.
>>>
>>> I don't quite understand.  I would have thought that if an attacker can
>>> do that, he can also wait for the final client response and then start
>>> accessing the server, pretending to be the client.  Maybe that just
>>> shows my ignorance of the subject, but many other readers will be
>>> equally ignorant.
>>>
>> What you are saying might be true, but I don't think it is relevant for
>> the section you've quoted. By the time the server has sent a fake (or
>> wrong) "additional data with success", it is too late: the client has
>> already provided its credentials to the server.
>
> But the same is true even if you don't support "additional data with 
> success".  By the time the server sends the last data, the client has 
> _still_ already sent its credentials to the server.  In either case 
> the client cannot abort the exchange, because the MitM attacker simply 
> won't forward that part.

I agree with you.
The point of the paragraph is to say that with additional data with 
success the client is *not able* to abort SASL exchange, thus it has to 
disconnect.

Date: Tue, 12 Oct 2004 13:12:51 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

On Tuesday, October 12, 2004 16:52:10 +0100 Alexey Melnikov 
<[email-masked]> wrote:

> Hallvard B Furuseth wrote:
>
>>>   Profiles whose
>>>   authorization identities are simple user names (e.g. IMAP [RFC 3501])
>>>   SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
>>>   algorithm [StringPrep] to prepare these names for matching. The
>>>   profiles MAY use a stringprep profile that is more strict than
>>>   SASLprep.
>>>
>>>
>>
>> That uppercase "MAY" gives the impression that this is the only other
>> option:  It may not a more lax stringprep profile, or an entirely
>> different way to prepare.
>>
> This MAY is just fine according to [KEYWORDS] (RFC 2119).
> I am not sure how this can be improved.
>
> The reason for having the MAY is to emphasize that this is actually
> considered a reasonable thing to do.

Try this:

Profiles MAY use a stringprep profile other than SASLprep, or none at all.

>>> 6.2.  Server returns success with additional data
>>>
>>>
>>>   Client implementors should be aware of an additional failure case
>>>   that might occur when the profile supports sending the additional
>>>   data with success. Imagine that an active attacker is trying to
>>>   impersonate the server and sends faked data, which should be used to
>>>   authenticate the server to the client, with success.  (A similar
>>>   situation can happen when either the server and/or the client has a
>>>   bug and they calculate different responses.) After checking the data,
>>>   the client will think that the authentication exchange has failed,
>>>   however the server will think that the authentication exchange has
>>>   completed successfully.  At this point the client can not abort the
>>>   authentication exchange; it SHOULD close the connection instead.
>>>   However, if the profile did not support sending of additional data
>>>   with success, the client could have aborted the exchange at the very
>>>   last step of the authentication exchange.
>>>
>>>
>>
>> I don't quite understand.  I would have thought that if an attacker can
>> do that, he can also wait for the final client response and then start
>> accessing the server, pretending to be the client.  Maybe that just
>> shows my ignorance of the subject, but many other readers will be
>> equally ignorant.
>>
> What you are saying might be true, but I don't think it is relevant for
> the section you've quoted. By the time the server has sent a fake (or
> wrong) "additional data with success", it is too late: the client has
> already provided its credentials to the server.

But the same is true even if you don't support "additional data with 
success".  By the time the server sends the last data, the client has 
_still_ already sent its credentials to the server.  In either case the 
client cannot abort the exchange, because the MitM attacker simply won't 
forward that part.

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

Date: Tue, 12 Oct 2004 16:52:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

--------------040303010201000505010401
Content-type: text/plain; charset="us-ascii"

Hallvard B Furuseth wrote:

>>3.    Authentication mechanisms    
>>
>>   sasl-mech    = 1*20mech-char
>>   mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
>>                  ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
>>                  ; and "_" from ASCII character set.
>>    
>>
>
>In most standards, tokens like sasl-mech cannot start with a hyphen;
>often they must start with a letter.  Prevents problems e.g. with
>programs that are overeager about extracting command line arguments, or
>utilities which notice token-like strings in general without an exact
>idea of what kind of token it is (e.g. click&cut&paste).  Is there any
>reason sasl-mech is different?
>
I see your point, but at this time I would rather not change this. Just 
in case somebody has designed and deployed a mechanism that starts with 
"_" or "-".

>>4.    Protocol profile requirements
>>    
>>
>>   Note that an additional data with success can't be empty. 
>>
>
>I suggest
>  "Note that if additional data is sent with success, it can't be empty."
>to clarify that one can send success without additional data.  At least
>that's what I assume it means.  The sentence as quoted above confused
>me: I could see no reason why one must always send additional data with
>success:-)
>
Ok and fixed.

>>   Profiles whose
>>   authorization identities are simple user names (e.g. IMAP [RFC 3501])
>>   SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
>>   algorithm [StringPrep] to prepare these names for matching. The
>>   profiles MAY use a stringprep profile that is more strict than
>>   SASLprep.
>>    
>>
>
>That uppercase "MAY" gives the impression that this is the only other
>option:  It may not a more lax stringprep profile, or an entirely
>different way to prepare.
>
This MAY is just fine according to [KEYWORDS] (RFC 2119).
I am not sure how this can be improved.

The reason for having the MAY is to emphasize that this is actually 
considered a reasonable thing to do.

>>5.    Mechanism profile guidelines    
>>
>>   SASL mechanisms
>>   must define which entity (or entities) must perform the preparation.
>>   If preparation fails or results in an empty string, the entity doing
>>   the preparation MUST fail the authentication exchange.
>>    
>>
>
>I expect preparation of an empty string should not fail, so:
>s/results in/turns a non-empty string into/.
>  
>
This text is talking about authentication identities and passwords. I am 
not sure whether the empty string should be allowed.

>>6.1.  Client sends data first
>>    
>>
>>   If the initial client response parameter is not given, or if a
>>   protocol's profile does not permit the command which initiates an
>>   authentication protocol exchange to contain an initial client
>>   response, then the server issues a challenge with no data.  The
>>   client's response to this challenge is then used as the initial
>>   client response.  (The server then proceeds to send the next
>>   challenge, indicates completion, or indicates failure.)
>>    
>>
>
>Then protocols that support an initial response must be clear on how to
>distinguish an absent initial response from a present but empty initial
>response.  I expect their protocol profiles must also specify whether or
>not the protocol _can_ distinguish the two, so the mechanism can tell
>whether or not to send empty initial responses.
>
This is described in Section 4, bullet # 2.

>
>Protocol example: A line-oriented protocol similar to SMTP where the
>client sends commands with space-separated arguments, and servers strip
>trailing spaces from client command lines.
>
>Mechanism example: EXTERNAL with authorization ID = empty string.
>
>  
>
>>6.2.  Server returns success with additional data
>>    
>>
>>   Client implementors should be aware of an additional failure case
>>   that might occur when the profile supports sending the additional
>>   data with success. Imagine that an active attacker is trying to
>>   impersonate the server and sends faked data, which should be used to
>>   authenticate the server to the client, with success.  (A similar
>>   situation can happen when either the server and/or the client has a
>>   bug and they calculate different responses.) After checking the data,
>>   the client will think that the authentication exchange has failed,
>>   however the server will think that the authentication exchange has
>>   completed successfully.  At this point the client can not abort the
>>   authentication exchange; it SHOULD close the connection instead.
>>   However, if the profile did not support sending of additional data
>>   with success, the client could have aborted the exchange at the very
>>   last step of the authentication exchange.
>>    
>>
>
>I don't quite understand.  I would have thought that if an attacker can
>do that, he can also wait for the final client response and then start
>accessing the server, pretending to be the client.  Maybe that just
>shows my ignorance of the subject, but many other readers will be
>equally ignorant.
>
What you are saying might be true, but I don't think it is relevant for 
the section you've quoted. By the time the server has sent a fake (or 
wrong) "additional data with success", it is too late: the client has 
already provided its credentials to the server.

>>7.    The EXTERNAL mechanism
>>    
>>
>>   The client sends a single message containing the UTF-8 encoding of
>>   the authorization identity. The message may be empty.
>>    
>>
>
>s/message/response/ the first time,
>s/message/authorization identity/ the second time?
>  
>
I actually prefer to keep the informal term message here.

>See my comments above about empty initial response.
>  
>
>>Appendix C. Changes since RFC 2222
>>    
>>
>>   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
>>   been removed.    
>>
>
>I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
>has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
>registration only lists a person (Simon Josefsson).  The same is true
>for some other mechanisms.  Why is that?
>
There is no reference, because there is no RFC. I think one can ask IANA 
to add one.

Alexey

--------------040303010201000505010401
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
<title></title>
Hallvard B Furuseth wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">3.    Authentication mechanisms    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   sasl-mech    = 1*20mech-char
   mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
                  ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
                  ; and "_" from ASCII character set.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&amp;cut&amp;paste).  Is there any
reason sasl-mech is different?</pre>
</blockquote>
I see your point, but at this time I would rather not change this. Just
in case somebody has designed and deployed a mechanism that starts with
"_" or "-".
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">4.    Protocol profile requirements
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   Note that an additional data with success can't be empty. </pre>
  </blockquote>
  <pre wrap=""><!---->
I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)</pre>
</blockquote>
Ok and fixed.
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">   Profiles whose
   authorization identities are simple user names (e.g. IMAP [RFC 3501])
   SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
   algorithm [StringPrep] to prepare these names for matching. The
   profiles MAY use a stringprep profile that is more strict than
   SASLprep.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.</pre>
</blockquote>
This MAY is just fine according to [KEYWORDS] (RFC 2119).<br>
I am not sure how this can be improved.<br>
<br>
The reason for having the MAY is to emphasize that this is actually
considered a reasonable thing to do.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">5.    Mechanism profile guidelines    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   SASL mechanisms
   must define which entity (or entities) must perform the preparation.
   If preparation fails or results in an empty string, the entity doing
   the preparation MUST fail the authentication exchange.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.
  </pre>
</blockquote>
This text is talking about authentication identities and passwords. I
am not sure whether the empty string should be allowed.
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">6.1.  Client sends data first
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   If the initial client response parameter is not given, or if a
   protocol's profile does not permit the command which initiates an
   authentication protocol exchange to contain an initial client
   response, then the server issues a challenge with no data.  The
   client's response to this challenge is then used as the initial
   client response.  (The server then proceeds to send the next
   challenge, indicates completion, or indicates failure.)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.</pre>
</blockquote>
This is described in Section 4, bullet # 2.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

  </pre>
  <blockquote type="cite">
    <pre wrap="">6.2.  Server returns success with additional data
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   Client implementors should be aware of an additional failure case
   that might occur when the profile supports sending the additional
   data with success. Imagine that an active attacker is trying to
   impersonate the server and sends faked data, which should be used to
   authenticate the server to the client, with success.  (A similar
   situation can happen when either the server and/or the client has a
   bug and they calculate different responses.) After checking the data,
   the client will think that the authentication exchange has failed,
   however the server will think that the authentication exchange has
   completed successfully.  At this point the client can not abort the
   authentication exchange; it SHOULD close the connection instead.
   However, if the profile did not support sending of additional data
   with success, the client could have aborted the exchange at the very
   last step of the authentication exchange.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.</pre>
</blockquote>
What you are saying might be true, but I don't think it is relevant for
the section you've quoted. By the time the server has sent a fake (or
wrong) "additional data with success", it is too late: the client has
already provided its credentials to the server.
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">7.    The EXTERNAL mechanism
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   The client sends a single message containing the UTF-8 encoding of
   the authorization identity. The message may be empty.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
s/message/response/ the first time,
s/message/authorization identity/ the second time?
  </pre>
</blockquote>
I actually prefer to keep the informal term message here.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">See my comments above about empty initial response.
  </pre>
  <blockquote type="cite">
    <pre wrap="">Appendix C. Changes since RFC 2222
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">   The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
   been removed.    </pre>
  </blockquote>
  <pre wrap=""><!---->
I just noticed that <a
 class="moz-txt-link-rfc2396E"
 href="http://www.iana.org/assignments/sasl-mechanisms">&lt;http://www.iana.org/assignments/sasl-mechanisms&gt;</a>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?</pre>
</blockquote>
There is no reference, because there is no RFC. I think one can ask
IANA to add one.<br>
<br>
Alexey<br>
<br>
<blockquote cite="[email-masked]" type="cite"></blockquote>
</body>
</html>

--------------040303010201000505010401--

Date: Tue, 12 Oct 2004 14:30:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Making forward progress
Sender: [email-masked]

Sam Hartman wrote:

>I've seen no objections to Kurt's new summary of the identities issue
>nor to his proposed text for section 3.  I think we should move
>forward with that change.
>  
>
Sounds good.

>Alexey, how much help do you need dealing with implications of this
>change for the rest of the document?
>  
>
I will need somebody's help to review my changes once I am done.

>Also, are there any of Hallvard's comments that you have questions
>about or that you believe require more WG discussion?
>  
>
I haven't looked very attentively, but at this time I think most 
issues/questions are straightforward.

Let me cautiously promise to have another revision by October 25. 
Cautiously, because I need to submit 3 more documents in other WGs by 
the same date.

Alexey

To: [email-masked]
Subject: Making forward progress
From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 18:42:10 -0400
Sender: [email-masked]

I've seen no objections to Kurt's new summary of the identities issue
nor to his proposed text for section 3.  I think we should move
forward with that change.

Alexey, how much help do you need dealing with implications of this
change for the rest of the document?

Also, are there ny of Hallvard's comments that you have questions
about or that you believe require more WG discussion?

--Sam

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Tue, 5 Oct 2004 16:33:02 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote:
>>> Abstract
>>
>>>    The Simple Authentication and Security Layer (SASL) is a framework
>>>    for providing authentication and data security services in
>>>    connection-oriented protocols via replaceable
>>
>>authentication
> 
> The sentence might be more clear if worded:
>         The Simple Authentication and Security Layer (SASL) is
>         a framework for providing authentication and data security
>         services via replaceable mechanisms to connection-oriented
>         protocols.

I don't think so; it looks a little strange to have the 'to...' after
the 'via...'.  Maybe s/in/to/ would improve the original sentence.

I've asked a coworker what he thought the Abstract meant: He got it more
or less right, but was somewhat vague about it and thought it was a bit
hard to get.  He did not think my suggested extra words would make a
difference.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: rfc2222bis-08 comments
Date: Tue, 5 Oct 2004 14:59:27 +0200
Sender: [email-masked]

Fixes to my previous comments, and comments to the rest of the draft.

I wrote:
> Subject: rfc2222bis-08 comments

>> 3.2.  Authorization and authentication identities

>>    The processing model is as follows.  A server, upon completion of the
>>    authentication mechanism, uses the results produced by the
>>    authentication mechanism, the client-provided authorization identity
>>    value (which may be the empty string), and local policy information
>>    to derive an authorization identity.
> (...)
> Please clarify that the authorization ID is checked during the
> authentication (as section 3.2.1 says).  And local policy is used to
> either derive the authorization identity or check it.

Sorry, s/check(ed)/authorize(d)/ is probably better.

>>    Any normalization of the authentication identity is defined by a
>>    particular SASL mechanism, the protocol profile doesn't influence it.
>
> That's a bit misleading from the protocol's point of view.  From
> discussions elsewhere I gather the protocol may normalize the ID as it
> pleases for its own use, including when it locates the server-side
> secret matching the authentication ID, as long as this does not affect
> the ID which the authentication mechanism sees.

Or rather, the protocol or its implementation may do that.

>> 3.3.  Security layers

>>    Note that all SASL mechanisms that are unable to negotiate a security
>>    layer automatically select no security layer.
>
> Without checking up the 'selects no security layer' thread, I still
> can't tell if this says that such a mechanism cancels an old security
> layer or if it says that it doesn't affect it.  I'll check that later,
> unless someone replies first.

...and Section 6.3 clarified it, now that I have gotten that far.

================================================================

> 3.    Authentication mechanisms

>    sasl-mech    = 1*20mech-char
>    mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
>                   ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
>                   ; and "_" from ASCII character set.

In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&cut&paste).  Is there any
reason sasl-mech is different?

> 4.    Protocol profile requirements

>    Note that an additional data with success can't be empty.

I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)

>    Profiles whose
>    authorization identities are simple user names (e.g. IMAP [RFC 3501])
>    SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
>    algorithm [StringPrep] to prepare these names for matching. The
>    profiles MAY use a stringprep profile that is more strict than
>    SASLprep.

That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.

> 5.    Mechanism profile guidelines

>    SASL mechanisms
>    must define which entity (or entities) must perform the preparation.
>    If preparation fails or results in an empty string, the entity doing
>    the preparation MUST fail the authentication exchange.

I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.

> 6.1.  Client sends data first

>    If the initial client response parameter is not given, or if a
>    protocol's profile does not permit the command which initiates an
>    authentication protocol exchange to contain an initial client
>    response, then the server issues a challenge with no data.  The
>    client's response to this challenge is then used as the initial
>    client response.  (The server then proceeds to send the next
>    challenge, indicates completion, or indicates failure.)

Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

> 6.2.  Server returns success with additional data

>    Client implementors should be aware of an additional failure case
>    that might occur when the profile supports sending the additional
>    data with success. Imagine that an active attacker is trying to
>    impersonate the server and sends faked data, which should be used to
>    authenticate the server to the client, with success.  (A similar
>    situation can happen when either the server and/or the client has a
>    bug and they calculate different responses.) After checking the data,
>    the client will think that the authentication exchange has failed,
>    however the server will think that the authentication exchange has
>    completed successfully.  At this point the client can not abort the
>    authentication exchange; it SHOULD close the connection instead.
>    However, if the profile did not support sending of additional data
>    with success, the client could have aborted the exchange at the very
>    last step of the authentication exchange.

I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.

> 7.    The EXTERNAL mechanism

>    The client sends a single message containing the UTF-8 encoding of
>    the authorization identity. The message may be empty.

s/message/response/ the first time,
s/message/authorization identity/ the second time?
See my comments above about empty initial response.

> Appendix C. Changes since RFC 2222

>    The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
>    been removed.

I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?

-- 
Hallvard

Date: Sat, 02 Oct 2004 12:27:46 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:52 AM 10/2/2004, Sam Hartman wrote:

>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> be verified.  The precise form of the authorization identity
>    Kurt> is, excepting the Unicode restriction, is a application
>    Kurt> protocol detail.
>
>
>This isn't quite right.

By "form" above, I am referring to the shape of the Unicode
string and not the encoding of that Unicode string.  The shape
(Kerberos principal, LDAP DN, LDAP authzid, email address,
etc.) of the string is an application protocol matter, its
encoding (UTF-8, UTF-32, other) is a mechanism matter.

>The form of the requested authorization
>identity--the bits that are transferred over the wire--is a mechanism
>detail.  The protocol profile feeds in unicode codepoints and the
>mechanism decides how those codepoints will appear on the wire.  The
>semantics of these codepoints is what is a protocol detail.

To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: CRAMing for last call
From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:58:59 -0400
Sender: [email-masked]

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

    Lyndon> Finally, we need to address the issue of the MD5 "break."
    Lyndon> I have held off from commenting on this issue until the
    Lyndon> community has seen explicit evidence of the attack, and
    Lyndon> the implications of it. At this point, I don't know if the
    Lyndon> document deserves a writeup on the attack. Theory abounds,
    Lyndon> but I haven't yet seen a practical attack that works in
    Lyndon> the general case. We should at the least make mention of
    Lyndon> what has been discussed, and point to the literature, but
    Lyndon> I don't think the document deserves to discuss all the
    Lyndon> possible attacks. This doesn't mean to discourage anyone
    Lyndon> from contributing text to the Security Considerations
    Lyndon> section (please do).

The security area seems to believe that hmac-md5 is still OK, at least
for now.  Especially since cram-md5 does not require much structure
for the challenge, we should discuss the issue in the security
considerations section.

Will you need agenda time at the next meeting?  If so, can you give an
estimate of how much and what we want to cover?

Thanks,

--Sam

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Identity terminology in 2222bis
From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:52:58 -0400
Sender: [email-masked]

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

    Kurt> be verified.  The precise form of the authorization identity
    Kurt> is, excepting the Unicode restriction, is a application
    Kurt> protocol detail.

This isn't quite right.  The form of the requested authorization
identity--the bits that are transferred over the wire--is a mechanism
detail.  The protocol profile feeds in unicode codepoints and the
mechanism decides how those codepoints will appear on the wire.  The
semantics of these codepoints is what is a protocol detail.

--Sam

Date: Fri, 01 Oct 2004 22:02:54 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: CRAMing for last call
Sender: [email-masked]

Now that 2222bis is close to reality, I would like to push the final 
version of CRAM out as well. The two documents should be able to go 
through together, (I hope) making life easier for the RFC editor.

I have some non-substantive editorial changes that will make the 
document a bit easier to read, but these are not show stoppers. I think 
all of the last round of comments are addressed in the current draft. 
If not, I would like to hear from people, soon.

I would also like to solicit a few additional examples from anyone who 
has implemented CRAM in other than IMAP.

Finally, we need to address the issue of the MD5 "break." I have held 
off from commenting on this issue until the community has seen explicit 
evidence of the attack, and the implications of it. At this point, I 
don't know if the document deserves a writeup on the attack. Theory 
abounds, but I haven't yet seen a practical attack that works in the 
general case. We should at the least make mention of what has been 
discussed, and point to the literature, but I don't think the document 
deserves to discuss all the possible attacks. This doesn't mean to 
discourage anyone from contributing text to the Security Considerations 
section (please do).

The IMAP-EXT list has had recent discussion that points out the 
ambiguity of searching for the space (SP) separator (between the user 
id and the digest) as being the rightmost SP, so I will strengthen that 
text. Any other comments should come forth soon as I would like to run 
out the final draft at the end of next week (Oct. 8) if I can.

Cheers,

--lyndon (editor)

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400
Sender: [email-masked]

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

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

    >> While SASL mechanisms specify the form of credentials used to
    >> authenticating users and SASL application profiles specify the
    >> form of authorization identities transferred as part of
    >> authentication exchange, the precise form(s) of the
    >> authentication identities (used within the server in its
    >> verifications, or otherwise) and the precise form(s) of the
    >> authorization identities (used in making authorization
    >> decisions, or otherwise) is beyond the scope of the SASL and
    >> this specification.

    Simon> I'm worried by how this new text interact with string
    Simon> normalization like SASLPrep.  To me, it sounds as if the
    Simon> above leave the precise form of
    Simon> authentication/authorization identities up to either, or
    Simon> both, of application profiles and mechanisms.  Is that a
    Simon> correct interpretation?

The consensus of this working group is that the mechanism must
transport the requested authorization identity so that all unicode
code points are preserved.  I.E. the mechanism can use any bijective
transformation it desires; transforms like utf8-encode are assumed to
be bijective on the set of unicode code points.

Trying to be a bit more clear, mechanisms choose the encoding, but
must preserve the unicode code points given to them by the protocol.

The authentication identity is completely a matter for the mechanism;
it may (and often should) normalize it.

The normalization and interpretation of the requested authorization
identity is a protocol matter.

--Sam

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Date: Sat, 02 Oct 2004 01:25:32 +0200
Lines: 13
Cancel-Lock: sha1:/v3LJ3jCN8CLzghBvWRYkQ2Kb+0=
Sender: [email-masked]

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

> Simon,
>
> Note that the text I offer is not a direct replacement for
> Section 3.2.  Additional work, including moving key
> imperatives from the existing 3.2 to other sections, would
> have to be undertaken.

OK, I must have misread your initial post then.

Thanks,
Simon

Date: Fri, 01 Oct 2004 16:12:05 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Cc: [email-masked]
Sender: [email-masked]

Simon,

Note that the text I offer is not a direct replacement for
Section 3.2.  Additional work, including moving key
imperatives from the existing 3.2 to other sections, would
have to be undertaken.

At 02:05 PM 10/1/2004, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> While SASL mechanisms specify the form of credentials
>> used to authenticating users and SASL application
>> profiles specify the form of authorization identities
>> transferred as part of authentication exchange, the
>> precise form(s) of the authentication identities (used
>> within the server in its verifications, or otherwise)
>> and the precise form(s) of the authorization identities
>> (used in making authorization decisions, or otherwise) is
>> beyond the scope of the SASL and this specification.

This may need some slight rewording.  The intent is for
the mechanism specification to detail how to verify
the credentials and for the application protocol profile
to specify the precise form of the authorization identity
(within the Unicode restrict) but to make it clear that
there are many uses of these identities which SASL simply
doesn't not control.

>I'm worried by how this new text interact with string normalization
>like SASLPrep.

I presume the existing recommendations here will remain.

>To me, it sounds as if the above leave the precise
>form of authentication/authorization identities up to either, or both,
>of application profiles and mechanisms.

The precise form of the credentials is a mechanism detail.
The mechanism generally details how the credentials are to
be verified.  The precise form of the authorization
identity is, excepting the Unicode restriction, is a
application protocol detail.

Other uses of identities are outside the scope of SASL.

>For comparison, here is part of the old text:
>
>   Any normalization of the authentication identity is defined by a
>   particular SASL mechanism, the protocol profile doesn't influence it.

Though I think this needs to be slightly reworded, I agree
with the intent of the statement to say that protocol
profiles should leave of aspects of credentials and their
verification to the mechanism.  However, this in no way
implies that an application protocol specification, or
its implementations, cannot detail the form of authentication
identity the application protocol (or implementation) might
use otherwise.  For instance, an application protocol
specification could detail how to represent authentication
identities in an identity assumption authorization policy.

>   The mechanism MUST preserve Unicode codepoint when transferring
>   authorization identity (e.g. the mechanism cann't apply any form of
>   normalization).
>
>Read in contrast to each other, this seem like a major design change.
>
>Instead, I propose to clarify the terminology.

I think you propose a major design change.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Date: Sat, 02 Oct 2004 00:58:33 +0200
Lines: 27
Cancel-Lock: sha1:TTdNN5xkyEqxgQU8B6PSnsAdaIk=
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> The consensus of this working group is that the mechanism must
> transport the requested authorization identity so that all unicode
> code points are preserved.

Then I propose to keep the following in section 3.2:

   The mechanism MUST preserve Unicode codepoint when transferring
   authorization identity (e.g. the mechanism cann't apply any form of
   normalization).

Otherwise, I cannot find any normative text reflecting the consensus.

> The authentication identity is completely a matter for the mechanism;
> it may (and often should) normalize it.

Then I propose to keep the following in section 3.2:

   Any normalization of the authentication identity is defined by a
   particular SASL mechanism, the protocol profile doesn't influence it.

Kurt D. Zeilenga proposed to remove both paragraphs, if I understood
him correctly.

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Identity terminology in 2222bis
From: Sam Hartman <[email-masked]>
Date: Fri, 01 Oct 2004 18:38:33 -0400
Sender: [email-masked]

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

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

    >> While SASL mechanisms specify the form of credentials used to
    >> authenticating users and SASL application profiles specify the
    >> form of authorization identities transferred as part of
    >> authentication exchange, the precise form(s) of the
    >> authentication identities (used within the server in its
    >> verifications, or otherwise) and the precise form(s) of the
    >> authorization identities (used in making authorization
    >> decisions, or otherwise) is beyond the scope of the SASL and
    >> this specification.

    Simon> I'm worried by how this new text interact with string
    Simon> normalization like SASLPrep.  To me, it sounds as if the
    Simon> above leave the precise form of
    Simon> authentication/authorization identities up to either, or
    Simon> both, of application profiles and mechanisms.  Is that a
    Simon> correct interpretation?

The consensus of this working group is that the mechanism must
transport the requested authorization identity so that all unicode
code points are preserved.  I.E. the mechanism can use any bijective
transformation it desires; transforms like utf8-encode are assumed to
be bijective on the set of unicode code points.

Trying to be a bit more clear, mechanisms choose the encoding, but
must preserve the unicode code points given to them by the protocol.

The authentication identity is completely a matter for the mechanism;
it may (and often should) normalize it.

The normalization and interpretation of the requested authorization
identity is a protocol matter.

--Sam

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Identity terminology in 2222bis
Date: Fri, 01 Oct 2004 23:05:31 +0200
Lines: 46
Cancel-Lock: sha1:pqbbMshAe7vTm5P+HVrgAxdOyMk=
Sender: [email-masked]

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

> While SASL mechanisms specify the form of credentials
> used to authenticating users and SASL application
> profiles specify the form of authorization identities
> transferred as part of authentication exchange, the
> precise form(s) of the authentication identities (used
> within the server in its verifications, or otherwise)
> and the precise form(s) of the authorization identities
> (used in making authorization decisions, or otherwise) is
> beyond the scope of the SASL and this specification.

I'm worried by how this new text interact with string normalization
like SASLPrep.  To me, it sounds as if the above leave the precise
form of authentication/authorization identities up to either, or both,
of application profiles and mechanisms.  Is that a correct
interpretation?

If so, the new text would appear to permit, e.g., mechanisms to
perform SASLPrep on the authorization identity.  And to permit
application profiles to apply perform SASLPrep on the authentication
identity.  Here, SASLPrep could even be some other function, like
Unicode NFKC, or SASLPrep2, or some proprietary normalization
procedure.

For comparison, here is part of the old text:

   Any normalization of the authentication identity is defined by a
   particular SASL mechanism, the protocol profile doesn't influence it.

   The mechanism MUST preserve Unicode codepoint when transferring
   authorization identity (e.g. the mechanism cann't apply any form of
   normalization).

Read in contrast to each other, this seem like a major design change.

Instead, I propose to clarify the terminology.  Further, the
requirements on application profile and mechanisms should be
specified, and not left "beyond the scope of 2222bis".  One concrete
approach is to require that, for IETF application profiles and
mechanisms, both authentication and authorization identities MUST be
SASLPrep strings, and that the SASL library, the application profile,
and the mechanism may all perform SASLPrep on the identities.

Thanks,
Simon

Date: Fri, 01 Oct 2004 11:23:07 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis-08 comments
Cc: [email-masked]
Sender: [email-masked]

I have a few (initial) comments to inject here and there.

At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote:
>> Abstract
>
>>    The Simple Authentication and Security Layer (SASL) is a framework
>>    for providing authentication and data security services in
>>    connection-oriented protocols via replaceable
>
>authentication

The sentence might be more clear if worded:
        The Simple Authentication and Security Layer (SASL) is
        a framework for providing authentication and data security
        services via replaceable mechanisms to connection-oriented
        protocols.

>[nothing in the abstract says that's the kind of mechanisms it is
>talking about.]

Mechanisms provide authentication and data security services
to connection-oriented protocols through the SASL framework.

>>    mechanisms.  It
>>    provides structured interface between protocols and
>
>such SASL
>
>>    mechanisms.

I think its clear that both "protocols" and "mechanisms"
refer to those protocols and mechanisms which are utilizing
the SASL framework.  I don't think either needs to be
qualified here.  It would seem odd to qualify one and not
the other.  And as this is the Abstract, we should avoid
being too wordy.

>Or maybe "...and mechanisms that adhere to SASL", but that's probably
>more wordy than necessary.

First, you'd have to say s/SASL/SASL technical specification/.
But, yes, too wordy.

>The same change would be nice in the Introduction section, though of
>course the diagram there helps.
>
>Personally I would also have found an asymmetric definition easier to
>relate to: SASL defines a common interface to authentication mechanisms
>for protocols.  (Is that the right way to put it?)  But maybe that's not
>at all the view SASL intends to convey.  Is the protocol profile the
>common interface to protocols for authentication mechanisms?

The "protocol profile" is the part of the protocol's
technical specification which details how it makes use
of the SASL framework.

>> 2.    Introduction
>
>>    The implementors will also need to understand a
>>    specification of a
>
>SASL
>
>>    profile specific to the protocol,
>
>> 3.1.  Authentication protocol exchange
>
>This phrase looks to me like it is about an authentication protocol -
>i.e. part of SASL - and not the protocol which uses SASL.
>I don't see anything in the following section to correct that notion.

I think the word "protocol' here should be dropped here
and elsewhere where we're referring to the mechanism
exchange.

>Also,
>
>>    A SASL mechanism is responsible for conducting an authentication
>>    protocol exchange.
>
>I don't think so.  It's the protocol which conducts the _exchange_,
>and (below) which transmits anything.
>
>>    During the authentication protocol exchange, the mechanism performs
>
>I suggest s/performs/can perform/, since not all of them need be done.
>
>>    authentication, transmits an authorization identity (frequently known
>>    as a userid) from the client to server,
>
>This sounds like the authorization identity is independent of the
>authentication.  See below.
>
>> 3.2.  Authorization and authentication identities

There was some discussion in this area during WGLC.  That
discussion was recently re-opened.  I suggest you read
my latest post in this area as well as the WGLC thread.

>> 3.2.2.  Authorization Identity Format
>
>>    An authorization identity is a string of zero or more Unicode
>>    [Unicode] coded characters.  The NUL <U+0000> character is not
>>    permitted in authorization identities.
>
>But a NUL octet in a multibyte character is OK?

This sentence refers only to specific character, not
octets belonging to an encoding of other characters.

Date: Fri, 01 Oct 2004 11:21:13 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Identity terminology in 2222bis
Sender: [email-masked]

Historically, there was a bit of hand waving in regards
to identities.  In trying to nail down what identities
are involved in the SASL framework, where each identity
comes from and what are they used for, we ended up with
3 identities:
 - the "authentication identity" to refer to the
   identity associated with the users credentials,
 - the "requested identity" to refer to identity which
   the user requests to act as, and
 - "authorization identity" to refer to identity
   used by the server in making authorization decisions.
   (The latter being derived from by former two.)

However, we now face is that what we've historically
called an authorization identity is not the precise
identity used in making authorization decisions.

The amount of 2222bis editing to implement the WGLC
conclusion is actually minor in comparison to the
impact upon other documents, including most mechanism
specifications and application profiles.  If it was
only 2222bis, I'd be inclined to just bit the
bullet and make the terminology changes.  But given
the broader impact this terminology change would have,
we need to consider other approaches to resolving our
terminology woes.

In particular, I think this can be done by separating
how identities are used conceptually from how they
are used in practice and, in particular, their form.

Below is a 3.2 rewrite which, I think, demonstrates
how we can avoid the terminology problem.  I do think
other portions need work as well, but this should give
you reasonable idea of the approach I suggest we take.

Comments?

-- Kurt (as an individual contributor)

3.2 Identity Concepts

Conceptually, SASL framework involves two identities:
	1) an identity associated with the authentication
	credentials (termed the authentication identity), and
	2) an identity to act as (termed the authorization
	identity).

The client provides its credentials and, optionally, a
string representing the requested authorization identity
as part of the SASL exchange.  When this string is not
provided, the client is requesting to act as the identity
associated with the credentials (e.g., the user is
requesting to act as the authentication identity).

The server is responsible for verifying the user's
credentials and verifying that the user is able to
act as the authorization identity.  A SASL exchange
is successful if and only if both of these verifications
are successful.

While SASL mechanisms specify the form of credentials
used to authenticating users and SASL application
profiles specify the form of authorization identities
transferred as part of authentication exchange, the
precise form(s) of the authentication identities (used
within the server in its verifications, or otherwise)
and the precise form(s) of the authorization identities
(used in making authorization decisions, or otherwise) is
beyond the scope of the SASL and this specification.  In
some circumstances, the precise identity forms used
outside of the SASL exchange may be dictated by other
specifications.  For instance, the authorization policy
specification for an application protocol may dictate the
precise form that an authorization identity is to be
represented in the authorization policy.

Date: Fri, 01 Oct 2004 09:14:18 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Reconsideration Identity And Authorization Issue (Was: Summary of 2222bis WGLC)
Sender: [email-masked]

At 12:40 PM 9/24/2004, Kurt D. Zeilenga wrote:
>5) Identities and Authorization
>
>Kurt indicated that the I-D use of term "authorization
>identity" is confusing and suggested use of different
>terms for each distinct use of this term.  Jeffery
>suggested using the terms:
>        "authentication identity" to refer to the
>        identity associated with the users creditials,
>        "requested identity" to refer to identity
>        which the user requests to act as, and
>        "authorization identity" to refer to identity
>        used by the server in making authorization
>        decisions.  (The latter being derived from
>        by former two.)
>
>The chairs conclude the WG supports use of this
>suggested terminology.

After some lengthy discussions between the Sam, Alexey,
and I (with and without our respective chair/editor
hats), the chairs have decided to vacate their conclusion
regarding this issue and re-open discussion in this
area.  This post will be followed by a messaging
summarizing problems with above terminology choice and
offering a way to resolve the underlying terminology
problem.

Kurt, as SASL co-chair 

Date: Fri, 01 Oct 2004 07:39:20 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis-08 comments
Sender: [email-masked]

At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote:
>These are rather rather hurried comments, since Kurt said reviews are
>needed but soon.

Thanks for responding to my late request for review!

To the WG,  Sam and I have some concerns regarding the depth
and breadth of the WG review of this I-D.  The chairs continue
to actively seek additional review. 

Kurt

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis-08 comments
Date: Fri, 1 Oct 2004 15:59:44 +0200
Sender: [email-masked]

These are rather rather hurried comments, since Kurt said reviews are
needed but soon.  So I have only made a cursory check if these issues
have been discussed before; I don't know how much they would have been
delayed if I were to check properly.  Sorry about that.

> Abstract

I had trouble getting into SASL the first time I read the draft - mostly
things that did not make sense to me at first, only when I got to a
closer explanation later in the draft.  I'm beginning to figure out why
now, though I'm guessing a bit about what it was I didn't get.  Starting
with the Abstract: I didn't get that at all, though I don't really see
why, given the second paragraph.  "So I have a protocol here, and an
authentication mechanism there, and somehow if I include SASL, the two
will be able to talk to each other.  Um...?"  It's better now, but I
still suggest:

>    The Simple Authentication and Security Layer (SASL) is a framework
>    for providing authentication and data security services in
>    connection-oriented protocols via replaceable

authentication

[nothing in the abstract says that's the kind of mechanisms it is
talking about.]

>    mechanisms.  It
>    provides structured interface between protocols and

such SASL

>    mechanisms.

Or maybe "...and mechanisms that adhere to SASL", but that's probably
more wordy than necessary.

The same change would be nice in the Introduction section, though of
course the diagram there helps.

Personally I would also have found an asymmetric definition easier to
relate to: SASL defines a common interface to authentication mechanisms
for protocols.  (Is that the right way to put it?)  But maybe that's not
at all the view SASL intends to convey.  Is the protocol profile the
common interface to protocols for authentication mechanisms?

> 2.    Introduction

>    The implementors will also need to understand a
>    specification of a

SASL

>    profile specific to the protocol,

> 3.1.  Authentication protocol exchange

This phrase looks to me like it is about an authentication protocol -
i.e. part of SASL - and not the protocol which uses SASL.  I don't see
anything in the following section to correct that notion.

Also,

>    A SASL mechanism is responsible for conducting an authentication
>    protocol exchange.

I don't think so.  It's the protocol which conducts the _exchange_,
and (below) which transmits anything.

>    During the authentication protocol exchange, the mechanism performs

I suggest s/performs/can perform/, since not all of them need be done.

>    authentication, transmits an authorization identity (frequently known
>    as a userid) from the client to server,

This sounds like the authorization identity is independent of the
authentication.  See below.

> 3.2.  Authorization and authentication identities

>    The processing model is as follows.  A server, upon completion of the
>    authentication mechanism, uses the results produced by the
>    authentication mechanism, the client-provided authorization identity
>    value (which may be the empty string), and local policy information
>    to derive an authorization identity.

As above.  As described, the authorization ID appears not to be part of
the 'results produced by the authentication mechanism', only something
which is grabbed after completion of the authentication.  When I first
read about this, I was left wondering when the server checks if the
authentication ID has the authorization ID's access.  Each time one
tries to access something after the authentication?

Please clarify that the authorization ID is checked during the
authentication (as section 3.2.1 says).  And local policy is used to
either derive the authorization identity or check it.  But it looks a
little strange to use that local policy during the exchange if the user
provides it, but after the exchange if it is derived.  Should both be
done during the exchange instead?

>    The authorization identity may be an empty (zero length) string.  In
>    this case, the server derives an authorization identity from the
>    client's authentication identity.

I wonder a little why the authorization ID is explicitly said to be
provided by the client, when the authentication ID is not.

>    Any normalization of the authentication identity is defined by a
>    particular SASL mechanism, the protocol profile doesn't influence it.

That's a bit misleading from the protocol's point of view.  From
discussions elsewhere I gather the protocol may normalize the ID as it
pleases for its own use, including when it locates the server-side
secret matching the authentication ID, as long as this does not affect
the ID which the authentication mechanism sees.

>    The mechanism MUST preserve Unicode codepoint when transferring
>    authorization identity (e.g. the mechanism cann't apply any form of
>    normalization).

The () part does not seem say the same as the preceding sentence: 'when
transferring...' sounds like only the client-side part of the mechanism
must preserve the ID, while the () sounds like the server side also must
preserve it.

> 3.2.1.  Authorization identities and proxy authentication

>    The server SHOULD verify that a received authorization identity is in
>    the correct form. Protocol profiles whose authorization identities
>    are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
>    profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
>    prepare these names for matching. The profiles MAY use a stringprep
>    profile that is more strict than "SASLprep". If the preparation of
>    the authorization identity fails or results in an empty string, the
>    server MUST fail the authentication exchange. The only exception to
>    this rule is when the received authorization identity is already the
>    empty string.

In that case there can be authorization IDs which one can only get by
sending an empty authorization ID: IDs that are derived from the
authentication ID but would be invalid if specified explicitly.
Seems strange.

> 3.2.2.  Authorization Identity Format

>    An authorization identity is a string of zero or more Unicode
>    [Unicode] coded characters.  The NUL <U+0000> character is not
>    permitted in authorization identities.

But a NUL octet in a multibyte character is OK?
(Does not apply to UTF-8, of course.)

> 3.3.  Security layers

>    The security layer takes effect
>    immediately following the last response of the authentication
>    exchange for data sent by the client and the completion indication
>    for data sent by the server. The exact position MUST be defined by
>    the protocol profile (see section 4 part 5).

When does it stop having effect, if the protocol supports multiple
authentication?

>    Note that all SASL mechanisms that are unable to negotiate a security
>    layer automatically select no security layer.

Without checking up the 'selects no security layer' thread, I still
can't tell if this says that such a mechanism cancels an old security
layer or if it says that it doesn't affect it.  I'll check that later,
unless someone replies first.

-- 
Hallvard