[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Questions about startTLS.
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?
How the TLS handshake handles client auth via a client cert is described in
draft-ietf-tls-protocol-05.txt, in this section...
7.4.6. Client certificate
When this message will be sent:
This is the first message the client can send after receiving a
server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is
available, the client should send a certificate message
containing no certificates. If client authentication is required
by the server for the handshake to continue, it may respond with
a fatal handshake failure alert. Client certificates are sent
using the Certificate structure defined in Section 7.4.2.
Note: When using a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication is requested, the
Diffie-Hellman group and generator encoded in the client's
certificate must match the server specified Diffie-Hellman
parameters if the client's parameters are to be used for the key
exchange.
Now, in terms of the LDAP StartTLS operation, this means that the underlying
TLS handshake will fail, and the connection will be terminated. This is
described in tls-protocol-05 here..
7.2. Alert protocol
One of the content types supported by the TLS Record layer is the
alert type. Alert messages convey the severity of the message and a
description of the alert. Alert messages with a level of fatal
result in the immediate termination of the connection. In this case,
other connections corresponding to the session may continue, but the
session identifier must be invalidated, preventing the failed
session from being used to establish new connections. Like other
messages, alert messages are encrypted and compressed, as specified
by the current connection state.
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.html
Your question would seem to be about moving the overall state from state #1 to
#3 (on the diagram). If an fatal error occurs during the TLS handshake, then
the connection will effectively close, and the state will transition from (not
quite) $3 back to #1. Granted, perhaps the state diagram could display this
eventuality more precisely (but its already pretty complicated, perhaps I
should add an annotation to it).
> 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...
4.1.2.6 Subject
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name may be
carried in the subject field and/or the subjectAltName extension. If
the subject is a CA (e.g., the basic constraints extension, as dis-
cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the
subject field MUST be populated with a non-empty distinguished name
matching the contents of the issuer field (see sec. 4.1.2.4) in all
certificates issued by the subject CA. If subject naming information
is present only in the subjectAltName extension (e.g., a key bound
only to an email address or URI), then the subject name MUST be an
empty sequence and the subjectAltName extension MUST be critical.
.
.
.
4.2.1.7 Subject Alternative Name
The subject alternative names extension allows additional identities
to be bound to the subject of the certificate. Defined options
include an Internet electronic mail address, a DNS name, an IP
address, and a uniform resource identifier (URI). Other options
exist, including completely local definitions. Multiple name forms,
and multiple instances of each name form, may be included. Whenever
such identities are to be bound into a certificate, the subject
alternative name (or issuer alternative name) extension MUST be used.
Because the subject alternative name is considered to be defini-
tiviely bound to the public key, all parts of the subject alternative
name MUST be verified by the CA.
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present. If the subject field con-
tains an empty sequence, the subjectAltName extension MUST be marked
critical.
.
.
.
When the subjectAltName extension contains a domain name service
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax," as specified by RFC
1034 [RFC 1034]. Note that while upper and lower case letters are
allowed in domain names, no signifigance is attached to the case. In
addition, while the string " " is a legal domain name, subjectAltName
extensions with a dNSName " " are not permitted. Finally, the use of
the DNS representation for Internet mail addresses (wpolk.nist.gov
instead of wpolk@nist.gov) is not permitted; such identities are to
be encoded as rfc822Name.
.
.
.
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.
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).
> When you refer to the "canonical DNS name" do you mean the left most
> portion of the dns name -- e.g., the 'a' of a.bar.com?
No, not exactly. The passage you're citing is apparently...
- The client MUST use the server hostname it used to open
the LDAP connection as the value to compare against the
server name as expressed in the server's certificate.
The client MUST NOT use the server's canonical DNS name or
any other derived form of name.
What we're referring to there in terms of "canonical DNS name" is the name
attached to the "A" record for that IP address in the DNS. For example,
consider these DNS records..
www.domain.com CNAME domain.com
domain.com A 17.254.3.131
domain.com is the "canonical name" of ip address 17.254.3.131. www.domain.com
is an alias. If the user has entered "www.domain.com", then we should be
checking the cert's subjectAltName with a type of dNSName for that rather than
doing something like querying the DNS for the "A" record name (i.e.
"canonical" name) and using that.
Jeff
ps: comments and feedback from folks encouraged.