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

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Just some thoughts - below

Not using DNs for authorisation is permiited in X.500 and LDAP where
lower layer mechanisms are applied - that is a local matter. However,
mutual authentication becomes a local trust issue also. For DEN use, the
DEN accessors still have to work on naming contexts (DNs) and names of
objects regardless of the authentication processes for the access so it
cannot be too much effort to have named accessors..

Using other name forms than a DN in a directory system for authorisation
strikes me as a disaster. eg. I always assume that directories must be
distributed and replicated if they are to scale. Say I log on with an
email address as an authorisation string - does the server  now search
the whole world for authentication where is this mail address is located
?, what is the trust model on a client directed referral based system
such as LDAP  - how does that work?

I saw the General Name Choices as bad and unworkable in an LDAP server
only environment (its OK for one server - but then everything is isnt
it?). But not for many servers which are interconnected by
referrals..ie. The only chance of this working is via an X.500
infrastructure which can apply the mail address "Search" as a system.

just thoughts regards alan

> -----Original Message-----
> From:	RL Bob Morgan [SMTP:Bob.Morgan@stanford.edu]
> Sent:	Thursday, March 26, 1998 6:10 AM
> To:	Mark Wahl
> Cc:	Jeff.Hodges@stanford.edu; Bob.Morgan@stanford.edu;
> ietf-ldapext@netscape.com
> Subject:	Re: comments on draft-ietf-ldapext-authmeth-01.txt
> 
> 
> 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
> 
> 
>