idnits 2.17.1 draft-housley-aaa-key-mgmt-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1015. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.1X' is mentioned on line 135, but not defined == Missing Reference: 'RFC2284' is mentioned on line 909, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Duplicate reference: RFC1994, mentioned in 'RFC1994', was also mentioned in 'RFC1334'. -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet Draft Vigil Security 4 February 2007 B. Aboba 5 Expires in six months Microsoft 7 Guidance for AAA Key Management 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document provides guidance to designers of AAA key management 36 protocols. The guidance is also useful to designers of systems and 37 solutions that include AAA key management protocols. Given the 38 complexity and difficulty in designing secure, long-lasting key 39 management algorithms and protocols by experts in the field, it is 40 almost certainly inappropriate for IETF working groups without deep 41 expertise in the area to be designing their own key management 42 algorithms and protocols based on Authentication, Authorization and 43 Accounting (AAA) protocols. The guidelines in this document apply to 44 documents requesting publication as IETF RFCs. Further, these 45 guidelines will be useful to other standards development 46 organizations (SDOs) that specify AAA key management. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Specification . . . . . . . . . . . . . . 3 52 1.2. Mandatory to Implement . . . . . . . . . . . . . . . . 3 53 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . 3 54 2. AAA Environment Concerns . . . . . . . . . . . . . . . . 5 55 3. AAA Key Management Requirements . . . . . . . . . . . . 8 56 4. AAA Key Management Recommendations . . . . . . . . . . . 13 57 5. Security Considerations . . . . . . . . . . . . . . . . 13 58 6. Normative References . . . . . . . . . . . . . . . . . . 14 59 7. Informative References . . . . . . . . . . . . . . . . . 14 60 Appendix: AAA Key Management History . . . . . . . . . . . . 19 61 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 62 Authors' Address . . . . . . . . . . . . . . . . . . . . . 21 63 Intellectual Property Statement . . . . . . . . . . . . . . 22 64 Disclaimer of Validity . . . . . . . . . . . . . . . . . . 22 65 Copyright Statement . . . . . . . . . . . . . . . . . . . . 22 67 1. Introduction 69 This document provides architectural guidance to designers of AAA key 70 management protocols. The guidance is also useful to designers of 71 systems and solutions that include AAA key management protocols. 73 AAA Key Management often includes a collection of protocols, one of 74 which is the AAA protocol. Other protocols are used in conjunction 75 with the AAA protocol to provide an overall solution. These other 76 protocols often provide authentication and security association 77 establishment. 79 Given the complexity and difficulty in designing secure, long-lasting 80 key management algorithms and protocols by experts in the field, it 81 is almost certainly inappropriate for IETF working groups without 82 deep expertise in the area to be designing their own key management 83 algorithms and protocols based on Authentication, Authorization and 84 Accounting (AAA) protocols. These guidelines apply to documents 85 requesting publication as IETF RFCs. Further, these guidelines will 86 be useful to other standards development organizations (SDOs) that 87 specify AAA key management that depends on IETF specifications for 88 protocols such as EAP [RFC3748], RADIUS [RFC2865], and Diameter 89 [RFC3588]. 91 In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley 92 gave a presentation on "Key Management in AAA" [H]. That 93 presentation established the vast majority of the requirements 94 contained in this document. Over the last three years, this 95 collection of requirements have become known as the "Housley 96 Criteria". 98 1.1. Requirements Specification 100 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 101 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 102 document, are to be interpreted as described in RFC 2119 [RFC2119]. 104 An AAA key management proposal is not compliant with this 105 specification if it fails to satisfy one or more of the MUST or MUST 106 NOT statements. An AAA key management proposal that satisfies all 107 the MUST, MUST NOT, SHOULD and SHOULD NOT statements is said to be 108 "unconditionally compliant"; one that satisfies all the MUST and MUST 109 NOT statements but not all the SHOULD or SHOULD NOT requirements is 110 said to be "conditionally compliant". 112 1.2. Mandatory to Implement 114 The guidance provided in this document is mandatory to implement. 115 However, it is not mandatory to use. That is, configuration at the 116 time of deployment may result in a deployed implementation that does 117 not conform with all of these requirements. 119 For example, [RFC4072] enables EAP keying material to be delivered 120 from a AAA server to a AAA client without disclosure to third 121 parties. Thus, key confidentiality is mandatory to implement in 122 Diameter [RFC3588]. However, key confidentiality is not mandatory to 123 use. 125 1.3. Terminology 127 This section defines terms that are used in this document. 129 AAA 130 Authentication, Authorization and Accounting (AAA). AAA 131 protocols include RADIUS [RFC2865] and Diameter [RFC3588]. 133 Authenticator 134 The party initiating EAP authentication. The term 135 authenticator is used in [IEEE-802.1X], and authenticator has 136 the same meaning in this document. 138 Backend authentication server 139 A backend authentication server is an entity that provides an 140 authentication service to an authenticator. This terminology 141 is also used in [802.1X]. 143 CHAP 144 Challenge Handshake Authentication Protocol; a one-way 145 challenge/response authentication protocol defined in 146 [RFC1994]. 148 EAP 149 Extensible Authentication Protocol, defined in [RFC3748]. 151 EAP server 152 The entity that terminates the EAP authentication method with 153 the peer. In the case where no backend authentication server 154 is used, the EAP server is part of the authenticator. In the 155 case where the authenticator operates in pass-through mode, the 156 EAP server is located on the backend authentication server. 158 Key Wrap 159 The encryption of one symmetric cryptographic key in another. 160 The algorithm used for the encryption is called a key wrap 161 algorithm or a key encryption algorithm. The key used in the 162 encryption process is called a key-encryption key (KEK). 164 PAP 165 Password Authentication Protocol; a deprecated cleartext 166 password PPP authentication protocol, originally defined in 167 [RFC1334]. 169 Party 170 A party is a processing entity which can be identified as a 171 single role in a protocol. 173 Peer 174 The end of the link that responds to the authenticator. In 175 [802.1X], this end is known as the supplicant. 177 PPP 178 Point-to-Point Protocol, defined in [RFC1661], provides support 179 for multiprotocol serial datalinks. PPP is the primary IP 180 datalink used for dial-in NAS connection service. 182 Secure Association Protocol 183 A protocol for managing security associations derived from EAP 184 and/or AAA exchanges. The protocol establishes a security 185 association, which includes symmetric keys and a context for 186 the use of the keys. An example of a Secure Association 187 Protocol is the 4-way handshake defined within [802.11i]. 189 Session Keys 190 Keying material used to protect data exchanged after 191 authentication has successfully completed, using the negotiated 192 ciphersuite. 194 Network Access Server (NAS) 195 A device which provides an access service for a user to a 196 network. The service may be a network connection, or a value 197 added service such as terminal emulation, as described in 198 [RFC2881]. 200 4-Way Handshake 201 A Secure Association Protocol, defined in [802.11i], which 202 confirms mutual possession of a Pairwise Master Key by two 203 parties and distributes a Group Key. 205 2. AAA Environment Concerns 207 Examples of serious flaws plague the history of key management 208 protocol development, starting with the very first attempt to define 209 a key management protocol in the open literature, which was published 210 in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the 211 fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in 212 the original 1978 version, in an area not affected by the 1981/1994 213 issue. All of these flaws were blindingly obvious once described, 214 yet no one spotted them earlier. Note that the original protocol, if 215 it were revised to employ certificates, which of course had yet to be 216 invented, was only three messages. Many proposed AAA key management 217 schemes are significantly more complicated. 219 This bit of history shows that key management protocols are subtle. 220 Experts can easily miss a flaw. As a result, peer review by multiple 221 experts is essential, especially since many proposed AAA key 222 management schemes are significantly more complicated, In addition, 223 formal methods can help uncover problems [M]. 225 AAA-based key management is being incorporated into standards 226 developed by the IETF and other standards development organizations 227 (SDOs), such as IEEE 802. However, due to ad hoc development of AAA- 228 based key management, AAA-based key distribution schemes have poorly 229 understood security properties, even when well-studied cryptographic 230 algorithms are employed. More academic research is needed to fully 231 understand the security properties of AAA-based key management in the 232 diverse protocol environments where it is being employed today. In 233 the absence of such research results, pragmatic guidance based on 234 sound security engineering principles is needed. 236 In addition to the need for interoperability, cryptographic algorithm 237 independent solutions are greatly preferable. Without algorithm 238 independence, the AAA-based key management protocol must be changed 239 whenever a problem is discovered with any of the selected algorithms. 240 As AAA history shows, problems are inevitable. Problems can surface 241 due to age or design failure. 243 DES [FIPS46] was a well designed encryption algorithm, and it 244 provided protection for many years. Yet, the 56-bit key size was 245 eventually overcome by Moore's Law. No significant cryptographic 246 deficiencies have been discovered in DES. 248 The history of AAA underlines the importance of algorithm 249 independence as flaws have been found in authentication mechanisms 250 such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos 251 [W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates 252 use of the MD5 algorithm for integrity protection, which has known 253 deficiencies, and RADIUS has no provisions to negotiate substitute 254 algorithms. Similarly, the vendor-specific key wrap mechanism 255 defined in [RFC2548] has no provisions to negotiate substitute 256 algorithms. 258 The principle of least privilege is an important design guideline. 259 This principle requires that a party be given no more privilege than 260 necessary to perform the task assigned to them. Ensuring least 261 privilege requires clear identification of the tasks assigned to each 262 party, and explicit determination of the minimum set of privileges 263 required to perform those tasks. Only those privileges necessary to 264 perform the tasks are granted. By denying to parties unneeded 265 privileges, those denied privileges cannot be used to circumvent 266 security policy or enable attackers. With this principle in mind, 267 AAA key management schemes need to be designed in a manner where each 268 party has only the privileges necessary to perform their role. That 269 is, no party should have access to any keying material that is not 270 needed to perform their own role. A party has access to a particular 271 key if it has access to all of the secret information needed to 272 derive it. 274 EAP is being used in new ways. The inclusion of support for EAP 275 within IKEv2 and the standardization of robust Wireless LAN security 276 [802.11i] based on EAP are two examples. EAP has also been proposed 277 within IEEE 802.16e [802.16e] and by the IETF PANA Working Group. 278 AAA-based key management is being incorporated into standards 279 developed by the IETF and other standards development organizations 280 (SDOs), such as IEEE 802. However, due to ad hoc development of AAA- 281 based key management, AAA-based key distribution schemes have poorly 282 understood security properties, even when well-studied cryptographic 283 algorithms are employed. More academic research is needed to fully 284 understand the security properties of AAA-based key management in the 285 diverse protocol environments where it is being employed today. In 286 the absence of research results, pragmatic guidance based on sound 287 security engineering principles is needed. 289 EAP selects one end-to-end authentication mechanism. The mechanisms 290 defined in [RFC3748] only support unilateral authentication, and they 291 do not support mutual authentication or key derivation. As a result, 292 these mechanisms do not fulfill the security requirements for many 293 deployment scenarios, including Wireless LAN authentication 294 [RFC4017]. 296 To ensure adequate security and interoperability, EAP applications 297 need to specify mandatory-to-implement algorithms. As described in 298 [RFC3748], EAP methods seeking publication as an IETF RFC need to 299 document their security claims. However, some EAP methods are not 300 based on well-studied models, which makes the validity of these 301 security claims difficult to determine. 303 In the context of EAP, the EAP peer and server are the parties 304 involved in the EAP method conversation, and they gain access to key 305 material when the conversation completes successfully. However, the 306 lower layer needs keying material to provide the desired protection 307 through the use of cryptographic mechanisms. As a result, a "pass- 308 through" mode is used to provide the keying material, and the lower 309 layer keying material is replicated from the AAA server to the 310 authenticator. The only parties authorized to obtain all of the 311 keying material are the EAP peer and server; the authenticator 312 obtains only the keying material necessary for its specific role. No 313 other party can obtain direct access to any of the keying material; 314 however, other parties may receive keys that is derived from this 315 keying material for a specific purpose as long as the requirements 316 defined in the next section are met. 318 3. AAA Key Management Requirements 320 The overall goal of AAA key management is to provide cryptographic 321 keying material in situations where key derivation cannot be used by 322 the peer and authenticator. It may not be possible because the 323 authenticator lacks computational power, because it lacks the 324 resources necessary to implement the various authentication 325 mechanisms that might be required, or because it is undesirable for 326 each authenticator to engage in a separate key management 327 conversation. 329 This section provides guidance to AAA protocol designers, EAP method 330 designers, and security association protocol designers. Acceptable 331 solutions MUST meet all of these requirements. 333 Cryptographic algorithm independent 335 The AAA key management protocol MUST be cryptographic algorithm 336 independent. However, an EAP method MAY depend on a specific 337 cryptographic algorithm. The ability to negotiate the use of a 338 particular cryptographic algorithm provides resilience against 339 compromise of a particular cryptographic algorithm. Algorithm 340 independence is also REQUIRED with a Secure Association 341 Protocol if one is defined. This is usually accomplished by 342 including an algorithm identifier and parameters in the 343 protocol, and by specifying the algorithm requirements in the 344 protocol specification. While highly desirable, the ability to 345 negotiate key derivation functions (KDFs) is not required. For 346 interoperability, at least one suite of mandatory-to-implement 347 algorithms MUST be selected. Note that without protection by 348 IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] 349 does not meet this requirement, since the integrity protection 350 algorithm can not be negotiated. 352 This requirement does not mean that a protocol must support 353 both public-key and symmetric-key cryptographic algorithms. It 354 means that the protocol needs to be structured in such a way 355 that multiple public-key algorithms can be used whenever a 356 public-key algorithm is employed. Likewise, it means that the 357 protocol needs to be structured in such a way that multiple 358 symmetric-key algorithms can be used whenever a symmetric-key 359 algorithm is employed. 361 Strong, fresh session keys 363 While preserving algorithm independence, session keys MUST be 364 strong and fresh. Each session deserves an independent session 365 key. Fresh keys are required even when a long replay counter 366 (that is, one that "will never wrap") is used to ensure that 367 loss of state does not cause the same counter value to be used 368 more than once with the same session key. 370 Some EAP methods are capable of deriving keys of varying 371 strength, and these EAP methods MUST permit the generation of 372 keys meeting a minimum equivalent key strength. BCP 86 373 [RFC3766] offers advice on appropriate key sizes. The National 374 Institute for Standards and Technology (NIST) also offers 375 advice on appropriate key sizes in [SP800-57]. 377 A fresh cryptographic key is one that is generated specifically 378 for the intended use. In this situation, a secure association 379 protocol is used to establish session keys. The AAA protocol 380 and EAP method MUST ensure that the keying material supplied as 381 an input to session key derivation is fresh, and the secure 382 association protocol MUST generate a separate session key for 383 each session, even if the keying material provided by EAP is 384 cached. A cached key persists after the authentication 385 exchange has completed. For the AAA/EAP server, key caching 386 can happen when state is kept on the server. For the NAS or 387 client, key caching can happen when the NAS or client does not 388 destroy keying material immediately following the derivation of 389 session keys. 391 Session keys MUST NOT be dependent on one another. Multiple 392 session keys may derived from a higher-level shared secret as 393 long as a one-time value, usually called a nonce, is used to 394 ensure that each session key is fresh. The mechanism used to 395 generate session keys MUST ensure that the disclosure of one 396 session key does not aid the attacker in discovering any other 397 session keys. 399 Limit key scope 401 Following the principle of least privilege, parties MUST NOT 402 have access to keying material that is not needed to perform 403 their role. A party has access to a particular key if it has 404 access to all of the secret information needed to derive it. 406 Any protocol that is used to establish session keys, MUST 407 specify the scope for session keys, clearly identifying the 408 parties to whom the session key is available. 410 Replay detection mechanism 412 The AAA key management protocol exchanges MUST be replay 413 protected, including AAA, EAP and Secure Association Protocol 414 exchanges. Replay protection allows a protocol message 415 recipient to discard any message that was recorded during a 416 previous legitimate dialogue and presented as though it 417 belonged to the current dialogue. 419 Authenticate all parties 421 Each party in the AAA key management protocol MUST be 422 authenticated to the other parties with whom they communicate. 423 Authentication mechanisms MUST maintain the confidentiality of 424 any secret values used in the authentication process. 426 When a secure association protocol is used to establish session 427 keys, the parties involved in the secure association protocol 428 MUST identify themselves using identities that are meaningful 429 in the lower layer protocol environment that will employ the 430 session keys. In this situation, the authenticator and peer 431 may be known by different identifiers in the AAA protocol 432 environment and the lower layer protocol environment, making 433 authorization decisions difficult without a clear key scope. 434 If the lower layer identifier of the peer will be used to make 435 authorization decisions, then the pair of identifiers 436 associated with the peer MUST be authorized by the 437 authenticator and/or the AAA server. 439 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588] 440 provide a mechanism for the identification of AAA clients; 441 since the EAP authenticator and AAA client are always co- 442 resident, this mechanism is applicable to the identification of 443 EAP authenticators. 445 When multiple base stations and a "controller" (such as a WLAN 446 switch) comprise a single EAP authenticator, the "base station 447 identity" is not relevant; the EAP method conversation takes 448 place between the EAP peer and the EAP server. Also, many base 449 stations can share the same authenticator identity. The 450 authenticator identity is important in the AAA protocol 451 exchange and the secure association protocol conversation. 453 Authentication mechanisms MUST NOT employ plaintext passwords. 454 Passwords may be used provided that they are not sent to 455 another party without confidentiality protection. 457 Peer and authenticator authorization 459 Peer and authenticator authorization MUST be performed. These 460 entities MUST demonstrate possession of the appropriate keying 461 material, without disclosing it. Authorization is REQUIRED 462 whenever a peer associates with a new authenticator. The 463 authorization checking prevents an elevation of privilege 464 attack, and it ensures that an unauthorized authenticator is 465 detected. 467 Authorizations SHOULD be synchronized between the peer, NAS, 468 and backend authentication server. Once the AAA key management 469 protocol exchanges are complete, all of these parties should 470 hold a common view of the authorizations associated the other 471 parties. 473 In addition to authenticating all parties, key management 474 protocols need to demonstrate that the parties are authorized 475 to possess keying material. Note that proof of possession of 476 keying material does not necessarily prove authorization to 477 hold that keying material. For example, within an IEEE 478 802.11i, the 4-way handshake demonstrates that both the peer 479 and authenticator possess the same EAP keying material. 480 However, by itself, this possession proof does not demonstrate 481 that the authenticator was authorized by the backend 482 authentication server to possess that keying material. As 483 noted in RFC 3579 in section 4.3.7, where AAA proxies are 484 present, it is possible for one authenticator to impersonate 485 another, unless each link in the AAA chain implements checks 486 against impersonation. Even with these checks in place, an 487 authenticator may still claim different identities to the peer 488 and the backend authentication server. As described in RFC 489 3748 in section 7.15, channel binding is required to enable the 490 peer to verify that the authenticator claim of identity is both 491 consistent and correct. 493 Keying material confidentiality and integrity 495 While preserving algorithm independence, confidentiality and 496 integrity of all keying material MUST be maintained. 498 Confirm ciphersuite selection 500 The selection of the "best" ciphersuite SHOULD be securely 501 confirmed. The mechanism SHOULD detect attempted roll back 502 attacks. 504 Uniquely name keys 506 AAA key management proposals require a robust key naming 507 scheme, particularly where key caching is supported. The key 508 name provides a way to refer to a key in a protocol so that it 509 is clear to all parties which key is being referenced. Objects 510 that cannot be named cannot be managed. All keys MUST be 511 uniquely named, and the key name MUST NOT directly or 512 indirectly disclose the keying material. If the key name is 513 not based on the keying material, then one can be sure that it 514 cannot be used to assist in a search for the key value. 516 Prevent the Domino effect 518 Compromise of a single peer MUST NOT compromise keying material 519 held by any other peer within the system, including session 520 keys and long-term keys. Likewise, compromise of a single 521 authenticator MUST NOT compromise keying material held by any 522 other authenticator within the system. In the context of a key 523 hierarchy, this means that the compromise of one node in the 524 key hierarchy must not disclose the information necessary to 525 compromise other branches in the key hierarchy. Obviously, the 526 compromise of the root of the key hierarchy will compromise all 527 of the keys; however, a compromise in one branch MUST NOT 528 result in the compromise of other branches. There are many 529 implications of this requirement; however, two implications 530 deserve highlighting. First, the scope of the keying material 531 must be defined and understood by all parties that communicate 532 with a party that holds that keying material. Second, a party 533 that holds keying material in a key hierarchy must not share 534 that keying material with parties that are associated with 535 other branches in the key hierarchy. 537 Group keys are an obvious exception. Since all members of the 538 group have a copy of the same key, compromise of any one of the 539 group members will result in the disclosure of the group key. 541 Bind key to its context 543 Keying material MUST be bound to the appropriate context. The 544 context includes the following. 546 o The manner in which the keying material is expected to 547 be used. 549 o The other parties that are expected to have access to 550 the keying material. 552 o The expected lifetime of the keying material. Lifetime 553 of a child key SHOULD NOT be greater than the lifetime of 554 its parent in the key hierarchy. 556 Any party with legitimate access to keying material can 557 determine its context. In addition, the protocol MUST ensure 558 that all parties with legitimate access to keying material have 559 the same context for the keying material. This requires that 560 the parties are properly identified and authenticated, so that 561 all of the parties that have access to the keying material can 562 be determined. 564 The context will include the peer and NAS identities in more 565 than one form. One (or more) name form is needed to identify 566 these parties in the authentication exchange and the AAA 567 protocol. Another name form may be needed to identify these 568 parties within the lower layer that will employ the session 569 key. 571 4. AAA Key Management Recommendations 573 Acceptable solutions SHOULD meet all of these requirements. 575 Confidentiality of Identity 577 In many environments it is important to provide confidentiality 578 protection for identities. However, this is not important in 579 other environments. For this reason, EAP methods are 580 encouraged to provide a mechanism for identity protection of 581 EAP peers, but such protection is not a requirement. 583 Authorization restriction 585 If peer authorization is restricted, then the peer SHOULD be 586 made aware of the restriction. Otherwise, the peer may 587 inadvertently attempt to circumvent the restriction. For 588 example, authorization restrictions in an IEEE 802.11 589 environment include: 591 o Key lifetimes, where the keying material can only be used 592 for a certain period of time; 594 o SSID restrictions, where the keying material can only be 595 used with a specific IEEE 802.11 SSID; 597 o Called-Station-ID restrictions, where the keying material 598 can only be used with a single IEEE 802.11 BSSID; and 600 o Calling-Station-ID restrictions, where the keying material 601 can only be used with a single peer IEEE 802 MAC address. 603 5. Security Considerations 605 This document provides architectural guidance to designers of AAA key 606 management protocols. The guidance is also useful to designers of 607 systems and solutions that include AAA key management protocols. 609 In some deployment scenarios, more than one party in the AAA key 610 management protocol can reside on the same host. For example, the 611 EAP authenticator and AAA client are expected to reside on the same 612 entity. Colocation enables a single unique authenticator identity to 613 be sent by the authenticator to the AAA server as well as by the 614 authenticator to the EAP peer. Use of the same identity in both 615 conversations enables the peer and AAA server to confirm that the 616 authenticator is consistent in its identification, avoiding potential 617 impersonation attacks. If the authenticator and AAA client are not 618 colocated, then the authenticator and AAA client identities will 619 differ, and the key scope will not be synchronized between the EAP 620 peer, authenticator and server. Lack of key scope synchronization 621 enables a number of security vulnerabilities, including 622 impersonation. For this reason, a design needs to include mechanisms 623 to ensure that the key scope and key naming are unambiguous. 625 The AAA server is a trusted entity. When keying material is present 626 at all, it establishes keying material with the peer and distributes 627 keying material to the authenticator using the AAA protocol. It is 628 trusted to only distribute keying material to the authenticator that 629 was established with the peer, and it is trusted to provide that 630 keying material to no other parties. In many systems, keying 631 material established by the EAP peer and EAP server are combined with 632 publicly available data to derive other keys. The AAA server is 633 trusted to refrain from deriving these same keys even though it has 634 access to the secret values that are needed to do so. 636 The authenticator is also a trusted party. The authenticator is 637 trusted not to distribute keying material provided by the AAA server 638 to any other parties. If the authenticator uses a key derivation 639 function to derive additional keying material, the authenticator is 640 trusted to distribute the derived keying material only to the 641 appropriate party that is known to the peer, and no other party. 642 When this approach is used, care must be taken to ensure that the 643 resulting key management system meets all of the principles in this 644 document, confirming that keys used to protect data are to be known 645 only by the peer and authenticator. 647 EAP is used to authenticate the peer to the AAA/EAP Server. 648 Following successful authentication, the AAA/EAP server authorizes 649 the peer. In many situations, this is accomplished by sending keying 650 material to the authenticator and the peer in separate protocol 651 messages. The authenticator is not directly authenticated to the 652 peer. Rather, the peer determines that the authenticator has been 653 authorized by the AAA/EAP Server by confirming that the authenticator 654 has the same AAA/EAP Server-provided keying material. In some 655 systems, explicit authenticator and peer mutual authentication is 656 possible. This is desirable since it greatly improves 657 accountability. 659 When MIB modules are developed for AAA protocols or EAP methods, 660 these MIB modules might include managed objects for keying material. 661 The existence of managed objects associated with keying material 662 offers an additional avenue for key compromise if these objects 663 include the keying material itself. Therefore, these MIB modules 664 MUST NOT include objects for private keys or symmetric keys. 665 However, these MIB modules MAY include management objects that expose 666 names and context associated with keys, and they MAY provide a means 667 to delete keys. 669 6. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", RFC 2119, March, 1997. 674 7. Informative References 676 [802.1X] IEEE Standards for Local and Metropolitan Area Networks: 677 Port based Network Access Control, IEEE Std 802.1X-2004, 678 December 2004. 680 [802.11i] Institute of Electrical and Electronics Engineers, 681 "Supplement to Standard for Telecommunications and 682 Information Exchange Between Systems -- LAN/MAN Specific 683 Requirements - Part 11: Wireless LAN Medium Access 684 Control (MAC) and Physical Layer (PHY) Specifications: 685 Specification for Enhanced Security", IEEE 802.11i, July 686 2004. 688 [802.16e] Institute of Electrical and Electronics Engineers, 689 "Supplement to Standard for Telecommunications and 690 Information Exchange Between Systems -- LAN/MAN Specific 691 Requirements - Part 16: Air Interface for Fixed and 692 Mobile Broadband Wireless Access Systems -- Amendment for 693 Physical and Medium Access Control Layers for Combined 694 Fixed and Mobile Operation in Licensed Bands", Draft, 695 IEEE 802.16e/D8, May 2005. 697 [AN] M. Abadi and R. Needham, "Prudent Engineering Practice 698 for Cryptographic Protocols", Proc. IEEE Computer Society 699 Symposium on Research in Security and Privacy, May 1994. 701 [B] Brewin, B., "LEAP attack tool author says he wants to 702 alert users to risks", Computerworld, October 17, 2003. 704 [BM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos 705 authentication system", Proceedings of the 1991 Winter 706 USENIX Conference, pp. 253-267, 1991. 708 [DDNN39.2] DCA DDN Program Management Office, "MILNET TAC Access 709 Control", Defense Data Network Newsletter, DDN News 39, 710 Special Issue, 26 Apr 1985. 711 [http://sunsite.uakom.sk/doc/rfc/ddn-news.n39.2] 713 [DLS] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: 714 Kerberos 4 session keys", Proceedings of the Internet 715 Society Network and Distributed System Security 716 Symposium, pp. 60-70, March 1997. 718 [DS] D. Denning and G. Sacco. "Timestamps in key distributed 719 protocols", Communication of the ACM, 24(8):533--535, 720 1981. 722 [FIPS46] Federal Information Processing Standards Publication 723 (FIPS PUB) 46, Data Encryption Standard, 1977 January 15. 725 [H] Housley, R., "Key Management in AAA", Presentation to the 726 AAA WG at IETF 56, March 2003. 727 [http://www.ietf.org/proceedings/03mar/slides/aaa-5/ 728 index.html] 730 [L] G. Lowe. "An attack on the Needham-Schroeder public key 731 authentication protocol", Information Processing Letters, 732 56(3):131--136, November 1995. 734 [M] Meadows, C., "Analysis of the Internet Key Exchange 735 Protocol using the NRL Protocol Analyser", Proceedings of 736 the 1999 IEEE Symposium on Security & Privacy, Oakland, 737 CA, USA, IEEE Computer Society, May 1999. 738 [http://chacs.nrl.navy.mil/publications/CHACS/1999/ 739 1999meadows-IEEE99.pdf] 741 [NS] R. Needham and M. Schroeder. "Using encryption for 742 authentication in large networks of computers", 743 Communications of the ACM, 21(12), December 1978. 745 [RFC0927] Anderson, B.A., "TACACS user identification Telnet 746 option", RFC 927, December 1984. 748 [RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols", 749 RFC 1334, October 1992, Obsoleted by RFC 1994. 751 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes 752 Called TACACS", RFC 1492, July 1993. 754 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 755 1661, July 1994. 757 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, 758 June 1996. 760 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 761 Protocol (CHAP)", RFC 1994, August 1996. 763 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 764 (IKE)", RFC 2409, November 1998. 766 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption 767 Protocol, Version 2 (DESE-bis)", RFC 2419, September 768 1998. 770 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol 771 (3DESE)", RFC 2420, September 1998. 773 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 774 RFC 2433, October 1998. 776 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 777 RFC 2548, March 1999. 779 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 780 W. and G. Zorn, "Point-to-Point Tunneling Protocol 781 (PPTP)", RFC 2637, July 1999. 783 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 784 Protocol", RFC 2716, October 1999. 786 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 787 2759, January 2000. 789 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 790 "Remote Authentication Dial In User Service (RADIUS)", 791 RFC 2865, June 2000. 793 [RFC2881] D. Mitton, M. Beadles, "Network Access Server 794 Requirements Next Generation (NASREQNG) NAS Model", RFC 795 2881, July 2000. 797 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point 798 Encryption (MPPE) Protocol", RFC 3078, March 2001. 800 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to- 801 Point Encryption (MPPE)", RFC 3079, March 2001. 803 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 804 Dial In User Service) Support For Extensible 805 Authentication Protocol (EAP)", RFC 3579, September 2003. 807 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 808 Arkko, "Diameter Base Protocol", RFC 3588, September 809 2003. 811 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 812 Levkowetz, "Extensible Authentication Protocol (EAP)", 813 RFC 3748, June 2004. 815 [RFC3766] Orman, H. and P. Hoffman, "Determining Strength for 816 Public Keys Used For Exchanging Symmetric Keys", RFC 817 3766, April 2004. 819 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible 820 Authentication Protocol (EAP) Method Requirements for 821 Wireless LANs", RFC 4017, March 2005. 823 [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter 824 Extensible Authentication Protocol (EAP) Application", 825 RFC 4072, August 2005. 827 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 828 Protocol", RFC 4306, December 2005. 830 [SM1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 831 Point-to-Point Tunneling Protocol", Proceedings of the 832 5th ACM Conference on Communications and Computer 833 Security, ACM Press, November 1998. 835 [SM2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 836 PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, 837 Springer-Verlag, 1999, pp. 192-203. 839 [SP800-57] National Institute of Standards and Technology, 840 "Recommendation for Key Management", Special Publication 841 800-57, May 2006. 843 [W] Wu, T., "A Real-World Analysis of Kerberos Password 844 Security", Proceedings of the 1999 ISOC Network and 845 Distributed System Security Symposium, 846 [http://www.isoc.org/isoc/conferences/ndss/99/ 847 proceedings/papers/wu.pdf] 849 Appendix: AAA Key Management History 851 Protocols for Authentication, Authorization and Accounting (AAA) were 852 originally developed to support deployments of Network Access Servers 853 (NASes). In the ARPAnet, the Terminal Access Controller (TAC) 854 provided a means for "dumb terminals" to access the network, and the 855 TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN under 856 contract to the Defense Data Network Program Management Office (DDN 857 PMO) for this environment. [RFC1492] documents a later version of 858 TACACS, not the original version that was widely deployed in ARPAnet 859 and MILNET [DDNN39.2]. 861 Later, additional AAA protocols were developed to support deployments 862 of NASes providing access to the Internet via PPP [RFC1661]. In 863 deployments supporting more than a modest number of users, it became 864 impractical for each NAS to contain its own list of users and 865 associated credentials. As a result, additional AAA protocols were 866 developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These 867 protocols enabled a central AAA server to authenticate users 868 requesting network access, as well as providing authorization and 869 accounting. 871 While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP 872 [RFC1661] authentication, the limitations of these authentication 873 mechanisms became apparent. For example, both PAP and CHAP are 874 unilateral authentication schemes supporting only authentication of 875 the PPP peer to the NAS. Since PAP is a cleartext password scheme, 876 it is vulnerable to snooping by an attacker with access to the 877 conversation between the PPP peer and NAS. In addition, the use of 878 PAP creates vulnerabilities within RADIUS as described in Section 4.3 879 of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a 880 challenge-response scheme based on MD5, offers better security than 881 cleartext passwords, it does not provide for mutual authentication, 882 and CHAP is vulnerable to dictionary attack. 884 With the addition of the Encryption Control Protocol (ECP) to PPP 885 [RFC1968] as well as the definition of PPP ciphersuites in [RFC2419] 886 [RFC2420][RFC3078] the need arose to provide keying material for use 887 with link layer ciphersuites. As with user authentication, 888 provisioning of static keys on each NAS did not scale well. 890 Additional vendor-specific PPP authentication protocols such as MS- 891 CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide 892 mutual authentication as well as key derivation [RFC3079] for use 893 with negotiated ciphersuites, and they were subsequently adapted for 894 use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were 895 subsequently found in these new mechanisms [SM1][SM2]. 897 Even though PPP provided for negotiation of authentication 898 algorithms, addressing the vulnerabilities found in authentication 899 mechanisms still proved painful, since new code needed to be deployed 900 on PPP peers as well as on the AAA server. In order to enable more 901 rapid deployment of new authentication mechanisms, as well as fixes 902 for vulnerabilities found in existing methods, the Extensible 903 Authentication Protocol (EAP) [RFC3748] was developed, along with 904 support for centralized authentication via RADIUS/EAP [RFC3579]. 906 By enabling "pass through" authentication on the NAS, EAP enabled 907 deployment of new authentication methods or updates to existing 908 methods by revising code only on the EAP peer and AAA server. The 909 initial authentication mechanisms defined in [RFC2284] 910 (MD5-Challenge, One-Time Password (OTP), and Generic Token Card 911 (GTC)) only supported unilateral authentication, and these mechanisms 912 do not support key derivation. Subsequent authentication methods 913 such as EAP-TLS [RFC2716] supported mutual authentication and key 914 derivation. 916 In order to support the provisioning of dynamic keying material for 917 link layer ciphersuites in an environment supporting centralized 918 authentication, a mechanism was needed for the transport of keying 919 material between the AAA server and NAS. Vendor-specific RADIUS 920 attributes were developed for this purpose [RFC2548]. 921 Vulnerabilities were subsequently found in the key wrap technique, as 922 described in Section 4.3 of [RFC3579]. 924 In theory, public key authentication mechanisms such as EAP-TLS are 925 capable of supporting mutual authentication and key derivation 926 between the EAP peer and NAS without requiring AAA key distribution. 927 However, in practice such pure two-party schemes are rarely deployed. 928 Operation of a centralized AAA server significantly reduces the 929 effort required to deploy certificates to NASes, and even though a 930 AAA server may not be required for key derivation and possibly 931 authentication, its participation is required for service 932 authorization and accounting. 934 "Pass-through" authentication and AAA key distribution has retained 935 popularity even in the face of rapid improvements in processor and 936 memory capabilities. In addition to producing NAS devices of 937 increased capability for enterprise and carrier customers, 938 implementers have also produced low cost/high volume NAS devices such 939 as 802.11 Access Points, causing the resources available on an 940 average NAS to increase more slowly than Moore's law. Despite 941 widespread support for certificate handling and sophisticated key 942 derivation mechanisms such as IKEv1 [RFC2409] within host operating 943 systems, these security capabilities are rarely deployed on low-end 944 NASes and clients. 946 Even on more capable NASes, such as VPN servers, centralized 947 authentication and AAA key management has proven popular. For 948 example, one of the major limitations of IKEv1 [RFC2409] was the lack 949 of integration with EAP and AAA, requiring proprietary extensions to 950 enable use of IPsec VPNs by organizations deploying password or 951 authentication tokens. These limitations were addressed in IKEv2 952 [RFC4306], which while handling key derivation solely between the VPN 953 client and server, supports EAP methods for user authentication. In 954 order to enable cryptographic binding of EAP user authentication to 955 keys derived within the IKEv2 exchange, the transport of EAP-derived 956 keys within AAA is required where the selected EAP method supports 957 key derivation. 959 Acknowledgments 961 Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their 962 quality review and encouragement. 964 Thanks to the IETF AAA Working Group and the IETF EAP Working Group 965 for their review and comment. The document is greatly improved by 966 their contribution. 968 Authors' Address 970 Russell Housley 971 Vigil Security, LLC 972 918 Spring Knoll Drive 973 Herndon, VA 20170 974 USA 975 Email: housley@vigilsec.com 976 Phone: +1 703-435-1775 977 Fax: +1 703-435-1274 979 Bernard Aboba 980 Microsoft Corporation 981 One Microsoft Way 982 Redmond, WA 98052 983 USA 984 Email: bernarda@microsoft.com 985 Phone: +1 425-706-6605 986 Fax: +1 425-936-7329 988 Intellectual Property Statement 990 The IETF has been notified of intellectual property rights claimed in 991 regard to some or all of the specification contained in this 992 document. For more information consult the online list of claimed 993 rights. 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; nor does it represent that it has 1000 made any independent effort to identify any such rights. Information 1001 on the procedures with respect to rights in RFC documents can be 1002 found in BCP 78 and BCP 79. 1004 Copies of IPR disclosures made to the IETF Secretariat and any 1005 assurances of licenses to be made available, or the result of an 1006 attempt made to obtain a general license or permission for the use of 1007 such proprietary rights by implementers or users of this 1008 specification can be obtained from the IETF on-line IPR repository at 1009 http://www.ietf.org/ipr. 1011 The IETF invites any interested party to bring to its attention any 1012 copyrights, patents or patent applications, or other proprietary 1013 rights that may cover technology that may be required to implement 1014 this standard. Please address the information to the IETF at 1015 ietf-ipr@ietf.org. 1017 Disclaimer of Validity 1019 This document and the information contained herein are provided on an 1020 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1021 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1022 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1023 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1024 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1025 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1027 Copyright Statement 1029 Copyright (C) The IETF Trust (2007). 1031 This document is subject to the rights, licenses and restrictions 1032 contained in BCP 78, and except as set forth therein, the authors 1033 retain all their rights.