Subject: Re: AuthzIDs or DNs, but not both

From: Jeff Hodges <[email-masked]>
Date: Mon, 06 Dec 1999 15:11:20 -0800

"Kurt D. Zeilenga" wrote:
> 
> It appears to me that the authzIds-are-not-necessarily-DNs
> notion will cause a ripple of change through the protocol and
> information model.  The introduction of authzid
> representation [AuthMeth] will lead to creatorsAuthzid,
> modifiersAuthzid, memberAuthzid, and many other use of DNs
> to be replaced with something that can contain both an
> authzId.  I believe the addition of authzIds will
> unnecessarily complicate the protocol and information model.

I'm sorry, but I don't believe this assertion is correct. As Paul pointed out, 
RFC2251 clearly states that the creatorsName and modifiersName operational attributes are
"MAY"s. And RFC2119 says..

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

In fact, my understanding from Mark Wahl is that Innosoft's Distributed Directory Server
has supported the ldapv3-tls and the ldapext-authmeth drafts' "StartTLS" and SASL-based
functionality for well over a year now, and has customers using it. Implementing it did
~not~ in fact "unnecessarily complicate the protocol and information model".

Harald Alvestrand wrote in anoter msg in this thread:
> When we discussed this in Washington 2 years ago, I think we had an 
> implicit assumption that the authzId in the SASL exchange, which may, but 
> need not, be a DN, would be *mapped to* a DN if required for internal purposes.

Nominally correct according to my recollection -- I participated in that discussion -- 
but the key clause is "if required for internal purposes". Kurt is
suggesting that the ~protocol~ defines and ~requires~ this mapping. 

Kurt continued in his msg:
> In particular, I suggest we consider
> introducing a DNs-may-be-authzid notion.  Such a notion
> (which one could argue that this already exists) ...

Yes, it definitely already exists and is explicitly delineated in section 11 of
ldapext-authmeth and in section 3 of RFC2222 (by reference). 

> I suggest we formalize a mechanism for mapping non-DN
> authorization identifiers onto DNs and allow BOTH clients
> and servers to use these DNs-can-be-authorzids DNs
> whereever DNs are used today.

We went through this particular discussion on the ietf-ldapext list back in Mar-1998,
culminating in an off-line meeting between myself, RLBob, Mark Wahl, John Myers and one or
two others during the 41st IETF in LA (Apr-1998) during which we worked out what now
comprises section 11 of ldapext-authmeth. The notes of the results of this meeting are in
the proceedings here (item 13 in the subsection entitled "third session")..

  http://www.ietf.org/proceedings/98mar/98mar-edited-24.htm#P3704_186255

We decided that the protocol should support the notion of an authorization identity that
was not necessarily a DN, and designed the material that became section 11 of
ldapext-authmeth. (The discussion that Harald is referring to above was at the prior IETF
meeting -- the 40th in WashDC in Dec 1997.) We presented this conclusion to the LDAPEXT
group in the third official session that week (in LA) and according to the working group
chairs, had rough consensus. 

Again, the rationale behind this is that LDAP-based directory technology isn't being used
primarily for people objects and their roles -- it's being applied to everything and
anything under the sun. And the ~protocol suite~ itself doesn't make an explicit or
implicit assumption that all or most DSAs are linked together so entries in other parts of
an uber-DIT may be chased down. It doesn't make sense to require implementors of, for
example, an "embedded" LDAP-accessed datastore -- such as some DEN-enabled device -- to
utilize only DNs as the authorization identifier. And it wouldn't make any sense to
preclude them from doing so if they wished. 

Thus the ldapv3-tls and ldapext-authmeth drafts ended up being crafted as they are. 

The full-bore version of this rant is here..

  http://www.stanford.edu/~hodges/doc/AuthzIDsNotRestrictedToDNs-1999-11-09.txt

..and the notions of authentication identities, authorization identities, access control
factors, et al are laid out in section 5 of ldapext-authmeth. 

Kurt said in another msg in this thread:
> 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've gone back through archives of a few lists and this overall topic was discussed on the
ietf-asid, ietf-ldapext, [email-masked], and [email-masked] as far back as
spring 1997 (on the asid list). One must in general search for "authorization" as well as
"authz" in order to find this thread in the archives.  

thanks,

JeffH
--
refs..

ldapext-authmeth:
http://search.ietf.org/internet-drafts/draft-ietf-ldapext-authmeth-04.txt
ldapv3-tls: http://search.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-tls-05.txt

--
Jeff Hodges                                          [email-masked]
Staff Scientist                                 voice: +1 408 861 6656
Oblix Inc.                                        fax: +1 408 861 6810
18922 Forge Drive, Cupertino, CA 95014           main: +1 408 861 6800
Corporate........................................http://www.oblix.com/
Personal..............................http://www.stanford.edu/~hodges/

---

From: Jeff Hodges <[email-masked]>
Date: Mon, 06 Dec 1999 16:34:17 -0800

I said in my previous msg in this thread..

> primarily for people objects and their roles 
  ^^^^^^^^^

I intended to type...

> only for people objects and their roles 
  ^^^^

apologies for any confusion. 

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 1999 16:50:30 -0800

Though I disagree that creatorsName is a MAY (see RFC2252, 5.1.2 says
SHOULD), I do agree that this issue can be addressed by server side
mapping of non-DN authorization identities into DN identities.  I
would be curious to hear what others have done in this area.

I fully believe users should be able to specify authentication and
authorization identities which may or may not be entries within
the directory.  This, however, is quite different than saying we
need two on-the-wire representations of such identities.  LDAPDN
could be used to represent identities which are not or do not
have directory entries.  However, without operational experience
with such an approach, I will defer further comment until such
time that I do (which may be never).

I do believe, however, that there are a number of other issues
raised subsequently to my posting you quote that do need to be
addressed before AuthMeth/StartTLS drafts are published as an
RFC.  I will attempt summarize my concerns in a separate posting.

Kurt

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

---

From: Jeff Hodges <[email-masked]>
Date: Thu, 09 Dec 1999 13:21:51 -0800

"Kurt D. Zeilenga" wrote:
> SHOULD), 

This is another case of stuff that needs to be considered for clean-up on the
way to Draft Standard maturity level for LDAP as a whole. Given that neither of
the requirements are "MUST", seems to me that that functionality is optional if
one has good reason (which is the definition of "SHOULD", after all). 

JeffH