[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
draft-ietf-ldapext-ldapv3-tls-06.txt
Jeff,
I have only significant concern.
In 6.1.2:
[Upon failure of BIND SASL/EXTERNAL...]
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.
This is inconsistent with RFC 2251 prescribed behavior:
Clients MAY send multiple bind requests on a connection to change
their credentials. ... Authentication from earlier binds
are subsequently ignored, and so if the bind fails, the connection
will be treated as anonymous.
I can find no compelling reasoning why BIND failure whilst
TLS is enabled should have special behavior. I believe this an
unnecessary complication. I believe there are many good reasons
why this BIND behavior should be consistent without regard to TLS
(or IPSEC or whatever). Reasons: simplicity of specification,
implementation, and use.
The general rule for security is simplicity. Why the complication?