Subject: [authmeth] effect of StartTLS on authentication state

From: "Roger Harrison" <[email-masked]>
Date: Tue, 01 Jul 2003 17:18:05 -0600

A WG member has asked whether the server should drop all knowledge of
the connection, i.e. return to anonymous state, if it gets a StartTLS
request on a connection that has successfully bound using the simple
method. I believe that the intent of section 5 the authmeth draft is
clear on this point: if the association is in state S4 (authenticated
but no TLS) and the client performs action A3 (sends a Start TLS
request), then the next association state is S5 (authenticated with
TLS).
 
My understanding of existing implementations leads me to believe that
this is the generally accepted understanding of the way this should
work.  I can't see any serious security issues with maintaining this
behavior. Therefore, I propose that we do not change this requirement. 
I will consider adding wording to clarify this point if WG members
request it.
 
Please respond with your opinions.
 
Thanks,
 
Roger

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 01 Jul 2003 19:00:12 -0700

The obvious security consideration is that a client which does:
        StartTLS+simple
and a client which does
        simple+StartTLS

would (assuming both provided the same credentials and the negotiated
the same security layers, association state diagram were followed)
achieve the same apparent authorization state and protection levels when,
in fact, the latter approach is prone to a number of obvious attacks.

For the life of me, I cannot imagine why a client would do
    simple+StartTLS+modify
or even
    simple+StartTLS+search-for-user-application-objects

If the exchanged information is sensitive enough to warrant starting TLS,
then it follows that password which provides access to that information is
equally sensitive and should be protected by TLS.

It's my opinion that the RFC 2830, section 5.1.1 absolute
imperative is inappropriate and actually in conflict with section 3.1.
Authorization state diagram aside (its not normative), if a client does
simple+StartTLS+X, the server is free, per section 3.1, to return
strongAuthRequired for X.  And if 3.1 isn't enough, please consider
access and administrative control models behavior is a local matter and
servers are free to return security codes as necessary to implement
the model they support.  Also, nothing in the LDAP TS should be viewed
as precluding from lowering the effective access rights or otherwise
placing restrictions upon clients for this or any other reason.

It is not only reasonable that servers treat StartTLS+simple differently
than simple+StartTLS, it makes good sense from a security perspective.  I
believe that the OpenLDAP behavior (which is policy driven) of forcing the
session to anonymous upon StartTLS has significantly improved the security
of the Internet.  There are a lot less clients doing simple+StartTLS now
and that is, IMO, a good thing.

Kurt

At 04:18 PM 7/1/2003, Roger Harrison wrote:
>A WG member has asked whether the server should drop all knowledge of the connection, i.e. return to anonymous state, if it gets a StartTLS request on a connection that has successfully bound using the simple method. I believe that the intent of section 5 the authmeth draft is clear on this point: if the association is in state S4 (authenticated but no TLS) and the client performs action A3 (sends a Start TLS request), then the next association state is S5 (authenticated with TLS).
> 
>My understanding of existing implementations leads me to believe that this is the generally accepted understanding of the way this should work.  I can't see any serious security issues with maintaining this behavior. Therefore, I propose that we do not change this requirement.  I will consider adding wording to clarify this point if WG members request it.
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 01 Jul 2003 19:33:47 -0700

>imperative is inappropriate and actually in conflict with section 3.1.

I misread section 3.1.  It doesn't cover this case (as StartTLS
as been initiated) so is not in conflict with 5.1.1.  Regardless,
I still believe the server is free to return strongAuthRequired
at any time it considers the in force association to be inappropriate
for the requested operation.   Hence, the server may, in effect,
move the association to anonymous after StartTLS.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 3 Jul 2003 15:47:53 +0200

Kurt D. Zeilenga writes:

> I still believe the server is free to return strongAuthRequired at any
> time it considers the in force association to be inappropriate for the
> requested operation.

I don't think so.  5.2.1 says:
    
   Upon establishment of the TLS session onto the LDAP association, any 
   previously established authentication and authorization identities 
   MUST remain in force

> Hence, the server may, in effect, move the association to anonymous
> after StartTLS.

I think it _should_ be allowed to, yes.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 3 Jul 2003 15:29:03 +0200

>     simple+StartTLS+search-for-user-application-objects

However, an attacker could insert a bind before the StartTLS in a client
which expects to run with anonymous auth and which grants access to
something depending on what is returned from the search.  I can vaguely
imagine that this could be a problem in rare cases.

And of course, the attacker could insert another bind after the client's
bind if the client does simple+StartTLS+modify.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Jul 2003 07:53:34 -0700

>   previously established authentication and authorization identities 

This only says the server must keep identities in force.  It
does not mean that the server cannot consider the client not
to have obtained a strong enough security association to
request the subsequent operation.  The server is always free
to return stongAuthRequired when the in force association is
not strong enough.

>I think it _should_ be allowed to, yes.

While obviously I agree,  I argue that they can, in all effect, as
nothing in the LDAP TS says what authorization an in force identity
has.  It may have none, it may have same authorization as an anonymous
user, it may have some other level of authorization.  The authorization
of a client may depend on any number of factors, including the ordering
of operations presented to it.

Kurt