RFC 5247
Extensible Authentication Protocol (EAP) Key Management Framework
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
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
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.
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.
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:
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.
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
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.
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.
[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.
[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.
[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.
[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.
[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.
[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.
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).
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.
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].
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
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.