diff options
Diffstat (limited to 'doc/rfc/rfc4962.txt')
| -rw-r--r-- | doc/rfc/rfc4962.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc4962.txt b/doc/rfc/rfc4962.txt new file mode 100644 index 0000000..a57fd47 --- /dev/null +++ b/doc/rfc/rfc4962.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group R. Housley +Request for Comments: 4962 Vigil Security +BCP: 132 B. Aboba +Category: Best Current Practice Microsoft + July 2007 + + + Guidance for Authentication, Authorization, and Accounting (AAA) + Key Management + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document provides guidance to designers of Authentication, + Authorization, and Accounting (AAA) key management protocols. The + guidance is also useful to designers of systems and solutions that + include AAA key management protocols. Given the complexity and + difficulty in designing secure, long-lasting key management + algorithms and protocols by experts in the field, it is almost + certainly inappropriate for IETF working groups without deep + expertise in the area to be designing their own key management + algorithms and protocols based on Authentication, Authorization, and + Accounting (AAA) protocols. The guidelines in this document apply to + documents requesting publication as IETF RFCs. Further, these + guidelines will be useful to other standards development + organizations (SDOs) that specify AAA key management. + + + + + + + + + + + + + + + + +Housley & Aboba Best Current Practice [Page 1] + +RFC 4962 Guidance for AAA Key Management July 2007 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Specification .................................3 + 1.2. Mandatory to Implement .....................................3 + 1.3. Terminology ................................................3 + 2. AAA Environment Concerns ........................................5 + 3. AAA Key Management Requirements .................................7 + 4. AAA Key Management Recommendations .............................13 + 5. Security Considerations ........................................14 + 6. Normative References ...........................................15 + 7. Informative References .........................................15 + Appendix: AAA Key Management History ..............................20 + Acknowledgments ...................................................22 + +1. Introduction + + This document provides architectural guidance to designers of AAA key + management protocols. The guidance is also useful to designers of + systems and solutions that include AAA key management protocols. + + AAA key management often includes a collection of protocols, one of + which is the AAA protocol. Other protocols are used in conjunction + with the AAA protocol to provide an overall solution. These other + protocols often provide authentication and security association + establishment. + + Given the complexity and difficulty in designing secure, long-lasting + key management algorithms and protocols by experts in the field, it + is almost certainly inappropriate for IETF working groups without + deep expertise in the area to be designing their own key management + algorithms and protocols based on Authentication, Authorization and + Accounting (AAA) protocols. These guidelines apply to documents + requesting publication as IETF RFCs. Further, these guidelines will + be useful to other standards development organizations (SDOs) that + specify AAA key management that depends on IETF specifications for + protocols such as Extensible Authentication Protocol (EAP) [RFC3748], + Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and + Diameter [RFC3588]. + + In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley + gave a presentation on "Key Management in AAA" [H]. That + presentation established the vast majority of the requirements + contained in this document. Over the last three years, this + collection of requirements have become known as the "Housley + Criteria". + + + + + +Housley & Aboba Best Current Practice [Page 2] + +RFC 4962 Guidance for AAA Key Management July 2007 + + +1.1. Requirements Specification + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in RFC 2119 [RFC2119]. + + An AAA key management proposal is not compliant with this + specification if it fails to satisfy one or more of the MUST or MUST + NOT statements. An AAA key management proposal that satisfies all + the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be + "unconditionally compliant"; one that satisfies all the MUST and MUST + NOT statements but not all the SHOULD or SHOULD NOT requirements is + said to be "conditionally compliant". + +1.2. Mandatory to Implement + + The guidance provided in this document is mandatory to implement. + However, it is not mandatory to use. That is, configuration at the + time of deployment may result in a deployed implementation that does + not conform with all of these requirements. + + For example, [RFC4072] enables EAP keying material to be delivered + from a AAA server to an AAA client without disclosure to third + parties. Thus, key confidentiality is mandatory to implement in + Diameter [RFC3588]. However, key confidentiality is not mandatory to + use. + +1.3. Terminology + + This section defines terms that are used in this document. + + AAA + Authentication, Authorization, and Accounting (AAA). AAA + protocols include RADIUS [RFC2865] and Diameter [RFC3588]. + + Authenticator + The party initiating EAP authentication. The term + authenticator is used in [802.1X], and authenticator has the + same meaning in this document. + + Backend authentication server + A backend authentication server is an entity that provides an + authentication service to an authenticator. This terminology + is also used in [802.1X]. + + + + + + + +Housley & Aboba Best Current Practice [Page 3] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + CHAP + Challenge Handshake Authentication Protocol; a one-way + challenge/response authentication protocol defined in + [RFC1994]. + + EAP + Extensible Authentication Protocol, defined in [RFC3748]. + + EAP server + The entity that terminates the EAP authentication method with + the peer. In the case where no backend authentication server + is used, the EAP server is part of the authenticator. In the + case where the authenticator operates in pass-through mode, the + EAP server is located on the backend authentication server. + + Key Wrap + The encryption of one symmetric cryptographic key in another. + The algorithm used for the encryption is called a key wrap + algorithm or a key encryption algorithm. The key used in the + encryption process is called a key-encryption key (KEK). + + PAP + Password Authentication Protocol; a deprecated cleartext + password PPP authentication protocol, originally defined in + [RFC1334]. + + Party + A party is a processing entity that can be identified as a + single role in a protocol. + + Peer + The end of the link that responds to the authenticator. In + [802.1X], this end is known as the supplicant. + + PPP + Point-to-Point Protocol, defined in [RFC1661], provides support + for multiprotocol serial datalinks. PPP is the primary IP + datalink used for dial-in NAS connection service. + + Secure Association Protocol + A protocol for managing security associations derived from EAP + and/or AAA exchanges. The protocol establishes a security + association, which includes symmetric keys and a context for + the use of the keys. An example of a Secure Association + Protocol is the 4-way handshake defined within [802.11i]. + + + + + + +Housley & Aboba Best Current Practice [Page 4] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + Session Keys + Keying material used to protect data exchanged after + authentication has successfully completed, using the negotiated + ciphersuite. + + Network Access Server (NAS) + A device that provides an access service for a user to a + network. The service may be a network connection, or a value + added service such as terminal emulation, as described in + [RFC2881]. + + 4-Way Handshake + A Secure Association Protocol, defined in [802.11i], which + confirms mutual possession of a Pairwise Master Key by two + parties and distributes a Group Key. + +2. AAA Environment Concerns + + Examples of serious flaws plague the history of key management + protocol development, starting with the very first attempt to define + a key management protocol in the open literature, which was published + in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the + fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in + the original 1978 version, in an area not affected by the 1981/1994 + issue. All of these flaws were blindingly obvious once described, + yet no one spotted them earlier. Note that the original protocol, if + it were revised to employ certificates, which of course had yet to be + invented, was only three messages. Many proposed AAA key management + schemes are significantly more complicated. + + This bit of history shows that key management protocols are subtle. + Experts can easily miss a flaw. As a result, peer review by multiple + experts is essential, especially since many proposed AAA key + management schemes are significantly more complicated. In addition, + formal methods can help uncover problems [M]. + + AAA-based key management is being incorporated into standards + developed by the IETF and other standards development organizations + (SDOs), such as IEEE 802. However, due to ad hoc development of + AAA-based key management, AAA-based key distribution schemes have + poorly understood security properties, even when well-studied + cryptographic algorithms are employed. More academic research is + needed to fully understand the security properties of AAA-based key + management in the diverse protocol environments where it is being + employed today. In the absence of such research results, pragmatic + guidance based on sound security engineering principles is needed. + + + + + +Housley & Aboba Best Current Practice [Page 5] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + In addition to the need for interoperability, cryptographic algorithm + independent solutions are greatly preferable. Without algorithm + independence, the AAA-based key management protocol must be changed + whenever a problem is discovered with any of the selected algorithms. + As AAA history shows, problems are inevitable. Problems can surface + due to age or design failure. + + DES [FIPS46] was a well-designed encryption algorithm, and it + provided protection for many years. Yet, the 56-bit key size was + eventually overcome by Moore's Law. No significant cryptographic + deficiencies have been discovered in DES. + + The history of AAA underlines the importance of algorithm + independence as flaws have been found in authentication mechanisms + such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos + [W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates + use of the MD5 algorithm for integrity protection, which has known + deficiencies, and RADIUS has no provisions to negotiate substitute + algorithms. Similarly, the vendor-specific key wrap mechanism + defined in [RFC2548] has no provisions to negotiate substitute + algorithms. + + The principle of least privilege is an important design guideline. + This principle requires that a party be given no more privilege than + necessary to perform the task assigned to them. Ensuring least + privilege requires clear identification of the tasks assigned to each + party, and explicit determination of the minimum set of privileges + required to perform those tasks. Only those privileges necessary to + perform the tasks are granted. By denying to parties unneeded + privileges, those denied privileges cannot be used to circumvent + security policy or enable attackers. With this principle in mind, + AAA key management schemes need to be designed in a manner where each + party has only the privileges necessary to perform their role. That + is, no party should have access to any keying material that is not + needed to perform their own role. A party has access to a particular + key if it has access to all of the secret information needed to + derive it. + + EAP is being used in new ways. The inclusion of support for EAP + within Internet Key Exchange Protocol version 2 (IKEv2) and the + standardization of robust Wireless LAN security [802.11i] based on + EAP are two examples. EAP has also been proposed within IEEE 802.16e + [802.16e] and by the IETF PANA Working Group. AAA-based key + management is being incorporated into standards developed by the IETF + and other standards development organizations (SDOs), such as IEEE + 802. However, due to ad hoc development of AAA-based key management, + AAA-based key distribution schemes have poorly understood security + properties, even when well-studied cryptographic algorithms are + + + +Housley & Aboba Best Current Practice [Page 6] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + employed. More academic research is needed to fully understand the + security properties of AAA-based key management in the diverse + protocol environments where it is being employed today. In the + absence of research results, pragmatic guidance based on sound + security engineering principles is needed. + + EAP selects one end-to-end authentication mechanism. The mechanisms + defined in [RFC3748] only support unilateral authentication, and they + do not support mutual authentication or key derivation. As a result, + these mechanisms do not fulfill the security requirements for many + deployment scenarios, including Wireless LAN authentication + [RFC4017]. + + To ensure adequate security and interoperability, EAP applications + need to specify mandatory-to-implement algorithms. As described in + [RFC3748], EAP methods seeking publication as an IETF RFC need to + document their security claims. However, some EAP methods are not + based on well-studied models, which makes the validity of these + security claims difficult to determine. + + In the context of EAP, the EAP peer and server are the parties + involved in the EAP method conversation, and they gain access to key + material when the conversation completes successfully. However, the + lower-layer needs keying material to provide the desired protection + through the use of cryptographic mechanisms. As a result, a "pass- + through" mode is used to provide the keying material, and the lower- + layer keying material is replicated from the AAA server to the + authenticator. The only parties authorized to obtain all of the + keying material are the EAP peer and server; the authenticator + obtains only the keying material necessary for its specific role. No + other party can obtain direct access to any of the keying material; + however, other parties may receive keys that are derived from this + keying material for a specific purpose as long as the requirements + defined in the next section are met. + +3. AAA Key Management Requirements + + The overall goal of AAA key management is to provide cryptographic + keying material in situations where key derivation cannot be used by + the peer and authenticator. It may not be possible because the + authenticator lacks computational power, because it lacks the + resources necessary to implement the various authentication + mechanisms that might be required, or because it is undesirable for + each authenticator to engage in a separate key management + conversation. + + + + + + +Housley & Aboba Best Current Practice [Page 7] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + This section provides guidance to AAA protocol designers, EAP method + designers, and security association protocol designers. Acceptable + solutions MUST meet all of these requirements. + + Cryptographic algorithm independent + + The AAA key management protocol MUST be cryptographic algorithm + independent. However, an EAP method MAY depend on a specific + cryptographic algorithm. The ability to negotiate the use of a + particular cryptographic algorithm provides resilience against + compromise of a particular cryptographic algorithm. Algorithm + independence is also REQUIRED with a Secure Association + Protocol if one is defined. This is usually accomplished by + including an algorithm identifier and parameters in the + protocol, and by specifying the algorithm requirements in the + protocol specification. While highly desirable, the ability to + negotiate key derivation functions (KDFs) is not required. For + interoperability, at least one suite of mandatory-to-implement + algorithms MUST be selected. Note that without protection by + IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] + does not meet this requirement, since the integrity protection + algorithm cannot be negotiated. + + This requirement does not mean that a protocol must support + both public-key and symmetric-key cryptographic algorithms. It + means that the protocol needs to be structured in such a way + that multiple public-key algorithms can be used whenever a + public-key algorithm is employed. Likewise, it means that the + protocol needs to be structured in such a way that multiple + symmetric-key algorithms can be used whenever a symmetric-key + algorithm is employed. + + 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]. + + + + +Housley & Aboba Best Current Practice [Page 8] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + 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. + + 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. + + 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. + + Authenticate all parties + + Each party in the AAA key management protocol MUST be + authenticated to the other parties with whom they communicate. + Authentication mechanisms MUST maintain the confidentiality of + any secret values used in the authentication process. + + + +Housley & Aboba Best Current Practice [Page 9] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + When a secure association protocol is used to establish session + keys, the parties involved in the secure association protocol + MUST identify themselves using identities that are meaningful + in the lower-layer protocol environment that will employ the + session keys. In this situation, the authenticator and peer + may be known by different identifiers in the AAA protocol + environment and the lower-layer protocol environment, making + authorization decisions difficult without a clear key scope. + If the lower-layer identifier of the peer will be used to make + authorization decisions, then the pair of identifiers + associated with the peer MUST be authorized by the + authenticator and/or the AAA server. + + AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], + provide a mechanism for the identification of AAA clients; + since the EAP authenticator and AAA client are always co- + resident, this mechanism is applicable to the identification of + EAP authenticators. + + When multiple base stations and a "controller" (such as a WLAN + switch) comprise a single EAP authenticator, the "base station + identity" is not relevant; the EAP method conversation takes + place between the EAP peer and the EAP server. Also, many base + stations can share the same authenticator identity. The + authenticator identity is important in the AAA protocol + exchange and the secure association protocol conversation. + + Authentication mechanisms MUST NOT employ plaintext passwords. + Passwords may be used provided that they are not sent to + another party without confidentiality protection. + + 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. + + + + + +Housley & Aboba Best Current Practice [Page 10] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + 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.11i, 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 RFC 3579 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 RFC + 3748 in Section 7.15, channel binding is required to enable the + peer to verify that the authenticator claim of identity is both + consistent and correct. + + Keying material confidentiality and integrity + + While preserving algorithm independence, confidentiality and + integrity of all keying material MUST be maintained. + + Confirm ciphersuite selection + + The selection of the "best" ciphersuite SHOULD be securely + confirmed. The mechanism SHOULD detect attempted roll-back + attacks. + + 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. + + Prevent the Domino effect + + Compromise of a single peer MUST NOT compromise keying material + held by any other peer within the system, including session + keys and long-term keys. Likewise, compromise of a single + + + +Housley & Aboba Best Current Practice [Page 11] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + authenticator MUST NOT compromise keying material held by any + other authenticator within the system. In the context of a key + hierarchy, this means that the compromise of one node in the + key hierarchy must not disclose the information necessary to + compromise other branches in the key hierarchy. Obviously, the + compromise of the root of the key hierarchy will compromise all + of the keys; however, a compromise in one branch MUST NOT + result in the compromise of other branches. There are many + implications of this requirement; however, two implications + deserve highlighting. First, the scope of the keying material + must be defined and understood by all parties that communicate + with a party that holds that keying material. Second, a party + that holds keying material in a key hierarchy must not share + that keying material with parties that are associated with + other branches in the key hierarchy. + + Group keys are an obvious exception. Since all members of the + group have a copy of the same key, compromise of any one of the + group members will result in the disclosure of the group key. + + Bind key to its context + + Keying material MUST be bound to the appropriate context. The + context includes the following. + + o The manner in which the keying material is expected to be + used. + + o The other parties that are expected to have access to the + keying material. + + o The expected lifetime of the keying material. Lifetime + of a child key SHOULD NOT be greater than the lifetime of + its parent in the key hierarchy. + + Any party with legitimate access to keying material can + determine its context. In addition, the protocol MUST ensure + that all parties with legitimate access to keying material have + the same context for the keying material. This requires that + the parties are properly identified and authenticated, so that + all of the parties that have access to the keying material can + be determined. + + + + + + + + + +Housley & Aboba Best Current Practice [Page 12] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + The context will include the peer and NAS identities in more + than one form. One (or more) name form is needed to identify + these parties in the authentication exchange and the AAA + protocol. Another name form may be needed to identify these + parties within the lower layer that will employ the session + key. + +4. AAA Key Management Recommendations + + Acceptable solutions SHOULD meet all of these requirements. + + Confidentiality of identity + + In many environments, it is important to provide + confidentiality protection for identities. However, this is + not important in other environments. For this reason, EAP + methods are encouraged to provide a mechanism for identity + protection of EAP peers, but such protection is not a + requirement. + + 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. + + + + + + + + + + + +Housley & Aboba Best Current Practice [Page 13] + +RFC 4962 Guidance for AAA Key Management July 2007 + + +5. Security Considerations + + This document provides architectural guidance to designers of AAA key + management protocols. The guidance is also useful to designers of + systems and solutions that include AAA key management protocols. + + In some deployment scenarios, more than one party in the AAA key + management protocol can reside on the same host. For example, the + EAP authenticator and AAA client are expected to reside on the same + entity. Colocation enables a single unique authenticator identity to + be sent by the authenticator to the AAA server as well as by the + authenticator to the EAP peer. Use of the same identity in both + conversations enables the peer and AAA server to confirm that the + authenticator is consistent in its identification, avoiding potential + impersonation attacks. If the authenticator and AAA client are not + colocated, then the authenticator and AAA client identities will + differ, and the key scope will not be synchronized between the EAP + peer, authenticator, and server. Lack of key scope synchronization + enables a number of security vulnerabilities, including + impersonation. For this reason, a design needs to include mechanisms + to ensure that the key scope and key naming are unambiguous. + + The AAA server is a trusted entity. When keying material is present + at all, it establishes keying material with the peer and distributes + keying material to the authenticator using the AAA protocol. It is + trusted to only distribute keying material to the authenticator that + was established with the peer, and it is trusted to provide that + keying material to no other parties. In many systems, keying + material established by the EAP peer and EAP server are combined with + publicly available data to derive other keys. The AAA server is + trusted to refrain from deriving these same keys even though it has + access to the secret values that are needed to do so. + + The authenticator is also a trusted party. The authenticator is + trusted not to distribute keying material provided by the AAA server + to any other parties. If the authenticator uses a key derivation + function to derive additional keying material, the authenticator is + trusted to distribute the derived keying material only to the + appropriate party that is known to the peer, and no other party. + When this approach is used, care must be taken to ensure that the + resulting key management system meets all of the principles in this + document, confirming that keys used to protect data are to be known + only by the peer and authenticator. + + EAP is used to authenticate the peer to the AAA/EAP server. + Following successful authentication, the AAA/EAP server authorizes + the peer. In many situations, this is accomplished by sending keying + material to the authenticator and the peer in separate protocol + + + +Housley & Aboba Best Current Practice [Page 14] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + messages. The authenticator is not directly authenticated to the + peer. Rather, the peer determines that the authenticator has been + authorized by the AAA/EAP server by confirming that the authenticator + has the same AAA/EAP server-provided keying material. In some + systems, explicit authenticator and peer mutual authentication is + possible. This is desirable since it greatly improves + accountability. + + When MIB modules are developed for AAA protocols or EAP methods, + these MIB modules might include managed objects for keying material. + The existence of managed objects associated with keying material + offers an additional avenue for key compromise if these objects + include the keying material itself. Therefore, these MIB modules + MUST NOT include objects for private keys or symmetric keys. + However, these MIB modules MAY include management objects that expose + names and context associated with keys, and they MAY provide a means + to delete keys. + +6. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +7. Informative References + + [802.1X] IEEE Standards for Local and Metropolitan Area Networks: + Port based Network Access Control, IEEE Std 802.1X-2004, + December 2004. + + [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, July + 2004. + + [802.16e] Institute of Electrical and Electronics Engineers, + "Supplement to Standard for Telecommunications and + Information Exchange Between Systems -- LAN/MAN Specific + Requirements - 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 Operation in Licensed Bands", Draft, IEEE + 802.16e/D8, May 2005. + + + + + + +Housley & Aboba Best Current Practice [Page 15] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + [AN] M. Abadi and R. Needham, "Prudent Engineering Practice for + Cryptographic Protocols", Proc. IEEE Computer Society + Symposium on Research in Security and Privacy, May 1994. + + [B] Brewin, B., "LEAP attack tool author says he wants to + alert users to risks", Computerworld, October 17, 2003. + + [BM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos + authentication system", Proceedings of the 1991 Winter + USENIX Conference, pp. 253-267, 1991. + + [DDNN39.2] DCA DDN Program Management Office, "MILNET TAC Access + Control", Defense Data Network Newsletter, DDN News 39, + Special Issue, 26 Apr 1985, <http://www.isi.edu/ + in-notes/museum/ddn-news/ddn-news.n39.2>. + + [DLS] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: + Kerberos 4 session keys", Proceedings of the Internet + Society Network and Distributed System Security Symposium, + pp. 60-70, March 1997. + + [DS] D. Denning and G. Sacco. "Timestamps in key distributed + protocols", Communication of the ACM, 24(8):533--535, + 1981. + + [FIPS46] Federal Information Processing Standards Publication (FIPS + PUB) 46, Data Encryption Standard, 1977 January 15. + + [H] Housley, R., "Key Management in AAA", Presentation to the + AAA WG at IETF 56, March 2003, <http://www.ietf.org/ + proceedings/03mar/slides/aaa-5/index.html>. + + [L] G. Lowe. "An attack on the Needham-Schroeder public key + authentication protocol", Information Processing Letters, + 56(3):131--136, November 1995. + + [M] Meadows, C., "Analysis of the Internet Key Exchange + Protocol using the NRL Protocol Analyser", Proceedings of + the 1999 IEEE Symposium on Security & Privacy, Oakland, + CA, USA, IEEE Computer Society, May 1999, + <http://chacs.nrl.navy.mil/publications/CHACS/1999/ + 1999meadows-IEEE99.pdf>. + + [NS] R. Needham and M. Schroeder. "Using encryption for + authentication in large networks of computers", + Communications of the ACM, 21(12), December 1978. + + + + + +Housley & Aboba Best Current Practice [Page 16] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + [RFC0927] Anderson, B.A., "TACACS user identification Telnet + option", RFC 927, December 1984. + + [RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992, Obsoleted by RFC 1994. + + [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called + TACACS", RFC 1492, July 1993. + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, + June 1996. + + [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption + Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. + + [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol + (3DESE)", RFC 2420, September 1998. + + [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC + 2433, October 1998. + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", + RFC 2548, March 1999. + + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, + W., and G. Zorn, "Point-to-Point Tunneling Protocol + (PPTP)", RFC 2637, July 1999. + + [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication + Protocol", RFC 2716, October 1999. + + [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC + 2759, January 2000. + + + + + + +Housley & Aboba Best Current Practice [Page 17] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2865, June 2000. + + [RFC2881] Mitton, D. and M. Beadles, "Network Access Server + Requirements Next Generation (NASREQNG) NAS Model", RFC + 2881, July 2000. + + [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption + (MPPE) Protocol", RFC 3078, March 2001. + + [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to- + Point Encryption (MPPE)", RFC 3079, March 2001. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication + Dial In User Service) Support For Extensible + Authentication Protocol (EAP)", RFC 3579, September 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, "Extensible Authentication Protocol (EAP)", RFC + 3748, June 2004. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strength for Public + Keys Used For Exchanging Symmetric Keys", BCP 86, RFC + 3766, April 2004. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, March 2005. + + [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter + Extensible Authentication Protocol (EAP) Application", RFC + 4072, August 2005. + + [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + [SM1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's + Point-to-Point Tunneling Protocol", Proceedings of the 5th + ACM Conference on Communications and Computer Security, + ACM Press, November 1998. + + [SM2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP + Authentication Extensions (MS-CHAPv2)", CQRE 99, + Springer-Verlag, 1999, pp. 192-203. + + + +Housley & Aboba Best Current Practice [Page 18] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + [SP800-57] National Institute of Standards and Technology, + "Recommendation for Key Management", Special Publication + 800-57, May 2006. + + [W] Wu, T., "A Real-World Analysis of Kerberos Password + Security", Proceedings of the 1999 ISOC Network and + Distributed System Security Symposium, + <http://www.isoc.org/isoc/conferences/ndss/99/ + proceedings/papers/wu.pdf>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley & Aboba Best Current Practice [Page 19] + +RFC 4962 Guidance for AAA Key Management July 2007 + + +Appendix: AAA Key Management History + + Protocols for Authentication, Authorization, and Accounting (AAA) + were originally developed to support deployments of Network Access + Servers (NASes). In the ARPAnet, the Terminal Access Controller + (TAC) provided a means for "dumb terminals" to access the network, + and the TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN + under contract to the Defense Data Network Program Management Office + (DDN PMO) for this environment. [RFC1492] documents a later version + of TACACS, not the original version that was widely deployed in + ARPAnet and MILNET [DDNN39.2]. + + Later, additional AAA protocols were developed to support deployments + of NASes providing access to the Internet via PPP [RFC1661]. In + deployments supporting more than a modest number of users, it became + impractical for each NAS to contain its own list of users and + associated credentials. As a result, additional AAA protocols were + developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These + protocols enabled a central AAA server to authenticate users + requesting network access, as well as providing authorization and + accounting. + + While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP + [RFC1661] authentication, the limitations of these authentication + mechanisms became apparent. For example, both PAP and CHAP are + unilateral authentication schemes supporting only authentication of + the PPP peer to the NAS. Since PAP is a cleartext password scheme, + it is vulnerable to snooping by an attacker with access to the + conversation between the PPP peer and NAS. In addition, the use of + PAP creates vulnerabilities within RADIUS as described in Section 4.3 + of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a + challenge-response scheme based on MD5, offers better security than + cleartext passwords, it does not provide for mutual authentication, + and CHAP is vulnerable to dictionary attack. + + With the addition of the Encryption Control Protocol (ECP) to PPP + [RFC1968] as well as the definition of PPP ciphersuites in [RFC2419], + [RFC2420], and [RFC3078], the need arose to provide keying material + for use with link layer ciphersuites. As with user authentication, + provisioning of static keys on each NAS did not scale well. + + Additional vendor-specific PPP authentication protocols such as + MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide + mutual authentication as well as key derivation [RFC3079] for use + with negotiated ciphersuites, and they were subsequently adapted for + use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were + subsequently found in these new mechanisms [SM1][SM2]. + + + + +Housley & Aboba Best Current Practice [Page 20] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + Even though PPP provided for negotiation of authentication + algorithms, addressing the vulnerabilities found in authentication + mechanisms still proved painful, since new code needed to be deployed + on PPP peers as well as on the AAA server. In order to enable more + rapid deployment of new authentication mechanisms, as well as fixes + for vulnerabilities found in existing methods, the Extensible + Authentication Protocol (EAP) [RFC3748] was developed, along with + support for centralized authentication via RADIUS/EAP [RFC3579]. + + By enabling "pass through" authentication on the NAS, EAP enabled + deployment of new authentication methods or updates to existing + methods by revising code only on the EAP peer and AAA server. The + initial authentication mechanisms defined in [RFC2284] (MD5- + Challenge, One-Time Password (OTP), and Generic Token Card (GTC)) + only supported unilateral authentication, and these mechanisms do not + support key derivation. Subsequent authentication methods such as + EAP-TLS [RFC2716] supported mutual authentication and key derivation. + + In order to support the provisioning of dynamic keying material for + link layer ciphersuites in an environment supporting centralized + authentication, a mechanism was needed for the transport of keying + material between the AAA server and NAS. Vendor-specific RADIUS + attributes were developed for this purpose [RFC2548]. + Vulnerabilities were subsequently found in the key wrap technique, as + described in Section 4.3 of [RFC3579]. + + In theory, public key authentication mechanisms such as EAP-TLS are + capable of supporting mutual authentication and key derivation + between the EAP peer and NAS without requiring AAA key distribution. + However, in practice, such pure two-party schemes are rarely + deployed. Operation of a centralized AAA server significantly + reduces the effort required to deploy certificates to NASes, and even + though an AAA server may not be required for key derivation and + possibly authentication, its participation is required for service + authorization and accounting. + + "Pass-through" authentication and AAA key distribution has retained + popularity even in the face of rapid improvements in processor and + memory capabilities. In addition to producing NAS devices of + increased capability for enterprise and carrier customers, + implementers have also produced low-cost/high-volume NAS devices such + as 802.11 Access Points, causing the resources available on an + average NAS to increase more slowly than Moore's law. Despite + widespread support for certificate handling and sophisticated key + derivation mechanisms such as IKEv1 [RFC2409] within host operating + systems, these security capabilities are rarely deployed on low-end + NASes and clients. + + + + +Housley & Aboba Best Current Practice [Page 21] + +RFC 4962 Guidance for AAA Key Management July 2007 + + + Even on more capable NASes, such as VPN servers, centralized + authentication and AAA key management has proven popular. For + example, one of the major limitations of IKEv1 [RFC2409] was the lack + of integration with EAP and AAA, requiring proprietary extensions to + enable use of IPsec VPNs by organizations deploying password or + authentication tokens. These limitations were addressed in IKEv2 + [RFC4306], which while handling key derivation solely between the VPN + client and server, supports EAP methods for user authentication. In + order to enable cryptographic binding of EAP user authentication to + keys derived within the IKEv2 exchange, the transport of EAP-derived + keys within AAA is required where the selected EAP method supports + key derivation. + +Acknowledgments + + Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their + quality review and encouragement. + + Thanks to the IETF AAA Working Group and the IETF EAP Working Group + for their review and comment. The document is greatly improved by + their contribution. + +Authors' Addresses + + Russell Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + EMail: housley@vigilsec.com + Phone: +1 703-435-1775 + Fax: +1 703-435-1274 + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + EMail: bernarda@microsoft.com + Phone: +1 425-706-6605 + Fax: +1 425-936-7329 + + + + + + + + + + +Housley & Aboba Best Current Practice [Page 22] + +RFC 4962 Guidance for AAA Key Management July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Housley & Aboba Best Current Practice [Page 23] + |