Appendix C. Examples
この節では TEAPv1 の RFC 原文を保持し, TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations, examples を含めます.
Appendix C. Examples
C.1. Successful Authentication
The following exchanges show a successful TEAP authentication with
basic password authentication. The conversation will appear as
follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV(Response),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.2. Failed Authentication
The following exchanges show a failed TEAP authentication due to
wrong user credentials. The conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
<- Intermediate-Result TLV (Failure),
Result TLV (Failure)
Intermediate-Result TLV (Failure),
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
C.3. Full TLS Handshake Using Certificate-Based Cipher Suite
In the case within TEAP Phase 1 where an abbreviated TLS handshake is
tried, fails, and falls back to the certificate-based full TLS
handshake, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello with
SessionTicket extension)->
// If the server rejects the session resumption,
it falls through to the full TLS handshake.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.4. Client Authentication During Phase 1 with Identity Privacy
In the case where a certificate-based TLS handshake occurs within
TEAP Phase 1 and client certificate authentication and identity
privacy is desired (and therefore TLS renegotiation is being used to
transmit the peer credentials in the protected TLS tunnel), the
conversation will appear as follows for TLS 1.2:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(EAP Payload messages sent within the TLS channel)
// peer sends TLS client_hello to request TLS renegotiation
TLS client_hello ->
<- TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success)
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
//TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.5. Fragmentation and Reassembly
In the case where TEAP fragmentation is required, the conversation
will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 3)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)->
<- EAP-Request/
EAP-Type=TEAP, V=1
EAP-Response/
EAP-Type=TEAP, V=1
(Fragment 2)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
[EAP-Payload TLV[
EAP-Request/Identity]])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.6. Sequence of EAP Methods
When TEAP is negotiated with a sequence of EAP method X followed by
method Y, the conversation will occur as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel
Identity_Type TLV
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Optional additional X Method exchanges...
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
// Next EAP conversation started (with EAP-Request/Identity)
after successful completion of previous method X. The
Intermediate-Result and Crypto-Binding TLVs are sent in
the next packet to minimize round trips.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
EAP-Payload TLV [EAP-Response/Identity (MyID2)] ->
// Optional additional EAP method Y exchanges...
<- EAP Payload TLV [
EAP-Type=Y]
EAP Payload TLV
[EAP-Type=Y] ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// Compound MAC calculated using keys generated from EAP
methods X and Y and the TLS tunnel. Compound keys are
generated using keys generated from EAP methods X and Y
and the TLS tunnel.
// TLS channel torn down (messages sent in cleartext)
<- EAP-Success
C.7. Failed Crypto-Binding
The following exchanges show a failed crypto-binding validation. The
conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV/
EAP Identity Response ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Challenge)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Response) ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Success Request)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Success Response) ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Result TLV (Failure)
Error TLV with
(Error Code = 2001) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
When TEAP is negotiated with a sequence of EAP methods followed by a
Vendor-Specific TLV exchange, the conversation will occur as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Vendor-Specific TLV,
// Vendor-Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor-Specific TLV
in next packet to minimize round trips.
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Vendor-Specific TLV ->
// Optional additional Vendor-Specific TLV exchanges...
<- Vendor-Specific TLV
Vendor-Specific TLV ->
<- Result TLV (Success)
Result TLV (Success) ->
// TLS channel torn down (messages sent in cleartext)
<- EAP-Success
C.9. Peer Requests Inner Method After Server Sends Result TLV
In the case where the peer is authenticated during Phase 1 and the
server sends back a Result TLV but the peer wants to request another
Inner Method, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity. TLS client certificate is also sent.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success))
// TLS channel established
(TLV Payload messages sent within the TLS channel)
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Negotiate-EAP)->
<- EAP-Payload TLV
[EAP-Request/Identity]
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.10. Channel Binding
The following exchanges show a successful TEAP authentication with
basic password authentication and channel binding using a Request-
Action TLV. The conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Crypto-Binding TLV (Request),
Result TLV (Success),
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Process TLV,
TLV=Channel-Binding TLV)->
<- Channel-Binding TLV (Response),
Result TLV (Success),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
C.11. PKCS Exchange
The following exchanges show the peer sending a PKCS#10 TLV and
server replying with a PKCS7 TLV. The exchange below assumes that
the EAP peer is authenticated in Phase 1, either via bidirectional
certificate exchange or some other TLS method such as a proof of
knowledge (TLS-POK). The conversation will appear as follows:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS change_cipher_spec, |
| TLS certificate, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Send Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Send PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Sign the CSR and send PKCS7 TLV Intermediate-Result|
| TLV request(Success), |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Success), |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
C.12. Failure Scenario
The following exchanges show a failure scenario. The conversation
will appear as follows:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, V=1 |
| (TEAP Start, S bit set, Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, V=1 |
| (TLS server_hello,(TLS change_cipher_spec, TLS finished)|
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1 |
| (TLS change_cipher_spec, |
| TLS finished) |
| TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Bad PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Intermediate-Result TLV request(Failure), |
| Result TLV(Failure) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Failure), |
| Result TLV(Failure) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Failure |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
C.13. Client Certificate in Phase 1
The following exchanges show a scenario where the client certificate
is sent in Phase 1 and no additional authentication or provisioning
is performed in Phase 2. The conversation will appear as follows:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS change_cipher_spec, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS certificate, |
| TLS change_cipher_spec, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - -