Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4851

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)

Pages: 64
Informational
Errata
Updated by:  8996
Part 3 of 3 – Pages 44 to 64
First   Prev   None

Top   ToC   RFC4851 - Page 44   prevText

8. Acknowledgements

The EAP-FAST design and protocol specification is based on the ideas and hard efforts of Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc. The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, and Simon Josefsson. Helpful review comments were provided by Russ Housley, Jari Arkko, Bernard Aboba, Ilan Frenkel, and Jeremy Steiglitz.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006.
Top   ToC   RFC4851 - Page 45

9.2. Informative References

[EAP-PROV] Cam-Winget, N., "Dynamic Provisioning using EAP- FAST", Work in Progress, January 2007. [IEEE.802-1X.2004] "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004. [NIST.SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006.
Top   ToC   RFC4851 - Page 46

Appendix A. Examples

In the following examples the version field in EAP Fast is always assumed to be 1. The S, M, and L bits are assumed to be 0 unless otherwise specified.

A.1. Successful Authentication

The following exchanges show a successful EAP-FAST authentication with optional PAC refreshment; the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque in SessionTicket extension)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/EAP-FAST (TLS change_cipher_spec, TLS finished) -> TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST) <- EAP Payload TLV (EAP-Request/EAP-GTC(Challenge)) EAP Payload TLV (EAP-Response/ EAP-GTC(Response with both user name and password)) -> optional additional exchanges (new pin mode, password change etc.) ...
Top   ToC   RFC4851 - Page 47
                               <- Intermediate-Result TLV (Success)
                                  Crypto-Binding TLV (Request)


       Intermediate-Result TLV (Success)
       Crypto-Binding TLV(Response) ->

                                <- Result TLV (Success)
                                  [Optional PAC TLV]

       Result TLV (Success)
       [PAC TLV Acknowledgment] ->

       TLS channel torn down
       (messages sent in clear text)

                               <- EAP-Success

A.2. Failed Authentication

The following exchanges show a failed EAP-FAST 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-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque in SessionTicket extension)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/EAP-FAST (TLS change_cipher_spec, TLS finished) ->
Top   ToC   RFC4851 - Page 48
       TLS channel established
       (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

                              <- EAP Payload TLV (EAP-Request/
                                EAP-GTC (Challenge))

       EAP Payload TLV (EAP-Response/
       EAP-GTC (Response with both
       user name and password)) ->

                              <- EAP Payload TLV (EAP-Request/
                                EAP-GTC (error message))

       EAP Payload TLV (EAP-Response/
       EAP-GTC (empty data packet to
       acknowledge unrecoverable error)) ->

                               <- Result TLV (Failure)

       Result TLV (Failure) ->

       TLS channel torn down
       (messages sent in clear text)

                               <- EAP-Failure

A.3. Full TLS Handshake using Certificate-based Ciphersuite

In the case where an abbreviated TLS handshake is tried and failed, and a fallback to certificate-based full TLS handshake occurs within EAP-FAST Phase 1, 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-FAST (S=1, A-ID)
Top   ToC   RFC4851 - Page 49
      EAP-Response/EAP-FAST
      (TLS client_hello
       with PAC-Opaque extension)->

      // Peer sends PAC-Opaque of Tunnel PAC along with a list of
         ciphersuites supported.  If the server rejects the PAC-
         Opaque, it falls through to the full TLS handshake

                              <- EAP-Request/EAP-FAST
                              (TLS server_hello,
                               TLS certificate,
                              [TLS server_key_exchange,]
                              [TLS certificate_request,]
                               TLS server_hello_done)
      EAP-Response/EAP-FAST
      ([TLS certificate,]
       TLS client_key_exchange,
      [TLS certificate_verify,]
       TLS change_cipher_spec,
       TLS finished) ->
                              <- EAP-Request/EAP-FAST
                              (TLS change_cipher_spec,
                               TLS finished,
                               EAP-Payload-TLV
                               (EAP-Request/Identity))

      // TLS channel established
         (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

      // First EAP Payload TLV is piggybacked to 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/Method X)

      EAP-Payload-TLV
      (EAP-Response/Method X) ->
Top   ToC   RFC4851 - Page 50
      // Method X exchanges followed by Protected Termination

                               <- Crypto-Binding TLV (Version=1,
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               Result TLV (Success)

      Crypto-Binding TLV (Version=1,
      EAP-FAST Version=1, Nonce,
      CompoundMAC),
      Result-TLV (Success) ->

      // TLS channel torn down
      (messages sent in clear text)

                              <- EAP-Success

A.4. Client Authentication during Phase 1 with Identity Privacy

In the case where a certificate-based TLS handshake occurs within EAP-FAST Phase 1, and client certificate authentication and identity privacy is desired, 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-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/EAP-FAST (TLS client_key_exchange, TLS change_cipher_spec, TLS finished) ->
Top   ToC   RFC4851 - Page 51
                              <- EAP-Request/EAP-FAST
                              (TLS change_cipher_spec,
                               TLS finished,TLS Hello-Request)

      // TLS channel established
         (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

      // TLS Hello-Request is piggybacked to the TLS Finished as
         Handshake Data and protected by the TLS tunnel

      // Subsequent messages are protected by the TLS Tunnel

      EAP-Response/EAP-FAST
      (TLS client_hello) ->


                              <- EAP-Request/EAP-FAST
                               (TLS server_hello,
                               TLS certificate,
                               [TLS server_key_exchange,]
                               [TLS certificate_request,]
                               TLS server_hello_done)
      EAP-Response/EAP-FAST
      ([TLS certificate,]
       TLS client_key_exchange,
      [TLS certificate_verify,]
       TLS change_cipher_spec,
       TLS finished) ->

                              <- EAP-Request/EAP-FAST
                                (TLS change_cipher_spec,
                                 TLS finished,
                                 Result TLV (Success))

      EAP-Response/EAP-FAST
      (Result-TLV (Success)) ->

      //TLS channel torn down
      (messages sent in clear text)

                              <- EAP-Success
Top   ToC   RFC4851 - Page 52

A.5. Fragmentation and Reassembly

In the case where EAP-FAST fragmentation is required, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (L=1,M=1, TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,]) EAP-Response/EAP-FAST -> <- EAP-Request/EAP-FAST (M=1, [TLS certificate_request(con't),]) EAP-Response/EAP-FAST -> <- EAP-Request/EAP-FAST ([TLS certificate_request(con't),] TLS server_hello_done) EAP-Response/EAP-FAST, (L=1,M=1,[TLS certificate,])-> <- EAP-Request/EAP-FAST EAP-Response/EAP-FAST ([TLS certificate(con't),] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished))-> <- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
Top   ToC   RFC4851 - Page 53
      // TLS channel established
         (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

      // First EAP Payload TLV is piggybacked to 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/Method X)

      EAP-Payload-TLV
      (EAP-Response/Method X) ->

      // Method X exchanges followed by Protected Termination

                               <- Crypto-Binding TLV (Version=1,
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               Result TLV (Success)

      Crypto-Binding TLV (Version=1,
      EAP-FAST Version=1, Nonce,
      CompoundMAC),
      Result-TLV (Success) ->

      // TLS channel torn down
      (messages sent in clear text)

                              <- EAP-Success

A.6. Sequence of EAP Methods

Where EAP-FAST 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-FAST (S=1, A-ID)
Top   ToC   RFC4851 - Page 54
      EAP-Response/EAP-FAST
      (TLS client_hello)->
                              <- EAP-Request/EAP-FAST
                              (TLS server_hello,
                               TLS certificate,
                              [TLS server_key_exchange,]
                              [TLS certificate_request,]
                               TLS server_hello_done)
      EAP-Response/EAP-FAST
      ([TLS certificate,]
       TLS client_key_exchange,
      [TLS certificate_verify,]
       TLS change_cipher_spec,
       TLS finished) ->
                             <- EAP-Request/EAP-FAST
                              (TLS change_cipher_spec,
                               TLS finished,
                              EAP-Payload-TLV(
                              EAP-Request/Identity))

      // TLS channel established
         (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

      // First EAP Payload TLV is piggybacked to the TLS Finished as
         Application Data and protected by the TLS tunnel

      EAP-Payload-TLV
      (EAP-Response/Identity) ->

                              <- EAP-Payload-TLV
                               (EAP-Request/Method X)

      EAP-Payload-TLV
      (EAP-Response/Method X) ->

             // Optional additional X Method exchanges...

                             <- EAP-Payload-TLV
                              (EAP-Request/Method X)

      EAP-Payload-TLV
      (EAP-Response/EAP-Type X)->
Top   ToC   RFC4851 - Page 55
                              <- Intermediate Result TLV (Success),
                               Crypto-Binding TLV (Version=1
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               EAP Payload TLV (EAP-Request/Method Y)

      // Next EAP conversation started after successful completion
         of previous method X.  The Intermediate-Result and Crypto-
         Binding TLVs are sent in this packet to minimize round-
         trips.  In this example, identity request is not sent
         before negotiating EAP-Type=Y.

      // Compound MAC calculated using Keys generated from
         EAP methods X and the TLS tunnel.

      Intermediate Result TLV (Success),
      Crypto-Binding TLV (Version=1,
      EAP-FAST Version=1, Nonce,
      CompoundMAC),
      EAP-Payload-TLV (EAP-Response/Method Y) ->

             // Optional additional Y Method exchanges...

                             <- EAP Payload TLV
                               (EAP-Request/Method Y)

      EAP Payload TLV
      (EAP-Response/Method Y) ->

                             <- Intermediate-Result-TLV (Success),
                               Crypto-Binding TLV (Version=1
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               Result TLV (Success)

      Intermediate-Result-TLV (Success),
      Crypto-Binding TLV (Version=1,
      EAP-FAST Version=1, Nonce,
      CompoundMAC),
      Result-TLV (Success) ->

      // Compound MAC calculated using Keys generated from EAP
         methods X and Y and the TLS tunnel.  Compound Keys
         generated using Keys generated from EAP methods X and Y;
         and the TLS tunnel.
Top   ToC   RFC4851 - Page 56
      // TLS channel torn down (messages sent in clear text)

                              <- EAP-Success

A.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-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello without PAC-Opaque extension)-> <- EAP-Request/EAP-FAST (TLS Server Key Exchange, TLS Server Hello Done) EAP-Response/EAP-FAST (TLS Client Key Exchange, TLS change_cipher_spec, TLS finished)-> <- EAP-Request/EAP-FAST (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 piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel EAP-Payload TLV (EAP-Response/Identity) -> <- EAP Payload TLV (EAP-Request/ EAP-MSCHAPV2 (Challenge)) EAP Payload TLV (EAP-Response/ EAP-MSCHAPV2 (Response)) ->
Top   ToC   RFC4851 - Page 57
                          <-  EAP Payload TLV  (EAP-Request/
                              EAP-MSCHAPV2  (Success Request))

   EAP Payload TLV  (EAP-Response/
   EAP-MSCHAPV2 (Success Response)) ->

                            <- Crypto-Binding TLV (Version=1,
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               Result TLV (Success)

      Result TLV (Failure),
      Error TLV (Error Code = 2001) ->

   // TLS channel torn down
      (messages sent in clear text)

                           <- EAP-Failure

A.8. Sequence of EAP Method with Vendor-Specific TLV Exchange

Where EAP-FAST is negotiated, with a sequence of EAP method followed by Vendor-Specific TLV exchange, the conversation will occur as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)
Top   ToC   RFC4851 - Page 58
      EAP-Response/EAP-FAST
      ([TLS certificate,]
       TLS client_key_exchange,
      [TLS certificate_verify,]
       TLS change_cipher_spec,
       TLS finished) ->
                             <- EAP-Request/EAP-FAST
                              (TLS change_cipher_spec,
                               TLS finished,
                               EAP-Payload-TLV
                               (EAP-Request/Identity))

      // TLS channel established
         (Subsequent messages sent within the TLS channel,
                                  encapsulated within EAP-FAST)

      // First EAP Payload TLV is piggybacked to the TLS Finished as
         Application Data and protected by the TLS tunnel

      EAP-Payload-TLV
      (EAP-Response/Identity) ->

                            <- EAP-Payload-TLV
                            (EAP-Request/Method X)

      EAP-Payload-TLV
      (EAP-Response/Method X) ->

                             <- EAP-Payload-TLV
                            (EAP-Request/Method X)

      EAP-Payload-TLV
      (EAP-Response/Method X)->

                              <- Intermediate Result TLV (Success),
                               Crypto-Binding TLV (Version=1
                               EAP-FAST Version=1, Nonce,
                               CompoundMAC),
                               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 this packet to minimize round-trips.

      // Compound MAC calculated using Keys generated from
         EAP methods X and the TLS tunnel.
Top   ToC   RFC4851 - Page 59
      Intermediate Result TLV (Success),
      Crypto-Binding TLV (Version=1,
      EAP-FAST Version=1, Nonce,
      CompoundMAC),
      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 clear text)

                              <- EAP-Success
Top   ToC   RFC4851 - Page 60

Appendix B. Test Vectors

B.1. Key Derivation

PAC KEY: 0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14 Server_hello Random 3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A Client_hello Random 00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00 Master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", server_random + Client_random, 48) 4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29 38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2 Key_block = PRF(Master_secret, "key expansion", server_random + Client_random) 59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44 11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71 Session Key Seed D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
Top   ToC   RFC4851 - Page 61
       IMCK = T-PRF(SKS,
                    "Inner Methods Compound Keys",
                    ISK,
                    60)

              Note: ISK is 32 octets 0's.

       16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
       4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
       18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9
       04 D0 69 56 72 8B 6B B8 15 EC 57 7B

       [SIMCK 1]
       16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
       4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
       18 40 7B 56 BE EA A7 C5


       MSK = T-PRF(S-IMCKn,
                   "Session Key Generating Function",
                    64);

       4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33
       C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9
       27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49
       67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3


       EMSK = T-PRF(S-IMCKn,
                    "Extended Session Key Generating Function",
                    64);

       3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55
       EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9
       76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A
       2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9
Top   ToC   RFC4851 - Page 62

B.2. Crypto-Binding MIC

[Compound MAC Key 1] 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 15 EC 57 7B [Crypto-Binding TLV] 80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7 [Server Nonce] D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 [Compound MAC] 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
Top   ToC   RFC4851 - Page 63

Authors' Addresses

Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US EMail: ncamwing@cisco.com David McGrew Cisco Systems San Jose, CA 95134 US EMail: mcgrew@cisco.com Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US EMail: jsalowey@cisco.com Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US EMail: hzhou@cisco.com
Top   ToC   RFC4851 - Page 64
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.