Subject: Re: Authz/Authc state upon start TLS

From: Jeff Hodges <[email-masked]>
Date: Sat, 01 Jan 2000 10:48:35 -0800

I've updated/enhanced/repaired the "LDAP Association State Diagram". The new version is
v2.0b 1999-12-14 and is available here..

  http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.html or..
  http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.gif  or..
  http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.ps

The intent is to diagram all of the possible states and state transitions of an LDAP
association *security context*, and thus is a compendium of information gleaned from..

[1] Lightweight Directory Access Protocol (v3):Extension for Transport Layer Security.
     http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-ldapv3-tls-05.txt
[2] Authentication Methods for LDAP.
     http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-authmeth-04.txt
[3] Lightweight Directory Access Protocol (v3).  http://www.faqs.org/rfcs/rfc2251.html

..where the security context is defined to consist of the LDAP association's notion of
authentication and authorization identities, plus any present TLS (aka "session") layer's
authentication identity. 

"Kurt D. Zeilenga" wrote:
> 
> First, a general comment.  This diagram scares the hell out of me.
> I am quite concerned that we've added an unmanagable amount of
> complexity to the authentication process.  

I agree it's complex. I don't agree it's "unmanageable". For example, there is at least
one implementation presently available on the market that implements much if not all of
the security context states and state transitions defined in the three above documents.
And several others presently shipping that come very close if one is willing to view
TLS/SSL-on-separate-port-(for now) as functionally equivalent to StartTLS-on-single-port.

In fact, the purpose of the AuthMeth draft [2] is explicitly to provide guidance to
implementers and deployers on what (a) what aspects of the overall security picture to
implement, and (b) what mechanisms make sense to use in what given scenarios. 

> I can not even imagine
> what affect introduction of IPSEC will have on this complexity.  

From the LDAP-cum-TLS/SSL perspective, IPSEC is a separate layer underneath. The only
interaction envisioned at this time might be if an implementor enables the SASL EXTERNAL
mechanism to assert an IPSEC-layer authentication identity as the source for an LDAP
association's authorization identity. This is in fact noted in state 4 of the diagram. 

> Second, per AuthMeth:
>         2->8 is inappropriate as 2 has no TLS identity, 2->5?

Good catch. Fixed.

> Third, per RFC2251, bind failures should cause connection to be
> treated as "anonymous"
>         4-EXTERNAL should return to 1
>         5-EXTERNAL should return to 2
>         7-NO should return to 3
>         11-NO should return to 3

I disagree. Perhaps you didn't read the explanation & rationale about this in my msg in
this thread dated "Tue, 07 Dec 1999 13:40:47 -0800"?

> One additional comment on 1->StartTLS->3.
> 
> A StartTLS that asserts a TLS client identity should not automatically
> imply or assert an LDAP authentication identity as shown in state 3.
> State 3 should be no AuthID, no AuthzID as no bind has occurred.  I
> believe that any mapping of SASL client identity to the LDAP
> authentication identity should be done upon SASL External bind.

This was an admitted bug in StartTLSStateDiagram-8-May-1998.html, and is fixed in
LDAPAssociationStateDiagram-1999-12-12.html & LDAPAssociationStateDiagram-1999-12-14.html.

thanks,

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Jan 2000 12:53:19 -0800

>this thread dated "Tue, 07 Dec 1999 13:40:47 -0800"?

I did read it and just reread it.  I still don't see an overriding
reason for treating bind failures when TLS is established any differently
than any other bind failure.  Maybe you can elaborate on:
	"ldapv3-tls-05 is more correct from thinking about how security works"
	
I believe SASL/EXTERNAL should be just like any other SASL mechanism.
The SASL bind either passes or it fails, and if it fails the LDAP connection
should be treated as "anonymous".  I do believe it unwise to special
case any bind failure in this regard.

My rational is that the security specifications need to be simple such
as to reduce the likelyhood that they are flawed or that their implementations
(or deployments of implementations) are flawed.

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