idnits 2.17.1 draft-aboba-pppext-eapgss-11.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 39 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 40 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 849 has weird spacing: '...tor) is obtai...' == Line 969 has weird spacing: '...he peer has a...' == Line 1085 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 (13 February 2002) is 8108 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1509 -- Looks like a reference, but probably isn't: '2' on line 1513 -- Looks like a reference, but probably isn't: '3' on line 1519 == Missing Reference: 'KERBLIM' is mentioned on line 880, but not defined == Missing Reference: 'RFC 2284' is mentioned on line 1107, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Missing Reference: 'RFC 1964' is mentioned on line 1133, but not defined -- Looks like a reference, but probably isn't: '4' on line 1524 -- Looks like a reference, but probably isn't: '5' on line 1447 -- Looks like a reference, but probably isn't: '6' on line 1535 == Unused Reference: 'KERB' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'RFC2867' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'DESFIPS' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'IEEE80211i' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'AESProp' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'AESFIPS' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'BLOCK' is defined on line 1284, 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: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-13 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 13 February 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 .............................. 32 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 entropy of the GSS- 815 API MIC cannot be guaranteed, additional randomness needs to be 816 introduced into the derivation at this point. 818 [2] Nonce generation. TLS includes an exchange of nonces, and the 819 exchanged nonces are used within the keying hierarchy in order to 820 ensure liveness in the derived master session keys. GSS-API methods 821 such as Kerberos do not include such a nonce exchange, although 822 typically some other source of "liveness" is provided, such as a 823 counter or a time value. The variation in GSS-API methods makes it 824 difficult to come up with a key hierarchy that can be used with any 825 GSS-API method, if only GSS-API calls are available. To circumvent 826 this limitation, EAP GSS adds a nonce exchange patterned after 827 [RFC2246]. 829 In the techniques described here, master session keys are derived from 830 the master key derived by the GSS-API method, but are never used to 831 encrypt or decrypt data; they are only used in the derivation of 832 transient session keys. 834 The derivation proceeds as follows: 836 [1] The "Pseudo-Master Key" K' is derived from the raw master key using 837 the formula: K' = HMAC-SHA1("", GSS_GetMIC("EAP GSS pseudo master 838 key") | random). Here random is defined as the concatenation of the 839 message fields client_nonce and server_nonce (in that order). 841 [2] Given the K' value and the pseudorandom function (PRF) defined in 842 Appendix B, the value PRF1 = PRF(K', "client EAP encryption", 843 random) is computed up to 128 bytes, and the PRF2 = PRF("","client 844 EAP encryption", random) is computed up to 64 bytes (where "" is an 845 empty string). Here random is defined as the concatenation of the 846 message fields client_nonce and server_nonce (in that order). 848 [3] The peer encryption key (the one used for encrypting data from peer 849 to authenticator) is obtained by truncating to the correct length 850 the first 32 bytes of PRF1. The authenticator encryption key (the 851 one used for encrypting data from authenticator to peer), if 852 different from the client encryption key, is obtained by truncating 853 to the correct length the second 32 bytes of PRF1. The peer 854 authentication key (the one used for computing MICs for messages 855 from peer to authenticator), if used, is obtained by truncating to 856 the correct length the third 32 bytes of PRF1. The authenticator 857 authentication key (the one used for computing MICs for messages 858 from authenticator to peer), if used, and if different from the 859 peer authentication key, is obtained by truncating to the correct 860 length the fourth 32 bytes of PRF1. The peer initialization vector 861 (IV), used for messages from peer to authenticator if a block 862 cipher has been specified, is obtained by truncating to the 863 cipher's block size the first 32 bytes of PRF2. Finally, the 864 authenticator initialization vector (IV), used for messages from 865 peer to authenticator if a block cipher has been specified, is 866 obtained by truncating to the cipher's block size the second 32 867 bytes of PRF2. 869 The use of these encryption, authentication keys and IVs is specific to 870 the ciphersuite used. Additional keys or other non-secret values (such 871 as IVs) can be obtained as needed for future ciphersuites by extending 872 the outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 874 A description of the key hierarchy is provided on the next page. 876 5. Security Considerations 878 5.1. Dictionary attacks 880 As noted in [KRBATTACK],[KERBLIM],[KERB4WEAK], both Kerberos IV and V 881 are vulnerable to dictionary attack. These attacks are particularly 882 potent when carried out in a location where a large number of 883 authentication exchanges can be collected within a short period of time, 884 such as with wireless LANs deployed in "hot spots". 886 As noted in [KRBATTACK], offline dictionary attacks are easily carried 887 out against the AS_REP, since the key encrypting the enclosed Kerberos 888 ticket is a function of the password. Such attacks are amenable to 889 parallelization, and it is therefore possible to crack a large number of 890 passwords in short time with only modest resources. The imposition of a 891 password policy is likely only to decrease the yield, but given access 892 to sufficient exchanges, large scale password compromise remains 893 possible. 895 For this reason, when used on wireless networks, EAP GSS SHOULD 896 negotiate methods invulnerable to offline dictionary attacks. This 897 includes public key authentication techniques such as [PKINIT], or 898 password-based techniques such as SRP, described in [RFC2945], EKE, 899 described in [EKE], or techniques described in [STRONGAUTH] or [DUAL]. 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 | Derivation of the pseudo | 904 | master key from the | 905 | raw master key | 906 | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | 909 | K' 910 | 911 V 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | | 914 | Master Session Key | 915 | Derivation | 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | 919 | PRF1 | PRF2 920 | 128B | 64B 921 V V 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | | | | 924 | Key | | IV | 925 | Derivation | | Derivation | 926 | | | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | P->A | A->P | P->A | A->P | P->A | A->P 929 | Enc. | Enc. | Auth. | Auth. | IV | IV 930 | Key | Key | Key | Key | 32B | 32B 931 | 32B | 32B | 32B | 32B | | 932 | | | | | | 933 V V V V V V 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | | 936 | Ciphersuite-Specific Truncation & | 937 | Key utilization | 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 1 - Algorithm for derivation of session keys from the 942 GSS-API method master key K. 944 Kerberos V SHOULD NOT be used without extensions providing protection 945 against offline dictionary attacks. As noted in [KRBATTACK], it has 946 been proposed that Kerberos V dictionary attack vulnerabilities be 947 addressed via a pre-authentication exchange. The vulnerability can also 948 be addressed by use of public key authentication with Kerberos, 949 described in [PKINIT]. 951 5.2. Certificate revocation 953 Since the EAP server is typically connected to the Internet during the 954 EAP conversation, it is capable of following a certificate chain or 955 verifying whether the peer's certificate has been revoked. In contrast, 956 the peer may or may not have Internet connectivity, and thus while it 957 can validate the EAP server's certificate based on a pre-configured set 958 of CAs, it may not be able to follow a certificate chain or verify 959 whether the EAP server's certificate has been revoked. 961 In the case where the peer is initiating a voluntary Layer 2 tunnel 962 using PPTP or L2TP, the peer will typically already have a PPP interface 963 and Internet connectivity established at the time of tunnel initiation. 964 As a result, during the EAP conversation it is capable of checking for 965 certificate revocation. 967 However, in the case where the peer is initiating a connection, it will 968 not have Internet connectivity and is therefore not capable of checking 969 for certificate revocation until after the peer has access to the 970 Internet. In this case, the peer SHOULD check for certificate revocation 971 after connecting to the Internet. 973 5.3. Mutual authentication 975 In order to guard against rogue NAS devices, it is recommended that a 976 GSS-API method supporting mutual authentication be selected during the 977 SPNEGO negotiation, as described in [RFC2478]. This also avoids 978 potential reflection attacks against dual one-way authentication 979 methods, such as EAP-MD5. 981 5.4. Credential reuse 983 A peer with valid credentials may reuse those credentials in a 984 subsequent authentication. Credential reuse improves efficiency in a 985 number of scenarios. Where the peer attempts to re-authenticate to an 986 EAP server within a short period of time, the re-authentication time may 987 be shortened. Also, where the peer roams to another NAS willing to 988 accept credentials from a previous NAS, fast-handoff may be achieved. 989 Credential reuse may also prove useful during multi-link authentication. 991 For example, a peer initially using the IAKERB GSS-API method to obtain 992 a TGT and a ticket to the NAS may subsequently reuse that ticket in an 993 AP_REQ/AP_REP exchange. Such an exchange may occur either in-band (e.g. 994 via use of the Kerberos V GSS-API method) or out-of-band (e.g. via an 995 802.1X EAPOL-Key message). Typically in-band efficiency savings are 996 modest (one round-trip saved using the Kerberos V GSS-API method versus 997 IAKERB), since the authentication typically is remoted to the backend 998 authentication server. The savings from out-of-band credential reuse can 999 be more substantial, since in this case the credential validation may 1000 occur on the NAS. 1002 The decision of whether to attempt to reuse credentials is left up to 1003 the peer, which needs to determine whether credential use is likely to 1004 succeed. The decision may be based on out-of-band information (such as 1005 probe/response messages exchanged via 802.11 [IEEE80211]), or the time 1006 elapsed since the previous authentication attempt. 1008 If the peer attempts to reuse credentials that are not valid, then it 1009 will receive an error response and the peer can re-authenticate using 1010 the more complete sequence. For example, after an initial IAKERB 1011 authentication, the peer will have obtained a TGT from the KDC via the 1012 AS_REP, and a ticket for network access via the TGS_REP. The peer may 1013 subsequently attempt to negotiate the Kerberos V GSS-API method, so as 1014 to reuse the previously obtained credentials. Should a KRB_ERROR be 1015 returned to the peer, then the peer can negotiate IAKERB on its next 1016 attempt instead. 1018 Note that credential reuse for the purpose of "fast handoff" has 1019 significant limitations. For use in "fast handoff", it is desirable for 1020 Kerberos ticket validation to occur on the NAS, rather than remoting the 1021 validation to the backend authentication server, since this will save a 1022 round-trip between the NAS and the backend authentication server. 1024 However, to enable the peer to reuse a Kerberos ticket on a different 1025 NAS, it is necessary for NASen within the same geographic area to share 1026 a key with the KDC. If this is not the case, then peers moving from one 1027 NAS to another will not be able to reuse credentials without either 1028 requiring communication between the NASen, or remoting of the credential 1029 validation to a backend authentication server. 1031 Allowing multiple NASen to share a key with the KDC makes it more likely 1032 that an attacker sniffing the wire will be able to obtain the NAS key, 1033 particularly if the key is derived from a password. Details are provided 1034 within reference [KRBATTACK]. Alternatively, the new NAS can pass the 1035 submitted ticket and authenticator to a backend authentication server or 1036 to the previous NAS for validation. However, requiring communication 1037 between the NAS and backend authentication server for "fast handoff" 1038 adds substantial to the delay. In addition if it is assumed that the 1039 NASen support an Inter-Access Point Protocol (IAPP), then EAP-based 1040 "fast handoff" is not necessary at all. 1042 Similarly, if the EAP servers are set up in a rotary or made available 1043 via a round-robin technique, then the credentials also may not be 1044 reusable without communication with a backend authentication server or 1045 previous NAS. 1047 Furthermore, since existing Kerberos implementations do not include AAA 1048 authorizations within the authorization data field of the Kerberos 1049 ticket [RFC1510], even if the credentials can be reused, it may be 1050 necessary for the NAS to obtain the authorization information from the 1051 AAA server before the correct session state can be re-established on the 1052 new NAS. If AAA authorizations are not obtained prior to granting 1053 access, then the new NAS could potentially provide the wrong service to 1054 the peer. For example, where Filter-Id [RFC2865] or tunnel attributes 1055 [RFC2868] were unavailable, a peer might be given unrestricted network 1056 access where this was not intended. 1058 As a result of these considerations, credential reuse for the purpose of 1059 "fast handoff" does not appear to be practical at this time. 1061 5.5. Key transmission issues 1063 As a result of the EAP GSS conversation, the EAP endpoints will mutually 1064 authenticate and derive a session key, which this specification calls 1065 the "master key". Within GSS-API, it is possible to use GSSWrap() to 1066 encrypt using the master key, or GSSGetMIC() to produce a messsage 1067 integrity check (MIC) keyed by the master key. However, for security 1068 reasons, there are no GSS-API calls to obtain the master key itself. 1070 In the most general case, authentication keys, encryption keys and IVs 1071 may be required for use with the chosen ciphersuite. The keys from which 1072 these session keys are derived are known as "master session keys" and 1073 are derived from the master key. 1075 Since the peer and EAP client reside on the same machine, and the master 1076 key cannot be exported, it is necessary for the master session keys to 1077 be derived within EAP GSS. Once the ciphersuite has been determined, 1078 the master session keys are converted to ciphersuite-specific session 1079 keys and passed to the link layer encryption module. 1081 The situation may be more complex on the NAS, which may or may not 1082 reside on the same machine as the EAP server. In the case where the EAP 1083 server and NAS reside on different machines, there are several 1084 implications for security. Firstly, the mutual authentication defined in 1085 EAP GSS will occur between the peer and the EAP server, not between the 1086 peer and the NAS. 1088 This means that as a result of the EAP GSS conversation, it is not 1089 possible for the peer to validate the identity of the device that it is 1090 speaking to. The second issue is that the master session keys negotiated 1091 between the peer and EAP server will need to be transmitted to the NAS. 1093 Both issues can be addressed via addition of a followon exchange. For 1094 example, where the IAKERB GSS-API method is used for initial 1095 authentication, the Kerberos V GSS-API method can be used to mutually 1096 authenticate the peer and NAS and transfer the master session key from 1097 the peer to the NAS, enclosed in a Kerberos ticket. The NAS can then 1098 derive the master session keys from the master key. Once the ciphersuite 1099 is determined, the master session keys are converted to ciphersuite- 1100 specific session keys and passed to the link layer encryption module on 1101 the NAS. 1103 5.6. Protected negotiation 1105 SPNEGO [RFC2478] supports protected method negotiation in the case where 1106 the negotiated method provides authentication and integrity protection. 1107 In contrast, EAP, described in [RFC 2284], does not provide for 1108 protected method negotiation. 1110 Link layer ciphersuite negotiations are also typically unprotected. For 1111 example, ECP, described in [RFC1968], supports unprotected cipher-suite 1112 negotiations within PPP and is thus vulnerable to attack. Similarly, 1113 802.11, described in [IEEE80211], does not support protected ciphersuite 1114 negotiations. 1116 Since peers completing the GSS-API SPNEGO negotiation will typically 1117 implicitly select a ciphersuite, which includes key strength, encryption 1118 and hashing methods, it is tempting to use this protected ciphersuite 1119 negotiation in place of unprotected ciphersuite negotiation mechanisms. 1121 However, use of EAP GSS for protected ciphersuite negotiation presents 1122 substantial difficulties, since available link layer ciphersuites may 1123 not correspond to the ciphersuites implicitly negotiated as part of 1124 SPNEGO. 1126 For example, 802.11 [IEEE80211] supports Wired Equivalency Privacy 1127 (WEP), a flawed cipher based on RC4 which supports confidentiality but 1128 lacks a keyed message integrity check. As a result, WEP does not 1129 support per-frame authentication and integrity protection. Similarly, 1130 PPP encryption methods such as DESEbis [RFC2419] and 3DES [RFC2420] 1131 support confidentiality but also do not support per-frame authentication 1132 or integrity protection. Since GSS-API ciphersuites available within 1133 GSS-API methods such as Kerberos V [RFC 1964] provide confidentiality as 1134 well as per-packet integrity protection and authentication, they do not 1135 correspond well to these link layer ciphersuites. As a result, the use 1136 of SPNEGO for link-layer ciphersuite negotiation is not recommended. 1138 6. Normative References 1140 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network Authentication 1141 Service (V5)", RFC 1510, September 1993. 1143 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 1144 51, RFC 1661, July 1994. 1146 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1147 1964, June 1996. 1149 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, June 1150 1996. 1152 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 1153 Coradetti, "The PPP Multilink Protocol (MP)." RFC 1990, August 1154 1996. 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, March 1997. 1159 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 1160 2246, November 1998. 1162 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1163 Protocol (EAP)", RFC 2284, March 1998. 1165 [RFC2478] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 1166 Negotiation Mechanism", RFC 2478, December 1998. 1168 [RFC2743] Linn, J., "Generic Security Service Application Program 1169 Interface, Version 2", RFC 2743, January 2000. 1171 [IEEE8021X] 1172 IEEE Standards for Local and Metropolitan Area Networks: Port 1173 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 1175 [KERB] Neuman, B. C., Ts'o, T., "Kerberos: An Authentication Service 1176 for Computer Networks", IEEE Communications, 32(9):33-38, 1177 September 1994. 1179 [IAKERB] Swift, M., Trostle, J., Aboba, B., Zorn, G., "Initial 1180 Authentication and Pass Through Authentication Using Kerberos 1181 V5 and the GSS-API (IAKERB)", Internet draft (work in 1182 progress), draft-ietf-cat-iakerb-08.txt, August 2001. 1184 7. Non-normative References 1186 [RFC2104] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 1187 Authentication", RFC 2104, February 1997. 1189 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 1190 Version 2 (DESE-bis)", RFC 2419, September 1998. 1192 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 1193 RFC 2420, September 1998. 1195 [RFC2716] Aboba, B., Simon, S.,"PPP EAP TLS Authentication Protocol", 1196 RFC 2716, October 1999. 1198 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1199 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1200 2000. 1202 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1204 [RFC2867] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting 1205 Modifications for Tunnel Protocol Support", RFC 2867, June 1206 2000. 1208 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1209 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", 1210 RFC 2868, June 2000. 1212 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 1213 2869, June 2000. 1215 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 1216 2945, September 2000. 1218 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption 1219 (MPPE) RFC 3078, March 2001. 1221 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 1222 Encryption (MPPE)," RFC 3079, March 2001. 1224 [IEEE80211] 1225 Information technology - Telecommunications and information 1226 exchange between systems - Local and metropolitan area 1227 networks - Specific Requirements Part 11: Wireless LAN Medium 1228 Access Control (MAC) and Physical Layer (PHY) Specifications, 1229 IEEE Std. 802.11-1997, 1997. 1231 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1232 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1234 [DESFIPS] National Bureau of Standards, "DES Modes of Operation", FIPS 1235 PUB 81 (December 1980). 1237 [KRBATTACK] 1238 Wu, T., "A Real-World Analysis of Kerberos Password Security", 1239 Stanford University Computer Science Department, 1240 http://theory.stanford.edu/~tjw/krbpass.html 1242 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 1243 authentication system", Proceedings of the 1991 Winter USENIX 1244 Conference, pp. 253-267, 1991. 1246 [KERB4WEAK] 1247 Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 1248 Kerberos 4 session keys", Proceedings of the Internet Society 1249 Network and Distributed System Security Symposium, pp. 60-70, 1250 March 1997. 1252 [EKE] Bellovin, S.M., Merritt, M., "Encrypted key exchange: 1253 Password-based protocols secure against dictionary attacks", 1254 Proceedings of the 1992 IEEE Computer Society Conference on 1255 Research in Security and Privacy, pp. 72-84, 1992. 1257 [STRONGAUTH] 1258 Jablon, D., "Strong password-only authenticated key exchange", 1259 Computer Communication Review, 26(5):5-26, October 1996. 1261 [DUAL] Jaspan, B., "Dual-workfactor encrypted key exchange: 1262 Efficiently preventing password chaining and dictionary 1263 attacks", Proceedings of the Sixth Annual USENIX Security 1264 Conference, pp. 43-50, July 1996. 1266 [IEEE80211i] 1267 IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 1268 Telecommunications and Information Exchange between Systems - 1269 LAN/MAN Specific Requirements - Part 11: Wireless Medium 1270 Access Control (MAC) and physical layer (PHY) specifications: 1271 Specification for Enhanced Security", July 2001. 1273 [AESProp] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 1274 Proposal, June 1998. 1275 http://csrc.nist.gov/encryption/aes/round2/ 1276 AESAlgs/Rijndael/Rijndael.pdf 1278 [AESFIPS] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard 1279 (AES)", U.S. DoC/NIST, summer 2001. 1281 [MODES] "Symmetric Key Block Cipher Modes of Operation," 1282 http://www.nist.gov/modes. 1284 [BLOCK] "Recommendation for Block Cipher Modes of Operation", National 1285 Institute of Standards and Technology (NIST) Special 1286 Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing 1287 Office, Washington, DC, July 2001. 1289 [PKINIT] Tung, B. Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., 1290 Wray, J., Trostle, J., "Public Key Cryptography for Initial 1291 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1292 init-13.txt, August 2001. 1294 IANA Considerations 1296 This document requires assignment of a EAP Type for EAP GSS. It does not 1297 create any new number spaces for IANA administration. 1299 Acknowledgments 1301 Thanks to Paul Leach of Microsoft, Glen Zorn of Cisco Systems, and Jesse 1302 Walker of Intel for useful discussions of this problem space. 1304 Authors' Addresses 1306 Bernard Aboba 1307 Microsoft Corporation 1308 One Microsoft Way 1309 Redmond, WA 98052 1311 Phone: +1 425 706 6605 1312 EMail: bernarda@microsoft.com 1314 Dan Simon 1315 Microsoft Research 1316 Microsoft Corporation 1317 One Microsoft Way 1318 Redmond, WA 98052 1320 EMail: dansimon@microsoft.com 1321 Phone: +1 425 706 6711 1322 Appendix A - Example IAKERB topologies 1324 Where EAP GSS is used along with the GSS-API IAKERB [IAKERB] or Kerberos 1325 V [RFC1964] mechanisms, two major topologies are possible: 1327 RADIUS+KDC backend 1328 Here a RADIUS backend is used, along with a Kerberos KDC. The NAS 1329 functions as an EAP-pass-through device as described in [RFC2284]. 1330 This involves encapsulating EAP messages received from the peer 1331 within RADIUS as described in [RFC2869], and passing them on to the 1332 RADIUS server. In turn, the RADIUS server acts as an IAKERB proxy, 1333 de-capsulating EAP GSS/IAKERB packets, and passing them on to the 1334 Kerberos KDC. In turn, the RADIUS server will encapsulate packets 1335 from the Kerberos KDC in EAP GSS/IAKERB and send them to the NAS. 1336 EAP-Message attributes received from the RADIUS server are de- 1337 capsulated by the NAS and sent to the peer. In this topology, the 1338 NAS need not have knowledge of specific EAP or GSS-API methods, 1339 while the RADIUS server does require this knowledge. 1341 KDC backend 1342 In this topology, only a Kerberos KDC is used as a backend, and the 1343 NAS functions as an IAKERB proxy, de-capsulating EAP GSS/IAKERB 1344 messages and passing them on to the KDC. Messages from the KDC are 1345 encapsulated within EAP GSS/IAKERB by the NAS and sent to the peer. 1346 In this case, the NAS needs to understand the EAP GSS, GSS-API 1347 IAKERB, as well as GSS-API Kerberos V mechanisms. In addition, 1348 where the peer already has a valid TGT and ticket to the NAS, it 1349 may choose to use the Kerberos V mechanism within EAP. Note that in 1350 the case of 802.11, the Kerberos AP_REQ/AP_REP messages may be 1351 carried in messages outside the conventional EAP exchange, such as 1352 those defined in [IEEE8021X] so that use of the Kerberos V 1353 mechanism within EAP is not necessary. 1355 In the examples below, each topology is discussed. While nominally the 1356 EAP conversation occurs between the NAS and the peer, the NAS MAY act as 1357 a pass-through device, with the EAP packets received from the peer being 1358 encapsulated for transmission to a RADIUS server. In the discussion 1359 that follows, we will use the term "EAP server" to denote the ultimate 1360 endpoint conversing with the peer. 1362 A.1 RADIUS+KDC backend 1364 In this topology, the NAS will act as an EAP pass-through, and the 1365 RADIUS server acts as an IAKERB proxy. A successful EAP GSS/IAKERB 1366 authentication will appear as follows: 1368 Peer NAS RADIUS KDC 1369 ------ ------------- --------- ------ 1370 EAP/Identity 1371 <-Request 1373 EAP/Identity 1374 Response -> 1376 EAP/Identity 1377 Response -> 1378 Access-Challenge 1379 EAP GSS Request 1380 <- (Start) 1382 <-EAP GSS Request(Empty) 1384 EAP GSS 1385 Response [1] 1386 (SPNEGO) -> 1388 EAP GSS Response 1389 (SPNEGO) -> 1390 Access-Challenge 1391 EAP GSS Request 1392 <-(SPNEGO) 1394 EAP GSS Request 1395 <-(SPNEGO) 1397 EAP GSS IAKERB 1398 Response [2] 1399 (AS_REQ) -> 1401 EAP GSS IAKERB 1402 Response 1403 (AS_REQ) -> 1405 AS_REQ -> 1406 <- AS_REP 1408 Access-Challenge 1409 EAP GSS IAKERB Request 1411 <-(AS_REP) 1413 EAP GSS IAKERB 1414 Request 1415 <-(AS_REP) 1417 EAP GSS IAKERB 1418 Response [3] 1419 (TGS_REQ) -> 1421 EAP GSS IAKERB 1422 Response 1423 (TGS_REQ) -> 1425 TGS_REQ -> 1426 <- TGS_REP 1428 Access-Challenge 1429 EAP GSS IAKERB Request 1430 <-(TGS_REP) 1431 EAP GSS IAKERB 1432 Request 1433 <-(TGS_REP) 1435 EAP GSS IAKERB 1436 Response 1437 (Empty) -> 1439 EAP GSS IAKERB 1440 Response 1441 (Empty) -> 1442 Access-Accept [4] 1443 <- EAP-Success 1445 <- EAP-Success 1446 AP_REQ -> 1447 <- AP_REP [5] 1449 Notes: 1451 1. IAKERB may be requested by the EAP GSS client without the need for 1452 negotiation, or SPNEGO may be used. 1454 2. The AS_REQ requests a TGT from the KDC. It may or may not include 1455 PADATA. As a result, the AS_REQ may not authenticate the peer to 1456 the KDC, but the AS_REP authenticates the KDC to the peer. 1458 3. The TGS_REQ requests a ticket to the NAS service. The ticket is 1459 encrypted with the NAS's key so that it can only be validated by 1460 the NAS. 1462 4. On receiving a TGS_REP from the KDC rather than a KRB_ERROR, the 1463 RADIUS server can conclude that the peer has successfully 1464 authenticated, and thus that it is appropriate to reply to the NAS 1465 with an Access-Accept encapsulating an EAP-Success. 1467 5. The IAKERB exchange ends before the AP_REQ/AP_REP exchange occurs. 1468 As a result, the AP_REQ/AP_REP exchange either will not occur 1469 (preventing mutual authentication between peer and NAS or transport 1470 of the session key from peer to NAS), will occur out-of-band (e.g. 1471 after access is granted), or will occur in a subsequent EAP GSS 1472 conversation (e.g. using the GSS-API Kerberos V method). 1474 A.2 Kerberos KDC backend 1476 In this topology, there is no RADIUS server, and the NAS functions as an 1477 IAKERB proxy, de-capsulating EAP GSS/IAKERB frames and passing them on 1478 to the KDC. In turn, packets from the KDC are are encapsulated in EAP 1479 GSS/IAKERB frames and sent to the peer by the NAS. Where IAKERB is 1480 used, the NAS functions as an IAKERB proxy, de-capsulating EAP 1481 GSS/IAKERB messages and passing them on to the KDC. In addition, where 1482 the peer already has a valid TGT and ticket to the NAS, it may choose to 1483 use the Kerberos V mechanism within EAP. Note that in the case of 1484 802.11, the Kerberos AP_REQ/AP_REP messages are carried in messages 1485 outside the conventional EAP exchange, such as the EAPOL-Key messages 1486 described in [IEEE8021X] so that use of the Kerberos V mechanism within 1487 EAP is not necessary. 1489 In the Kerberos-only topology, messages from the KDC are encapsulated 1490 within EAP GSS/IAKERB and sent to the peer. In this case, the NAS needs 1491 to understand the EAP GSS, GSS-API IAKERB, as well as GSS-API Kerberos V 1492 mechanisms. 1494 A successful EAP GSS/IAKERB authentication occurring in a topology with 1495 a NAS acting as an IAKERB proxy to a Kerberos KDC will appear as 1496 follows: 1498 Peer NAS KDC 1499 ------ ------------- --------- 1500 EAP/Identity 1501 <-Request 1503 EAP/Identity 1504 Response -> 1506 <-EAP GSS Start 1508 EAP GSS IAKERB 1509 Response [1] 1510 (AS_REQ) -> 1512 AS_REQ -> 1513 <- AS_REP [2] 1515 EAP GSS IAKERB Request 1516 <-AS_REP) 1518 EAP GSS IAKERB 1519 Response [3] 1520 (TGS_REQ) -> 1522 TGS_REQ -> 1524 <- TGS_REP [4] 1526 EAP GSS IAKERB Request 1527 <-(TGS_REP) 1529 EAP GSS IAKERB 1530 Response 1531 (Empty) -> 1533 <- EAP-Success 1534 AP_REQ [5]-> 1535 <- AP_REP [6] 1536 Notes: 1538 1. If PADATA is not used in the AS_REQ, then the peer does not 1539 authenticate to the KDC. 1541 2. The KDC authenticates to the peer in the AS_REP. 1543 3. The peer authenticates to the KDC via the TGS_REQ. 1545 4. The KDC authenticates to the peer via the TGS_REP. The TGS_REP 1546 also provides the peer with a ticket and session-key for use with 1547 the NAS. 1549 5. Up until this point, the peer has not mutually authenticated with 1550 the NAS, or exchanged a key with it. As a result, the peer and NAS 1551 need to conclude an AP_REQ/AP_REP exchange. This can occur in-band 1552 or out-of-band. In the AP-REQ, the peer authenticates to the NAS 1553 and provides it with a session key. 1555 6. The NAS authenticates to the peer using the AP_REP. 1557 Appendix B - The Pseudorandom Function 1559 Given below is the description of the HMAC and pseudorandom function 1560 based on Section 5 of the TLS Protocol Version 1.0 specification 1561 [RFC2246]. 1563 Some of operations in the key derivation require a keyed MIC; this is a 1564 secure digest of some data protected by a secret. Forging the MIC is 1565 infeasible without knowledge of the MIC secret. The construction we use 1566 for this operation is known as HMAC, described in [RFC2104]. 1568 HMAC can be used with a variety of different hash algorithms. We use it 1569 with two different algorithms: MD5 and SHA-1, denoting these as 1570 HMAC_MD5(secret, data) and HMAC_SHA1(secret, data). Additional hash 1571 algorithms can be defined and used to protect record data, but MD5 and 1572 SHA-1 are hard coded into the protocol. 1574 In addition, a construction is required to do expansion of secrets into 1575 blocks of data for the purposes of key generation or validation. This 1576 pseudo-random function (PRF) takes as input a secret, a seed, and an 1577 identifying label and produces an output of arbitrary length. 1579 In order to make the PRF as secure as possible, it uses two hash 1580 algorithms in a way which should guarantee its security if either 1581 algorithm remains secure. 1583 First, we define a data expansion function, P_hash(secret, data) which 1584 uses a single hash function to expand a secret and seed into an 1585 arbitrary quantity of output: 1587 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 1588 HMAC_hash(secret, A(2) + seed) + 1589 HMAC_hash(secret, A(3) + seed) + ... 1591 Where + indicates concatenation. A() is defined as: 1593 A(0) = seed 1594 A(i) = HMAC_hash(secret, A(i-1)) 1596 P_hash can be iterated as many times as is necessary to produce the 1597 required quantity of data. For example, if P_SHA-1 was being used to 1598 create 64 bytes of data, it would have to be iterated 4 times (through 1599 A(4)), creating 80 bytes of output data; the last 16 bytes of the final 1600 iteration would then be discarded, leaving 64 bytes of output data. 1602 The PRF is created by splitting the secret into two halves and using one 1603 half to generate data with P_MD5 and the other half to generate data 1604 with P_SHA-1, then exclusive-or'ing the outputs of these two expansion 1605 functions together. 1607 S1 and S2 are the two halves of the secret and each is the same length. 1608 S1 is taken from the first half of the secret, S2 from the second half. 1609 Their length is created by rounding up the length of the overall secret 1610 divided by two; thus, if the original secret is an odd number of bytes 1611 long, the last byte of S1 will be the same as the first byte of S2. 1613 L_S = length in bytes of secret; 1614 L_S1 = L_S2 = ceil(L_S / 2); 1616 The secret is partitioned into two halves (with the possibility of one 1617 shared byte) as described above, S1 taking the first L_S1 bytes and S2 1618 the last L_S2 bytes. 1620 The PRF is then defined as the result of mixing the two pseudorandom 1621 streams by exclusive-or'ing them together. 1623 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR 1624 P_SHA-1(S2, label + seed); 1626 The label is an ASCII string. It should be included in the exact form it 1627 is given without a length byte or trailing null character. For example, 1628 the label "slithy toves" would be processed by hashing the following 1629 bytes: 1631 73 6C 69 74 68 79 20 74 6F 76 65 73 1633 Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 1634 byte outputs, the boundaries of their internal iterations will not be 1635 aligned; to generate a 80 byte output will involve P_MD5 being iterated 1636 through A(5), while P_SHA-1 will only iterate through A(4). 1638 Intellectual Property Statement 1640 The IETF takes no position regarding the validity or scope of any 1641 intellectual property or other rights that might be claimed to pertain 1642 to the implementation or use of the technology described in this 1643 document or the extent to which any license under such rights might or 1644 might not be available; neither does it represent that it has made any 1645 effort to identify any such rights. Information on the IETF's 1646 procedures with respect to rights in standards-track and standards- 1647 related documentation can be found in BCP-11. Copies of claims of 1648 rights made available for publication and any assurances of licenses to 1649 be made available, or the result of an attempt made to obtain a general 1650 license or permission for the use of such proprietary rights by 1651 implementors or users of this specification can be obtained from the 1652 IETF Secretariat. 1654 The IETF invites any interested party to bring to its attention any 1655 copyrights, patents or patent applications, or other proprietary rights 1656 which may cover technology that may be required to practice this 1657 standard. Please address the information to the IETF Executive 1658 Director. 1660 Full Copyright Statement 1662 Copyright (C) The Internet Society (2002). All Rights Reserved. 1663 This document and translations of it may be copied and furnished to 1664 others, and derivative works that comment on or otherwise explain it or 1665 assist in its implementation may be prepared, copied, published and 1666 distributed, in whole or in part, without restriction of any kind, 1667 provided that the above copyright notice and this paragraph are included 1668 on all such copies and derivative works. However, this document itself 1669 may not be modified in any way, such as by removing the copyright notice 1670 or references to the Internet Society or other Internet organizations, 1671 except as needed for the purpose of developing Internet standards in 1672 which case the procedures for copyrights defined in the Internet 1673 Standards process must be followed, or as required to translate it into 1674 languages other than English. The limited permissions granted above are 1675 perpetual and will not be revoked by the Internet Society or its 1676 successors or assigns. This document and the information contained 1677 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1678 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1679 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1682 Expiration Date 1684 This memo is filed as , and expires 1685 August 23, 2002.