TSG-X
TITLE:
SUPPORT FILE FOR X.P0028-200 COMMENT RESOLUTION (TLS CALL FLOW)
SOURCE:
Frank M. Alfano
1960 Lucent lane
Naperville IL 60566
630.979.7209
falfano@lucent.com
ABSTRACT:
This document contains text for X.P0028-200 section 5.8.3 EAP TLS
RECOMMENDATION:
Review and accept as baseline text for EAP TLS section of X.P0028-200.
Notice
Lucent Technologies grants a free, irrevocable license to 3GPP2 and its Organization
Partners to incorporate text or other copyrightable material contained in the contribution
and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell
in Organizational Partner’s name any Organizational Partner’s standards publication even
though it may include portions of the contribution; and at the Organization Partner’s sole
discretion to permit others to reproduce in whole or in part such contributions or the
resulting Organizational Partner’s standards publication. Lucent Technologies is also
willing to grant licenses under such contributor copyrights to third parties on reasonable,
non-discriminatory terms and conditions for purpose of practicing an Organizational
Partner’s standard which incorporates this contribution. This document has been prepared
by Lucent Technologies to assist the development of specifications by 3GPP2. It is
proposed to the Committee as a basis for discussion and is not to be construed as a
binding proposal on Lucent Technologies. Lucent Technologies specifically reserves the
right to amend or modify the material contained herein and nothing herein shall be
construed as conferring or offering licenses or rights with respect to any intellectual
property of Lucent Technologies other than provided in the copyright statement above.
5.8.3 EAP TLS
In the flow given in the following figure, the MS (the EAP supplicant) and the H-AAA (the authentication
server), will establish a Master Session Key (MSK, called the master_secret in TLS) that the MS calculates
and the H-AAA distributes to the PDIF (the authenticator).
1. A pre_master_secret is calculated from a pre-shared secret known by the MS and the H-AAA.
2. The pre_master_secret along with other data exchanged between the MS and the H-AAA is then
used by the MS and H-AAA to calculate the master_secret.
master_secret = Psuedo_Random_Function(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random) (RFC 2246 Section 8.1)
3. The MSK is then used by the PDIF and the MS to authenticate the previously sent IKEv2
messages and as key material for the IPsec security association established via IKEv2.
MS
0
1
PDIF
IKE_SA_INIT
IKE_AUTH Request
[EAP Response Identity, SAs, Traffic Selectors]
2
3
4
5
6
EAP_Response Identity
[EAP Response Identity, SAs, Traffic Selectors]
EAP Request
IKE_AUTH Response
[EAP-Type = EAP-TLS, TLS Start]
EAP_Request[EAP-Type = EAP-TLS, TLS Start]
IKE_AUTH Request
EAP Response
EAP Response[TLS client_hello]
[TLS client_hello]
EAP Request
7
8
H-AAA
IKE_AUTH Response
TLS server_hello, TLS_server_key_exchange,
TLS_server_hello_done
TLS server_hello, TLS_server_key_exchange,
TLS_server_hello_done
9
10
11
12
13
14
15
16
IKE_AUTH Request
EAP Response[TLS_client_key_exchange,
TLS_change_cipher_spec, TLS finished]
IKE_AUTH Response
EAP Response
[TLS_client_key_exchange,
TLS_change_cipher_spec, TLS finished]
EAP Request
[TLS_change_cipher_spec, TLS finished]
[TLS_change_cipher_spec, TLS finished]
IKE_AUTH Request
EAP Response
EAP Response
EAP Success
IKE_AUTH Response
EAP Success, SAs, Traffic Selectors
(Editor’s note: After step 16, add two steps EAP-AKA call flow 10 and 11 in Support
File from QC.)
0. The MS and the PDIF exchange IKE_SA_INIT messages.
1. The MS initiates IKE_AUTH exchange with the PDIF. The MS shall include its
identity in an IKE_AUTH request so that the Authentication Server can determine
the authentication method to be used.
2. When the PDIF receives the IKE_AUTH request it shall send the EAP Response
Identity to the H-AAA server, containing the user identity and the IP Service
Identifier. If DIAMETER is used Diameter-EAP-Request (DER) Command [RFC
4072] or AA-Request message [RFC 4005] is used. If RADIUS is used a RADIUS
Access-Request message including a RADIUS EAP message [RFC 3579] is used.
3. The H-AAA verifies the identity and decides what type of authentication is
suitable based on the user profile. If it determines that EAP-TLS is the preferred
method, the H-AAA will send a TLS-Start as an indication that the client should
begin the TLS negotiation process. If DIAMETER is used Diameter-EAP-Answer
(DEA) Command [RFC 4072] or AA-Answer message [RFC 4005] is used. If
RADIUS is used a RADIUS Access-Response message including a RADIUS EAP
message [RFC 3579] is used.
4. The PDIF shall send an IKE_AUTH Response that contains the EAPRequest/TLS-Start message received from the H-AAA, to the MS.
5. The MS responds by sending the TLS EAP Response containing a ClientHello
message to the PDIF via an IKE_AUTH Request. The ClientHello message includes
a NULL session identifier (to be set by the server). The MS shall indicate its
willingness to use pre-shared key authentication by including one or more of the
supported PSK cipher-suites in the Client Hello TLS record. The MS will also include
an optional compression method indication and 28 random bytes.
6. The PDIF forwards the EAP response to the H-AAA in the appropriate Diameter
or Radius message.
7. The H-AAA examines the parameters sent by the MS. In response it sends an
EAP Response containing a TLS ServerHello message to indicate that it was able to
identify an acceptable (set of) algorithms from the set sent by the MS, identifies the
highest mutually acceptable TLS version, its own set of random bytes, a session_id to
identify the new session, a single cipher-suite from the list sent in the ClientHello,
and the single compression method from the list in the ClientHello. The H-AAA may
also send a TLS server_key_exchange message providing a hint to the client about
which identity to use in selecting the Pre-shared secret. Finally, the server hello done
message is sent by the server to indicate the end of the server hello and associated
messages.
8. The PDIF shall send an IKE_AUTH Response that contains the EAPRequest/TLS ClientHello and associated messages received from the H-AAA, to the
MS. The MS can now calculate the master secret using the random values from the
calculated premaster secret, and the client.hello and server.hello messages.
9. The MS responds by sending an IKE_AUTH Request containing an EAP
Response message. The EAP Response message will contain the identity of the Preshared Secret in the TLS client_key_exchange message. The MS also includes the
change_cipher_spec message indicating that subsequent data will be sent using the
agreed upon key and cipher suites. Finally the MS includes the TLS finished
message. The finished message is first protected with the just-negotiated algorithms,
key, and secrets. Recipients of finished messages must verify that the contents are
correct.
10. The PDIF forwards the EAP response to the H-AAA in the appropriate Diameter
or Radius message.
11. The H-AAA can now calculate the master_secret. The H-AAA verifies the TLS
finished message from the MS. If it verifies correctly, the H-AAA sends an EAP
Request containing the change_cipher_spec message and a finished message. The
message is sent to the PDIF along with the master_secret.
12. The PDIF encapsulates the EAP Request in an IKE_AUTH Response message
and forwards the message to the MS.
13. The MS will verify the TLS Finished message from the server and if it is correct
will send an EAP Response message to the server containing no data. The MS shall
use the master_secret as input to generate the AUTH parameter to authenticate the
previously sent IKEv2 messages. The AUTH parameter is sent to the PDIF in an
IKE_AUTH Request message along with the EAP Response message.
14. The PDIF verifies the AUTH parameter. The PDIF sends the EAP response to
the H-AAA.
15. The H-AAA sends an EAP Success message to the PDIF. The PDIF calculates
the AUTH parameter, which authenticates the previously sent IKEv2 messages.
16. PDIF sends the EAP-Success message in the IKE AUTH response.