tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4851

 
 
 

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

Part 3 of 3, p. 44 to 64
Prev RFC Part

 


prevText      Top      Up      ToC       Page 44 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.