Re: Authz/Authc state upon start TLS

[Jeff Hodges <jhodges@oblix.com>]

First, I want to say it's great to get feedback on this stuff and that I think
Kurt found some things to think about and a bug in the state diagram. 

However,..

"Kurt D. Zeilenga" wrote on Fri, 19 Nov 1999 17:39:15 -0800 (PST):
> 
> Steve Sonntag wrote:
> >
> > > "Kurt D. Zeilenga" <kurt@boolean.net> 17-Nov-99 5:00:17 PM >
> > > 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."
> > >
> 
> 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.

.., I'm sorry, but I don't agree with this blanket assertion. One can securely
authenticate over an arbitrary, insecure transport using mechanisms such as
Kerberos and Digest-MD5, for example. I feel it is up to the directory
administrators to configure their deployments to either accept or reject Bind
operations given the particular authentication mechanisms asserted by the
requester and the context in which they are wielded (e.g. over a secure session
layer (e.g. TLS, or SASL with security layer on) or not) -- and that we as
protocol designers need to give the protocol-based server & client implementors
the skosh room they need in order to deliver said configurability to deployers.  
 

> Howeever, my main concern is that Bind failures do not return the connection
> to an anonymous state per RFC2251.  

This is a good point in that this sentence from the middle of the last paragraph
of section 4.2.1 of RFC2251..

  "Authentication from earlier binds
   are subsequently ignored, and so if the bind fails, the connection
   will be treated as anonymous."

..is in apparent conflict with the assertions in the last sentence of each
paragraph of 7.1.2.3 of ldapv3-tls-05:

  [Following a failed bind,] the LDAP association's authentication
  identity and authorization identity (if any) which were in effect after
  TLS establishment but prior to making the Bind request, MUST remain in
  force. 

..and this is a good thing to catch. 


However, RLBob and I feel that it's arguable that ldapv3-tls-05 is more correct
from thinking about how security works, and it isn't as simple to resolve as
saying that there's a bug in ldapv3-tls-05 that we should just fix now prior to
publication of ldapv3-tls-05 as an RFC, since the issue needs more discussion.  

This is just the sort of detailed cleanup that should happen on the way to Draft
Standard maturity level for LDAPv3 ~as a whole~; but this shouldn't hold up
progression of the ldapv3-tls-05 draft as-is to Proposed Standard. 


> 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

[Thank you for pointing to the diagram and using it as the basis of discussion.]

Yes, the diagram is nominally up-to-date relative to ldapv3-tls-05 -cum- RFC2251
-cum- ldapext-authmeth-04, but Kurt has found some things that need to be fixed
and clairified, I believe. 

I'm going to go thru Kurt's below points assuming that ldapv3-tls-05 remains
as-specified. 

> In particular,
> 
>   Failure of 3->6 bind should return to state 3 not 7.

This is a bug in the diagram, there should be a "No." edge from 6->3 indicating
"invalidCredentials". Also, there arguably should be a separate "decision box"
along the path from 7->6->8 than along the path from 3->?->8. I don't know what
the "proper" way to model such decision situations in a state diagram is, if
anyone knows, please speak up (references to pertinent books/papers always
welcome). 

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

Actually, per the statement in section 4.2.1 of RFC2251 (excerpted above), all
failed binds must be returned to state 1 (in the diagram), or arguably state 2
depending upon whether TLS was ON or not (but recall that RFC2251 wasn't crafted
with running over TLS in mind), upon bind failure. 

So, I (and RLBob) agree this here is a specific disconnect between ldapv3-tls-05
and RFC2251, as discussed above. 


> In addition, I think the following are missing:
>   "anonymous" bind from state 3 to 3 with failures to 3.

Yes, I agree. Though, if one's strictly adhering to RFC2251, failures from this
state would arguably go to state 2. However, we feel that we should keep
ldapv3-tls-05 as-currently-specified and thus the failure should go back to
state 3. 


>   simple or SASL (non-External) bind from 3 to 7 with failures to 3.

Well I think you really mean 3->?->8 (as discussed above), with ? being a new
decision box to-be-added on the overall 3->8 path. And yes, a "No." edge should
go from the new decision box back to state 3. 


>   "anonymous" bind from state 2 to 2 with failures to 2.

Yes, I agree.


>   simple or SASL (non-External) bind from 2 to 7 with failures to 2.

Yes, I agree. 


I'm in the process of updating the state diagram according to this message and
will announce a pointer to it when I get it put up. 

Thanks again for the careful review. 

JeffH 

acknowledgement: RLBob <rlmorgan@cac.washington.edu> collaborated on the
reasoning & wording of how to address the RFC2251 & ldapv3-tls-05
bind-failure-disconnect.