Subject: RE: AuthzIDs or DNs, but not both

From: "Curtin, William" <[email-masked]>
Date: Mon, 15 Nov 1999 13:47:52 -0500

Perhaps the use of the word INTERNAL was a poor choice. By internal I meant
that the server would map the uAuthzId used for authentication into the
distinguished name associated with the uAuthzId to support operational
attributes, access control, etc. Is there a better way to phrase it?

							bill

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 1:24 PM
> To: Curtin, William
> Cc: 'Harald Tveit Alvestrand'; [email-masked]; IETF LDAP Extensions
> WG; RL Bob Morgan
> Subject: Re: AuthzIDs or DNs, but not both
> 
> 
> "Curtin, William" wrote:
> > 
> > So then should the draft contain an additional paragraph to 
> assure this
> > mapping?
> > 
> > For example change section 11 to:
> > 
> > <snip>
> > 
> >    The uAuthzId choice allows for compatibility with client 
> applications
> >    which wish to authenticate to a local directory but do 
> not know their
> >    own Distinguished Name or have a directory entry.  The 
> format of the
> >    string is defined as only a sequence of UTF-8 encoded ISO 10646
> >    characters, and further interpretation is subject to 
> prior agreement
> >    between the client and server.
> > 
> >    For example, the userid could identify a user of a 
> specific directory
> >    service, or be a login name or the local-part of an RFC 822 email
> >    address. In general a uAuthzId MUST NOT be assumed to be 
> globally unique.
> > 
> > <new>
> >    All servers which support the uAuthzId choice MUST be 
> capable of mapping
> > the uAuthzId
> >    to an associated distinguished name for internal use.
> > <end new>
> 
> But the use in question is not internal.  We need to map the uAuthzID
> to an associated distingusied name for EXTERNAL use.  That is, for
> use with directory attributes such as creatorsname, modifiersname,
> member, owner, access control subjects, etc..
> 
> Kurt
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 11:00:57 -0800

At 01:21 PM 11/15/99 -0500, you wrote:
>So then should the draft contain an additional paragraph to assure this
>mapping?

I suggest it have a separate draft to define a one-to-one mapping
between arbitrary authentication identities and their DN representation.

Basically, I propose that when a user enters "kdz" as an authorization
string that the client uses the DN "authzid=kdz" to bind as user
"kdz".   This can be used with all forms of bind, but more importantly,
it can be used where ever a DN is allowed.  It provides the desired
capability of allowing users to provide arbitrary string as an
authorization identity without introducing another on the wire
representation of identities.

I, then, suggest we amend all specifications require use of authzid
to instead use DNs and make note that these DNs may represent
arbitrary authentication identities per the one-to-one mapping
document.

Kurt

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 11:40:45 -0800

It should not be a MUST, because the internal use of which you speak is
itself optional.

It MAY be pointed out in the draft, but it should be obvious and a matter of
simple logic, that if one wishes to support creatorName, whose value is a
DN, and the creators ID was given via uAuthzID, then there has to be a
mapping.

Paul

---

From: "Curtin, William" <[email-masked]>
Date: Mon, 15 Nov 1999 14:54:32 -0500

See embedded comments.

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 2:01 PM
> To: Curtin, William
> Cc: [email-masked]
> Subject: RE: AuthzIDs or DNs, but not both
> 
> 
> string that the client uses the DN "authzid=kdz"
 
[do you mean RDN authzid=kdz? That is, are you suggesting that all users
 which are being mapped from uauthzid to a DN has to reside in 
 "authzid=kdz, dc=foobar, dc=com"?  If so, I don't see the benefit of
mapping to this
 form of DN over any other DN. Why couldn't I map to, for instance, to an
Active Directory
 form of DN - "cn=kdz, cn=users, dc=foobar, dc=com"? ]
 
> to bind as user

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 12:01:18 -0800

At 02:54 PM 11/15/99 -0500, Curtin, William wrote:
>[do you mean RDN authzid=kdz?

No.  I mean the DN "authzid=kdz".  That is, the DN as only one
component.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 14:34:11 -0800

> Sent: Monday, November 15, 1999 11:56 AM

> 
> 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. Users who are accustomed to a given principal name form
should not have to learn the DN form. 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.

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.

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

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 14:38:49 -0800

> Sent: Monday, November 15, 1999 12:01 PM
> To: Curtin, William
> Cc: Curtin, William; [email-masked]

This isn't a legal DN. (Not that I care very much, but some people care
really a lot, and we work by rough concensus around here...)

Even if it were, it doesn't provide much if any added value over saying that
the authzid is a UTF-8 string.

If this is going to prove such a bother, I would just prefer that the whole
authzid thing got yanked. I think its a bad idea to let anyone (even an
admin) just declare that they want to be someone else. A bad idea in that I
think its ripe for security abuse.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 18:00:04 -0800

I'm afraid you are barking up the wrong tree, Bob.
 
There is already a way to use a DN as the authzid.
 
Kurt wants to make DNs be the _only_ way.
 
I like the way it is currently, where it is permitted to use other forms for
authzid. Having more than one way does not violate the previous agreement
that a standard interoperable way needs to be specified. In fact, the
agreement was that _both_ DN and non-DN forms should be allowed, IIRC.
 
There are, I believe, strong arguments that the mere existence of authzid is
a layering violation. The authentication protocol is the owner of
identification and of the forms of identities, not application protocols.
And SASL has a way of handling authzid.
 
Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 18:26:31 -0800

-----Original Message-----
From: Bob Blakley [mailto:[email-masked]]
Sent: Monday, November 15, 1999 3:02 PM

> Paul writes:
 
>> If this is going to prove such a bother, I would just prefer that 
>> the whole authzid thing got yanked. I think its a bad idea to let 
>> anyone (even an admin) just declare that they want to be someone 
>> else. A bad idea in that I think its ripe for security abuse.
 
> I feel some sympathy for this proposal.  Is anyone using authzid?

Not us. We can't. We hand over all the authentication stuff to
authentication modules architected along the lines of GSS, and they work in
an application protocol independent way, and have no idea what "dn:
uid=kdz,dc=bar,dc=com", or similar, means.

Even if this weren't the case, implementation of this feature by a server
means that it has to run as root to be able to change its identity. That's a
Bad Thing (tm) for an application protocol to require. And it has to be able
to check whether the user authenticating to it has the right to ask it to
become anyone the user wants. It has to get that check right, or the
security of the whole system running the LDAP server, and maybe even other
servers, is at risk.

Paul

---

From: "Bob Blakley" <[email-masked]>
Date: Tue, 16 Nov 1999 08:59:54 -0600

--bob

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

>a layering violation. The authentication protocol is the owner of identification 
>and of the forms of identities, not application protocols. 

I agree that there are strong arguments, and I agree with those arguments.  I think authorization data
should *never* be carried as part of an authentication and key exchange protocol, except as
an implementation convenience, for performance purposes, collapsing a formal architecture in
which authorization information should be encapsulated within an authenticated session.  In other
words, authorization information should be layered above authentication protocols -- always.

---

From: "Curtin, William" <[email-masked]>
Date: Tue, 16 Nov 1999 13:00:58 -0500

> Sent: Monday, November 15, 1999 8:30 PM
> To: Bob Blakley
> Cc: Paul Leach (Exchange); 'Kurt D. Zeilenga'; IETF LDAP Extensions WG
> 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).

I'm trying to understand this proposal. 

So are you proposing that there be a new object class, say 
authorizedUser, which MUST contain the uauthzid attribute and 
which is supported by a structure rule which allows this new 
object class to reside at the same level as Country, Organization, 
and Domain? If so, is this object class outside of the server's naming 
context? Does it carry other attributes about a user (e.g. phone, 
address, email, etc.) or are they found elsewhere in the DIT?
 
> 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

Agree. From the server perspective there is probably no difference
between mapping u:kdz -> uid=kdz,dc=openldap,dc=org or
uauthzid=kdz -> uid=kdz,dc=openldap,dc=org

				bill

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Nov 1999 12:15:02 -0800

At 01:00 PM 11/16/99 -0500, Curtin, William wrote:
>and Domain?

I purposely focused on the bind DN, not the entry it names.
However, if a specification was drafted, it would likely
have to specify schema of named entries.   First note, I
intend to allow servers to make entries named by these DN
not visible to clients (excepting for bind operations).
That is, an base search of one of these DN may return
noSuchObject or such.   Of course, an implementation
could make the visible.

I am actually thinking that they would subentries of the
root DSE.  This gives them a context which is local, that is,
they are not tied to any specific naming context.

>If so, is this object class outside of the server's naming 
>context?

As subentries of the root DSE they would be outside the
naming context(s) of the server.  

>Does it carry other attributes about a user (e.g. phone, 

Likely not.

If there is reasonable support for exploring such an approach,
I would be willing to draft an specification and put it before
the WG for consideration.  I would want to enlist a coauthor
with strong knowledge of the LDAP/X.500 information model.

Regards, Kurt

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