Subject: authzId in draft-myers-saslrev-00.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Apr 2001 20:23:12 -0700

Think we discussed this pre-publication I-D... maybe at IETF#50.
Anyways, just to ensure this issue gets discussed in regards to
the I-D...

There seems to be a bit of work needed regarding authorization identities
in SASL.

First sentence of last paragraph of 4.1:
   During the authentication protocol exchange, the mechanism performs
   authentication, transmits an authorization identity (frequently known
   as a userid) from the client to server, and negotiates the use of a
   mechanism-specific security layer.

First paragraph of 4.2:
   The authorization identity transmitted during the authentication
   protocol exchange may be different from the identity derived from the
   client's authentication credentials.  When the two are different,
   this is typically referred to as "proxy authentication". 

This implies a couple of things which I believe are incorrect.
First, that the authorization identity is not optional.  Second
that it may be the same as the authentication identity in the
same form as the authentication identity.

If the client wishes to assert the authorization identity derived
from the client's authentication credentials, no authorization
identity SHOULD be provided.  The client MUST NOT assume that
it can derive an authorization identity from its authentication
credential to assert which server will recognize as being equivalent
to the authorization identity which the server might derive from
the client's authentication credential.

I believe section 4.1 and 4.2 conflicts with section 5:
   In order to use this specification, a protocol definition
   MUST supply the following information:
	A specification of how the authorization identity passed
      from the client to the server is to be interpreted.

One cases where clients where it clear where the client cannot
derive an equivalent authorization identity from their credential
is when EXTERNAL is used.  The client does know exactly what the
credential is when using EXTERNAL.  It could be a TLS or IPSEC
credential or it could be something completely different (like
say RFC1413 based authentication (I hope not, but)).

A less obvious case is that SASL leaves the form of the authorization
identity AS WELL AS the authentication identity to authorization
identity mapping requirements to the application protocol's SASL
profile.  LDAP's profile specifically says:
   The method by which a server composes and validates an
   authorization identity from the authentication credentials
   supplied by a client is implementation-specific.

Hence, an LDAP client has no reliable means for deriving an
authorization identity from its credential which would be
guaranteed to match what the LDAP server would derive from the
credential.  This would lead to authorization failures.

As far as I know, all existing SASL profiles leave authcId to
authzId mapping to implementations.

I believe the specification needs to be clear that the authorization
identity should not be asserted unless the client wishes to assert
an authorization identity different (not just in form) from its
authentication identity.  In don't believe this clarification will
break anything as rfc2222 is pretty clear that the client may assert
empty to have the server derive the authorization identity from the
authentication identity.  I am not aware of any profile which says
empty authorization identities are disallowed.

Comments?

Kurt