Subject: authmeth: removal of DIGEST-MD5

From: "Roger Harrison" <[email-masked]>
Date: Thu, 13 Oct 2005 12:49:20 -0600

Based on the comments to the WG over the past several days, I believe
that authmeth should only reference DIGEST-MD5 in historical terms.  The
Simple Mechanism Security Considerations currently state: 

The name/password authentication mechanism of the simple Bind method
discloses the password to the server, which is an inherent security
risk. There are other mechanisms such as DIGEST-MD5 that do not disclose
the password to the server. 

I would like to replace this reference with DIGEST-MD5 with another
mechanism (it does not need to be normative) that would not disclose the
password to the server. Suggestions? 

Thanks, 

Roger

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Oct 2005 12:07:17 -0700

At 11:49 AM 10/13/2005, Roger Harrison wrote:

>Based on the comments to the WG over the past several days, I believe that authmeth should only reference DIGEST-MD5 in historical terms.  The Simple Mechanism Security Considerations currently state: 
>
>"The name/password authentication mechanism of the simple Bind method discloses the password to the server, which is an inherent security risk. There are other mechanisms such as DIGEST-MD5 that do not disclose the password to the server." 
>
>I would like to replace this reference with DIGEST-MD5 with another mechanism (it does not need to be normative) that would not disclose the password to the server. Suggestions? 

I'm fine with leaving this sentence in place as it doesn't
require a normative reference to DIGEST-MD5.

---

From: Howard Chu <[email-masked]>
Date: Thu, 13 Oct 2005 12:19:33 -0700

Roger Harrison wrote:
> "The name/password authentication mechanism of the simple Bind method 
> the password to the server."
> 

GSSAPI would probably be the next most recognizable choice. Just off the 
top of my head.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Oct 2005 21:27:07 +0200

Roger Harrison writes:
> that authmeth should only reference DIGEST-MD5 in historical terms.

You should probably keep much of the DIGEST-MD5 text on authmeth-15
page 16 and generalize it to talk about SASL.

> The Simple Mechanism Security Considerations currently state:
>
> mechanism (it does not need to be normative) that would not disclose
> the password to the server.  Suggestions?

CRAM-MD5 seems to be the only alternative mechanism which is widely
enough deployed to suggest now.  That mechanism apparently has its own
problems, though.  So I suggest to keep the DIGEST-MD5 reference.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Oct 2005 12:54:31 -0700

>problems, though.  So I suggest to keep the DIGEST-MD5 reference. 

I note that while CRAM-MD5 and DIGEST-MD5 don't expose the
actual password, they do expose a hash of that password that
is quite prone to offline dictionary attacks.  I'd argue
that you need to be just as careful as to whom you give
that hash to as you are giving out the actual password.

Kurt

---

From: Howard Chu <[email-masked]>
Date: Thu, 13 Oct 2005 12:57:55 -0700

> page 16 and generalize it to talk about SASL.

Good point.

> problems, though.  So I suggest to keep the DIGEST-MD5 reference.

Indeed. Definitely not CRAM-MD5.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Oct 2005 22:18:30 +0200

> GSSAPI would probably be the next most recognizable choice. Just off the

I forgot about that one.  My impresson was that there has been a lot of
hype but not yet that much deployment, but I may be badly out of date.
Or maybe DIGEST-MD5 deployment is bad enough that GSSAPI competes well
anyway?

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Oct 2005 22:27:46 +0200

> that hash to as you are giving out the actual password.

Or not use passwords that resemble words in dictionaries?

Keep in mind that Unix DES crypt is still in use, though...

-- 
Hallvard

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 14 Oct 2005 09:39:55 +0200

I'm fine with keeping the sentence as is. This is not a normative reference.

Ludovic.

-- 
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo                              Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Roger Harrison" <[email-masked]>
Date: Wed, 19 Oct 2005 17:27:52 -0600

Hallvard, 

I've added this new section to authmeth-17 based on your suggestion. 
I'd appreciate comments and feedback prior to my submitting authmeth-17
on Friday. 

5.2.2. SASL Semantics Within LDAP 

Implementers must take care to ensure that they maintain the semantics
of SASL specifications when handling data that has different semantics
in the LDAP protocol. 

For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
utilizes realm and username values ([DIGEST-MD5] section 2.1) which are
syntactically simple strings and semantically simple realm and username
values. These values are not LDAP DNs, and there is no requirement that
they be represented or treated as such. Username and realm values that
look like LDAP DNs in form, e.g. <cn=bob, dc=example,dc=com>, are
syntactically allowed, however DIGEST-MD5 treats them as simple strings
for comparison purposes. To illustrate further, the two DNs
<cn=Bob,dc=example,dc=com> (upper case B) and <cn=bob,dc=example,dc=com>
(lower case b) are equivalent when being compared semantically as LDAP
DNs because the cn attribute is defined to be case insensitive, however
the two values are not equivalent if they represent username values in
DIGEST-MD5 because [SASLPrep] semantics are used by DIGEST-MD5. 

Thanks, 

Roger

>>> Hallvard B Furuseth <[email-masked]> 10/13/05 1:27 pm >>>

--
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 20 Oct 2005 09:02:32 -0600

Hallvard, 

Shortly after sending a proposed new section 5.2.2 for authmeth-17, I rediscovered your email on the same subject from last March. I've reworked section 5.2.2, as below. I'd appreciate comments and feedback prior to my submitting authmeth-17 on Friday. 

Implementers must take care to ensure that they maintain the semantics of SASL specifications when handling data that has different semantics in the LDAP protocol. 

For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829] utilizes an authentication identity (username) and a realm which are syntactically simple strings and semantically simple username and realm values ([DIGEST-MD5] section 2.1). These values are not LDAP DNs, and there is no requirement that they be represented or treated as such. 

After preparing these values as specified in [DIGEST‑MD5], the server may choose to use LDAP semantics to locate an entry with the user's authentication information.  For example, it may expect the username to have the form of a DN and look up the named entry, or it may search for (cn=<username>) below cn=<realm>,cn=auth,dc=example,dc=com.  However, when the entry is located, authentication will fail if the realm and username values do not match according to DIGEST‑MD5's semantics. 

To illustrate, the two DNs <cn=Bob,dc=example,dc=com> (upper case B) and <cn=bob,dc=example,dc=com> (lower case b) are equivalent when being compared semantically as LDAP DNs because the cn attribute is defined to be case insensitive, however the two values are not equivalent if they represent username values in DIGEST‑MD5 because DIGEST‑MD5 matching is case‑sensitive. 

Thanks, 

Roger

--
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 22:50:36 +0200

Roger Harrison writes:
> Shortly after sending a proposed new section 5.2.2 for authmeth-17, I
> rediscovered your email on the same subject from last March. I've
> reworked section 5.2.2, as below. I'd appreciate comments and feedback
> prior to my submitting authmeth-17 on Friday.

> of SASL specifications when handling data that has different semantics

That can be shortened even more since my original clumsy wording:

s/take care to ensure that they maintain/take care to maintain/.

> After preparing these values as specified in [DIGEST-MD5], the
> server may choose to use LDAP semantics to locate an entry with the
> user's authentication information.  For example, it may expect the
> username to have the form of a DN and look up the named entry, or it may
> search for (cn=<username>) below cn=<realm>,cn=auth,dc=example,dc=com.
> However, when the entry is located, authentication will fail if the
> realm and username values do not match according to DIGEST-MD5's
> semantics.

Maybe s/authentication will fail/authentication may fail/.

As I wrote in that old message (a bit less clearly:-), I wonder if both
the quoted text and the original authmeth DIGEST-MD5 text is too strict,
though I didn't know what to do about it at the time:

Formally, I imagine the server could regard <cn=Bob,...> and
<cn=bob,...> as different DIGEST-MD5 usernames which have the same
password:  Since the username => password mapping in the example is
implemented in LDAP, the mapping has LDAP semantics.

For DIGEST-MD5, that would only work if the server stores the password
as plaintext so it can hash it with the username provided by the client.
It won't work if what the server stores is a hash of (password, DN,
realm).

I don't know the intent of either SASL or LDAP specs in this regard
though.

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Fri, 21 Oct 2005 21:00:05 -0600

> As I wrote in that old message (a bit less clearly:‑), I wonder if both 
> the quoted text and the original authmeth DIGEST‑MD5 text is too strict, 
> <cn=bob,...> as different DIGEST‑MD5 usernames which have the same 
> For DIGEST‑MD5, that would only work if the server stores the password 

I think this example will be OK because it is correct (to the best of my knowledge) and it isn't meant to exhaustively enumerate the issues with DIGEST-MD5 semantics relative to LDAP such as the method used to generate a hash value. 

Roger

---

From: "Roger Harrison" <[email-masked]>
Date: Fri, 21 Oct 2005 21:21:41 -0600

> Hallvard Furuseth wrote: 
> 
> 4. Authorization State has been changed to include 
> 
> >   It is noted that other events both internal and external to LDAP may 
> >   result in the authentication and authorization states being moved to 
> >   an anonymous one.  For instance, the establishment, change, or 
> >   closure of security services may result in a move to an anonymous 
> >   state, or the user's credential information (e.g., certificate) may 
> >   have expired.  The former is an example of an event internal to LDAP 
> >   whereas the latter is an example of an event external to LDAP. 
> 
> As I wrote in message 
> <http://www.openldap.org/lists/ietf-ldapbis/200510/msg00012.html>, 
> 
> internal events that revert the auth to anonymous can lead to major 
> breakage at the client side, e.g. for clients that treat noSuchObject 
> as information that the some value is not present in the directory. 
> At our site, e‑mail to valid addresses would bounce since LDAP informed 
> the mail system that the address is not present. 
> 
> I suppose the draft could allow for server admins to configure such 
> behaviour, and add warnings about it, but unless there is a strong call 
> for this functionality I don't see a good reason for blessing it.  
> 
> If this change was done in response to the invalidated associations 
> discussions, this is not the right answer.  The possibilities that I am 
> aware of is for unacceptable requests could get some didn't perform 
> the operation‑result code, or cause the the server to close the 
> connection. 
> 

I agree with Hallvard on this.  It seems that this situation really could leave the client clueless as to its current state and the need to take action to reestablish its desired authentication state.  I see three possibilities for the server to communicate an event that has caused the authentication state being moved to anonymous: 

1. Use an unsolicited notification 
2. Send a notice of disconnect 
3. Use a specific result code in subsequent operation responses 

#1 is probably outside the purview of the ldapbis charter; I view it as adding a new element to the protocol. #2 would work indirectly by forcing the client to reestablish a connection and the desired authentication/authorization state.  #3 might require overloading an existing result code such as unwillingToPerform or strongerAuthRequired (a bad idea, I think) or adding a new result code (probably outside the purview of the ldapbis charter). 

None of these options seem particularly nice, but I believe we need to choose one of them. 

Roger

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 22 Oct 2005 05:32:06 +0200

Roger Harrison writes:
>> As I wrote in that old message (a bit less clearly:$,1rq(B), I wonder if
>> both the quoted text and the original authmeth DIGEST$,1rq(BMD5 text is too
>> strict, though I didn't know what to do about it at the time:
>>
>> <cn=bob,...> as different DIGEST$,1rq(BMD5 usernames which have the same
>> password
>> (...)
>
> I think this example will be OK because it is correct (to the best of
> my knowledge)

I've not a clue myself.

> and it isn't meant to exhaustively enumerate the issues with
> DIGEST-MD5 semantics relative to LDAP such as the method used to
> generate a hash value.

No, I was only suggesting s/will fail/may fail/ at this time.
Or "can fail".  A long explanation for a short word:-)

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 22 Oct 2005 06:12:04 +0200

(Wrong thread or subject line:-)

Roger Harrison writes:
>>>   an anonymous one.  (...)
> I agree with Hallvard on this.  It seems that this situation really
> could leave the client clueless as to its current state and the need
> to take action to reestablish its desired authentication state.

If you are still brushing up on authmeth-17, I suggest to leave it alone
for now, or at least until Kurt can reply.  His current text has after
all been sitting more or less unopposed for a while, and there isn't
chance for much discussion for -17 now.  I'll be posting a reply to Kurt
soon.

> I see three possibilities for the server to communicate an event that
> has caused the authentication state being moved to anonymous:
>

4. Don't try to inform the client of the real problem (except maybe in
the diagnosticMessage field), just keep sending failure result codes
that fit each individual request.

5. Kurt pointed out that it would be quite valid to use the "authz ID is
now unreliable" as an access control factor.  I think something like
that is a lot better than reverting to anon; getting back to that in a
reply to Kurt.

> None of these options seem particularly nice, but I believe we need to

Or let the server admin choose.

I think #1 and #3 were shot down and that's one reason we gave up on
invalidated associations, except as extensions (maybe after the client
has requested them).

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 22 Oct 2005 02:11:05 -0700

At 08:21 PM 10/21/2005, Roger Harrison wrote:
>I agree with Hallvard on this.  It seems that this situation really could leave the client clueless as to its current state

I believe we've been through this before.

The client is always clueless as to its current authorization
state.  Authorization is a local matter.  Even though the client
may know at times (such as upon connect) that its in an anonymous
authorization state, it doesn't know which anonymous state its in
(they might not all be equivalent).  And when some authenticated
state, it doesn't know (through the protocol) which authenticated
authorization state its in, nor what authorization that state
may grant/deny, or whether or not that state is equivalent to
some anonymous state.

>and the need to take action to reestablish its desired authentication state.
>I see three possibilities for the server to communicate an event that has caused the authentication state being moved to anonymous: 

> 1. Use an unsolicited notification 

There is no such unsolicited notification defined.
LDAPBIS is not chartered to add any.

> 2. Send a notice of disconnect 

A server can certain disconnect the client if it wants to,
but it also free to continue providing service to the
client in whatever authorization state the server considers
the client to be in.

> 3. Use a specific result code in subsequent operation responses 

LDAP Result codes are only indicative of why the requested
operation failed.  LDAPBIS is not chartered to add new
result codes.

> we need to choose one of them. 

Historically, LDAP servers have reduced service to clients
to fit their current authorization instead of returning
authorization errors, including reduction of service to
that equivalent to an anonymous user.  LDAP servers may
also, and some do, support "don't disclose on error"
capabilities.  Clients need to designed with both of these
aspects in mind.

As authorization is a local matter, servers are free to move the
authorization state to an anonymous-like authorization state.
This anonymous-like authorization state may be functionally
equivalent an anonymous authorization state.  The distinction
is irrelevant in the protocol and to the client.  To the
server, whatever distinction that might be there is simply
an implementation detail.

While some may not like this, without re-engineering the
protocol, there is nothing we can about this.  As such
re-engineering is beyond the scope of our charter, the
best we can do is detail these aspects of LDAP and
offer appropriate considerations.

-- Kurt

---

From: "Roger Harrison" <[email-masked]>
Date: Sat, 22 Oct 2005 18:34:16 -0600

I've added this security consideration in response to your note below:
 
6.3.4. Hashed Password Security Considerations
 
Some authentication mechanisms (e.g. DIGEST-MD5) transmit a hash of the
password value that may be vulnerable to offline dictionary attacks. 
Implementers should take care to protect such hashed password values
during transmission using mechanisms similar to those suggested for
protecting clear text passwords.
 
Roger

>>> "Kurt D. Zeilenga" <[email-masked]> 10/13/2005 1:54 pm >>>

Kurt

---

From: "Roger Harrison" <[email-masked]>
Date: Sat, 22 Oct 2005 18:41:20 -0600

> Or "can fail".  A long explanation for a short word:-)
 
Perhaps I'm not very imaginative, but how could the authentication
succeed if there isn't a match according to SASL DIGEST-MD5 semantics?
Can you give me at least a possible example? If so, I'll gladly s/will
fail/may fail/. If not, I think I'd prefer to leave it as "will fail."

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 23 Oct 2005 03:05:34 +0200

> fail/may fail/. If not, I think I'd prefer to leave it as "will fail."

It will fail if there is no match by the DIGEST-MD5 semantics, but the
implementor may have a choice as to which values to apply that semantics
to.

If I bind as "hbf" and the directory locates an entry with "UID: HBF",
authentication will fail if the server uses the uid stored in the server
to compute the hash value.  It will succeed if the server uses the uid
provided by the client for the hash - which might be allowable since
"hbf" denotes the same user as "HBF" in LDAP.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Oct 2005 11:05:59 +0100

I think I've missed few issues before:

> utilizes an authentication identity (username)
>
A bit of nit picking: according to SASL "username" is not authentication 
identity, it is authorization identity. So I suggested you remove 
"(username)".

> and a realm which are syntactically simple strings and semantically 
> simple username and realm values ([DIGEST-MD5] section 2.1). These 
> values are not LDAP DNs, and there is no requirement that they be 
> represented or treated as such.
>
[...]

> To illustrate, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") 
> and <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when 
> being compared semantically as LDAP DNs because the cn attribute is 
> defined to be case insensitive, however the two values are not 
> equivalent if they represent username values in DIGEST‑MD5 because 
> DIGEST‑MD5 matching is case‑sensitive.
>
"username" ==> "authentication identity".

The client has to treat authentication identities and realms as 
case-sensitive, because it doesn't know if the server treats them as 
case-sensitive or not.
However a server implementation can treat authentication 
identities/realms as case-insensitive and I know that some existing 
implementations are. For such servers the last statement is not correct. 
So I suggest to weaken the last sentence: "however the two values are 
not necessarily equivalent .. because DIGEST-MD5 matching might be 
case-sensitive". Or "because DIGEST‑MD5 matching is usually case‑sensitive".

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Oct 2005 11:05:21 +0100

>Maybe s/authentication will fail/authentication may fail/.
I completely agree. Otherwise the last sentence might be read as being 
prescriptive.

Isode implementation might be configured to search for 
(<attr>=<username>) below a realm entry, but we certainly never check 
that the found entry contain <attr> value exactly as specified in the 
SASL Bind request.

---

From: "Roger Harrison" <[email-masked]>
Date: Tue, 25 Oct 2005 17:06:51 -0600

Thanks for the feedback. I've incorporated all of your suggested changes
into authmeth-18. This section now reads:

Implementers must take care to maintain the semantics of SASL
specifications when handling data that has different semantics in the
LDAP protocol.

For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
utilizes an authentication identity and a realm which are syntactically
simple strings and semantically simple username and realm values
([DIGEST-MD5] section 2.1). These values are not LDAP DNs, and there is
no requirement that they be represented or treated as such.

After preparing these values as specified in [DIGEST- MD5], the server
may choose to use LDAP semantics to locate an entry with the user's
authentication information.  For example, it may expect the
authentication identity to have the form of a DN and look up the named
entry, or it may search for "(cn=<authentication identity>)" below
"cn=<realm>,cn=auth,dc=example,dc=com".  However, when the entry is
located, authentication may fail if the realm and authentication
identity values do not match according to DIGEST- MD5's semantics.  For
example, the two DNs "cn=Bob,dc=example,dc=com" (upper case 'B') and
"cn=bob,dc=example,dc=com" (lower case 'b') are equivalent when being
compared semantically as LDAP DNs because the cn attribute is defined to
be case insensitive, however the two values are not necessarily
equivalent if they represent authentication identity values in DIGEST-
MD5 because DIGEST- MD5 matching usually is case- sensitive.

Roger

>>> On Mon, Oct 24, 2005 at  4:05 am, in message
<[email-masked]>,

>> equivalent if they represent username values in DIGEST- MD5 because

>> DIGEST- MD5 matching is case- sensitive.
>>

> case-sensitive". Or "because DIGEST- MD5 matching is usually case-
sensitive".