Subject: Issues with current authmeth draft.

From: Mark Ennis <[email-masked]>
Date: Wed, 07 May 2003 15:28:49 +1000

Following are some issues I encountered with the current authmeth draft 
(draft-ietf-ldapbis-authmeth-05.txt).

1) The phrase "inside an OCTET STRING wrapper" is ambiguous.

This phrase is from a sentence in the fourth paragraph of section 4.3:
"The credentials field contains the arbitrary data used for 
authentication, inside an OCTET STRING wrapper." It appears to be 
transcribed from RFC2251.

This phrase could arguably be interpreted to mean either:
i) The SASL credentials are arbitrary data stored in the 
SaslCrentials.credentials OCTET STRING field, or
ii) The SASL credentials are arbitrary data in a BER encoded OCTET 
STRING in the SaslCredentials.credentials OCTET STRING field, i.e. the 
SaslCredentials.credentials contains BER.

Although I interpret the intention to be i), I find the wording 
ambiguous and think it should be fixed, probably by simply removing this 
phrase from the sentence.

2) DIGEST-MD5 authentication identity

There does not appear to be a clear statement as to the form of the 
authentication identity (as opposed to authorization identity) to be 
provided in the username-value of the SASL credentials for DIGEST-MD5 
(or other mechanisms). I have seen examples of this value being an 
arbitrary identifier such as a Unix system might use, a LDAPDN and an 
*authzid*-style production.

3) Section 4.3.3 *Other SASL Mechanisms*

This section states "Other SASL mechanisms may be used with LDAP, but 
their usage is not considered in this document.", however, the 
DIGEST-MD5 mechanism has not been referenced in section 4.3 and yet, 
contrary to this statement, is considered later in the document.

- Mark Ennis.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 May 2003 17:19:07 -0700

At 10:28 PM 5/6/2003, Mark Ennis wrote:
>Following are some issues I encountered with the current authmeth draft (draft-ietf-ldapbis-authmeth-05.txt).
>
>"The credentials field contains the arbitrary data used for authentication, inside an OCTET STRING wrapper." It appears to be transcribed from RFC2251.

This should be:
        The credentials field, an OCTET STRING, contains the arbitrary
        data used for authentication.

>There does not appear to be a clear statement as to the form of the authentication identity (as opposed to authorization identity) to be provided in the username-value of the SASL credentials for DIGEST-MD5 (or other mechanisms).

RFC 2831 says its a user name.  That is, it's not a LDAPDN, not
an authzid, not a domain name, not a ....

>This section states "Other SASL mechanisms may be used with LDAP, but their usage is not considered in this document.", however, the DIGEST-MD5 mechanism has not been referenced in section 4.3 and yet, contrary to this statement, is considered later in the document.

I note as well that the ANONYMOUS/PLAIN section (4.2) should
be deleted.  ANONYMOUS and PLAIN, like in other mechanism,
can be used in LDAP if a) supported and b) enabled.  I note
that they each offer capabilities not found in their simple
bind equivalents (and hence are used in some deployments).
For example, PLAIN (over TLS) is quite useful when interacting
with legacy authentication subsystems.

---

From: Mark Ennis <[email-masked]>
Date: Mon, 12 May 2003 08:51:09 +1000

> an authzid, not a domain name, not a ....

On the other hand, RFC2831 does not specify the authzid field in the 
SASL parameters should use the authzid syntax defined in RFC2829 either. 
It does, however, define the username SASL parameter as
      "The user's name in the specified realm, encoded according to the
       value of the "charset" directive. This directive is required and
       MUST be present exactly once; otherwise, authentication fails."

I suggest this supports the potential to use LDAPDN which is the closest 
thing to a username within LDAP that is required by the LDAP 
specifications. After all, the "user's name" in LDAP is the LDAPDN of 
the user's entry.

Furthermore, [authmeth] has the statement:
   "Clients sending a bind request with the sasl choice selected SHOULD
    NOT send a value in the name field. Servers receiving a bind request
    with the sasl choice selected SHALL ignore any value in the name
    field. "
in *4.3 SASL Authentication* which appears to prohibits the use of the 
BindRequest name field to establish the authentication identity. Without 
this or the  SASL username providing a LDAPDN, how should the 
authentication credentials be determined?

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 11 May 2003 16:24:26 -0700

At 03:51 PM 5/11/2003, Mark Ennis wrote:
>On the other hand, RFC2831 does not specify the authzid field in the SASL parameters should use the authzid syntax defined in RFC2829 either.

RFC 2222 says the form of the (proxy) authorization identity
is application protocol specific.

>      MUST be present exactly once; otherwise, authentication fails."

I think this is an issue which already came up in the SASL WG.

>I suggest this supports the potential to use LDAPDN

I don't believe it supports any such thing.

>which is the closest thing to a username within LDAP that is required by the LDAP specifications.

I don't think the LDAP specifications require a DN for authentication
proposes.  If one considers EXTERNAL, the underlying authentication
identity can be anything.  Likewise, any SASL mechanism can be used.
Here the form of the authentication identity is mechanism specific.

Regardless of the mechanism, it is the server's responsibility to
derive an appropriate authorization identity from the authentication
identity associated with the credentials.  And if a (proxy) authorization
identity is asserted, make sure the identity associated with the
credentials is authorized to assume that asserted (proxy)
authorization identity and, as appropriate, derive an identity
representation suitable for application of access control and other
administrative policies.

>After all, the "user's name" in LDAP is the LDAPDN of the user's entry.

Not necessarily.  There may be no LDAPDN associated with the user
and, even if so, it may not refer to an entry.

>in *4.3 SASL Authentication* which appears to prohibits the use of the BindRequest name field to establish the authentication identity.
>Without this or the  SASL username providing a LDAPDN, how should the authentication credentials be determined?

A local matter.  That is, how identities of different forms (or
of the same form used in different contexts) relate to each other is
a local matter.  How and where credentials are stored is a local
matter.  Which identities may assume (proxy for) other identities is
also a local matter.  And the form of identity used in access control
systems is local matter.

It's certainly a matter which the client should not concern itself
with...

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Mon, 12 May 2003 17:25:25 +1000

> is application protocol specific.
So? I am not questioning the appropriateness of [authmeth] defining the 
authzid syntax for the authorization identity defined in RFC2831. I was 
intending to point out that RFC2222 and RFC2831 are not LDAP 
specifications. Their use and the appropriate content of their fields 
with respect to LDAP are defined by an LDAP specification, i.e. 
[authmeth], which sees fit to define the content of the authzid field 
(and therefore the form the authorization identity will take), but not 
the username field (and therefore the form the authentication 
credentials will take). I question the value in defining the usage of 
one and not the other by the LDAP specification.

> I don't believe it supports any such thing.

So, if I have an authentication engine which uses distinguished names as 
the unique identifier in the realm and passwords for the shared secret, 
I can't use this authentication engine with the SASL "DIGEST-MD5" 
mechanism because I can't use the LDAPDN in the username-value in this 
mechanism? I must introduce a new arbitrary identifier and a mapping of 
this identifier to a distinguished name in order to bind? This does not 
seem reasonable.

> and, even if so, it may not refer to an entry.
I conceed I used a poor argument here. I agree that there is not a 
requirement for an entry identified by the LDAPDN used in authentication 
to exist. I also agree that SASL allows for authentication using 
credentials which do not include an LDAPDN, and that the server is 
responsible for defining a mapping if it requires it.

However, I do not accept that SASL prevents my use of an LDAPDN as an 
identifier in authentication credentials. One of the possible forms of 
an identifier in the authentication credentials for an "EXTERNAL" SASL 
authentication is the subject name of a certificate, i.e. a 
distinguished name. Where my authentication engine is an LDAP or X.500 
system, I do accept that I should need to introduce a new identifier, if 
the directory does contain entries associated with LDAPDNs where the 
entries hold user passwords (or their hashes), if I wish to use SASL 
"DIGEST-MD5" authentication. [This would seem to be the point Ron Ramsey 
was making.]

I feel that [authmeth] should make some statement as to the usage of the 
username field in the SASL "DIGEST-MD5" credentials when used for digest 
authentication in LDAP, even if this is to clarify that the content of 
the username-value is an arbitrary octet string assigned by the server. 
Clients which make assumptions about the content of this field based on 
prior experience may have problems interworking with other servers. As I 
mentioned previously, I have already encountered LDAP clients which 
appear to make assumptions about the content of this field.

> also a local matter.  And the form of identity used in access control

Accepted.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 09:06:20 -0700

At 12:25 AM 5/12/2003, Mark Ennis wrote:
>So?

Because RFC 2222 makes it fairly clear that the form of the
authentication identity is mechanism specific while the form
of the authorization identity is specific to the application-level
protocol profiling its use of SASL.

>I am not questioning the appropriateness of [authmeth] defining the authzid syntax for the authorization identity defined in RFC2831. I was intending to point out that RFC2222 and RFC2831 are not LDAP specifications.  Their use and the appropriate content of their fields with respect to LDAP are defined by an LDAP specification,

I think we need to be careful here.  The LDAP SASL profile defines
a few application protocol specific particulars, in accordance with
SASL profiling requirements.  Beyond this, it is generally inappropriate
for any other application protocol TS, to overload fields of specific
mechanisms.  That would defeats many of the values the SASL framework
brings to the Internet.

>i.e. [authmeth], which sees fit to define the content of the authzid field (and therefore the form the authorization identity will take), but not the username field (and therefore the form the authentication credentials will take).

RFC 2222 says the authorization identity form is application protocol
specific.  RFC 2222 implies the form of the authentication identity
is mechanism specific.

>I question the value in defining the usage of one and not the other by the LDAP specification.

Noted.

>So, if I have an authentication engine which uses distinguished names as the unique identifier in the realm and passwords for the shared secret, I can't use this authentication engine with the SASL "DIGEST-MD5" mechanism because I can't use the LDAPDN in the username-value in this mechanism?

A username value doesn't have LDAPDN syntax or semantics in the
protocol.

>I must introduce a new arbitrary identifier and a mapping of this identifier to a distinguished name in order to bind? This does not seem reasonable.

Or introduce identity mapping.
Or use a more appropriate mechanism.

>I conceed I used a poor argument here. I agree that there is not a requirement for an entry identified by the LDAPDN used in authentication to exist. I also agree that SASL allows for authentication using credentials which do not include an LDAPDN, and that the server is responsible for defining a mapping if it requires it.

Okay, DIGEST-MD5 is clearly one of those mechanisms.

>However, I do not accept that SASL prevents my use of an LDAPDN as an identifier in authentication credentials.

Well, a username might look like an LDAPDN... but clearly the username
does not have LDAPDN semantics.

>One of the possible forms of an identifier in the authentication credentials for an "EXTERNAL" SASL authentication is the subject name of a certificate, i.e. a distinguished name. Where my authentication engine is an LDAP or X.500 system, I do accept that I should need to introduce a new identifier, if the directory does contain entries associated with LDAPDNs where the entries hold user passwords (or their hashes), if I wish to use SASL "DIGEST-MD5" authentication. [This would seem to be the point Ron Ramsey was making.]
>
>I feel that [authmeth] should make some statement as to the usage of the username field in the SASL "DIGEST-MD5" credentials when used for digest authentication in LDAP, even if this is to clarify that the content of the username-value is an arbitrary octet string assigned by the server.

I note that RFC 2222 and 2831 are being revised and they will include
some clarification in this area.  I would likely support (I'd have to
see the exact wording to be sure, please suggest something) an
[authmeth] clarification that reiterate these general statements
with a "for instance" for the DIGEST-MD5 username instance.

>Clients which make assumptions about the content of this field based on prior experience may have problems interworking with other servers. As I mentioned previously, I have already encountered LDAP clients which appear to make assumptions about the content of this field.
>
>>