Subject: RE: Use of authorization identity

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

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

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: Tony Hansen <[email-masked]>
Date: Wed, 16 May 2001 20:38:48 -0400

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]

---

From: Tony Hansen <[email-masked]>
Date: Wed, 16 May 2001 20:38:48 -0400

Tony Hansen
	[email-masked]