| Author |
Topic: StartTLS -- RFC 2830: Extension for Transport Layer Security |
|
authen
member
offline  |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
 |
|
|
| StartTLS -- RFC 2830: Extension for Transport Layer Security |
RFC 2830 defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an
LDAP extended request.
|
|
|
|
|
|
|
authen
member
offline  |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| StartTLS Request |
A client may perform a Start TLS operation by transmitting an LDAP
PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
Start TLS operation:
1.3.6.1.4.1.1466.20037
An LDAP ExtendedRequest is defined as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
A Start TLS extended request is formed by setting the requestName
field to the OID string given above. The requestValue field is
absent. The client MUST NOT send any PDUs on this connection
following this request until it receives a Start TLS extended
response.
Note: Protocol Data Unit (PDU) is a standard method for transporting LDAP messages over TCP/IP.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| StartTLS Response |
When a Start TLS extended request is made, the server MUST return an
LDAP PDU containing a Start TLS extended response. An LDAP
ExtendedResponse is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
A Start TLS extended response MUST contain a responseName field which
MUST be set to the same string as that in the responseName field
present in the Start TLS extended request. The response field is
absent.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Response with ResultCode other than |
If the ExtendedResponse contains a resultCode other than success,
this indicates that the server is unwilling or unable to negotiate
TLS.
If the Start TLS extended request was not successful, the resultCode
will be one of:
operationsError(1) (operations sequencing incorrect; e.g. TLS already
established)
protocolError(2) (TLS not supported or incorrect PDU structure)
referral(10) (this server doesn't do TLS, try this one)
unavailable(52) (e.g. some major problem with TLS, or server is
shutting down)
The server MUST return operationsError if the client violates any of
the Start TLS extended operation sequencing requirements.
If the server does not support TLS (whether by design or by current
configuration), it MUST set the resultCode to protocolError.
The client's current session is unaffected if the server does not support TLS.
The client MAY proceed with any LDAP operation, or it MAY close the connection.
The server MUST return unavailable if it supports TLS but cannot
establish a TLS connection for some reason, e.g. the certificate
server not responding, it cannot contact its TLS implementation, or
if the server is in process of shutting down. The client MAY retry
the StartTLS operation, or it MAY proceed with any other LDAP
operation, or it MAY close the connection.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Requesting to Start TLS on an LDAP Association |
The client MAY send the Start TLS extended request at any time after
establishing an LDAP association, except that in the following cases
the client MUST NOT send a Start TLS extended request:
if TLS is currently established on the connection, or
during a multi-stage SASL negotiation, or
if there are any LDAP operations outstanding on the connection.
The result of violating any of these requirements is a resultCode of
operationsError.
The client MAY have already performed a Bind operation when it sends
a Start TLS request, or the client might have not yet bound.
If the client did not establish a TLS connection before sending any
other requests, and the server requires the client to establish a TLS
connection before performing a particular request, the server MUST
reject that request with a confidentialityRequired or
strongAuthRequired result. The client MAY send a Start TLS extended
request, or it MAY choose to close the connection.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Starting TLS |
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].
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Server Identity Check |
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.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| TLS Connection Establishment Effects |
Upon establishment of the TLS connection onto the LDAP association,
any previously established authentication and authorization
identities MUST remain in force, including anonymous state. This
holds even in the case where the server requests client
authentication via TLS -- e.g. requests the client to supply its
certificate during TLS negotiation (see [TLS]).
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Client Assertion of Authorization Identity |
A client MAY either implicitly request that its LDAP authorization
identity be derived from its authenticated TLS credentials or it MAY
explicitly provide an authorization identity and assert that it be
used in combination with its authenticated TLS credentials. The
former is known as an implicit assertion, and the latter as an
explicit assertion.
Implicit Assertion
An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will derive
the client's authorization identity from the authentication identity
supplied in the client's TLS credentials (typically a public key
certificate) according to local policy. The underlying mechanics of
how this is accomplished are implementation specific.
Explicit Assertion
An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
credentials octet string. This string MUST be constructed as
documented in section 9 of "Authentication Methods for LDAP", RFC 2829.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 07/02/2007 01:21:55 PM
Edit
Quote
Report
Profile
Reply