idnits 2.17.00 (12 Aug 2021) /tmp/idnits62065/draft-aboba-pppext-eapgss-12.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 741 has weird spacing: '...fy that the c...' == Line 742 has weird spacing: '... by the peer....' == Line 850 has weird spacing: '...tor) is obtai...' == Line 970 has weird spacing: '...he peer has a...' == Line 1086 has weird spacing: '...between the...' == (3 more instances...) == 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.) -- The document date (6 April 2002) is 7343 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1511 -- Looks like a reference, but probably isn't: '2' on line 1515 -- Looks like a reference, but probably isn't: '3' on line 1521 == Missing Reference: 'KERBLIM' is mentioned on line 881, but not defined == Missing Reference: 'RFC 2284' is mentioned on line 1108, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Missing Reference: 'RFC 1964' is mentioned on line 1134, but not defined -- Looks like a reference, but probably isn't: '4' on line 1526 -- Looks like a reference, but probably isn't: '5' on line 1449 -- Looks like a reference, but probably isn't: '6' on line 1537 == Unused Reference: 'KERB' is defined on line 1176, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 1203, but no explicit reference was found in the text == Unused Reference: 'RFC2867' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 1222, but no explicit reference was found in the text == Unused Reference: 'DESFIPS' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'IEEE80211i' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'AESProp' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'AESFIPS' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: 'BLOCK' is defined on line 1285, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) == Outdated reference: A later version (-09) exists of draft-ietf-cat-iakerb-08 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 Summary: 10 errors (**), 0 flaws (~~), 27 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Experimental Microsoft 5 6 6 April 2002 8 EAP GSS Authentication Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 The Extensible Authentication Protocol (EAP) provides a standard 38 mechanism for support of multiple authentication methods, including 39 public key, smart cards, One Time Passwords, and others. 41 This document describes the EAP GSS protocol, which enables the use of 42 GSS-API mechanisms within EAP. As a result, any GSS-API mechanism 43 providing initial authentication can be used with EAP GSS. 45 Table of Contents 47 1. Introduction .......................................... 3 48 1.1 Requirements language ........................... 3 49 1.2 Terminology ..................................... 3 50 2. Protocol overview ...................... .............. 4 51 2.1 EAP server as GSS-API initiator ................. 4 52 2.2 Peer as GSS-API initiator ....................... 6 53 3. Detailed description of EAP GSS protocol .............. 9 54 3.1 EAP GSS packet format ........................... 9 55 3.2 EAP GSS Request packet .......................... 10 56 3.3 EAP GSS Response packet ......................... 12 57 3.4 Options ......................................... 13 58 3.5 Fragmentation ....... ........................... 15 59 3.6 Retry behavior .................................. 18 60 3.7 Identity verification ........................... 18 61 3.8 Use of addresses ................................ 19 62 4. Key management ........................................ 19 63 4.1 Key derivation algorithm ........................ 19 64 5. Security considerations ............................... 21 65 5.1 Dictionary attacks .............................. 21 66 5.2 Certificate revocation ......................... 23 67 5.3 Mutual authentication ........................... 23 68 5.4 Credential reuse ................................ 23 69 5.5 Key transmission issues ......................... 25 70 5.6 Protected negotiation ........................... 26 71 6. Normative References .................................. 27 72 7. Informative References ................................ 28 73 IANA Considerations .......................................... 30 74 Acknowledgments .............................................. 30 75 Author's Addresses ........................................... 30 76 Appendix A - Example IAKERB topologies ....................... 31 77 A.1 RADIUS+KDC backend .............................. 31 78 A.2 Kerberos KDC backend ............................ 34 79 Appendix B - The Pseudorandom Function ....................... 36 80 Intellectual Property Statement .............................. 38 81 Full Copyright Statement ..................................... 38 82 1. Introduction 84 The Extensible Authentication Protocol (EAP) [RFC2284] provides a 85 standard mechanism for support of multiple authentication methods, 86 including public key [RFC2716], smart cards, One Time Passwords 87 [RFC2284], and others. EAP may run directly over the link layer without 88 requiring IP and therefore includes its own support for in-order 89 delivery and re-transmission, but not fragmentation and reassembly, 90 which is the responsibility of individual EAP methods. While EAP was 91 originally developed for use with PPP [RFC1661], it is also now in use 92 with IEEE 802 [IEEE802]. The encapsulation of EAP on IEEE 802 links is 93 described in [IEEE8021X]. 95 The Generic Security Service API (GSS-API), is described in [RFC2743]. 96 This document describes the EAP GSS protocol, which supports 97 fragmentation and reassembly and enables the use of GSS-API mechanisms 98 within EAP. As a result, any GSS-API mechanism providing initial 99 authentication can be used with EAP GSS. 101 Supporting GSS-API authentication methods within EAP is desirable 102 because this enables developers creating GSS-API authentication methods 103 to leverage their development efforts. Since the EAP Type field is a 104 finite (one octet) resource, EAP GSS allows GSS-API methods to 105 automatically be supported within EAP without having to consume an EAP 106 Type for each GSS-API method. 108 1.1. Requirements language 110 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 111 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 112 described in [RFC2119]. 114 1.2. Terminology 116 This document frequently uses the following terms: 118 Authentication Server 119 An Authentication Server is an entity that provides an 120 Authentication Service to an NAS. This service verifies from 121 the credentials provided by the peer, the claim of identity 122 made by the peer. 124 Master key 125 The key derived between the EAP client and EAP server during 126 the EAP authentication process. 128 Master session key 129 The keys derived from the master key that are subsequently 130 used in generation of the transient session keys for 131 authentication, encryption, and IV-generation. So that the 132 master session keys are usable with any ciphersuite, they are 133 longer than is necessary, and are truncated to fit. 135 NAS The end of the link requiring the authentication. In IEEE 136 802.1X, this end is known as the Authenticator. 138 Peer The other end of the point-to-point link (PPP), point-to-point 139 LAN segment (IEEE 802.1X) or 802.11 wireless link, which being 140 authenticated by the NAS. In IEEE 802.1X, this end is known as 141 the Supplicant. 143 Transient session keys 144 The chosen ciphersuites uses transient session keys for 145 authentication and encryption as well as IVs (if required). 146 The transient session keys are derived from the master session 147 keys, and are of the appropriate size and type for use with 148 the chosen ciphersuite. 150 2. Protocol overview 152 As described in [RFC2284], EAP conversations will typically begin with 153 the NAS and the peer negotiating EAP. The NAS will then typically send 154 an EAP-Request/Identity packet to the peer, and the peer will respond 155 with an EAP-Response/Identity packet to the NAS, containing the peer's 156 UserId. Once having received the peer's Identity, the EAP server 157 responds with an EAP-Request packet of EAP-Type=EAP GSS. From this 158 point forward, the EAP GSS conversation may proceed in one of two ways: 160 [1] EAP server as GSS-API iniator. Here the EAP server acts as the GSS- 161 API initiator, and the peer acts as the GSS-API target. 163 [2] EAP client as GSS-API initiator. Here the peer acts as the GSS-API 164 initiator, and the EAP server acts as the GSS-API target. This mode 165 adds an extra round-trip. 167 2.1. EAP server as GSS-API initiator 169 As described in [RFC2284], the EAP server typically authenticates the 170 peer using a prearranged method or set of methods. As a result, the EAP 171 server may have predetermined the use of EAP GSS as well as the GSS-API 172 method to be used. If that GSS-API method can be initiated by the EAP 173 Server, then the EAP server MAY act as a GSS-API initiator with the peer 174 acting as a GSS-API target. In this case, the EAP Server will indicate 175 the pre-determined GSS-API method, possibly via SPNEGO, but SHOULD NOT 176 allow negotiation of a substitute GSS-API method. 178 To initiate the conversation, the EAP-Server sends an EAP-Request packet 179 with EAP-Type=EAP GSS. This initial packet MUST have the O (Options) bit 180 set, and MUST include a Nonce Payload option. The data field of the 181 packet will encapsulate a GSS-API token, created as a result of a call 182 to GSS_Init_sec_context (). In this case mutual authentication MUST be 183 requested (otherwise the peer would not be authenticated to the NAS!) so 184 that the the mutual_req_flag is set and the call to GSS_Init_sec- 185 context() returns GSS_S_CONTINUE_NEEDED status. 187 When it receives the EAP-Request, the peer will de-capsulate the 188 received GSS-API token within the EAP GSS frame, and will pass it as the 189 input_token parameter to GSS_Accept_sec_context(). If 190 GSS_Accept_sec_context indicates GSS_S_COMPLETE status, then the NAS has 191 been authenticated by the peer, and the NAS's indicated identity is 192 provided in the src_name result. The peer then responds with an EAP- 193 Response packet with EAP-Type= EAP GSS, MUST have the O bit (Options) 194 set, and contains a Nonce Payload option. The data field of the packet 195 contains the returned output_token. 197 The EAP server will then de-capsulate the GSS-API token within the EAP- 198 Response message and pass it as the input_token parameter to 199 GSS_Init_sec_context(). If the call returns GSS_S_COMPLETE status, then 200 the peer has been authenticated to the EAP-Server, then the EAP-Server 201 responds with an EAP-Success message. If GSS_S_CONTINUE_NEEDED status 202 is returned, then the EAP Server encapsulates the returned output_token 203 with an EAP-Request packet of EAP-Type=EAP GSS, and pass this back to 204 the peer. 206 The conversation (which can be completed in a minimum of 2.5 round 207 trips), appears as follows: 209 Peer NAS 210 ------ ------------- 211 EAP/Identity 212 <-------Request 214 EAP/Identity 215 Response --------> 217 GSS_Init_sec_context(mutual_req_flag) 218 returns GSS_S_CONTINUE_NEEDED, 219 output_token 221 <--------EAP Request 222 EAP Type=EAP GSS 223 O bit, Nonce Payload, 224 output_token 226 GSS_Accept_sec_context(input_token) 227 returns GSS_S_COMPLETE, 228 output_token 230 EAP Response --------> 231 EAP Type=EAP GSS 232 O bit, Nonce Payload, 233 output_token 235 GSS_Init_sec_context(input_token) 236 returns GSS_S_COMPLETE 238 <--------EAP Success 240 2.2. Peer as GSS-API initiator 242 If the EAP server is prepared to allow negotiation of the GSS-API method 243 via SPNEGO [RFC2478], or if the EAP server knows the GSS-API method to 244 be used, but cannot initiate it (e.g. IAKERB, or Kerberos V), then the 245 peer MUST act as a GSS-API initiator, with the EAP server acting as the 246 GSS-API target. 248 In this case, the EAP server MUST respond with an EAP GSS/Start packet, 249 which is an EAP-Request packet with EAP-Type=EAP GSS, the Start (S) and 250 Options (O) bits set, a Nonce Payload option, and no data. 252 The peer then calls GSS_Init_sec_context(), typically with mutual 253 authentication requested so that the mutual_req_flag is set and the call 254 returns GSS_S_CONTINUE_NEEDED status. The peer then MUST respond with an 255 EAP-Response packet with EAP-Type=EAP GSS, the O bit set, the Nonce 256 Payload option present, and the data field set to the output_token. 258 If method negotiation is to be used, then an initial negotiation token 259 for the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) 260 [RFC2478] is transferred. This contains an ordered list of mechanisms, a 261 set of options that should be supported by the selected mechanism and 262 the initial security token for the mechanism preferred by the peer. The 263 inclusion of the initial security token for the preferred method saves a 264 round-trip, assuming that the NAS agrees to the preferred mechanism. 266 The EAP server then de-capsulates the GSS-API token contained within the 267 EAP-Response of EAP-Type=EAP GSS and uses this as the input_token 268 parameter to a call to GSS_Accept_sec_context(). The output_token 269 parameter will then contain a token, containing the result of the 270 negotiation and in the case of accept, the agreed security mechanism and 271 the response to the initial security token as described in [RFC2478]. 272 This token is then encapsulated within an EAP-Request packet of EAP- 273 Type=GSS-API, which is sent to the peer. This occurs whether the call 274 completed with GSS_S_CONTINUE_NEEDED status or GSS_S_COMPLETE status. 276 The peer then de-capsulates the GSS-API token contained within the EAP- 277 Request packet with EAP-Type=EAP GSS, and passes the input_token 278 parameter to GSS_Init_sec_context(). The output_token is encapsulated 279 within an EAP-Response packet with EAP-Type=EAP GSS and sent to the EAP 280 server. This occurs whether the call completed with 281 GSS_S_CONTINUE_NEEDED status or GSS_S_COMPLETE status. 283 If the previous call to GSS_Accept_sec_context() returned GSS_S_COMPLETE 284 status, then the EAP-Server returns an EAP-Success message to the 285 client. Otherwise, it de-capsulates the GSS-API token contained within 286 the EAP-Request packet, and the conversation continues. 288 The conversation (which can be completed in a minimum of 3.5 round 289 trips), appears as follows: 291 Authenticating Peer NAS 292 ------------------- ------------- 293 EAP-Request/ 294 <- Identity 295 EAP-Response/ 296 Identity (MyID) -> 297 EAP-Request/ 298 EAP-Type=EAP GSS 299 (GSS Start, 300 S and O bits set), 301 <- Nonce Payload 303 GSS_Init_sec_context(mutual_req_flag) 304 returns GSS_S_CONTINUE_NEEDED, 305 output_token (SPNEGO) 307 EAP-Response/ 308 EAP-Type=EAP GSS 309 O bit, Nonce Payload, 310 output_token -> 311 GSS_Accept_sec_context(input_token) 312 returns GSS_S_COMPLETE, 313 output_token (SPNEGO) 315 EAP-Request/ 316 EAP-Type=EAP GSS 317 <- output_token 319 GSS_Init_sec_context(input_token) 320 returns GSS_S_COMPLETE, 321 output_token 323 EAP-Response/ 324 EAP-Type=EAP GSS 325 output_token -> 326 <- EAP-Success 328 3. Detailed description of the EAP GSS protocol 330 3.1. EAP GSS Packet Format 332 A summary of the EAP GSS Request/Response packet format is shown below. 333 The fields are transmitted from left to right. 335 0 1 2 3 336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Code | Identifier | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Data... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Code 345 1 - Request 346 2 - Response 348 Identifier 350 The identifier field is one octet and aids in matching responses with 351 requests. 353 Length 355 The Length field is two octets and indicates the length of the EAP 356 packet including the Code, Identifier, Length, Type, and Data fields. 357 Octets outside the range of the Length field should be treated as 358 Data Link Layer padding and should be ignored on reception. 360 Type 362 TBD - EAP GSS 364 Data 366 The format of the Data field is determined by the Code field. 368 3.2. EAP GSS Request Packet 370 A summary of the EAP GSS Request packet format is shown below. The 371 fields are transmitted from left to right. 373 0 1 2 3 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Code | Identifier | Length | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Version | Flags | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Options... 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | GSS Data... 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Code 387 1 389 Identifier 391 The Identifier field is one octet and aids in matching responses with 392 requests. The Identifier field MUST be changed on each Request 393 packet. 395 Length 397 The Length field is two octets and indicates the length of the entire 398 EAP packet. 400 Type 402 TBD - EAP GSS 404 Version 406 1 408 Flags 410 0 1 2 3 4 5 6 7 8 411 +-+-+-+-+-+-+-+-+ 412 |L M S O R R R R| 413 +-+-+-+-+-+-+-+-+ 415 L = Length included 416 M = More fragments 417 S = EAP GSS start 418 O = Options present 419 R = Reserved 421 The L bit (length included) MUST be set for the first fragment of a 422 fragmented GSS message or set of messages. If set, the GSS Message 423 Length option MUST be included. The M bit (more fragments) is set on 424 all but the last fragment. The S bit (EAP GSS start) is set in an EAP 425 GSS Start message. This differentiates the EAP GSS Start message 426 from a fragment acknowledgment. The O bit (Options present) is set 427 to indicate the presence of options, including the GSS Message Length 428 option. As a result, the O bit MUST be set whenever the L bit is set; 429 however, it also may be set when the L bit is not set. 431 Options 433 The Options field is of variable length, and contains type-length- 434 value tuples (TLVs). Options are present only if the O bit is set. 436 GSS data 438 The GSS data consists of the encapsulated GSS token. 440 3.3. EAP GSS Response Packet 442 A summary of the EAP GSS Response packet format is shown below. The 443 fields are transmitted from left to right. 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Code | Identifier | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Version | Flags | Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Options... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | GSS Data... 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Code 459 2 461 Identifier 463 The Identifier field is one octet and MUST match the Identifier field 464 from the corresponding request. 466 Length 468 The Length field is two octets and indicates the length of the entire 469 EAP packet. 471 Type 473 TBD - EAP GSS 475 Version 477 1 479 Flags 481 0 1 2 3 4 5 6 7 8 482 +-+-+-+-+-+-+-+-+ 483 |L M S O R R R R| 484 +-+-+-+-+-+-+-+-+ 486 L = Length included 487 M = More fragments 488 S = EAP GSS start 489 O = Options present 490 R = Reserved 492 The L bit (length included) MUST be set for the first fragment of a 493 fragmented GSS message or set of messages. If set, the GSS Message 494 Length option MUST be included. The M bit (more fragments) is set on 495 all but the last fragment. The S bit (EAP GSS start) is set in an EAP 496 GSS Start message. This differentiates the EAP GSS Start message 497 from a fragment acknowledgment. The O bit (Options present) is set 498 to indicate the presence of options, including the GSS Message Length 499 option. As a result, the O bit MUST be set whenever the L bit is set; 500 however, it also may be set when the L bit is not set. 502 Options 504 The Options field is of variable length, and contains type-length- 505 value tuples (TLVs). Options are present only if the O bit is set. 507 GSS data 509 The GSS data consists of the encapsulated GSS token. 511 3.4. Options 513 To date, the only options that are defined are the GSS Message Length 514 option (option 1) and the Nonce Payload option (option 2). The format 515 of options are as follows: 517 0 1 2 3 518 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Value... 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Type 526 A two octet field, denoting the option. Values include: 528 1 - GSS Message Length 529 2 - Nonce Payload 531 Length 533 The length of the option, including the type, length and value 534 fields. 536 Value 538 The value of the option. 540 3.4.1. GSS Message Length option 542 The GSS Message Length option is present only if the L and O bits are 543 set. It is defined as follows: 545 0 1 2 3 546 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Value | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type 555 1 557 Length 559 8 561 Value 563 The value field of the GSS Message Length options is four octets in length. 564 This field provides the total length of the GSS message or set of messages 565 that is being fragmented. 567 3.4.2. Nonce Payload option 569 The Nonce Payload option is defined as follows: 571 0 1 2 3 572 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type | Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Value | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Type 581 2 583 Length 585 36 587 Value 589 The value field of the Nonce Payload option is 32 octets in length. 590 As in [RFC2246] the first 4 octets of this field are the time of 591 day when the message was generated (in seconds since the Unix epoch, 592 12:00 midnight, January 1, 1970 GMT) and the other 28 octets are randomly 593 generated. 595 3.5. Fragmentation 597 It is possible that EAP GSS messages may exceed the link MTU size, the 598 maximum RADIUS packet size of 4096 octets, or even the PPP Multilink 599 Maximum Received Reconstructed Unit (MRRU). As described in [RFC1990], 600 within PPP the multi-link MRRU is negotiated via the Multilink MRRU LCP 601 option, which includes an MRRU length field of two octets, and thus can 602 support MRRUs as large as 64 KB. 604 In order to protect against reassembly lockup and denial of service 605 attacks, it may be desirable for an implementation to set a maximum size 606 for a GSS-API token. Since a typical certificate chain is rarely longer 607 than a few thousand octets, and no other field is likely to be anywhere 608 near as long, a reasonable choice of maximum acceptable message length 609 might be 64 KB. 611 If this value is chosen, then for PPP links, fragmentation can be 612 handled via the multi-link PPP fragmentation mechanisms described in 613 [RFC1990]. While this is desirable, there may be cases in which multi- 614 link or the MRRU LCP option cannot be negotiated. Also, since EAP 615 methods must also be usable within IEEE 802.1X [IEEE8021X], an EAP GSS 616 implementation MUST provide its own support for fragmentation and 617 reassembly. 619 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 620 added in a simple manner. In EAP, fragments that are lost or damaged in 621 transit will be retransmitted, and since sequencing information is 622 provided by the Identifier field in EAP, there is no need for a fragment 623 offset field as is provided in IP. 625 EAP GSS fragmentation support is provided through addition of a flags 626 octet within the EAP-Response and EAP-Request packets, as well as a GSS 627 Message Length field of four octets. Flags include the Length included 628 (L), More fragments (M), Options (O) and EAP GSS Start (S) bits. The L 629 is set to indicate the presence of the GSS Message Length option, and 630 MUST be set for the first fragment of a fragmented GSS message or set of 631 messages. The M flag is set on all but the last fragment. The S flag is 632 set only within the EAP GSS start message sent from the EAP server to 633 the peer. The GSS Message Length option provides the total length of the 634 GSS-API token or set of messages that is being fragmented; this 635 simplifies buffer allocation. 637 When an EAP GSS peer receives an EAP-Request packet with the M bit set, 638 it MUST respond with an EAP-Response with EAP-Type=EAP GSS and no data. 639 This serves as a fragment ACK. The EAP server MUST wait until it 640 receives the EAP-Response before sending another fragment. In order to 641 prevent errors in processing of fragments, the EAP server MUST increment 642 the Identifier field for each fragment contained within an EAP-Request, 643 and the peer MUST include this Identifier value in the fragment ACK 644 contained within the EAP-Response. Retransmitted fragments will contain 645 the same Identifier value. 647 Similarly, when the EAP server receives an EAP-Response with the M bit 648 set, it MUST respond with an EAP-Request with EAP-Type=EAP GSS and no 649 data. This serves as a fragment ACK. The EAP peer MUST wait until it 650 receives the EAP-Request before sending another fragment. In order to 651 prevent errors in the processing of fragments, the EAP server MUST use 652 increment the Identifier value for each fragment ACK contained within an 653 EAP-Request, and the peer MUST include this Identifier value in the 654 subsequent fragment contained within an EAP-Response. 656 In the case where the EAP GSS authentication is successful, and 657 fragmentation is required, the conversation will appear as follows: 659 Authenticating Peer NAS 660 ------------------- ------------- 661 EAP-Request/ 662 <- Identity 663 EAP-Response/ 664 Identity (MyID) -> 665 EAP-Request/ 666 EAP-Type=EAP GSS 667 <- GSS Start, 668 O and S bit set, 669 Nonce Payload 671 GSS_Init_sec_context(mutual_req_flag) 672 returns GSS_S_CONTINUE_NEEDED, 673 output_token (SPNEGO) 675 EAP-Response/ 676 EAP-Type=EAP GSS 677 O bit set, Nonce Payload, 678 output_token -> 680 GSS_Accept_sec_context(input_token) 681 returns GSS_S_COMPLETE, 682 output_token (SPNEGO) 684 EAP-Request/ 685 EAP-Type=EAP GSS 686 output_token 687 <- (Fragment 1: L, O, M bits set) 688 EAP-Response/ 689 EAP-Type=EAP GSS -> 690 EAP-Request/ 691 EAP-Type=EAP GSS 692 <- (Fragment 2: M bit set) 693 EAP-Response/ 694 EAP-Type=EAP GSS -> 695 EAP-Request/ 696 EAP-Type=EAP GSS 697 <- (Fragment 3) 699 GSS_Init_sec_context(input_token) 700 returns GSS_S_COMPLETE, 701 output_token 703 EAP-Response/ 704 EAP-Type=EAP GSS 705 output_token 706 (Fragment 1: 707 L, O, M bits set)-> 708 EAP-Request/ 709 <- EAP-Type=EAP GSS 710 EAP-Response/ 711 EAP-Type=EAP GSS 712 (Fragment 2)-> 713 <- EAP-Success 715 3.6. Retry behavior 717 As with other EAP protocols, the EAP server is responsible for retry 718 behavior. This means that if the EAP server does not receive a reply 719 from the peer, it MUST resend the EAP-Request for which it has not yet 720 received an EAP-Response. However, the peer MUST NOT resend EAP-Response 721 packets without first being prompted by the EAP server. 723 For example, if the initial EAP GSS start packet sent by the EAP server 724 were to be lost, then the peer would not receive this packet, and would 725 not respond to it. As a result, the EAP GSS start packet would be resent 726 by the EAP server. Once the peer received the EAP GSS start packet, it 727 would send an EAP-Response encapsulating the client_hello message. If 728 the EAP-Response were to be lost, then the EAP server would resend the 729 initial EAP GSS start, and the peer would resend the EAP-Response. 731 As a result, it is possible that a peer will receive duplicate EAP- 732 Request messages, and may send duplicate EAP-Responses. Both the peer 733 and the EAP-Server should be engineered to handle this possibility. 735 3.7. Identity verification 737 As part of the GSS-API conversation, it is possible that the server may 738 present a certificate to the peer, or that the peer may present a 739 certificate to the EAP server. If the peer has made a claim of identity 740 in the EAP-Response/Identity (MyID) packet, the EAP server SHOULD 741 verify that the claimed identity corresponds to the certificate 742 presented by the peer. Typically this will be accomplished either by 743 placing the userId within the peer certificate, or by providing a 744 mapping between the peer certificate and the userId using a directory 745 service. 747 Similarly, the peer MUST verify the validity of the EAP server 748 certificate, and SHOULD also examine the EAP server name presented in 749 the certificate, in order to determine whether the EAP server can be 750 trusted. Please note that in the case where the EAP authentication is 751 remoted that the EAP server will not reside on the same machine as the 752 NAS, and therefore the name in the EAP server's certificate cannot be 753 expected to match that of the intended destination. In this case, a more 754 appropriate test might be whether the EAP server's certificate is signed 755 by a CA controlling the intended destination and whether the EAP server 756 exists within a target sub-domain. 758 3.8. Use of addresses 760 When using EAP GSS, the EAP client may not be able to include an address 761 in an EAP-Response message, since prior to obtaining access the EAP 762 client may not have an IP address. This limits effective use of EAP GSS 763 to GSS-API methods that do not require the peer to have an IP address 764 prior to authentication. 766 The IAKERB GSS-API method can explicitly handle this situation, as 767 described in [IAKERB]. However, where the Kerberos V protocol, described 768 in [RFC1510], is negotiated as a GSS-API method as described in 769 [RFC1964], the addresses field of the AS_REQ and TGS_REQ SHOULD be blank 770 and the caddr field of the ticket SHOULD also be left blank. 772 4. Key management 774 As a result of the EAP GSS conversation, the EAP endpoints will mutually 775 authenticate and derive a master key. The master key is then used to 776 derive master session keys for authentication and encryption as well as 777 initialization vectors in each direction. It is the master session keys 778 that are provided by the EAP method hosted on the client and AAA server, 779 and communicated by the AAA server to the NAS. 781 The master session keys are then used by the client and NAS in order to 782 derive ciphersuite-specific keys, once the negotiated ciphersuite is 783 known. Depending on the negotiated ciphersuite, not all of the master 784 session keys will be used in this process. 786 By requiring master session keys (but not ciphersuite-specific keys) to 787 be derived by the EAP method, it is possible for EAP methods to derive 788 keying material that can be used by any ciphersuite. This is desirable, 789 since it avoids having to revise EAP methods each time a new ciphersuite 790 is deployed for any of the applications using EAP. 792 4.1. Key derivation algorithm 794 EAP TLS, described in [RFC2716], provides a mechanism for deriving 795 authentication and encryption keys as well as IVs in both directions 796 from the TLS master key. The key hierarcy of EAP GSS is similar to that 797 of EAP TLS, with the following differences: 799 [1] Pseudo-master key derivation. TLS APIs typically do not enable 800 direct access to the master key, for security reasons. As a result, 801 EAP TLS utilizes the TLS PRF in the master session key derivation, 802 rather than acting on the master key itself. 804 For similar reasons, EAP GSS implementations will typically not be 805 able to obtain access to the master key via GSS-API. However, GSS- 806 API methods can call GSS_Wrap() to encrypt and GSS_GetMIC() to 807 generate authentication tokens based on the master key. Since EAP 808 GSS cannot assume direct access to the master key, it is not 809 possible to utilize the master key directly in the derivation of 810 the master session keys. 812 Instead, an intermediate step is required, where a "Pseudo-Master 813 Key" K' is derived from the master key, and used in the derivation 814 of the master session keys. Note that since the randomness of the 815 GSS-API MIC cannot be guaranteed, it is preferrable to use 816 GSS_Wrap() to generate the K', and additional randomness needs to 817 be introduced into the derivation to ensure sufficient entropy. 819 [2] Nonce generation. TLS includes an exchange of nonces, and the 820 exchanged nonces are used within the keying hierarchy in order to 821 ensure liveness in the derived master session keys. GSS-API methods 822 such as Kerberos do not include such a nonce exchange, although 823 typically some other source of "liveness" is provided, such as a 824 counter or a time value. The variation in GSS-API methods makes it 825 difficult to come up with a key hierarchy that can be used with any 826 GSS-API method, if only GSS-API calls are available. To circumvent 827 this limitation, EAP GSS adds a nonce exchange patterned after 828 [RFC2246]. 830 In the techniques described here, master session keys are derived from 831 the master key derived by the GSS-API method, but are never used to 832 encrypt or decrypt data; they are only used in the derivation of 833 transient session keys. 835 The derivation proceeds as follows: 837 [1] The "Pseudo-Master Key" K' is derived from the raw master key using 838 the formula: K' = HMAC-SHA1("", GSS_Wrap("EAP GSS pseudo master 839 key") | random). Here random is defined as the concatenation of the 840 message fields client_nonce and server_nonce (in that order). 842 [2] Given the K' value and the pseudorandom function (PRF) defined in 843 Appendix B, the value PRF1 = PRF(K', "client EAP encryption", 844 random) is computed up to 128 bytes, and the PRF2 = PRF("","client 845 EAP encryption", random) is computed up to 64 bytes (where "" is an 846 empty string). Here random is defined as the concatenation of the 847 message fields client_nonce and server_nonce (in that order). 849 [3] The peer encryption key (the one used for encrypting data from peer 850 to authenticator) is obtained by truncating to the correct length 851 the first 32 bytes of PRF1. The authenticator encryption key (the 852 one used for encrypting data from authenticator to peer), if 853 different from the client encryption key, is obtained by truncating 854 to the correct length the second 32 bytes of PRF1. The peer 855 authentication key (the one used for computing MICs for messages 856 from peer to authenticator), if used, is obtained by truncating to 857 the correct length the third 32 bytes of PRF1. The authenticator 858 authentication key (the one used for computing MICs for messages 859 from authenticator to peer), if used, and if different from the 860 peer authentication key, is obtained by truncating to the correct 861 length the fourth 32 bytes of PRF1. The peer initialization vector 862 (IV), used for messages from peer to authenticator if a block 863 cipher has been specified, is obtained by truncating to the 864 cipher's block size the first 32 bytes of PRF2. Finally, the 865 authenticator initialization vector (IV), used for messages from 866 peer to authenticator if a block cipher has been specified, is 867 obtained by truncating to the cipher's block size the second 32 868 bytes of PRF2. 870 The use of these encryption, authentication keys and IVs is specific to 871 the ciphersuite used. Additional keys or other non-secret values (such 872 as IVs) can be obtained as needed for future ciphersuites by extending 873 the outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 875 A description of the key hierarchy is provided on the next page. 877 5. Security Considerations 879 5.1. Dictionary attacks 881 As noted in [KRBATTACK],[KERBLIM],[KERB4WEAK], both Kerberos IV and V 882 are vulnerable to dictionary attack. These attacks are particularly 883 potent when carried out in a location where a large number of 884 authentication exchanges can be collected within a short period of time, 885 such as with wireless LANs deployed in "hot spots". 887 As noted in [KRBATTACK], offline dictionary attacks are easily carried 888 out against the AS_REP, since the key encrypting the enclosed Kerberos 889 ticket is a function of the password. Such attacks are amenable to 890 parallelization, and it is therefore possible to crack a large number of 891 passwords in short time with only modest resources. The imposition of a 892 password policy is likely only to decrease the yield, but given access 893 to sufficient exchanges, large scale password compromise remains 894 possible. 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 | Derivation of the pseudo | 899 | master key from the | 900 | raw master key | 901 | | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | 904 | K' 905 | 906 V 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | | 909 | Master Session Key | 910 | Derivation | 911 | | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | | 914 | PRF1 | PRF2 915 | 128B | 64B 916 V V 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | | | 919 | Key | | IV | 920 | Derivation | | Derivation | 921 | | | | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | P->A | A->P | P->A | A->P | P->A | A->P 924 | Enc. | Enc. | Auth. | Auth. | IV | IV 925 | Key | Key | Key | Key | 32B | 32B 926 | 32B | 32B | 32B | 32B | | 927 | | | | | | 928 V V V V V V 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | 931 | Ciphersuite-Specific Truncation & | 932 | Key utilization | 933 | | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Figure 1 - Algorithm for derivation of session keys from the 937 GSS-API method master key K. 939 For this reason, when used on wireless networks, EAP GSS SHOULD 940 negotiate methods invulnerable to offline dictionary attacks. This 941 includes public key authentication techniques such as [PKINIT], or 942 password-based techniques such as SRP, described in [RFC2945], EKE, 943 described in [EKE], or techniques described in [STRONGAUTH] or [DUAL]. 945 Kerberos V SHOULD NOT be used without extensions providing protection 946 against offline dictionary attacks. As noted in [KRBATTACK], it has 947 been proposed that Kerberos V dictionary attack vulnerabilities be 948 addressed via a pre-authentication exchange. The vulnerability can also 949 be addressed by use of public key authentication with Kerberos, 950 described in [PKINIT]. 952 5.2. Certificate revocation 954 Since the EAP server is typically connected to the Internet during the 955 EAP conversation, it is capable of following a certificate chain or 956 verifying whether the peer's certificate has been revoked. In contrast, 957 the peer may or may not have Internet connectivity, and thus while it 958 can validate the EAP server's certificate based on a pre-configured set 959 of CAs, it may not be able to follow a certificate chain or verify 960 whether the EAP server's certificate has been revoked. 962 In the case where the peer is initiating a voluntary Layer 2 tunnel 963 using PPTP or L2TP, the peer will typically already have a PPP interface 964 and Internet connectivity established at the time of tunnel initiation. 965 As a result, during the EAP conversation it is capable of checking for 966 certificate revocation. 968 However, in the case where the peer is initiating a connection, it will 969 not have Internet connectivity and is therefore not capable of checking 970 for certificate revocation until after the peer has access to the 971 Internet. In this case, the peer SHOULD check for certificate revocation 972 after connecting to the Internet. 974 5.3. Mutual authentication 976 In order to guard against rogue NAS devices, it is recommended that a 977 GSS-API method supporting mutual authentication be selected during the 978 SPNEGO negotiation, as described in [RFC2478]. This also avoids 979 potential reflection attacks against dual one-way authentication 980 methods, such as EAP-MD5. 982 5.4. Credential reuse 984 A peer with valid credentials may reuse those credentials in a 985 subsequent authentication. Credential reuse improves efficiency in a 986 number of scenarios. Where the peer attempts to re-authenticate to an 987 EAP server within a short period of time, the re-authentication time may 988 be shortened. Also, where the peer roams to another NAS willing to 989 accept credentials from a previous NAS, fast-handoff may be achieved. 990 Credential reuse may also prove useful during multi-link authentication. 992 For example, a peer initially using the IAKERB GSS-API method to obtain 993 a TGT and a ticket to the NAS may subsequently reuse that ticket in an 994 AP_REQ/AP_REP exchange. Such an exchange may occur either in-band (e.g. 995 via use of the Kerberos V GSS-API method) or out-of-band (e.g. via an 996 802.1X EAPOL-Key message). Typically in-band efficiency savings are 997 modest (one round-trip saved using the Kerberos V GSS-API method versus 998 IAKERB), since the authentication typically is remoted to the backend 999 authentication server. The savings from out-of-band credential reuse can 1000 be more substantial, since in this case the credential validation may 1001 occur on the NAS. 1003 The decision of whether to attempt to reuse credentials is left up to 1004 the peer, which needs to determine whether credential use is likely to 1005 succeed. The decision may be based on out-of-band information (such as 1006 probe/response messages exchanged via 802.11 [IEEE80211]), or the time 1007 elapsed since the previous authentication attempt. 1009 If the peer attempts to reuse credentials that are not valid, then it 1010 will receive an error response and the peer can re-authenticate using 1011 the more complete sequence. For example, after an initial IAKERB 1012 authentication, the peer will have obtained a TGT from the KDC via the 1013 AS_REP, and a ticket for network access via the TGS_REP. The peer may 1014 subsequently attempt to negotiate the Kerberos V GSS-API method, so as 1015 to reuse the previously obtained credentials. Should a KRB_ERROR be 1016 returned to the peer, then the peer can negotiate IAKERB on its next 1017 attempt instead. 1019 Note that credential reuse for the purpose of "fast handoff" has 1020 significant limitations. For use in "fast handoff", it is desirable for 1021 Kerberos ticket validation to occur on the NAS, rather than remoting the 1022 validation to the backend authentication server, since this will save a 1023 round-trip between the NAS and the backend authentication server. 1025 However, to enable the peer to reuse a Kerberos ticket on a different 1026 NAS, it is necessary for NASen within the same geographic area to share 1027 a key with the KDC. If this is not the case, then peers moving from one 1028 NAS to another will not be able to reuse credentials without either 1029 requiring communication between the NASen, or remoting of the credential 1030 validation to a backend authentication server. 1032 Allowing multiple NASen to share a key with the KDC makes it more likely 1033 that an attacker sniffing the wire will be able to obtain the NAS key, 1034 particularly if the key is derived from a password. Details are provided 1035 within reference [KRBATTACK]. Alternatively, the new NAS can pass the 1036 submitted ticket and authenticator to a backend authentication server or 1037 to the previous NAS for validation. However, requiring communication 1038 between the NAS and backend authentication server for "fast handoff" 1039 adds substantial to the delay. In addition if it is assumed that the 1040 NASen support an Inter-Access Point Protocol (IAPP), then EAP-based 1041 "fast handoff" is not necessary at all. 1043 Similarly, if the EAP servers are set up in a rotary or made available 1044 via a round-robin technique, then the credentials also may not be 1045 reusable without communication with a backend authentication server or 1046 previous NAS. 1048 Furthermore, since existing Kerberos implementations do not include AAA 1049 authorizations within the authorization data field of the Kerberos 1050 ticket [RFC1510], even if the credentials can be reused, it may be 1051 necessary for the NAS to obtain the authorization information from the 1052 AAA server before the correct session state can be re-established on the 1053 new NAS. If AAA authorizations are not obtained prior to granting 1054 access, then the new NAS could potentially provide the wrong service to 1055 the peer. For example, where Filter-Id [RFC2865] or tunnel attributes 1056 [RFC2868] were unavailable, a peer might be given unrestricted network 1057 access where this was not intended. 1059 As a result of these considerations, credential reuse for the purpose of 1060 "fast handoff" does not appear to be practical at this time. 1062 5.5. Key transmission issues 1064 As a result of the EAP GSS conversation, the EAP endpoints will mutually 1065 authenticate and derive a session key, which this specification calls 1066 the "master key". Within GSS-API, it is possible to use GSS_Wrap() to 1067 encrypt using the master key, or GSS_GetMIC() to produce a messsage 1068 integrity check (MIC) keyed by the master key. However, for security 1069 reasons, there are no GSS-API calls to obtain the master key itself. 1071 In the most general case, authentication keys, encryption keys and IVs 1072 may be required for use with the chosen ciphersuite. The keys from which 1073 these session keys are derived are known as "master session keys" and 1074 are derived from the master key. 1076 Since the peer and EAP client reside on the same machine, and the master 1077 key cannot be exported, it is necessary for the master session keys to 1078 be derived within EAP GSS. Once the ciphersuite has been determined, 1079 the master session keys are converted to ciphersuite-specific session 1080 keys and passed to the link layer encryption module. 1082 The situation may be more complex on the NAS, which may or may not 1083 reside on the same machine as the EAP server. In the case where the EAP 1084 server and NAS reside on different machines, there are several 1085 implications for security. Firstly, the mutual authentication defined in 1086 EAP GSS will occur between the peer and the EAP server, not between the 1087 peer and the NAS. 1089 This means that as a result of the EAP GSS conversation, it is not 1090 possible for the peer to validate the identity of the device that it is 1091 speaking to. The second issue is that the master session keys negotiated 1092 between the peer and EAP server will need to be transmitted to the NAS. 1094 Both issues can be addressed via addition of a followon exchange. For 1095 example, where the IAKERB GSS-API method is used for initial 1096 authentication, the Kerberos V GSS-API method can be used to mutually 1097 authenticate the peer and NAS and transfer the master session key from 1098 the peer to the NAS, enclosed in a Kerberos ticket. The NAS can then 1099 derive the master session keys from the master key. Once the ciphersuite 1100 is determined, the master session keys are converted to ciphersuite- 1101 specific session keys and passed to the link layer encryption module on 1102 the NAS. 1104 5.6. Protected negotiation 1106 SPNEGO [RFC2478] supports protected method negotiation in the case where 1107 the negotiated method provides authentication and integrity protection. 1108 In contrast, EAP, described in [RFC 2284], does not provide for 1109 protected method negotiation. 1111 Link layer ciphersuite negotiations are also typically unprotected. For 1112 example, ECP, described in [RFC1968], supports unprotected cipher-suite 1113 negotiations within PPP and is thus vulnerable to attack. Similarly, 1114 802.11, described in [IEEE80211], does not support protected ciphersuite 1115 negotiations. 1117 Since peers completing the GSS-API SPNEGO negotiation will typically 1118 implicitly select a ciphersuite, which includes key strength, encryption 1119 and hashing methods, it is tempting to use this protected ciphersuite 1120 negotiation in place of unprotected ciphersuite negotiation mechanisms. 1122 However, use of EAP GSS for protected ciphersuite negotiation presents 1123 substantial difficulties, since available link layer ciphersuites may 1124 not correspond to the ciphersuites implicitly negotiated as part of 1125 SPNEGO. 1127 For example, 802.11 [IEEE80211] supports Wired Equivalency Privacy 1128 (WEP), a flawed cipher based on RC4 which supports confidentiality but 1129 lacks a keyed message integrity check. As a result, WEP does not 1130 support per-frame authentication and integrity protection. Similarly, 1131 PPP encryption methods such as DESEbis [RFC2419] and 3DES [RFC2420] 1132 support confidentiality but also do not support per-frame authentication 1133 or integrity protection. Since GSS-API ciphersuites available within 1134 GSS-API methods such as Kerberos V [RFC 1964] provide confidentiality as 1135 well as per-packet integrity protection and authentication, they do not 1136 correspond well to these link layer ciphersuites. As a result, the use 1137 of SPNEGO for link-layer ciphersuite negotiation is not recommended. 1139 6. Normative References 1141 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network Authentication 1142 Service (V5)", RFC 1510, September 1993. 1144 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 1145 51, RFC 1661, July 1994. 1147 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1148 1964, June 1996. 1150 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, June 1151 1996. 1153 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 1154 Coradetti, "The PPP Multilink Protocol (MP)." RFC 1990, August 1155 1996. 1157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", BCP 14, RFC 2119, March 1997. 1160 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 1161 2246, November 1998. 1163 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1164 Protocol (EAP)", RFC 2284, March 1998. 1166 [RFC2478] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 1167 Negotiation Mechanism", RFC 2478, December 1998. 1169 [RFC2743] Linn, J., "Generic Security Service Application Program 1170 Interface, Version 2", RFC 2743, January 2000. 1172 [IEEE8021X] 1173 IEEE Standards for Local and Metropolitan Area Networks: Port 1174 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 1176 [KERB] Neuman, B. C., Ts'o, T., "Kerberos: An Authentication Service 1177 for Computer Networks", IEEE Communications, 32(9):33-38, 1178 September 1994. 1180 [IAKERB] Swift, M., Trostle, J., Aboba, B., Zorn, G., "Initial 1181 Authentication and Pass Through Authentication Using Kerberos 1182 V5 and the GSS-API (IAKERB)", Internet draft (work in 1183 progress), draft-ietf-cat-iakerb-08.txt, August 2001. 1185 7. Informative References 1187 [RFC2104] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 1188 Authentication", RFC 2104, February 1997. 1190 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 1191 Version 2 (DESE-bis)", RFC 2419, September 1998. 1193 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 1194 RFC 2420, September 1998. 1196 [RFC2716] Aboba, B., Simon, S.,"PPP EAP TLS Authentication Protocol", 1197 RFC 2716, October 1999. 1199 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1200 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1201 2000. 1203 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1205 [RFC2867] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting 1206 Modifications for Tunnel Protocol Support", RFC 2867, June 1207 2000. 1209 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1210 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", 1211 RFC 2868, June 2000. 1213 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 1214 2869, June 2000. 1216 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 1217 2945, September 2000. 1219 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption 1220 (MPPE) RFC 3078, March 2001. 1222 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 1223 Encryption (MPPE)," RFC 3079, March 2001. 1225 [IEEE80211] 1226 Information technology - Telecommunications and information 1227 exchange between systems - Local and metropolitan area 1228 networks - Specific Requirements Part 11: Wireless LAN Medium 1229 Access Control (MAC) and Physical Layer (PHY) Specifications, 1230 IEEE Std. 802.11-1997, 1997. 1232 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1233 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1235 [DESFIPS] National Bureau of Standards, "DES Modes of Operation", FIPS 1236 PUB 81 (December 1980). 1238 [KRBATTACK] 1239 Wu, T., "A Real-World Analysis of Kerberos Password Security", 1240 Stanford University Computer Science Department, 1241 http://theory.stanford.edu/~tjw/krbpass.html 1243 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 1244 authentication system", Proceedings of the 1991 Winter USENIX 1245 Conference, pp. 253-267, 1991. 1247 [KERB4WEAK] 1248 Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 1249 Kerberos 4 session keys", Proceedings of the Internet Society 1250 Network and Distributed System Security Symposium, pp. 60-70, 1251 March 1997. 1253 [EKE] Bellovin, S.M., Merritt, M., "Encrypted key exchange: 1254 Password-based protocols secure against dictionary attacks", 1255 Proceedings of the 1992 IEEE Computer Society Conference on 1256 Research in Security and Privacy, pp. 72-84, 1992. 1258 [STRONGAUTH] 1259 Jablon, D., "Strong password-only authenticated key exchange", 1260 Computer Communication Review, 26(5):5-26, October 1996. 1262 [DUAL] Jaspan, B., "Dual-workfactor encrypted key exchange: 1263 Efficiently preventing password chaining and dictionary 1264 attacks", Proceedings of the Sixth Annual USENIX Security 1265 Conference, pp. 43-50, July 1996. 1267 [IEEE80211i] 1268 IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 1269 Telecommunications and Information Exchange between Systems - 1270 LAN/MAN Specific Requirements - Part 11: Wireless Medium 1271 Access Control (MAC) and physical layer (PHY) specifications: 1272 Specification for Enhanced Security", July 2001. 1274 [AESProp] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 1275 Proposal, June 1998. 1276 http://csrc.nist.gov/encryption/aes/round2/ 1277 AESAlgs/Rijndael/Rijndael.pdf 1279 [AESFIPS] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard 1280 (AES)", U.S. DoC/NIST, summer 2001. 1282 [MODES] "Symmetric Key Block Cipher Modes of Operation," 1283 http://www.nist.gov/modes. 1285 [BLOCK] "Recommendation for Block Cipher Modes of Operation", National 1286 Institute of Standards and Technology (NIST) Special 1287 Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing 1288 Office, Washington, DC, July 2001. 1290 [PKINIT] Tung, B. Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., 1291 Wray, J., Trostle, J., "Public Key Cryptography for Initial 1292 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1293 init-13.txt, August 2001. 1295 IANA Considerations 1297 This document requires assignment of a EAP Type for EAP GSS. It does not 1298 create any new number spaces for IANA administration. 1300 Acknowledgments 1302 Thanks to Paul Leach of Microsoft, Glen Zorn of Cisco Systems, and Jesse 1303 Walker of Intel for useful discussions of this problem space. 1305 Authors' Addresses 1307 Bernard Aboba 1308 Microsoft Corporation 1309 One Microsoft Way 1310 Redmond, WA 98052 1312 Phone: +1 425 706 6605 1313 EMail: bernarda@microsoft.com 1315 Dan Simon 1316 Microsoft Research 1317 Microsoft Corporation 1318 One Microsoft Way 1319 Redmond, WA 98052 1321 EMail: dansimon@microsoft.com 1322 Phone: +1 425 706 6711 1324 Appendix A - Example IAKERB topologies 1326 Where EAP GSS is used along with the GSS-API IAKERB [IAKERB] or Kerberos 1327 V [RFC1964] mechanisms, two major topologies are possible: 1329 RADIUS+KDC backend 1330 Here a RADIUS backend is used, along with a Kerberos KDC. The NAS 1331 functions as an EAP-pass-through device as described in [RFC2284]. 1332 This involves encapsulating EAP messages received from the peer 1333 within RADIUS as described in [RFC2869], and passing them on to the 1334 RADIUS server. In turn, the RADIUS server acts as an IAKERB proxy, 1335 de-capsulating EAP GSS/IAKERB packets, and passing them on to the 1336 Kerberos KDC. In turn, the RADIUS server will encapsulate packets 1337 from the Kerberos KDC in EAP GSS/IAKERB and send them to the NAS. 1338 EAP-Message attributes received from the RADIUS server are de- 1339 capsulated by the NAS and sent to the peer. In this topology, the 1340 NAS need not have knowledge of specific EAP or GSS-API methods, 1341 while the RADIUS server does require this knowledge. 1343 KDC backend 1344 In this topology, only a Kerberos KDC is used as a backend, and the 1345 NAS functions as an IAKERB proxy, de-capsulating EAP GSS/IAKERB 1346 messages and passing them on to the KDC. Messages from the KDC are 1347 encapsulated within EAP GSS/IAKERB by the NAS and sent to the peer. 1348 In this case, the NAS needs to understand the EAP GSS, GSS-API 1349 IAKERB, as well as GSS-API Kerberos V mechanisms. In addition, 1350 where the peer already has a valid TGT and ticket to the NAS, it 1351 may choose to use the Kerberos V mechanism within EAP. Note that in 1352 the case of 802.11, the Kerberos AP_REQ/AP_REP messages may be 1353 carried in messages outside the conventional EAP exchange, such as 1354 those defined in [IEEE8021X] so that use of the Kerberos V 1355 mechanism within EAP is not necessary. 1357 In the examples below, each topology is discussed. While nominally the 1358 EAP conversation occurs between the NAS and the peer, the NAS MAY act as 1359 a pass-through device, with the EAP packets received from the peer being 1360 encapsulated for transmission to a RADIUS server. In the discussion 1361 that follows, we will use the term "EAP server" to denote the ultimate 1362 endpoint conversing with the peer. 1364 A.1 RADIUS+KDC backend 1366 In this topology, the NAS will act as an EAP pass-through, and the 1367 RADIUS server acts as an IAKERB proxy. A successful EAP GSS/IAKERB 1368 authentication will appear as follows: 1370 Peer NAS RADIUS KDC 1371 ------ ------------- --------- ------ 1372 EAP/Identity 1373 <-Request 1375 EAP/Identity 1376 Response -> 1378 EAP/Identity 1379 Response -> 1380 Access-Challenge 1381 EAP GSS Request 1382 <- (Start) 1384 <-EAP GSS Request(Empty) 1386 EAP GSS 1387 Response [1] 1388 (SPNEGO) -> 1390 EAP GSS Response 1391 (SPNEGO) -> 1392 Access-Challenge 1393 EAP GSS Request 1394 <-(SPNEGO) 1396 EAP GSS Request 1397 <-(SPNEGO) 1399 EAP GSS IAKERB 1400 Response [2] 1401 (AS_REQ) -> 1403 EAP GSS IAKERB 1404 Response 1405 (AS_REQ) -> 1407 AS_REQ -> 1408 <- AS_REP 1410 Access-Challenge 1411 EAP GSS IAKERB Request 1413 <-(AS_REP) 1415 EAP GSS IAKERB 1416 Request 1417 <-(AS_REP) 1419 EAP GSS IAKERB 1420 Response [3] 1421 (TGS_REQ) -> 1423 EAP GSS IAKERB 1424 Response 1425 (TGS_REQ) -> 1427 TGS_REQ -> 1428 <- TGS_REP 1430 Access-Challenge 1431 EAP GSS IAKERB Request 1432 <-(TGS_REP) 1433 EAP GSS IAKERB 1434 Request 1435 <-(TGS_REP) 1437 EAP GSS IAKERB 1438 Response 1439 (Empty) -> 1441 EAP GSS IAKERB 1442 Response 1443 (Empty) -> 1444 Access-Accept [4] 1445 <- EAP-Success 1447 <- EAP-Success 1448 AP_REQ -> 1449 <- AP_REP [5] 1451 Notes: 1453 1. IAKERB may be requested by the EAP GSS client without the need for 1454 negotiation, or SPNEGO may be used. 1456 2. The AS_REQ requests a TGT from the KDC. It may or may not include 1457 PADATA. As a result, the AS_REQ may not authenticate the peer to 1458 the KDC, but the AS_REP authenticates the KDC to the peer. 1460 3. The TGS_REQ requests a ticket to the NAS service. The ticket is 1461 encrypted with the NAS's key so that it can only be validated by 1462 the NAS. 1464 4. On receiving a TGS_REP from the KDC rather than a KRB_ERROR, the 1465 RADIUS server can conclude that the peer has successfully 1466 authenticated, and thus that it is appropriate to reply to the NAS 1467 with an Access-Accept encapsulating an EAP-Success. 1469 5. The IAKERB exchange ends before the AP_REQ/AP_REP exchange occurs. 1470 As a result, the AP_REQ/AP_REP exchange either will not occur 1471 (preventing mutual authentication between peer and NAS or transport 1472 of the session key from peer to NAS), will occur out-of-band (e.g. 1473 after access is granted), or will occur in a subsequent EAP GSS 1474 conversation (e.g. using the GSS-API Kerberos V method). 1476 A.2 Kerberos KDC backend 1478 In this topology, there is no RADIUS server, and the NAS functions as an 1479 IAKERB proxy, de-capsulating EAP GSS/IAKERB frames and passing them on 1480 to the KDC. In turn, packets from the KDC are are encapsulated in EAP 1481 GSS/IAKERB frames and sent to the peer by the NAS. Where IAKERB is 1482 used, the NAS functions as an IAKERB proxy, de-capsulating EAP 1483 GSS/IAKERB messages and passing them on to the KDC. In addition, where 1484 the peer already has a valid TGT and ticket to the NAS, it may choose to 1485 use the Kerberos V mechanism within EAP. Note that in the case of 1486 802.11, the Kerberos AP_REQ/AP_REP messages are carried in messages 1487 outside the conventional EAP exchange, such as the EAPOL-Key messages 1488 described in [IEEE8021X] so that use of the Kerberos V mechanism within 1489 EAP is not necessary. 1491 In the Kerberos-only topology, messages from the KDC are encapsulated 1492 within EAP GSS/IAKERB and sent to the peer. In this case, the NAS needs 1493 to understand the EAP GSS, GSS-API IAKERB, as well as GSS-API Kerberos V 1494 mechanisms. 1496 A successful EAP GSS/IAKERB authentication occurring in a topology with 1497 a NAS acting as an IAKERB proxy to a Kerberos KDC will appear as 1498 follows: 1500 Peer NAS KDC 1501 ------ ------------- --------- 1502 EAP/Identity 1503 <-Request 1505 EAP/Identity 1506 Response -> 1508 <-EAP GSS Start 1510 EAP GSS IAKERB 1511 Response [1] 1512 (AS_REQ) -> 1514 AS_REQ -> 1515 <- AS_REP [2] 1517 EAP GSS IAKERB Request 1518 <-AS_REP) 1520 EAP GSS IAKERB 1521 Response [3] 1522 (TGS_REQ) -> 1524 TGS_REQ -> 1526 <- TGS_REP [4] 1528 EAP GSS IAKERB Request 1529 <-(TGS_REP) 1531 EAP GSS IAKERB 1532 Response 1533 (Empty) -> 1535 <- EAP-Success 1536 AP_REQ [5]-> 1537 <- AP_REP [6] 1538 Notes: 1540 1. If PADATA is not used in the AS_REQ, then the peer does not 1541 authenticate to the KDC. 1543 2. The KDC authenticates to the peer in the AS_REP. 1545 3. The peer authenticates to the KDC via the TGS_REQ. 1547 4. The KDC authenticates to the peer via the TGS_REP. The TGS_REP 1548 also provides the peer with a ticket and session-key for use with 1549 the NAS. 1551 5. Up until this point, the peer has not mutually authenticated with 1552 the NAS, or exchanged a key with it. As a result, the peer and NAS 1553 need to conclude an AP_REQ/AP_REP exchange. This can occur in-band 1554 or out-of-band. In the AP-REQ, the peer authenticates to the NAS 1555 and provides it with a session key. 1557 6. The NAS authenticates to the peer using the AP_REP. 1559 Appendix B - The Pseudorandom Function 1561 Given below is the description of the HMAC and pseudorandom function 1562 based on Section 5 of the TLS Protocol Version 1.0 specification 1563 [RFC2246]. 1565 Some of operations in the key derivation require a keyed MIC; this is a 1566 secure digest of some data protected by a secret. Forging the MIC is 1567 infeasible without knowledge of the MIC secret. The construction we use 1568 for this operation is known as HMAC, described in [RFC2104]. 1570 HMAC can be used with a variety of different hash algorithms. We use it 1571 with two different algorithms: MD5 and SHA-1, denoting these as 1572 HMAC_MD5(secret, data) and HMAC_SHA1(secret, data). Additional hash 1573 algorithms can be defined and used to protect record data, but MD5 and 1574 SHA-1 are hard coded into the protocol. 1576 In addition, a construction is required to do expansion of secrets into 1577 blocks of data for the purposes of key generation or validation. This 1578 pseudo-random function (PRF) takes as input a secret, a seed, and an 1579 identifying label and produces an output of arbitrary length. 1581 In order to make the PRF as secure as possible, it uses two hash 1582 algorithms in a way which should guarantee its security if either 1583 algorithm remains secure. 1585 First, we define a data expansion function, P_hash(secret, data) which 1586 uses a single hash function to expand a secret and seed into an 1587 arbitrary quantity of output: 1589 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 1590 HMAC_hash(secret, A(2) + seed) + 1591 HMAC_hash(secret, A(3) + seed) + ... 1593 Where + indicates concatenation. A() is defined as: 1595 A(0) = seed 1596 A(i) = HMAC_hash(secret, A(i-1)) 1598 P_hash can be iterated as many times as is necessary to produce the 1599 required quantity of data. For example, if P_SHA-1 was being used to 1600 create 64 bytes of data, it would have to be iterated 4 times (through 1601 A(4)), creating 80 bytes of output data; the last 16 bytes of the final 1602 iteration would then be discarded, leaving 64 bytes of output data. 1604 The PRF is created by splitting the secret into two halves and using one 1605 half to generate data with P_MD5 and the other half to generate data 1606 with P_SHA-1, then exclusive-or'ing the outputs of these two expansion 1607 functions together. 1609 S1 and S2 are the two halves of the secret and each is the same length. 1610 S1 is taken from the first half of the secret, S2 from the second half. 1611 Their length is created by rounding up the length of the overall secret 1612 divided by two; thus, if the original secret is an odd number of bytes 1613 long, the last byte of S1 will be the same as the first byte of S2. 1615 L_S = length in bytes of secret; 1616 L_S1 = L_S2 = ceil(L_S / 2); 1618 The secret is partitioned into two halves (with the possibility of one 1619 shared byte) as described above, S1 taking the first L_S1 bytes and S2 1620 the last L_S2 bytes. 1622 The PRF is then defined as the result of mixing the two pseudorandom 1623 streams by exclusive-or'ing them together. 1625 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR 1626 P_SHA-1(S2, label + seed); 1628 The label is an ASCII string. It should be included in the exact form it 1629 is given without a length byte or trailing null character. For example, 1630 the label "slithy toves" would be processed by hashing the following 1631 bytes: 1633 73 6C 69 74 68 79 20 74 6F 76 65 73 1635 Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 1636 byte outputs, the boundaries of their internal iterations will not be 1637 aligned; to generate a 80 byte output will involve P_MD5 being iterated 1638 through A(5), while P_SHA-1 will only iterate through A(4). 1640 Intellectual Property Statement 1642 The IETF takes no position regarding the validity or scope of any 1643 intellectual property or other rights that might be claimed to pertain 1644 to the implementation or use of the technology described in this 1645 document or the extent to which any license under such rights might or 1646 might not be available; neither does it represent that it has made any 1647 effort to identify any such rights. Information on the IETF's 1648 procedures with respect to rights in standards-track and standards- 1649 related documentation can be found in BCP-11. Copies of claims of 1650 rights made available for publication and any assurances of licenses to 1651 be made available, or the result of an attempt made to obtain a general 1652 license or permission for the use of such proprietary rights by 1653 implementors or users of this specification can be obtained from the 1654 IETF Secretariat. 1656 The IETF invites any interested party to bring to its attention any 1657 copyrights, patents or patent applications, or other proprietary rights 1658 which may cover technology that may be required to practice this 1659 standard. Please address the information to the IETF Executive 1660 Director. 1662 Full Copyright Statement 1664 Copyright (C) The Internet Society (2002). All Rights Reserved. 1665 This document and translations of it may be copied and furnished to 1666 others, and derivative works that comment on or otherwise explain it or 1667 assist in its implementation may be prepared, copied, published and 1668 distributed, in whole or in part, without restriction of any kind, 1669 provided that the above copyright notice and this paragraph are included 1670 on all such copies and derivative works. However, this document itself 1671 may not be modified in any way, such as by removing the copyright notice 1672 or references to the Internet Society or other Internet organizations, 1673 except as needed for the purpose of developing Internet standards in 1674 which case the procedures for copyrights defined in the Internet 1675 Standards process must be followed, or as required to translate it into 1676 languages other than English. The limited permissions granted above are 1677 perpetual and will not be revoked by the Internet Society or its 1678 successors or assigns. This document and the information contained 1679 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1680 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1681 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1682 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1683 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1684 Expiration Date 1686 This memo is filed as , and expires 1687 November 23, 2002.