Subject: Re: Thoughts on the sasl plain authzid [revised]

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Feb 2005 11:09:04 -0800

I hit send a bit too fast.

At 10:02 AM 2/28/2005, Sam Hartman wrote:
> I'm complaining that the handling of the default authorization
>ID is discussed in the mechanism spec and that people think you might
>want to do it in the mechanism implementation. 

Are you complaining about this text?
   "... and verify the authentication credentials permit the client
   to act as the (presented or derived) authorization identity."
and/or this text:
   "When no authorization identity is provided, the server SHALL
   derive the authorization identity from the prepared representation
   of the provided authentication identity string."

or just the pseudo code?  If just the latter, I note that the
code is illustrating the above text.  That is, I would think
that if you have a problem with the pseudo code, you'd have
a problem with the text.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Feb 2005 11:09:04 -0800

Kurt  

Date: Mon, 28 Feb 2005 11:09:04 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Thoughts on the sasl plain authzid [revised]
Cc: [email-masked]
Sender: [email-masked]

Kurt  

Date: Mon, 28 Feb 2005 11:03:43 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Thoughts on the sasl plain authzid
Cc: [email-masked]
Sender: [email-masked]

Kurt 

Date: Mon, 28 Feb 2005 10:41:29 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Thoughts on the sasl plain authzid
Cc: [email-masked]
Sender: [email-masked]

At 10:02 AM 2/28/2005, Sam Hartman wrote:
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> At 06:48 AM 2/28/2005, Sam Hartman wrote:
>    >>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>    >> I'm not sure this distiction matters for this discussion but it
>    >> does exist.
>
>    Kurt> The distinction I am trying to draw is between values of
>    Kurt> abstract types and their representations.
>
>    Kurt> However, as that doesn't seem to be working, let me try
>    Kurt> another approach.
>
>    Kurt> Consider a SASL mechanism PLAINprep which was much like
>    Kurt> PLAIN except the client was required to prepare strings
>    Kurt> before transfer.  Would have concerns than that the
>    Kurt> PLAINprep I-D was passing this prepared string to the derive
>    Kurt> function and other functions?  If its okay for PLAINprep I-D
>    Kurt> to provide a prepared authentication to these functions, why
>    Kurt> isn't it okay for PLAIN to do the same?  Why does the
>    Kurt> difference in wire format between PLAIN and PLAINprep
>    Kurt> matter?
>
>I agree that plain must only provide a prepared authcid as output.
>
>I have not complained about the fact that when deriving a default
>authorization ID only the prepared form of the authentication ID is
>used.  I'm complaining that the handling of the default authorization
>    >> >> application specific type.
>    >> >> 
>    >> >> 
>    >> >> If you have a mechanism mucking with authzid or an
>    >> application >> mucknig with authcid, then you are building the
>    >> non-general
>    >> 
>    >> 
>    >> 
>    >> No, I actually meant either application protocol or application
>    >> here and was focusing on application.
>
>    Kurt> I now think I understand how you are using the words
>    Kurt> "application" and "framework".
>
>    Kurt> But do actually think the boundaries between "application",
>    Kurt> "framework", and "mechanism" implementations are going to
>    Kurt> aligned with the specification boundaries?
>
>Yes.
>    Kurt> Most current SASL frameworks do not hide details of
>    Kurt> mechanisms from application implementations.  They could,
>    Kurt> but that would likely require the SASL framework to under
>    Kurt> not only details of the mechanisms, but details of
>    Kurt> application level protocols and their implementations.
>
>I think I disagree with you here.  I'd say that most current SASL
>implementations other than Microsoft's SSPI (which isn't quite a SASL
>implementation but is close enough for this discussion) do a bad job
>of hiding mechanism details from the application because they have a
>simplistic concept of authentication identity.

I argue its because the isn't a unified identity space for the
Internet, and frankly, I don't think there ever will be one.

>I certainly consider it a requirement that I be able to use a SASL
>mechanism I wrote with an application that has never heard about that
>SASL mechanism.

I don't see SASL as being able to met that requirement
as the SASL framework doesn't provide a unified identity space
across all mechanisms and application-level protocols.

>I consider it a requirement for operating systems
>that their native SASL support works well with this usage.
>
>There is some implementation work needed to get to this point.
>
>    >> However my definition of application seems to be different than
>    >> yours.  My basic argument is that the way we've constructed the
>    >> plain document is undesirable because it makes building SASL
>    >> frameworks difficult.
>
>    Kurt> I don't see how.  The work a mechanism implementation must
>    Kurt> do is harder than before, it must prepare strings.  But all
>    Kurt> of this is (properly) hidden from the framework and
>    Kurt> application implementations.  They only deal with prepared
>    Kurt> authentication identities.  Now if we were to pass the
>    Kurt> unprepared authcid value in, the framework or the
>    Kurt> application implementation would need to deal them (e.g.,
>    Kurt> prepare this value before using it in comparison).
>
>I agree passing back unprepared strings would be problematic.
>
>    >> So, by application I mean the part of the application that
>    >> implements the application protocol.
>
>    Kurt> But, as previously discussed, this part will likely have
>    Kurt> knowledge of the mechanism used and its particulars.
>
>Disagree as previous.
>
>    >> By framework I mean the part of the implementation of SASL
>    >> independent of mechanisms and applications--a part of SASL
>    >> mostly but not completely out of scope for this working group.
>
>    Kurt> Well, what about a framework that provided a general
>    Kurt> identity mapping facility.  That framework would need to
>    Kurt> know forms of authentication and authorization identities
>    Kurt> used.
>
>The application provides a mapping from authorization identities to
>the generic form.  The mechanism provides mapping from authcids to the  generic form.

What form is that?

>    >> I believe the only way in which this part of the implementation
>    >> is in scope for this working group is that we've decided that
>    >> such parts of an implementation need to be possible to
>    >> construct.
>
>    Kurt> There are many ways to divide implementations so that they
>    Kurt> can share code.  Some are more feasible than others.
>
>    Kurt> Personally, I think it infeasible for a framework to provide
>    Kurt> a general identity facility.  I think it far more likely, as
>    Kurt> with current SASL libraries I am familiar with, to push
>    Kurt> these issues onto the "application" developer.
>
>I consider this unacceptable.  I do not believe this is the goal of
>general SASL implementations today although I agree that said
>implementations have not done a great job of handling these
>situations.

>    Kurt> I don't see how the PLAIN I-D precludes sharing of code
>    Kurt> between implementations.
>
>It tends to require the application implementation to be aware of
>mechanism details of the plain mechanism.

That's SASL.

>    >> >> I think the current text in plain probably crosses this
>    >> line.
>    >> 
>    Kurt> I disagree.  The PLAIN I-D does not muck with the authzid.
>    Kurt> It only is detailing how the mechanism specific wire
>    Kurt> representations are to mapped to values of the mechanism's
>    Kurt> abstract authentication identity type.
>    >>  The concern I have is that the plain mechanism assumes there
>    >> is some single function that takes plain_authcid_t in and
>    >> returns in the case of LDAP ldap_authzid_t or
>    >> ldap_authzid_rep_t depending on what level you believe this
>    >> function works at.
>
>    Kurt> Is this the general presumption?
>
>Perhaps.  I'm arguing that this presumption is wrong.

I argue that the presumption is what it is.

>Simon's
>implementation difficulties started me thinking and then I started
>looking at whether we had divided things reasonably.
>
>I think that we have in fact divided things incorrectly.  I believe
>that mechanisms specifications should output an abstract authcid and
>an abstract authzid+.  The authzid+ is either an authzid as specified
>by the client or and indication that a default authzid should be
>derived from the authcid.

Er, which is what the current pseudo-code illustrates.
The DeriveAuthzid and Authorize functions are not provided by
the mechanism implementation, they are provided by the framework
or application.  Would use of function pointers in the pseudo-code make
this more clear?  Or maybe just comment to say that functions are
detailed here as they are provided by the application or framework
codes.  Of course, these codes are still dependent on the mechanism
specific authentication identity abstractions (and their
implementations dependent on representations used in the
mechanism implementation).

That is, none of this would change the fact that SASL-enabled
applications (or their frameworks they use) have to deal with
mechanism (and mechanism implementation) details.

>I.E. the mechanism and the mechanism spec
>should not do the work of deriving the authzid; they should leave this
>up to the application or framework as appropriate.
>
>
>    Kurt> Doesn't GSSAPI I-D presume there is some single function
>    Kurt> that takes a GSSAPI identity information and produces an
>    Kurt> appropriate authorization identity?
>
>This is an excellent example of why I don't think this belongs in a
>mechanism implementation.  Thinking about all the work we're doing
>with naming in kitten, this seems clearly the wrong place for that
>step in GSSAPI.
>
>
>--Sam

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Thoughts on the sasl plain authzid
From: Sam Hartman <[email-masked]>
Date: Mon, 28 Feb 2005 13:02:03 -0500
Sender: [email-masked]

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

    Kurt> At 06:48 AM 2/28/2005, Sam Hartman wrote:
    >>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
    >> I'm not sure this distiction matters for this discussion but it
    >> does exist.

    Kurt> The distinction I am trying to draw is between values of
    Kurt> abstract types and their representations.

    Kurt> However, as that doesn't seem to be working, let me try
    Kurt> another approach.

    Kurt> Consider a SASL mechanism PLAINprep which was much like
    Kurt> PLAIN except the client was required to prepare strings
    Kurt> before transfer.  Would have concerns than that the
    Kurt> PLAINprep I-D was passing this prepared string to the derive
    Kurt> function and other functions?  If its okay for PLAINprep I-D
    Kurt> to provide a prepared authentication to these functions, why
    Kurt> isn't it okay for PLAIN to do the same?  Why does the
    Kurt> difference in wire format between PLAIN and PLAINprep
    Kurt> matter?

I agree that plain must only provide a prepared authcid as output.

I have not complained about the fact that when deriving a default
authorization ID only the prepared form of the authentication ID is
used.  I'm complaining that the handling of the default authorization
ID is discussed in the mechanism spec and that people think you might
want to do it in the mechanism implementation.

    >> >> application specific type.
    >> >> 
    >> >> 
    >> >> If you have a mechanism mucking with authzid or an
    >> application >> mucknig with authcid, then you are building the
    >> non-general
    >> 
    >> 
    >> 
    >> No, I actually meant either application protocol or application
    >> here and was focusing on application.

    Kurt> I now think I understand how you are using the words
    Kurt> "application" and "framework".

    Kurt> But do actually think the boundaries between "application",
    Kurt> "framework", and "mechanism" implementations are going to
    Kurt> aligned with the specification boundaries?

Yes.

    Kurt> Most current SASL frameworks do not hide details of
    Kurt> mechanisms from application implementations.  They could,
    Kurt> but that would likely require the SASL framework to under
    Kurt> not only details of the mechanisms, but details of
    Kurt> application level protocols and their implementations.

I think I disagree with you here.  I'd say that most current SASL
implementations other than Microsoft's SSPI (which isn't quite a SASL
implementation but is close enough for this discussion) do a bad job
of hiding mechanism details from the application because they have a
simplistic concept of authentication identity.

I certainly consider it a requirement that I be able to use a SASL
mechanism I wrote with an application that has never heard about that
SASL mechanism.  I consider it a requirement for operating systems
that their native SASL support works well with this usage.

There is some implementation work needed to get to this point.

    >> However my definition of application seems to be different than
    >> yours.  My basic argument is that the way we've constructed the
    >> plain document is undesirable because it makes building SASL
    >> frameworks difficult.

    Kurt> I don't see how.  The work a mechanism implementation must
    Kurt> do is harder than before, it must prepare strings.  But all
    Kurt> of this is (properly) hidden from the framework and
    Kurt> application implementations.  They only deal with prepared
    Kurt> authentication identities.  Now if we were to pass the
    Kurt> unprepared authcid value in, the framework or the
    Kurt> application implementation would need to deal them (e.g.,
    Kurt> prepare this value before using it in comparison).

I agree passing back unprepared strings would be problematic.

    >> So, by application I mean the part of the application that
    >> implements the application protocol.

    Kurt> But, as previously discussed, this part will likely have
    Kurt> knowledge of the mechanism used and its particulars.

Disagree as previous.

    >> By framework I mean the part of the implementation of SASL
    >> independent of mechanisms and applications--a part of SASL
    >> mostly but not completely out of scope for this working group.

    Kurt> Well, what about a framework that provided a general
    Kurt> identity mapping facility.  That framework would need to
    Kurt> know forms of authentication and authorization identities
    Kurt> used.

The application provides a mapping from authorization identities to
the generic form.  The mechanism provides mapping from authcids to the
generic form.

    >> I believe the only way in which this part of the implementation
    >> is in scope for this working group is that we've decided that
    >> such parts of an implementation need to be possible to
    >> construct.

    Kurt> There are many ways to divide implementations so that they
    Kurt> can share code.  Some are more feasible than others.

    Kurt> Personally, I think it infeasible for a framework to provide
    Kurt> a general identity facility.  I think it far more likely, as
    Kurt> with current SASL libraries I am familiar with, to push
    Kurt> these issues onto the "application" developer.

I consider this unacceptable.  I do not believe this is the goal of
general SASL implementations today although I agree that said
implementations have not done a great job of handling these
situations.

    Kurt> I don't see how the PLAIN I-D precludes sharing of code
    Kurt> between implementations.

It tends to require the application implementation to be aware of
mechanism details of the plain mechanism.

    >> >> I think the current text in plain probably crosses this
    >> line.
    >> 
    Kurt> I disagree.  The PLAIN I-D does not muck with the authzid.
    Kurt> It only is detailing how the mechanism specific wire
    Kurt> representations are to mapped to values of the mechanism's
    Kurt> abstract authentication identity type.
    >>  The concern I have is that the plain mechanism assumes there
    >> is some single function that takes plain_authcid_t in and
    >> returns in the case of LDAP ldap_authzid_t or
    >> ldap_authzid_rep_t depending on what level you believe this
    >> function works at.

    Kurt> Is this the general presumption?

Perhaps.  I'm arguing that this presumption is wrong.  Simon's
implementation difficulties started me thinking and then I started
looking at whether we had divided things reasonably.

I think that we have in fact divided things incorrectly.  I believe
that mechanisms specifications should output an abstract authcid and
an abstract authzid+.  The authzid+ is either an authzid as specified
by the client or and indication that a default authzid should be
derived from the authcid.  I.E. the mechanism and the mechanism spec
should not do the work of deriving the authzid; they should leave this
up to the application or framework as appropriate.

    Kurt> Doesn't GSSAPI I-D presume there is some single function
    Kurt> that takes a GSSAPI identity information and produces an
    Kurt> appropriate authorization identity?

This is an excellent example of why I don't think this belongs in a
mechanism implementation.  Thinking about all the work we're doing
with naming in kitten, this seems clearly the wrong place for that
step in GSSAPI.

--Sam

Date: Mon, 28 Feb 2005 08:34:51 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Thoughts on the sasl plain authzid
Cc: [email-masked]
Sender: [email-masked]

At 06:48 AM 2/28/2005, Sam Hartman wrote:

>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> possibly other) abstract types.  Values of ldap_authzid_t
>    Kurt> may have multiple possible Unicode string representations,
>    Kurt> each a value of the ldap_authzid_representation_t (a UTF-8
>    Kurt> encoded Unicode string).  
>
>Agree up to here.
>
>    Kurt> While values of
>    Kurt> ldap_authzid_representation_t are transferred by the
>    Kurt> mechanism, these values are not used in the verification
>    Kurt> process directly.  
>
>No, the mechanism may not actually transport unicode, although it
>needs to be able to map to and from unicode.

The mechanism has to transfer the abstract value of the type.
It can encode that value as it pleases, as long as the encoding
preserves the abstract value.

>I'm not sure this distiction matters for this discussion but it does
>exist.

The distinction I am trying to draw is between values of abstract
types and their representations.

However, as that doesn't seem to be working, let me try another
approach.

Consider a SASL mechanism PLAINprep which was much like PLAIN
except the client was required to prepare strings before
transfer.  Would have concerns than that the PLAINprep I-D was
passing this prepared string to the derive function and other
functions?  If its okay for PLAINprep I-D to provide a prepared authentication to these functions, why isn't it okay for PLAIN
to do the same?  Why does the difference in wire format between
PLAIN and PLAINprep matter?

>    >> application specific type.
>    >> 
>    >> 
>    >> If you have a mechanism mucking with authzid or an application
>    >> mucknig with authcid, then you are building the non-general
>
>
>
>No, I actually meant either application protocol or application here
>and was focusing on application.

I now think I understand how you are using the words "application"
and "framework".

But do actually think the boundaries between "application", "framework",
and "mechanism" implementations are going to aligned with the
specification boundaries?

Most current SASL frameworks do not hide details of mechanisms
from application implementations.   They could, but that would
likely require the SASL framework to under not only details of
the mechanisms, but details of application level protocols and
their implementations.

>However my definition of application seems to be different than yours.
>My basic argument is that the way we've constructed the plain document
>is undesirable because it makes building SASL frameworks difficult.

I don't see how.  The work a mechanism implementation must do is
harder than before, it must prepare strings.  But all of this is
(properly) hidden from the framework and application implementations.
They only deal with prepared authentication identities.  Now if
we were to pass the unprepared authcid value in, the framework or
the application implementation would need to deal them (e.g.,
prepare this value before using it in comparison).

>So, by application I mean the part of the application that implements
>the application protocol.

But, as previously discussed, this part will likely have knowledge
of the mechanism used and its particulars.

> By framework I mean the part of the
>implementation of SASL independent of mechanisms and applications--a
>part of SASL mostly but not completely out of scope for this working
>group.

Well, what about a framework that provided a general identity mapping
facility.  That framework would need to know forms of authentication
and authorization identities used.

>I believe the only way in which this part of the
>implementation is in scope for this working group is that we've
>decided that such parts of an implementation need to be possible to
>construct.

There are many ways to divide implementations so that they can
share code.  Some are more feasible than others.

Personally, I think it infeasible for a framework to provide a
general identity facility.  I think it far more likely, as with
current SASL libraries I am familiar with, to push these issues
onto the "application" developer.

>A mechanism is an implementation of a mechanism specification.
>    >> knowledge into either your mechanism or your application.
>
>    Kurt> I assume s/application/application protocol/ here.
>
>    >> For a particular implmentation that's OK, but we've decided in
>    >> 2222bis that we will not require that generally.  So if you are
>    >> doing something that would require all applications to know
>    >> about an authcid or all implementations of a mechanism to know
>    >> about an authzid for a particular application then you are
>    >> going against 2222bis.
>
>Again, not really.
>
>    Kurt> I assume s/application/application protocol/ here.  And, I
>    Kurt> think you are referring to specification of these.
>
>    Kurt> For clarity, an implementation a SASL-enabled application
>    Kurt> protocol must implement the application protocol
>    Kurt> specification, the base SASL specification, and one or more
>    Kurt> mechanism specifications.
>
>I have provided alternate definitions because the definitions you
>provide are not expressive enough for me to say what I wanted to say.
>IN particular you did not distinguish the parts of an implementation.
>
>
>    Kurt> While an implementation might share code with other
>    Kurt> implementations, how do share code between implementations
>    Kurt> is beyond the scope of current SASL WG I-Ds.
>
>But the requirement that it be possible to do so is not.

I don't see how the PLAIN I-D precludes sharing of code
between implementations.

>    >> I think the current text in plain probably crosses this line.
>
>    Kurt> I disagree.  The PLAIN I-D does not muck with the authzid.
>    Kurt> It only is detailing how the mechanism specific wire
>    Kurt> representations are to mapped to values of the mechanism's
>    Kurt> abstract authentication identity type.
>
>The concern I have is that the plain mechanism assumes there is some
>single function that takes plain_authcid_t in and returns in the case
>of LDAP ldap_authzid_t or ldap_authzid_rep_t depending on what level
>you believe this function works at.

Is this the general presumption?

Doesn't GSSAPI I-D presume there is some single function that
takes a GSSAPI identity information and produces an appropriate
authorization identity?

Doesn't DIGEST-MD5 I-D presume there is some single function that
takes a DIGEST-MD5 identity information and produces an appropriate
authorization identity?

Doesn't EXTERNAL I-D presume there is some single function that
takes a EXTERNAL identity information and produces an appropriate
authorization identity?

Now, I guess I could I could have written:
        authzid = DeriveAuthzid("PLAIN", pAuthcid);
and, likewise,
        Authorize("PLAIN", pAuthcid, authzid)

That, at least at this level, implies a shared derived function.

But we need to pass the prepared form of the authenticate identity
in so that these functions need not have to implement the preparation
function.

>That is to say, an implementation
>of plain is implied to have an application specific mapping.

SASL, as a whole, relies on there being a facility for mapping
mechanism-specific identity forms to application-protocol
specific identity forms (and to implementation-specific
identity forms).

>I think that by this point our thinking has diverged enough that we
>I'll let you respond to my clarifications of my very muddled original
>thoughts before trying to finish responding to your original message.
>
>--Sam

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Thoughts on the sasl plain authzid
From: Sam Hartman <[email-masked]>
Date: Mon, 28 Feb 2005 09:48:11 -0500
Sender: [email-masked]

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

    Kurt> possibly other) abstract types.  Values of ldap_authzid_t
    Kurt> may have multiple possible Unicode string representations,
    Kurt> each a value of the ldap_authzid_representation_t (a UTF-8
    Kurt> encoded Unicode string).  

Agree up to here.

    Kurt> While values of
    Kurt> ldap_authzid_representation_t are transferred by the
    Kurt> mechanism, these values are not used in the verification
    Kurt> process directly.  

No, the mechanism may not actually transport unicode, although it
needs to be able to map to and from unicode.

I'm not sure this distiction matters for this discussion but it does
exist.

    >> application specific type.
    >> 
    >> 
    >> If you have a mechanism mucking with authzid or an application
    >> mucknig with authcid, then you are building the non-general

No, I actually meant either application protocol or application here
and was focusing on application.

However my definition of application seems to be different than yours.
My basic argument is that the way we've constructed the plain document
is undesirable because it makes building SASL frameworks difficult.

So, by application I mean the part of the application that implements
the application protocol.  By framework I mean the part of the
implementation of SASL independent of mechanisms and applications--a
part of SASL mostly but not completely out of scope for this working
group.  I believe the only way in which this part of the
implementation is in scope for this working group is that we've
decided that such parts of an implementation need to be possible to
construct.  A mechanism is an implementation of a mechanism
specification.
    >> knowledge into either your mechanism or your application.

    Kurt> I assume s/application/application protocol/ here.

    >> For a particular implmentation that's OK, but we've decided in
    >> 2222bis that we will not require that generally.  So if you are
    >> doing something that would require all applications to know
    >> about an authcid or all implementations of a mechanism to know
    >> about an authzid for a particular application then you are
    >> going against 2222bis.

Again, not really.

    Kurt> I assume s/application/application protocol/ here.  And, I
    Kurt> think you are referring to specification of these.

    Kurt> For clarity, an implementation a SASL-enabled application
    Kurt> protocol must implement the application protocol
    Kurt> specification, the base SASL specification, and one or more
    Kurt> mechanism specifications.

I have provided alternate definitions because the definitions you
provide are not expressive enough for me to say what I wanted to say.
IN particular you did not distinguish the parts of an implementation.

    Kurt> While an implementation might share code with other
    Kurt> implementations, how do share code between implementations
    Kurt> is beyond the scope of current SASL WG I-Ds.

But the requirement that it be possible to do so is not.

    >> I think the current text in plain probably crosses this line.

    Kurt> I disagree.  The PLAIN I-D does not muck with the authzid.
    Kurt> It only is detailing how the mechanism specific wire
    Kurt> representations are to mapped to values of the mechanism's
    Kurt> abstract authentication identity type.

The concern I have is that the plain mechanism assumes there is some
single function that takes plain_authcid_t in and returns in the case
of LDAP ldap_authzid_t or ldap_authzid_rep_t depending on what level
you believe this function works at.  That is to say, an implementation
of plain is implied to have an application specific mapping.

I think that by this point our thinking has diverged enough that we
I'll let you respond to my clarifications of my very muddled original
thoughts before trying to finish responding to your original message.

--Sam

To: [email-masked]
Subject: IETF62 sasl agenda (fwd)
From: Tom Yu <[email-masked]>
Date: Sun, 27 Feb 2005 23:57:30 -0500
Lines: 29
Sender: [email-masked]

Simple Authentication And Security Layer (SASL)

Tuesday, March 08, at 1530-1630
===============================

Chairs:

Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

AGENDA: (1 hour)

* intro, scribe appointment, agenda bashing - 5 min

* document status - 5 min

  - draft-ietf-sasl-anon-05.txt
  - draft-ietf-sasl-crammd5-04.txt
  - draft-ietf-sasl-gssapi-??
  - draft-ietf-sasl-plain-07.txt
  - draft-ietf-sasl-rfc2222bis-10.txt
  - draft-ietf-sasl-rfc2831bis-04.txt
  - draft-ietf-sasl-saslprep-10.txt

* sasl-plain and sasl-rfc2222bis - 30 min

* discuss milestones - 10 min

* open mike - remaining time

Date: Sun, 27 Feb 2005 20:26:26 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Thoughts on the sasl plain authzid
Cc: [email-masked]
Sender: [email-masked]

At 04:19 PM 2/27/2005, Sam Hartman wrote:
>I find it helpful to think of things from a type matching standpoint.

Okay...

In the PLAIN mechanism, the authentication identities are of the
plain_authcid_t abstract type.  Values of plain_authcid_t may have
multiple possible Unicode string representations, each a value of
plain_authcid_representation_t (a UTF-8 encoded Unicode string).
While values of plain_authcid_representation_t are transferred by
the mechanism, these values are not used in the verification process
directly.  Instead the plain_authcid_representation_t value is to
be converted to a value of plain_authcid_t type.  SASLprep is the
recommended conversion function.

Likewise, in the LDAP application protocol, the authorization
identities are the ldap_authzid_t abstract type, a choice of the
ldap_dn_t and ldap_userid_t (and possibly other) abstract types.
Values of ldap_authzid_t may have multiple possible Unicode
string representations, each a value of the
ldap_authzid_representation_t (a UTF-8 encoded Unicode string).
While values of ldap_authzid_representation_t are transferred
by the mechanism, these values are not used in the verification
process directly.  Instead the ldap_authzid_representation value
is to be converted to a value of ldap_authzid_t type.

>The authcid is a mechanism-specific type and the authzid is an
>application specific type.
>
>
>If you have a mechanism mucking with authzid or an application mucknig
>with authcid, then you are building the non-general knowledge into
>either your mechanism or your application.

I assume s/application/application protocol/ here.

>For a particular
>implmentation that's OK, but we've decided in 2222bis that we will not
>require that generally.  So if you are doing something that would
>require all applications to know about an authcid or all
>implementations of a mechanism to know about an authzid for a
>particular application then you are going against 2222bis.

I assume s/application/application protocol/ here.
And, I think you are referring to specification of these.

For clarity, an implementation a SASL-enabled application protocol
must implement the application protocol specification, the
base SASL specification, and one or more mechanism specifications.

While an implementation might share code with other implementations,
how do share code between implementations is beyond the scope
of current SASL WG I-Ds.

>I think the current text in plain probably crosses this line.

I disagree.  The PLAIN I-D does not muck with the authzid.
It only is detailing how the mechanism specific wire representations
are to mapped to values of the mechanism's abstract authentication
identity type.

>But somewhere you need a mapping from authcid_t to authzid_t to do the
>default authzid logic.

Presently, all identity mapping is implementation specific.

>How is that possible in a general framework?

Not sure how you are using the term "general framework" here?
I assume you mean "SASL library", some code intended to be shared
between different implementations of the various SASL-enabled
application protocols.

>I think that a general framework will need to have a
>mechanism-independent form of authcids completely internal to the
>framework.

Or just pass a mechanism-dependent authcid form (not necessary
what used on the wire) through the SASL library.   I note this
as it may not be desirable to utilize shared mappings. 

>So, the mechanism maps from authcid to frameworkid and
>exports the frameworkid.  Then the application maps from frameworkid
>to authzid.

Well, if I was designing the SASL library, I would require
each mechanism implementation to produce a canonical UTF-8
string representation of its authentication identity and
pass that, along with the name of the mechanism, to the
application protocol implementation for mapping to an
appropriate authzid.  (I'd pass the mechanism name as
PLAIN "joe" may not be same as say CRAM-MD5 "joe", or
in mechanism like DIGEST-MD5, may include realm information.)

>In practice you'll probably do authorizations in terms of frameworkids
>(particularly if they happen to be Windows sids or some general
>concept like that) and so you'll only map authzids to frameworkids
>when an explicit authzid is carried from the user to the server.

In practice, I think its generally done in terms of non-canonical
mechanism-specific Unicode string representations, sometimes
mucked (*) by the framework (ugh).

>These are my thoughts at least for now.
>--Sam

To: [email-masked]
Subject: Thoughts on the sasl plain authzid
From: Sam Hartman <[email-masked]>
Date: Sun, 27 Feb 2005 19:19:25 -0500
Sender: [email-masked]

I find it helpful to think of things from a type matching standpoint.

The authcid is a mechanism-specific type and the authzid is an
application specific type.

If you have a mechanism mucking with authzid or an application mucknig
with authcid, then you are building the non-general knowledge into
either your mechanism or your application.  For a particular
implmentation that's OK, but we've decided in 2222bis that we will not
require that generally.  So if you are doing something that would
require all applications to know about an authcid or all
implementations of a mechanism to know about an authzid for a
particular application then you are going against 2222bis.  I think
the current text in plain probably crosses this line.

But somewhere you need a mapping from authcid_t to authzid_t to do the
default authzid logic.  How is that possible in a general framework?

I think that a general framework will need to have a
mechanism-independent form of authcids completely internal to the
framework.  So, the mechanism maps from authcid to frameworkid and
exports the frameworkid.  Then the application maps from frameworkid
to authzid.

In practice you'll probably do authorizations in terms of frameworkids
(particularly if they happen to be Windows sids or some general
concept like that) and so you'll only map authzids to frameworkids
when an explicit authzid is carried from the user to the server.

These are my thoughts at least for now.

--Sam

Date: Fri, 25 Feb 2005 08:45:47 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: <[email-masked]>
Sender: [email-masked]

At 01:56 AM 2/25/2005, Simon Josefsson wrote:
>> Are there any objections to this proposed course of action?
>
>Not from me, although I sympathize with those who are concerned with
>the time delay.

This I-D has to wait for the base specification to catch up,
so pulling it back is likely not to cause any delay in its
publication.

>It is not entirely clear to me that my approach (move
>all authzid handling to the application profile, including
>preparation/derivation of a default authzid) is not conceptually
>problematic in some other way.

Some handling of the authorization identity is mechanism specific.
For instance, a mechanism is free to encode the authorization
identity using base64.  It is appropriate for the mechanism
specification to be clear has to how its encoded for transfer.
The pseudo-code illustrates that no special decoding is needed.

The form of the authentication identity is mechanism specific,
as are details to which forms are to be considered equivalent.
It is appropriate for a mechanism specification to, as the
PLAIN I-D does, to specify and illustrate this.

It would be inappropriate for a mechanism specification to
otherwise detail how the authorization identity is derived,
or how authorization is done.  The PLAIN I-D does not otherwise
detail these functions.

Kurt 

Date: Fri, 25 Feb 2005 08:29:26 -0800
To: Tom Yu <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: <[email-masked]>
Sender: [email-masked]

At 12:54 AM 2/25/2005, Tom Yu wrote:
>Are there any objections to this proposed course of action?

I do not object to this course of action.

I do have comment, intend to spark WG discussion.  I've trimmed
the Cc list so not to overload the IESG list with these discussions.

>I make the following observations:
>
>* The pseudo-code in Section 4 of sasl-plain appears to me to be not
>  normative; it probably should be clearly labeled as not normative.
>  If it is intended to be normative, the use of SASLprep(...)
>  conflicts with the "SHOULD" language in Section 2 regarding
>  preparation of the presented strings.

I suggest replacing the statement to the top of the section with:
   This section provides pseudo-code illustrating the
   verification process (using hashed passwords and the SASLprep
   preparation function).  This section is not definitive.

>* The pseudo-code in Section 4, in addition to the ensuing discussion,
>  exhibits some confusion regarding the actions which belong in a SASL
>  mechanism. In particular, it is not clear whether the actions
>  performed when receiving an empty authorization identity (authzid)
>  are performed by the SASL mechanism or by the application server
>  implementation.  Additionally, the mechanism description in Section
>  2 exhibits similar confusion.

Note that the pseudo-code does not illustrate detail (nor does
Section 3 specify) the particulars of the derivation.  That is
purposely left to implementations.  What the pseudo-code does
illustrates (and the Section 3 specifies) is what representation
of the authentication identity the mechanism provides to the
derivation function.  Likewise, for the Authorize function.

One could simply add the following text to the end of the Section 4
to clarify this:
   Note that the details of the DeriveAuthzId and Authorize
   are not illustrated as they are not specified in the above
   specification.  The authentication identity provided to these
   functions by this mechanism is, as specified above, is a
   prepared representation.

>* Section 3.2 of sasl-rfc2222bis implies to me that the role of the
>  SASL mechanism is to transmit the authorization identity from the
>  client to the application server unchanged.  This suggests that the
>  application server, not the SASL mechanism,

The application server implements both the application protocol
and the SASL mechanism and hence is responsible for implementing
the application protocol specification, the SASL specification,
and the mechanism specification.  The question seems to be: which
specification is responsible for specify what.

>  is responsible for handling the empty authzid string,

The mechanism specification is responsible for specifying
the form of the authentication identity and how it is
verified.   The PLAIN specification does not detail how
the authorization identity is derived, it only prescribes
the form of the authentication identity it produces for
use in deriving the authorization identity.  It is quite
appropriate for mechanism to be clear in regards to
authentication identity forms.

I would argue that mechanism specifications SHOULD specify
how to produce a canonical representation of the authentication
identity or, at the very least, detail which representations are
to be considered equivalent.

>while sasl-plain can be
>  interpreted as stating that the SASL PLAIN mechanism is responsible
>  for producing a authzid string from the authentication identity when
>  the authzid is an empty string.

That's a stretch in my opinion.  PLAIN only states what it
produces for use in the derivation (and authorization)
and illustrates how these functions in the verification
process.

Note that the pseudo-code illustrates that no special action
(e.g., decoding) in regards to the authzid, as in some mechanisms.
For a mechanism transferred the authzid using base64, it would be
appropriate for the mechanism to illustrate that decoded authzid
is provided to the authorize function.  Hence, it is appropriate
for this pseudo-code to illustrate that no such decoding is done.

>Simon's points about authzid strings in sasl-plain leave me with the
>impression that text in sasl-plain is sufficiently confusing to cause
>implementation difficulties.  These difficulties arise from conceptual
>ambiguity about the exact boundaries of the abstract interface to a
>SASL mechanism.

Which, I presume we agree, is largely a base specification issue.

>I suggest that the working group discuss and arrive at a consensus
>concerning the interface between a SASL mechanism and an application
>protocol server implementation, and that sufficiently lucid text be
>written to resolve the conceptual ambiguity.  

As noted above, a server implements multiple specifications.  While
I agree that we need to be more clear in our abstractions separating
mechanisms from application protocols (and whatever might be in between)
and responsibilities and restrictions placed upon specifications of
mechanisms and application protocols, we need to be careful to leave
actual interface boundaries within a implementation as implementation
details. 

To: [email-masked]
Subject: IETF62 sasl agenda draft 0.1
From: Tom Yu <[email-masked]>
Date: Fri, 25 Feb 2005 05:14:47 -0500
Lines: 31
Sender: [email-masked]

Since we are rapidly approaching the deadline for working group
agendas (Feb 28), I suggest the following draft agenda.  Please send
any requests for agenda changes to the chairs.

Simple Authentication And Security Layer (SASL)

XXX, March XX, at XXXX-XXXX
===========================

Chair(s):

Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

DRAFT AGENDA: (1 hour)

* intro, scribe appointment, agenda bashing - 5 min

* document status - 5 min

  - draft-ietf-sasl-anon-05.txt
  - draft-ietf-sasl-crammd5-04.txt
  - draft-ietf-gssapi-??
  - draft-ietf-sasl-plain-07.txt
  - draft-ietf-sasl-rfc2222bis-10.txt
  - draft-ietf-sasl-rfc2831bis-04.txt
  - draft-ietf-sasl-saslprep-10.txt

* sasl-plain, sasl-rfc2222bis - 30? min

* update milestones - 10 min

From: Simon Josefsson <[email-masked]>
To: <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 25 Feb 2005 11:07:16 +0100
Sender: [email-masked]

Programmers may be helped in thinking about this issue by considering
an actual implementation.  There is one in:

http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/plain/server.c?view=markup

I have applied a patch to make the implementation behave according to
the current document (i.e., the mechanism is responsible for
preparing/deriving the authzid).  The patch is straightforward, even
though the implications may not be:

http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/plain/server.c?r1=1.22&r2=1.23&diff_format=l

I've done this to experiment with that approach.

(Naturally, I'm not saying there aren't other thinkos in that code.
Comments appreciated, of course.)

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], <[email-masked]>, Sam Hartman <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 25 Feb 2005 10:56:52 +0100
Sender: [email-masked]

Tom Yu <[email-masked]> writes:

> Are there any objections to this proposed course of action?

Not from me, although I sympathize with those who are concerned with
the time delay.  It is not entirely clear to me that my approach (move
all authzid handling to the application profile, including
preparation/derivation of a default authzid) is not conceptually
problematic in some other way.  The discussion has made me less sure
about my position.

One idea is to last call the core document at the same time as at
least one mechanism, since, if I recall correctly, the text regarding
authcid/authzid has been changed in the core document a few times.  It
may help to review the core document and one mechanism, for
consistency, at the same time.

Thanks,
Simon

To: Sam Hartman <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Tom Yu <[email-masked]>
Date: Fri, 25 Feb 2005 03:54:41 -0500
Lines: 54
Sender: [email-masked]

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

Sam> I agree with Kurt here.  I actually think Simon and perhaps the whole
Sam> discussion of this issue in the working group has missed a more
Sam> fundamental issue.  The authorization ID is not in the same namespace
Sam> or typespace as the authentication identity.  

I apologize for not replying to this discussion sooner.  It has taken
me some amount of time to unravel the issues in a satisfactory manner.
At this point I think that it is best to withdraw the document from
the IESG for further discussion in the working group.  There appear to
be some conceptual discrepancies between sasl-rfc2222bis and
sasl-plain.  Both documents could use some further discussion and
revision to remove conceptual ambiguity.  I make the following
observations:

* The pseudo-code in Section 4 of sasl-plain appears to me to be not
  normative; it probably should be clearly labeled as not normative.
  If it is intended to be normative, the use of SASLprep(...)
  conflicts with the "SHOULD" language in Section 2 regarding
  preparation of the presented strings.

* The pseudo-code in Section 4, in addition to the ensuing discussion,
  exhibits some confusion regarding the actions which belong in a SASL
  mechanism.  In particular, it is not clear whether the actions
  performed when receiving an empty authorization identity (authzid)
  are performed by the SASL mechanism or by the application server
  implementation.  Additionally, the mechanism description in Section
  2 exhibits similar confusion.

* Section 3.2 of sasl-rfc2222bis implies to me that the role of the
  SASL mechanism is to transmit the authorization identity from the
  client to the application server unchanged.  This suggests that the
  application server, not the SASL mechanism, is responsible for
  handling the empty authzid string, while sasl-plain can be
  interpreted as stating that the SASL PLAIN mechanism is responsible
  for producing a authzid string from the authentication identity when
  the authzid is an empty string.

Simon's points about authzid strings in sasl-plain leave me with the
impression that text in sasl-plain is sufficiently confusing to cause
implementation difficulties.  These difficulties arise from conceptual
ambiguity about the exact boundaries of the abstract interface to a
SASL mechanism.

I suggest that the working group discuss and arrive at a consensus
concerning the interface between a SASL mechanism and an application
protocol server implementation, and that sufficiently lucid text be
written to resolve the conceptual ambiguity.  For the time being,
sasl-plain should be withdrawn from the IESG, pending revision.

Are there any objections to this proposed course of action?

---Tom

To: Simon Josefsson <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Thu, 24 Feb 2005 13:52:06 -0500
Sender: [email-masked]

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

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

    >>> The section reads:
    >>> 
    >>> When an empty authorization identity is provided, the server
    >>> SHALL derive the authorization identity from the prepared
    >>> representation of the provided authentication identity string.
    >>> This ensures that the derivation of different representations
    >>> of the authentication identity produce the same authorization
    >>> identity.
    >>> 
    >>> If you are saying that this SHALL is not mandatory,
    >>  This text says that server SHALL use the prepared form of the
    >> authentication identity in deriving the authorization identity
    >> when no authzid is provided.  The earlier text says: The server
    >> SHOULD prepare each string using the [SASLPrep] profile of the
    >> [StringPrep] algorithm.

    Simon> What is unclear to me is whether following is permitted or
    Simon> not: Let's say authcid is prepared using SASLprep (i.e.,
    Simon> the SHOULD is followed).  The authzid is missing, so it is
    Simon> has to be derived from authcid.  In this case, do the SHALL
    Simon> above require that the "default" authzid input to
    Simon> DeriveAuthzid is SASLprep(authcid)?

    Simon> As far as I can tell, the answer would be yes.  

I agree with Kurt and you that the answer is yes.

    Simon> And I
    Simon> believe that is unfortunate.

    Simon> In my opinion, it should be permitted to let DeriveAuthzid
    Simon> receive 'authcid', so the function can prepare the string
    Simon> according to its own application-specific preparation
    Simon> rules.
I think with moderate confidence that the working group explicitly
decided not to allow this.  I don't have a pointer to a discussion though.

I'm quite sure I don't want to allow this.  In particular it would
allow nonsensical behavior such as the following:

* the identity you authenticate as (or what password you need) is dependent on saslprep.
* The identity you act as is dependent on un-normalized Unicode.

In other words you're asking for rope that would allow the set of
privileges you end up having to depend on whether separate accent
characters are used in your login name, even though your password
cannot depend on this.

I see no advantage in offering such rope and significant
disadvantages.

    Simon> Another way to put it, is that the choice of preparation
    Simon> algorithm used by a mechanism should not be forced upon all
    Simon> application profiles.

Storngly disagree.  The authentication identity is in the namespace of
the mechanism; only the mechanism knows what type it is.  The
authorization identity is in the namespace of the application profile.
The application profile must not depend on the mechanism so it must
not say anything about the mapping from authentication identity to
authorization identity; that mapping is an implementation matter.  It
is not a matter for the mechanism spec or the application profile.
Doing anything else will violate typing rules.

--Sam

Date: Thu, 24 Feb 2005 07:44:21 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 02:09 AM 2/24/2005, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>>>The section reads:
>>>
>>>  When an empty authorization identity is provided, the server SHALL
>>>  derive the authorization identity from the prepared representation of
>>>  the provided authentication identity string.  This ensures that the
>>>  derivation of different representations of the authentication identity
>>>  produce the same authorization identity.
>>>
>>>If you are saying that this SHALL is not mandatory,
>>
>> This text says that server SHALL use the prepared form of the
>> authentication identity in deriving the authorization identity
>> when no authzid is provided.  The earlier text says:
>>   The server SHOULD prepare each string using the
>>   [SASLPrep] profile of the [StringPrep] algorithm.
>
>What is unclear to me is whether following is permitted or not: Let's
>say authcid is prepared using SASLprep (i.e., the SHOULD is followed).

So, the implementor has choose to use the SASLprep as the preparation
algorithm.

>The authzid is missing, so it is has to be derived from authcid.

It has to be derived from the prepared form of the authentication
identity, e.g., prepare(authcid) or, as SASLprep() was chosen as
the preparation algorithm, SASLprep(authcid).  (Note that this
is the same octet string as prepare(stored authentication identity,
hence the language "THE prepared representation" (in the I-D),
"THE prepared form" (in my comment).)

>In
>this case, do the SHALL above require that the "default" authzid input
>to DeriveAuthzid is SASLprep(authcid)?

As SASLprep was chosen as the preparation algorithm, yes.  But the implementor
could have chosen to use another preparation algorithm.  If it does so, then
it to consistently use that algorithm in the verification process.

>As far as I can tell, the answer would be yes.  And I believe that is
>unfortunate.

Aside from ranting further that it would be unfortunate if the authorization
identity given the user would depend on the details of the client implementation
the user choose, I ask you to provide an "for instance" which is not addressed
by selecting a different preparation algorithm for use in the verification
process.

>In my opinion, it should be permitted to let DeriveAuthzid receive
>'authcid', so the function can prepare the string according to its own
>application-specific preparation rules.

The implementor is given plenty of rope (in the SHOULD use SASLprep).

>Another way to put it, is that the choice of preparation algorithm
>used by a mechanism should not be forced upon all application
>profiles.

Not sure what you mean by "profile".  I generally take that word
to refer to a particular kind of specification, you might be using to
refer to an implementation of a specification.

In the former case, see Jeffrey comments regarding the separation of
mechanisms and application protocols.  In the latter case, I again
note that implementors are free not to use SASLprep as PLAIN's
preparation algorithm.

Kurt 

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 24 Feb 2005 11:09:36 +0100
Sender: [email-masked]

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

>>The section reads:
>>
>>  When an empty authorization identity is provided, the server SHALL
>>  derive the authorization identity from the prepared representation of
>>  the provided authentication identity string.  This ensures that the
>>  derivation of different representations of the authentication identity
>>  produce the same authorization identity.
>>
>>If you are saying that this SHALL is not mandatory,
>
> This text says that server SHALL use the prepared form of the
> authentication identity in deriving the authorization identity
> when no authzid is provided.  The earlier text says:
>   The server SHOULD prepare each string using the
>   [SASLPrep] profile of the [StringPrep] algorithm.

What is unclear to me is whether following is permitted or not: Let's
say authcid is prepared using SASLprep (i.e., the SHOULD is followed).
The authzid is missing, so it is has to be derived from authcid.  In
this case, do the SHALL above require that the "default" authzid input
to DeriveAuthzid is SASLprep(authcid)?

As far as I can tell, the answer would be yes.  And I believe that is
unfortunate.

In my opinion, it should be permitted to let DeriveAuthzid receive
'authcid', so the function can prepare the string according to its own
application-specific preparation rules.

Another way to put it, is that the choice of preparation algorithm
used by a mechanism should not be forced upon all application
profiles.

Thanks,
Simon

Date: Wed, 23 Feb 2005 08:14:12 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 07:24 AM 2/23/2005, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> At 01:51 AM 2/23/2005, Simon Josefsson wrote:
>>
>>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>>
>>>>>The "derive" function can compute the
>>>>>latter itself, but cannot go from SASLprep(authcid) to authcid. 
>>>>
>>>> The point of using prepare here is to ensure that the
>>>> output of derive() is not dependent on possible representational
>>>> differences in the authentication identity.
>>>>
>>>> That is, if one client happens to produce NFC representation
>>>> of the authentication identity, and another NKFC, the user
>>>> will have the same authorization identity regardless of
>>>> which of the two clients was used.
>>>
>>>Not necessarily, since prepare() currently permit unassigned code
>>>points in the output.  I.e., with the current text you can have
>>>prepare(NFC(X)) != prepare(NFKC(X)) if X contain some code point new
>>>in Unicode 4.0 that is normalized differently by NFC and NFKC.
>>
>> If X contains some new code points, e.g., unassigned in
>> Unicode as defined in SASLprep, then authentication will
>> fail (by design) if the server uses the RECOMMENDED
>> algorithm.  If the server doesn't use the RECOMMENDED
>> algorithm, behavior is implementation specific.
>
>The document is not clear that deriving a "default" authzid using
>DeriveAuthzid(SASLprep(authcid)) is part of the RECOMMENDED
>verification algorithm.

First, there is no RECOMMENDED verification algorithm, there
is a verification process which includes preparation, an
a statement of which preparation algorithm is RECOMMENDED.

I think the document is quite clear as to what the
verification process is, what the RECOMMENDED preparation
algorithm is, and that the verification process includes
both verification that the passwd is suitable to authenticate
the user identified by the authcid AND verification of that
that this user can assume the identity represented by the
provided authzid or, if absent, associated with the authcid.

  Upon receipt of the message, the server will verify the presented
  (in the message) 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.

  In this verification process, the presented authentication identity
  and password strings, as well as the database authentication identity
  and password strings, are to be prepared before being used in any
  comparison.  The server SHOULD prepare each string using the
  [SASLPrep] profile of the [StringPrep] algorithm.  The SASLprep
  preparation is recommended to improve the likelihood that comparisons
  behave in an expected manner.  It is not mandatory to allow the      
  server to employ other preparation algorithms (including none) as  
  necessary to interoperate with external systems.

We've also provided pseudo code to illustrate this.  Hence,
I disagree that the I-D is not clear as to what the verification
process is, where preparation should be used, and/or what
preparation algorithm should be used.

>The section reads:
>
>  When an empty authorization identity is provided, the server SHALL
>  derive the authorization identity from the prepared representation of
>  the provided authentication identity string.  This ensures that the
>  derivation of different representations of the authentication identity
>  produce the same authorization identity.
>
>If you are saying that this SHALL is not mandatory,

This text says that server SHALL use the prepared form of the
authentication identity in deriving the authorization identity
when no authzid is provided.  The earlier text says:
  The server SHOULD prepare each string using the
  [SASLPrep] profile of the [StringPrep] algorithm. 

>or that it is
>conditioned on some other decision, I believe it is misleading to use
>the term SHALL.

I don't think its misleading.

>Thanks,
>Simon

Date: Wed, 23 Feb 2005 07:32:42 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

At 01:41 AM 2/23/2005, Simon Josefsson wrote:
>That view seem consistent, and now I understand it.  A further
>question then: Why are unassigned code points allowed in the input to
>DeriveAuthzid()? 

If SASLprep is used, then unassigned code points won't appear
in the input to DerivedAuthzid as such an authcid value
cannot possibly match any stored authcid value.  In the
pseudo-code, this is the case of FetchPasswordHash(pAuthcid)
returning NULL (unknown authcid).

Of course, if using another prepare algorithm the behavior
is implementation specific.

Kurt 

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Feb 2005 16:24:45 +0100
Sender: [email-masked]

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

> At 01:51 AM 2/23/2005, Simon Josefsson wrote:
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>>>The "derive" function can compute the
>>>>latter itself, but cannot go from SASLprep(authcid) to authcid. 
>>>
>>> The point of using prepare here is to ensure that the
>>> output of derive() is not dependent on possible representational
>>> differences in the authentication identity.
>>>
>>> That is, if one client happens to produce NFC representation
>>> of the authentication identity, and another NKFC, the user
>>> will have the same authorization identity regardless of
>>> which of the two clients was used.
>>
>>Not necessarily, since prepare() currently permit unassigned code
>>points in the output.  I.e., with the current text you can have
>>prepare(NFC(X)) != prepare(NFKC(X)) if X contain some code point new
>>in Unicode 4.0 that is normalized differently by NFC and NFKC.
>
> If X contains some new code points, e.g., unassigned in
> Unicode as defined in SASLprep, then authentication will
> fail (by design) if the server uses the RECOMMENDED
> algorithm.  If the server doesn't use the RECOMMENDED
> algorithm, behavior is implementation specific.

The document is not clear that deriving a "default" authzid using
DeriveAuthzid(SASLprep(authcid)) is part of the RECOMMENDED
verification algorithm.  The section reads:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the prepared representation of
  the provided authentication identity string.  This ensures that the
  derivation of different representations of the authentication identity
  produce the same authorization identity.

If you are saying that this SHALL is not mandatory, or that it is
conditioned on some other decision, I believe it is misleading to use
the term SHALL.

Thanks,
Simon

Date: Wed, 23 Feb 2005 07:01:45 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 01:51 AM 2/23/2005, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>>>The "derive" function can compute the
>>>latter itself, but cannot go from SASLprep(authcid) to authcid. 
>>
>> The point of using prepare here is to ensure that the
>> output of derive() is not dependent on possible representational
>> differences in the authentication identity.
>>
>> That is, if one client happens to produce NFC representation
>> of the authentication identity, and another NKFC, the user
>> will have the same authorization identity regardless of
>> which of the two clients was used.
>
>Not necessarily, since prepare() currently permit unassigned code
>points in the output.  I.e., with the current text you can have
>prepare(NFC(X)) != prepare(NFKC(X)) if X contain some code point new
>in Unicode 4.0 that is normalized differently by NFC and NFKC.

If X contains some new code points, e.g., unassigned in
Unicode as defined in SASLprep, then authentication will
fail (by design) if the server uses the RECOMMENDED
algorithm.  If the server doesn't use the RECOMMENDED
algorithm, behavior is implementation specific.

>> Your proposal, if adopted, would allow servers to make the
>> derivation dependent on allowed representational differences
>> which should not impact the behavior of the server.
>
>I think the current text permit this too, see above, since unassigned
>code points are left untouched by prepare().

When SASLprep is not used, anything is possible.

>An alternative solution to this problem would be to disallow
>unassigned code points when preparing the authcid that is used as
>input to DeriveAuthzid.

When SASLprep is used, they are (since even if allowed in the
provided authcid, a provided authcid with unassigned code
points cannot possibly match a SASLprep-prepared stored authcid.

>That would be simpler, but I still prefer my
>approach, although I can't pin-point exactly what the difference would
>be.
>
>Thanks,
>Simon

To: Simon Josefsson <[email-masked]>, [email-masked]
Cc: "Kurt D. Zeilenga" <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Wed, 23 Feb 2005 09:41:38 -0500
Sender: [email-masked]

[Tom, I'm asking for an explicit call from the chair for this document.]

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

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

    >>> The "derive" function can compute the latter itself, but
    >>> cannot go from SASLprep(authcid) to authcid.
    >>  The point of using prepare here is to ensure that the output
    >> of derive() is not dependent on possible representational
    >> differences in the authentication identity.
    >> 
    >> That is, if one client happens to produce NFC representation of
    >> the authentication identity, and another NKFC, the user will
    >> have the same authorization identity regardless of which of the
    >> two clients was used.

    Simon> Not necessarily, since prepare() currently permit
    Simon> unassigned code points in the output.  I.e., with the
    Simon> current text you can have prepare(NFC(X)) !=
    Simon> prepare(NFKC(X)) if X contain some code point new in
    Simon> Unicode 4.0 that is normalized differently by NFC and NFKC.

Simon, when you bring up an issue in IETF-wide last call that has been
extensively discussed in the working group, please note that fact.  In
this instance it's not the same field as was discussed before but it
is the same issue as with the password.  

It's my opinion that the consensus on the last go around was fairly
rough, so bringing it up again especially when you noticed a new
implication is a fine thing to do.

Currently we're under a bit of time pressure because the document is
on the IESG agenda.  This issue is complicated enough that if the WG
wants to revisit it, I will remove the document from the agenda and we
can hash things out on the working group list bringing it back when
we're done.  I don't think making a quick change to the handling of
this issue would give me the necessary confidence in the quality of
the change.

My personal opinion is that the text is fine as is and that the
current text creates greater interoperability than forbidding unassigned
codepoints.

Tom, please let me know by Friday whether there is a consensus in the
WG to pull the document back to discuss this issue.

--Sam

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Feb 2005 10:51:39 +0100
Sender: [email-masked]

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

>>The "derive" function can compute the
>>latter itself, but cannot go from SASLprep(authcid) to authcid. 
>
> The point of using prepare here is to ensure that the
> output of derive() is not dependent on possible representational
> differences in the authentication identity.
>
> That is, if one client happens to produce NFC representation
> of the authentication identity, and another NKFC, the user
> will have the same authorization identity regardless of
> which of the two clients was used.

Not necessarily, since prepare() currently permit unassigned code
points in the output.  I.e., with the current text you can have
prepare(NFC(X)) != prepare(NFKC(X)) if X contain some code point new
in Unicode 4.0 that is normalized differently by NFC and NFKC.

> Your proposal, if adopted, would allow servers to make the
> derivation dependent on allowed representational differences
> which should not impact the behavior of the server.

I think the current text permit this too, see above, since unassigned
code points are left untouched by prepare().

An alternative solution to this problem would be to disallow
unassigned code points when preparing the authcid that is used as
input to DeriveAuthzid.  That would be simpler, but I still prefer my
approach, although I can't pin-point exactly what the difference would
be.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Feb 2005 10:41:47 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Wednesday, February 23, 2005 01:01:45 AM +0100 Simon Josefsson 
> <[email-masked]> wrote:
>
>>
>> Sam Hartman <[email-masked]> writes:
>>
>>>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>>>
>>>     Simon> I'm saying that it is the application profile that should
>>>     Simon> define the form of authzid,
>>>
>>> I think the authorization ID tends to have more of an implementation
>>> specific (instead of application specific) component than you seem to
>>> be assuming.  The profile does need to describe the form in so far as
>>> it needs to describe normalization and that sort of thing.  However I
>>> am unclear on whether application profiles must assign semantics to
>>> authorization identities.
>>
>> The problem here is that a mechanism (PLAIN) assume some semantics on
>> authzid's when it is using SASLprep to prepare input to the
>> DeriveAuthzid function.  I'm saying it is better to let DeriveAuthzid
>> call SASLprep internally, if appropriate.  Then we also do not need to
>> copy the same 'authzid=SASLprep(authcid)' text to all future SASL
>> mechanism documents.
>
> The document does not say "authzid=SASLprep(authcid)".
> It says "authzid=DeriveAuthzid(SASLprep(authcid))".
>
> This does not say that the authzid is prepared by SASLprep.  It says that 
> the authcid is prepared by SASLprep before being handed to DeriveAuthzid, 
> which then returns authzid in whatever form is appropriate for the 
> application.  We are not applying SASLprep to the _output_ of the mapping; 
> we're applying it to the _input_ to the mapping, which is a 
> mechanism-specific authcid.

Right, I agree, but I expressed myself poorly.

> The Derive function can do pretty much whatever it wants.  It cannot be 
> constrained by mechanisms, and in most cases is not constrained by the 
> application profile either (rather, it is usually 
> implementation-dependent).  However, its input is a valid authcid for the 
> mechanism in use, prepared according to the specification of that 
> mechanism.  This _needs_ to be specified by each mechanism because it is a 
> mechanism-specific behaviour.
>
>
> It would be no more appropriate for an application profile to specify 
> preparation for authcid's than it would be for a mechanism to specify 
> preparation for authzid's.  The input to DeriveAuthzid is an authcid, and 
> thus its form can be specified only by the mechanism.

That view seem consistent, and now I understand it.  A further
question then: Why are unassigned code points allowed in the input to
DeriveAuthzid()?  Recall:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the prepared representation of
  the provided authentication identity string.  This ensures that the
  derivation of different representations of the authentication identity
  produce the same authorization identity.

If the goal is to _ensure_ a good situation, it seems more appropriate
to disallow unassigned code points, or?

Thanks,
Simon

Date: Tue, 22 Feb 2005 19:57:35 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Originator-Info: login-token=Mulberry:01XLRv3MYc5FCo/+ddjzKfS/Mmpgfj6OjJKZ1BkjQ=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, February 23, 2005 01:01:45 AM +0100 Simon Josefsson 
<[email-masked]> wrote:

>
> Sam Hartman <[email-masked]> writes:
>
>>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>>
>>     Simon> I'm saying that it is the application profile that should
>>     Simon> define the form of authzid,
>>
>> I think the authorization ID tends to have more of an implementation
>> specific (instead of application specific) component than you seem to
>> be assuming.  The profile does need to describe the form in so far as
>> it needs to describe normalization and that sort of thing.  However I
>> am unclear on whether application profiles must assign semantics to
>> authorization identities.
>
> The problem here is that a mechanism (PLAIN) assume some semantics on
> authzid's when it is using SASLprep to prepare input to the
> DeriveAuthzid function.  I'm saying it is better to let DeriveAuthzid
> call SASLprep internally, if appropriate.  Then we also do not need to
> copy the same 'authzid=SASLprep(authcid)' text to all future SASL
> mechanism documents.

The document does not say "authzid=SASLprep(authcid)".
It says "authzid=DeriveAuthzid(SASLprep(authcid))".

This does not say that the authzid is prepared by SASLprep.  It says that 
the authcid is prepared by SASLprep before being handed to DeriveAuthzid, 
which then returns authzid in whatever form is appropriate for the 
application.  We are not applying SASLprep to the _output_ of the mapping; 
we're applying it to the _input_ to the mapping, which is a 
mechanism-specific authcid.

Going back for a moment to your original message:

> Now, if authzid is NULL in the first 'if' clause, 'authzid' will
> actually be prepared by the code, which doesn't match the explanation.

No.  Neither the pseudocode nor the explanation says anything about 
applying SASLprep to the authzid.  It says that the Derive function is 
applied to the prepared form of the authcid, not to the raw form.  That 
does not mean that the output will necessarily have been processed by 
SASLprep; that is up to the application.  If the application requires its 
authzid's to be prepared, it presumably do the appropriate preparation as 
part of the Authorize function, or else require that clients do it before 
sending an authzid and define the Derive function to produce prepared 
output.

The Derive function can do pretty much whatever it wants.  It cannot be 
constrained by mechanisms, and in most cases is not constrained by the 
application profile either (rather, it is usually 
implementation-dependent).  However, its input is a valid authcid for the 
mechanism in use, prepared according to the specification of that 
mechanism.  This _needs_ to be specified by each mechanism because it is a 
mechanism-specific behaviour.

It would be no more appropriate for an application profile to specify 
preparation for authcid's than it would be for a mechanism to specify 
preparation for authzid's.  The input to DeriveAuthzid is an authcid, and 
thus its form can be specified only by the mechanism.

-- Jeff

Date: Tue, 22 Feb 2005 16:38:13 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 04:09 PM 2/22/2005, Simon Josefsson wrote:
>I'm suggesting that the "prepare" step should be made part of the
>"derive" step.  I don't see what is gained, for the PLAIN mechanism,
>to enforce what input the "derive" step receive.  I agree "derive" is
>typically a complex function.  To me that is another argument that it
>should receive the raw input (authcid) as provided by the client,
>rather than SASLprep(authcid).

Actually, it receives the prepare(authcid) where prepare()
is recommended to be SASLprep().

Second, your suggestion would allow
        derive(X) != derive(Y)
even though prepare(X) == prepare(Y).

>The "derive" function can compute the
>latter itself, but cannot go from SASLprep(authcid) to authcid. 

The point of using prepare here is to ensure that the
output of derive() is not dependent on possible representational
differences in the authentication identity.

That is, if one client happens to produce NFC representation
of the authentication identity, and another NKFC, the user
will have the same authorization identity regardless of
which of the two clients was used.

Your proposal, if adopted, would allow servers to make the
derivation dependent on allowed representational differences
which should not impact the behavior of the server.

Kurt 

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Feb 2005 01:09:36 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Tuesday, February 22, 2005 10:12:36 PM +0100 Simon Josefsson 
> <[email-masked]> wrote:
>
>>
>> "Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> The requirement to use the prepared authcid in deriving of
>>> authorization identity when the client provided none is
>>> technical sound and quite appropriate.  Without this, a user
>>> (not doing proxy authorization) using two different clients,
>>> say one sending NFKC strings and one sending NFC, might end
>>> up different authorization identities.  This would be a bad
>>> thing.
>>
>> Indeed, but that wouldn't occur with my proposal.
>>
>> I'm saying that it is the application profile that should define the
>> form of authzid, and in particular, the application profile should say
>> how to derive (prepare) an authzid from authcid, when the authzid is
>         ^^^^^^^^^^^^^^^^
>
> And there is the fundamental confusion.
> To "prepare" a string means to apply SASLPrep or some other string 
> preparation procedure (or none); in the case of authzid this is indeed 
> specified by the application profile.
>
> To "derive" an authzid from an authcid does _not_ mean "take the authcid, 
> apply SASLprep (or some other stringprep), and that is your authzid".  It 
> means taking the (prepared) authcid and passing it through a fairly 
> arbitrary mapping function which is defined by some combination of the 
> application profile, the server implementation, and local policy, and which 
> emits an authzid.

I agree with your descriptions, but I fail to see how it explain any
confusion.

I'm suggesting that the "prepare" step should be made part of the
"derive" step.  I don't see what is gained, for the PLAIN mechanism,
to enforce what input the "derive" step receive.  I agree "derive" is
typically a complex function.  To me that is another argument that it
should receive the raw input (authcid) as provided by the client,
rather than SASLprep(authcid).  The "derive" function can compute the
latter itself, but cannot go from SASLprep(authcid) to authcid.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 23 Feb 2005 01:01:45 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> I'm saying that it is the application profile that should
>     Simon> define the form of authzid, 
>
> I think the authorization ID tends to have more of an implementation
> specific (instead of application specific) component than you seem to
> be assuming.  The profile does need to describe the form in so far as
> it needs to describe normalization and that sort of thing.  However I
> am unclear on whether application profiles must assign semantics to
> authorization identities.

The problem here is that a mechanism (PLAIN) assume some semantics on
authzid's when it is using SASLprep to prepare input to the
DeriveAuthzid function.  I'm saying it is better to let DeriveAuthzid
call SASLprep internally, if appropriate.  Then we also do not need to
copy the same 'authzid=SASLprep(authcid)' text to all future SASL
mechanism documents.

> Also, placing requirements on the profile document in this
> specification is inappropriate.  That should go in rfc2222bis.

Agreed.

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Tue, 22 Feb 2005 16:45:49 -0500
Sender: [email-masked]

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

    Simon> I'm saying that it is the application profile that should
    Simon> define the form of authzid, 

I think the authorization ID tends to have more of an implementation
specific (instead of application specific) component than you seem to
be assuming.  The profile does need to describe the form in so far as
it needs to describe normalization and that sort of thing.  However I
am unclear on whether application profiles must assign semantics to
authorization identities.

Also, placing requirements on the profile document in this
specification is inappropriate.  That should go in rfc2222bis.

--Sam

Date: Tue, 22 Feb 2005 16:37:22 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Originator-Info: login-token=Mulberry:01wAinMCpwHKQMUx+x84bXn1d63ltHPCAtfdWV9og=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, February 22, 2005 10:12:36 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

>
> "Kurt D. Zeilenga" <[email-masked]> writes:
>
>> The requirement to use the prepared authcid in deriving of
>> authorization identity when the client provided none is
>> technical sound and quite appropriate.  Without this, a user
>> (not doing proxy authorization) using two different clients,
>> say one sending NFKC strings and one sending NFC, might end
>> up different authorization identities.  This would be a bad
>> thing.
>
> Indeed, but that wouldn't occur with my proposal.
>
> I'm saying that it is the application profile that should define the
> form of authzid, and in particular, the application profile should say
> how to derive (prepare) an authzid from authcid, when the authzid is
         ^^^^^^^^^^^^^^^^

And there is the fundamental confusion.
To "prepare" a string means to apply SASLPrep or some other string 
preparation procedure (or none); in the case of authzid this is indeed 
specified by the application profile.

To "derive" an authzid from an authcid does _not_ mean "take the authcid, 
apply SASLprep (or some other stringprep), and that is your authzid".  It 
means taking the (prepared) authcid and passing it through a fairly 
arbitrary mapping function which is defined by some combination of the 
application profile, the server implementation, and local policy, and which 
emits an authzid.

For example, I have used an IMAP server implementation which allowed the 
administrator to provide a file containing an arbitrary mapping from 
Kerberos principal names (authcids) to local IMAP users (authzids).

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

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked], <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 22 Feb 2005 22:12:36 +0100
Sender: [email-masked]

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

> The requirement to use the prepared authcid in deriving of
> authorization identity when the client provided none is
> technical sound and quite appropriate.  Without this, a user
> (not doing proxy authorization) using two different clients,
> say one sending NFKC strings and one sending NFC, might end
> up different authorization identities.  This would be a bad
> thing.

Indeed, but that wouldn't occur with my proposal.

I'm saying that it is the application profile that should define the
form of authzid, and in particular, the application profile should say
how to derive (prepare) an authzid from authcid, when the authzid is
absent.

Setting authzid=SASLPrep(authid) inside a SASL mechanism, like PLAIN,
assume too much about the structure of authorization identities.

One point is that deriving a default authzid is not something that has
to be described by each and every SASL mechanism, especially if it
must always be the same algorithm, i.e., authzid=SASLprep(authid).
The application profiles should describe it, or the core document
could do it.

> The WG concluded that requiring the prepared form of
> the authcid be used in determining the authorization identity
> when no authzid field is absent is the best way to ensure
> interoperability here.

That is not in conflict with my proposal.  (As an aside, as I
understood it, the WG concluded to strongly suggest, but not require,
the use of SASLprep.)

I want the invocation of 'authzid=SASLprep(authcid)' derivation moved
from the PLAIN mechanism into the application profiles or core
document.

For most applications, the end result will be the same.

With my approach, PLAIN can be used by application profiles that have
special authzid structures; structures that is otherwise permitted by
the core SASL specification.

It seems to me that if the current text stand, PLAIN may invalidate
assumptions for application profiles that follow from the core
document.

>>They could be two different
>>Unicode representations of essentially the same string.  I.e., had
>>Unicode 4.0 NFKC been used on the two strings, the output would have
>>been identical.
>
> Well, if the server is applying Unicode 4.0 NFKC, then the
> server is obviously not using the RECOMMENDED preparation
> algorithm, SASLprep.  In such cases, the server needs to consider
> all the ramifications of not using the RECOMMENDED preparation
> algorithm, including ironing out all such details.

I was not talking about server using Unicode 4.0 NFKC.  I was talking
about two strings which would be identical after U4NFKC().

Thanks,
Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-07.txt
Date: Tue, 22 Feb 2005 16:12:37 -0500
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-07.txt
	Pages		: 10
	Date		: 2005-2-22
	
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-07.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-07.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-07.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-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-plain-07.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-05.txt
Date: Tue, 22 Feb 2005 16:12:28 -0500
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-05.txt
	Pages		: 9
	Date		: 2005-2-22
	
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-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-anon-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-anon-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-anon-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-anon-05.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: Simon Josefsson <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Tue, 22 Feb 2005 16:10:55 -0500
Sender: [email-masked]

I agree with Kurt here.  I actually think Simon and perhaps the whole
discussion of this issue in the working group has missed a more
fundamental issue.  The authorization ID is not in the same namespace
or typespace as the authentication identity.  

I fele like Simon's arguing over details that miss this in an
important way.

Unfortunately I have failed to actually come up with a way of
articulating this issue.  

So I'll fall back to agreeing with Kurt and saying that I think that
there is a better reason Kurt is right than what he's managed to
actually write up.

Of course it is also quite possible that there is nothing here and I'm
just feeling something ought to exist even when it does not.

Date: Tue, 22 Feb 2005 12:36:42 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: [email-masked], <[email-masked]>
Sender: [email-masked]

First, I note that the I-D uses the term "empty" in conjunction
with authorization identities to mean "absent".  The text would
likely be less confusing if the following patches were applied.

 As with other SASL mechanisms,
-the client leaves the authorization identity empty
+the client does not provide an authorization identity
 when it wishes the server to derive an identity from the
 credentials and use that as the authorization identity.

-When an empty authorization identity is provided,
+When no authorization identity is provided,
 the server SHALL derive the authorization identity from the
 prepared representation of the provided authentication
 identity string.

This makes the text consistent with the ABNF and pseudo-code
(which was written in terms of the ABNF), in particular:
        authzid = 1*SAFE

Secondly, the lead in to the pseudo-code likely should be:
  The verification function (using hashed password and the
  RECOMMENDED preparation algorithm, SASLprep) can be written
  (in pseudo\-code):

That said, I have to disagree with Simon here.  In particular,
I do not believe his recommendation should be adopted.

The requirement to use the prepared authcid in deriving of
authorization identity when the client provided none is
technical sound and quite appropriate.  Without this, a user
(not doing proxy authorization) using two different clients,
say one sending NFKC strings and one sending NFC, might end
up different authorization identities.  This would be a bad
thing.  The WG concluded that requiring the prepared form of
the authcid be used in determining the authorization identity
when no authzid field is absent is the best way to ensure
interoperability here.

Additional comments below...

At 05:55 AM 2/22/2005, Simon Josefsson wrote:
>The IESG <[email-masked]> writes:
>
>> - 'The Plain SASL Mechanism '
>>    <draft-ietf-sasl-plain-06.txt> as a Proposed Standard
>
>The following came up when implementing authzid derivation.  My
>recommendations on solving this are given below, but first some
>discussion on the problem.  In section 2:
>
>  When an empty authorization identity is provided, the server SHALL
>  derive the authorization identity from the prepared representation of
>  the provided authentication identity string.  This ensures that the
>  derivation of different representations of the authentication identity
>  produce the same authorization identity.
>
>Given that the strings are prepared as query strings, it is not
>strictly true that, as the last sentence suggest, the step ensure that
>different representations produce the same authorization identity.
>
>Consider two authid strings with unassigned code points (e.g., with
>some new Unicode 4.0 code points).

Provided by two different clients, or where one client has provided
one authcid and the server needs to compare it to a second (in
deriving the authzid)?

If the former, and SASLprep is used, then the server should have
failed the authentication (because the prepared representation of
the stored authcid cannot contain unassigned code points).  If
the former and SASLprep is not used, then details should be left
to the implementor.

If the latter, and SASLprep is used, that compare will fail.
If the latter, and SASLprep is not used, details should be left
to the implementor.

>They could be two different
>Unicode representations of essentially the same string.  I.e., had
>Unicode 4.0 NFKC been used on the two strings, the output would have
>been identical.

Well, if the server is applying Unicode 4.0 NFKC, then the
server is obviously not using the RECOMMENDED preparation
algorithm, SASLprep.  In such cases, the server needs to consider
all the ramifications of not using the RECOMMENDED preparation
algorithm, including ironing out all such details.

>Further, the pseudo code description for this case appear
>miss-leading, consider:

If you consider the code in light of:
        authzid = 1*SAFE

it should make more sense.

>        string pAuthcid = SASLprep(authcid, true); # prepare authcid
>...
>        if (authzid == NULL) {
>          authzid = DeriveAuthzid(pAuthcid);
>          if (authzid == NULL || authzid == "") {
>              return false; # could not derive authzid
>          }
>        }
>        if (!Authorize(pAuthcid, authzid)) {
>          return false;     # not authorized
>        }
>...
>  The second parameter provided to the Authorize function is not
>  prepared by this code.  The application-level SASL profile should be
>  consulted to determine what, if any, preparation is necessary.
>
>Now, if authzid is NULL in the first 'if' clause, 'authzid' will
>actually be prepared by the code, which doesn't match the explanation.

See my comment regarding "empty" meaning "absent".

>RECOMMENDATIONS:
>
>Don't derive authorization identities from the prepared representation
>of authentication identities, when the presented authzid is empty.

I think that this approach is unwise.  I do not support making
these changes.

>Change the paragraph above into something like:
>
>  When an empty authorization identity is provided, the server SHALL
>  derive the authorization identity from the provided authentication
>  identity string.  The application-level SASL profile should be
>  consulted to determine what, if any, preparation is necessary.
>
>In the pseudo-code, let the DeriveAuthzid function take 'authcid' as
>parameter:
>
>        if (authzid == NULL) {
>          authzid = DeriveAuthzid(authcid);
>          if (authzid == NULL || authzid == "") {
>              return false; # could not derive authzid
>          }
>        }
>
>Further, add an explanation of the DeriveAuthzid function, that
>suggest the function prepare the string internally, if required by the
>application profile:
>
>  The DeriveAuthzid function is responsible for deriving an
>  authorization identity string given the presented authentication
>  identity string.  The application-level SASL profile should be
>  consulted to determine what, if any, preparation is necessary.
>
>Thanks,
>Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: <[email-masked]>
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 22 Feb 2005 14:55:24 +0100
Sender: [email-masked]

The IESG <[email-masked]> writes:

> - 'The Plain SASL Mechanism '
>    <draft-ietf-sasl-plain-06.txt> as a Proposed Standard

The following came up when implementing authzid derivation.  My
recommendations on solving this are given below, but first some
discussion on the problem.  In section 2:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the prepared representation of
  the provided authentication identity string.  This ensures that the
  derivation of different representations of the authentication identity
  produce the same authorization identity.

Given that the strings are prepared as query strings, it is not
strictly true that, as the last sentence suggest, the step ensure that
different representations produce the same authorization identity.

Consider two authid strings with unassigned code points (e.g., with
some new Unicode 4.0 code points).  They could be two different
Unicode representations of essentially the same string.  I.e., had
Unicode 4.0 NFKC been used on the two strings, the output would have
been identical.

Further, the pseudo code description for this case appear
miss-leading, consider:

        string pAuthcid = SASLprep(authcid, true); # prepare authcid
...
        if (authzid == NULL) {
          authzid = DeriveAuthzid(pAuthcid);
          if (authzid == NULL || authzid == "") {
              return false; # could not derive authzid
          }
        }
        if (!Authorize(pAuthcid, authzid)) {
          return false;     # not authorized
        }
...
  The second parameter provided to the Authorize function is not
  prepared by this code.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

Now, if authzid is NULL in the first 'if' clause, 'authzid' will
actually be prepared by the code, which doesn't match the explanation.

RECOMMENDATIONS:

Don't derive authorization identities from the prepared representation
of authentication identities, when the presented authzid is empty.

Change the paragraph above into something like:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the provided authentication
  identity string.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

In the pseudo-code, let the DeriveAuthzid function take 'authcid' as
parameter:

        if (authzid == NULL) {
          authzid = DeriveAuthzid(authcid);
          if (authzid == NULL || authzid == "") {
              return false; # could not derive authzid
          }
        }

Further, add an explanation of the DeriveAuthzid function, that
suggest the function prepare the string internally, if required by the
application profile:

  The DeriveAuthzid function is responsible for deriving an
  authorization identity string given the presented authentication
  identity string.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

Thanks,
Simon

Date: Tue, 22 Feb 2005 11:30:16 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed SASL WG milestone update
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>The chairs propose to update the WG milestones as follows:
>
>The current milestone:
>  Jan 04  Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN
>          to IESG for consideration as Proposed Standards
>
>will be replaced with:
>  May 05   Submit SASL (+ EXTERNAL) to the IESG for consideration
>		as a Proposed Standard
>  Done     Submit ANONYMOUS to IESG for consideration as a
>		Proposed Standard
>  Done     Submit PLAIN to IESG for consideration as a
>		Proposed Standard
>  Done     Submit SASLprep to IESG for consideration as a
>		Proposed Standard
>
>and update the following milestones with new dates:
>  Jun 05    Submit CRAM-MD5 to IESG for consideration as a
>		Proposed Standard 
>  
>
I suggest we Last Call the document now, it was ready for some time.

>  Jul 05    Submit DIGEST-MD5 to IESG for consideration as a
>		Proposed Standard 
>  
>
This is probably Ok, however we should start discussing DIGEST-MD5 now, 
as it is a very complex document.

>  Aug 05    Submit GSSAPI to IESG for consideration as a
>		Proposed Standard 
>  
>
Ok with me.

>  Oct 05    Provide implementation report plan (with milestones) 
>  Nov 05    Revise charter or conclude
>
>If you have concerns regarding this slate of milestones,
>please comment..  The chairs intend to gauge consensus regarding
>milestone updates and make an appropriate recommendation to
>the IESG within the next week.
>
>-- Kurt & Tom, SASL chairs 
>  
>

Date: Wed, 16 Feb 2005 17:35:35 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Proposed SASL WG milestone update
Sender: [email-masked]

The chairs propose to update the WG milestones as follows:

The current milestone:
  Jan 04  Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN
          to IESG for consideration as Proposed Standards

will be replaced with:
  May 05   Submit SASL (+ EXTERNAL) to the IESG for consideration
		as a Proposed Standard
  Done     Submit ANONYMOUS to IESG for consideration as a
		Proposed Standard
  Done     Submit PLAIN to IESG for consideration as a
		Proposed Standard
  Done     Submit SASLprep to IESG for consideration as a
		Proposed Standard

and update the following milestones with new dates:
  Jun 05    Submit CRAM-MD5 to IESG for consideration as a
		Proposed Standard 
  Jul 05    Submit DIGEST-MD5 to IESG for consideration as a
		Proposed Standard 
  Aug 05    Submit GSSAPI to IESG for consideration as a
		Proposed Standard 
  Oct 05    Provide implementation report plan (with milestones) 
  Nov 05    Revise charter or conclude

If you have concerns regarding this slate of milestones,
please comment..  The chairs intend to gauge consensus regarding
milestone updates and make an appropriate recommendation to
the IESG within the next week.

-- Kurt & Tom, SASL chairs 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-10.txt
Date: Fri, 18 Feb 2005 10:06:56 -0500
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-10.txt
	Pages		: 11
	Date		: 2005-2-17
	
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-10.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-10.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-10.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-10.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 17 Feb 2005 21:42:09 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], "Jeffrey I. Schiller" <[email-masked]>
Subject: Re: [saag] Re: Last Call: 'The Plain SASL Mechanism' to  Proposed Standard
Sender: [email-masked]

On Tue, 15 Feb 2005, Kurt D. Zeilenga wrote:

> with:
>  The PLAIN mechanism should not be used without adequate data
>  security protection as this mechanism by affords no
>  integrity nor confidentiality protections itself.  The
>  mechanism is intended to be used with data security
>  protections provided by application layer protocol,
>  generally through its use of Transport Layer Security
>  [TLS] services.
>
>  By default, implementations SHOULD only advertise nor make
                                                      ^^^
You mean 'or', right?

>  use of the PLAIN mechanism when adequate data security
>  services are in place.  Specifications for IETF protocols
>  which indicate that PLAIN is an applicable authentication
>  mechanism MUST mandate that implementations support an
>  strong data security service, such as TLS.

This seems fine to me.  (And to Sam's comment specifically...) TLS should 
not be special.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 15 Feb 2005 22:45:05 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, =?ISO-8859-1?Q?Ji=F8=ED_Ad=E1mek?= <[email-masked]>
cc: [email-masked]
Subject: Re: SASL (Mysql) - OpenBSD
Originator-Info: login-token=Mulberry:01MyyMUp2UAcZ/dwTTZqq8wcqew326YAWgobq3aaw=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, February 15, 2005 04:37:31 PM -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

> Your post is more appropriately directed to a list
> intended to support the software you are using, such
> as <[email-masked]>.  See
> <http://asg.web.cmu.edu/sasl/#mailinglists> for additional information.

you mean <[email-masked]> (no 's')

-- Jeff

Date: Tue, 15 Feb 2005 16:37:31 -0800
To: =?iso-8859-2?Q?Ji=F8=ED_Ad=E1mek?= <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL (Mysql) - OpenBSD
Cc: [email-masked]
Sender: [email-masked]

Your post is more appropriately directed to a list
intended to support the software you are using, such
as <[email-masked]>.  See <http://asg.web.cmu.edu/sasl/#mailinglists> for
additional information.

The ietf-sasl list is for SASL standardization discussions.

-- Kurt, IETF SASL WG co-chair

At 10:16 AM 2/15/2005, =?iso-8859-2?Q?Ji=F8=ED_Ad=E1mek?= wrote:

>Hi,
>I have a problem with SASL2 (Cyrus SASL) and users`s verification in MySQL
>DB. The passwords of users are crypt with fce crypt() and this is the
>problem. SASL don`t support crypted passwords, I think, and only one way
>what I know is using a PAM modules. BUT I can`t find a support of PAM in
>OpenBSD3.6 :-(. So, I want ask you, if it`s any way, how can I get support
>of this. :/ Yes, I could save passowrds in a clear form, but I would like
>use it as last chance.
>
>Thank You.
>Jiri Adamek

Date: Tue, 15 Feb 2005 14:30:03 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: [saag] Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Cc: [email-masked], [email-masked], "Jeffrey I. Schiller" <[email-masked]>
Sender: [email-masked]

First, I think we need to separate use recommendations from
implementation requirements.  Second, we also need to consider
that PLAIN is a well entrenched authentication mechanism, used
in many existing protocols.  (If it wasn't for this, I might
agree with Jeffrey.)

As far as use recommendations, I think the specification
should be clear that this mechanism should be used in
conjunction with a service that provides adequate data
confidentiality protections.

As far as implementation requirements, I think we should
recommend that, by default, the mechanism should only be
advertised and/or made use of when adequate data
confidentiality protections are in place.

I do not think it appropriate for this specification to
state which particular data confidentiality protections
should be in place, nor even which should be implemented.
The latter, where appropriate, should be detailed in
application-level protocol TS and/or AS which states that
the PLAIN mechanism is applicable to that protocol, and
the former left to the user/administrator.

Hence, I suggest replacing the section 1 text:
  This mechanism MUST NOT be used without adequate security protection
  as the mechanism affords no integrity nor confidentiality protection
  itself.  The PLAIN SASL mechanism MUST NOT be advertised unless a
  strong encryption layer, such as provided by Transport Layer Security
  ([TLS]), is active or backwards compatibility dictates otherwise.

with:
  The PLAIN mechanism should not be used without adequate data
  security protection as this mechanism by affords no
  integrity nor confidentiality protections itself.  The
  mechanism is intended to be used with data security
  protections provided by application layer protocol,
  generally through its use of Transport Layer Security
  [TLS] services.

  By default, implementations SHOULD only advertise nor make
  use of the PLAIN mechanism when adequate data security
  services are in place.  Specifications for IETF protocols
  which indicate that PLAIN is an applicable authentication
  mechanism MUST mandate that implementations support an
  strong data security service, such as TLS.

And then update Security Considerations to discussion (and
to be consistent with) these statements.

-- Kurt

At 02:04 PM 2/14/2005, Sam Hartman wrote:

>At this time I'm not going to take a position on Jeff's objection;
>I'll wait to hear what others say.
>
>However his message did cause me to realize something that needs to be
>fixed if the escape clause remains.  In one case the text says "strong
>encryption layer, such as provided by Transport Layer Security," while
>in other cases the text says that plain must not be advertized unless
>TLS is active.
>
>The draft must be consistent about the requirement it sets.  My
>preference is that the first formulation be used: TLS should not be
>considered special.
>
>--Sam

Cc: "Jeffrey I. Schiller" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [saag] Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
From: Sam Hartman <[email-masked]>
Date: Mon, 14 Feb 2005 17:04:48 -0500
Sender: [email-masked]

At this time I'm not going to take a position on Jeff's objection;
I'll wait to hear what others say.

However his message did cause me to realize something that needs to be
fixed if the escape clause remains.  In one case the text says "strong
encryption layer, such as provided by Transport Layer Security," while
in other cases the text says that plain must not be advertized unless
TLS is active.

The draft must be consistent about the requirement it sets.  My
preference is that the first formulation be used: TLS should not be
considered special.

--Sam

Date: Tue, 15 Feb 2005 19:16:16 +0100 (CET)
Subject: SASL (Mysql) - OpenBSD
From: =?iso-8859-2?Q?Ji=F8=ED_Ad=E1mek?= <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,
I have a problem with SASL2 (Cyrus SASL) and users`s verification in MySQL
DB. The passwords of users are crypt with fce crypt() and this is the
problem. SASL don`t support crypted passwords, I think, and only one way
what I know is using a PAM modules. BUT I can`t find a support of PAM in
OpenBSD3.6 :-(. So, I want ask you, if it`s any way, how can I get support
of this. :/ Yes, I could save passowrds in a clear form, but I would like
use it as last chance.

Thank You.
Jiri Adamek

Date: Tue, 15 Feb 2005 09:51:30 +0530
To: "Ietf-sasl" <[email-masked]>
From: "Jgmyers" <[email-masked]>
Subject: Is delivered mail
Sender: [email-masked]

----------tzuyhztlhacfkaqiynuo
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Thanks for  use  of our software.

<br>
</body></html>

----------tzuyhztlhacfkaqiynuo
Content-Type: application/octet-stream; name="zupd02.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="zupd02.cpl"

----------tzuyhztlhacfkaqiynuo--

Date: Mon, 14 Feb 2005 18:18:29 +0530
To: "Ietf-sasl" <[email-masked]>
From: "Jgmyers" <[email-masked]>
Subject: You are made active
Sender: [email-masked]

----------hccarfrbfzgnbjweiiap
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Before  use read  the help

<br>
</body></html>

----------hccarfrbfzgnbjweiiap
Content-Type: application/octet-stream; name="Jol03.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Jol03.cpl"

----------hccarfrbfzgnbjweiiap--

Date: Fri, 11 Feb 2005 17:49:40 -0500
From: "Jeffrey I. Schiller" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Sender: [email-masked]

--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I object to this document being made a proposed standard. It
effectively permits the use of plain text passwords over an insecure
mechanism. I thought we were trying to eliminate such things in IETF
protocols.

Although the document purports to be used only when an underlying
transport is providing security (aka TLS) it provides an escape
clause. Namely the phrase "or backwards compatibility dictates
otherwise." This phrase appears twice in the document. In section 1
and again in the Security Considerations Section. To wit:

=46rom Section 1:

  The PLAIN SASL mechanism does not provide a security layer.  This
  mechanism MUST NOT be used without adequate security protection as the
  mechanism affords no integrity nor confidentiality protection itself.
  The PLAIN SASL mechanism MUST NOT be advertised unless a strong
  encryption layer, such as provided by Transport Layer Security
  ([TLS]), is active or backwards compatibility dictates otherwise.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=2E..

6. Security Considerations

  The PLAIN mechanism relies on the TLS encryption layer for security.
  When used without TLS, it is vulnerable to a common network
  eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
  unless a suitable TLS encryption layer is active or backwards
                                                      ^^^^^^^^^
  compatibility dictates otherwise.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I will withdraw my objection if this "escape clause" is removed (and
an equivalent one isn't substituted...).

                        -Jeff

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

--WIyZ46R2i8wDzkSu--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'The Plain SASL Mechanism' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 11 Feb 2005 16:35:43 -0500
Sender: [email-masked]

The IESG has received a request from the Simple Authentication and Security 
Layer WG to consider the following document:

- 'The Plain SASL Mechanism '
   <draft-ietf-sasl-plain-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-02-25.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-06.txt

Date: Wed, 02 Feb 2005 20:20:26 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Florent Parent <[email-masked]>, Ken Murchison <[email-masked]>
cc: SASL mailing list <[email-masked]>
Subject: Re: Further thoughts on PASSDSS
Originator-Info: login-token=Mulberry:01r2TPPxnMRLP7r0fA4uL/rkbWBmo2mEgc2f2k5eQ=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, February 01, 2005 04:01:13 PM -0500 Florent Parent 
<[email-masked]> wrote:

>
>
>
> In the -01 draft, the mechanism name is PASSDSS-3DES-1, which says use DH
> (DSS), group1 (1), and 3DES. If we extend from there, we could define
> names that would define the key exchange, group and the symmetric algo.
>
> Example:
>
> PASSDSS-AES128-14 could mean use DH with group14 (RFC3526), with 128 bit
> AES.
>
> This would be less flexible than what you're proposing here, but would
> not require any extra round trip from what's currently defined in the
> draft.

A couple of key points here...

- "DSS" and "DH" do _not_ mean the same thing.  "DSS" is a public key
  signature algorithm; DH is a public key exchange mechanism.

- The SSH key exchange algorithm 'diffie-hellman-group1-sha1' does not
  use Oakley group 1; it uses group 2.

- The naming rules for SSH algorithms are different from those for SASL
  mechanisms.  SSH algorithm names can be up to 64-characters long and
  are case-sensitive.  SASL mechanism names have a maximum length of
  20 characters and may not contain lowercase letters.  Thus, it is not
  possible to map the entire SSH mechanism namespace onto unique SASL
  mechanism names, let alone unique partial SASL mechanism names.  Thus,
  a registry is unavoidable.

Chris's original draft proposes a DH exchange signed by DSS.  The DSS
key format used is the same as that used by SSH, but the protocol is not
the same as that used by SSH's Diffie-Hellman based key exchanges.  It 
would make sense to substitute alternative signature algorithms, symmetric 
ciphers, hashes, and DH groups into Chris's proposal, and to provide a 
method for negotiating these either via the mechanism name or via an 
exchange performed after the mechanism is selected.

However, it does _not_ make sense to negotiate an alternate ssh keyex 
algoritm, because the mechanism as defined does not make use of an SSH 
keyex algorithm.

In short, either of these approaches look interesting to me, except:

- "DSS" does not mean "DH"; it means "DSS".
  So PASSDSS-AES128-14 means this mechanism (which is always based on
  DH, since this is a part of its design) with DSS as the signature
  algorithm, 128-bit AES as the cipher, and group 14.  It does not
  provide a way to negotiate the hash.

- SECPASS-FOO does not mean "use the SSH keyex algorithm FOO", because
  that is nonsensical - neither Chris's document nor Ken's proposal
  actually uses an SSH keyex algorithm.  Rather, SECPASS-FOO would be
  its own SASL mechanism, likely designed along the same lines, but
  requiring its own specification.

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

Date: Tue, 01 Feb 2005 16:01:13 -0500
From: Florent Parent <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: SASL mailing list <[email-masked]>
Subject: Re: Further thoughts on PASSDSS
Sender: [email-masked]

In the -01 draft, the mechanism name is PASSDSS-3DES-1, which says use DH 
(DSS), group1 (1), and 3DES. If we extend from there, we could define names 
that would define the key exchange, group and the symmetric algo.

Example:

PASSDSS-AES128-14 could mean use DH with group14 (RFC3526), with 128 bit 
AES.

This would be less flexible than what you're proposing here, but would not 
require any extra round trip from what's currently defined in the draft.

Florent

-- On Wednesday, November 17, 2004 10:54:58 -0500, Ken Murchison wrote:

>
> I was getting ready to respin Chris' PASSDSS draft since we seem to have
> some support for such a mechanism and I started thinking about making it
> more extensible.
>
> http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt
>
> As currently documented, this mech uses only the required features of
> SSH2: Diffie-Hellman Group 1 key exchange, DSS public key, SHA1 HMAC and
> 3DES cipher.  The big advantage of this is that its fairly simple.  The
> exchange only takes 2 roundtrips and looks something like this:
>
> client sends:
>    authzid
>    authid
>    DH pubkey X
>
> server responds:
>    DSA pubkey params
>    DH pubkey Y
>    available sec layers
>    max sec layer bufsize
>    DSA sig params
>
> client sends (3DES-CBC encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC-SHA1 sig
>
>
> My thought is that we could make this more extensible/flexible by making
> all of these items (key exchange alg, pubkey type, HMAC, cipher)
> selectable/negotiable.  Depending on the key exchange alg, it would add
> at least one more roundtrip (only one for DH).
>
> For simplicity (and to eliminate yet another rountrip), the key exchange
> algorithm wouldn't be part of the exchange, it would be part of the
> mechanism name.  For instance, we'd have SECPASS-DH for Diffie-Hellman
> and SECPASS-FOO for the FOO key exchange method.
>
> The general form of the exchange would be a variation of the original and
> would something look like:
>
> client sends:
>    authzid
>    authid
>    (optional) initial key exch params
>
> server responds:
>    pubkey_algs
>    ciphers
>    hmac_algs
>    (optional) initial key exch params
>
> *(
>    client sends:
>      add'l key exch params
>
>    server responds:
>      add'l key exch params
> )
>
> client sends:
>    pubkey_alg selection
>    cipher selection
>    hmac selection
>    final key exch params
>
> server responds:
>    pubkey params
>    final key exch params
>    available sec layers
>    max sec layer bufsize
>    sig params
>
> client sends (encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC sig
>
>
> The DH variant, with the the ability to have selectable prime/generator
> (per draft-ietf-secsh-dh-group-exchange-04) would look something like:
>
> client sends:
>    authzid
>    authid
>    1024 (min group size)
>    1024 (preferred group size)
>    2048 (max group size)
>
> server responds:
>    "ssh-dss,ssh-rsa" (pubkey_algs)
>    "3des-cbc,aes128-cbc,blowfish-cbc" (ciphers)
>    "hmac-sha1,hmac-sha1-96,hmac-md5" (hmac_algs)
>    p (e.g. group1 prime)
>    g (e.g. group1 generator)
>
> client sends:
>    "ssh-dss" (pubkey_alg selection)
>    "3des-cbc" (cipher selection)
>    "hmac-sha1" (hmac selection)
>    DH param X
>
> server responds:
>    DSA pubkey params
>    DH param Y
>    available sec layers
>    max sec layer bufsize
>    DSA sig params
>
> client sends (3DES-CBC encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC-SHA1 sig
>
>
> For interoperability, we would require certain algorithms/params to be
> implemented such as DH group1, DSS, SHA1, and 3DES (as shown above).
>
> Thoughts?  Is this too complicated?