| |
Server Identity Check |
|
|
Subject: Server Identity Check
Author: authen
In response to: Starting TLS
Posted on: 07/02/2007 08:48:26 PM
The client MUST 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.
Matching is performed according to these rules:
- 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.
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- Matching is case-insensitive.
- The "*" wildcard character is allowed. If present, it applies only
to the left-most name component.
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
bar.com. If more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name), a match in any one of
the set is considered acceptable.
If the hostname does not match the dNSName-based identity in the
certificate per the above check, user-oriented clients SHOULD either
notify the user (clients MAY give the user the opportunity to
continue with the connection in any case) or terminate the connection
and indicate that the server's identity is suspect. Automated clients
SHOULD close the connection, returning and/or logging an error
indicating that the server's identity is suspect.
Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The
client MAY need to make use of local policy information.
>
> On 07/02/2007 08:46:13 PM authen wrote:
The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. It will return
other resultCodes, documented above, if it is unable.
In the successful case, the client, which has ceased to transfer LDAP
requests on the connection, MUST either begin a TLS negotiation or
close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
server to initiate TLS negotiation [TLS].
References:
|
|
|
|
