Revisited: effect of Start TLS on authentication state

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

After the WG discussion on this topic a couple of days ago, I went back
through the discussion on the WG mail list from approximately July 1,
2003 to August 4, 2003. Here is where I think we stand based on these
two sources:

Desire 1. There are people who want to ensure that authentication and
authorization states achieved by relatively secure means (such as SASL
GSSAPI) can remain valid after Start TLS operation. Although it is not
stated, this decision would likely be based on local policy of some
sort.

Desire 2. There are people who want to ensure that authentication and
authorization states achieved by relatively insecure or weak means (such
as simple password) can be invalidated by a Start TLS based on local
policy.

The concern I have with trying to meet both of these requirements is
that they conflict--there's really no deterministic way for a client
implementation to figure out what has happened to its authentication and
authorization status in the LDAP spec if we support both outcomes. To
get deterministic behavior I believe we have two choices:

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

Option 2: Require servers to invalidate any existing
authentication/authorization state and return the LDAP association to
anonymous upon processing of Start TLS.  Clients would then have to
reestablish any authentication state. In practice this will mean that
clients using Start TLS will typically establish TLS before doing the
first non-anonymous operation to avoid having to repeat a step.

Either one of these is probably workable, however based on the way that
RFC 2830 was written, I believe that Option 1 is more faithful to
currently implemented practice and should not be difficult for server
implementers to work with. I propose it as the solution to this issue.

Roger