Re: Revisited: effect of Start TLS on authentication state

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

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 12/6/2003 1:38:15 AM
>>>

> 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.
 
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
> > 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
 
I'll make this change.

> 
> > 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:
 
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
> > 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
>