Subject: authmeth: TLS issues

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 17:28:09 +0200

[Authmeth] says:

> 2. Implementation Requirements

[About simple (DN and password) bind:]

>    Implementations that support this mechanism MUST be capable of
>    protecting it by establishment of TLS (as discussed in section 3) or
>    other suitable suitable data confidentiality and data integrity
>    protection (e.g. IPSec). 

RL 'Bob' Morgan noted that "or other suitable ..." is wrong:  Message
'Re: Simple auth and TLS (Was: authmeth review notes [long])', 10 Mar
2004, <http://www.openldap.org/lists/ietf-ldapbis/200403/msg00062.html>.

Kurt agreed, nobody protested that I can see.  (Me, I couldn't quite
figure it all out.)

That also applies to:

> 8. Simple Authentication Mechanism of Simple Bind 

>    LDAP implementations MUST be
>    capable of protecting it by establish::qment of TLS (as discussed in
>    section 3) or other suitable data confidentiality and data integrity
>    protection(e.g. IPSec).

I hope it's not necessary for this - after all it's a SHOULD NOT, not
MUST NOT:

>    LDAP implementations SHOULD NOT
>    support authentication with the "simple" authentication choice
>    unless the data on the connection is protected using TLS or other
>    data confidentiality and data integrity protection.

BTW, the same should be stated about plain text password mechanisms in
general, such as SASL/PLAIN.  I suggest to put it in section 12.1.1
(Password-related Security Considerations), whose text is related but
weaker.  (I previously suggested to just expand the above statement
without moving it, but that would have left it in the wrong section.)

Bob's objection probably also applies to this, though that depends a bit
on the purpose of this section:

> 12.1.1.Password-related Security Considerations

>    a server implementation that supports any password-based
>    authentication mechanism that transmits passwords in the clear MUST
>    support a policy mechanism that at the time of authentication or
>    password modification, requires:
> 
>         A StartTLS encryption layer has been successfully negotiated.
> 
>       OR
> 
>         Some other confidentiality mechanism that protects the password
>         value from snooping has been provided.
> 
>       OR
>         (...)

On the other hand, I think TLS can be replaced with "(better) integrity
or confidentiality protection" here, since this is about what the
particular server and not the standard requires anyway:

> 3.1.1. StartTLS Request 

>    If the client did not establish a TLS connection before sending a
>    request and the server requires the client to establish a TLS
>    connection before performing that request, the server MUST reject
>    that request by sending a resultCode of confidentialityRequired.

In any case,

- I think the above paragraph does not belong under StartTLS; it is
  about all requests.

- It might be rewritten to a less "commanding" style; since this
  response does _not_ mean "you must do StartTLS now!":

  If the server receives a request for which it requires better [TLS
  protection or whatever] than the current connection has, the server
  MUST reject...

Also, how about this:

> 3.3. TLS Ciphersuites
>        Ciphersuites vulnerable to man-in-the-middle
>        attacks SHOULD NOT be used to protect passwords or sensitive
>        data, unless the network configuration is such that the danger
>        of a man-in-the-middle attack is tolerable.
> 3.3.1. TLS Ciphersuites Recommendations
>    The following ciphersuites defined in [TLS] MUST NOT be used for
>    confidentiality protection of passwords or data:

What if the user or sysadmin knows that the connection is protected by
other means, e.g. a connection to the loopback device (localhost), but
the implementation does not know that?

========

Does graceful TLS closure revert the association to anonymous?
There was a discussion about that, but I don't remember the conclusion.

Authmeth is inconsistent:

The normative part of the draft says it does not revert to anonymous:

- 3.2.3 (TLS Connection Closure Effects).

- 4.3 (Invalidated Associations):
  "The association remains invalidated until the next bind request."
  (Would otherwise need "...or graceful TLS closure".)

The transition table in the appendix says it does revert to anonymous:

- A.4. LDAP Association State Transition Table
  "A9         S1   [Protocol] section 4.14.3.1".

  However, [Protocol] 4.14.3.1 does not say that.

========

Kurt has mentioned that the draft needs to address TLS ciphersuite
renegotiation.  I don't know TLS well enough to know where, and I'm not
going to search the archives for that, but I can think of:

- Section 3.2 (Effects of TLS on a Client's Authorization Identity).

- Might the server decide that a certificate exchanged during TLS
  establishment cannot be used for SASL/EXTERNAL?

- If renegotiation strengthens the security, is the previous weaker
  security relevant to a "security strength" access control factor?

========

> 3.2.1. TLS Connection Establishment Effects
> 3.2.2. Client Assertion of Authorization Identity
> 3.2.3. TLS Connection Closure Effects

One case is only implicitly listed here, which I think should
be mentioned explicitly:  StartTLS succeeds, but the client or server
decides the security level is not good enough and performs graceful
closure.  In particular if connection closure reverts the connection to
anonymous, readers should be reminded that StartTLS can have that
effect.

Maybe a new section 3.2.1 'StartTLS Effects' would be best, which would
just note that this can result in both operation failure (no change),
connection establishment and connection closure.

========

> 12.2. StartTLS Security Considerations

I've suggested a new consideration is added:

  Since an attacker can sometimes inject a Bind operation before the
  client can perform StartTLS, thus leaving the TLS-protected connection
  with unexpected authentication, it can be prudent to Bind immediately
  after StartTLS.  Servers can enforce this by invalidating the
  association after a successful StartTLS which has been preceded by a
  Bind operation.

I don't quite like the wording, but that's still the best I can come up
with.

(I've added "which has been preceded by a Bind operation" since when I
posted it; I think that's sufficient.  That does let an attacker remove
a Bind, but the client would under normal use get an invalidated
association, and so would not be used that way.)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 12:03:50 -0700

>Kurt agreed, nobody protested that I can see.  (Me, I couldn't quite

Basically, it's not good enough to say "MUST be protected with
a suitable data security service".  Besides "suitable" being too
subjective, the interoperability needs are not met by allowing
implementors to choose any suitable data security service.

We should state that implementations
        1) MUST be capable of protecting this mechanism using
        TLS as established by the Start TLS operation,
        2) SHOULD disallow use of this mechanism by default
        when suitable data security services are not in place,
        3) MAY provide other suitable data security services
        for use with this mechanism.

>> 8. Simple Authentication Mechanism of Simple Bind 

Yes.  If the requirements of section 2 are restated elsewhere,
those restatements should be consistent with section 2.

>general, such as SASL/PLAIN.

Depends on whether we discuss use of SASL/PLAIN.  I'm of the
opinion that we only discuss SASL/PLAIN if we decide to
recommend its use over DIGEST-MD5 for non-DN based identity
forms (and make simple bind + TLS as the mandatory-to-implement
strong authentication mechanism).

>I suggest to put it in section 12.1.1

I think the MUST is too strong as "policy mechanism" implies
that the implementation is not free to hard-code the policy,
but must have some mechanism which allows the administrator
to control that policy (aside from modifying the code).

I think it better to simply state that servers
        SHOULD disallow use of clear text password authentication
        and management mechanisms by default when suitable data
        security services are not in place

and avoid discussion of "policy mechanisms".

>>    that request by sending a resultCode of confidentialityRequired.

First, s/performing/sending/.

>- I think the above paragraph does not belong under StartTLS; it is

I concur.

>  response does _not_ mean "you must do StartTLS now!":

I concur.

>  protection or whatever] than the current connection has, the server

MUST here is unneeded.  It would be better to simply state
that the server is to return confidentiality if it requires
the establishment of (stronger) data confidentiality services
in order to perform the requested operation.

>the implementation does not know that?

Personally, I think Section 3.3 should be axed.  The
applicability of other (than the mandatory-to-implement)
cipher suites is a local manner (or a matter of applicability
statements for particular applications of LDAP).

>Does graceful TLS closure revert the association to anonymous?

IMO, If the association was established under TLS, than that
association should be invalided upon closure of TLS.  This
is because the protections of TLS are no longer in effect,
meaning the association is now subject to hijack attack.

However, authmeth-12 states:
>   The decision to keep or invalidate the established LDAP association
>   after TLS closure is a matter of local server policy.

so currently the answer to your question is "its a local matter".

>There was a discussion about that, but I don't remember the conclusion.

I think authmeth-12 reflects the conclusion.  It's a local matter.

>The transition table in the appendix says it does revert to anonymous:

The tables need to be updated.

>  establishment cannot be used for SASL/EXTERNAL?

Yes.  For instance, if the ciphersuite was changed strong
to NULL, the server is free to invalidate the association.

>  security relevant to a "security strength" access control factor?

The implementation needs to be very careful here.  Consider
for instance a client which authenticated using simple+weak
cipher and then upgraded to a strong cipher, should the
server now treat the client as if authenticated with
simple+strong.  I would argue no as that would be
improperly binding (*) the credentials to the wrong data
security channel.  (* my use of 'binding' here refers to
channel binding, not LDAP bind operation.)

Which reminds me, we likely should chat about "channel
binding" issues as well.

>I don't quite like the wording, but that's still the best I can come up

If we're not going to require invalidation (which I think
would be wise), then we certainly need to discuss this risk
and how it can be mitigated.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 19:47:00 +0200

Kurt D. Zeilenga writes:
>  Depends on whether we discuss use of SASL/PLAIN.

No, not a statement about plain text password mechanisms in general.
There are others than Simple Bind and SASL/PLAIN.  Such a statement
could refrain from giving an example of a plaintext password mechanism,
if that is clearer.

As for discussiong SASL/PLAIN, I think we could do that briefly and even
suggest a use for it (my SASL/PLAIN message) without discussing password
issues for it in detail.  Such a paragraph could simply say that
password issues and requirements elsewhere in the draft apply.

>  I'm of the

Yes, if we do that, the wording must be more thorough.
Though in that case the password issues for SASL/PLAIN and Simple Bind
would be similar enough that I'd suggest to mostly factor them out to a
common text anyway, and add references where necessary.

>> [Snipped comment about a later paragraph]
>

Good point.

>  and avoid discussion of "policy mechanisms".

Your text solves the "policy mechanisms" if you s/SHOULD/MUST/ too, and
also fixes that the original text does not say the secure mode should be
the default.

I guess MUST vs SHOULD comes back to the purpose of that section.
Is the MUST to satisfy an IETF requirement of the draft, or just
something the WG wants (or perhaps doesn't want after all:-)?
Since it addresses auth mechanisms that are not part of the LDAP
standard, maybe it's also reasonable to keep a MUST that may be
satisfied by a confidentiality mechanisms outside the standard.
Personally, I could go either way.

>  in order to perform the requested operation.

Fine.  Or since I said to make it less commandig, maybe 'will only
perform the requested operation when (stronger) data confidentiality
services are established'.

>  Personally, I think Section 3.3 should be axed.

I have no opinion on that.

>  meaning the association is now subject to hijack attack.

Well, the same is true of a bind mechanism which protects the password
but does not install a security layer - which to me seems reasonable to
use in some circumstances.  From that perspective, this sounds like your
point ought to be a client-side issue.  But if there are client/library
implementations that just continue merrily after the closure,
invalidation on the server side will help for that.

I imagine that after graceful closure, a client or library should return
an error for attempts to send or receive LDAPmessages except StartTLS,
until the caller or user acknowledges that it is aware of the closure.
Or just to not support further operations after closure, of course.
Should we put something like that in Security Considerations or a
section with implementation guidelines?

>  so currently the answer to your question is "its a local matter".

Sorry, I meant in the case when the server does not invalidate.
The StartTLS description says there is no change, while the table says
it reverts to anonymous.

>  I think authmeth-12 reflects the conclusion.

I found references to the discussions now: RFC 2830 section 5.2 said
revert to anonymous, ldapbis discussions changed that.
'Revisited: effect of Start TLS on authentication state', dec 2003.

>                                                It's a local matter.

No:-)

>  The tables need to be updated.

Yes.

>  to NULL, the server is free to invalidate the association.

Again, I meant if the server does not invalidate.  Renegotiate, maybe
exchange some LDAPMessages, then try SASL/EXTERNAL.  Anyway, from the
rest of your answer, the server should not accept such a Bind.

>>   security relevant to a "security strength" access control factor?

Come to think of it, I don't even know if TLS allows renegotiation to a
stronger cipher.

>  The implementation needs to be very careful here.  (...)

>> association, and so would not be used that way.)

And by adding that, my suggested section no longer addresses the problem
it claims to address:-(  Oops.

A client which does StartTLS and runs anonymously without Bind can be
developed against a server which behaves as described above, and that
server will protect it against attackers who Bind first.  However, the
client will be vulnerable if it moves to a server which does not
invalidate after Bind+StartTLS.

That could be solved by making the suggested server behaviour a MUST,
but I suspect that's a rather strong change as this point.

Except - is there any reason to do a SASL bind which establishes a
security laywer and then StartTLS, maybe with a weak ciphersuite since
there is alreadya security layer?  In that case Bind+StartTLS should not
always invalidate.

[Note: I believe this has been discussed before, but I could only find
references to the discussion in the archive, not the discussion itself.]

-- 
Hallvard