authmeth: TLS issues

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

[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