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

[Jeff.Hodges@stanford.edu]

Thanks for the comments Helmut.

Helmut.Baumgaertner@mch.sni.de said:
> Any particular reason for not using authMethodNotSupported as the
> resultCode in case the  LDAP server does not support TLS and cannot
> return a referral.   

Yes, the reasons we designed it like this are that..

- TLS isn't necessarily an authentication method. It of course ~can~ be, but 
isn't by default.

- the client may be trying to send the operation to an LDAPv2 server, and it 
will hopefully respond with a protocolError -- so we're trying to keep the 
semantics consistent.

Plus, a v3-capable client may ascertain whether the server it is talking with 
supports StartTLS by querying the server's root DSE for the supportedExtension 
attribute and checking to see that StartTLS is listed.


> >4.6.  Server Identity Check 
> > 
> >The client SHOULD check its understanding of the server's hostname 
> >against the server's identity as presented in the server's Certificate 
> >message, in order to prevent man-in-the-middle attacks. 
> > 
> >If a subjectAltName extension of type dNSName is present, it SHOULD be 
> >used as the source of the server's identity. 
> > 
> 
> Paragraph is duplicate 

I'll argue that aren't duplicates. The first is saying that the client SHOULD 
do this sort of check. The second is saying that if you've decided to do the 
check, here's what and how you SHOULD check. Perhaps the text could be more 
clear?


> 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. 
If we want to have a detailed conversation on how such a check works in the 
face of all possibilities, we should probably have it on 
ietf-apps-tls-request@imc.org.

> The original text seems to mandate, that an Ldap server needs to
> possess a cert with the  dNSName altName extension.  

It doesn't actually mandate this because the entire check is cast as a 
"SHOULD".

It's worth noting that a related discussion (on name attributes in the certs 
of various types of entities) has been raging on ietf-pkix@imc.org this week.

I'm inclined to leave our text as-is for now, but raise this issue on 
ietf-pkix@imc.org (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.

Also, what it may actually take is sending the draft on to the IESG and seeing 
what they have to say about it.

Jeff