Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5247

Extensible Authentication Protocol (EAP) Key Management Framework

Pages: 79
Proposed Standard
Errata
Updates:  3748
Updated by:  8940
Part 4 of 4 – Pages 60 to 79
First   Prev   None

Top   ToC   RFC5247 - Page 60   prevText

5.5. Authorization

Requirement: The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so that binding between the EAP and Secure Association Protocol identities is REQUIRED. Mandatory requirement from [RFC4962] Section 3: Peer and authenticator authorization Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED
Top   ToC   RFC5247 - Page 61
      whenever a peer associates with a new authenticator.  The
      authorization checking prevents an elevation of privilege attack,
      and it ensures that an unauthorized authenticator is detected.

      Authorizations SHOULD be synchronized between the peer, NAS, and
      backend authentication server.  Once the AAA key management
      protocol exchanges are complete, all of these parties should hold
      a common view of the authorizations associated with the other
      parties.

      In addition to authenticating all parties, key management
      protocols need to demonstrate that the parties are authorized to
      possess keying material.  Note that proof of possession of keying
      material does not necessarily prove authorization to hold that
      keying material.  For example, within an IEEE 802.11, the 4-way
      handshake demonstrates that both the peer and authenticator
      possess the same EAP keying material.  However, by itself, this
      possession proof does not demonstrate that the authenticator was
      authorized by the backend authentication server to possess that
      keying material.  As noted in [RFC3579] in Section 4.3.7, where
      AAA proxies are present, it is possible for one authenticator to
      impersonate another, unless each link in the AAA chain implements
      checks against impersonation.  Even with these checks in place, an
      authenticator may still claim different identities to the peer and
      the backend authentication server.  As described in [RFC3748]
      Section 7.15, channel binding is required to enable the peer to
      verify that the authenticator claim of identity is both consistent
      and correct.

   Recommendation from [RFC4962] Section 3:

      Authorization restriction

      If peer authorization is restricted, then the peer SHOULD be made
      aware of the restriction.  Otherwise, the peer may inadvertently
      attempt to circumvent the restriction.  For example, authorization
      restrictions in an IEEE 802.11 environment include:

      o  Key lifetimes, where the keying material can only be used for a
         certain period of time;

      o  SSID restrictions, where the keying material can only be used
         with a specific IEEE 802.11 SSID;

      o  Called-Station-ID restrictions, where the keying material can
         only be used with a single IEEE 802.11 BSSID; and
Top   ToC   RFC5247 - Page 62
      o  Calling-Station-ID restrictions, where the keying material can
         only be used with a single peer IEEE 802 MAC address.

   As described in Section 2.3, consistent identification of the EAP
   authenticator enables the EAP peer to determine the scope of keying
   material provided to an authenticator, as well as to confirm with the
   backend authentication server that an EAP authenticator proving
   possession of EAP keying material during the Secure Association
   Protocol was authorized to obtain it.

   Within the AAA protocol, the authorization attributes are bound to
   the transported keying material.  While the AAA exchange provides the
   AAA client/authenticator with authorizations relating to the EAP
   peer, neither the EAP nor AAA exchanges provide authorizations to the
   EAP peer.  In order to ensure that all parties hold the same view of
   the authorizations, it is RECOMMENDED that the Secure Association
   Protocol enable communication of authorizations between the EAP
   authenticator and peer.

   In lower layers where the authenticator consistently identifies
   itself to the peer and backend authentication server and the EAP peer
   completes the Secure Association Protocol exchange with the same
   authenticator through which it completed the EAP conversation,
   authorization of the authenticator is demonstrated to the peer by
   mutual authentication between the peer and authenticator as discussed
   in the previous section.  Identification issues are discussed in
   Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in
   Section 3.2.

   Where the EAP peer utilizes different identifiers within the EAP
   method and Secure Association Protocol conversations, peer
   authorization can be difficult to demonstrate to the authenticator
   without additional restrictions.  This problem does not exist in
   IKEv2 where the Identity Payload is used for peer identification both
   within IKEv2 and EAP, and where the EAP conversation is
   cryptographically protected within IKEv2 binding the EAP and IKEv2
   exchanges.  However, within [IEEE-802.11], the EAP peer identity is
   not used within the 4-way handshake, so that it is necessary for the
   authenticator to require that the EAP peer utilize the same MAC
   address for EAP authentication as for the 4-way handshake.
Top   ToC   RFC5247 - Page 63

5.6. Replay Protection

Mandatory requirement from [RFC4962] Section 3: Replay detection mechanism The AAA key management protocol exchanges MUST be replay protected, including AAA, EAP and Secure Association Protocol exchanges. Replay protection allows a protocol message recipient to discard any message that was recorded during a previous legitimate dialogue and presented as though it belonged to the current dialogue. [RFC3748] Section 7.2.1 describes the "replay protection" security claim, and [RFC4017] Section 2.2 requires use of EAP methods supporting this claim. Diameter [RFC3588] provides support for replay protection via use of IPsec or TLS. "RADIUS Support for EAP" [RFC3579] protects against replay of keying material via the Request Authenticator. According to [RFC2865] Section 3: In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. However, some RADIUS packets are not replay protected. In Accounting, Disconnect, and Care-of Address (CoA)-Request packets, the Request Authenticator contains a keyed Message Integrity Code (MIC) rather than a nonce. The Response Authenticator in Accounting, Disconnect, and CoA-Response packets also contains a keyed MIC whose calculation does not depend on a nonce in either the Request or Response packets. Therefore, unless an Event-Timestamp attribute is included or IPsec is used, it is possible that the recipient will not be able to determine whether these packets have been replayed. This issue is discussed further in [RFC5176] Section 6.3. In order to prevent replay of Secure Association Protocol frames, replay protection is REQUIRED on all messages. [IEEE-802.11] supports replay protection on all messages within the 4-way handshake; IKEv2 [RFC4306] also supports this.
Top   ToC   RFC5247 - Page 64

5.7. Key Freshness

Requirement: A session key SHOULD be considered compromised if it remains in use beyond its authorized lifetime. Mandatory requirement from [RFC4962] Section 3: Strong, fresh session keys While preserving algorithm independence, session keys MUST be strong and fresh. Each session deserves an independent session key. Fresh keys are required even when a long replay counter (that is, one that "will never wrap") is used to ensure that loss of state does not cause the same counter value to be used more than once with the same session key. Some EAP methods are capable of deriving keys of varying strength, and these EAP methods MUST permit the generation of keys meeting a minimum equivalent key strength. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached. A cached key persists after the authentication exchange has completed. For the AAA/EAP server, key caching can happen when state is kept on the server. For the NAS or client, key caching can happen when the NAS or client does not destroy keying material immediately following the derivation of session keys. Session keys MUST NOT be dependent on one another. Multiple session keys may be derived from a higher-level shared secret as long as a one-time value, usually called a nonce, is used to ensure that each session key is fresh. The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys. EAP, AAA, and the lower layer each bear responsibility for ensuring the use of fresh, strong session keys. EAP methods need to ensure the freshness and strength of EAP keying material provided as an input to session key derivation. [RFC3748] Section 7.10 states:
Top   ToC   RFC5247 - Page 65
      EAP methods SHOULD ensure the freshness of the MSK and EMSK, even
      in cases where one party may not have a high quality random number
      generator.  A RECOMMENDED method is for each party to provide a
      nonce of at least 128 bits, used in the derivation of the MSK and
      EMSK.

   The contribution of nonces enables the EAP peer and server to ensure
   that exported EAP keying material is fresh.

   [RFC3748] Section 7.2.1 describes the "key strength" and "session
   independence" security claims, and [RFC4017] requires EAP methods
   supporting these claims as well as methods capable of providing
   equivalent key strength of 128 bits or greater.  See Section 3.7 for
   more information on key strength.

   The AAA protocol needs to ensure that transported keying material is
   fresh and is not utilized outside its recommended lifetime.  Replay
   protection is necessary for key freshness, but an attacker can
   deliver a stale (and therefore potentially compromised) key in a
   replay-protected message, so replay protection is not sufficient.  As
   discussed in Section 3.5, the Session-Timeout Attribute enables the
   backend authentication server to limit the exposure of transported
   keying material.

   The EAP Session-Id, described in Section 1.4, enables the EAP peer,
   authenticator, and server to distinguish EAP conversations.  However,
   unless the authenticator keeps track of EAP Session-Ids, the
   authenticator cannot use the Session-Id to guarantee the freshness of
   keying material.

   The Secure Association Protocol, described in Section 3.1, MUST
   generate a fresh session key for each session, even if the EAP keying
   material and parameters provided by methods are cached, or either the
   peer or authenticator lack a high entropy random number generator.  A
   RECOMMENDED method is for the peer and authenticator to each provide
   a nonce or counter used in session key derivation.  If a nonce is
   used, it is RECOMMENDED that it be at least 128 bits.  While
   [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement,
   [IEEE-802.16e] does not, since randomness is only contributed from
   the Base Station.
Top   ToC   RFC5247 - Page 66

5.8. Key Scope Limitation

Mandatory requirement from [RFC4962] Section 3: Limit key scope Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it. Any protocol that is used to establish session keys MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available. Transported keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive EAP keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol exchange, the EAP peer utilizes keying material to demonstrate to the authenticator that it is the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator utilizes the transported keying material to prove to the peer not only that the EAP conversation was transported through it (this could be demonstrated by a man-in-the-middle), but that it was uniquely authorized by the EAP server to provide the peer with access to the network. Unique authorization can only be demonstrated if the EAP authenticator does not share the transported keying material with a party other than the EAP peer and server. TSKs are permitted to be accessed only by the EAP peer and authenticator (see Section 1.5); TSK derivation is discussed in Section 2.1. Since demonstration of authorization within the Secure Association Protocol exchange depends on possession of transported keying material, the backend authentication server can obtain TSKs unless it deletes the transported keying material after sending it.

5.9. Key Naming

Mandatory requirement from [RFC4962] Section 3: Uniquely named keys AAA key management proposals require a robust key naming scheme, particularly where key caching is supported. The key name provides a way to refer to a key in a protocol so that it is clear to all parties which key is being referenced. Objects that cannot be named cannot be managed. All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying
Top   ToC   RFC5247 - Page 67
      material.  If the key name is not based on the keying material,
      then one can be sure that it cannot be used to assist in a search
      for the key value.

   EAP key names (defined in Section 1.4.1), along with the Peer-Id(s)
   and Server-Id(s), uniquely identify EAP keying material, and do not
   directly or indirectly expose EAP keying material.

   Existing AAA server implementations do not distribute key names along
   with the transported keying material.  However, Diameter EAP
   [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose
   of transporting the EAP Session-Id.  Since the EAP-Key-Name AVP is
   defined within the RADIUS attribute space, it can be used either with
   RADIUS or Diameter.

   Since the authenticator is not provided with the name of the
   transported keying material by existing backend authentication server
   implementations, existing Secure Association Protocols do not utilize
   EAP key names.  For example, [IEEE-802.11] supports PMK caching; to
   enable the peer and authenticator to determine the cached PMK to
   utilize within the 4-way handshake, the PMK needs to be named.  For
   this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is
   based on the key.  Since IKEv2 [RFC4306] does not cache transported
   keying material, it does not need to refer to transported keying
   material.

5.10. Denial-of-Service Attacks

Key caching can result in vulnerability to denial-of-service attacks. For example, EAP methods that create persistent state can be vulnerable to denial-of-service attacks on the EAP server by a rogue EAP peer. To address this vulnerability, EAP methods creating persistent state can limit the persistent state created by an EAP peer. For example, for each peer an EAP server can choose to limit persistent state to a few EAP conversations, distinguished by the EAP Session-Id. This prevents a rogue peer from denying access to other peers. Similarly, to conserve resources an authenticator can choose to limit the persistent state corresponding to each peer. This can be accomplished by limiting each peer to persistent state corresponding to a few EAP conversations, distinguished by the EAP Session-Id. Whether creation of new TSKs implies deletion of previously derived TSKs depends on the EAP lower layer. Where there is no implied deletion, the authenticator can choose to limit the number of TSKs and associated state that can be stored for each peer.
Top   ToC   RFC5247 - Page 68

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.

6.2. Informative References

[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1x Model", Proceedings of the IFIP TC6/WG6.8 Working Conference on Personal Wireless Communications, p.175-182, October 23-25, 2002. [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way Handshake", Proceedings of the 2004 ACM Workshop on Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. [Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, H. and P. Schoo, "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs", Proceedings of the 2nd ACM international workshop on Wireless mobile applications and services on WLAN hotspots, October, 2004. [GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group Key Distribution Protocol", Work in Progress, March 2006. [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. Mitchell, "A Modular Correctness Proof of TLS and IEEE 802.11i", ACM Conference on Computer and Communications Security (CCS '05), November, 2005.
Top   ToC   RFC5247 - Page 69
   [IEEE-802.11]  Institute of Electrical and Electronics Engineers,
                  "Information technology - Telecommunications and
                  information exchange between systems - Local and
                  metropolitan area networks - Specific Requirements
                  Part 11:  Wireless LAN Medium Access Control (MAC) and
                  Physical Layer (PHY) Specifications", IEEE Standard
                  802.11-2007, 2007.

   [IEEE-802.1X]  Institute of Electrical and Electronics Engineers,
                  "Local and Metropolitan Area Networks: Port-Based
                  Network Access Control", IEEE Standard 802.1X-2004,
                  December 2004.

   [IEEE-802.1Q]  IEEE Standards for Local and Metropolitan Area
                  Networks:  Draft Standard for Virtual Bridged Local
                  Area Networks, P802.1Q-2003, January 2003.

   [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
                  "Supplement to Standard for Telecommunications and
                  Information Exchange Between Systems - LAN/MAN
                  Specific Requirements - Part 11: Wireless LAN Medium
                  Access Control (MAC) and Physical Layer (PHY)
                  Specifications:  Specification for Enhanced Security",
                  IEEE 802.11i/D1, 2001.

   [IEEE-802.11F] Institute of Electrical and Electronics Engineers,
                  "Recommended Practice for Multi-Vendor Access Point
                  Interoperability via an Inter-Access Point Protocol
                  Across Distribution Systems Supporting IEEE 802.11
                  Operation", IEEE 802.11F, July 2003 (now deprecated).

   [IEEE-802.16e] Institute of Electrical and Electronics Engineers,
                  "IEEE Standard for Local and Metropolitan Area
                  Networks: Part 16: Air Interface for Fixed and Mobile
                  Broadband Wireless Access Systems: Amendment for
                  Physical and Medium Access Control Layers for Combined
                  Fixed and Mobile Operations in Licensed Bands" IEEE
                  802.16e, August 2005.

   [IEEE-03-084]  Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K.
                  Jang, "Proactive Key Distribution to support fast and
                  secure roaming", IEEE 802.11 Working Group, IEEE-03-
                  084r1-I, http://www.ieee802.org/11/Documents/
                  DocumentHolder/3-084.zip, January 2003.
Top   ToC   RFC5247 - Page 70
   [EAP-SERVICE]  Arkko, J. and P. Eronen, "Authenticated Service
                  Information for the Extensible Authentication Protocol
                  (EAP)", Work in Progress, October 2005.

   [SHORT-TERM]   Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term
                  Certificates", Work in Progress, June 2007.

   [HANDOFF]      Arbaugh, W. and B. Aboba, "Handoff Extension to
                  RADIUS", Work in Progress, October 2003.

   [EAP-CHANNEL]  Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel
                  Binding Mechanism Based on Parameter Binding in Key
                  Derivation", Work in Progress, June 2007.

   [EAP-BINDING]  Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
                  "The Compound Authentication Binding Problem", Work in
                  Progress, October 2003.

   [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
                  Within a Minute", Cryptology ePrint Archive, March
                  2006, http://eprint.iacr.org/2006/105.pdf

   [MishraPro]    Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key
                  Distribution using Neighbor Graphs", IEEE Wireless
                  Communications, vol. 11, February 2004.

   [RFC1661]      Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
                  STD 51, RFC 1661, July 1994.

   [RFC1968]      Meyer, G., "The PPP Encryption Control Protocol
                  (ECP)", RFC 1968, June 1996.

   [RFC2230]      Atkinson, R., "Key Exchange Delegation Record for the
                  DNS", RFC 2230, November 1997.

   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.

   [RFC2516]      Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
                  D., and R. Wheeler, "A Method for Transmitting PPP
                  Over Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
                  Attributes", RFC 2548, March 1999.

   [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
                  Policy Implementation in Roaming", RFC 2607, June
                  1999.
Top   ToC   RFC5247 - Page 71
   [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
                  Protocol", RFC 2716, October 1999.

   [RFC2782]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                  for specifying the location of services (DNS SRV)",
                  RFC 2782, February 2000.

   [RFC2845]      Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
                  Wellington, "Secret Key Transaction Authentication for
                  DNS (TSIG)", RFC 2845, May 2000.

   [RFC2865]      Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                  "Remote Authentication Dial In User Service (RADIUS)",
                  RFC 2865, June 2000.

   [RFC3007]      Wellington, B., "Secure Domain Name System (DNS)
                  Dynamic Update", RFC 3007, November 2000.

   [RFC3162]      Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
                  RFC 3162, August 2001.

   [RFC3547]      Baugher, M., Weis, B., Hardjono, T., and H. Harney,
                  "The Group Domain of Interpretation", RFC 3547, July
                  2003.

   [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
                  Authentication Dial In User Service) Support For
                  Extensible Authentication Protocol (EAP)", RFC 3579,
                  September 2003.

   [RFC3580]      Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
                  Roese, "IEEE 802.1X Remote Authentication Dial In User
                  Service (RADIUS) Usage Guidelines", RFC 3580,
                  September 2003.

   [RFC3588]      Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                  J. Arkko, "Diameter Base Protocol", RFC 3588,
                  September 2003.

   [RFC3766]      Orman, H. and P. Hoffman, "Determining Strengths For
                  Public Keys Used For Exchanging Symmetric Keys", BCP
                  86, RFC 3766, April 2004.

   [RFC3830]      Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
                  K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC
                  3830, August 2004.
Top   ToC   RFC5247 - Page 72
   [RFC4005]      Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
                  "Diameter Network Access Server Application", RFC
                  4005, August 2005.

   [RFC4017]      Stanley, D., Walker, J., and B. Aboba, "Extensible
                  Authentication Protocol (EAP) Method Requirements for
                  Wireless LANs", RFC 4017, March 2005.

   [RFC4033]      Arends, R., Austein, R., Larson, M., Massey, D., and
                  S. Rose, "DNS Security Introduction and Requirements",
                  RFC 4033, March 2005.

   [RFC4035]      Arends, R., Austein, R., Larson, M., Massey, D., and
                  S. Rose, "Protocol Modifications for the DNS Security
                  Extensions", RFC 4035, March 2005.

   [RFC4067]      Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R.
                  Koodli, "Context Transfer Protocol (CXTP)", RFC 4067,
                  July 2005.

   [RFC4072]      Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
                  Extensible Authentication Protocol (EAP) Application",
                  RFC 4072, August 2005.

   [RFC4118]      Yang, L., Zerfos, P., and E. Sadot, "Architecture
                  Taxonomy for Control and Provisioning of Wireless
                  Access Points (CAPWAP)", RFC 4118, June 2005.

   [RFC4186]      Haverinen, H., Ed., and J. Salowey, Ed., "Extensible
                  Authentication Protocol Method for Global System for
                  Mobile Communications (GSM) Subscriber Identity
                  Modules (EAP-SIM)", RFC 4186, January 2006.

   [RFC4187]      Arkko, J. and H. Haverinen, "Extensible Authentication
                  Protocol Method for 3rd Generation Authentication and
                  Key Agreement (EAP-AKA)", RFC 4187, January 2006.

   [RFC4282]      Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
                  Network Access Identifier", RFC 4282, December 2005.

   [RFC4284]      Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
                  "Identity Selection Hints for the Extensible
                  Authentication Protocol (EAP)", RFC 4284, January
                  2006.

   [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
                  Internet Protocol", RFC 4301, December 2005.
Top   ToC   RFC5247 - Page 73
   [RFC4306]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                  Protocol", RFC 4306, December 2005.

   [RFC4372]      Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
                  "Chargeable User Identity", RFC 4372, January 2006.

   [RFC4334]      Housley, R. and T. Moore, "Certificate Extensions and
                  Attributes Supporting Authentication in Point-to-Point
                  Protocol (PPP) and Wireless Local Area Networks
                  (WLAN)", RFC 4334, February 2006.

   [RFC4535]      Harney, H., Meth, U., Colegrove, A., and G. Gross,
                  "GSAKMP: Group Secure Association Key Management
                  Protocol", RFC 4535, June 2006.

   [RFC4763]      Vanderveen, M. and H. Soliman, "Extensible
                  Authentication Protocol Method for Shared-secret
                  Authentication and Key Establishment (EAP-SAKE)", RFC
                  4763, November 2006.

   [RFC4675]      Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
                  Attributes for Virtual LAN and Priority Support", RFC
                  4675, September 2006.

   [RFC4718]      Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
                  Implementation Guidelines", RFC 4718, October 2006.

   [RFC4764]      Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol:
                  A Pre-Shared Key Extensible Authentication Protocol
                  (EAP) Method", RFC 4764, January 2007.

   [RFC5176]      Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                  Aboba, "Dynamic Authorization Extensions to Remote
                  Authentication Dial In User Service (RADIUS)", RFC
                  5176, January 2008.

   [RFC5216]      Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
                  Authentication Protocol", RFC 5216, March 2008.

   [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                  Security (TLS) Protocol Version 1.2", RFC 5246, August
                  2008.

   [SP800-57]     National Institute of Standards and Technology,
                  "Recommendation for Key Management", Special
                  Publication 800-57, May 2006.
Top   ToC   RFC5247 - Page 74
   [Token]        Fantacci, R., Maccari, L., Pecorella, T., and F.
                  Frosali, "A secure and performant token-based
                  authentication for infrastructure and mesh 802.1X
                  networks", IEEE Conference on Computer Communications,
                  June 2006.

   [Tokenk]       Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover
                  Keying: A Media-Independent Handover Key Management
                  Architecture", Mobiarch 2007.

Acknowledgments

Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco, and Russ Housley of Vigil Security for useful feedback.
Top   ToC   RFC5247 - Page 75

Appendix A - Exported Parameters in Existing Methods

This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-Lifetime for EAP methods that have been published prior to this specification. Future EAP method specifications MUST include a definition of the Session-Id, Peer-Id and Server-Id (could be the null string). In the descriptions that follow, all fields comprising the Session-Id are assumed to be in network byte order. EAP-Identity The EAP-Identity method is defined in [RFC3748]. It does not derive keys, and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length). EAP-Notification The EAP-Notification method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length). EAP-MD5-Challenge The EAP-MD5-Challenge method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length). EAP-GTC The EAP-GTC method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length). EAP-OTP The EAP-OTP method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
Top   ToC   RFC5247 - Page 76
   EAP-AKA

      EAP-AKA is defined in [RFC4187].  The EAP-AKA Session-Id is the
      concatenation of the EAP Type Code (0x17) with the contents of the
      RAND field from the AT_RAND attribute, followed by the contents of
      the AUTN field in the AT_AUTN attribute:

      Session-Id = 0x17 || RAND || AUTN

      The Peer-Id is the contents of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless of whether the
      transmitted identity was a permanent, pseudonym, or fast EAP
      re-authentication identity.  The Server-Id is the null string
      (zero length).

   EAP-SIM

      EAP-SIM is defined in [RFC4186].  The EAP-SIM Session-Id is the
      concatenation of the EAP Type Code (0x12) with the contents of the
      RAND field from the AT_RAND attribute, followed by the contents of
      the NONCE_MT field in the AT_NONCE_MT attribute:

      Session-Id = 0x12 || RAND || NONCE_MT

      The Peer-Id is the contents of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless of whether the
      transmitted identity was a permanent, pseudonym, or fast EAP
      re-authentication identity.  The Server-Id is the null string
      (zero length).

   EAP-PSK

      EAP-PSK is defined in [RFC4764].  The EAP-PSK Session-Id is the
      concatenation of the EAP Type Code (0x2F) with the peer (RAND_P)
      and server (RAND_S) nonces:

      Session-Id = 0x2F || RAND_P || RAND_S

      The Peer-Id is the contents of the ID_P field and the Server-Id is
      the contents of the ID_S field.
Top   ToC   RFC5247 - Page 77
   EAP-SAKE

      EAP-SAKE is defined in [RFC4763].  The EAP-SAKE Session-Id is the
      concatenation of the EAP Type Code (0x30) with the contents of the
      RAND_S field from the AT_RAND_S attribute, followed by the
      contents of the RAND_P field in the AT_RAND_P attribute:

      Session-Id = 0x30 || RAND_S || RAND_P

      Note that the EAP-SAKE Session-Id is not the same as the "Session
      ID" parameter chosen by the Server, which is sent in the first
      message, and replicated in subsequent messages.  The Peer-Id is
      contained within the value field of the AT_PEERID attribute and
      the Server-Id, if available, is contained in the value field of
      the AT_SERVERID attribute.

   EAP-TLS

      For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in
      [RFC5216].
Top   ToC   RFC5247 - Page 78

Authors' Addresses

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329 Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com
Top   ToC   RFC5247 - Page 79
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.