Subject: Authz/Authc state upon start TLS

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 17 Nov 1999 15:58:06 -0800

I am wondering what is the rational of 7.1.1 is:
	"Upon establishment of the TLS connection into the LDAP
	association, any previous established authentication and
	authorization identities MUST remain in force, including
	anonymous state."

I would have thought it more appropriate to require:
	"Upon establishment of the TLS connection into the LDAP
	association, any previous established non-anonymous
	authentication and authorizations identitites MUST NOT
	remain in force.  The LDAP association must move to an is
	anonymous authentication and authorization state upon
	return successful completion of the Start TLS operation."

I should also note that the above MUST does not limit the server
ability to affect authorization otherwise (per RFC2251):
	Authorization MAY be affected by factors outside of the
	LDAP Bind request, such as lower layer security services.

To eliminate any potential conflict between RFC2251 and the TLS
draft, the above MUSTs likely should be SHOULDs.

In addition, I am wondering what is rational of 7.1.2.1.
	"Any authentication identity and authorization
	identity, as well as TLS connection, which were
	in effect prior to making the [FAILED] bind request,
	MUST remain in force."

RFC2251 states:
	"... if the bind fails, the connection will be treated
	as anonymous."

It seems odd to me that the TLS connection state would change
the semantics of the bind operation.  It seems that this may
confuse implementors.

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Steve Sonntag" <[email-masked]>
Date: Thu, 18 Nov 1999 10:30:24 -0700

> "Kurt D. Zeilenga" <[email-masked]> 17-Nov-99 5:00:17 PM >

I disagree

The TLS establishment that the draft describes  has nothing to do with bind, i.e.
it does not  affect the LDAP association in any way.   The way the application
affects the LDAP association is described in 7.1.2.1 and 7.1.2.2 by invoking a
bind request after the TLS establishment.

In a similar way, terminating TLS on the connection leaves the existing LDAP
association intact (5.1)  however closing the connection terminates the
association (7.2).  

I think the draft language needs to be tightened up in this area, it overloads
the term "connection" to mean the physical connection, and the
establishment of TLS and the termination of TLS.  An example:
I believe 7.2 is talking about closing the physical connection, where 5.1 is describing
terminating TLS, but both use the term connection to describe the behavior.

> draft, the above MUSTs likely should be SHOULDs.

The inability to enable an vendors underlying security service could
cause an authentication failure.  The security service is not associated
with the bind PDU.

> 	in effect prior to making the [FAILED] bind request,

Again, it does not affect authentication
> the semantics of the bind operation.  It seems that this may
Again it doesn't change bind behavior at all
> Net Boolean Incorporated	<http://www.boolean.net/>

------------------------
Steve Sonntag
Novell Directory Services
+1 801 861 7097

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Nov 1999 17:36:43 -0800

> >       return successful completion of the Start TLS operation."

The authoration and authentication identities established before StartTLS,
in my opinion, should be ignored upon established of StartTLS as they
were neogiated using a less secure transport.

Howeever, my main concern is that Bind failures do not return the connection
to an anonymous state per RFC2251.  This is best demonstrated by viewing
Jeff's diagram (I believe it's up to date).

http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.html

In particular,

  Failure of 3->6 bind should return to state 3 not 7.
  Failure of 7->6 bind should return to state 3 not 7.
  Failure of 7->10 bind should return to state 3 not 7.
  Failure of 5->5 bind should return to state 2.
  Failure of 4->4 bind should return to state 1.

In addition, I think the following are missing:
  "anonymous" bind from state 3 to 3 with failures to 3.
  simple or SASL (non-External) bind from 3 to 7 with failures to 3.
  "anonymous" bind from state 2 to 2 with failures to 2.
  simple or SASL (non-External) bind from 2 to 7 with failures to 2.