Re: AuthzIDs or DNs, but not both

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