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