Subject: AuthMeth issue summary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 1999 20:55:35 -0800

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).

---

From: Mark Wahl <[email-masked]>
Date: Tue, 07 Dec 1999 14:52:19 -0600

One background item is that we are trying to provide interoperability
between LDAP users of SASL in advance of all of the SASL framework being 
completed as PS RFCs.  Some of your issues are more generic SASL discussion 
points.   In authmeth-04 as part of a compromise between some of the groups of
implementors / users of authorization IDs in LDAP, we provided a specification 
of authorization identities that allows for both DNs and arbitrary user 
identities. (RFC 2222 4. #5 states that a protocol defines how the authorization
identity is to be interpreted). I would hope that there would be a SASL work 
item at some point to more fully define how authorization identities can be 
used that is independent of the underlying protocol: e.g. I want to have a 
common authorization identity for a Web site accessed via HTTP, an IMAP store, 
an LDAP directory, etc.  Furthermore I would want to ensure that access control
systems which use authorization identities in implementations of each of 
the underlying protocols can make interoperable decisions, such as how to 
 - validate an authorization identity (e.g. identities with a expiry date)
 - compare two authorization identities for equality, 
 - map different kinds of real-world identities to authorization ids,
 - express containment, wildcards, role<->occupant and group<->member 
   relationships between authorization identities,
 - know whether an authorization identity is a capability and should be 
   protected as such etc
Once this is done by some SASL working group, then it would presumably 
update 2222 section 4 #5 so that the interpretation of authorization identity
is not purely a protocol-specific function, and then the next revisions to
the LDAPv3, IMAP, HTTP etc RFCs could move the protocol-specific identity 
information out into its own documents.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 1999 13:07:18 -0800

AuthMeth draft provides a secure Bind mechanism (DIGEST-MD5)
for authentication users who provide a simple username/password.
Though the mechanism describes how to provide an LDAP DN
authorization identity, it doesn't not allow an LDAP DN
authentication identity (DIGEST-MD5 username) [and it shouldn't].

However, I do believe that we need to provide a secure Bind
mechanism for authentication users who provide an LDAP DN as
their authentication identity.

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Thu, 09 Dec 1999 16:18:09 +0100

Hi Mark,

If we had all the items you list that would be SASL-heaven...have you any idea when
these SASL work-items will start to be mapped out in more detail ?

Rob.
--iPlanet Directory Group