Re: Revisited: effect of Start TLS on authentication state

["Roger Harrison" <RHARRISON@novell.com>]

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 <h.b.furuseth@usit.uio.no> 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