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

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 17:53:58 -0700

"Kurt D. Zeilenga" wrote:
> First, that the authorization identity is not optional.

With respect to this document, an authorization identity is indeed
always transmitted from the client to the server by the authentication
protocol exchange.  The transmitted authorization identity may be the
empty string and some mechanisms, such as CRAM-MD5, are only capable of
transmitting the empty string.

How a particular mechanism encodes an authorization identity of the
empty string is of no concern to this document.

Trying to distinguish cases of "no authorization identiy" and
"authorization identity of the empty string" is simply asking for
trouble.  DIGEST-MD5 has had interoperability problems caused by the
fact that it provides two different ways to encode an authorization
identity of the empty string.

> Second

Indeed it can.  There is no reason to disallow this.  The client may not
even be able to determine what the identity in the user's credentials
is.

> the client's authentication credential.

I oppose adding either statement.  The document clearly states how a
client is to assert the auathorization identity derived from the
credentials.

>       from the client to the server is to be interpreted.

How does this conflict?

> authzId mapping to implementations.

This is inherently an implementation (or site) defined mapping.

Have you seen implementors incorrectly sending non-empty authorization
ids?

Does the following rewording of section 4.2 address your concern?

The identity derived from the client's
authentication credentials is known as the "authentication identity".
With any mechanism, transmitting an
authorization identity of the empty string directs the server to derive
an authorization identity from the client's authentication
identity.

If the authorization identity transmitted during the authentication
protocol exchange is not the empty string, this is typically referred
to as "proxy authentication".  This feature permits agents such as
proxy servers to authenticate using their own credentials, yet request
the access privileges of the identity for which they are proxying.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 18:22:30 -0700

>>       from the client to the server is to be interpreted.

Because the previous sections imply that its not up to the
protocol definition.

>This is inherently an implementation (or site) defined mapping.

Or profile specific.  That is, an application protocol TS
can define how the mapping is to occur if it chooses to.

>Have you seen implementors incorrectly sending non-empty authorization

YES!  I see applications authentication user "foo" just stuff
"foo" in the authorization id (unless the client asserted something
different).  An authentication identity "foo" is not necessarily
equivalent to the authorization identity "foo".

>Does the following rewording of section 4.2 address your concern?

I think this goes to a long way to clarifying my concerns.
I still am concerned that clients developers might continue
to believe they can map an authentication identity to
authorization identity in the same manner that a server
does without a priori knowledge of that server's implementation
of said mapping.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 18:50:16 -0700

I propose appending to the previous reword of section 4.2:

As a client might not have the same information as the server,
clients SHOULD NOT themselves try to derive authorization identities
from auhentication identities when clients could instead transmit an
authorization identity of the empty string.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 19:42:25 -0700

>authorization identity of the empty string.

This and your previous reword of 4.2 would adequately
address my concerns.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 17:53:58 -0700

How does this conflict?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 18:22:30 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 18:50:16 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 19:42:25 -0700