AuthMeth issue summary

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

I believe that the LDAP drafts must provide secure authentication
mechanisms for both DN and non-DN authentication identities.


1. LDAP/SASL Layering Violations

It has been pointed out that support of application specific
authentication and authorization identities (LDAP DNs) violates
the layering provided by SASL.  I concur. [This relates to Jeff's
suggestion the ACL model also needs to support AuthzIds].

I believe authorization identities should be utf-8 strings
which may or may not be a DN.

Rational:  When using DIGEST-MD5, a user may specify
authentication identity (username) and authorization
identity (authzid) as arbitrary strings.   A client
cannot readily determine if the user provided string
is a DN or not.  That is: if the user provides "cn=foo",
is it "dn: cn=foo" or "u: cn=foo"?   The client should
not guess as any guess may be wrong.

[Note: the ACL-model should likely be updated,
  I suggest 4.2 read:
	A bind authenticates a principal to the directory.
	A principal is represented by a utf-8 string which
	may or may not be a DN.
  and:
	s/SubjectDN/SubjectId/g
	s/DNtype/IdType/g
	s/SpecifyCrediatials/SpecifyIdentity/g]


2. Secure Authentication of identities represented by DNs.

The DIGEST-MD5 mechanism is designed to be used with non-application
specific authentication identities (utf-8 usernames), not LDAP DNs.
As such, we have no secure, password-based SASL mechanism for
authenticating identities represented by DNs.

Though I have suggested means for adapting DIGEST-MD5, I do
concur that it is a bastardization of DIGEST-MD5.  I suggest
we instead define a new SASL mechanism (derived from DIGEST-MD5)
that is specifically designed for LDAP DN based authentication
identities.  This would provide a secure mechanism for LDAP
(and other applications) to authenticate using LDAP DN identities
and credentials.


3. SASL Session Security

Section 3 of AuthMeth suggests that the LDAP protocol may be
protected using session security features negotiated via SASL.
   "The LDAP protocol suite can be protected with the following     
   security mechanisms:
     (3)   Data integrity protection by means of [...]
           data-integrity SASL mechanisms,
   
     (4)   Protection against snooping by means of [...]
           data-encrypting SASL mechanisms,

However, does not fully specify how such mechanisms can be
utilized.  In particular, AuthMeth should state explicitly
how the data-encrypting, data-encrypting is initiated.

SASL Profiling Requirements, RFC 2222, Section 4:
   4. Identification of the octet where any negotiated security layer
      starts to take effect, in both directions.


4. Conformance requirements

AuthMeth, Section 6 (3) states that StartTLS will be used for
session protection.  We should optionally allow use of any SASL
security layers to provide session protection.


5. "anonymous" on bind failures

AuthMeth states (10) "Any authentication identity and authorization
identity, as well as TLS connection, which were in effect prior to
making the [FAILED] Bind request, MUST remain in force."  I assume
this is referring to the lower level identities, and not the LDAP
identities.  Per RFC2251, the LDAP session MUST be treated by the
server as "anonymous" if any BIND operation fails.


6. userPassword (section 8.2)

AuthMeth should not describe specifics of password storage
(even using MAY terms).