[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: AuthzIDs or DNs, but not both
"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, ietf-apps-tls@imc.org, and ietf-tls@consensus.com 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 jhodges@oblix.com
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/