Subject: Re: AuthzIDs or DNs, but not both

From: "Bob Blakley" <[email-masked]>
Date: Mon, 15 Nov 1999 16:59:38 -0600

Paul Leach responded to Kurt as follows

>> The key issue I am raising is whether or not it makes sense 
>> to have more 
>> than one protocol representation of authorization principals. 
>>  I believe 
>> only one is necessary and that a second is an unnecessary 
>> complication. 
> 
>LDAP servers should be free to use principal names supported by the 
>platform on which they run. 

This is the heart of a discussion we've had several times before in this WG and which 
I thought we'd resolved.  LDAP servers are of course in some sense by definition
"free" to use principal names supported by the platform on which they run, since IETF
doesn't mandate implementation.  However they're NOT free to assume that their
clients know which platforms they run on, or to assume that their clients are willing or
able to generate and authenticate principal names of the sort supported by the server's
platform.

This is the heart of secure interoperability -- does the LDAP protocol specify a principal
namespace, or does it simply assume that the client and the server agree on a principal
namespace and authentication conventions out of band, and only begin to interoperably
use the LDAP protocol after identities have been established and authenticated?

Essentially this amounts to the question of whether an LDAP server has a notion of its
users' identities *AS LDAP USERS* or whether it's merely allowing all kinds of platform
(and maybe non-platform) users into its DIT.

The position of the working group has consistently been (both on the mailing list and
in the FTF meetings) that interoperable security for LDAP should be specified, rather than
simply exposing the underlying platform security.

>Users who are accustomed to a given principal 
>name form should not have to learn the DN form. 

This sounds plausible but carries many assumptions.  Users are accustomed to a variety of 
different principal name forms, and to allow them to use these completely transparently
*and* still have an interoperable environment, it would be necessary to have every server:

(1) be able to distinguish all principal name forms, and to determine to which name
        form a given principal name conforms -- in the absence of explicit name-type indicators
        in some cases.
(2) be able to map all principal name forms to DNs.  Furthermore, in order to prevent
        "identity mutation" when visiting different servers, it would be desirable to have
        every server map every form of name to a DN in exactly the same way -- hence we'd
        need a separate RFC describing the mapping for all "interesting" name forms
        to enable heterogeneous, interoperable configurations.
(3) to be able to support authentication of all name forms (this would require doing the
        mapping as a prerequisite to looking up authentication data in LDAP on the bind)

or else it would be necessary to have every client map the name form provided by the user
into a DN prior to sending it to the LDAP server, but this is what Paul wants to avoid 
in the paragraph below.

>Client software should not 
>have to turn the platform user name into a DN, only to have the server turn 
>it back into the platform user name -- they should just take what the user 
>typed and use that as the uAuthzId. Client software can't do this in a platform independent way.

?? I'm confused... if there's a canonical way to turn each name form into a DN, then 
the client can perform the transformation just as easily as the server.

>So, yes, I believe it makes sense to have more than one representation. Unless 
>that representation is UTF-8 string. 
>And I think it makes clients and servers simpler, not more complicated. 

I don't get this.... can you explain why?

>> The fact that a server can map the uAuthzId to a DN implies 
>> that the client can map a uAuthzId to a DN. 
> 
>That's a fallacy in all except the most trivial sense (that both sides are Turing complete). 
>The client may not, and sometimes should not, have all the information available at the server. 

This I agree with.  However it's not a good assumption that the client NEEDS all the information to which
the server has access in order to do its job.

Normally at a client the user gets a name by logging on to the client system.  Normally this is done using 
a particular, known name form.  This means that the client can in many cases correctly assume the 
form of the name it's mapping from, and so has no confusion about how to map names (unless we
screw up really badly and underspecify the mappings).  There may be strange cases, but perhaps not many...

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 17:29:40 -0800

I'm going to respond to Paul response and Bob's subsequent response in one shot.

Bob Blakley wrote:
> I thought we'd resolved.

Well, I actually checked the archives before posting my authzid creatorsname thread.
I actually found very little on the topic.  Then, again, the discussions could have
taken place on ASID lists or offline.

I only raised this issue now because I just now realized the impact of the addition
of authzid to the protocol and information model.  The functionality of authzid
can be provided by mapping uAuthzIDs onto DNs.  It just as easy for a client to
provide DN "uauthzid=kdz" as it is to provide AuthzId "u: kdz".  There is NO
difference to the user!

(note: I switch to uauthzid attribute type to reflect that I am mapping the
uauthzid scheme of the authorzid).

As far as the issue that servers may want to provide some other mapping, they
are free to do so.  We have operational experience with servers mapping the
bind DN onto another DN.  I did this with "uid=kdz" -> "uid=kdz,dc=openldap,dc=org".
It works fine and doesn't require any protocol changes.  I would suspect that
	uauthzid=kdz -> uid=kdz,dc=openldap,dc=org

would work just fine as well.  I plan to add general support for the above
in OpenLDAP as a "friendly bind" mechanism (which doesn't rely on anonymous
search).

I would like to hear from someone with operational experience using uAuthzIDs.
In particular, what impact did your use of uAuthzIDs have upon required and
optional requirements of LDAP protocol and information model?

> (and maybe non-platform) users into its DIT.

All authentication mechanisms described by RFC specify that authorization identity
is provided as an string of LDAP DN syntax.   It does not state whether or not this
DN is usable by the client in any other context.  That is, the DN used by the
client to bind to the directory not be necessarily be usable in any other
context.

> simply exposing the underlying platform security.

Which implies that we must have one representation of authorization principles that
can be used consistently in the information model.

> Paul wrote:

My suggestion is to restrict the protocol and information model to DN representations
of principals.  Client applications can easily map user provided principal
representation to a DN representation so that it may be carried by the protocol
as currently defined by RFC2251.  I've suggested one possible mapping to make
such generally usable and interoperable.

>        form a given principal name conforms -- in the absence of explicit name-type >	indicators in some cases.

I believe my suggestion adequately addresses this issue.

>        to enable heterogeneous, interoperable configurations.

Yes, I believe that the mapping should be made an RFC which describes both the
form and scope limitations.  (That is, the uauthz DNs are unique only within
the local context).

>        mapping as a prerequisite to looking up authentication data in LDAP on the bind)

I suggest only one name form, DN.

>into a DN prior to sending it to the LDAP server, but this is what Paul wants to avoid 

Well, the client needs to either map the user provided string into an authzid or
needs to map it into a DN... and the server needs to decode it.  The amount of
real work is the same.  The difference is one on-the-wire representation or two.

>the client can perform the transformation just as easily as the server.

Exactly.

>I don't get this.... can you explain why?

The syntax of the uAuthzId attribute type can be DirectoryString.

>>The client may not, and sometimes should not, have all the information available at the server.

The server need not provide any information to the client to do the suggested mapping.

All the client needs to do is instead of creating an AuthzID of uAuthzID scheme
as suggested by the AuthMeth draft and instead maps the uAuthzID value to a DN
of the form uAuthzID=string.   This eliminates the need for a second on-the-wire
representation of authorization principals, eliminates the ripple of changes
to the information model cause by adding a second representation, and at no
apparent loss in functionality.