RE: Questions about startTLS.

[Kristianne Palmer <Kristianne.Palmer@entrust.com>]

> Jeff,
> Thanks for your reply.
> I have a few more questions/comments below.
> Regards,
> -Kristianne
> 
> Kristianne,
> 
> > If a client sends a startTLS extended request to start a TLS/SSL
> > handshake, must the TLS server request a certificate?
> 
> Nope. Whether or not an LDAP server requires client authentication, by
> 
> whatever means (e.g. password-based auth, Kerberos-based, cert-based
> via TLS, 
> etc) is a deployment & configuration decision.
> 
> > If the client does not send a certificate will the server return an
> > error?
So the way I read the excerpts you provided
(draft-ietf-tls-protocol-05.txt 7.4.6 and 7.2) the server can be
configured to 
a) not request a client certificate
b) request a client certificate but not require that one be sent
c) require that a client certificate be sent

> In terms of what it looks like from the LDAP level of abstraction,
> please 
> refer to..
> 
>  
> http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.ht
> ml
> 
Thanks for the pointer -- most useful.

> > Also in section 4.6 of the Internet Draft "LDAPv3: Extension for
> TLS"
> > you state that if a subjectAltName extension of type dNSName is
> present
> > it should be used to verify the server's identity. However, you
> don't
> > say how the server's identity should be verified in the absence of
> this
> > extension. 
> 
> Good point. I don't think we've really discussed what a fallback
> algorithm 
> would be, or whether we should have one. In the next version of
> ldapv3-tls, 
> this check will move from a "SHOULD' to a "MUST", per Schiller at the
> Chicago 
> IETF. I wonder what is said in PKIX's docs about plugging dNSName in
> the 
> server's cert's subjectAltName attribute? ....well, I just groveled
> thru 
> draft-ietf-pkix-ipki-part1-11.txt, and what it says is...
<pkix excerpts removed >

> So, pkix-ipki-part1-11 does NOT presently say that a cert issued for
> some 
> server hosting a service like LDAP must have a filled-in
> subjectAltName with a 
> type of dNSName. BUT, Schiller was, according to RLBob, saying in
> Chicago, if 
> the server's cert has a subjectAltName with a type of dNSName, then
> the client 
> MUST do the check.
While many clients may not care about verifying the server's identity I
think that it is necessary that we have a way that the client can do
this reliably if  desired. 
> Even if the SHOULD is upgraded to a MUST there are still problems with
> using the dNSName. The DNS name which is returned in a referral and
> used to contact the directory may not be the same as the one in the
> server's certificate -- if the directory lies on the other side of a
> firewall or proxy then the DNS name may change. This means that the
> client needs to be configured in advance to know what subject name to
> use to verify the identity of various servers. Definitely a high
> maintenance solution.
Ideally I think we should be addressing this by trying to get the PKIX
docs to require the dNSName to be present for servers, and encourage
placing all of the names by which a server may be contacted in the
subjectAltName, however, knowing all of these names may be impractical. 

> But, we don't seem to have complete agreement among apps folks what
> behavior 
> should of apps protocols (and the apps built on top of them) ought to
> be when, 
> either..
> 
> 1. the subjectAltName with a type of dNSName does not match the dns
> name for 
> the service/server that the client is wielding, or..
> 
> 2. there is not a subjectAltName with a type of dNSName in the cert. 
> 
> This is something that perhaps apps folks should get together and
> discuss 
> (doing so on the ietf-apps-tls@imc.org list comes to mind).
I'll try raising this issue on the list. Thanks.