Subject: RE: Issues with current authmeth draft.

From: John McMeeking <[email-masked]>
Date: Mon, 12 May 2003 08:16:22 -0500

With respect to DIGEST-MD5:

1) If only the authentication mechanism is used (not data integrity or
confidentiality), it provides a bind mechanism that protects the password
without the need to establish a secure connection.  Also, LDAP DNs are a
natural choice for a user name when authenticating to a LDAP directory.
From that perspective, I would like DIGEST-MD5 to allow the user name to be
a bind DN.  One way to do that might be to define a standard realm name
that LDAP servers support, for example "RFC2253 LDAP DN".  This would
provide a standard way for clients to take advantage of DIGEST-MD5 for
password protection not offered by simple bind.  The mapping from
authentication id to authorization id is trivial.

2) In the general case of using password based authentication to LDAP, with
a "user registry" that may, or may not, be the directory, the user name can
be most anything and the authentication id can be thought of as "<username>
in <authentication realm>".  For servers that have an access control
mechanism, the server must have some means of mapping the authentication id
to an authorization id.  And that is left to the server.  I'm fine with
that.

If we look at authentication id with other mechanisms:

GSSAPI:  The authentication id is based on a Kerberos principal name
([email-masked]).  Using the general form I described above:
"<kerberos-principal> in <all Kerberos realms>".

EXTERNAL: Some folks tend to think of the authentication id as the
certificate subject DN, which is something LDAP folks are comfortable with.
But as I understand it, the subject DN really should be used in association
with the issuer DN.  So the authentication id is more properly something
like "<subject-dn> in <certificates issued by issuer-DN>", which isn't a DN
at all.

simple bind:  could be expressed as "<bind-dn> in <RFC2253 LDAP DN>"

Looked at this way, I'd say RFC2829 over-emphasizes authorization id, and
neglects the use that of LDAP DN as a natural choice for user names when
authenticating to a LDAP directory.  I suspect it would be rare for a
client to know what authorization id to specify, and it is likely that a
server would require the user name to be the same id the server would
generate internally.

To summarize:  I'd like authmeth to define a realm name for use with
Digest-MD5 that corresponds to LDAP DNs known to this server.  Authzid is
okay, but perhaps could be better put into context.

John  McMeeking

                      "Ramsay, Ron"                                                                                                 
                      <[email-masked]>         To:       "Mark Ennis" <[email-masked]>, "Kurt D. Zeilenga"                
                      Sent by:                     <[email-masked]>                                                              
                      owner-ietf-ldapbis@O        cc:       <[email-masked]>                                             
                      penLDAP.org                 Subject:  RE: Issues with current authmeth draft.                                 

                      05/12/2003 03:08 AM                                                                                           

Two concepts discussed in this document are authentication identity and
authorisation identity. I take it that access control decisions are made on
the basis of the authorisation identity. Therefore, I believe this should
be a DN. I think RFC 2829 requires that it is a DN if it is provided.
Digest-MD5 seems, through the notion of realm, to assume that
authentication will take place in another domain.

Of TLS, RFC 2829 requires that the certificate subject be taken as the
identity of the user.

It is not clear to me whether the directory actually requires an
authentication identity, but it probably requires an authorisation
identity. Under this interpretation, SASL may provide an authentication
identity and this may or may not be understood by the directory. In the
case of simple bind, the directory must understand it as it is responsible
for authentication. In the case of Digest-MD5 there would be no need to
understand it as authentication is handled 'outside' the directory. In the
case of EXTERNAL, no identity is provided.

For simple bind, the authorisation identity would be the same as the
authentication identity. For EXTERNAL, the authorisation identity should be
the certificate subject. It would seem, for Digest-MD5, that the
authorisation identity, a DN, should be provided unless the server can
derive it by some out-of-band method.

If you agree with this, then the logical course of action would be to
require, for Digest-MD5, that the autorisation identity be a LDAP DN as per
RFC 2253 and that it be provided unless the client has out-of-band
knowledge that the server will derive it.

From the point of view of a server that performs Digest-MD5 authentication
internally, it could use such an authorization identity to locate data
necessary to perform the computation. But in this case, the authentication
identity has no function!

So, how can an authentication identity be useful if it is not a DN? Unless
it, to, is optional. What is our model?

Ron

-----Original Message-----
From: Mark Ennis [mailto:[email-masked]]
Sent: Monday, 12 May 2003 17:25
To: Kurt D. Zeilenga
Cc: [email-masked]
Subject: Re: Issues with current authmeth draft.

Kurt D. Zeilenga wrote:
> At 03:51 PM 5/11/2003, Mark Ennis wrote:
>
>>Kurt D. Zeilenga wrote:
>>
>>>At 10:28 PM 5/6/2003, Mark Ennis wrote:
>>>
>>>
>>>>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).
>>>
>>>RFC 2831 says its a user name.  That is, it's not a LDAPDN, not
>>>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.
>
>
> RFC 2222 says the form of the (proxy) authorization identity
> 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.

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

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.

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

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

Accepted.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 07:52:13 -0700

At 06:16 AM 5/12/2003, John McMeeking wrote:
>a bind DN.

There are few problems here.

First DIGEST-MD5 security considerations encourage server implementors
to store the A1 hash, not the clear text password.  For DIGEST-MD5 to
work as intended, the client MUST provide the authentication identity
is the form which the server used in generating the A1 hash.  There
is no canonical DN textual string representation.

Secondly, when DIGEST-MD5 is revised, the client and the server will
be required to "stringprep" the username according to an algorithm
specified in the DIGEST-MD5.  There will be some LDAPDNs which will
not pass this stringprep and others which would be mangled.  One would
have to define an algorithm for encoding LDAPDNs into DIGEST-MD5
usernames and then require servers decode these for subsequent
processing.

Third, this would make LDAP's use of DIGEST-MD5 inconsistent with
the general use of DIGEST-MD5, yielding it impossible for a
multi-protocol application to consistently use the mechanism.

>One way to do that might be to define a standard realm name
>that LDAP servers support, for example "RFC2253 LDAP DN".

This would defeat the purpose of realms in DIGEST-MD5.

>This would provide a standard way for clients to take advantage of DIGEST-MD5 for
>Looked at this way, I'd say RFC2829 over-emphasizes authorization id,

That I would agree with.  The purpose of SASL authorization identity
strings are to support identity assumption (proxy authorization).

>and

I think we put too much in "LDAP DNs are natural" line.  They aren't.
Users shouldn't have to know their DN.

Kurt

---

From: John McMeeking <[email-masked]>
Date: Mon, 12 May 2003 10:31:35 -0500

First, I doubt that Digest-MD5 with a LDAP DN (either as a authentication
id or as an authorization id) would often be using a DN provided directly
by a user.  I would expect its use to be more likely in one of these
scenarios:

1) An application is configured with a bind DN to use.  For this purpose, I
think it would be reasonable if some standard or directory vendor supplied
tool generated the proper normalized DN required for Digest-MD5.  This
might be a wrapper around a Generate Digest-MD5 UserName extended request.

2) An application authenticates to LDAP by first doing a search for
(&(mail=xxxx)(objectclass=person)) and then issuing an LDAP bind request
with the returned DN and the user entered password.  For this purpose, a
standard algorithm, the above extended operation, or an operational
attribute, could be used.

See additional comments marked <JAM>.

I'll have to refresh my memory on the stringprep part.  If that turns out
to require defining a DN normalization algorithm, or defining supporting
extending operations, it might be more appropriate to address this type of
item in a separate RFC.

John  McMeeking

                      "Kurt D.                                                                                                   
                      Zeilenga"                To:       John McMeeking/Rochester/IBM@IBMUS                                      
                      <[email-masked]        cc:       "Ramsay, Ron" <[email-masked]>, [email-masked], "Mark     
                      g>                        Ennis" <[email-masked]>                                                   
                                               Subject:  RE: Issues with current authmeth draft.                                 
                      05/12/2003 09:52                                                                                           
                      AM                                                                                                         

<JAM>
Technical problems aside (not to trivialize them), I don't see where a
predefined "LDAP DN" realm introduces any such problems.  This realm would
only be used by application that are designed to authenticate using a LDAP
DN, but want the additional password protection.  The multi-protocol
application can use the appropriate realms.
</JAM>

<JAM>
I see this exectly the opposite way.  The purpose realm is to allow the
application to chose which relam it uses and provide a hint to the user
what username would be appropriate.  I do not intend that an LDAP server
would support only this "LDAP DN" realm.
</JAM>

<JAM>
I agree that users shouldn't know what their DN is, and for the
applications I deal with that use simple binds, the user doesn't know their
DN.  However, it is natural for applications to use DNs.
</JAM>

Kurt

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 12 May 2003 20:06:03 -0600

Mark,
 
Would you please  provide a pointer to the text describing the
"reasons... for introducing SASL mechanisms..." that you are referring
to so that I can make appropriate changes.
 
Thanks,
 
Roger

>>> "Kurt D. Zeilenga" <[email-masked]> 5/12/2003 7:14:39 PM >>>
At 05:08 PM 5/12/2003, Mark Ennis wrote:
>This seems counter to the reasons in RFC2829 and [authmeth] for
introducing SASL mechanisms, in particular, SASL DIGEST-MD5. 

Well then we should clarify the rationale.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 13 May 2003 12:12:27 +1000

I don't see how you can say that these authentication methods are not expected to use DNs. RFC 2829 states:

"All servers which support the storage of authentication credentials, such as passwords or certificates, in the directory MUST support the dnAuthzId choice."

The word is MUST!

I don't know what you make of

"The user's certificate subject field SHOULD be the name of the user's directory entry...."

but it suggests to me that the subject DN is the authetication name.

But without dwelling on the technicalities I think we have a simple problem here. If Digest-MD5 is a non-directory authentication method it must be removed from authmeth (to its own RFC). Authmeth should only deal with LDAP-based authentication methods.

The problem with Digest-MD5 is that either the password or a hash of the password has to be stored somewhere. A "directory" implementation would store this in a "user" entry and use an authentication identity which is the name of this entry. I see that you propose that the auth ID shoudl be a simple string, and that the directory should resolve this to a DN, if it needs to, but this is using the directory as a directory application! and is clearly not appropriate for a mandatory-to-implement procedure as the actual mechanism is not specified.

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 13 May 2003 09:26
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Issues with current authmeth draft.

At 01:08 AM 5/12/2003, Ramsay, Ron wrote:
>Two concepts discussed in this document are authentication identity and authorisation identity.   I take it that access control decisions are made on the basis of the authorisation identity.

The form of the authorization identity used in access control
decisions may not be the same as the form asserted by the
client wishing to assume some identity.  Note that when a
client does asserts an authorization identity, is requesting
to assume an identity other than that associated with its
credentials.  When an client wishes to act under its own
identity is should not assert a proxy authorization identity.

>Therefore, I believe this should be a DN. I think RFC 2829 requires that it is a DN if it is provided.

Sorry, no.

>Digest-MD5 seems, through the notion of realm, to assume that authentication will take place in another domain.

>Of TLS, RFC 2829 requires that the certificate subject be taken as the identity of the user.

Sorry, no.  RFC 2829, 5.1.2.1:
   The server will derive the client's authorization identity from
   the authentication identity supplied in the client's TLS
   credentials (typically a public key certificate) according
   to local policy.   The underlying mechanics of  
   how this is accomplished are implementation specific.

>It is not clear to me whether the directory actually requires an authentication identity, but it probably requires an authorisation identity. 

Yes, one can take the view that SASL authentication results in the
establishment of an authorization identity suitable for use in
subsequent access control decisions.

>Under this interpretation, SASL may provide an authentication identity and this may or may not be understood by the directory.

If you have clear separation between SASL and directory processing,
authentication details can be hidden from the directory.  The SASL
subsystem can be produce an authorization identity which the access
control subsystem can (directly or indirectly) use.

>In the case of simple bind, the directory must understand it as it is responsible for authentication. 

Well, I think it can be argued that the bind name need not refer
to an entry normally visible as part of the directory.  For example,
a server is quite free to map the bind name to some identity in an
external and then ask that external system to verify the credentials.

>In the case of Digest-MD5 there would be no need to understand it as authentication is handled 'outside' the directory.

Well, then again, a server is free to map the username to a DN
and access information at that DN in order to complete authentication.

>In the case of EXTERNAL, no identity is provided.

>For simple bind, the authorisation identity would be the same as the authentication identity.

Yes, but the server is free to represent the authorization identity
in another form if so chooses.  Maybe it prefers authzids.  Maybe
it prefers short user names.

>For EXTERNAL, the authorisation identity should be the certificate subject.

Not necessarily.  The server could, for instance, use an alternative
subject name.  Or the certificate serial number.

> It would seem, for Digest-MD5, that the authorisation identity, a DN, should be provided unless the server can derive it by some out-of-band method.

Maybe the server uses usernames directly in its access control system.
No DN form needed.  But if the server needed a DN, it certainly can
map the username to a DN using whatever algorithm suits it.

>If you agree with this,

I think not.

>then the logical course of action would be to require, for Digest-MD5, that the autorisation identity be a LDAP DN as per RFC 2253

No.  The authzid is for proxy authorization, not for indicating which
identity should be derived from the authentication identity.

>and that it be provided unless the client has out-of-band knowledge that the server will derive it.

The client should assume the server is capable of deriving a
suitable authorization identity in the appropriate form from the
authentication identity associated with its credentials.  Requiring
the normal clients (those not doing proxy authorization) to know more
than its credentials is unnecessary and counter to intent of
username/password mechanisms.

If the client knows instead a DN and password, then it should a
mechanism intended for DN/password authentication (such as
Simple bind over TLS).

>From the point of view of a server that performs Digest-MD5 authentication internally, it could use such an authorization identity to locate data necessary to perform the computation. But in this case, the authentication identity has no function!

Sorry, but I think that has a significant impact upon the security
of the mechanism.

>So, how can an authentication identity be useful if it is not a DN?

There is actually no requirement to implement authentication
and authorization based upon DNs.  A server could just implement
the DIGEST-MD5, not support proxy authorization at all, and use
simple user names in making access control decisions.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 13 May 2003 12:20:27 +1000

I don't like messages that say "hear, hear", but I fell compelled to say hear, hear! There is also no credence given to the greater effort required to run TLS operationally. Digest-MD5 was suggested as a replacement for CRAM-MD5 not, as I believe, because it had very little connection with directories, but because it was argued to be superior. The aim, though, was a password mechanism that did not present the password in the clear.

Ron

-----Original Message-----
From: Mark Ennis [mailto:[email-masked]]
Sent: Tuesday, 13 May 2003 10:08
To: Kurt D. Zeilenga
Cc: Ramsay, Ron; [email-masked]
Subject: Re: Issues with current authmeth draft.

> mechanism intended for DN/password authentication (such as

 From an interoperability perspective this has problems as a server is 
only required to implement DIGEST-MD5 and simple authentication, not 
TLS. This theoretical client would then only be able to interwork with 
servers which implement TLS or would be forced to use a less secure 
authentication mechanism (simple bind without TLS). This seems counter 
to the reasons in RFC2829 and [authmeth] for introducing SASL 
mechanisms, in particular, SASL DIGEST-MD5.

- Mark.

---

From: Mark Ennis <[email-masked]>
Date: Tue, 13 May 2003 13:37:38 +1000

Roger,

I am not convinced at this stage that the text under discussion needs to 
be revised. We also have the problem that "clarification" of this text 
could lead to backward compatibility problems with pre-LDAPbis systems 
as we are potentially changing assumption on which the remaining text 
has, in the past, been interpreted. Particularly given that the text 
from the [authmeth] introduction has re-iterated the same points made in 
RFC2829 *1. Introduction*.

However, that said, I was referencing the following:

The [authmeth] text in *2. Introduction* discusses the security 
considerations for LDAP, identifying a set of basic threats and then the 
security mechanisms proposed to minimise these risks, including use of 
SASL and TLS.

The [authmeth] text in *3. Rationale for LDAPv3 Security Mechanisms* 
discusses the desirability for identities to take the form of 
distinguished names and authentication data to be stored in the 
directory. It also suggests support for non-LDAPDN authorization 
identities should be supported for backward-compatibility with 
non-LDAP-based authentication services.

- Mark.