Subject: Re: Revisited: effect of Start TLS on authentication state

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 6 Dec 2003 09:38:15 +0100

Roger Harrison writes:
> After TLS Establishment (proposed replacement for current authmeth
> section 4.2.1):
>  
> The decision to keep or invalidate the established authentication and
> authorization identities in place after TLS is negotiated is a matter of
> local server policy.

I think that's too weak.  Since keeping the current identities is a
security problem, servers SHOULD by default not do that.  Also, Security
Considerations should mention why it is a problem, and this section
should refer to Security Considerations.  Or maybe the problem should be
described in this section, since the draft is all about security anyway.

> If a server chooses to invalidate established
> authentication and authorization identities after TLS is negotiated, it
> MUST reply to subsequent

valid

> operation requests

until the next TLS closure or successful bind request

> with a resultCode of
> strongAuthRequired to indicate that the client needs to bind to
> reestablish its authentication.

"valid" because it may respond with e.g. protocolError to bad requests,
or operationsError to another StartTLS, and probably other errors.
Or... does that word leave too big a hole, so it's better to let
implementors figure out the exceptions themselves?  (BTW, abandon is
another exception: It should not get a response.)

Also, with the "until..." addition above, the following becomes
unnecessary:

> If the client attempts to bind using a
> method the server is unwilling to support, it responds to the with a
> resultCode of authMethodNotSupported (per [Protocol]) to indicate that a
> different authentication method should be used.

> (proposed replacement for current authmeth section 4.2.3):
>  
> The decision to keep or invalidate the established authentication and
> authorization identities in place after TLS closure is a matter of local
> server policy.

Why?  I don't remember any threads about problems with reverting to
anonymous on TLS closure.  Maybe there are current servers that don't do
that, so the requirement that closure revert to anonymous would be an
incompatible change?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 06 Dec 2003 12:19:13 -0800

At 12:38 AM 12/6/2003, Hallvard B Furuseth wrote:
>Why?

The rationale is that servers are allowed, for any reason,
to invalidate the LDAP association.  It makes no sense to
say that they cannot do that as a result of TLS closure
when they could do otherwise.

>I don't remember any threads about problems with reverting to
>anonymous on TLS closure. 

(While I recall some previous discussions in this area,) the
proposal certainly was discussed at IETF#58.  Now it's being
taken to the list.  Hopefully we'll be able to close on it soon.

>Maybe there are current servers that don't do that, so the requirement that closure revert to anonymous would be an incompatible change? 

No, because clients today have to deal with instances where
the server, at the server's will, invalidate the LDAP association.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Dec 2003 22:17:35 +0100

Kurt D. Zeilenga writes:
>>> The decision to keep or invalidate the established authentication
>>> and authorization identities in place after TLS closure is a matter
>>> of local server policy.
>>
>>Why?
> 

I don't understand.  Why can't they do it after TLS closure if it isn't
spelled out in the section of TLS closure section?  Why is not spelling
it out there different from not spelling it out in the Delete operation
section (since Delete can delete the DN which the user was bound as)?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 07 Dec 2003 16:32:56 -0800

At 01:17 PM 12/7/2003, Hallvard B Furuseth wrote:
>I don't understand.

Sorry.  I only stated why servers should be free to invalid
the association in this case, but not why they should also
be free to maintain the association.  Let me do that now.

If client and server, before or after starting TLS, established
strong authentication (possibly with layers), they should not be
forced to renegotiate strong authentication.  It also would make
little sense to leave the SASL layers in place (as required by
RFC 2222) yet move the LDAP association (which those layers are
bound to) into anonymous state.  Also, it makes no sense that TLS
closure would cause such but changes to the TLS cipher suite,
say to the null cipher suite, would not.

Lastly, it is reasonable for a client which has established
strong authentication and security layers though SASL to
close TLS to reduce resource consumption.

(One case where it might be good to suggest/recommend servers
drop the LDAP association is when SASL/EXTERNAL was used and
the lower-level identity came from TLS.)

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2003 11:31:42 +0100

Kurt D. Zeilenga writes:
> forced to renegotiate strong authentication.

OK if layers or IPsec is in place.

I'm not quite sure what strong auth is, but if there are no layers or
IPsec, I assume that the strong auth may have been done by a MITM
attacker, not by the client.  If so, I still think the association
SHOULD by default be invalidated after Start TLS unless some protection
(IPsec or SASL layer) is already in place.

> It also would make

True, but it does makes sense to stay compatible with rfc2830 section
5.2, which moves the association to anonymous at TLS closure.  Otherwise
the association is in any case in an unknown state for the client,
unless it knows whether or not it is using an ldapbis version of LDAPv3.
So it seems to me that TLS closure should either move to anonymous, or
invalidate the association.  That's compatible with rfc2830.

> close TLS to reduce resource consumption.

OK, and I can see how TLS can protect the SASL bind from a Denial of
Service attack and then be dropped, but you mentioned null TLS cipher
suites - can't that be used instead to get rid of TLS overhead but still
keep the association?

Another thing is that the text about invalidated associations still
seems misplaced to me.  Other situations than TLS start/closure can have
use for that, e.g. if the DN which the user bound as gets deleted.
So I suggest this text is moved to a separate section.  The TLS sections
can then simply say that start/close TLS MAY invalidated the association.
That's no real change in functionality, since [Protocol] already says
it is possible.

Like this:

Section whatever: Invalidated associations

   The server MAY at any time invalidate the association, e.g. if the
   established security association between the client and server has
   unexpectedly failed or been compromised.  The association remains
   invalidated until the next successful bind request.

   When the association is invalidated, the server it MUST reject
   subsequent operation requests other than Bind, Unbind and Start TLS,
   and respond with a resultCode of strongAuthRequired to indicate that
   the client needs to bind to reestablish its authentication.  If the
   client attempts to bind using a method the server is unwilling to
   support, it responds to the with a resultCode of
   authMethodNotSupported (per [Protocol]) to indicate that a different
   authentication method should be used.

Notes:

- I copied the MUST from Roger's text, but I don't like it.  Since
  [Protocol] A.2 says:

        strongAuthRequired (8) 
           Indicates that the server has detected that an established 
           security association between the client and server has 
           unexpectedly failed or been compromised, or that the server 
           now requires the client to authenticate using a strong(er) 
           mechanism. 

  I take it that the server may also choose to return strongAuthRequired
  in other circumstances, e.g. it might require strong auth for update
  requests but not read requests.  So the server may implement something
  which behaves slightly differently from whatever we put in the MUST.

  A fix would be to restrict the [Protocol] text a bit:

        strongAuthRequired (8) 
           Indicates that the association is invalidated as specified in
           [Authmeth], or that the server now requires the client to
           authenticate using a strong(er) mechanism.

  Another is to remove the MUST and instead add something like

     The server MAY also return strongAuthRequired in other
     circumstances, e.g. it might require stronger authentication for
     update requests than for read requests.

  That makes it harder for the client to figure out just what is going
  on when it receives strongAuthRequired, though.

- Maybe "reject subsequent operation requests" should be "reject
  subsequent _valid_ operation requests", see my earlier message.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Dec 2003 11:54:14 -0800

I don't see the compatibility issue as being a big deal in this case.
I don't see any reason to keep a MUST which few if anyone has ever
implemented (those who know of implementations should speak up),
especially with that MUST makes little sense.

>OK if layers or IPsec is in place.

Obviously without appropriate integrity layers, the connection
is subject to MITM attacks.  (I believe SASL/DIGEST-MD5 layers
support will be mandatory-to-implement in 2831bis.)

Part of the problem with this MUST was that it assumed that
protective layers where being provided by TLS.  This may not
actually be the case.  The null cipher suite may be in use,
and the TLS closure is being used simply to free resources
associated with the TLS stream.

>suites - can't that be used instead to get rid of TLS overhead but still

First, I'm not thinking of "resource consumption" in terms of a DoS
attack (though resource constraint can be attacked in this manner),
but just in terms of what may be expensive-enough resources that an
implementation might want to free them.  Specifically, I was think
of platforms which provide hardware support for TLS.  These systems
often have limitations on the total number of concurrent TLS streams
they can maintain.  It would be reasonable for an implementation
using such to issue TLS closures when the TLS protections were no
longer valuable to it.

>seems misplaced to me.

It seems so to me as well.

>Other situations than TLS start/closure can have

s/MAY/may/.  (I'm fine with adding just this text to the section
introducing associations)

>   the client needs to bind to reestablish its authentication.

I'm a little concerned that of the overload here.  strongAuthRequired
means, generally, that stronger authentication is required.  Now,
that could be due to the invalidation of the association, but it could
be due to any number of other reasons.  Additionally, the server could
be willing, after invalidating the association, to continue to allow
the client to attempt operations which don't require that association.

The MUST here is actually extraneous.  Consider a server which instead
of invalidating the association just has another factor which says
that the association is only strong enough for X and Y but not Z.
This would be perfectly compliant with the specification.  Hence,
any developer which doesn't want to implement this MUST can simply
claim that they using other factors to determine when to return
strongAuthRequired.  So, in effect, the MUST is only relevant if
certain implementation details are assumed.  As we cannot assume
those details, the MUST is moot and hence should not stated.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Dec 2003 10:47:44 +0100

Kurt D. Zeilenga writes:
> implemented

No, if it's largely unimplemented I have no objection to the change.
I do agree the new TLS Closure behavior is better.

That leaves one concern of mine: SHOULD invalidate association after
StartTLS unless other security layers are in place, or unless the TLS
cipersuite is weak (null?).  Should we add that, or not, or just suggest
it in Security Considerations?  I'm not quite sure if you were talking
about that or about TLS closure in some parts of your reply:-)

About invalidated associations:

> the client to attempt operations which don't require that association.

All true, but maybe this is the best LDAPv3 can do.  What we need is a
new error code, or at least to rename strongAuthRequired, but I take it
that's out of scope for ldapbis.  A new code certainly is.

> The MUST here is actually extraneous.

As I said in the previous message, I agree.  The MUST is OK if we change
[Protocol] to match.  Otherwise I suggest to delete it (not just
lowercase it) and add a sentence about servers being allowed to return
strongAuthRequired in other circumstances too.  See my previous message.

-- 
Hallvard