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

From: "Roger Harrison" <[email-masked]>
Date: Mon, 16 Feb 2004 00:08:57 -0700

I believe I have represented the discussion consensus on this issue for
the -10 draft of authmeth.
 
For TLS Connection Establishment Effects:
 
"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."
 
For TLS Connection Closure Effects
 
"The decision to keep or invalidate the established authentication and
authorization identities in place after TLS closure is a matter of local
server policy."
 
And I've added this new section:
 
"Invalidated Associations
 
"The server may, at any time, invalidate the association, e.g. if the
established security association between the client and server has
unexpectedly failed or been compromised.  The association remains
invalidated until the next successful bind request.  While the
association is invalidated, the server may reject any operation request
other than Bind, Unbind, and Start TLS by responding with a resultCode
of strongAuthRequired to indicate that the client needs to bind to
reestablish its authentication state before performing the requested
operation."
 
Roger

>>> Hallvard B Furuseth <[email-masked]> 12/10/2003 2:47:44
AM >>>
Kurt D. Zeilenga writes:
> I don't see any reason to keep a MUST which few if anyone has ever
> implemented

No, if it's largely unimplemented I have no objection to the change.
I do agree the new TLS Closure behavior is better.

That leaves one concern of mine: SHOULD invalidate association after
StartTLS unless other security layers are in place, or unless the TLS
cipersuite is weak (null?). Should we add that, or not, or just
suggest
it in Security Considerations? I'm not quite sure if you were talking
about that or about TLS closure in some parts of your reply:-)

About invalidated associations:

At 02:31 AM 12/9/2003, Hallvard B Furuseth wrote:

>> When the association is invalidated, the server it MUST reject
>> subsequent operation requests other than Bind, Unbind and Start
TLS,
>> and respond with a resultCode of strongAuthRequired to indicate
that
>> the client needs to bind to reestablish its authentication.
> 
> I'm a little concerned that of the overload here. strongAuthRequired
> means, generally, that stronger authentication is required. Now,
> that could be due to the invalidation of the association, but it
could
> be due to any number of other reasons. Additionally, the server
could
> be willing, after invalidating the association, to continue to allow
> the client to attempt operations which don't require that
association.

All true, but maybe this is the best LDAPv3 can do. What we need is a
new error code, or at least to rename strongAuthRequired, but I take
it
that's out of scope for ldapbis. A new code certainly is.

> The MUST here is actually extraneous.

As I said in the previous message, I agree. The MUST is OK if we
change
[Protocol] to match. Otherwise I suggest to delete it (not just
lowercase it) and add a sentence about servers being allowed to return
strongAuthRequired in other circumstances too. See my previous
message.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Feb 2004 16:37:12 -0800

At 11:08 PM 2/15/2004, Roger Harrison wrote:
>I believe I have represented the discussion consensus on this issue for the -10 draft of authmeth.

Thanks.  I ask the WG to carefully review this revision of authmeth I-D and
comment to the list regarding any and all technical issues which concern you.
Editorial comments should be sent directly to the editor.  If after you review
this revision you have no comments, please let me know by private email.

I ask that you review and comment so within the next couple of weeks so that
issues which need face-to-face time to resolve can be discussed at IETF#59.
We'll consider next steps (e.g., when issue the WG Last Call) at IETF#59.

Kurt (LDAPBIS co-chair)