[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Authz/Authc state upon start TLS
> "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."
>
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.
> 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.
>
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 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."
Again, it does not affect authentication
>
> 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.
>
Again it doesn't change bind behavior at all
>
>
>
> ----
> Kurt D. Zeilenga <kurt@boolean.net>
> Net Boolean Incorporated <http://www.boolean.net/>
------------------------
Steve Sonntag
Novell Directory Services
+1 801 861 7097