Re: Authmeth/DIGEST-MD5

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

On Thu, 1 Jul 1999, Kurt D. Zeilenga wrote:

> I've been experimenting with implementation of SASL/DIGEST-MD5.
> 
> The authmeth draft, section 8.1, does not state want the value of
> the DN field should be in the client's initial bind request.
> At first, I thought it should be empty (zero byte string).  However,
> I now come to the conclusion that the target DN should be provided
> on client's initial request to allow binding to servers which
> authenticate for multiple realms and do not have access to (or did
> not store) the cleartext password.
> 
> So, a few questions:
> 
> What should the value of the DN field be client's initial
> BIND/SASL/DIGEST-MD5 request?
> 
> If empty, how should servers determine which realm to respond?
> 
> If non-empty, how should servers to clients providing empty DN?
> 
> What should the value of the DN field be for second request?
> 
> If value differs from initial request, what should the server's
> response be?
> 
> I'm sure I won't be the last person needing such clarification... 
> amending the AUTHMETH specification with such might be appropriate.

These questions raise the more general question:

 * what is the role, in general, of the "name" field in the Bind Request?

To fully answer this we must also answer:

 * what is the nature of the authorization identities (as defined in
   draft-ietf-ldapext-authmeth-04.txt, section 5.4) that LDAP clients 
   transmit to LDAP servers?; which leads inevitably to:

 * how do LDAP servers represent identities used for access control?

"Authorization identity" as defined in authmeth is the same concept as
"security subject" in draft-ietf-ldapext-acl-reqts-02.txt, and
"subject" in draft-ietf-ldapext-acl-model-03.txt.  We tried to explain
this concept fully in section 5 of authmeth, but I think this does
need more clarification, so let me attempt it here.  While writing the
LDAP-TLS and authmeth docs it became clear that a lot of that material
will need to be put into a revised 2251 at some point, as will the
issues I describe here.

A client binds as some authorization identity so as to exercise the
privileges associated with that identity.  The client asserts an
identity that it wants to use via any or all of:

 * the Bind Request name field, or 

 * the identity used in the authentication credentials it supplies via
   the SASL mechanism it uses, if any (in Digest,
   draft-leach-digest-sasl-03.txt, this is the "username-value" in the
   digest-response structure in section 2.1.2), or

 * the authorization id field in the SASL mechanism (in Digest, this
   is the "authzid-value" in digest-response); not all SASL mechanisms
   support this field.

The server is free to use any of this info however it wants as part of
making its access-control decisions; it can use other info too such as
the request's source network address, time of day, load, etc (these
are called Access Control Factors in section 5.2 of authmeth).  For
the sake of simplicity we'd expect a reasonable server to use the
three fields above to determine a single client identity (the
authorization identity, in authmeth terms) which it associates with
the bound connection.  Further it would be useful to specify how the
server SHOULD do this for each of the several authentication
mechanisms, which is, I think, what your questions are about regarding
Digest.

A central question is whether the authorization identity asserted by
the client MUST take the form of a DN, and hence be a directory object
on some DSA somewhere.  This was the subject of much debate as we were
developing the authmeth document.  The conclusion that we (the ldapext
working group) came to at that time (about a year ago) was that the
authorization identity does NOT have to be a DN, that it can be
whatever sort of identity the client and server agree on to express
their security principals.  This decision is reflected in the text of
authmeth, in particular in section 11, which describes both DN and
non-DN syntax for the authorization id field.

This decision permits LDAP-based directory services to be integrated,
when desired, with existing authentication infrastructures such as
Kerberos, and allows the existence of LDAP servers that don't happen
to maintain or have access to user entries.  The alternative view,
that every LDAP deployment must implement an authentication
infrastructure using DN-labelled principals in addition to managing
whatever info it has been set up to manage, IMHO unnecessarily
restricts the applicability of the protocol.

Note that if a DSA chooses to use DNs to represent client entities for
access control purposes, it can still allow clients to bind using
other forms of authorization ID by having an internal mapping between
these other forms and a set of DNs.  In fact even DSAs that accept DNs
supplied, eg, in client certs via TLS, have found it necessary to
provide a mapping function between the client-supplied DNs, which are
likely to come from all over the place, to the more controlled space
of DNs that the DSA uses internally (as mentioned in authmeth, section
9.1).  I think that for some common non-DN-based authentication
methods (Kerberos in particular) it would be useful to standardize how
this mapping might be done, but that's a topic for another rant.

So, given all this, the question remains as to how servers SHOULD
handle the various pieces of authentication/authorization data in the
various authentication mechanisms, and hence what clients should put
into them.

Regarding the Bind Request name, RFC 2251, section 4.2, says:

   - name: The name of the directory object that the client wishes to
     bind as.  This field may take on a null value (a zero length
     string) for the purposes of anonymous binds, when authentication
     has been performed at a lower layer, or when using SASL credentials
     with a mechanism that includes the LDAPDN in the credentials.

This permits a null name if the entity-to-bind-as is conveyed via the
SASL mechanism, though the implication is that it has to be a DN in
any case.  But as I mention above, in fact a DN is not required; any
form of user name expressed by the client via SASL is acceptable from
a protocol point of view.  Since any SASL mechanism will include
transmission of credentials including user name, this means that the
"name" field is only required in the Bind Request for the "simple"
option.

In the case of a SASL mechanism that supports reasonably strong
authentication and an authorization ID field that is protected from
tampering (eg, GSS/Kerberos and Digest), the name field is superfluous
at best.  In fact it is worse, because unless the datastream is
protected by TLS or IPSec or similar, it can be modified by an active
attacker.  So: the Bind Request name field SHOULD be null when used
with these mechanisms, and SHOULD (or MUST?) be ignored by the server.
If it is non-null, the server might find it useful as a hint for doing
the mapping I mention above, but should be sure not to rely on it as
part of its access control decision.

In the case of SASL EXTERNAL, when used with TLS or IPSec, the client
requests an authorization ID via the SaslCredentials sequence
(draft-ietf-ldapext-ldapv3-tls-05.txt, section 7.1.2.2); the Bind
Request name field is not used.  I suggest that the client SHOULD
transmit it as null; and the server SHOULD (or MUST?) ignore it.  This
clarification should be made to the LDAPv3-TLS document; at this
point, probably not until it goes to Draft Standard.

You ask if the Bind Request name field DN should have a role in
Digest in helping the client and server agree on what realm to
authenticate in.  draft-leach-digest-sasl-03.txt says that the initial
server challenge can contain multiple realm directives; the client
chooses one to respond about.  There would be a small optimization, in
the particular case where the server deals with multiple realms and
the client knows ahead of time which it wants, for the client to put
this into the Bind Request name field.  It's hard to know whether this
will be a common case or not; it seems unlikely to me that it would be
worth optimizing.  In any case the client can still authenticate
successfully if it uses a null name in its Bind Request and chooses
one of the realms the server offers.

> What should the value of the DN field be for second request?
> 
> If value differs from initial request, what should the server's
> response be?

If by "second request" you mean subsequent authentication as described
in section 2.2 of digest-sasl-03, then I suggest that in this case the
Bind Request name field be null when sent by the client and ignored by
the server.  Subsequent authentication reuses all the info (username,
realm, etc) from the initial authentication, so the name field can't
add anything useful.

 - RL "Bob"