Re: authmeth: TLS issues

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:28 AM 9/27/2004, Hallvard B Furuseth wrote:
>[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.)

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.

>That also applies to:
>
>> 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.


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

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
>(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:

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


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

First, s/performing/sending/.

>In any case,
>
>- I think the above paragraph does not belong under StartTLS; it is
>  about all requests.

I concur.

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

I concur.


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

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.


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

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.

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

The tables need to be updated.

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

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

>- If renegotiation strengthens the security, is the previous weaker
>  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.

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

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.

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