comments on TLS and text in Authmeth

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

<draft-ietf-ldapext-ldapv3-tls-01.txt>


Comments on <draft-ietf-ldapext-ldapv3-tls-01.txt>

the section listed.

7.  Security Considerations

The goals of using the TLS protocol with LDAP are to ensure connection
confidentiality and integrity, and to optionally provide for
authentication. 
(SNIP)
The level of security provided though the use of TLS depends directly on
both the quality of the TLS implementation used and the style of usage
of that implementation. Both parties SHOULD independently ascertain and
consent to the privacy level achieved once TLS is established and before
begining use of the TLS connection. For example, the privacy level of
the TLS connection might have been negotiated down to plaintext.

Client and server implementors SHOULD take measures to ensure proper
protection of credentials and other confidential data where such
measures are not otherwise provided by the TLS implementation.

Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality is required.


AND



<draft-ietf-ldapext-authmeth-02.txt>

For this authentication procedure to be successful, the client and
server MUST negotiate a ciphersuite which contains a bulk encryption
algorithm of appropriate strength.  Recommendations on cipher suites are
given in section 12. 
 Following the successful completion of TLS negotiation, the client MUST
send an LDAP bind request with the version number of 3, the  name field
containing the name of the user's entry, and the "simple"
authentication choice, containing a password.
 The server will, for each value of the userPassword attribute in  the
named user's entry, compare these for case-sensitive equality  with the
client's presented password.  If there is a match, then the  server will
respond with resultCode success, otherwise the server will respond with
resultCode invalidCredentials.





Comments
It seems we may have yet another set of single "bilateral"interface
mechanisms between a client and a server. For mutual confidentiality
services that may be OK. But as we all know by now - LDAP client and
LDAP only server systems do not scale . Simply because in the case of
any security features for anything, including distributed
authentication- we have to replicate every user entry and interface
property to every server that the user or users might access via the
LDAP referral mechanisms. 
I wonder if the approach to LDAP development is to keep compounding
additional LDAP security features (which require the replication of all
User entries and their key material (for authentication) and their
associated key management overheads for everything ....and now
replicating the transport security key management information.


I think that if one keeps on adding balaterally defined security
mechanisms which rely on operational management and replication effort,
to be a fundamentally broken concept simply because it does not scale
and is operationally unworkable for the wider Internet community.


It seems that we have a paradox with the LDAP work - LDAP was defined to
a simple protocol for the Internet community, which is in fact growing
by the day. But at the same time, it is getting obvious that the more
bilateral security features one puts into the design of a non scaleable
client-server interface system - that depend on heavy operational
management and replication processes to remain interoperable, the more
certain it is that the system will not scale or be operationally viable.

I therefore request that any security "interface mechanism" document
produced for directories SERIOUSLY defines how the system will or will
not scale, what the key management issues are AND what the issues are re
replicating everything to everywhere to make it work.

Otherwise one has to be blunt here and say these security mechanisms are
not worth the paper they are written on - as a mechanism to protect my
data in my environment for me is not very valuable.

Regards alan


PS - And I do not agree with architecting  transport layer security
operations into a specific applications protocol. 
Having a general Bind format which reflects/requests QOS requirements of
underlying services (for security, reliability and throughput) seems to
be the way ahead - The DEN work and every Internet service providor on
this planet seems to be working that way with directory objects
representing policies and profiles and QOS. But here we are again with
LDAP and a "spanner in the architectural works"