Re: Authz/Authc state upon start TLS

[Jeff Hodges <JHodges@oblix.com>]

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