Subject: [AuthMeth] clarification on SASL DN AuthZ ID

From: "Roger Harrison" <[email-masked]>
Date: Tue, 12 Nov 2002 13:52:37 -0700

Section 4.4.1.1 of [AuthMeth] states:

All servers that support the storage of authentication credentials, such as passwords or certificates, in the directory MUST support the dnAuthzId choice. The format for distinguishedName is defined in section 3 of [LDAPDN].

I see two problems with this statement.

Problem 1: This requirement would apply to directories that store passwords or certificates for uses other than authentication of LDAP clients or establishing TLS sessions with LDAP clients. I believe the intent of this requirement was to apply to all servers that support the storage of authentication credentials used in authenticating LDAP clients and not to servers that store them for other unrelated purposes.

Problem 2: This statement does not specify whether the DN specified must exist in the directory when this form of SASL credentials is used. In my opinion it makes sense to require that the DN exist in the directory when this form is used. The unspecified authorization identity can be used for cases when the DN does not exist in the directory.

I propose the following wording to clarify these two issues:

All servers that support the storage of authentication credentials, such as passwords or certificates, in the directory for use in authenticating LDAP clients MUST support the dnAuthzId choice. The format for distinguishedName is defined in section 3 of [LDAPDN]. The distinguishedName value specified in the dnAuthzId MUST exist in the directory.

I welcome your comments and feedback on this proposal.

Sincerely,

Roger Harrison

Roger G. Harrison
Manager, eDirectory Core and Utilities
Novell, Inc., the Leader Provider of Net Business Solutions
www.novell.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 12 Nov 2002 21:27:08 -0800

>I see two problems with this statement.

The problem I see is that this MUST is not necessary for
interoperability.

For authentication only, no authorization identity is needed.  As
discussed on the ietf-sasl list, the authorization identity SHOULD
only be provided if the client wishes to assume the identity
different from that implied by the authentication credentials.
That is, specifying an authorization identity when not doing
proxy authorization causes interoperability problems and should
be avoid.

For proxy authorization, interoperability requires that the
user know the value and form authzId expected by the server.
Servers need only to support the value and forms they expect.
If anything, we should be stating that CLIENTs which support
Proxy Authorization SHOULD support both forms so that users
can specify either.

It's my personal opinion that paragraph should be deleted.

Kurt