tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5247

 
 
 

Extensible Authentication Protocol (EAP) Key Management Framework

Part 4 of 4, p. 60 to 79
Prev RFC Part

 


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