Subject: Use of authorization identity

From: "John Brezak" <[email-masked]>
Date: Tue, 15 May 2001 16:01:55 -0700

In the SASL I-D (and RFC2222) there is mention of an authorization
identity. In the I-D there is clarification of its intended use for
proxies.

What errors can should be returned in these cases:

1) authenticated user is not allowed to operate as the authz id
2) authz id doesn't exist (should you interpret this as the empty authz
id?)

Or should the SASL protocol just pass this information along to the
application protocol that would then handle the error cases?

But in this case I can't see how the proxy part applies in a general
sense. The application protocol may not distinguish between an
authentication identity and authorization identity. It may not even be
valid in this case.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-936-2602
One Microsoft Way
Redmond, WA 98052

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 May 2001 08:54:49 -0700

At 04:01 PM 5/15/01, John Brezak wrote:

>In the SASL I-D (and RFC2222) there is mention of an authorization identity. In the I-D there is clarification of its intended use for proxies.
>
>2) authz id doesn't exist (should you interpret this as the empty authz id?) 

It's my opinion that both should result in a "bad authorization"
error.  Note that each protocol which makes use of SASL has to
define its own mechanism for handling this.  However, I believe
it would be generally inappropriate for a non-existent authzId to
be interpreted as an empty authzid.  Of course, the handling of
authzIds is protocol specific (see item 5 of section 4).

>Or should the SASL protocol just pass this information along to the application protocol that would then handle the error cases?

SASL has no means for transferring error information between peers,
that is left to the protocol making use of SASL (see item 3 of
section 4).

>But in this case I can't see how the proxy part applies in a general sense. The application protocol may not distinguish between an authentication identity and authorization identity. It may not even be valid in this case.

Well, I would say that SASL provides a framework for one to add
proxying capabilities to protocols (LDAP is an example of a protocol
which made no distinction between these identities until SASL was
added).  It may not make sense to add proxying support and in such
cases one can easily write a SASL profile which says that
authorization identities shall be empty and interpreted as implying
the authorization associated with the authentication identity.  I,
however, would suggest something more like "support for non-empty
authorization identity in this protocol is not defined currently
but may be defined by extension".

---

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 14:06:19 -0700

I would suggest that the SASL I-D should not infer any use for the
authz_id for protocols employing SASL. How an application protocol makes
use of the SASL authz_id should be left entirely up to the application.

Also the encoding should be consistent between all SASL authentication
methods - UTF-8, otherwise the application needs to know too much about
the authentication method used to make use of it.

I would recommend removing any suggest use - like proxy from the I-D and
simply specify that it its use is application define and specify the
encoded format. A generic purpose like "for use by the application
protocol. Also that it is optionally provided by the client.

Is an application using SASL required to utilize the authz_id?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2001 8:55 AM
To: John Brezak
Cc: [email-masked]
Subject: Re: Use of authorization identity

id?) 

It's my opinion that both should result in a "bad authorization" error.
Note that each protocol which makes use of SASL has to define its own
mechanism for handling this.  However, I believe it would be generally
inappropriate for a non-existent authzId to be interpreted as an empty
authzid.  Of course, the handling of authzIds is protocol specific (see
item 5 of section 4).

>application protocol that would then handle the error cases?

SASL has no means for transferring error information between peers, that
is left to the protocol making use of SASL (see item 3 of section 4).

>authentication identity and authorization identity. It may not even be 

Well, I would say that SASL provides a framework for one to add proxying
capabilities to protocols (LDAP is an example of a protocol which made
no distinction between these identities until SASL was added).  It may
not make sense to add proxying support and in such cases one can easily
write a SASL profile which says that authorization identities shall be
empty and interpreted as implying the authorization associated with the
authentication identity.  I, however, would suggest something more like
"support for non-empty authorization identity in this protocol is not
defined currently but may be defined by extension".

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 May 2001 15:49:56 -0700

At 02:06 PM 5/16/01, John Brezak wrote:
>authz_id for protocols employing SASL.

It doesn't.  rfc2222 (and this I-D) says the protocol's profile
provides:
   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

That is, SASL doesn't say how a non-empty authzId is to be interpreted.
(SASL does say how an absent/empty authzId is to be interpreted)

>How an application protocol makes

The specification of the application protocol may choose to do
so... or it may not.  Examples of both can be found [BEEP and LDAP,
respectively].

>the authentication method used to make use of it.

Currently SASL itself places no restrictions upon the encoding/form of
the authorization identity.  Some mechanisms do.  I would suggest
that SASL itself not place restrictions upon the encoding/form of the
authorization identity as this would limit the types of mechanisms
which SASL can support.

Obviously if an application protocol and a mechanism have incompatible
requirements upon the authzId, they cannot be used together to support
authorization proxying.

>encoded format.

I disagree.  I believe it is every important for the I-D to describe
the intended use of the field.  Proxy authorization is the intended
use.

>A generic purpose like "for use by the application

This field is not a meaningless BLOB and application protocols
(and applications) should not use it for unintended purposes.  The
use of this field is to allow a client to assert an authorization
identity different from the authentication identity.

>Is an application using SASL required to utilize the authz_id?

No.  A client only needs to assert an authzId when the user
desires to take on rights of an authorization identity different
from those which the user's authentication identity implies.
That is, a client which is not using the proxy feature should
specify an empty authzId.

---

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 16:04:27 -0700

> Sent: Wednesday, May 16, 2001 3:50 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: RE: Use of authorization identity
> 
> 
> That is, SASL doesn't say how a non-empty authzId is to be 
> interpreted. (SASL does say how an absent/empty authzId is to 
> be interpreted)

It does - it suggests that the application protocol use it for an
identity
that the authenticated user perform the application specific operation
as.

> The specification of the application protocol may choose to 
> do so... or it may not.  Examples of both can be found [BEEP 
> and LDAP, respectively].

Does this mean that the proxy in the I-D is not required?

> Currently SASL itself places no restrictions upon the 
> encoding/form of the authorization identity.  Some mechanisms 
> do.  I would suggest that SASL itself not place restrictions 
> upon the encoding/form of the authorization identity as this 
> would limit the types of mechanisms which SASL can support.
> 
> Obviously if an application protocol and a mechanism have 
> incompatible requirements upon the authzId, they cannot be 
> used together to support authorization proxying.

You need to keep the encoding of the name form consistent between
authentication protocols. Otherwise the application will have to
know what protocol was used in the authentication and apply the
correct format conversion function. If SASL is suppose to abstract
the authentication negotiation process, any outputs from that process
to be used by the application should also be abstracted to a common
encoding form.

> 
> >I would recommend removing any suggest use - like proxy from the I-D 
> >and simply specify that it its use is application define and specify 
> >the encoded format.
> 
> I disagree.  I believe it is every important for the I-D to 
> describe the intended use of the field.  Proxy authorization 
> is the intended use.

I read it as requiring protocols to implement proxy behaviors as
specified
in the SASL I-D.

> This field is not a meaningless BLOB and application 
> protocols (and applications) should not use it for unintended 
> purposes.  The use of this field is to allow a client to 
> assert an authorization identity different from the 
> authentication identity.

It is an application defined authz identity. The proxy should be
worded as an example use of such an authz_id, but shouldn't imply
that all applications employing SASL MUST implement a proxy mechanism.

> desires to take on rights of an authorization identity 
> different from those which the user's authentication identity 
> implies. That is, a client which is not using the proxy 
> feature should specify an empty authzId.

What about protocols that have no notion of an identity split as you
are describing? Does any application using SASL have to now build in
this behavior?

Use of SASL shouldn't require the ability of an application to deal with
this proxy mechanism. What if the application already had its own
"proxy" mechanism?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 May 2001 18:16:36 -0700

SASL only provides a framework for application protocols to
implement authentication and security services.  These services
include proxy authorization and data protection. It's up
to the application protocol's SASL profile to detail how it
makes use of SASL, including how the proxy authorization feature
is to used (if at all).  I believe SASL appropriately leaves
the form of the authorization identity to the application
protocol's SASL profile.  Some application protocols
have very specific requirements in this area (such as those
of LDAP), others have no specific requirements (BEEP) and
hence defer the specification to others.

Kurt

---

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 18:28:01 -0700

Is there a LDAP SASL profile published that describes how the SASL proxy
feature is to be used? What about the other SASL applications?

There needs to be wording in the I-D stating that the use of the SASL
proxy feature is optional in applications that use SASL and its use is
described outside of the I-D.

I still maintain that the encoding (UTF-8) of the authz_id needs to be
independent of the authentication mechanism.

> Sent: Wednesday, May 16, 2001 6:17 PM
> To: John Brezak
> Cc: [email-masked]
> implement authentication and security services.  These 
> services include proxy authorization and data protection. 
> It's up to the application protocol's SASL profile to detail 
> how it makes use of SASL, including how the proxy 
> authorization feature is to used (if at all).  I believe SASL 
> appropriately leaves the form of the authorization identity 
> to the application protocol's SASL profile.  Some application 
> protocols have very specific requirements in this area (such 
> as those of LDAP), others have no specific requirements 
> (BEEP) and hence defer the specification to others.
> 
> Kurt
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 May 2001 19:31:05 -0700

At 06:28 PM 5/16/01, John Brezak wrote:
>feature is to be used?

The LDAP SASL profile (RFC2251,RFC2829) says how the authorization
identity is to be interpreted.  It does not state how a server is
to determine the validity of the authorization identity assertion.
That an area left to implementations and/or future standardization.

>What about the other SASL applications?

All SASL profiles should specify how to interpret the authorization
identity.  Some may leave everything, including form, to implementations
others may be quite specific not only as to the form but exactly how
the authorization identity assertion is to validated.  (Most take the
former approach).

---

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 17:55:55 -0700

Is the description of the intended use a requirement? In this case do
all applications that are to employ SASL authentication required to
support proxy?

If so, then how is proxy to be used in existing applications that are
using SASL - LDAP, IMAP?

I still maintain that the encoding of the authz_id must be independent
of authentication mechanism for an application to be able to make use of
it.

> From: Tony Hansen [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 5:39 PM
> To: John Brezak
> Cc: [email-masked]
> I must forcefully disagree. A statement like "for use by the 
> application protocol" is absolutely useless. If I can't write 
> a client application that uses a protocol feature and know 
> what it's going to do, then the "feature" is instead a 
> misfeature. So SASL MUST give a description of the definition 
> of the field and its intended use.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> John Brezak wrote:
> > 
> > authz_id for protocols employing SASL. How an application protocol 
> > makes use of the SASL authz_id should be left entirely up to the 
> > application.
> > 
> > methods - UTF-8, otherwise the application needs to know too much 
> > about the authentication method used to make use of it.
> > 
> > the encoded format. A generic purpose like "for use by the 
> application 
> > error. Note that each protocol which makes use of SASL has 
> to define 
> > its own mechanism for handling this.  However, I believe it 
> would be 
> > generally inappropriate for a non-existent authzId to be 
> interpreted 
> > as an empty authzid.  Of course, the handling of authzIds 
> is protocol 
> > specific (see item 5 of section 4).
> > 
> > that is left to the protocol making use of SASL (see item 3 
> of section 
> > 4).
> > 
> > >authentication identity and authorization identity. It may 
> not even 
> > >be valid in this case.
> > 
> > authorization identity in this protocol is not defined 
> currently but 
> > may be defined by extension".
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 May 2001 20:35:12 -0700

At 05:55 PM 5/16/01, John Brezak wrote:
>Is the description of the intended use a requirement?

In general, no.

>In this case do

A profile MUST specify how to interpret an authorization identity
asserted using the proxy mechanism.  However, a profile need not
mandate that all implementations of that profile support the
proxy mechanism.  If a profile however does mandate such, then
all applications implementing that profile MUST implement it.

>If so, then how is proxy to be used in existing applications that are

For LDAPv3, SASL proxy is to be used as described in RFC 2829.
For other protocols, it's to be used as described by their
SASL profiles.

>of authentication mechanism for an application to be able to make use of

Currently, the encoding of the authzId is mechanism specific
but the form is application protocol specific.  Each mechanism
should describe the means for encoding any set of octets
representing an authorization identity.  Otherwise, one could
not assert a BER encoded X.500(4th edition) distinguished name
(if that was what application protocol specified as the form).

Some mechanisms are capable of transferring the identity as
an arbitrary string of octets.  Requiring such mechanisms to
encode the identity using UTF-8 is unnecessary work.  Other
mechanisms may already be limited to UTF-8 and hence it
may be appropriate for them to encode the identity into some
UTF-8 string.  However, the exact encoding used must take
into account restrictions of the mechanisms syntax.  For
example, DIGEST-MD5 syntax requires different escaping
requirements necessary to support the mechanism.

I believe it would be unwise at this stage in the standardization
of SASL to place new restrictions upon the encoding/forms of
identities previously left to mechanisms and/or profiles.

Kurt

---

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 22:50:17 -0700

> Sent: Wednesday, May 16, 2001 8:35 PM
> To: John Brezak
> Cc: Tony Hansen; [email-masked]
> A profile MUST specify how to interpret an authorization 
> identity asserted using the proxy mechanism.  However, a 
> profile need not mandate that all implementations of that 
> profile support the proxy mechanism.  If a profile however 
> does mandate such, then all applications implementing that 
> profile MUST implement it.

So something like this language needs to be in the SASL I-D passing the
requirement to application profiles describing the use of SASL.

> For LDAPv3, SASL proxy is to be used as described in RFC 
> 2829. For other protocols, it's to be used as described by 
> their SASL profiles.

I'll have a look at LDAP. Others?

> >of authentication mechanism for an application to be able to 
> make use 
> >of it.
> 
> but the form is application protocol specific.  Each 
> mechanism should describe the means for encoding any set of 
> octets representing an authorization identity.  Otherwise, 
> one could not assert a BER encoded X.500(4th edition) 
> distinguished name (if that was what application protocol 
> specified as the form).
> 
> mechanisms may already be limited to UTF-8 and hence it may 
> be appropriate for them to encode the identity into some 
> I believe it would be unwise at this stage in the 
> standardization of SASL to place new restrictions upon the 
> encoding/forms of identities previously left to mechanisms 
> and/or profiles.

I disagree. If the point is for the application to not have to know
how to deal with different authentication mechanisms, why should the
application have to know what character encoding the authz_id is going
to be in based on what authentication mechanism is selected?

This does not allow new authentication mechanisms to be swapped into
an application with modification of the app. A benefit of SASL is to
make authentication easy and mechanism independent for applications.

---

From: Tim Martin <[email-masked]>
Date: Thu, 17 May 2001 14:57:08 -0700

Excerpts From "John Brezak" <[email-masked]>:
Message
>application have to know what character encoding the authz_id is ing

The SASL library knows about the specific mechanism encodings and 
can convert the authzid's to a known encoding before asking the 
application "can <authid> proxy as <authzid>?"

-Tim

---

From: [email-masked]
Date: Thu, 17 May 2001 15:46:47 -0700 (PDT)

>What is that "known encoding"?

Whatever your SASL library defines it as.

-Tim

---

From: "John Brezak" <[email-masked]>
Date: Thu, 17 May 2001 15:12:13 -0700

I see that RFC-2829 specifies that authz_id names are to be UTF-8.

> From: Tim Martin [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2001 2:57 PM
> To: John Brezak; [email-masked]
> Excerpts From "John Brezak" <[email-masked]>: Message
> >I disagree. If the point is for the application to not have 
> to know how 
> >to deal with different authentication mechanisms, why should the 
> >application have to know what character encoding the 
> authz_id is ing to 
> >be in based on what authentication mechanism is selected?
>

---

From: [email-masked]
Date: Thu, 17 May 2001 16:57:15 -0700 (PDT)

>In the case of LDAP that is UTF-8 for all of the authentication
>mechanisms. I'm looking at the protocol definitions, not the
>implementations.
>
>I guess I'm thinking that SASL provides a level of abstraction for
>applications to be able to use a collection of authentication mechanisms
>without the application having to know about the mechanisms. Clearly
>this isn't the case.

I think you're missing a level of abstraction. Typically you have a layer between the application and the mechanisms that has knowledge of how specific mechanisms work. This layer can present a uniform view to the application. In the case of the authzid it can convert the string from whatever form the mechanism used to utf8 when passing the string to the application.

-Tim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 17 May 2001 17:13:45 -0700

>I see that RFC-2829 specifies that authz_id names are to be UTF-8.

That's for LDAP.  For another protocol authzIds could be DER
encoded distinguished names.  In any case, each mechanism has
differing requirements on how authzIds need to be encoded.
So, for example, when a client wants to specify some authzId
(which should be in form described in the appropriate
profile), the API encodes it as necessary for that mechanism.
For mechanisms which transfer the authzId as an octet string
(such as RFC 2222 - EXTERNAL), no encoding is necessary.  For
mechanisms (such as RFC2831 - DIGEST-MD5) which transfer the
authzId in some restricted encoding (such as a subset of UTF-8),
then the authzId provided by the application must be reencoded
as needed.  For example, if the LDAPv3 authzId was
        dn:CN=Joe,O="FOO BAR"

then the DIGEST-MD5 authzId field would look like:
        authzid="dn:CN=Joe,O=\22FOO BAR\22"

The biggest authzid problem I see currently is mechanisms
overly restricting the encoding.  For example, some mechanisms
restrict the authzid to "visible" UTF-8 and provide no
escaping mechanism.  This disallows valid (per the profile's
authorization identity form) from being transferred by the
mechanism.  Each mechanism should define the algorithm to
encode an arbitrary data containing the profile specific
authzid.

Kurt

---

From: "John Brezak" <[email-masked]>
Date: Thu, 17 May 2001 16:13:28 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2001 3:47 PM
> To: [email-masked]; John Brezak

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 19 May 2001 08:59:37 +1000

>without the application having to know about the mechanisms. Clearly

if i understood it correctly, John is arguing the following case:

1. any datum defined in a SASL mechanism that is to be used between the 
SASL client/server and its couterpart is supposed to be fully described, in 
terms of how it's encoded and should be interpreted, by the SASL mechanism.

2. the authorization-id, is an entity that is included in all mechanisms 
because it's defined in the SASL specs.  hence although some mechanisms do 
not, directly, make use of this entity they have to include it in their 
specifications (of the exchanges between client and server).

3. as soon as the authorization-id information has to be communicated to a 
module (proxy or otherwise), external to the SASL mechanism, the 
implementor of a mechanism has to know (a) what type this entity is; eg. 
string, numeric, octet-string, etc... and (b) how to encode/decode it; eg. 
length followed by bytes, utf-8 characters preceded by their length, 
der-encoded stream, etc...

4. even if this information is defined/specified by a SASL profile, and 
because more than one profile may use the same SASL mechanism, (a) the 
problem of interpreting such information remains, and (b) the designer of a 
SASL mechanism, as long as information similar in function/purpose to the 
authorization-id have not been fully specified in the SASL specs 
themselves, has the onus of doing it in the mechanism specification.

if i got it right so far i believe it makes more sense to fully specify 
this in the SASL specs rather than every time, and potentially with 
multiple forms/options, in mechanisms and profiles.  the disadvantage of 
imposing one way of encoding such information, and the cost of translating 
it to another form, is in my opinion a lesser evil.

a utf-8 character-sequence preceded by a one-octet designating the count of 
following characters would be appropriate for string literals.  or if the 
objective is to allow for more than just string literals, a big-endian 
octet-sequence preceded by a one-octet length should do the job.  in both 
cases the implied limit is 255 octets of meaningful data.

cheers;
rsn