Re: comments on draft-ietf-ldapext-authmeth-01.txt

[RL Bob Morgan <Bob.Morgan@Stanford.EDU>]

Here is a note we had prepared previously on this topic.  I think it
addresses some of your concerns, but I'll try to answer those more
directly too. 

 - RL "Bob"

---

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
spec.  We think it's an important point, hence this note to provoke
discussion and (we hope) consensus.

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 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
ACL-type expressions used by servers) must be allowed to be any octet
string.  The TLS-for-LDAP draft (draft-ietf-ldapext-ldapv3-tls-00.txt)
currently does not constrain authorization IDs to be DNs (nor does RFC
2251, for that matter).

In terms of the ldapv3-tls draft, this is the "authorization
identity" described in section 6.4, and referred to in the third
paragraph of 7.1:

  The credentials field (within the SaslCredentials sequence in the
  Bind Request) MAY contain an authorization identity, or it MAY be
  empty. 

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 to X.509v3/PKIX,
there is a consistent reduction in the significance of the subject DN.
In PEM it was not only required, it indicated 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 a client 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 requestors.  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-readable 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, ours 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 be used to transmit this
data, and that any octet string is acceptable.  This reveals problems
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 be deprecated in favor of the SASL PLAIN
mechanism (which is unfortunately still draft, see
draft-newman-sasl-plaintrans-04.txt).

Any particular deployment, or even any particular client/server
implementation, might use only DNs for authorization IDs, while a more
flexible implementation might permit other forms.  If we want to
constrain the forms of authorization IDs, we might look at the set of
"GeneralName" choices defined for SubjectAltName in
draft-ietf-pkix-ipki-part1-06.txt, section 4.2.1.7, including
rfc822Name, dNSName, etc.  However, these types are distinguished in
the X.509 cert by ASN.1 tags (I believe), while the SASL authorization
ID field isn't so blessed.  We might even require, for
interoperability, that an implementation has to be able to accept DNs
for this purpose, though it's not clear how we would state what it has
to be able to do with such a DN.

Assuming there's consensus on this point, it's probably worth saying
it explicitly in the ldapext-authmeth document.

 - RL "Bob" Morgan & Jeff Hodges
   Stanford