idnits 2.17.1 draft-walker-aaa-key-distribution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 10) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 67 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- The document date (April 15, 2002) is 8037 days in the past. Is this intentional? 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: 'RFC2026' is mentioned on line 18, but not defined == Missing Reference: 'RFC2119' is mentioned on line 71, but not defined == Unused Reference: 'PROB' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'TRANS' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'DIAM' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'CMS' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'TTLS' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'PEAP' is defined on line 514, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'PROB' == Outdated reference: A later version (-12) exists of draft-ietf-aaa-transport-05 == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-08 == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-08 -- No information found for draft-ietf-aaa-diameter-cms - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CMS' == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-01 -- Possible downref: Normative reference to a draft: ref. 'TTLS' == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-02 -- Possible downref: Normative reference to a draft: ref. 'PEAP' Summary: 6 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jesse Walker 3 Expiration: December 2002 Intel Corporation 4 File: draft-walker-aaa-key-distribution-00.txt Russ Housley 5 RSA Labs 6 Nancy Cam-Winget 8 AAA Key Distribution 9 Last Updated: April 15, 2002 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be 28 accessed at http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This memo describes problems with the current AAA NASREQ key 41 distribution mechanisms, and proposes enhancements to the NASREQ key 42 distribution model to address these problems. 44 Please send comments on this document to the aaa-wg@merit.edu mailing 45 list. 47 1. Introduction 49 The IETF AAA Working Group is developing solutions for 50 Authentication, Authorization and Accounting as applied to network 51 access. The AAA Working Group has defined protocols addressing the 52 network access needs specified by the NASREQ, MOBILE IP, and ROAMOPS 53 Working Groups as well as TIA 45.6. The solution specified by the 54 AAA Working Group is also thought to address the needs of IEEE 55 802.11 wireless networks. The solution is intended to augment and 56 eventually replace RADIUS. 58 One area under the AAA Working Group's purview is the subject of 59 session key distribution. For the purposes here, a session key is a 60 cryptographic key that is used either directly or indirectly to 61 protect traffic exchanged over a link between a Network Access Server 62 (NAS) and one of its clients. [NASREQ] describes the key exchange 63 mechanism. This document analyzes the NASREQ key distribution 64 mechanism, identifies a number of security weaknesses, and proposes 65 some enhancements that rectify the identified weaknesses. 67 1.1. Requirements Terminology 69 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 70 "MAY" that appear in this document are to be interpreted as described 71 in [RFC2119]. 73 2. Description of NASREQ Key Distribution 75 [NASREQ] defines session key distribution from an AAA server to a 76 NAS. The model (or models) it uses are never explicitly specified, 77 but it is possible to infer the model from the documentation 78 available. 80 The purpose of NASREQ key distribution is to securely establish a 81 session key between the NAS and the NAS client. The AAA server may 82 distribute more than one key to the NAS, each to provide different 83 functions. For instance, it can distribute both encryption and data 84 authenticity keys, or send and receive keys, or master keys that can 85 be used to derive other keys. 87 [NASREQ] allows the AAA server to distribute a key to the NAS client 88 using EAP, but does not specify how this is accomplished. EAP fails 89 to specify mechanisms. As a result, all mechanisms assume that the 90 AAA server and the NAS client already share a key that may be used 91 directly to protect the link between the NAS and the NAS client, and 92 so it is unnecessary to distribute any key to the NAS client. Since 93 no specified instances of EAP key distribution to the NAS client 94 exist, the implicit assumption has to be that such mechanisms are 95 unimportant and will not be deployed as part of the AAA architecture. 96 That is, the lack of any defined EAP key distribution mechanism, and 97 the further lack of any work on such a mechanism, implies that the 98 AAA Working Group implicitly assumes it is only necessary to 99 distribute the key to the NAS. This de facto NASREQ key distribution 100 architecture is the object of our critique. 102 To effect key distribution, at some (unspecified) point in the 103 authentication process, the AAA server decides to distribute a key to 104 the NAS. This is accomplished by inserting a NAS-Session-Key AVP in 105 an Answer packet sent by the AAA server to the NAS. Each distributed 106 key is included in its own NAS-Session-Key AVP. 108 The NAS-Session-Key AVP has the following structure: 110 NAS-Session-Key ::= < AVP Header: 408 > 111 { NAS-Key-Direction } 112 { NAS-Key-Type } 113 { NAS-Key } 114 { NAS-Key-Data } 115 [ NAS-Key-Binding ] 116 [ NAS-Key-Lifetime ] 117 [ NAS-IV ] 119 Here 121 o NAS-Key-Direction tells whether the key is bi-directional, used 122 for upstream communication, or for downstream communication; 124 o NAS-Key-Type tells whether the key is a cipher key, an 125 integrity key, or some type of master key, used for further key 126 derivation; 128 o NAS-Key is never defined; 130 o NAS-Key-Data is the distributed key itself; 132 o NAS-Key-Binding indicates the cryptographic primitive to use 133 with the key, and it is optional; 135 o NAS-Key-Lifetime gives the number of seconds remaining before 136 the key expires, and it is optional; and 138 o NAS-IV may be used as an initialization vector, and it is 139 optional. 141 To protect the key distribution, [NASREQ] permits three different 142 mechanisms: 144 1. IPsec can be used to protect the entire Answer packet conveying 145 the NAS-Session-Key AVP. In this case, ESP would be used to 146 provide confidentiality, integrity, and data origin 147 authentication. 149 2. TLS can be used to protect the entire Answer packet, or TLS can 150 be used to protect a portion of the packet. 152 3. CMS can be used to envelope any included NAS-Session-Key AVPs. 154 [NASREQ] specifies no mandatory-to-implement protections for the key 155 distribution. 157 3. Analysis of NASREQ Key Distribution 159 This section argues there are five fundamental problems with the 160 model assumed by the NASREQ key distribution mechanism: 162 1. It is incompatible with static keys. 164 2. It has an inadequate, non-existent key naming scheme, which 165 opens the mechanism to numerous abuses. 167 3. It provides inadequate protection for distributed keys. 169 4. It introduces a novel key distribution architecture with poorly 170 understood security properties, while key distribution is an 171 area bedeviled by subtle bugs. 173 5. It is not feasible to design the key distribution exchange 174 between the AAA server and the NAS in isolation of any 175 associated handshaking between the NAS and the NAS client. 177 3.1. Architecture incompatible with static keys 179 In the de facto key distribution model described above, the key 180 distributed by the AAA server to the NAS must not ever be used again, 181 with either the same or with any other NAS. To permit the 182 distributed key to be reused with the same NAS, both the NAS and the 183 NAS client would have to maintain a record of the consumed sequence 184 spaces, nonce spaces, and replay windows used with the key, to 185 prevent inadvertent compromise on reuse, something that is not in 186 general feasible or desirable. To permit the key to be used by a 187 different NAS, a mechanism to prevent the original NAS from using the 188 key to masquerade as the NAS client would be needed. Some people may 189 argue that this latter problem is not a genuine concern because the 190 NAS is trusted. However, the consequences of NAS compromise must be 191 considered. The NAS is not immune from compromise; within the past 192 year alone, for example, the Code Red virus and SNMP buffer overrun 193 alert have applied to nearly every NAS, and almost all NASes required 194 patches as a consequence. Therefore, NASREQ key distribution cannot 195 be used with static keys; all distributed keys must be fresh, never- 196 used-before keys. 198 Another approach exists that can safely employ static keys. Under 199 this approach the static key remains a secret shared only between the 200 AAA server and the NAS client; it is never shared with the NAS. The 201 AAA server employs this static key to distribute a key to the NAS 202 client at the same time it distributes a key to the NAS. The cost of 203 this increased flexibility is that the AAA server generates a random 204 key and distributes it both to the NAS client and to the NAS, not 205 just the NAS, as in the present de facto architecture. 207 Proponents of the NASREQ approach might argue that the use of 208 protocols like TTLS or PEAP will alleviate this problem. They reason 209 that TTLS derives a fresh key at initial contact, and TLS-resume can 210 be used to derive another fresh key at the time of reattachment. 211 This is an attractive line of thinking, but suffers from two 212 problems. 214 The first problem is that organizations deploying TTLS or PEAP still 215 have to obtain an X.509 certificate for their AAA servers and deploy 216 a trust anchor that allows the X.509 certificate to be validated on 217 the NAS client. The trust anchor only contains public data, but 218 integrity must be maintained. If the trust anchor can be altered, 219 then the NAS clients cannot properly authenticate the AAA server, and 220 the NAS clients are subject to rogue NASes. This trust anchor 221 provisioning can be costly. It is probably an unacceptable cost for 222 many simple deployments, especially ad hoc wireless networks. 224 The second problem with this reasoning is that it leads to a more 225 complex exchange between the NAS client and the AAA server than is 226 actually necessary. An approach distributing the derived key only to 227 the NAS requires at least a three packet exchange between the NAS 228 client and the AAA server (EAP-TLS actually requires a four packet 229 exchange for TLS-resume) to generate a fresh key, while an approach 230 distributing a fresh randomly generated key to both the NAS and the 231 NAS client requires only a two packet exchange. This means that at 232 the time of a reattachment, when an existing key may be used, the de 233 facto architecture implementation is 50% more complex than necessary. 234 A 50% reduction in complexity is a giant win for security analysis, 235 and, when amortized over all reattachments, it provides a significant 236 performance enhancement for the case that is most time critical. 238 This is not to say that TTLS and PEAP do not provide any value. The 239 argument is rather they do not solve the problem being raised here. 241 Presumably, the NASREQ vision can be completed by enhancing EAP to 242 distribute an analog of the NAS-Session-Key AVP, delivering a session 243 key to the NAS client. Mandating this usage going forward would 244 improve flexibility by restoring the use of static keys, and would 245 simplify the overall system design. 247 3.2. Inadequate key naming 249 Since NASREQ did not tackle the fundamental issue of key freshness, 250 it also fails to address the issue of binding keys to particular 251 sessions between particular entity pairs. The protocol fails to 252 explicitly name the distributed keys. This is a much more serious 253 problem than the failure to work with static keys, because the 254 history of key distribution protocols shows that failing to properly 255 identify keys presents a major opportunity for compromise of the 256 distributed keys. It is a major vulnerability exploited to launch 257 attacks. 259 To prevent these kinds of weaknesses, it is necessary to specify both 260 the NAS client and the NAS identities in the key distribution, to 261 allow their peers to detect when either cheats or uses the key with 262 unintended parties. It is further necessary to explicitly bind the 263 key to a particular session between the NAS and the NAS client, to 264 detect key reuse problems. 266 The sort of key naming required represents an assertion by the AAA 267 server that the parties may not use the key with any other party, nor 268 with a different session. Thus, the only reasonable identification 269 has to include the AAA identities of the intended pair of peers and 270 some session identifier. This is not needless overhead. 272 The NAS-Session-Key AVP can be easily enhanced to provide this 273 additional information. 275 3.3. Inadequate protections for NAS-Session-Key AVPs 277 The NAS-Session-Key AVP does not require any explicit mandatory 278 protection. Instead, the NASREQ specification permits 279 implementations to rely upon TLS or IPsec to protect the AVP. The 280 problem with this approach is a practical implementation necessity: 281 AAA server implementations are typically software only, running under 282 general-purpose operating systems; many NAS devices are likewise 283 based on public domain UNIX implementation. In either environment it 284 is usually easy for an attacker to insert a Trojan horse that 285 intercepts the data stream between modules, e.g., between the TCP/IP 286 stack and the socket layer. Such a Trojan horse can read and replace 287 distributed keys if the cryptographic protections are applied by a 288 separate module. This defect in the design may be remedied by 289 mandating that the NAS-Session-Key AVP be CMS encapsulated and design 290 due diligence applied to keep the cryptographic operations from 291 crossing module boundaries. 293 The issue is deeper than just the layer at which the cryptographic 294 protections are applied. To minimize the immunity of a key 295 distribution protocol to attack, it is necessary to explicitly bind 296 together the information in a way that the recipient of the 297 distributed key can validate, and this binding typically crosses 298 message boundaries and often must even relate to messages from all 299 three parties in the protocol; section 3.5 below touches further on 300 this theme. These are application protocol issues, and it is simply 301 not reasonable to expect that bilateral mechanisms at other layers 302 can effectively solve these problems. [NASREQ] as it stands today 303 does not exhibit any evidence that this issue has even been 304 contemplated. For instance, the relationship between information in 305 AAA Request messages and Answer messages is never spelled out, being 306 left entirely as a method-specific detail. For some aspects of key 307 distribution to work properly, this relationship has to be defined. 308 Key distribution is not merely a data transport operation; it is also 309 a mechanism for building transitive trust; it is simply infeasible to 310 specify a secure key distribution without binding data across several 311 messages. 313 As an example of this complaint, even CMS wrapping the NAS-Session- 314 Key AVP does not explicitly protect the key distribution from replay. 315 Thus, although the NAS itself can assume a CMS-wrapped key is genuine 316 and issued from the AAA server, the NAS cannot determine that the AVP 317 it receives has not been issued already for some prior session. 318 Instead, the NAS must assume that the AAA server is playing by the 319 rules and issuing only fresh keys, and that there is no man-in-the- 320 middle replacing AVPs before or after they are unwrapped by a lower- 321 layer security mechanism. Many session establishment handshakes do 322 not define adequate key confirmation handshakes, so the NAS could end 323 up sending new data encrypted under already-used keys and IVs before 324 the problem can be detected, potentially compromising previously sent 325 data. What is needed to defeat this kind of attack is to require the 326 AAA server to incorporate a challenge from the NAS (and/or the NAS 327 client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a 328 timestamp into the AVP is another option, but maintaining 329 synchronized time in many of the environments served by an AAA server 330 introduces its own problems.) Relying on TLS or IPsec does not solve 331 the problem, because the replay protection afforded by such low-level 332 mechanisms is not adequately bound to the AVP to prevent a Trojan 333 horse from substituting an old AVP for the new one without detection. 335 While it was poorly implemented, the RADIUS authenticator played a 336 useful role. It allowed the NAS to detect replay. By removing the 337 authenticator when going forward to DIAMETER, AAA created a 338 structurally weaker protocol than RADIUS. This omission is an 339 opportunity, however, because it would be better to include an 340 authenticator field in the NAS-Session-Key AVP than as part of the 341 larger Answer packet, so it may be more tightly bound to the 342 distributed key. 344 Finally, the AVP wrapping algorithm is not specified with sufficient 345 granularity. Key distribution protocols make very specific 346 assumption about what is encrypted, what is authenticated but not 347 encrypted, and what must be sent without any protection. [NASREQ] 348 appears to apply the same protection to the entire AVP. This again 349 argues in favor of a mandatory application-specific security 350 protocol. 352 3.4. Novel solution to a problem bedeviled by subtle failures 354 The cryptographic community has not studied the de facto 355 architecture. Key distribution as defined in [NASREQ] is a three 356 party protocol, with the AAA server, the NAS, and the NAS client all 357 parties with an interest in the exchange. Cryptographers have 358 defined protocols that are known to protect the interests of all 359 three parties in such an exchange, but the NASREQ key distribution 360 does not resemble any of these well-studied protocols. This is 361 particularly troubling, because three-party key distribution of this 362 sort appears to be one of the hardest problems cryptographers have 363 attempted to address. Almost all of the initial proposals to this 364 problem have been flawed. There are examples where minor flaws have 365 remained undiscovered for 20 years after the protocol was published. 366 This repeated history of failure puts a premium on the most 367 conservative possible design, restricting it to well scrutinized 368 protocols. 370 It may be possible to address many of the problems discussed here 371 without adopting a classical, well-studied three-party protocol. It 372 may be, for instance, feasible to clean up the NASREQ architecture to 373 securely distribute keys in an environment where TTLS or PEAP is 374 mandated. However, many years of analysis and scrutiny may be 375 necessary to develop the confidence that this kind of approach is 376 secure from practical attack. It is safer to deploy a protocol known 377 to work correctly than to gamble that the novel design won't be 378 broken after the NASREQ application is widely deployed in the 379 Internet. 381 3.5. Key Distribution Protocols not Properly Bound 383 The IETF and the AAA WG have followed the time-honored custom of 384 decomposing problems into separate pieces. In the case of key 385 distribution, the decomposition is into the NASREQ/DIAMETER exchange 386 between the AAA server and the NAS on one hand, and the AAA server 387 and NAS client on the other, the latter being under the purview of 388 the EAP WG. Unfortunately, this decomposition is not correct. It is 389 incorrect because it is difficult to create separate key distribution 390 sub-protocols that, when reassembled into a single system, guarantee 391 the security needs of all three parties involved. A valid key 392 distribution protocol requires that the sub-protocols interact in 393 subtle and non-trivial ways and thus the key distribution 394 specification has to span the domains of at least two Working Groups. 396 As an example of this, [NASREQ] permits the distribution of several 397 keys for the same function, e.g., several Master session keys. On 398 the other hand, while allowing this flexibility, it provides no means 399 of indicating the sequence in which these keys are used, and when to 400 change from one key to another. The point is that, to be useful, the 401 usage of the distributed key must be synchronized on the NAS and the 402 NAS client, and the protocol does not provide the information 403 necessary for synchronization. 405 As a second example, in environments such as IEEE 802.11, an EAP- 406 Success message is inappropriate to signal the open link between the 407 NAS and the NAS client for general traffic. Rather, a key 408 confirmation handshake is required; it is inappropriate to open the 409 link to data traffic until the peer has signaled that its session 410 keys are in place. It is not feasible to design all the details of 411 the key confirmation handshake without also binding the handshake to 412 the details of the key distribution. The reason is that key 413 confirmation requires additional information to be exchanged that 414 would not be configured when there is no trusted third party. 416 An objection has been raised that an approach based on a classical 417 three-party protocol might be more complex than the present course of 418 the AAA Working Group. This objection is wrong on two accounts. 419 First, it is a necessary complexity, because composition of 420 separately designed protocols does not necessarily lead to a secure 421 overall protocol. Second, increasing the local complexity by binding 422 together protocols which are intrinsically linked reduces the 423 coupling of session key establishment from the remainder of the 424 system, and hence also reduces global complexity. 426 4. NASREQ Key Distribution Requirements 428 A key distribution protocol should provide a secure means for 429 affecting use of the session key. In addition to the requirements 430 already spelled out for NASREQ key distribution, the following 431 requirements are also needed for such a key distribution mechanism: 433 1. Must ensure the session key is fresh; 435 2. Must name the key; 437 3. Must bind the key to the intended session between the NAS and 438 NAS client; and 440 4. Must enforce protection of the session key. 442 4.1. Session key freshness 444 Key distribution mechanisms must ensure that the session key 445 distributed is statistically unique. That is, a session key must 446 never be used again in either subsequent sessions or reused with 447 another NAS. The protocol must allow both the NAS and the NAS client 448 some means of verifying the freshness of the key distribution. 450 4.2. Key naming 452 Each key must be properly identified to a given session corresponding 453 to a NAS and NAS client. The protocol and key naming scheme together 454 must allow the participants to detect the unauthorized use of a 455 distributed key. The protocol must allow each party to verify that 456 the session peer is the other intended recipient of the distributed 457 key. 459 4.3. Key binding 461 A key must be properly bound to a particular NAS and NAS client 462 session. The key binding is critical to allow both the NAS and NAS 463 client to properly synchronize to a session key. Since the key is 464 ultimately used to establish communications between the NAS and the 465 NAS client, the protocol must be explicit on when the distributed key 466 becomes active as well as allowing the NAS and NAS client to validate 467 and confirm receipt of the key. 469 4.4. Protection of the session key 471 The protocol must provide assurances to all three parties (the AAA 472 server, the NAS, and the NAS client) that no other parties have 473 access to the distributed session key, assuming none of the three 474 publishes it either intentionally or inadvertently. 476 5. Proposed NASREQ Key Distribution Architecture and Enhancements 478 < To be supplied by 3 May 2002 > 480 6. Security Considerations 482 This document concerns the security of [NASREQ]. The authors hope 483 that the analysis presented here will be embraced by the AAA Working 484 Group, resulting in a more secure protocol. 486 7. Acknowledgements 488 8. References 490 [PROB] Calhoun, P., Aboba, B., Guttman, E., Mitton, D., Nelson, 491 D., Schoenwaelder, J., Wolff, B., Zhang, X., "AAA Problem 492 Statements", work in progress, draft-ietf-aaa-issues-05.txt, 493 January 2002. 495 [TRANS] Aboba, B., Wood, J., "Authentication, Authorization, and 496 Accounting (AAA) Transport Profile", work in progress, 497 draft-ietf-aaa-transport-05.txt, November 2001. 499 [DIAM] Calhoun, P., Akhtar, H., Arkko, J., Guttman, E., Rubens, 500 A., Zorn, G., "Diameter Base Protocol", work in progress, draft-ietf-aaa-diameter-08.txt, November 2001 502 [NASREQ] Calhoun, P., Bulley, W., Rubens, A.C., Haag, J., Zorn., G. 503 "Diameter NASREQ Application", work in progress, 504 draft-ietf-aaa-diameter-nasreq-08.txt, November 2001. 506 [CMS] Calhoun, P., Farrell, S., Bulley, W., "The Diameter CMS 507 Security Application", work in progress, 508 draft-ietf-aaa-diameter-cms-03.txt, November 2001. 510 [TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 511 Authentication Protocol", work in progress, 512 draft-ietf-pppext-eap-ttls-01.txt, February 2002 514 [PEAP] Anderson, H., Josefsson, S., Zorn, G., Simon, D., Palekar, 515 A., "Protected EAP Protocol (PEAP)", work in progress, 516 draft-josefsson-pppext-eap-tls-eap-02.txt, February 2002 518 9. Author Addresses 520 Jesse Walker 521 Intel Corporation 522 2111 N.E. 25th Avenue 523 Hillsboro, OR 97214 524 USA 525 jesse.walker@intel.com 527 Russell Housley 528 RSA Laboratories 529 918 Spring Knoll Drive 530 Herndon, VA 20170 531 USA 532 rhousley@rsasecurity.com 534 Nancy Cam-Winget 535 Mountain View, CA 94040 536 USA 537 nance@winget.net 539 10. Full Copyright Statement 541 Copyright (C) The Internet Society (2002). All Rights Reserved. 543 This document and translations of it may be copied and furnished to 544 others, and derivative works that comment on or otherwise explain it 545 or assist in its implementation may be prepared, copied, published 546 and distributed, in whole or in part, without restriction of any 547 kind, provided that the above copyright notice and this paragraph 548 are included on all such copies and derivative works. In addition, 549 the ASN.1 modules presented in Appendices A and B may be used in 550 whole or in part without inclusion of the copyright notice. 551 However, this document itself may not be modified in any way, such 552 as by removing the copyright notice or references to the Internet 553 Society or other Internet organizations, except as needed for the 554 purpose of developing Internet standards in which case the 556 procedures for copyrights defined in the Internet Standards process 557 shall be followed, or as required to translate it into languages 558 other than English. 560 The limited permissions granted above are perpetual and will not be 561 revoked by the Internet Society or its successors or assigns. This 562 document and the information contained herein is provided on an "AS 563 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 564 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 565 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 566 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 567 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.