Re: Revisited: effect of Start TLS on authentication state

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

Kurt D. Zeilenga writes:
> If client and server, before or after starting TLS, established
> strong authentication (possibly with layers), they should not be
> 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
> 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.

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.

> Lastly, it is reasonable for a client which has established
> strong authentication and security layers though SASL to
> 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