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

From: "Roger Harrison" <[email-masked]>
Date: Fri, 05 Dec 2003 17:57:31 -0700

OK. I've had some more time to think about this, and here's another
proposal that may meet the need.
 
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. If a server chooses to invalidate established
authentication and authorization identities after TLS is negotiated, it
MUST reply to subsequent operation requests 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.
 
(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. If a server chooses to invalidate established
authentication and authorization identities after TLS closure, it MUST
reply to subsequent operation requests 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.
 
I'm going to make this change to the -09 version unless there's a
flurry of negative sentiment for this proposal before I can get it
published.
 
Roger

>>> Hallvard B Furuseth <[email-masked]> 11/14/2003 9:19:33
AM >>>
Roger Harrison writes:
> Option 1. Keep the requirement that servers MUST not change the
> authentication and authorization state of the LDAP association when
a
> security service such as Start TLS is added to the session.

OK...

> Add wording that says that servers SHOULD (MUST?) not allow the LDAP
> association to achieve authentication/authorization states that it
> will not honor across a Start TLS operation by returning a
resultCode
> of confidentialityRequired for bind operations that would achieve
> these states if processed.

Some binds _before_ Start TLS should fail, just because a later Start
TLS won't like them? That makes no sense if the client isn't planning
to send Start TLS.

I prefer that servers SHOULD respond with strongAuthRequired to
requests
_following_ Start TLS, until the next bind or TLS closure. Unless
other
protection is already in place, like a SASL security layer.

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Sat, 06 Dec 2003 12:41:56 -0700

Hallvard B Furuseth <[email-masked]> 12/6/2003 1:38:15 AM

> > 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.
 
Could you give me some words that explain the security considerations
for this as you see them, and I'll edit them in? The same goes for
anyone else in the WG who has thoughts on this subject.

> 
> > If a server chooses to invalidate established
> > MUST reply to subsequent
> valid
> > operation requests
> until the next TLS closure or successful bind request
 
I'll make this change.

> > with a resultCode of
> > 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:
 
This was actually unnecessary in my original wording (hence the "per
[Protocol]" comment, but I felt that it was good to be explicit about
what the situation. Until I thought about this a bit, it wasn't clear to
me that this was the proper way for the server to communicate its intent
to the client, and I thought it wouldn't hurt to spell it out.

> 
> > If the client attempts to bind using a
> > 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?

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Dec 2003 21:28:05 +0100

Roger Harrison writes:
>>> 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.
>> 
>> 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.
>  

I know of two security problems with using a bind identity from before
Start TLS:

- An attacker can insert a Bind Request prior to the Start TLS request
  so that the LDAP association will be bound with another ID than the
  client intends.

- Using a bind ID from prior to the Start TLS encourages clients to
  bind before instead of after Start TLS, which gives weaker security
  for the credentials - in particular if plain passwords are enabled
  (even though they should not be, before Start TLS).
  
> what the situation. Until I thought about this a bit, it wasn't clear
> to me that this was the proper way for the server to communicate its
> intent to the client, and I thought it wouldn't hurt to spell it out.

Maybe.  I think Authmeth already containts too much redundancy.  See
message http://www.OpenLDAP.org/lists/ietf-ldapbis/200310/msg00035.html
(authmeth-07 issues).

-- 
Hallvard