Subject: Re: authmeth review notes [long]

From: Michael Ströder <[email-masked]>
Date: Mon, 01 Mar 2004 18:04:07 +0100

Kurt D. Zeilenga wrote:
> 
>  LDAP implementations SHOULD support the simple DN/password mechanism
>  of the simple Bind method (as detailed in Section X).

s/SHOULD/MUST/

>  Implementations
>  which support this mechanism MUST be capable of protecting it by
>  establishment (as discussed in Section 3) of TLS. 

s/MUST/SHOULD/

Kurt, although I appreciate your intention to emphasize the need for
transport layer security for clear-text passwords I see it the other way round.

> Instead, I suggest:
> [..]
> 	The server is only to return success result
> 	code when the credentials are valid and the server is willing
> 	to provide service to the entity these credentials identify.

Hmm, this combined sentence mixes authentication and authorization. I don't
like that since an LDAP application cannot distinguish between failed
authentication and missing authorization. IMO in the latter case
insufficientAccessRights should be returned.

>> 9. SASL EXTERNAL Mechanism
> [..] For ease of implementation, we should avoid mandating
> mechanism-specific failure handling.

Yes!

Ciao, Michael.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 19:09:42 +0100

Kurt D. Zeilenga writes:
>> 1. Introduction
>> (...)
>>    LDAP offers the following security mechanisms:
>>
>>    (1) Authentication by means of the Bind operation.  The Bind
>>        operation provides a simple method which supports anonymous,
>>        unauthenticated, and authenticated with password mechanisms, and
>>        the Secure Authentication and Security Layer (SASL) method which
>>        supports a wide variety of authentication mechanisms and which
>>        may be extended to support additional methods of authentication.
>
> s/./,/
> s/and which...//  (no need to discuss extensibility here)

Whoops, I seem to have lost the thread I started about this with my
earlier review notes.  ('authmeth-09 comments', ended by Kurt's message
<http://www.openldap.org/lists/ietf-ldapbis/200401/msg00073.html>.)

I do not think this list should talk about LDAP operations like Bind.
It should talk about features which LDAP makes use of, such as passwords
and SASL.  That's why I suggested

  (1) Client authentication by various means, including a simple
      password mechanism and the Secure Authentication and Security
      Layer (SASL) [SASL] mechanism set, as well as unauthenticated
      users,

Kurt replied,

  I rather drop the "as well as unauthenticated users" phrase (which
  actually is a problem in my suggestion as well) because we're talking
  about means for establishing the client identity, not means for
  establishing an anonymous association.

I'm fine with that (and maybe s/client//).  Kurt, I'm not sure if you
feel that argument still applies to the current [Authmeth] text, or if
my text - if it is used - should be expanded to mention anonymous and
unauthenticated associations?

>>    (2) Client authorization by means of access control based on the
>>        requestor's authenticated identity,
>
> Given that LDAP doesn't offer an authorization (access control)
> model, this seems dubious (even with the note below).  However, I
> don't have a suggestion (at the moment) on how to better address
> this.

Put "Servers are expected to support" in front of the sentence?

>>    Given the presence of the Directory, there is a strong desire to see
>>    mechanisms where identities take the form of an LDAP distinguished
>>    name [LDAPDN] and authentication data can be stored in the
>>    directory.
>
> s/see/use/
> s/take the form of an LDAP distinguished name/
> s/are represented as distinguished names [X.501][Models] in string
> form [LDAPDN]/.

>>                This means that this data must be updated outside the
>>    protocol or only updated in sessions well protected against
>>    snooping.
>
> s/snooping/eavesdropping/ (use RFC2828 term)

This sentence has nothing to do with DN identities and authentication
data in the directory.  It also applies if the server supports an
extended operation to modify passwords stored outside the directory,
with non-DN identities.  I think it belongs in Section 11 - unless
Section 11 is modified to only talk about authentication, like Kurt
suggested in thread 'authmeth: passwords in the clear', message
<http://www.openldap.org/lists/ietf-ldapbis/200402/msg00086.html>:-)
Also, it applies to any sensitive data, not just authentication data.
So I'm not sure that it is any need to mention this special case at all.

>>                It is also desirable to allow authentication methods to
>>    carry identities not represented as LDAP DNs that are familiar to
>>    the user or that are used in other systems.
>
> suggest:
> 	It is also desirable to allow authentication methods to
> 	carry identities (other than DNs) that are familiar to the
> 	user or that are used in other systems.

...and also to authenticate against existing credentials maintained and
stored outside the LDAP installation.

> I would like to add a new section (or possible placed subsequent
> to the technical specification of these features) which gathers the
> high level implementation requirements.

Good idea, if you mean to move the requirements to this section,
rather than to copy them.  However, you have made many changes:

> 2.  Implementation Requirements

>  LDAP implementations which support any authentication mechanism
>  (other than anonymous mechanism of the simple Bind method) MUST
>  support the DIGEST-MD5 [RFC2831bis] mechanism of the SASL Bind
>  method (as detailed in Section X).

I preferred the authmeth-10 text which only required this of servers,
not "implementations".  It should be OK to write thin clients.

Also, the original text from Section 10 (quoted below) seems clear
enough to me, I don't see why you spelled it out more than this?

   LDAP servers that implement any authentication method or mechanism 
   other than simple anonymous bind MUST implement the SASL 
   DIGEST-MD5 mechanism [DIGEST-MD5].

(Well, I liked your s/method or mechanism/mechanism/, and I'd suggest
s/DIGEST-MD5 mechanism/DIGEST-MD5 authentication mechanism/ if that
text is moved the new section.)

>  That is, excepting those
>  implementations which only support anonymous connections, all
>  implementations MUST support DIGEST-MD5.

Strike this, it is clear enough from the first sentence.  Though we
could rearrange that sentence a bit to emphasize the DIGEST-MD5
requirement, if we keep your spelled-out version:

   LDAP {servers/implementations} MUST support the DIGEST-MD5
   [DIGEST-MD5] mechanism of the SASL Bind method (as detailed in
   Section X) if they support any authentication mechanism other than
   the anonymous mechanism of the Simple Bind method.

>  of the simple Bind method (as detailed in Section X).  Implementations

This has several differences from the requirements in Section 7.  I seem
to remember there have been previous discussions about just what bind
methods should be supported when.  I don't think this should be changed
without more discussion.  E.g., I disagree with the TLS requirement.
Other protection, like IPSec, ldap://localhost/, or a Unix filename
socket, is fine.  Also note section H.45:

   Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG 
   consensus that Simple+TLS should be mandatory to implement. No 
   further discussion is necessary. 

BTW, I can't find any requirement that TLS be supported.

>  LDAP server implementations MUST support the anonymous mechanism of
>  the simple Bind method.

You changed this from "implementations" to "server implementations".
I guess I agree with that.

BTW, MUST they support unauthenticated binds?  Section 6 says those
SHOULD by default be rejected; I'm not sure if that means it MUST be
possible to turn the default off.

>  Implementations MAY support additional authentication mechanisms of
>  the simple and SASL bind methods, and/or mechanisms of other bind
>  methods.  Some of these mechanisms are discussed below.

I think this paragraph can be dropped.

>> 3.1.1. Start TLS Request
>>
>>    A client may send the Start TLS extended request at any time after
>>    establishing an LDAP connection, except:
>>
>>       - when TLS is currently established on the connection,
>>       - when a multi-stage SASL negotiation is in progress on the
>>         connection, or
>>       - when there are outstanding LDAP operations on the connection.
>
> s/LDAP operations/responses for previously issued operations/
>
> This makes, I think, it clear that clients are to wait.

I don't see the difference; I liked the original better.  However, I
like your following change anyway:

> Hence,
> the following paragraph can be replaced with:
>
> 	As described in [Protocol, Section 4.13.2.2], a (detected)
> 	violation of any of these requirements results in return of
> 	the operationsError resultCode.

>> 6. Anonymous Authentication
>>
>>    Directory operations that modify entries or access protected
>>    attributes or entries generally require client authentication.
>>    Clients that do not intend to perform any of these operations
>>    typically use anonymous authentication.
>
> I hope this is not typical.

Why?

> I think this paragraph should simply be deleted.

Yes.

>> 7. Simple Authentication

>>    An LDAP client may establish an LDAP association by sending a Bind
>>    Request with a name value consisting of an LDAP distinguished name
>>    [LDAPDN] and specifying the simple authentication choice with a
>>    password value.
>
> s/an LDAP distinguished name/a distinguished name in LDAP string
> form [LDAPDN]/

I don't see why, except the [LDAPDN] reference.

> s/password value/password value, an OCTET STRING.

Why?

>>    DSAs that map the DN sent in the bind request to a directory entry
>>    with an associated set of one or more passwords will compare the
>>    presented password to the set of passwords associated with that
>>    entry.

> s/more passwords/more passwords, each an OCTET STRING,/
> s/compare/compare octet wise/

No!

- [SASLprep] may apply first.

- If the directory entry contains a password, how to compare the
  passwords should be defined by the password attribute's syntax.  For
  example, caseExactMatch would be appropriate if one uses long
  passwords that consist of several easy-to-remember words instead of
  short cryptic passwords.

- Even if DN is mapped to a directory entry, the entry's password
  attribute may refer to some user's password stored in the operating
  system, and one must use the operating system's routine to compare
  passwords.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 19:25:03 +0100

>>  establishment (as discussed in Section 3) of TLS. 

Still wrong.  Together, these changes require implementations that do
not support TLS, to implement a security hole.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 10:36:00 -0800

>not support TLS, to implement a security hole.

Which security hole you refer to here?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 10:55:12 -0800

Hallvard, nevermind regarding my previous post.  After re-reading
Michael's and your messages, I believe I understand what each of
you are getting at.

Michael, I believe the text, which mandates implementations be
capable of protecting simple password authentication using TLS,
is supported by WG consensus.  Operational experience has shown,
that in absence of such mandates, implementations will not offer
adequate protective services.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 19:48:48 +0100

> Which security hole you refer to here?

Simple bind with an unprotected cleartext password.  But I should have
said, implementations will be required to _support_ a security hole.
They don't have to activate it.  Unfortunately, one can trust some users
to activate it, and some server admins to allow such binds.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 12:22:31 -0800

At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:
>rather than to copy them.

The idea is to provide a brief general "applicability statement"
which details which security services are required, recommended,
or elective (but not detailing how those services are to be
implemented).  That is, it details the what should be implemented,
not the how they should be implemented.

It might be best to title the section "General Applicability Statement"

>However, you have made many changes:

Yes.  authmeth-10, I believe, is not fully consistent with the WG
consensus as previously gauged.  Hence, the changes.

>not "implementations".  It should be OK to write thin clients.

I believe similar concerns were previously discussed.  I believe
consensus supports the requirement as applying to both clients and
servers.

>   DIGEST-MD5 mechanism [DIGEST-MD5].

I have tried to be more precise regarding Bind methods and
authentication mechanisms.  Each Bind method can support multiple
mechanisms.  I hope that we can carry this precision into
the rest of the specification.

>text is moved the new section.)

I actually had in a rough draft written "authentication mechanism"
in the second sentence.  I removed it because, without it, it should
be clear I'm referring to mechanisms of the first sentence but
with it, it **could** be viewed as referring to only the authentication
aspects of the DIGEST-MD5 mechanism.  (English is a fun language.)

However, I'm fine either way.  Just wanted to let you know that I
had considered that wording and why I opted for this instead.

>Strike this, it is clear enough from the first sentence.

We've had a bit of confusion here, I added this statement to
really drive it home.  That is, while I agree that the first
sentence should be clear enough, it seems some are having a
hard time understanding its meaning.  So I think reenforcement
here is good.

>Though we

I prefer my wording.  It avoids the "if ... other than" construction
(which I think was causing some of the confusion).

>without more discussion.

Actually, I think we've discussed this in gory detail repeatedly.
While I put forth this text as what I believe the consensus to be,
wether or not the text actually does reflects consensus is certain
a matter for discussion.  That is, the chairs have declared consensus
in a number of related issues here, but have not yet declared the
text as being consistent with that consensus.  It is hoped we can
fine tune the text without having to reopen previously hashed issues.

>E.g., I disagree with the TLS requirement.

I think it would be fine to extend this with something like:
"or other suitable means (e.g., IPSec)".

>socket, is fine.

I assume you meant ldaps://.

>Also note section H.45:

Simple+TLS is not mandatory to implement.  But if you implement
Simple, you must implement a means to protect Simple.  This comes
from concerns raised at IETF#58 (and, if I recall correctly, on list).

>BTW, I can't find any requirement that TLS be supported.

It's not.  DIGEST-MD5 is LDAP's strong authentication mechanism
(which provides adequate data security services).  There is no
interop or security reason to mandate or recommend more (except
in limited cases, such as when Simple is to be used).

>I guess I agree with that.

This is because servers need to support various initial operation
sequences discussed in [Protocol].  However, clients need not support
all of these.  For instance, a client is free to initially request
DIGEST-MD5 authentication.  Such a client need not support the
anonymous mechanism.  But because a client might attempt discovery
and hence might anonymously bind first, servers need to be capable
of supporting this (even though the only thing they might allow
an anonymous client to do is discovery).

>BTW, MUST they support unauthenticated binds?

I believe consensus is that the unauthenticated mechanism of the simple
method is elective, but those implementations which do support this
mechanism should, by default, have it disabled (e.g., reject such
requests).

I didn't enumerate elective mechanisms... nor attempt to discuss how
any mechanism should be implemented.

>Section 6 says those

I think it is important to say that other mechanisms are elective.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 22:23:37 +0100

> I assume you meant ldaps://.

For the filename socket?  Yes, ldaps:// sounds familiar.

> It's not.

Sorry, I meant 'no requirement in any circumstance', like required when
you implement Simple Bind.  But you have already addressed that.

> DIGEST-MD5 is LDAP's strong authentication mechanism

While I like that TLS is optional, I don't buy this as an argument for
it.  DIGEST-MD5...

- cannot be used if the server-side password store is maintained
  encrypted by the OS, so there are no cleartext passwords to
  make MD5 digests from.

- is compromised if the store of MD5-digested passwords is compromised.
  (Or if just one such digested password is compromised?  I don't
  remember.)  If that happens, one must rehash the entire password
  store.  That means one must either maintain a cleartext password
  store, which may be unacceptable, or all users must change their
  passwords, which can be from expensive to near impossible for large
  organizations.

Since I don't actually want a change, this is obviously not important to
me, but it might be important to those who feel DIGEST-MD5 as an
argument for optional TLS.

> method is elective, (...)

Then this is wrong:

It should be 'support anonymous binds with...' (according to section 6),
or 'anonymous authentication via the simple Bind method with no name or
password'.

> I think it is important to say that other mechanisms are elective.

If you mean _all_ other mechanisms, the paragraph doesn't say that.  It
just says there are elective mechanisms.  But I agree such a statement
would be nice.  As well as a similar statement for basic TLS features.

> consensus supports the requirement as applying to both clients and

Above, clients that do not use DIGEST-MD5 must support it anyway.
Below, clients that do not use simple/anon need not support it.

> anonymous mechanism.  (...)

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Mar 2004 22:42:02 +0100

> While I like that TLS is optional, I don't buy this as an argument for

... is also vulnerable to active intermediary attacks ([Authmeth]
section 10).

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 15:45:40 -0800

At 01:23 PM 3/9/2004, Hallvard B Furuseth wrote:
>it.

The argument is a) DIGEST-MD5 is good enough to be the
mandatory-to-implement authentication mechanism and
b) there only needs to be one mandatory-to-implement
authentication mechanism.

The reason why Simple+TLS is optional is simply due to
fact that once you've met the IETF requirements for
reasonable strong authentication mechanism and there doesn't
appear to much of a reason to require/recommend everyone to
implement yet another authentication mechanism.

I note that the WG did consider making Simple+TLS the
mandatory-to-implement strong authentication method, but
choose to stick with DIGEST-MD5.

> LDAP server implementations MUST support the anonymous mechanism of

No, that's talking about the anonymous mechanism, not the
unauthenticated mechanism.

Simple bind support three mechanisms: anonymous, unauthenticated,
and authenticated.  While the first two both result in an anonymous
associations, they are different mechanisms.

>or 'anonymous authentication via the simple Bind method with no name or

I think we just need to be more precise when it comes to
distinguishing mechanisms from outcomes.  One could say
that the use of SASL/ANONYMOUS mechanism is an "anonymous
bind".  But it is a different mechanism from the simple
method's anonymous mechanism.

>If you mean _all_ other mechanisms, the paragraph doesn't say that.
>It just says there are elective mechanisms.  But I agree such a statement

I rather not say _all_ other mechanisms, as some mechanisms have
very limited applicability (and some other mechanisms may actually
be deprecated (for very good reasons)).  So, I guess, it may be best
not to actually say other mechanisms are elective.

Maybe we should just s/MAY/may/ (or s/MAY/can/) here.  That is,
just point out that implementations can support other implementations
but avoid discussing there applicability.  It might be appropriate
to note that implementors considering supporting additional mechanisms
should carefully consider their applicability to LDAP and directory
applications they intend to support.

>Below, clients that do not use simple/anon need not support it.

Because the requirements address different concerns.

The former requirement is to ensure that all implementations
share a strong authentication mechanism.

The latter requirement is to ensure that all servers provide
adequate support for discovery.  Clients are not generally
required to use discovery (or use simple/anon with discovery),
but servers are generally required to support discovery (if
so configured).

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Mar 2004 01:31:29 +0100

> associations, they are different mechanisms.

Oh.  The problem is, the 'anonymous mechanism' of Simple Bind isn't
defined anywhere, so it can be read eather as your definition or as
anonymous binds.  I see no reason to define it either, just to be able

>> or 'anonymous authentication via the simple Bind method with no name or

Also, this text from your suggestion must be fixed in the same way:

  LDAP implementations which support any authentication mechanism
  (other than anonymous mechanism of the simple Bind method) MUST
  support the DIGEST-MD5 (...)

> method's anonymous mechanism.

My suggested texts do refer to anonymous simple bind, so they exclude
SASL/ANONYMOUS.

> not to actually say other mechanisms are elective.

This should cover both needs: 'Of the mechanisms defined in this
document, only the above mechanisms are mandatory'.

> Maybe we should just s/MAY/may/ (or s/MAY/can/) here.

Also an improvement over your original text.

> It might be appropriate

I don't understand.  Are you talking about a security consideration, or
something else?  Why and how would they consider it?

> share a strong authentication mechanism.

If this is to satisfy some formal IETF requirement that they must share
such a mechanism, I'm with you.  Otherwise I still don't see the
difference between clients that don't need DIGEST-MD5 and clients that
don't need discovery (below).  Also, that all implementations 'share'
DIGEST-MD5 doesn't mean that one can bind with DIGEST-MD5 to all servers
supporting it, for the reasons I meantioned before about DIGEST-MD5.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 17:03:27 -0800

At 04:31 PM 3/9/2004, Hallvard B Furuseth wrote:
>defined anywhere,

It should be.  We need to be distinguish this mechanism from
other simple mechanisms and well as other mechanisms whose
purpose is to establish an anonymous association.

>so it can be read eather as your definition or as

We need to precise in this area as we have different requirements
for different mechanisms.

>  support the DIGEST-MD5 (...)

I think it better to precisely define the "anonymous mechanism of
the simple Bind method".

>My suggested texts do refer to anonymous simple bind, so they exclude

Yes, but my point "anonymous simple bind" as you just used it
is ambiguous.  It could mean binding with the anonymous
mechanism of the simple method or binding with the unauthenticated
mechanism of the simple method.  I think the term "anonymous
simple bind" should be avoid.  We should, depending on the
circumstances, either talk in terms of what kinds of associations
will/have been established, or in terms the particular
mechanisms to used in establishing the association.

>document, only the above mechanisms are mandatory'.

I don't believe all the mechanisms "above" are mandatory.

>Also an improvement over your original text.

Okay.

>something else?  Why and how would they consider it?

Applicability of a mechanism certain encompasses security
considerations, but can also encompass other factors.
Note that I use the term applicability in the RFC 2026 sense.

>such a mechanism, I'm with you.

There is a requirement for all IETF protocols to have a reasonable
strong authentication mechanism.  (I forget where it is formalized.)

> Otherwise I still don't see the
>don't need discovery (below).

Maybe someone else can take a stab at explaining the difference
better than I.

>Also, that all implementations 'share'

Assuming you are referring to interoperability issues
(as opposed to local policy/configuration issues), please
drop me a note with a quick summary of the reasons and
pointers to past discussions.

(I have some interoperability concerns with DIGEST-MD5,
especially with layers.  I intend to do a quick interop
study in this area in the next few weeks to ensure we
have (or likely will have) multiple independently developed
implementations of DIGEST-MD5 (including layers).)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 17:34:20 -0800

>... is also vulnerable to active intermediary attacks ([Authmeth]

So is TLS (version downgrade attack), see RFC 2246.

DIGEST-MD5 addresses the known active intermediate vulnerability
(the layer downgrade attack) of the authentication exchange by
stating that both peers must ensure that adequate protections have
been established before transferring any application-protocol data.
Likewise, [Authmeth] must say this for its use of SASL as LDAP's
SASL mechanism discovery facility is also subject to downgrade
attacks (unless protected by other means).

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Wed, 10 Mar 2004 08:37:28 +0100

> adequate protective services.

In principle I support the WG consensus that clear-text passwords have to be 
protected. And in most cases I'm in favour of protecting the LDAP connection 
instead of relying on trusted networks etc.

SHOULD seems strong enough to me to require TLS and there are various other 
means by which you can protect clear-text passwords transmitted which are 
outside this specification (e.g. IPsec, Unix domain socket, etc.). That's 
local security policy and the security issues should be made very clear but 
IMHO "MUST [..] TLS" is too strong here.

Ciao, Michael.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 10 Mar 2004 00:48:00 -0800 (PST)

On Wed, 10 Mar 2004, Michael Ströder wrote:

> SHOULD seems strong enough to me to require TLS and there are various
> other means by which you can protect clear-text passwords transmitted
> which are outside this specification (e.g. IPsec, Unix domain socket,
> etc.). That's local security policy and the security issues should be
> made very clear but IMHO "MUST [..] TLS" is too strong here.

IETF standard protocol documents describe (and constrain) the behavior of

> > capable of protecting simple password authentication using TLS,

The choice of using IPsec, etc, as you suggest, is a deployment-time
choice, and our documents generally say nothing about what deployers can
or should do.  But the requirement, for which MUST is I think entirely
appropriate, for *implementations* of LDAPv3 is that they must *be
capable* of using TLS, if they do password authentication.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Mar 2004 08:00:51 -0800

>capable* of using TLS, if they do password authentication. 

In a previous note in response to Hallvard, I had noted that it
likely was fine to add ""or other suitable means (e.g., IPSec)".
However, I now have to retract this.  I agree with you that
we need to place a requirement upon the implementation to
provide adequate protection and the only suitable protective
service to mandate here is TLS.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Mar 2004 22:55:18 +0100

Kurt D. Zeilenga writes:
>>> DIGEST-MD5...

I couldn't find that, but I found 'version rollback attack'.  Then
[Authmeth] should mention that TLS is vulnerable too.  However, an
unqualified statement that it is vulnerable seems wrong.  As far as I
can tell from RFC 2246, TLS is 'reasonably secure' if one uses version
3.0+ and addresses the attack properly.  Should be added to Section
3.1.4 (Discovery of Resultant Security Level), which will then need to
be renamed a bit.

> attacks (unless protected by other means).

Um... that "also" confuses me.  Are you talking about two different
attacks on DIGEST-MD5, or is it one attack and DIGEST-MD5 is secure
(as far as we know) if one addresses this attack?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Mar 2004 15:00:40 -0800

At 01:55 PM 3/10/2004, Hallvard B Furuseth wrote:
>I couldn't find that, but I found 'version rollback attack'.

That's it.

>Then [Authmeth] should mention that TLS is vulnerable too.

Or simply say that implementors should be aware of and understand
TLS security considerations as discussed in RFC 2246.  It does
not make much sense trying to reiterate this material, it can
be incorporated by reference.  However, [Authmeth] should discuss
any LDAP-specific attacks or any LDAP-specific defenses against
these attacks.

>However, an
>unqualified statement that it is vulnerable seems wrong.

My point exactly, as applied to both TLS or DIGEST-MD5.

>As far as I can tell from RFC 2246, TLS is 'reasonably secure'
>if one uses version 3.0+ and addresses the attack properly.

Same can be said for DIGEST-MD5 and it's technical specification.

>Should be added to Section

There is an attack on SASL mechanism discovery (mechanism downgrade)
and an attack on DIGEST-MD5 mechanism (layer downgrade) and, these
attacks can be used together in some interesting ways.  Both
attacks (and combined attacks) are addressed by having each peer
ensure the resultant security level meets their minimum
requirements before continuing.  (It is also wise to avoid
entering into an exchange which cannot possible result in
acceptable security level.)

I believe all known attacks upon DIGEST-MD5 are discussed in
draft-ietf-sasl-rfc2831bis.  If not, please holler on the SASL
WG list.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 11 Mar 2004 17:52:07 -0800

>Put "Servers are expected to support" in front of the sentence?

I don't think servers are necessarily expected to support a means of
access control.  There are, after all, servers which do not support
any form of authentication.  But more importantly, this list is of
security services LDAP provides.  I don't think LDAP provide this
expectation and, even if it did, it's only an expectation.

>with non-DN identities.  I think it belongs in Section 11 - unless

This section is introductory.  It's providing some background as to
why particular security services are offered and why particular
applicability statements have been made.  Section 11 is basically
stating a security consideration.

So, I don't think this introductory/background information should be
moved.  (This is not to say additional security considerations should
or shouldn't be stated.)

>stored outside the LDAP installation.

It can be argued that "used" encompasses both "maintained" and "stored".

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 11 Mar 2004 19:15:18 -0800

>> I hope this is not typical.

Because even clients which access attributes or entries that don't
require client authentication often authenticate anyway.

>I don't see why, except the [LDAPDN] reference.

Because the term "LDAP distinguished name" is ambiguous.  It could
mean an X.500 DN, or the LDAP string representation of a X.500 DN.

>> s/password value/password value, an OCTET STRING.

Because the value, in the protocol, is an OCTET STRING.

>> s/compare/compare octet wise/

This mechanism's shared secret has always been an OCTET STRING,
to be compared octet wise.  We cannot change that without causing
loads of problems.  In terms of the wire and the server, we're
only trying to allow non-userPassword storage (or verification)
mechanisms, such as authPassword.  However, these storage (or
verification) mechanisms must be consistent with the overall
requirements of the mechanism.
  
>- [SASLprep] may apply first.

Application of SASLprep, where necessary, is done by the binding
client and by password management client (or other management agent).

The rest of your message seems to be a rehash external password
system limitations we already discussed in depth.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Mar 2004 06:24:25 +0100

> require client authentication often authenticate anyway.

Fine, but that doesn't explain why you apparently think it's bad if many
clients don't do that.  Not that it matters to Authmeth, I'm just
curious.

> mean an X.500 DN, or the LDAP string representation of a X.500 DN.

I don't really care about just this change, if it's not repeated in
other places, but:

No, [Protocol] specifies that BindRequest.name is an LDAPDN, as it
specifies the format or syntax of other fields used in [Authmeth].
[Authmeth] should not duplicate that work, except with reminders of what
[Protocol] says at places where we feel that is useful.  Here it is not
useful; everywhere core LDAP mentions DNs (except in [LDAPDN] itself) it
means the LDAP string representation.

Actually, if we are going to fiddle with this one, I would rather
shorten it:  'with a name (a DN [LDAPDN]) and specifying...'.

In any case, there are plenty of other places in [Authmeth] and some in
[Protocol] that talk about DNs or LDAP DNs without clarifying that they
mean the LDAP string representation.

> Because the value, in the protocol, is an OCTET STRING.

That's why it's pointless to specify it.
Doing so doesn't even restrict what it may contain, since an OCTET
STRING can contain anything.  And to encode the provided value with the
correct ASN.1 type is a [Protocol] matter, not an [Authmeth] matter.

Are we also going to specify that SaslCredentials.mechanism is an
LDAPString and SaslCredentials.credentials an OCTET STRING when their
values are mentioned too?

> to be compared octet wise.  (...)

I can find no indication of either claim in RFC 2251.

- userPassword is OCTET STRING, but implementations can just as well
  use other attributes.

- I can find no mention of how to compare Bind passwords or Simple Bind
  passwords in general.

> client

Application to the client-side password, yes.  Application to the
server-side password, no.

> and by password management client (or other management agent).

I don't know what that means, but if it means the server-side password
checker, you just contradicted that comparison is done octet wise.

> system limitations we already discussed in depth.

If you refer to the SASLprep thread, yes.  But in that case there was a
workaround:  One can choose passwords that SASLprep does not modify.

In this case you are totally prohibiting anything else than The LDAP Way
To Compare Passwords, which will _differ_ from what most systems do.
And since that way will not even allow us to compare passwords by
hashing the Bind password and comparing with a stored hash, we'll even
be required to store all the users' plaintext passwords somewhere.  That
is utterly unacceptable.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 11 Mar 2004 22:59:29 -0800

>I don't really care about just this change, if it's not repeated in

I haven't looked at all the other places.  The key is it avoid
the term "LDAP DN" as it is ambiguous.  The ambiguity leads to
improper implementation of DN matching (comparing representations
of DN instead of properly comparing the DN values).

>everywhere core LDAP mentions DNs (except in [LDAPDN] itself) it

Whether you are referring to the current LDAP TS [RFC3377] or the
revised LDAP TS [Roadmap], I doubt this statement is correct.  The
very fact you state this kind of makes the case for more clarification
in this area.

>shorten it:  'with a name (a DN [LDAPDN]) and specifying...'.

Since you referring to the name, not the name value, the reference
should be to [Models][X.501] not [LDAPDN].

>mean the LDAP string representation.

In protocol, the term "LDAP DN" should be replaced with either
"DN" or "LDAPDN" or "string representation of the DN".

>That's why it's pointless to specify it.

No.  It is reenforcing that this value, which has been misinterpreted
as being a character string, is in fact an OCTET STRING.

>STRING can contain anything.

Yes, but stating that it is an OCTET STRING reminds implementors that
they should be capable of handling (in terms of the protocol) any
arbitrary value.   For instance, where a server uses an external system
capable of storing only UTF-8 passwords, the server shouldn't puke
because the value wasn't restricted to UTF-8.

>And to encode the provided value with the

But using the value in the server is an [Authmeth] matter.  The
server implementor needs to reminded that protocol is providing
an OCTET STRING.

>values are mentioned too?

I'm not aware of any confusion there.

>I can find no indication of either claim in RFC 2251.

RFC 2251 has lots a holes. 

>server-side password, no.

I think 'binding client' makes it pretty clear as to which side
I was referring to here.

>I don't know what that means,

I likely should have just said "password management entity".

>but if it means the server-side password
>checker,

I don't necessarily (and generally don't) mean the "checker"
(see below).

>you just contradicted that comparison is done octet wise.

Not really.  When textual passwords are used, the shared secret
(on both sides) is the UTF-8 encoded output of SASLprep.  It is
storage mechanism specific when and where this preparation is done,
we can just say that the password management entity takes care of it.
(Note the preparation could occur before or after storage.)

>workaround:  One can choose passwords that SASLprep does not modify.

It is intended one can do that as well here.  See below.

>be required to store all the users' plaintext passwords somewhere.  That

The intent was to say things had to be compared in an octet wise
manner, but not necessarily octet wise.  A simple rewording should
provide plenty of wiggle room.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 13 Mar 2004 16:34:22 +0100

> as being a character string, is in fact an OCTET STRING.

OK.  A slight change, to make it look less like a definition:

s/password value/password value (an OCTET STRING)/.

> RFC 2251 has lots a holes.

If you mean 'hole' as in under-specified compared to X.500, as far as I
can tell LDAP already differs from X.500 in this respect, in that X.500
does not support DIGEST-MD5.  An LDAP/X.500 server can support it over
LDAP, but an LDAP-X.500 gateway can not.  You are also suggesting LDAP
may use a password management entity or the authPassword attribute,
while X.500 explicitly states that Simple bind must compare with the
userPassword attribute (which contains plaintext passwords).
I've only checked X.500(1993) very briefly just now, though:
  X.511: 8.1 (Bind): Only simple/password & strong/certificate auth.
  X.509: 6 (Simple auth): Bind operation sends password, server compares
  with userPassword.

Pasting back from your your previous message (I snipped it because I
partly misunderstood you):

> We cannot change that without causing loads of problems.

I'm asking for a non-change, not a change.  RFC 2251 does not contain
the text you wish to add.  So people must already be having those loads
of problems.  Then why didn't LDAPbis find it necessary to address them
years ago?  Which problems are you referring to anyway?

I'm rearranging the following and snipping some misunderstandings and
clarifications:

> manner, but not necessarily octet wise.

Still sounds like not hashing the bind password to me.  But just to be
sure I know what you are talking about, I expect you mean something
like: comparison where all bits (in each octet) are significant though
there may be unorganized information loss?  (Organized information loss
would allow caseIgnore comparison, or only checking the first 8 octets
of the password like old Unix crypt() does.  Don't know if you wish to
forbid both.  As you can tell, I wish to forbid neither.)

As for 'passwords, each an OCTET STRING', that looks like a clear
statement that the password itself must be represented in an octet
string, and not some hash of it.  If you want this statement just so you
can talk about octet wise comparison, and if my guess about what you
meant with comparison above is OK, you can probably drop ", each an
OCTET STRING" and instead say that when comparing, each bit in the
password received over the protocol is significant.
And then I will vote against that too:-)

I still don't get this:

> When textual passwords are used, the shared secret

OK, but now the shared server-side secret is the plaintext password
again, never a one-way hash of the password.  Having it in a password
management entity doesn't fix that.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 13 Mar 2004 09:22:12 -0800

I'm going to avoid responding with nested comments as things are
getting a bit convoluted.

LDAP simple bind method is related to the X.500 simple bind method.
(DIGEST-MD5 is tangential.)

As LDAP servers are to act in accordance with X.500, understanding
how simple bind works in X.500 is key to understanding how LDAP
servers are to act.  X.500 is quite clear that simple bind shared
secret is an octet string and is to be compared in an octet wise
manner.  One can argue that X.500 is even more restrictive
(requires userPassword), but I think it also can be reasonable
be argued the X.500 allowed a limited amount wiggle room here.

I think simply saying that the LDAP simple bind shared secret
is an OCTET STRING to be compared in an octet wise manner gives
plenty of wiggle room, but then it seems I am taking a more
liberal view of what 'shared' and what 'manner' means here.

I don't think 'shared' means that server necessarily has
knowledge of the secret, but that it is able to verify
that the client has knowledge of the secret, an OCTET STRING.
And 'manner' doesn't necessarily imply that this verification
needs to be perfect, but that the server can use a reasonable
verification method.  That is, I think this allows use
of hashes because comparison of hashes is reasonable
verification that the client shares the secret.

Another way to look at this: the specification is providing
a conceptional view of the process, implementation details
may vary.  This is good way to look at the SASLprep issue.

The key SASLprep point is, when textual passwords are used,
that shared secret is the output of SASLprep.  That is what
the client puts on the wire and that's what is to be
verified.

A server is certainly free to, instead of storing this
shared secret, to store something else which can reasonable
be used for verification purposes.  And just as the server
can hash the asserted value as part of the verification
process, a server can apply other reasonable mappings to
the asserted value.

If a server stores the SHA1 hash of a UTF32 password, it
should ensure that stores SASLprep'ed password (or it
restricts passwords to those which x=SASLprep(x)).
Then it compare function can be written:
  if assertedPassword is (looks like) UTF-8;
  then return storedPassword equals
        SHA1(toUTF32(SASLprep(assertedPassword)))
  else return FALSE

This comparison can be said to act in an octet wise manner
as it reasonable verification that the client has knowledge
of the shared secret, an OCTET STRING.

Kurt