Subject: RE: Use of authorization identity

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

At 03:12 PM 5/17/01, John Brezak wrote:
>What is that "known encoding"?
>
>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

>> -----Original Message-----
>> From: Tim Martin [mailto:[email-masked]] 
>> Sent: Thursday, May 17, 2001 2:57 PM
>> To: John Brezak; [email-masked]
>> Subject: RE: Use of authorization identity
>> 
>> 
>> 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?
>> 
>> 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: John Gardiner Myers <[email-masked]>
Date: Thu, 17 May 2001 17:53:39 -0700

"Kurt D. Zeilenga" wrote:
> For another protocol authzIds could be DER

I did intend to have the authorization identity be a character string,
with NUL characters prohibited.  That assumption is made by the SASL
libraries I am familiar with.

The character encoding scheme used for transmitting this character
string is entirely in the domain of the mechanism.  Some may find UTF-8
more convenient, some may prefer UTF-16-be, some may require more
complex encodings.  DIGEST-MD5, for example, will use either ISO-8859-1
or UTF-8, depending on circumstances.  In a SASL implementation, it is
the job of the SASL mechanism code to convert from the
mechansim-specific encoding to the SASL implementation's canonical form,
just like it is the mechanism code's job to represent the authentication
identity in the SASL implementation's canonical form.

There is a limit to how far any standard can specify the interpretation
of an authorization identity, as an authorization identity (or "userid")
is fundamentally implementation-defined.

Similarly, a proxying policy, being a policy, is
implementation-defined.  It is a perfectly valid policy to prohibit all
users from proxying to any other users.

---

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

At 05:53 PM 5/17/01, John Gardiner Myers wrote:
>with NUL characters prohibited.

That may have been the intent, but RFC 2222 notes places no
restriction upon authorization identities passed by mechanisms
nor any restrictions upon form specified by the profile.

Even adding a NUL restriction could break things as EXTERNAL,
S/KEY, and GSSAPI (as defined in RFC 2222) allowed arbitrary
authorization identities to be passed via SASL.

It seems that the latest I-D attempts to restrict authorization
identities to UTF-8.  It says nothing about NUL characters
and nothing about how to support encoding of the profile
specific authorization identities.

Such restrictions are new to the I-D.  We should be very
careful here to 1) avoid breaking things that work and 2)
avoid adding new features which would cause this specification
to have to reissued at Proposed.

>That assumption is made by the SASL libraries I am familiar with.

While that may be true, that's their limitation, not a general
limitation.  I know of multiple independently developed LDAP
implementations supporting SASL external with authorization
identities which can legally contain zero-valued octets.  (I
don't think anyone uses ids containing zero-valued octets in
their deployments, but these implementations do support it).

Now, we can argue until we're blue in the face about what
should have been.  The questions for today is:
        Does the lack of an authorization identity encoding
        restriction upon authorization identities break SASL?

I content the answer is no.  SASL is not broken, it doesn't
need to be fixed.
        
You can take this an objection to adding a UTF-8 restriction
upon authorization identities in general or to EXTERNAL (as
in the current SASL I-D).

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 16:35:15 -0700

> nor any restrictions upon form specified by the profile.

Clearly we have an open issue.
 
> authorization identities to be passed via SASL.

Do you know of any implementations which would be broken by the addition
of such a restriction?
 
> specific authorization identities.

The latest I-D was written with the same assumption that the
authorization identity was a character string.  It added a specification
of the charset used by the EXTERNAL mechanism, resolving an omission in
the original specification.

> to have to reissued at Proposed.

Restricting the authorization id to a string and prohibiting NUL
characters is not adding a new feature.  If anything, it is removing a
feature that has been demonstrated to be noninteroperable.

> I content the answer is no.  SASL is not broken, it doesn't

I disagree.  There exist widely deployed SASL mechanisms and
implementations which are incapable of carrying non-character-string
authorization identities.  Implementations which expect to use
non-character-string authorization identities will fail to interoperate
with such mechanisms and implementations.

A specification which permits two conforming implementations to fail to
interoperate (when such noninteroperation is not required by policy) is
broken.

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 17 May 2001 17:53:39 -0700

---

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

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 16:35:15 -0700