EAP-TLS
From this point forward, while nominally the EAP conversation occurs
between the EAP authenticator and the peer, the authenticator MAY act
as a pass-through device, with the EAP packets received from the peer
being encapsulated for transmission to a backend authentication
server.
Once having received the peer's Identity, the EAP server MUST respond
with an EAP-TLS/Start packet, which is an EAP-Request packet with
EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS
conversation will then begin, with the peer sending an EAP-Response
packet with EAP-Type=EAP-TLS. The data field of that packet will
encapsulate one or more TLS records in TLS record layer format,
containing a TLS client_hello handshake message. The current cipher
spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
compression. This current cipher spec remains the same until the
change_cipher_spec message signals that subsequent records will have
the negotiated attributes for the remainder of the handshake.
The client_hello message contains the peer's TLS version number, a
sessionId, a random number, and a set of ciphersuites supported by
the peer. The version offered by the peer MUST correspond to TLS
v1.0 or later.
The EAP server will then respond with an EAP-Request packet with
EAP-Type=EAP-TLS. The data field of this packet will encapsulate one
or more TLS records. These will contain a TLS server_hello handshake
message, possibly followed by TLS certificate, server_key_exchange,
certificate_request, server_hello_done and/or finished handshake
messages, and/or a TLS change_cipher_spec message. The server_hello
handshake message contains a TLS version number, another random
number, a sessionId, and a ciphersuite. The version offered by the
server MUST correspond to TLS v1.0 or later.
If the peer's sessionId is null or unrecognized by the server, the
server MUST choose the sessionId to establish a new session.
Otherwise, the sessionId will match that offered by the peer,
indicating a resumption of the previously established session with
that sessionId. The server will also choose a ciphersuite from those
offered by the peer. If the session matches the peer's, then the
ciphersuite MUST match the one negotiated during the handshake
protocol execution that established the session.
If the EAP server is not resuming a previously established session,
then it MUST include a TLS server_certificate handshake message, and
a server_hello_done handshake message MUST be the last handshake
message encapsulated in this EAP-Request packet.
The certificate message contains a public key certificate chain for
either a key exchange public key (such as an RSA or Diffie-Hellman
key exchange public key) or a signature public key (such as an RSA or
Digital Signature Standard (DSS) signature public key). In the
latter case, a TLS server_key_exchange handshake message MUST also be
included to allow the key exchange to take place.
The certificate_request message is included when the server desires
the peer to authenticate itself via public key. While the EAP server
SHOULD require peer authentication, this is not mandatory, since
there are circumstances in which peer authentication will not be
needed (e.g., emergency services, as described in [UNAUTH]), or where
the peer will authenticate via some other means.
If the peer supports EAP-TLS and is configured to use it, it MUST
respond to the EAP-Request with an EAP-Response packet of EAP-
Type=EAP-TLS. If the preceding server_hello message sent by the EAP
server in the preceding EAP-Request packet did not indicate the
resumption of a previous session, the data field of this packet MUST
encapsulate one or more TLS records containing a TLS
client_key_exchange, change_cipher_spec, and finished messages. If
the EAP server sent a certificate_request message in the preceding
EAP-Request packet, then unless the peer is configured for privacy
(see Section 2.1.4) the peer MUST send, in addition, certificate and
certificate_verify messages. The former contains a certificate for
the peer's signature public key, while the latter contains the peer's
signed authentication response to the EAP server. After receiving
this packet, the EAP server will verify the peer's certificate and
digital signature, if requested.
If the preceding server_hello message sent by the EAP server in the
preceding EAP-Request packet indicated the resumption of a previous
session, then the peer MUST send only the change_cipher_spec and
finished handshake messages. The finished message contains the
peer's authentication response to the EAP server.
In the case where the EAP-TLS mutual authentication is successful,
the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success