Subject: RE: AuthMeth issue summary

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 11:47:00 -0800

> -----Original Message-----
> From: Mark Wahl [mailto:[email-masked]]
> Sent: Tuesday, December 07, 1999 12:52 PM
> To: Kurt D. Zeilenga
> Cc: [email-masked]
> Subject: Re: AuthMeth issue summary
> 
> 
> 
> One background item is that we are trying to provide interoperability
> between LDAP users of SASL in advance of all of the SASL 
> framework being 
> completed as PS RFCs.  Some of your issues are more generic 
> SASL discussion 
> points.   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. Authenticate 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.

Paul

---

From: "Bob Blakley" <[email-masked]>
Date: Fri, 10 Dec 1999 15:22:52 -0600

Paul Leach writes:

>> In authmeth-04 as part of a compromise between some 
>> of the groups of 

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Dec 1999 13:36:28 -0800

At 11:57 AM 12/10/99 -0800, Paul Leach (Exchange) wrote: 
>> From: Kurt D. Zeilenga [<mailto:[email-masked]>mailto:[email-masked]] 
>> AuthMeth draft provides a secure Bind mechanism (DIGEST-MD5) 
>> for authentication users who provide a simple username/password. 
>> Though the mechanism describes how to provide an LDAP DN 
>> authorization identity, it doesn't not allow an LDAP DN 
>> authentication identity (DIGEST-MD5 username) [and it shouldn't]. 

> Yes, it does allow an LDAP DN as an authentication ID.

Not without an canonical string representation of an LDAP DN.

DIGEST-MD5 uses arbitrary utf-8 string as the authentication ID.
A utf-8 that differs from another is considered a different
authentication identity.  That is:  "cn=foo" and "CN=FOO" are
two differnet authentication identities in terms of SASL/DIGEST-MD5.

However, "cn=foo" and "CN=FOO" (and "2.5.4.3=#666f4f"), as LDAPDN,
are all refer to the same authentication identity.

Though a SASL/DIGEST-MD5 service could be implemented where the
eight upper case vs lower case varients of "foo" are treated as
the same identity, such approaches, this cannot be done for
LDAP DN in general.  There are countless LDAPDN strings
representing a particular DN (especially when you consider
optional extra spaces, RDN ordering, quoting options, etc.).

>It in fact places no constraints on the form of authentication IDs
>at all (other than that they be strings, ASCII or UTF-8, and
>that the user supply exactly the same value (including case, etc)
>as the server stored when the users account was created).

EXACTLY!  A user cannot be told they can enter an LDAP DN, they
must be told to enter a canonical utf-8 string which represents
their LDAP DN.

> Obviously, the security subsystem on the server would have to use DNs as usernames in order for users to supply DNs as user names.

The SASL/DIGEST subsystem would use a canonical string representation
of a DN as the username.   This is quite different than using the DN.

>> However, I do believe that we need to provide a secure Bind 
>> mechanism for authentication users who provide an LDAP DN as 
>> their authentication identity. 
>
>I believe all the necessary protocol elements are in place
>so that systems can be built that use LDAP DNs as their
>authentication IDs. And for ones that don't.

Given a canonical string representation for LDAP DNs, such that a
client can map the DN provided by the user into the exact string
representation expected by the server, I agree.  However, we do
not have specification for a canonical string representation for
LDAP DNs.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Dec 1999 15:10:54 -0800

At 02:45 PM 12/10/99 -0800, Paul Leach (Exchange) wrote: 
>We are in complete agreement on the last point, and in fact on all the previous >ones you mentioned, _except_ for the claim that this is a deficiency of >SASL/Digest, or even the province of SASL to specify.

I concur that this is NOT a deficiency of SASL/Digest.  I did not
mean to imply such.

I meant only to clarify that LDAP use of of SASL/Digest as defined by
AuthMeth does not provide the LDAP community with a mechanism for
authenticating users identified by LDAP DNs.

The deficiency, in my opinion, is that AuthMeth fails to provide
a mechanism to authenticate users identified by an LDAP DN.

The deficiency, on the other hand, could be my view that this issue
is within the scope of the AuthMeth draft.  If it's not, I strongly
recommend that a statement be added to AuthMeth draft that states
that it does not specify a secure mechanism for authenticating
users identified by LDAP DNs.

	Kurt

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 14:45:47 -0800

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Friday, December 10, 1999 1:36 PM
> 

We are in complete agreement on the last point, and in fact on all the
previous ones you mentioned, _except_ for the claim that this is a
deficiency of SASL/Digest, or even the province of SASL to specify.

I'm certainly happy to have the LDAP WG specify a canonical form of user
names that are LDAP DNs, and to recommend that systems that use DNs as their
user name support it. However, from SASL's point of view, the only
requirement is that the same string be used consistently.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 11:57:03 -0800

> Sent: Tuesday, December 07, 1999 1:07 PM
> To: Mark Wahl

Yes, it does allow an LDAP DN as an authentication ID. It in fact places no
constraints on the form of authentication IDs at all (other than that they
be strings, ASCII or UTF-8, and that the user supply exactly the same value
(including case, etc) as the server stored when the users account was
created).

Obviously, the security subsystem on the server would have to use DNs as
usernames in order for users to supply DNs as user names. Most servers'
OSes, of course, have security subsystems that use a different user naming
scheme than that. Even so, that needn't stop a determined LDAP server writer
from creating their own security subsystem just for the LDAP server (or
similarly the mail server writer, or FTP server writer, or Telnet server
writer) -- at the cost of making users understand a different form of user
name for (potentially) every different server, and the sysadmin having to
administer all the attendant security databases).

> their authentication identity.

I believe all the necessary protocol elements are in place so that systems
can be built that use LDAP DNs as their authentication IDs. And for ones
that don't.

Paul