Re: AuthMeth issue summary

Paul Leach writes:

>> In authmeth-04 as part of a compromise between some
>> of the groups of
>> implementors / users of authorization IDs in LDAP, we
>> provided a specification
>> of authorization identities that allows for both DNs and
>> arbitrary user
>> identities. (RFC 2222 4. #5 states that a protocol defines
>> how the authorization
>> identity is to be interpreted). I would hope that there would
>> be a SASL work
>> item at some point to more fully define how authorization
>> identities can be
>> used that is independent of the underlying protocol: e.g. I
>> want to have a
>> common authorization identity for a Web site accessed via
>> HTTP, an IMAP store,
>> an LDAP directory, etc. Furthermore I would want to ensure
>> that access control
>> systems which use authorization identities in implementations
>> of each of
>> the underlying protocols can make interoperable decisions,
>> such as how to
>> - validate an authorization identity (e.g. identities with a
>> expiry date)
>> - compare two authorization identities for equality,
>> - map different kinds of real-world identities to authorization ids,
>> - express containment, wildcards, role<->occupant and group<->member
>> relationships between authorization identities,
>> - know whether an authorization identity is a capability and
>> should be
>> protected as such etc

>I don't believe that most of this is the province of SASL.

>1. Authentication protocols authenticate identities. They don't care what the identities _are_.
>2. Authorization mechanisms deal with issues like group membership, not authentication protocols.
>3. Ditto with capabilities.
>4. Ditto with account expiration.

I entirely agree with Paul. SASL should NOT provide this functionality at all. There's no reason a priori

to believe that a client and a server which can agree on a subject's authentication "identity" (e.g. the

DN or some other field in an X.509 cert) will necessarily be able to agree on ANY aspect of

the authorization attribute set for the same subject, so it may not even be POSSIBLE to "validate

an authorization identity". Comparing two authorization attributes for equality also raises a lot

of complex issues. Many organizations may share the same role name (e.g. "VP", "sys-admin")

without sharing ANY of the semantics associated with that role name. What would be wanted

for a function like this would be not lexical equality, but semantic equivalence -- which is hard

even to express, much less to check.

Furthermore, even if a client & server could agree on the syntax and semantics of authorization

attributes, the client might not have access to any service competent to validly assert those

attributes (for example, because the subject sitting at the client machine might not be a member of

the domain in which the attributes are defined). This could happen for example in environments

in which authorization ids or roles are built up (by the receiving system) by regular-_expression_ matching

based on the domain the subject inhabits or some other subject characteristic. The underlying problem

here is that push-protocol authorization data assumes a very intimate trust relationship between the

client and the server: the client must have access to some service which in effect says to the server

"this user is allowed to do X to *your* resources". But in an Internet environment I think this scenario

is rare. It's much more sensible for (1) the client to have access to some service which says "this subject

is Joe", and then (2) have the server have access to some service *living within the server's trust domain*

which says "Joe is allowed to do X in my system".

SASL is designed to authenticate clients to servers, & so (appropriately) it does (1). However

interaction (2) isn't necessarily (or even typically) an interaction between the client & the server -

it's often an interaction between the server & something else. And so SASL is the wrong protocol

to do (2).