Subject: Identity and TLS sessions

From: "Gary Anderson" <[email-masked]>
Date: Mon, 28 Jan 2002 17:01:42 -0700

RFC 2830, and subsequently the bis draft Authentication Methods and
Connection Level Security Mechanism for LDAPv3 specify that the
established identity persists through the Start TLS operation, but that
at the end of the TLS portion of the session, identity is lost and the
connection reverts to the anonymous identity.

The draft specifically states that the server can respond to any
request for data with the confidentialityRequired or strongAuthRequired
result code.  The server in this case is implementing administrator
policy about confidentiality of specific data.  If the client chooses to
proceed and access this information, he is not required to re-verify his
identity.  He can simply start an encrypted session and get the data.  I
think that it makes sense not to require the client application to
re-authenticate once he has finished transfer of the confidential
information and chooses to close the TLS session because the rest of the
data he is getting is not confidential and does not require the overhead
of an encrypted channel.

It seems to me that there are four possible cases for handling identity
at the end of a TLS session:

1.  Always default to anonymous identity - the current specification

2.  Always retain the session identity, regardless of where it was
established - this mirrors the operation specified for StartTLS

3.  Retain the session identity if it didn't change between StartTLS
and ending TLS, but revert to anonymous if the identity changed during
the TLS portion of the user session

4.  Retain the session identity prior to the TLS portion of the session
and restore that identity at the end of the TLS portion of the session

I suspect that the choice of anonymous identity upon closure of the TLS
session was simply one of convenience.  I think that the actual
operation should more closely resemble 2 or 4 in the above list.

Can someone provide insight on why the current RFC specifies returning
to the anonymous identity?

In light of the above, I would like to propose the following change to
5.5.2 of the Authentication Methods draft:

Old Text:    
   Closure of the TLS connection MUST cause the LDAP association to 
   move to an anonymous authentication and authorization state 
   regardless of the state established over TLS and regardless of the 
   authentication and authorization state prior to TLS connection 
   establishment. 

New Text:
  Upon closure of the TLS connection, the server MAY leave the LDAP
  association with any previously established authentication and 
  authorization identities, or it MAY move the LDAP association to
  an anonymous authentication and authorization state.  The 
  authentication and authorization identities for the LDAP association
  will depend on server authentication and association identity
policy.

The above only leaves the client the thorny problem of identifying what
the server policy is.

---

From: Mark Wahl <[email-masked]>
Date: Tue, 29 Jan 2002 15:17:09 -0600

> to the anonymous identity?

Because a server may have based the identity decision on the TLS or SSL 
negotiation, e.g. if the client has used certificate-based 
authentication and then Binds with mechanism EXTERNAL.  The LDAP Bind 
operation does not stack credentials.

>   will depend on server authentication and association identity

Changes between a Proposed and Draft standard should be based on resolving
interoperability problems.  I don't see an interoperability problem in the
current RFCs or that this change would improve interoperability between 
clients which have implemented the existing RFCs.

Mark Wahl
Sun Microsystems Inc.