Re: authmeth: TLS issues

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

Kurt D. Zeilenga writes:
>At 08:28 AM 9/27/2004, Hallvard B Furuseth wrote:
>>[Authmeth] says:
>>
>>>  8. Simple Authentication Mechanism of Simple Bind
>>>
>>>     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.

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

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.

>> 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
>>>          (...)
>> [Snipped comment about a later paragraph]
>
>  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).

Good point.

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

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.

>>>  3.1.1. StartTLS Request
>> (...)
>> - 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.

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.

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

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?

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

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.

>> There was a discussion about that, but I don't remember the conclusion.
>
>  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:-)

>> Authmeth is inconsistent:
>>
>> The transition table in the appendix says it does revert to anonymous:
>
>  The tables need to be updated.

Yes.

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

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.

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

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

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