RE: comments on draft-ietf-ldapext-ldapv3-tls-01.txt

 
I may be one of those opinionated persons - 
But given there are so many options in LDAP and options in the way one
does passwords, authentication, binding, TLS, GSSAPIs and tokens and so
on - and without a distributed model a DIT and access contol model and
mutual authentication - one can only descibe LDAP as a pile of different
wheels with a pile of different door locks without a car to put them on.

If I stood back and looked at this lot as a customer who was
knowledgeble about trusted systems and my career depended on selection
of product - and then I read that the spec contains weasle words to
cover up the issues associated with  (no) key management of the
multitudes of inconsistent security features - I would recommend to my
CIO or CEO to put LDAP in the bin.

It is pointless designing fragments of inconsistent mechanims for
security if one cannot express profiles for their use, the associated
trust models and the crypto/key management requirements ... and scaling
issues.

I think the Internet has grown into a commercial system that requires
commercial grade standards  - particularly for scaleable security
regimes.
Now that the LDAP PICS has been produced - I think their is a need to
profile the security aspects of LDAP and highlight the trust/keymgt
issues with it.

But of course - because LDAP servers are not distributed - then this is
really not required - security becomes bilateral between a client and a
server.. But we still cannot solve certficate path processing in a wider
context..

If on the other hand X.500 is used with LDAP access then a lot of the
above issues are already solved.

regards alan  
----------
From: RL Bob Morgan
To: [email protected] LDAPEXT
Cc: [email protected]
Sent: 7/29/98 10:19:49 PM
Subject: Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt 


On Thu, 23 Jul 1998 [email protected] wrote:

> ...
> > In the absence of a subjectAltName extension of type dNSName in the
> > certificate: how should  the compare algorithm should look like, as
> > the only ldap server name in the cert - the  subjectName field -
will
> > be an X.500 Distinguished Name? Some RDNs may contain rfc822MailBox
> > names or something else that allows a mapping onto the servers
> > hostname.  
> 
> > The cert may also contain subjectAltName extensions distinct from
> > dNSName, but nevertheless  suitable for identity check, e.g
> > rfc822Name, uniformResourceIdentifier or iPAddress.  
> 
> Defining this check down to every last possibility is something we've
been 
> hoping to avoid. The check is based on the one in
draft-ietf-tls-https-01.txt 
> and is written as per conversations with Jeff Schiller and Harald
Alvestrand. 
> ...
> I'm inclined to leave our text as-is for now, but raise this issue on 
> [email protected] (e.g. "hey, we think that end-entity server certs
should 
> have a subjectAltName of type dNSName whether or not they have a
subjectName, 
> because of this client checking the server thing, what do you folks
think?") 
> and see what they have to say.

We had a discussion on just this question (whether and how a TLS client
should check the server-supplied cert with the server's name and/or
address) at the ldapext WG session in LA.  One knowledgeable opinionated
person said that if this check isn't fully specified and absolutely
required we may as well throw all the other security out the window. 
Another knowledgeable opinionated person said this issue is such a mess
and so poorly understood that we would be jumping into a deep black hole
if we even mentioned it in the spec.  We concluded that consensus is
lacking, hence the weasel wording in the spec.  I strongly suggest that
we
don't want this issue to hold up this document. 

 - RL "Bob"