Re: Revisited: effect of Start TLS on authentication state

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

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