Subject: rfc2222bis: authentication identity

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 16:47:38 +0200

I sent this message in April, but received no reply and forgot about it.
And now I discovered that I was no longer subscribed to ietf-sasl:-(

  rfc2222bis has added the concept of an authentication identity since
  rfc2222.  Is this identity only a parameter to the SASL authentication
  process, and can be discarded after SASL authentication is complete?
  Or is it also part of the connecton's authorization state after SASL
  authentication?  If so, what for?

  Could you clarify that in the draft?

Is this too late now?  If so, can someone explain anyway?
(I'm wondering if I should suggest that the LDAP authmeth draft removes
the authentication ID from the association (session state), or if it
should mention what it can be used for.)

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 12:59:44 +0200

Hallvard B Furuseth writes:
> (...)

Never mind - I was mixing up which concepts belong in SASL and which
ones belong in protocols using SASL.  Alexey set me straight.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 12:59:44 +0200

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: rfc2222bis: authentication identity
Date: Tue, 28 Sep 2004 12:59:44 +0200
Sender: [email-masked]

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: authentication identity
Date: Mon, 27 Sep 2004 16:47:38 +0200
Sender: [email-masked]

-- 
Hallvard

Date: Fri, 24 Sep 2004 12:40:30 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Summary of 2222bis WGLC
Sender: [email-masked]

The chairs initiated a SASL Working Group Last Call on the
document:

  Title: Simple Authentication and Security Layer (SASL)
  Editor: A. Melnikov
  Filename: draft-ietf-sasl-rfc2222bis-08.txt

on 21 July 2004.  The last call period, though originally
scheduled to close 13 August 2004, was extended to allow
additional review and discussion.  All comments received
prior to the posting of this summary were considered.
The last call period is now closed.

ISSUE SUMMARY

Below is a summary of the issues of substance raised. For
each, the chairs provide a statement of regarding the
actions it believes are/aren't supported by WG consensus.
Additionally, a number of editorial issues were raised
and referred to the Editor for appropriate action.

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.

The chairs believes the WG supports addition of this text.

2) Detail Hiding

Sam indicated the I-D claims that the layer does not generally
hide the details of mechanisms from protocols and suggested
this was an accurate reflection of what the WG intended to
state.  He suggested the I-D to be revised to state that
while the layer hides the details of protocols from mechanisms
and the details of mechanisms from protocols, it does not hide
the details of mechanisms from protocol implementations.

The chairs conclude the WG supports revising the I-D as
Sam suggests here.

3) Confidentiality and Integrity

Sam indicated that the I-D states "confidentiality protection
usually implies integrity protection" and that this was less than
ideal from a security standard point.  He suggested that the
word 'usually' be deleted.  Nico suggested revising the
specification to explicitly require future mechanisms which
provide a confidentiality protection service to provide include
integrity protection with that service.

The chairs conclude the WG supports revising the I-D as Sam
suggests here.

The chairs conclude that the WG supports allowing mechanisms to
"offer other kinds of security services" and hence does not
adding the requirement upon future mechanisms suggested by Nico.

4) Channel Binding

Nico asked whether the I-D should include text regarding
channel binding issues.  He suggest security consideration
text that clients using SASL over TLS should verify
the server's TLS identity to prevent MITM attacks.
He also suggested adding text encouraging future
mechanisms support channel bindings.

The chairs conclude that the WG supports the former
suggestion but not the latter.

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.

6) Empty initial response I

Ken suggested that the SHOULD in "the protocol profile
SHOULD also describe how an empty initial response is
encoded" ought to be a MUST.

The chairs conclude the WG supports this change.

7) Empty initial response II

Ken asked whether the I-D should explicitly state that
the profile also needs to describe how *empty* server
challenges and client responses as encoded.  Alexey
respond as to why he believes the I-D is sufficiently
clear here.

The chairs that the WG supports making no change here.

8) EXTERNAL use of external information

Ken suggested replacing "authenticate as" in the I-D text:
  The server uses information, external to SASL, to
  determine whether the client is permitted to authenticate
  as the authorization identity.
with "have the access privileges of".  Alexey suggested
it be replaced with "to act as".

The chairs conclude the WG supports this the change
suggested by Alexey. 

GENERAL CONCLUSION and NEXT STEPS

The chairs believe that WG consensus supports a recommendation
of this I-D, once the above issues are appropriate addressed,
to the IESG for publication as a Proposed Standard replacing
RFC 2222.  The chairs believes its above conclusions regarding
supported actions accurately reflect WG consensus and hence
direct the Editor to prepare a revision making the changes
for which chairs have indicated are supported by the WG.

The chairs believes its above conclusions regarding supported
actions accurately reflect WG consensus.  If you believe the
chairs have misread consensus, please indicate so by email
as soon as possible.  If you believe the above summary is
incomplete, please indicate by email as soon as possible.

After giving the WG sufficient time (1 week) to verify that
the actually changes made are consistent with WG consensus,
the chairs intend to recommend the revised I-D to the IESG
for consideration as a Proposed Standard.  The chairs do
not foresee the need to subject this I-D to another WG
Last Call.

Kurt & Sam, SASL co-chairs 

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sasl mailing list <[email-masked]>, sasl chair <[email-masked]>, sasl  chair <[email-masked]>
Subject: Protocol Action: 'SASLprep: Stringprep profile for user names  and passwords' to Proposed Standard 
Date: Fri, 24 Sep 2004 11:58:47 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'SASLprep: Stringprep profile for user names and passwords '
   <draft-ietf-sasl-saslprep-10.txt> as a Proposed Standard

This document is the product of the Simple Authentication and Security Layer 
Working Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document describes the preparation of Unicode strings
  representing user names and passwords for comparison.  The document
  defines the "SASLprep" profile of the "stringprep" algorithm to be
  used for both user names and passwords.  This profile is intended to
  be used by Simple Authentication and Security Layer (SASL) mechanisms
  (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols
  exchanging user names or passwords.

Working Group Summary

  The SASL Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

Date: Fri, 10 Sep 2004 11:47:15 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: identities and authorization
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:08 AM 9/10/2004, Jeffrey Hutzelman wrote:
>On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" <[email-masked]> wrote:
>
>>(Below I am going to refer to the identity used in making
>>authorization decisions as the subject identity.)
>
>Maybe it would be best if we avoided the term "authorization identity" at all.  Or maybe not.

I prefer to use the term "authorization identity" to refer
to the subject of authorization decisions in the I-D.  For
the client-provided identity, I prefer "requested identity".

(I only used the term "subject identity" in my email to
avoid ambiguity of the I-D terms, and didn't intend to
suggest that this term be used in the I-D.)

>Given that a server is expected to either use the identity provided by the user (possibly mapped to some internal form) or reject the exchange entirely, I'm beginning to suspect that making the distinction between requested and subject identity may be more confusing than not....

I think it appropriate to outlining the identity concepts
while being clear that the described relationship between
the identities is only conceptual.  Protocol specifications
and their implementation have a lot of freedom (and that
freedom, I would argue, is necessary to make things work).

Kurt 

Date: Fri, 10 Sep 2004 14:08:44 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

On Friday, September 10, 2004 10:55:06 -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

> (Below I am going to refer to the identity used in making
> authorization decisions as the subject identity.)

Maybe it would be best if we avoided the term "authorization identity" at 
all.  Or maybe not.

Given that a server is expected to either use the identity provided by the 
user (possibly mapped to some internal form) or reject the exchange 
entirely, I'm beginning to suspect that making the distinction between 
requested and subject identity may be more confusing than not....

Date: Fri, 10 Sep 2004 11:07:05 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: identities and authorization
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:33 AM 9/10/2004, Kurt D. Zeilenga wrote:
>At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote:
>>Ugh.  Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. 
>
>I wouldn't object to use of another term, such as 'asserted identity'
>or something.

or 'requested identity'.  I'm fine with your terminology
suggestion.

Kurt 

Date: Fri, 10 Sep 2004 10:55:06 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: identities and authorization
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:08 AM 9/10/2004, Alexey Melnikov wrote:
>The document is mostly talking about the requested identity.

Expecting the document explicitly says the identity used in
making authorization decisions is derived from the credentials
and the requested identity.  (Note that I have suggested that
even this statement be clarified as being 'conceptional' in
nature.)

>The identity used for access control *after* a successful SASL authentication is out of scope for the SASL framework. 

Yes, as are the particulars of the derivation.

Note that LDAP is a protocol where, in most implementations
(LDAP doesn't have standardized schema for representing
authorization policy), the identity form used in making
authorization decisions (generally a DN) is not the same form
of the SASL requested identity (a LDAP authzId [RFC2829]).

(Below I am going to refer to the identity used in making
authorization decisions as the subject identity.)

I also note that derivation also allows a level of indication
which some implementations may take advantage of.  For instance,
consider a server which has two groups of users.  Though each
user authenticates as themselves, and requests implicitly or
explicitly to assume their own identity, the server is free
to map all users in one group to an identity associated with
the group.  That is, there may be a many-to-1 relationship
between requested and subject identities.  Also, it is
allowed that the server base the mapping of requested to
subject identities on other factors.  This implies that
there is also a 1-to-many relationship between requested
and subject identities.

I think it best for the particulars of identity mappings
to be left out-of-scope.

Kurt 

Date: Fri, 10 Sep 2004 10:33:09 -0700
To: Jeffrey Hutzelman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: identities and authorization
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:45 AM 9/10/2004, Jeffrey Hutzelman wrote:
>Ugh.  Have I mentioned how much I hate the use of the word "proxy" to describe a relationship that frequently has nothing whatsoever to do with one entity acting for another. 

I wouldn't object to use of another term, such as 'asserted identity'
or something.

My concern is that the document uses confusing terminology to
refer to the three distinct identities (the identity associated
with credentials, a client provide identity, the identity the
server uses to make authorization decisions) it discusses.
The document should use three distinct terms for refer to
each distinct identities it discusses.

(Note that in my use of distinct above, I do not intend to
imply that each of these identities could not refer the same
user (or application entity).  I intend to imply that they
each has distinct characteristics (as discussed in the I-D)
within the SASL identity model).

Kurt 

Date: Fri, 10 Sep 2004 18:08:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> Instead, let's refer to the identity provided by the client and 
> transported by SASL over the wire as the 'requested' identity.  Then 
> the server derives the authorization identity based on the 
> authentication identity, the requested identity, and local policy. 

The document is mostly talking about the requested identity. The 
identity used for access control *after* a successful SASL 
authentication is out of scope for the SASL framework.

> In case it is not clear, I fully agree here that the phrase 
> "authorization identity" should be used to refer to the identity 
> actually used in making authorization decisions, and not that 
> requested by the client.

>   While some of us may need to get used to the new usage, I don't 
> think that's as big a problem as will be caused by implementors and 
> protocol designers being confused into thinking they should used the 
> requested identity rather than the derived one for authorization 
> decisions.
>
>
>
> Incidentally, this whole discussion reminds me of an issue that 
> occurred to me while re-reading the document earlier this week.  It is 
> not at all clear to me that the requested and derived identities are 
> permitted to be different, except in the case where the requested 
> identity is the empty string.

If you are talking about semantics of the two - you are right, they are 
referring to the same entity. But of course the syntax of the derived 
identity is implementation specific and out of scope for SASL and 
doesn't have to be the same as the protocol specific syntax for 
authorization (requested) identities.

Date: Fri, 10 Sep 2004 13:04:17 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

On Friday, September 10, 2004 17:56:43 +0100 Alexey Melnikov 
<[email-masked]> wrote:

>
> Jeffrey Hutzelman wrote:
>
>> When a client requests a specific identity, do we consider it
>> desirable for the server to be able to use some arbitrary other
>> identity instead?
>
> No. The server should either "obey" or fail authentication.

OK.  I'm inclined to agree, and I think the document should state this more 
explicitly.

Further, if that is the case, then I think the distinction between the 
requested and derived identities is much less significant -- if there is a 
requested ID, they will be the same or the exchange will fail.

Date: Fri, 10 Sep 2004 17:56:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> When a client requests a specific identity, do we consider it 
> desirable for the server to be able to use some arbitrary other 
> identity instead?

No. The server should either "obey" or fail authentication.

Date: Fri, 10 Sep 2004 12:45:19 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

On Thursday, September 09, 2004 22:15:02 +0100 Alexey Melnikov 
<[email-masked]> wrote:

> Kurt D. Zeilenga wrote:
>
>> While qualification of the term would likely resolve this
>> issue, that solution would likely be cumbersome.  As the
>> 'authorization identity' more properly refers to the identity
>> directly used in authorization, it seems more appropriate
>> to call the value referred to here as the 'client-provided
>> authorization identity' as the 'proxied identity'.

Ugh.  Have I mentioned how much I hate the use of the word "proxy" to 
describe a relationship that frequently has nothing whatsoever to do with 
one entity acting for another.

Sure, if I connect to one of the cyrus.andrew IMAP backends using a 
requested authorization ID of 'jhutz' and provide credentials proving I am 
a front end, then there is a proxy relationship.  However, if I make the 
same request with credentials belonging to the Kerberos principal 
[email-masked], there is _no_ proxy relationship.  And in either case, 
the client is not _authenticating_ as 'jhutz' at all -- the only 
authentication is of the authentication ID provided by the mechanism, and 
all the client is doing here is asking the server to allow it to _act- as 
the user 'jhutz'.

It's bad enough that people use the confusing phrase "proxy authentication" 
to refer to this situation when it is neither authentication nor 
necessarily involves any proxy relationship.  Let's not compound the 
problem by introducing additional confusing uses of the word 'proxy'.

Instead, let's refer to the identity provided by the client and transported 
by SASL over the wire as the 'requested' identity.  Then the server derives 
the authorization identity based on the authentication identity, the 
requested identity, and local policy.

In case it is not clear, I fully agree here that the phrase "authorization 
identity" should be used to refer to the identity actually used in making 
authorization decisions, and not that requested by the client.  While some 
of us may need to get used to the new usage, I don't think that's as big a 
problem as will be caused by implementors and protocol designers being 
confused into thinking they should used the requested identity rather than 
the derived one for authorization decisions.

Incidentally, this whole discussion reminds me of an issue that occurred to 
me while re-reading the document earlier this week.  It is not at all clear 
to me that the requested and derived identities are permitted to be 
different, except in the case where the requested identity is the empty 
string.  Operationally, my expectation has always been that you have two 
choices - either allow the server to derive an identity from the 
authentication ID, or ask for a specific one which the server can either 
accept or reject.

When a client requests a specific identity, do we consider it desirable for 
the server to be able to use some arbitrary other identity instead?

-- Jeff

Date: Fri, 10 Sep 2004 07:33:53 -0300 (EST)
Subject: 
From: "Silvana Rossetto" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Date: Thu, 09 Sep 2004 22:15:02 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: 2222bis: identities and authorization
Sender: [email-masked]

[Sorry about the delay, I've integrated all other comments received so far.]

Kurt D. Zeilenga wrote:

>>Would you mind explaining the problem you had with this section in
>>better detail?  I thought it flowed fairly well and is a significant
>>improvement on our previous attempts to describe this issue.  However
>>I might well miss problems because as someone who has been following
>>SASL I'm familiar with the issue.  I am not always good at reading a
>>document as someone new to a technology.
>>    
>>
>
>Sure.  The following 3.2 text:
>  
>
>>  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.
>>    
>>
>
>clearly shows the document is using the term 'authorization identity'
>to refer, at times, to the client-provided authorization identity
>and, at times, to a derived authorization identity.  However, in
>other portions of the document, the term 'authorization identity'
>is mostly used unqualified.
>
Right. I agree this is an issue.

>
>While qualification of the term would likely resolve this
>issue, that solution would likely be cumbersome.  As the
>'authorization identity' more properly refers to the identity
>directly used in authorization, it seems more appropriate
>to call the value referred to here as the 'client-provided
>authorization identity' as the 'proxied identity'.
>  
>
[...]

>I've been trying to come with a new term to call the derived
>identity to allow us unambiguously use the term 'authorization
>identity' to refer to the client provided value, as the WG
>seems to have some attachment to this usage.  The best I
>have come with here is 'subject identity' (the identity which
>is the subject in access control decisions). 
>
>I do not recommend this approach myself as I believe it
>would be more proper to use the term 'authorization identity'
>to refer to the subject of access control decisions.
>
I would actually strongly prefer not to do that, as this will make 
everybody very confused. At least I am pretty sure I will be.

"Subject identity" might be a bit ugly, but it is not so bad ;-)

>However, I am far more concerned about ambiguous use of
>the term (using the term to refer to two different values)
>than I am about which of the two uses continues to this
>term.  That is, I can live with calling the client provided
>value an 'authorization identity' if we don't also use that
>term to refer to the derived identity.
>  
>
Ok, I will do the change.

Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-04.txt
Date: Wed, 08 Sep 2004 15:36:55 -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		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: P. Leach, et al. 
	Filename	: draft-ietf-sasl-rfc2831bis-04.txt
	Pages		: 45
	Date		: 2004-9-8
	
This specification defines how HTTP Digest Authentication [Digest]
can be used as a SASL [RFC 2222] mechanism for any protocol that has
a SASL profile. It is intended both as an improvement over CRAM-MD5
[RFC 2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 06 Sep 2004 23:22:11 -0400
From: Tony Hansen <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

Alexey Melnikov wrote:
> Let me clarify what kind of answers I was expecting to my question. I 
> would like to hear something like:
> 1). I don't care either way.
> 2). I prefer that all occurrences of "authentication protocol exchange" 
> are changed to "authentication exchange", but I am Ok if this is not done.
> 3). Must change "authentication protocol exchange" to "authentication 
> exchange".

#1

	Tony Hansen
	[email-masked]

Date: Fri, 03 Sep 2004 12:02:50 -0700
From: Morteza Ansari <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

#2.

Cheers,
Morteza

Kurt D. Zeilenga wrote:

> Let me re-iterate my basic concern.  The specification uses the
> term 'protocol' in general to refer to the application-level
> protocol which is profiling SASL.  Using the term in other
> contexts is confusing.
> 
> For instance, the statement that "A SASL mechanism is responsible
> for conducting an authentication protocol exchange" is unnecessarily
> confusing.  By dropping the word "protocol" from this sentence,
> it is more clear that the mechanism is responsible for the
> authentication exchange (which is defined in the next sentence
> as a series of challenges and responses) and not the actual
> protocol for carrying the exchange.
> 
> I note that the current I-D already uses the terms "authentication
> exchange" instead of "authentication protocol exchange" in numerous
> places.  My suggestion is to always use the term "authentication
> exchange" in place of "authentication protocol exchange".  I view
> this as an editorial change that will improve specification
> clarity.
> 
> With chair hat off, Kurt
> 
> At 07:21 AM 9/3/2004, Alexey Melnikov wrote:
> 
> 
> 
>>>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document.
>>>
>>>This change wouldn't bother me. 
>>
>>Let me clarify what kind of answers I was expecting to my question. I would like to hear something like:
>>1). I don't care either way.
>>2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done.
>>3). Must change "authentication protocol exchange" to "authentication exchange".
>>
>>Having said that, are you #1 or #2?
>>
>>Alexey
>>

Date: Fri, 03 Sep 2004 08:02:06 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Cc: Ken Murchison <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

Let me re-iterate my basic concern.  The specification uses the
term 'protocol' in general to refer to the application-level
protocol which is profiling SASL.  Using the term in other
contexts is confusing.

For instance, the statement that "A SASL mechanism is responsible
for conducting an authentication protocol exchange" is unnecessarily
confusing.  By dropping the word "protocol" from this sentence,
it is more clear that the mechanism is responsible for the
authentication exchange (which is defined in the next sentence
as a series of challenges and responses) and not the actual
protocol for carrying the exchange.

I note that the current I-D already uses the terms "authentication
exchange" instead of "authentication protocol exchange" in numerous
places.  My suggestion is to always use the term "authentication
exchange" in place of "authentication protocol exchange".  I view
this as an editorial change that will improve specification
clarity.

With chair hat off, Kurt

At 07:21 AM 9/3/2004, Alexey Melnikov wrote:

>>>The issue discussed below was raised by Kurt. He suggested to replace "authentication protocol exchange" to "authentication exchange" everywhere in the document.
>>
>>This change wouldn't bother me. 
>
>Let me clarify what kind of answers I was expecting to my question. I would like to hear something like:
>1). I don't care either way.
>2). I prefer that all occurrences of "authentication protocol exchange" are changed to "authentication exchange", but I am Ok if this is not done.
>3). Must change "authentication protocol exchange" to "authentication exchange".
>
>Having said that, are you #1 or #2?
>
>Alexey
>

Date: Fri, 03 Sep 2004 10:41:16 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

Alexey Melnikov wrote:
> 
>>> The issue discussed below was raised by Kurt. He suggested to replace 
>>> "authentication protocol exchange" to "authentication exchange" 
>>> everywhere in the document.
>>
>>
>> This change wouldn't bother me. 
> 
> 
> Let me clarify what kind of answers I was expecting to my question. I 
> would like to hear something like:
> 1). I don't care either way.
> 2). I prefer that all occurrences of "authentication protocol exchange" 
> are changed to "authentication exchange", but I am Ok if this is not done.
> 3). Must change "authentication protocol exchange" to "authentication 
> exchange".
> 
> Having said that, are you #1 or #2?

#2

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Fri, 03 Sep 2004 15:21:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

>> The issue discussed below was raised by Kurt. He suggested to replace 
>> "authentication protocol exchange" to "authentication exchange" 
>> everywhere in the document.
>
> This change wouldn't bother me. 

Let me clarify what kind of answers I was expecting to my question. I 
would like to hear something like:
1). I don't care either way.
2). I prefer that all occurrences of "authentication protocol exchange" 
are changed to "authentication exchange", but I am Ok if this is not done.
3). Must change "authentication protocol exchange" to "authentication 
exchange".

Having said that, are you #1 or #2?

Alexey

Date: Fri, 03 Sep 2004 09:24:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL WG <[email-masked]>
Subject: Re: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> Hi,
> 
> The issue discussed below was raised by Kurt. He suggested to replace 
> "authentication protocol exchange" to "authentication exchange" 
> everywhere in the document.

This change wouldn't bother me.

> 
> Kurt wrote:
> 
>> The problem here is this usage causes the term 'protocol'
>> to be overloaded, making this and other uses of the term
>> ambiguous.  We need to consistently use the term 'protocol'
>> to refer to the application-level protocol making use of
>> SASL.  Other protocols, in particular that of mechanisms,
>> should be referred to by other terms, such as an
>> 'authentication exchange'.
> 
> 
> 
> The term "authentication protocol exchange" comes from RFC 2222. It 
> tries to say that an "authentication exchange" produced by a SASL 
> mechanism is carried by a SASL aware protocol. (I personally find the 
> original term unambiguous, although it is cumbersome.) So I am a bit 
> worried about changing "authentication protocol exchange" to 
> "authentication exchange" at this stage, as this seems to be a 
> [significant] terminology change from RFC 2222.
> 
> It is probably Ok to say in the Introduction that "authentication 
> protocol exchange" and "authentication exchange" are synonyms and that 
> the document will use the latter term everywhere.
> 
> I would like to hear opinions of other WG members.
> 
> Thanks,
> Alexey
> 
> 

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Fri, 03 Sep 2004 10:56:54 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: 2222bis: use of "authentication protocol exchange"
Sender: [email-masked]

Hi,

The issue discussed below was raised by Kurt. He suggested to replace 
"authentication protocol exchange" to "authentication exchange" 
everywhere in the document.

Kurt wrote:

>The problem here is this usage causes the term 'protocol'
>to be overloaded, making this and other uses of the term
>ambiguous.  We need to consistently use the term 'protocol'
>to refer to the application-level protocol making use of
>SASL.  Other protocols, in particular that of mechanisms,
>should be referred to by other terms, such as an
>'authentication exchange'.

The term "authentication protocol exchange" comes from RFC 2222. It 
tries to say that an "authentication exchange" produced by a SASL 
mechanism is carried by a SASL aware protocol. (I personally find the 
original term unambiguous, although it is cumbersome.) So I am a bit 
worried about changing "authentication protocol exchange" to 
"authentication exchange" at this stage, as this seems to be a 
[significant] terminology change from RFC 2222.

It is probably Ok to say in the Introduction that "authentication 
protocol exchange" and "authentication exchange" are synonyms and that 
the document will use the latter term everywhere.

I would like to hear opinions of other WG members.

Thanks,
Alexey