[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
"Authz IDs as only DNs" (in acl-reqts and acl-model) issue
Both I and RLBob note that the current versions of both acl-reqts and
acl-model drafts (draft-ietf-ldapext-acl-reqts-02.txt and
draft-ietf-ldapext-acl-model-04.txt) effectively declare authorization
identities ("subjects" in their parlance) "must" be DNs.
We went through a long process back in spring 1998 culminating at the
41st IETF in LA where we came to agreement among the AuthMeth and
LDAPv3-TLS coauthors about the authzIds-are-not-necessarily-DNs notion
and those changes have in fact been in the AuthMeth and LDAPv3-TLS
drafts since then. In fact, the AuthMeth draft sections 5 and 11 go to
fair lengths to discuss this stuff.
I think that it wouldn't make much sense if the access control scheme
eventually developed for LDAP didn't buy into this notion.
Below's the (updated) rant RLBob & I wrote about this back in '98. It is
also available on the web at..
http://www.Stanford.edu/~hodges/doc/AuthzIDsNotRestrictedToDNs-1999-11-09.txt
thanks,
JeffH
--
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/
----------------------------------------------------------------------
Authorization Identities shouldn't be restricted to being only
Distinguished Names
RL "Bob" Morgan, University of Washington
Jeff Hodges, Oblix, Inc.
original: Wed, March 25, 1998
Updated: Tue, 9 Nov 1999
This note is available as:
http://www.Stanford.edu/~hodges/doc/AuthzIDsNotRestrictedToDNs-1999-11-09.txt
This is a note about the form of authorization identities for use in
LDAPv3. This issue came up while we were working on the TLS-for-LDAP
[LDAPv3-TLS] and LDAP Authentication [LDAPv3-AUTH] specs.
We believe it's an important point, hence this note to provoke
discussion and (we hope) continued consensus. The discussion was
originally
held on the ietf-ldapext@netscape.com email distribution list (which
is probably the best place for continued discussion).
It has been suggested in several venues that the identities used for
access control purposes with LDAP should always be Distinguished
Names. The ldapext-acl-reqts draft [ACL-Reqts] says this explicitly
(U2 in section 3.3), and this has been suggested in some conversations
we have had (email and face-to-face). This note presents an argument
that identities (ie, the authorization IDs asserted by clients and
expressed in ACL-type expressions used by servers) must be allowed
to be any octet string. The TLS-for-LDAP draft [LDAPv3-TLS]
currently does not constrain authorization IDs to be DNs (nor does
[RFC 2251], for that matter).
In terms of the [LDAPv3-TLS] and [LDAPv3-AUTH] drafts,
this is the "authorization identity" described in section 5.4 of
[LDAPv3-AUTH], and referred to in section 7.1.2 of [LDAPv3-TLS]:
A client MAY either implicitly request that its LDAP authorization
identity be derived from its authenticated TLS credentials or it
MAY explicitly provide an authorization identity and assert that
it be used in combination with its authenticated TLS credentials.
Further, the Authorization Identity is explicitly syntactically
defined in Section 11 of [LDAPv3-AUTH] as being _either_ a "unspecified
userid, UTF-8 encoded" _or_ a "distinguished-name-based authz id".
We understand, we think, the motivation for requiring the
authorization identity to be a DN. DNs are the stuff of directories,
and it gives at least a little structure to the identity. Some
attributes (modifiersname?) referring to protocol identities are
already defined as DNs, apparently. But for much the same reasons
that some current directory server products offer a flexible mapping
between the DN in a client cert and the authorization ID DN, we argue
that the authorization ID must be permitted to be something other than
a DN. Consider:
(1) If you look at the evolution from X.509v1/PEM [PEM] to
X.509v3/PKIX [PKIX], there is a consistent reduction in the signif-
icance of the subject DN. In PEM it was not only required, it indicat-
ed the CA hierarchy, and this is a well-known design disaster. In
PKIX it doesn't have to be present at all; subjectAltName, which can
take any number of other forms, is a key new feature permitting
a non-DN identifier. In the LDAP-TLS scenario this means that a
perfectly valid client cert might have no client DN in it at all.
Requiring the authorization ID to be a DN seems much more like the
mistake that PEM made than the flexibility that PKIX has found it
appropriate to permit.
(2) The appeal of DNs as authorization IDs for LDAP seems to be based
on the X.500 scenario, where the directories of interest contain
mostly person entries, and all DSAs are linked so entries in other
parts of the DIT can be chased down. But the wider applicability of
LDAP negates both of these assumptions. Suppose a network management
station is using LDAP as an access protocol to query a data-collection
agent, acting as an LDAP server, for device info (the sort of use
envisioned in the MS-Cisco Directory-Enabled Networks initiative,
for example), using Kerberos as an security layer. How does a DN-format
authorization ID fit into this picture? Answer: it doesn't. The LDAP
server only maintains info about device objects, not about users or
whatever other entities are acting as requesters. Expecting that this
server would be able to act as an LDAP client to look up info about
the requesting ID (specifically the krbName to DN mapping in this
example) seems to be well beyond the scope of current practice
or any procedures that have been generally agreed upon. The most
natural thing for this server would be to represent its internal
authorization info as Kerberos principals and get Kerberos principals
as authorization IDs in requests.
(3) It is our impression that the community is still quite divided on
the role of DN structure, and what forms DNs will take in practice.
Will DN components be used to locate LDAP servers, or represent
certificate validation paths? Should the hierarchy be c=, o= or dc=,
dc=? Should the last RDN be a name-like human-palatable string or a
guaranteed-unique UUID or GUID? Will particular DSAs or dir-based
apps require one form or another? It seems premature to specify that
ACLs and other places that might hold authorization identities should
fill them up with DNs if we don't even know what they will look like,
especially if an organization (eg, our former one at Stanford, with
Kerberos) already has a deployed security infrastructure with well-
established principal forms.
In short, we think that mandating DNs as authorization IDs assumes
that we know much more about how authorization will work, and how DNs
will be used, than we really do at this point. We should simply
specify that the SASL authorization ID field [SASL] be used to transmit
this data, and that any octet string is acceptable. This reveals prob-
lems with the simple bind method, which requires a DN as the bind ID,
and doesn't support a separate authorization ID. This implies that the
simple bind mechanism should plausibly be deprecated in favor of
authentication mechanisms supporting such a concept, such as the
SASL Digest mechanism [Digest].
It is now Fall 1999, over a year and a half since we wrote the first
version of this note. [LDAPv3-AUTH] and [LDAPv3-TLS] are on the
threshold of becoming Proposed Standard RFCs and explicitly express
the notion of Authorization IDs _not_ being constrained to being only
DNs. We feel this is a good thing. Unfortunately, we note that there
are still drafts in-the-works that have not yet acknowledged this
notion.
References
----------
[ACL-Reqts] Access Control Requirements for LDAP
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-acl-reqts-02.txt
[Digest] Using Digest Authentication as a SASL Mechanism
http://info.internet.isi.edu:80/in-drafts/files/draft-leach-digest-sasl-05.txt
[LDAPv3-AUTH] Authentication Methods for LDAP
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-authmeth-04.txt
[LDAPv3-TLS] Lightweight Directory Access Protocol (v3): Extension for
Transport Layer Security
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-ldapv3-tls-05.txt
[PEM] Privacy Enhancement for Internet Electronic Mail: Part I:
Message Encryption and Authentication Procedures
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1421.txt
[PKIX] Internet X.509 Public Key Infrastructure Certificate and
CRL Profile
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2459.txt
[RFC 2251] Lightweight Directory Access Protocol (v3)
ftp://ftp.isi.edu/in-notes/rfc2251.txt
[SASL] Simple Authentication and Security Layer (SASL)
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2222.txt
---
END