RFC 4962

Guidance for Authentication, Authorization, and Accounting (AAA) Key Management

📅 published July 2007, from ietf

Title Block 🎀

Okay bestie, this one is RFC 4962, published by the Network Working Group in July 2007 💖. Authors R. Housley (Vigil Security) and B. Aboba (Microsoft) wrote it, and it's a Best Current Practice, filed as BCP 132 🌸. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨.

The title is "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" 🔑.

Status of This Memo 📝

This document is a Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🫶. You can distribute it however you like, because distribution is unlimited 🦋.

Copyright (C) The IETF Trust (2007) 💜.

Abstract 🌈

This doc is the guidance you want if you're designing AAA key management protocols 💅. It's also useful if you're building systems and solutions that include those protocols ✨.

Key management is genuinely hard to get right and keep secure for the long haul, even for experts 💀. So it's almost certainly a bad idea for IETF working groups that don't have deep expertise in this area to design their own key management algorithms and protocols on top of AAA protocols 🙈. The guidelines here apply to documents that want to be published as IETF RFCs 📜. Other standards development organizations (SDOs) that specify AAA key management will find them useful too 🌷.

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 ✨

Okay so this section sets the stage 🎬. It gives architectural guidance to people designing AAA key management protocols 💖. Folks building systems and solutions around those protocols will get value out of it too 🫶.

AAA key management is usually a bundle of protocols 🧩. The AAA protocol is one of them, and it works alongside other protocols to make a full solution work 🔥. Those other protocols often handle authentication and security association establishment 🔐.

Again, the big warning: designing secure, long-lasting key management algorithms and protocols is super hard, even for experts 😭. So it's almost certainly inappropriate for IETF working groups without deep expertise to roll their own key management on top of AAA protocols 🙅‍♀️. These guidelines apply to documents requesting publication as IETF RFCs 📜. SDOs that specify AAA key management which depends on IETF specifications will find them handy too 🌸. That includes protocols like Extensible Authentication Protocol (EAP) [RFC3748], Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and Diameter [RFC3588] 🦋.

Some history, because it's giving origin story 🍓: in March 2003, at the IETF 56 AAA Working Group Session, Russ Housley gave a presentation called "Key Management in AAA" [H]. That talk basically established the vast majority of the requirements in this doc 🎀. Over the next three years, that collection of requirements became known as the "Housley Criteria" 👑.

1.1. Requirements Specification 📏

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be interpreted as described in RFC 2119 [RFC2119] 🤓.

So here's how compliance works 💅. An AAA key management proposal is not compliant if it fails to satisfy one or more of the MUST or MUST NOT statements 💀. A proposal that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is called "unconditionally compliant" 💖. A proposal that satisfies all the MUST and MUST NOT statements but doesn't meet every SHOULD or SHOULD NOT requirement is called "conditionally compliant" ✨.

1.2. Mandatory to Implement 🔧

The guidance in this document is mandatory to implement 🫶. But it is not mandatory to use 🙈. In other words, the way something gets configured at deployment time might mean the deployed implementation doesn't conform with every one of these requirements 🌈.

Here's an example 🍓: [RFC4072] lets EAP keying material get delivered from a AAA server to a AAA client without being disclosed to third parties 🔑. So key confidentiality is mandatory to implement in Diameter [RFC3588] ✨. But key confidentiality is not mandatory to use 💅.

1.3. Terminology 📖

This section defines the terms used throughout the document, so you're never left guessing what someone means 🧚.

AAA Authentication, Authorization, and Accounting (AAA) 💖. AAA protocols include RADIUS [RFC2865] and Diameter [RFC3588] 🦋.

Authenticator The party that initiates EAP authentication 🔐. The term authenticator is used in [802.1X], and it has the same meaning in this document ✨.

Backend authentication server An entity that provides an authentication service to an authenticator 🏰. This terminology is also used in [802.1X] 🌸.

CHAP Challenge Handshake Authentication Protocol 🎀. It's 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 🫶. If no backend authentication server is used, the EAP server is part of the authenticator 🧩. If 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 inside another 🔑. The algorithm used for that 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 🙈. It's a deprecated cleartext password PPP authentication protocol, originally defined in [RFC1334] 💀.

Party 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] 🌷. It 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 using those keys ✨. An example is the 4-way handshake defined within [802.11i] 🌈.

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 ✨

okay so the history of key management protocols is honestly a little embarrassing 💀 The very first key management protocol published in the open literature came out in 1978 [NS], and it had a real flaw. A flaw and a fix were published in 1981 [DS], and then that fix got broken in 1994 [AN]. Then in 1995 [L], somebody found a brand new flaw in the original 1978 version, in an area the 1981/1994 mess never touched 😭 All of these bugs were blindingly obvious once someone pointed them out, but nobody spotted them beforehand. Also, the original protocol was only three messages even if you revised it to use certificates (which, to be fair, hadn't been invented yet). Lots of the proposed AAA key management schemes are way more complicated than that 🙈

so the big lesson is that key management is subtle, and experts can totally miss a flaw. That's why peer review by multiple experts is essential, especially since the AAA schemes are so complicated. Formal methods can also help uncover problems [M] 🔍

AAA-based key management is getting built into standards from the IETF and other standards development organizations (SDOs), like IEEE 802. The catch is that AAA-based key management has been developed in an ad hoc way, so AAA-based key distribution schemes have poorly understood security properties, even when they use well-studied cryptographic algorithms. We need more academic research to really understand the security properties of AAA-based key management in all the different protocol environments where it's being used today. Until that research shows up, pragmatic guidance based on sound security engineering principles is needed 💖

Interoperability matters a lot, but so does cryptographic algorithm independence, and it's greatly preferable. Without algorithm independence, the AAA-based key management protocol has to be changed whenever a problem turns up with any of the selected algorithms. And as AAA history shows us, problems are inevitable 💅 Problems can surface because of age or because of a design failure.

DES [FIPS46] was a genuinely well-designed encryption algorithm, and it protected things for many years 🌸 Eventually though, its 56-bit key size got overcome by Moore's Law. No significant cryptographic deficiencies have been found in DES itself, so it's more of a size problem than a design problem.

The history of AAA also shows why algorithm independence matters, because flaws have been found in 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, and MD5 has known deficiencies. RADIUS also has no provisions for negotiating substitute algorithms. The vendor-specific key wrap mechanism defined in [RFC2548] has the same problem: no provisions to negotiate substitute algorithms 🥲

The principle of least privilege is a super important design guideline 👑 It says a party should get no more privilege than it needs to do its assigned task. To make that work, you need to clearly identify the tasks each party is assigned, and then explicitly figure out the minimum set of privileges needed to perform those tasks. Only the privileges that are necessary to do the tasks get granted. Denying parties the privileges they don't need is the whole point, because those denied privileges can't be used to get around security policy or help an attacker. So AAA key management schemes need to be designed so that each party only has the privileges it needs for its role. No party should have access to keying material it doesn't need for its 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 showing up in new places now, like the inclusion of EAP within Internet Key Exchange Protocol version 2 (IKEv2) and the standardization of robust Wireless LAN security [802.11i] based on EAP. EAP has also been proposed within IEEE 802.16e [802.16e] and by the IETF PANA Working Group 🦋 AAA-based key management is getting incorporated into standards from the IETF and other SDOs, such as IEEE 802. Again, that development has been ad hoc, so the security properties of AAA-based key distribution schemes are poorly understood, even with well-studied algorithms. More academic research is needed to fully understand these properties across the diverse protocol environments where AAA-based key management is used now. Until research results exist, 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. They don't support mutual authentication or key derivation. Because of that, they don't fulfill the security requirements for many deployment scenarios, including Wireless LAN authentication [RFC4017] 🙃

To get adequate security and interoperability, EAP applications need to specify mandatory-to-implement algorithms. As [RFC3748] describes, EAP methods that want to be published as an IETF RFC need to document their security claims. The catch is that some EAP methods aren't based on well-studied models, so it's hard to figure out whether those security claims are valid 🫶

In the context of EAP, the EAP peer and server are the parties in the EAP method conversation, and they get access to key material when that conversation completes successfully. The lower layer also needs keying material to provide the protection it wants through cryptographic mechanisms. So a "pass-through" mode is used to deliver that keying material, and the lower-layer keying material is replicated from the AAA server to the authenticator. Only the EAP peer and server are authorized to get all of the keying material. The authenticator only gets the keying material it needs for its specific role. No other party can get direct access to any of the keying material. Other parties can receive keys derived from this keying material for a specific purpose, though, as long as the requirements in the next section are met 💜

3. AAA Key Management Requirements 🎀

okay so the overall goal of AAA key management is to provide cryptographic keying material in situations where the peer and authenticator can't use key derivation. That might happen because the authenticator lacks computational power, or because it doesn't have the resources to implement the various authentication mechanisms that might be required. It could also be because it's undesirable for each authenticator to run its own separate key management conversation 🍓

This section gives 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. An EAP method MAY depend on a specific cryptographic algorithm, though 🦋 Being able to negotiate a particular cryptographic algorithm gives you resilience against compromise of that algorithm. Algorithm independence is also REQUIRED with a Secure Association Protocol, if one is defined. This is usually handled by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. Being able to negotiate key derivation functions (KDFs) is highly desirable, but it's not required. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Also note that without protection by IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] doesn't meet this requirement, since its integrity protection algorithm can't be negotiated 😬

This requirement doesn't mean a protocol has to support both public-key and symmetric-key cryptographic algorithms. What it means is that the protocol needs to be structured so that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, the protocol needs to be structured so 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 its own independent session key 🌈 Fresh keys are required even when a long replay counter (one that "will never wrap") is used, because a loss of state could otherwise cause the same counter value to be used more than once with the same session key.

Some EAP methods can derive keys of varying strength, and these EAP methods MUST permit the generation of keys that meet a minimum equivalent key strength. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also gives advice on appropriate key sizes in [SP800-57] 📚

A fresh cryptographic key is one that gets generated specifically for its 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. 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 sticks around after the authentication exchange has completed. On the AAA/EAP server, key caching can happen when state is kept on the server. On the NAS or client, key caching can happen when it doesn't destroy keying material right after deriving 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) gets used to make sure each session key is fresh. The mechanism used to generate session keys MUST ensure that disclosure of one session key doesn't help an attacker discover any other session keys 🔐

Limit key scope

Following the principle of least privilege, parties MUST NOT have access to keying material that they don't need 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's 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 lets a recipient toss any message that was recorded during an earlier legit conversation and then sent back like it belongs to the current one. Main character energy: the old message gets no screen time 🚫.

Authenticate all parties

Every party in the AAA key management protocol MUST be authenticated to the other parties it talks to 🔐. The authentication mechanisms MUST keep any secret values used in the process confidential 🤫.

When a secure association protocol sets up session keys, the parties in it MUST identify themselves using identities that make sense in the lower-layer protocol environment that will use those session keys 🧩. This can get messy, because the authenticator and peer might go by different identifiers in the AAA protocol environment than in the lower layer, and that makes authorization decisions hard without a clear key scope 😵‍💫. If the peer's lower-layer identifier is going to be used for authorization decisions, then the pair of identifiers tied to the peer MUST be authorized by the authenticator and/or the AAA server 🎀.

AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] give you a way to identify AAA clients 🪪. The EAP authenticator and AAA client are always co-resident, so that same mechanism works for identifying EAP authenticators too 💜.

When several base stations plus a "controller" (like a WLAN switch) make up one EAP authenticator, the "base station identity" doesn't matter 🙅‍♀️. The EAP method conversation happens between the EAP peer and the EAP server 🗣️. Also, lots of base stations can share the same authenticator identity 🌸. The authenticator identity does matter in the AAA protocol exchange and the secure association protocol conversation, though 👀.

Authentication mechanisms MUST NOT use plaintext passwords 🚷. Passwords can be used as long as they're never sent to another party without confidentiality protection 🔒.

Peer and authenticator authorization

Peer and authenticator authorization MUST be performed ✅. These entities MUST prove they have the right keying material without actually disclosing it 🕵️‍♀️. Authorization is REQUIRED whenever a peer associates with a new authenticator 🦋. The check stops an elevation of privilege attack and makes sure an unauthorized authenticator gets caught 🚨.

Authorizations SHOULD be synchronized between the peer, NAS, and backend authentication server 🔄. Once the AAA key management protocol exchanges are done, all of these parties should have a shared view of the authorizations tied to the other parties 🫶.

Authenticating everyone isn't the whole story, because key management protocols also need to show that the parties are authorized to hold keying material ✨. Proving you have keying material doesn't automatically prove you're allowed to hold it 🙈. For example, in IEEE 802.11i, the 4-way handshake shows that the peer and authenticator both have the same EAP keying material 🤝. But that proof alone doesn't show the backend authentication server authorized the authenticator to have that keying material 😬.

As noted in RFC 3579 in Section 4.3.7, when AAA proxies are involved, one authenticator can impersonate another unless every link in the AAA chain checks for impersonation 🎭. Even with those checks, an authenticator might claim different identities to the peer and to the backend authentication server 💀. As described in RFC 3748 in Section 7.15, channel binding is REQUIRED so the peer can verify that the authenticator's claimed identity is both consistent and correct 🔍.

Keying material confidentiality and integrity

While keeping algorithm independence, the 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 need a robust key naming scheme, especially where key caching is supported 🗂️. The key name gives a way to refer to a key in a protocol so everyone knows which key is being referenced 📛. Things that can't be named can't be managed, bestie 💅. All keys MUST be uniquely named 🔑, and the key name MUST NOT directly or indirectly disclose the keying material 🙊. If the key name isn't based on the keying material, you can be sure it can't help anyone search for the key value 🛑.

Prevent the Domino effect

Compromising a single peer MUST NOT compromise keying material held by any other peer in the system, including session keys and long-term keys 🀄. Likewise, compromising a single authenticator MUST NOT compromise keying material held by any other authenticator in the system 🧱. In a key hierarchy, this means compromising one node must not reveal the information needed to compromise other branches 🌳. Obviously, compromising the root of the key hierarchy will compromise all the keys 😭, but a compromise in one branch MUST NOT result in the compromise of other branches 🚧. This requirement has lots of implications, but two deserve a spotlight 🔦. First, the scope of the keying material must be defined and understood by all parties that communicate with a party holding that material 📜. Second, a party holding keying material in a key hierarchy must not share it with parties tied to other branches of that hierarchy 🙅‍♀️.

Group keys are the obvious exception 👯. Since all group members have a copy of the same key, compromising any one member will expose the group key 💔.

Bind key to its context

Keying material MUST be bound to the right context 🎯. The context includes the following:

  • The manner in which the keying material is expected to be used.
  • The other parties that are expected to have access to the keying material.
  • The expected lifetime of the keying material. The lifetime of a child key SHOULD NOT be greater than the lifetime of its parent in the key hierarchy ⏳.

Any party with legit access to keying material can figure out its context 🕵️. Plus, the protocol MUST ensure that all parties with legit access to keying material share the same context for it 🤝. That means the parties have to be properly identified and authenticated, so everyone who can access the keying material is known 🪪.

The context includes 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 them in the lower layer that will use the session key 🧚.

4. AAA Key Management Recommendations ✨

Acceptable solutions SHOULD meet all of these requirements 💯.

Confidentiality of identity

In many environments, it's important to protect the confidentiality of identities 🫣. In other environments, it isn't important 🤷‍♀️. For this reason, EAP methods are encouraged to provide a mechanism for identity protection of EAP peers, but that protection is not a requirement 🌈.

Authorization restriction

If peer authorization is restricted, the peer SHOULD be made aware of the restriction 📢. Otherwise, the peer may accidentally try to get around the restriction 🙃. For example, authorization restrictions in an IEEE 802.11 environment include:

  • Key lifetimes, where the keying material can only be used for a certain period of time ⏰;
  • SSID restrictions, where the keying material can only be used with a specific IEEE 802.11 SSID 📶;
  • Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID 📍; and
  • Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address 💻.

5. Security Considerations 🔐✨

Okay bestie, this section is the big one 😭 It's basically the guidance for anyone designing AAA key management protocols, and also for anyone building systems that include them. So pay attention 💅

Sometimes more than one party in an AAA key management protocol lives on the same host 🏠 For example, the EAP authenticator and the AAA client are expected to be the same entity. Being colocated means the authenticator can send one unique identity to the AAA server and that same identity to the EAP peer. If both conversations use the same identity, the peer and the AAA server can check that the authenticator is consistent about who it says it is, which helps avoid impersonation attacks 🎭 If the authenticator and AAA client are not colocated, though, their identities will be different, and the key scope won't stay in sync between the EAP peer, the authenticator, and the server. That's a huge red flag 🚩 Lack of key scope synchronization opens the door to a bunch of security vulnerabilities, impersonation included. So a design needs mechanisms that keep the key scope and key naming unambiguous. No vibes-based naming, it has to be clear 💯

The AAA server is a trusted entity 👑 When keying material exists at all, the server establishes it with the peer and then distributes it to the authenticator through the AAA protocol. It's trusted to only hand that keying material to the authenticator it was established with, and it's trusted not to give it to anyone else. In a lot of systems, keying material set up by the EAP peer and the EAP server gets combined with publicly available data to derive other keys. The AAA server is trusted to refrain from deriving those same keys, even though it has all the secret values it would need to do it 🙈 That's a whole lot of trust, so the server really has to be reliable.

The authenticator is also a trusted party 🫶 It's trusted not to pass along keying material it got from the AAA server to any other parties. If the authenticator uses a key derivation function to make extra keying material, it's trusted to hand that derived material only to the appropriate party, the one the peer knows about, and to nobody else. When you do it this way, you have to be careful that the whole key management system still meets every principle in this document. The goal is that keys protecting data are known only by the peer and the authenticator 🔑

EAP is used to authenticate the peer to the AAA/EAP server 🪪 After a successful authentication, the AAA/EAP server authorizes the peer. In lots of situations, that's done by sending keying material to the authenticator and to the peer in separate protocol messages 📨 The authenticator isn't directly authenticated to the peer, though. Instead, the peer figures out the authenticator was authorized by the AAA/EAP server by checking that the authenticator has the same AAA/EAP server-provided keying material. Some systems can do explicit mutual authentication between the authenticator and the peer, and that's desirable because it seriously improves accountability 📈 Accountability is everything, periodt ✨

When MIB modules get developed for AAA protocols or EAP methods, they might include managed objects for keying material 🗂️ Here's the catch: having managed objects tied to keying material gives attackers an extra way to compromise keys, especially if those objects contain the keying material itself 😬 So these MIB modules MUST NOT include objects for private keys or symmetric keys. The same tea applies to the other side of this: these MIB modules MAY include management objects that expose names and context associated with keys, and they MAY provide a means to delete keys 🧹 Expose the names, hide the secrets, and you're good 💖

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.
  • [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.
  • [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.
  • [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.
  • [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>.

Appendix: AAA Key Management History ✨

Okay so, AAA protocols (Authentication, Authorization, and Accounting) were originally built for Network Access Servers (NASes) 💻. In the ARPAnet, the Terminal Access Controller (TAC) let "dumb terminals" get onto the network, and BBN designed the TACACS [RFC0927][RFC1492] AAA protocol under contract to the Defense Data Network Program Management Office (DDN PMO) for that setup 🖥️. [RFC1492] describes a later version of TACACS, not the original one that was widely deployed in ARPAnet and MILNET [DDNN39.2]. Bestie, history is so iconic 🍓.

Then more AAA protocols showed up to support NASes giving Internet access over PPP [RFC1661] 🌐. Once a deployment had more than a modest number of users, it got impractical for every NAS to keep its own list of users and credentials 😩. So new AAA protocols came along, including RADIUS [RFC2865] and Diameter [RFC3588] 🎀. These let one central AAA server authenticate users asking for network access, and also handle authorization and accounting. Main character server energy 👑.

PPP [RFC1661] originally only supported PAP [RFC1334] and CHAP [RFC1661] authentication, but their limitations got obvious fast 🙈. Both PAP and CHAP are unilateral, meaning they only let the NAS authenticate the PPP peer and not the other way around. PAP is a cleartext password scheme, so anyone snooping on the conversation between the PPP peer and NAS can read it 💀. On top of that, PAP creates vulnerabilities inside RADIUS, as described in Section 4.3 of [RFC3579]. Because of all this, PAP is now deprecated 🚫. CHAP is a challenge-response scheme based on MD5, which is better than cleartext passwords, but it doesn't offer mutual authentication, and it's vulnerable to dictionary attacks 😭.

Next, the Encryption Control Protocol (ECP) was added to PPP [RFC1968], and PPP ciphersuites got defined in [RFC2419], [RFC2420], and [RFC3078]. That meant there was suddenly a need to supply keying material for link layer ciphersuites 🔐. Just like with user authentication, setting up static keys on every NAS did not scale well 🥲.

Vendor-specific PPP authentication protocols like MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were built to provide mutual authentication and key derivation [RFC3079] for negotiated ciphersuites 🔑. They were later adapted for PPP-based VPNs [RFC2637]. But just like PAP and CHAP, flaws were later found in these mechanisms too [SM1][SM2] 😤.

Even though PPP could negotiate authentication algorithms, fixing vulnerabilities in authentication mechanisms was still a whole pain, since new code had to be deployed on both the PPP peers and the AAA server 🥴. So to roll out new authentication mechanisms faster, and patch vulnerabilities in existing methods, the Extensible Authentication Protocol (EAP) [RFC3748] was created, along with support for centralized authentication via RADIUS/EAP [RFC3579] ✨.

EAP enabled "pass through" authentication on the NAS 🦋. That means you can deploy new authentication methods, or update existing ones, by changing code only on the EAP peer and the 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 none of them support key derivation 🙅‍♀️. Later methods like EAP-TLS [RFC2716] did support mutual authentication and key derivation 💜.

To provision dynamic keying material for link layer ciphersuites in an environment with centralized authentication, something was needed to carry keying material between the AAA server and the NAS 📦. Vendor-specific RADIUS attributes were developed for this job [RFC2548]. Vulnerabilities were later found in that key wrap technique too, as described in Section 4.3 of [RFC3579] 😬.

In theory, public key authentication mechanisms like EAP-TLS can do mutual authentication and key derivation between the EAP peer and NAS without any AAA key distribution 🧠. In practice though, those pure two-party schemes are rarely deployed 🙃. Running a centralized AAA server cuts down the effort needed to get certificates onto NASes a lot, and even though an AAA server might not be needed for key derivation and possibly authentication, it's still needed for service authorization and accounting 📊.

"Pass-through" authentication and AAA key distribution have stayed popular even as processors and memory got way better 🚀. Along with NAS devices with more capability for enterprise and carrier customers, implementers also made low-cost, high-volume NAS devices like 802.11 Access Points 📶. That caused the resources on an average NAS to grow more slowly than Moore's law 🐢. Even though host operating systems widely support certificate handling and sophisticated key derivation mechanisms like IKEv1 [RFC2409], those security capabilities are rarely deployed on low-end NASes and clients 🥺.

Even on more capable NASes, like VPN servers, centralized authentication and AAA key management have proven popular 💅. For example, one of the big limitations of IKEv1 [RFC2409] was that it didn't integrate with EAP and AAA, so organizations using passwords or authentication tokens needed proprietary extensions to use IPsec VPNs 😤. IKEv2 [RFC4306] fixed these limitations. It handles key derivation only between the VPN client and server, but it supports EAP methods for user authentication 🎉. To cryptographically bind EAP user authentication to keys derived within the IKEv2 exchange, the transport of EAP-derived keys within AAA is required wherever 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 way better because of their contributions 🌸.

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

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 warranty disclaimer is written in full capitals, verbatim, like so:

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 on 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 on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📚.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights can be obtained from the IETF's online 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🌈.

📦 where this page comes from