idnits 2.17.1 draft-aboba-pppext-eapgss-08.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 35 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 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 637 has weird spacing: '...fy that the c...' == Line 638 has weird spacing: '... by the peer....' == Line 754 has weird spacing: '...tor) is obtai...' == Line 1023 has weird spacing: '...he peer has a...' == Line 1414 has weird spacing: '...Given below i...' == (2 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 (23 October 2001) is 8221 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 810, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 813, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 828, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 831, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 834, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 840, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 858, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 863, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 869, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 873, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 880, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 896, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 898, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 912, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 916, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 923, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 928, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 931, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 953, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 957, but no explicit reference was found in the text == Unused Reference: '47' is defined on line 960, but no explicit reference was found in the text == Unused Reference: '48' is defined on line 963, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '5') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2716 (ref. '12') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2222 (ref. '14') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 1510 (ref. '16') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-09) exists of draft-ietf-cat-iakerb-08 ** Obsolete normative reference: RFC 2478 (ref. '19') (Obsoleted by RFC 4178) == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-13 ** Obsolete normative reference: RFC 2246 (ref. '49') (Obsoleted by RFC 4346) Summary: 11 errors (**), 0 flaws (~~), 35 warnings (==), 2 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 23 October 2001 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 RFC2026. 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 (2001). 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, Kerberos, One Time Passwords, and others. EAP 40 typically runs directly over the link layer without requiring IP and 41 therefore includes its own support for in-order delivery and re- 42 transmission. While EAP was originally developed for use with PPP, it is 43 also now in use with IEEE 802. The encapsulation of EAP on IEEE 802 44 links is described within IEEE 802.1X. 46 This document describes the EAP GSS protocol, which supports 47 fragmentation and reassembly, and enables the use of GSS-API mechanisms 48 within EAP. As a result, any GSS-API mechanism providing initial 49 authentication can be used with EAP GSS, including IAKERB. Supporting 50 GSS-API authentication methods within EAP is desirable because this 51 enables developers creating GSS-API authentication methods to leverage 52 their development efforts. Since the EAP Type field is a finite (one 53 octet) resource, EAP GSS allows GSS-API methods to automatically be 54 supported within EAP without having to consume an EAP Type for each GSS- 55 API method. 57 Table of Contents 59 1. Introduction .......................................... 3 60 1.1 Requirements language ........................... 3 61 1.2 Terminology ..................................... 3 62 2. Protocol overview ...................... .............. 4 63 2.1 EAP server as GSS-API initiator ................. 4 64 2.2 Peer as GSS-API initiator ....................... 5 65 3. Detailed description of EAP GSS protocol .............. 8 66 3.1 EAP GSS packet format ........................... 8 67 3.2 EAP GSS Request packet .......................... 9 68 3.3 EAP GSS Response packet ......................... 10 69 3.4 Fragmentation ....... ........................... 11 70 3.5 Retry behavior .................................. 14 71 3.6 Identity verification ........................... 14 72 3.7 Use of addresses ................................ 15 73 4. Key management ........................................ 15 74 4.1 Key derivation algorithm ........................ 16 75 4.2 Deriving session keys ........................... 17 76 5. References ............................................ 18 77 6. Security considerations ............................... 22 78 6.1 Dictionary attacks .............................. 22 79 6.2 Certificate revocation ......................... 22 80 6.3 Mutual authentication ........................... 23 81 6.4 Credential reuse ................................ 23 82 6.5 Key transmission issues ......................... 24 83 6.6 Link layer ciphersuite negotiation .............. 25 84 7. IANA Considerations ................................... 26 85 Appendix A - Example IAKERB topologies ....................... 27 86 A.1 RADIUS+KDC backend .............................. 28 87 A.2 Kerberos KDC backend ............................ 30 88 Appendix B - The Pseudorandom Function ....................... 32 89 Acknowledgments .............................................. 34 90 Author's Addresses ........................................... 34 91 Intellectual Property Statement .............................. 34 92 Full Copyright Statement ..................................... 35 93 1. Introduction 95 The Extensible Authentication Protocol (EAP) [5] provides a standard 96 mechanism for support of multiple authentication methods, including 97 public key [12], smart cards, Kerberos, One Time Passwords [5], and 98 others. EAP typically runs directly over the link layer without 99 requiring IP and therefore includes its own support for in-order 100 delivery and re-transmission. While EAP was originally developed for use 101 with PPP [1], it is also now in use with IEEE 802 [21]. The 102 encapsulation of EAP on IEEE 802 links is described within IEEE 802.1X 103 [27]. 105 This document describes the EAP GSS protocol, which supports 106 fragmentation and reassembly, and enables the use of GSS-API mechanisms 107 within EAP. As a result, any GSS-API mechanism providing initial 108 authentication can be used with EAP GSS, including IAKERB [18]. 109 Supporting GSS-API authentication methods within EAP is desirable 110 because this enables developers creating GSS-API authentication methods 111 to leverage their development efforts. Since the EAP Type field is a 112 finite (one octet) resource, EAP GSS allows GSS-API methods to 113 automatically be supported within EAP without having to consume an EAP 114 Type for each GSS-API method. 116 1.1. Requirements language 118 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 119 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 120 described in [11]. 122 1.2. Terminology 124 This document frequently uses the following terms: 126 Authentication Server 127 An Authentication Server is an entity that provides an 128 Authentication Service to an NAS. This service verifies from 129 the credentials provided by the peer, the claim of identity 130 made by the peer. 132 Master key 133 The session key derived between the EAP client and EAP server 134 during the EAP authentication process. 136 Master session key 137 The keys derived from the master key that are subsequently 138 used in generation of the transient session keys for 139 authentication, encryption, and IV-generation. So that the 140 master session keys are to be usable with any ciphersuite, 141 they are longer than is necessary, and are truncated to fit. 143 NAS The end of the link requiring the authentication. In IEEE 144 802.1X, this end is known as the Authenticator. 146 Peer The other end of the point-to-point link (PPP), point-to-point 147 LAN segment (IEEE 802.1X) or 802.11 wireless link, which being 148 authenticated by the NAS. In IEEE 802.1X, this end is known as 149 the Supplicant. 151 Transient session keys 152 The chosen ciphersuites uses transient session keys for 153 authentication and encryption as well as IVs (if required). 154 The transient session keys are derived from the master session 155 keys, and are of the appropriate size for use with the chosen 156 ciphersuite. 158 2. Protocol overview 160 As described in [5], the EAP GSS conversation will typically begin with 161 the NAS and the peer negotiating EAP. The NAS will then typically send 162 an EAP-Request/Identity packet to the peer, and the peer will respond 163 with an EAP-Response/Identity packet to the NAS, containing the peer's 164 user-Id. 166 Once having received the peer's Identity, the EAP server responds with 167 an EAP-Request packet of EAP-Type=EAP GSS. From this point forward, the 168 EAP GSS conversation may proceed in one of two way. 170 In the first mode, the EAP server acts as the GSS-API initiator, and the 171 peer acts as the GSS-API target. In the second mode, which adds an 172 extra round-trip, the peer acts as the GSS-API initiator, and the EAP 173 server acts as the GSS-API target. We discuss each mode in turn. 175 2.1. EAP server as GSS-API initiator 177 As described in RFC 2284 [5], the EAP server typically authenticates the 178 peer using a prearranged method or set of methods. As a result, the EAP 179 server may have predetermined the use of EAP GSS as well as the GSS-API 180 method to be used. If that GSS-API method can be initiated by the EAP 181 Server, then the EAP server MAY act as a GSS-API initiator with the peer 182 acting as a GSS-API target. In this case, the EAP Server will indicate 183 the pre-determined GSS-API method, possibly via SPNEGO, but SHOULD NOT 184 allow negotiation of a substitute GSS-API method. 186 To initiate the conversation, the EAP-Server sends an EAP-Request packet 187 with EAP-Type=EAP GSS. The data field of the packet will encapsulate a 188 GSS-API token, created as a result of a call to GSS_Init_sec_context (). 190 In this case mutual authentication MUST be requested (otherwise the peer 191 would not be authenticated to the NAS!) so that the the mutual_req_flag 192 is set and the call to GSS_Init_sec-context() returns 193 GSS_S_CONTINUE_NEEDED status. 195 When it receives the EAP-Request, the peer will de-capsulate the 196 received GSS-API token within the EAP GSS frame, and will pass it as the 197 input_token parameter to GSS_Accept_sec_context(). If 198 GSS_Accept_sec_context indicates GSS_S_COMPLETE status, then the NAS has 199 been authenticated by the peer, and the NAS's indicated identity is 200 provided in the src_name result, along with an output_token to be 201 encapsulated within an EAP-Response packet with EAP-Type=EAP GSS, and 202 passed back to the EAP-Server. 204 The EAP server will then de-capsulate the GSS-API token within the EAP- 205 Response message and pass it as the input_token parameter to 206 GSS_Init_sec_context(). If the call returns GSS_S_COMPLETE status, then 207 the peer has been authenticated to the EAP-Server, then the EAP-Server 208 responds with an EAP-Success message. If GSS_S_CONTINUE_NEEDED status 209 is returned, then the EAP Server encapsulates the returned output_token 210 with an EAP-Request packet of EAP-Type=EAP GSS, and pass this back to 211 the peer. 213 The conversation (which can be completed in a minimum of 2.5 round 214 trips), appears as follows: 216 Peer NAS 217 ------ ------------- 218 EAP/Identity 219 <-------Request 221 EAP/Identity 222 Response --------> 224 GSS_Init_sec_context(mutual_req_flag) 225 returns GSS_S_CONTINUE_NEEDED, 226 output_token 228 <--------EAP Request 229 EAP Type=EAP GSS 230 output_token 232 GSS_Accept_sec_context(input_token) 233 returns GSS_S_COMPLETE, 234 output_token 236 EAP Response --------> 237 EAP Type=EAP GSS 238 output_token 240 GSS_Init_sec_context(input_token) 241 returns GSS_S_COMPLETE 243 <--------EAP Success 245 2.2. Peer as GSS-API initiator 247 If the EAP server is prepared to allow negotiation of the GSS-API method 248 via SPNEGO [19], or if the EAP server knows the GSS-API method to be 249 used, but cannot initiate it (e.g. IAKERB, or Kerberos V), then the peer 250 MUST act as a GSS-API initiator, with the EAP server acting as the GSS- 251 API target. 253 In this case, the EAP server MUST respond with an EAP GSS/Start packet, 254 which is an EAP-Request packet with EAP-Type=EAP GSS, the Start (S) bit 255 set, and no data. The peer then calls GSS_Init_sec_context(), typically 256 with mutual authentication requested so that the mutual_req_flag is set 257 and the call returns GSS_S_CONTINUE_NEEDED status. The output_token is 258 then encapsulated within an EAP-Response packet with EAP-Type=EAP GSS 259 and sent to the NAS. If method negotiation is to be used, then an 260 initial negotiation token for the Simple and Protected GSS-API 261 Negotiation Mechanism (SPNEGO) [19] is transferred. This contains an 262 ordered list of mechanisms, a set of options that should be supported by 263 the selected mechanism and the initial security token for the mechanism 264 preferred by the peer. The inclusion of the initial security token for 265 the preferred method saves a round-trip, assuming that the NAS agrees to 266 the preferred mechanism. 268 The EAP server then de-capsulates the GSS-API token contained within the 269 EAP-Response of EAP-Type=EAP GSS and uses this as the input_token 270 parameter to a call to GSS_Accept_sec_context(). The output_token 271 parameter will then contain a token, containing the result of the 272 negotiation and in the case of accept, the agreed security mechanism and 273 the response to the initial security token as described in [19]. This 274 token is then encapsulated within an EAP-Request packet of EAP-Type=GSS- 275 API, which is sent to the peer. This occurs whether the call completed 276 with GSS_S_CONTINUE_NEEDED status or GSS_S_COMPLETE status. 278 The peer then de-capsulates the GSS-API token contained within the EAP- 279 Request packet with EAP-Type=EAP GSS, and passes the input_token 280 parameter to GSS_Init_sec_context(). The output_token is encapsulated 281 within an EAP-Response packet with EAP-Type=EAP GSS and sent to the EAP 282 server. This occurs whether the call completed with 283 GSS_S_CONTINUE_NEEDED status or GSS_S_COMPLETE status. 285 If the previous call to GSS_Accept_sec_context() returned GSS_S_COMPLETE 286 status, then the EAP-Server returns an EAP-Success message to the 287 client. Otherwise, it de-capsulates the GSS-API token contained within 288 the EAP-Request packet, and the conversation continues. 290 The conversation (which can be completed in a minimum of 3.5 round 291 trips), appears as follows: 293 Authenticating Peer NAS 294 ------------------- ------------- 295 EAP-Request/ 296 <- Identity 297 EAP-Response/ 298 Identity (MyID) -> 299 EAP-Request/ 300 EAP-Type=EAP GSS 301 <- (GSS Start, S bit set) 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 output_token -> 310 GSS_Accept_sec_context(input_token) 311 returns GSS_S_COMPLETE, 312 output_token (SPNEGO) 314 EAP-Request/ 315 EAP-Type=EAP GSS 316 <- output_token 318 GSS_Init_sec_context(input_token) 319 returns GSS_S_COMPLETE, 320 output_token 322 EAP-Response/ 323 EAP-Type=EAP GSS 324 output_token -> 325 <- EAP-Success 327 3. Detailed description of the EAP GSS protocol 329 3.1. EAP GSS Packet Format 331 A summary of the EAP GSS Request/Response packet format is shown below. 332 The fields are transmitted from left to right. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Code | Identifier | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Data... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Code 344 1 - Request 345 2 - Response 347 Identifier 349 The identifier field is one octet and aids in matching responses with 350 requests. 352 Length 354 The Length field is two octets and indicates the length of the EAP 355 packet including the Code, Identifier, Length, Type, and Data fields. 356 Octets outside the range of the Length field should be treated as 357 Data Link Layer padding and should be ignored on reception. 359 Type 361 TBD - EAP GSS 363 Data 365 The format of the Data field is determined by the Code field. 367 3.2. EAP GSS Request Packet 369 A summary of the EAP GSS Request packet format is shown below. The 370 fields are transmitted from left to right. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Code | Identifier | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Flags | GSS Message Length 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | GSS Message Length | GSS Data... 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Code 384 1 386 Identifier 388 The Identifier field is one octet and aids in matching responses with 389 requests. The Identifier field MUST be changed on each Request 390 packet. 392 Length 394 The Length field is two octets and indicates the length of the EAP 395 packet including the Code, Identifier, Length, Type, and GSS Response 396 fields. 398 Type 400 TBD - EAP GSS 402 Flags 404 0 1 2 3 4 5 6 7 8 405 +-+-+-+-+-+-+-+-+ 406 |L M S R R R R R| 407 +-+-+-+-+-+-+-+-+ 409 L = Length included 410 M = More fragments 411 S = EAP GSS start 412 R = Reserved 414 The L bit (length included) is set to indicate the presence of the 415 four octet GSS Message Length field, and MUST be set for the first 416 fragment of a fragmented GSS message or set of messages. The M bit 417 (more fragments) is set on all but the last fragment. The S bit (EAP 418 GSS start) is set in an EAP GSS Start message. This differentiates 419 the EAP GSS Start message from a fragment acknowledgment. 421 GSS Message Length 423 The GSS Message Length field is four octets, and is present only if 424 the L bit is set. This field provides the total length of the GSS 425 message or set of messages that is being fragmented. 427 GSS data 429 The GSS data consists of the encapsulated GSS packet. 431 3.3. EAP GSS Response Packet 433 A summary of the EAP GSS Response packet format is shown below. The 434 fields are transmitted from left to right. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Code | Identifier | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Flags | GSS Message Length 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | GSS Message Length | GSS Data... 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Code 448 2 450 Identifier 452 The Identifier field is one octet and MUST match the Identifier field 453 from the corresponding request. 455 Length 457 The Length field is two octets and indicates the length of the EAP 458 packet including the Code, Identifier, Length, Type, and GSS data 459 fields. 461 Type 463 TBD - EAP GSS 465 Flags 467 0 1 2 3 4 5 6 7 8 468 +-+-+-+-+-+-+-+-+ 469 |L M S R R R R R| 470 +-+-+-+-+-+-+-+-+ 472 L = Length included 473 M = More fragments 474 S = EAP GSS start 475 R = Reserved 477 The L bit (length included) is set to indicate the presence of the 478 four octet GSS Message Length field, and MUST be set for the first 479 fragment of a fragmented GSS message or set of messages. The M bit 480 (more fragments) is set on all but the last fragment. The S bit (EAP 481 GSS start) is set in an EAP GSS Start message. This differentiates 482 the EAP GSS Start message from a fragment acknowledgment. 484 GSS Message Length 486 The GSS Message Length field is four octets, and is present only if 487 the L bit is set. This field provides the total length of the GSS 488 message or set of messages that is being fragmented. 490 GSS data 492 The GSS data consists of the encapsulated GSS packet. 494 3.4. Fragmentation 496 It is possible that EAP GSS messages may exceed the link MTU size, the 497 maximum RADIUS packet size of 4096 octets, or even the PPP Multilink 498 Maximum Received Reconstructed Unit (MRRU). As described in [2], within 499 PPP the multi-link MRRU is negotiated via the Multilink MRRU LCP option, 500 which includes an MRRU length field of two octets, and thus can support 501 MRRUs as large as 64 KB. 503 In order to protect against reassembly lockup and denial of service 504 attacks, it may be desirable for an implementation to set a maximum size 505 for a GSS-API token. Since a typical certificate chain is rarely longer 506 than a few thousand octets, and no other field is likely to be anywhere 507 near as long, a reasonable choice of maximum acceptable message length 508 might be 64 KB. 510 If this value is chosen, then for PPP links, fragmentation can be 511 handled via the multi-link PPP fragmentation mechanisms described in 512 [2]. While this is desirable, there may be cases in which multi-link or 513 the MRRU LCP option cannot be negotiated. Also, since EAP methods must 514 also be usable within IEEE 802.1X [27], an EAP GSS implementation MUST 515 provide its own support for fragmentation and reassembly. 517 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 518 added in a simple manner. In EAP, fragments that are lost or damaged in 519 transit will be retransmitted, and since sequencing information is 520 provided by the Identifier field in EAP, there is no need for a fragment 521 offset field as is provided in IP. 523 EAP GSS fragmentation support is provided through addition of a flags 524 octet within the EAP-Response and EAP-Request packets, as well as a GSS 525 Message Length field of four octets. Flags include the Length included 526 (L), More fragments (M), and EAP GSS Start (S) bits. The L flag is set 527 to indicate the presence of the four octet GSS Message Length field, and 528 MUST be set for the first fragment of a fragmented GSS message or set of 529 messages. The M flag is set on all but the last fragment. The S flag is 530 set only within the EAP GSS start message sent from the EAP server to 531 the peer. The GSS Message Length field is four octets, and provides the 532 total length of the GSS-API token or set of messages that is being 533 fragmented; this simplifies buffer allocation. 535 When an EAP GSS peer receives an EAP-Request packet with the M bit set, 536 it MUST respond with an EAP-Response with EAP-Type=EAP GSS and no data. 537 This serves as a fragment ACK. The EAP server MUST wait until it 538 receives the EAP-Response before sending another fragment. In order to 539 prevent errors in processing of fragments, the EAP server MUST increment 540 the Identifier field for each fragment contained within an EAP-Request, 541 and the peer MUST include this Identifier value in the fragment ACK 542 contained within the EAP-Response. Retransmitted fragments will contain 543 the same Identifier value. 545 Similarly, when the EAP server receives an EAP-Response with the M bit 546 set, it MUST respond with an EAP-Request with EAP-Type=EAP GSS and no 547 data. This serves as a fragment ACK. The EAP peer MUST wait until it 548 receives the EAP-Request before sending another fragment. In order to 549 prevent errors in the processing of fragments, the EAP server MUST use 550 increment the Identifier value for each fragment ACK contained within an 551 EAP-Request, and the peer MUST include this Identifier value in the 552 subsequent fragment contained within an EAP-Response. 554 In the case where the EAP GSS authentication is successful, and 555 fragmentation is required, the conversation will appear as follows: 557 Authenticating Peer NAS 558 ------------------- ------------- 559 EAP-Request/ 560 <- Identity 561 EAP-Response/ 562 Identity (MyID) -> 563 EAP-Request/ 564 EAP-Type=EAP GSS 565 <-(GSS Start, S bit set) 567 GSS_Init_sec_context(mutual_req_flag) 568 returns GSS_S_CONTINUE_NEEDED, 569 output_token (SPNEGO) 571 EAP-Response/ 572 EAP-Type=EAP GSS 573 output_token -> 575 GSS_Accept_sec_context(input_token) 576 returns GSS_S_COMPLETE, 577 output_token (SPNEGO) 579 EAP-Request/ 580 EAP-Type=EAP GSS 581 output_token 582 <- (Fragment 1: L, M bits set) 583 EAP-Response/ 584 EAP-Type=EAP GSS -> 585 EAP-Request/ 586 EAP-Type=EAP GSS 587 <- (Fragment 2: M bit set) 588 EAP-Response/ 589 EAP-Type=EAP GSS -> 590 EAP-Request/ 591 EAP-Type=EAP GSS 593 <- (Fragment 3) 595 GSS_Init_sec_context(input_token) 596 returns GSS_S_COMPLETE, 597 output_token 599 EAP-Response/ 600 EAP-Type=EAP GSS 601 output_token 602 (Fragment 1: 603 L, M bits set)-> 604 EAP-Request/ 605 <- EAP-Type=EAP GSS 606 EAP-Response/ 607 EAP-Type=EAP GSS 608 (Fragment 2)-> 609 <- EAP-Success 611 3.5. Retry behavior 613 As with other EAP protocols, the EAP server is responsible for retry 614 behavior. This means that if the EAP server does not receive a reply 615 from the peer, it MUST resend the EAP-Request for which it has not yet 616 received an EAP-Response. However, the peer MUST NOT resend EAP-Response 617 packets without first being prompted by the EAP server. 619 For example, if the initial EAP GSS start packet sent by the EAP server 620 were to be lost, then the peer would not receive this packet, and would 621 not respond to it. As a result, the EAP GSS start packet would be resent 622 by the EAP server. Once the peer received the EAP GSS start packet, it 623 would send an EAP-Response encapsulating the client_hello message. If 624 the EAP-Response were to be lost, then the EAP server would resend the 625 initial EAP GSS start, and the peer would resend the EAP-Response. 627 As a result, it is possible that a peer will receive duplicate EAP- 628 Request messages, and may send duplicate EAP-Responses. Both the peer 629 and the EAP-Server should be engineered to handle this possibility. 631 3.6. Identity verification 633 As part of the GSS-API conversation, it is possible that the server may 634 present a certificate to the peer, or that the peer may present a 635 certificate to the EAP server. If the peer has made a claim of identity 636 in the EAP-Response/Identity (MyID) packet, the EAP server SHOULD 637 verify that the claimed identity corresponds to the certificate 638 presented by the peer. Typically this will be accomplished either by 639 placing the userId within the peer certificate, or by providing a 640 mapping between the peer certificate and the userId using a directory 641 service. 643 Similarly, the peer MUST verify the validity of the EAP server 644 certificate, and SHOULD also examine the EAP server name presented in 645 the certificate, in order to determine whether the EAP server can be 646 trusted. Please note that in the case where the EAP authentication is 647 remoted that the EAP server will not reside on the same machine as the 648 NAS, and therefore the name in the EAP server's certificate cannot be 649 expected to match that of the intended destination. In this case, a more 650 appropriate test might be whether the EAP server's certificate is signed 651 by a CA controlling the intended destination and whether the EAP server 652 exists within a target sub-domain. 654 3.7. Use of addresses 656 When using EAP GSS, the EAP client may not be able to include an address 657 in an EAP-Response message, since prior to obtaining access the EAP 658 client may not have an IP address. This limits effective use of EAP GSS 659 to GSS-API methods that do not require the peer to have an IP address 660 prior to authentication. 662 The IAKERB GSS-API method can explicitly handle this situation, as 663 described in [18]. However, where the Kerberos V protocol, described in 664 [16], is negotiated as a GSS-API method as described in [20], the 665 addresses field of the AS_REQ and TGS_REQ SHOULD be blank and the caddr 666 field of the ticket SHOULD also be left blank. 668 4. Key management 670 As a result of the EAP GSS conversation, the EAP endpoints will mutually 671 authenticate and derive a session key, which is known as the "master 672 key" in this specification. Ultimately, the master key is used to 673 produce the session keys for a growing number of ciphersuites. 675 In the most general case, authentication and encryption keys as well as 676 initialization vectors are required in each direction. Depending on the 677 negotiated ciphersuite, not all of these session keys may be used. 678 Within PPP, ciphersuites include DESEbis [9], 3DES [10], and MPPE [42]. 679 For PPP DESEbis, a 56-bit encryption key is required in each direction; 680 for PPP 3DES, a 168-bit encryption key is needed in each direction; for 681 MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in each 682 direction, as described in [42],[43]. While these PPP ciphersuites 683 provide encryption, they do not provide a per-frame keyed message 684 integrity check (MIC). 686 Within 802.11, ciphersuites include WEP-40, described in [28], which 687 requires a 40-bit encryption key, the same in either direction; and 688 WEP-128, which requires a 104-bit encryption key, the same in either 689 direction. These ciphersuites also do not include a keyed MIC. 690 Recently, new ciphersuites have been proposed for use with 802.11 that 691 do provide per-frame authentication as well as encryption. These 692 methods, described in [44], require 128-bit authentication and 693 encryption keys in each direction, and are based on AES [45]-[48]. 695 With the increase in the number of link layer ciphersuites, it is 696 undesirable for an EAP method to include ciphersuite-specific mechanisms 697 for session key derivation. This would require the specification to be 698 revised for operation with each new ciphersuite. 700 In fact, an EAP method may not even know the selected ciphersuite. For 701 example, in PPP, negotiation of the ciphersuite is accomplished via ECP, 702 which occurs after authentication. As a result, during authentication, 703 the client, NAS and backend authentication server may not be able to 704 anticipate the negotiated ciphersuite. 706 As a result, it is best for an EAP method to provide master session keys 707 that can be used with any ciphersuite, and allow the NAS and EAP client 708 to derive ciphersuite-specific session keys from those master keys, once 709 the ciphersuite is known. 711 4.1. Key derivation algorithm 713 EAP TLS, described in RFC 2716 [12], provides a mechanism for deriving 714 authentication and encryption keys as well as IVs in both directions 715 from the TLS master key. Since EAP TLS cannot assume knowledge of the 716 negotiated ciphersuite, it provides master session keys large enough for 717 use with any ciphersuite, assuming that they will be suitably truncated 718 by the client and NAS, once the ciphersuite is known. This technique is 719 therefore compatible with PPP and 802.11 ciphersuites, including both 720 stream and block ciphers. It is applicable to ciphersuites that provide 721 authentication only, encryption and authentication, or encryption only. 723 This specification reuses the RFC 2716 [12] key derivation technique, 724 with one major modification. In EAP TLS, the TLS master key is 725 typically not available via an API for security reasons, and as a 726 result, EAP TLS utilizes the TLS PRF in the master session key 727 derivation. For similar reasons, EAP GSS implementations will typically 728 not be able to obtain access to the master key via GSS-API. However, 729 while GSS-API methods can call GSS_Wrap() to encrypt and GSS_GetMIC() to 730 generate authentication tokens based on the master key, they cannot 731 utilize the TLS PRF operating directly on the master key, since this is 732 not obtainable. As a result, an intermediate step is required to 733 generate a "Pseudo-Master Key". 735 In the techniques described here, master session keys are derived from 736 the master key derived by the GSS-API method, but are never used to 737 encrypt or decrypt data; they are only used in the derivation of 738 transient session keys. 740 The derivation proceeds as follows: 742 [1] The "Pseudo-Master Key" K' is given by K' = 743 Extract_MIC(GSS_GetMIC("EAP GSS pseudo master key")). Here 744 Extract_MIC() is a function that extracts the MIC portion of the 745 authentication token returned by GSS_GetMIC(). 747 [2] Given the K' value and the pseudorandom function (PRF) defined in 748 Appendix B, the value PRF1 = PRF(K', "client EAP encryption", 749 random) is computed up to 128 bytes, and the PRF2 = PRF("","client 750 EAP encryption", random) is computed up to 64 bytes (where "" is an 751 empty string). 753 [3] The peer encryption key (the one used for encrypting data from peer 754 to authenticator) is obtained by truncating to the correct length 755 the first 32 bytes of PRF1. The authenticator encryption key (the 756 one used for encrypting data from authenticator to peer), if 757 different from the client encryption key, is obtained by truncating 758 to the correct length the second 32 bytes of PRF1. The peer 759 authentication key (the one used for computing MICs for messages 760 from peer to authenticator), if used, is obtained by truncating to 761 the correct length the third 32 bytes of PRF1. The authenticator 762 authentication key (the one used for computing MICs for messages 763 from authenticator to peer), if used, and if different from the 764 peer authentication key, is obtained by truncating to the correct 765 length the fourth 32 bytes of PRF1. The peer initialization vector 766 (IV), used for messages from peer to authenticator if a block 767 cipher has been specified, is obtained by truncating to the 768 cipher's block size the first 32 bytes of PRF2. Finally, the 769 authenticator initialization vector (IV), used for messages from 770 peer to authenticator if a block cipher has been specified, is 771 obtained by truncating to the cipher's block size the second 32 772 bytes of PRF2. 774 The use of these encryption and authentication keys is specific to the 775 ciphersuite used. Additional keys or other non-secret values (such as 776 IVs) can be obtained as needed for future ciphersuites by extending the 777 outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 779 4.2. Deriving session keys 781 The Master Send and Receive keys (Peer-to-Authenticator and 782 Authenticator-to-Peer encryption keys from the Peer's perspective and 783 Authenticator-to-Peer and Peer-to authenticator from the Authenticator's 784 perspective) are derived from the master key as described in the 785 previous section. 40 , 56, 104 and 128-bit keys are derived using the 786 same algorithm defined for EAP TLS session keys in [12]. The only 787 difference is in the length of the keys and their effective strength: 56 788 and 40-bit keys are 8 octets in length, while 104 and 128-bit keys are 789 16 octets long. Separate keys are derived for the send and receive 790 directions of the session. 792 5. References 794 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 795 RFC 1661, July 1994. 797 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 798 "The PPP Multilink Protocol (MP)." RFC 1990, August 1996. 800 [3] Simpson, W., Editor, "PPP LCP Extensions." RFC 1570, January 1994. 802 [4] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 803 1321, April 1992. 805 [5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 806 (EAP)", RFC 2284, March 1998. 808 [6] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, June 1996 810 [7] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 811 25, 1999. 813 [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 814 (December 1980). 816 [9] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 817 (DESE-bis)", RFC 2419, September 1998. 819 [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 820 2420, September 1998. 822 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 823 Levels", BCP 14, RFC 2119, March 1997. 825 [12] Aboba, B., Simon, S.,"PPP EAP TLS Authentication Protocol", RFC 826 2716, October 1999. 828 [13] D. Rand. "The PPP Compression Control Protocol." RFC 1962, Novell, 829 June 1996. 831 [14] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 832 2222, October 1997. 834 [15] Linn, J., "Generic Security Service Application Program Interface, 835 Version 2", RFC 2743, January 2000. 837 [16] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 838 (V5)", RFC 1510, September 1993. 840 [17] Neuman, B. C., Ts'o, T., "Kerberos: An Authentication Service for 841 Computer Networks", IEEE Communications, 32(9):33-38, September 842 1994. 844 [18] Swift, M., Trostle, J., Aboba, B., Zorn, G., "Initial 845 Authentication and Pass Through Authentication Using Kerberos V5 846 and the GSS-API (IAKERB)", Internet draft (work in progress), 847 draft-ietf-cat-iakerb-08.txt, August 2001. 849 [19] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 850 Negotiation Mechanism", RFC 2478, December 1998. 852 [20] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 853 June 1996. 855 [21] IEEE Standards for Local and Metropolitan Area Networks: Overview 856 and Architecture, ANSI/IEEE Std 802, 1990. 858 [22] ISO/IEC 10038 Information technology - Telecommunications and 859 information exchange between systems - Local area networks - Media 860 Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D- 1993), 861 1993. 863 [23] ISO/IEC Final CD 15802-3 Information technology - Tele- 864 communications and information exchange between systems - Local and 865 metropolitan area networks - Common specifications - Part 3:Media 866 Access Control (MAC) bridges, (current draft available as IEEE 867 P802.1D/D15). 869 [24] IEEE Standards for Local and Metropolitan Area Networks: Draft 870 Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, 871 January 1998. 873 [25] ISO/IEC 8802-3 Information technology - Telecommunications and 874 information exchange between systems - Local and metropolitan area 875 networks - Common specifications - Part 3: Carrier Sense Multiple 876 Access with Collision Detection (CSMA/CD) Access Method and 877 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 878 1996. 880 [26] IEEE Standards for Local and Metropolitan Area Networks: Demand 881 Priority Access Method, Physical Layer and Repeater Specification 882 For 100 Mb/s Operation, IEEE Std 802.12-1995. 884 [27] IEEE Standards for Local and Metropolitan Area Networks: Port based 885 Network Access Control, IEEE Std 802.1X-2001, June 2001. 887 [28] Information technology - Telecommunications and information 888 exchange between systems - Local and metropolitan area networks - 889 Specific Requirements Part 11: Wireless LAN Medium Access Control 890 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 891 802.11-1997, 1997. 893 [29] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 894 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 896 [30] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 898 [31] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting Modifications 899 for Tunnel Protocol Support", RFC 2867, June 2000. 901 [32] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 902 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", RFC 903 2868, June 2000. 905 [33] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 906 2869, June 2000. 908 [34] Wu, T., "A Real-World Analysis of Kerberos Password Security", 909 Stanford University Computer Science Department, 910 http://theory.stanford.edu/~tjw/krbpass.html 912 [35] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 913 authentication system", Proceedings of the 1991 Winter USENIX 914 Conference, pp. 253-267, 1991. 916 [36] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: Kerberos 4 917 session keys", Proceedings of the Internet Society Network and 918 Distributed System Security Symposium, pp. 60-70, March 1997. 920 [37] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, 921 September 2000. 923 [38] Bellovin, S.M., Merritt, M., "Encrypted key exchange: Password- 924 based protocols secure against dictionary attacks", Proceedings of 925 the 1992 IEEE Computer Society Conference on Research in Security 926 and Privacy, pp. 72-84, 1992. 928 [39] Jablon, D., "Strong password-only authenticated key exchange", 929 Computer Communication Review, 26(5):5-26, October 1996. 931 [40] Jaspan, B., "Dual-workfactor encrypted key exchange: Efficiently 932 preventing password chaining and dictionary attacks", Proceedings 933 of the Sixth Annual USENIX Security Conference, pp. 43-50, July 934 1996. 936 [41] Tung, B. Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 937 J., Trostle, J., "Public Key Cryptography for Initial 938 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 939 init-13.txt, August 2001. 941 [42] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) 942 RFC 3078, March 2001. 944 [43] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 945 Encryption (MPPE)," RFC 3079, March 2001. 947 [44] IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 948 Telecommunications and Information Exchange between Systems - 949 LAN/MAN Specific Requirements - Part 11: Wireless Medium Access 950 Control (MAC) and physical layer (PHY) specifications: 951 Specification for Enhanced Security", July 2001. 953 [45] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 954 Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/ 955 AESAlgs/Rijndael/Rijndael.pdf 957 [46] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", 958 U.S. DoC/NIST, summer 2001. 960 [47] "Symmetric Key Block Cipher Modes of Operation," 961 http://www.nist.gov/modes. 963 [48] "Recommendation for Block Cipher Modes of Operation", National 964 Institute of Standards and Technology (NIST) Special Publication 965 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, 966 DC, July 2001. 968 [49] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246, 969 November 1998. 971 [50] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 972 Authentication", RFC 2104, February 1997. 974 6. Security Considerations 976 6.1. Dictionary attacks 978 As noted in [34]-[36], both Kerberos IV and V are vulnerable to attack. 979 These attacks are particularly potent when carried out in a location 980 where a large number of authentication exchanges can be collected within 981 a short period of time, such as with wireless LANs deployed in "hot 982 spots". 984 As noted in [34], offline dictionary attacks are easily carried out 985 against the AS_REP, since the key encrypting the enclosed Kerberos 986 ticket is a function of the password. Such attacks are amenable to 987 parallelization, and it is therefore possible to crack a large number of 988 passwords in short time with only modest resources. As noted in [34], 989 the imposition of a password policy is likely only to decrease the 990 yield, but given access to sufficient exchanges, large scale password 991 compromise remains likely. 993 For this reason, when used on wireless networks, EAP GSS SHOULD be to 994 negotiate methods thought to be invulnerable to offline dictionary 995 attacks against the on-the-wire protocol. This includes public key 996 authentication techniques or password-based techniques described in 997 [37]-[40]. 999 Kerberos V SHOULD NOT be used without extensions providing protection 1000 against offline dictionary attacks. As noted in [34], it has been 1001 proposed that Kerberos V dictionary attack vulnerabilities be addressed 1002 via a pre-authentication exchange. The vulnerability can also be 1003 addressed by use of PKINIT [41]. 1005 6.2. Certificate revocation 1007 Since the EAP server is on the Internet during the EAP conversation, the 1008 server is capable of following a certificate chain or verifying whether 1009 the peer's certificate has been revoked. In contrast, the peer may or 1010 may not have Internet connectivity, and thus while it can validate the 1011 EAP server's certificate based on a pre-configured set of CAs, it may 1012 not be able to follow a certificate chain or verify whether the EAP 1013 server's certificate has been revoked. 1015 In the case where the peer is initiating a voluntary Layer 2 tunnel 1016 using PPTP or L2TP, the peer will typically already have a PPP interface 1017 and Internet connectivity established at the time of tunnel initiation. 1018 As a result, during the EAP conversation it is capable of checking for 1019 certificate revocation. 1021 However, in the case where the peer is initiating a connection, it will 1022 not have Internet connectivity and is therefore not capable of checking 1023 for certificate revocation until after the peer has access to the 1024 Internet. In this case, the peer SHOULD check for certificate revocation 1025 after connecting to the Internet. 1027 6.3. Mutual authentication 1029 It is recommended that a GSS-API method supporting mutual authentication 1030 be selected during the SPNEGO negotiation. This addresses 1031 vulnerabilities associated with rogue EAP servers, as well as avoiding 1032 vulnerabilities associated with parallel one-way authentications. 1034 6.4. Credential reuse 1036 A peer with valid credentials may reuse those credentials in a 1037 subsequent authentication. Credential reuse improves efficiency in a 1038 number of scenarios. Where the peer attempts to re-authenticate to an 1039 EAP server within a short period of time, the re-authentication time may 1040 be shortened. Also, where the peer roams to another NAS willing to 1041 accept credentials from a previous NAS, fast-handoff may be achieved. 1042 Credential reuse may also prove useful during multi-link authentication. 1044 For example, a peer initially using the IAKERB GSS-API method to obtain 1045 a TGT and a ticket to the NAS may subsequently reuse that ticket in an 1046 AP_REQ/AP_REP exchange that may occur either in-band (e.g. via use of 1047 the Kerberos V GSS-API method) or out-of-band (e.g. via an 802.1X EAPOL- 1048 Key message). Typically in-band efficiency savings are modest (one 1049 round-trip saved using the Kerberos V GSS-API method versus IAKERB), 1050 while savings from out-of-band credential reuse can be more substantial. 1052 The decision of whether to attempt to reuse credentials is left up to 1053 the peer, which needs to determine whether credential use is likely to 1054 succeed. The decision may be based on out-of-band information (such as 1055 probe/response messages exchanged via 802.11 [28]), or the time elapsed 1056 since the previous authentication attempt. 1058 If the peer attempts to reuse credentials that are not valid, then the 1059 NAS will respond with an error and the peer can re-authenticate using 1060 the more complete sequence. For example, after an initial IAKERB 1061 authentication, the peer will have obtained a TGT from the KDC via the 1062 AS_REP, and a ticket to the NAS within the TGS_REP. The peer may 1063 subsequently attempt to negotiate the Kerberos V GSS-API method, so as 1064 to reuse the previously obtained credentials. Should a KRB_ERROR be 1065 returned by the NAS, then the peer can negotiate IAKERB on its next 1066 attempt instead. 1068 Note that credential reuse for the purpose of "fast handoff" has 1069 significant limitations. For example, in order to reuse a Kerberos 1070 ticket on a different NAS, it is necessary for NASes within the same 1071 geographic area to share a key with the KDC. If this is not the case, 1072 then peers moving from one NAS to another will not be able to reuse 1073 credentials without requring communication between the NASes. Allowing 1074 multiple NASes to share a key with the KDC makes it more likely that an 1075 attacker sniffing the wire will be able to obtain the NAS key, 1076 particularly if the key is derived from a password. Details are provided 1077 within reference [34]. The alternative is for the new NAS to pass the 1078 submitted ticket and authenticator to a backend authentication server or 1079 previous NAS for validation. Having to communicate with the backend 1080 authentication server loses much of the benefits of "fast handoff" and 1081 if one presumes existence of such an Inter-Access Point Protocol (IAPP) 1082 then EAP-based "fast handoff" would not be necessary in the first place. 1084 Similarly, if the EAP servers are set up in a rotary or made available 1085 via a round-robin technique, then the credentials also may not be 1086 reusable without communication with a backend authentication server or 1087 previous NAS. 1089 Furthermore, since existing Kerberos implementations do not include AAA 1090 authorizations within the authorization data field of the Kerberos 1091 ticket [16], even if the credentials can be reused, it may be necessary 1092 for the NAS to obtain the authorization information from the AAA server 1093 before the correct session state can be re-established on the new NAS. 1094 If AAA authorizations are not obtained prior to granting access, then 1095 the new NAS could potentially provide the wrong service to the peer. For 1096 example, where Filter-Id [29] or tunnel attributes [32] were 1097 unavailable, a peer might be given unrestricted network access where 1098 this was not intended. 1100 As a result of these considerations, credential reuse for the purpose of 1101 "fast handoff" does not appear to be practical at this time. 1103 6.5. Key transmission issues 1105 As a result of the EAP GSS conversation, the EAP endpoints will mutually 1106 authenticate and derive a session key, which this specification calls 1107 the "master key". Within GSS-API, it is possible to use GSSWrap() to 1108 encrypt using the master key, or GSSGetMIC() to produce a messsage 1109 integrity check (MIC) keyed by the master key. However, for security 1110 reasons, there are no GSS-API calls to obtain the master key itself. 1112 In the most general case, authentication keys, encryption keys and IVs 1113 may be required for use with the chosen ciphersuite. The keys from which 1114 these session keys are derived are known as "master session keys" and 1115 are derived from the master key. 1117 Since the peer and EAP client reside on the same machine, and the master 1118 key cannot be exported, it is necessary for the master session keys to 1119 be derived within EAP GSS. Once the ciphersuite has been determined, 1120 the master session keys are converted to ciphersuite-specific session 1121 keys and passed to the link layer encryption module. 1123 The situation may be more complex on the NAS, which may or may not 1124 reside on the same machine as the EAP server. In the case where the EAP 1125 server and NAS reside on different machines, there are several 1126 implications for security. Firstly, the mutual authentication defined in 1127 EAP GSS will occur between the peer and the EAP server, not between the 1128 peer and the NAS. 1130 This means that as a result of the EAP GSS conversation, it is not 1131 possible for the peer to validate the identity of the device that it is 1132 speaking to. The second issue is that the master session keys negotiated 1133 between the peer and EAP server will need to be transmitted to the NAS. 1135 Both issues can be addressed via addition of a followon exchange. For 1136 example, where the IAKERB GSS-API method is used for initial 1137 authentication, the Kerberos V GSS-API method can be used to mutually 1138 authenticate the peer and NAS and transfer the master session key from 1139 the peer to the NAS, enclosed in a Kerberos ticket. The NAS can then 1140 derive the master session keys from the master key. Once the ciphersuite 1141 is determined, the master session keys are converted to ciphersuite- 1142 specific session keys and passed to the link layer encryption module on 1143 the NAS. 1145 6.6. Link layer ciphersuite negotiation 1147 SPNEGO [19] supports protected ciphersuite negotiation in the case where 1148 the negotiated method provides authentication and integrity protection. 1149 As a result, SPNEGO negotiations are typically more secure than than 1150 unprotected link layer ciphersuite negotiations. For example, ECP, 1151 described in [6], supports unprotected cipher-suite negotiations within 1152 PPP and is thus vulnerable to attack. Similarly, 802.11, described in 1153 [28], currently does not support protected ciphersuite negotiations. 1155 Since peers completing the GSS-API SPNEGO negotiation will typically 1156 implicitly select a ciphersuite, which includes key strength, encryption 1157 and hashing methods, it is tempting to use this protected ciphersuite 1158 negotiation in place of link layer ciphersuite negotiation mechanisms. 1160 Nevertheless, this presents substantial difficulties. The available 1161 link layer ciphersuites may not correspond to the ciphersuites 1162 implicitly negotiated as part of SPNEGO, and therefore it may be 1163 difficult to use SPNEGO in this way. For example, 802.11 [28] currently 1164 only supports Wired Equivalency Privacy (WEP), a flawed cipher based on 1165 RC4 which lacks a keyed message integrity check, and therefore does not 1166 support per-frame authentication and integrity protection. Similarly, 1167 the PPP ECP methods defined in [9]-[10] support DESEbis and 3DES 1168 transforms for confidentiality, but do not support per-frame 1169 authentication or integrity protection. Thus, there is no correspondence 1170 between 802.11 or PPP ciphersuites and the ciphersuites available within 1171 GSS-API methods such as Kerberos V [16]-[17]. As a result, the use of 1172 SPNEGO for link-layer ciphersuite negotiation is not recommended. 1174 7. IANA Considerations 1176 This document requires assignment of a EAP Type for EAP GSS. It does not 1177 create any new number spaces for IANA administration. 1179 Appendix A - Example IAKERB topologies 1181 Where EAP GSS is used along with the GSS-API IAKERB [18] or Kerberos V 1182 [20] mechanisms, two major topologies are possible: 1184 RADIUS+KDC backend 1185 Here a RADIUS backend is used, along with a Kerberos KDC backend. 1186 The NAS functions as an EAP-pass-through device, encapsulating EAP 1187 messages received from the peer within RADIUS as described in [33], 1188 and passing them on to the RADIUS server. In turn, the RADIUS 1189 server acts as an IAKERB proxy, de-capsulating EAP GSS/IAKERB 1190 packets, and passing them on to the Kerberos KDC. In turn, the 1191 RADIUS server will encapsulated packets from the Kerberos KDC in 1192 EAP GSS/IAKERB and send this to the NAS. EAP-Message attributes 1193 received from the RADIUS server are de-capsulated by the NAS and 1194 sent to the peer. In this topology, the NAS need not have knowledge 1195 of specific EAP or GSS-API methods, while the RADIUS server does 1196 require this knowledge. 1198 KDC backend 1199 In this topology, only a Kerberos KDC is used as a backend, and the 1200 NAS functions as an IAKERB proxy, de-capsulating EAP GSS/IAKERB 1201 messages and passing them on to the KDC. Messages from the KDC are 1202 encapsulated within EAP GSS/IAKERB by the NAS and sent to the peer. 1203 In this case, the NAS needs to understand the EAP GSS, GSS-API 1204 IAKERB, as well as GSS-API Kerberos V mechanisms. In addition, 1205 where the peer already has a valid TGT and ticket to the NAS, it 1206 may choose to use the Kerberos V mechanism within EAP. Note that in 1207 the case of 802.11, the Kerberos AP_REQ/AP_REP messages may be 1208 carried in messages outside the conventional EAP exchange [27] so 1209 that use of the Kerberos V mechanism within EAP is not necessary. 1211 In the examples below, each topology is discussed. While nominally the 1212 EAP conversation occurs between the NAS and the peer, the NAS MAY act as 1213 a pass-through device, with the EAP packets received from the peer being 1214 encapsulated for transmission to a RADIUS server. In the discussion 1215 that follows, we will use the term "EAP server" to denote the ultimate 1216 endpoint conversing with the peer. 1218 A.1 RADIUS+KDC backend 1220 In this topology, the NAS will act as an EAP pass-through, and the 1221 RADIUS server acts as an IAKERB proxy. A successful EAP GSS/IAKERB 1222 authentication will appear as follows: 1224 Peer NAS RADIUS KDC 1225 ------ ------------- --------- ------ 1226 EAP/Identity 1227 <-Request 1229 EAP/Identity 1230 Response -> 1232 EAP/Identity 1233 Response -> 1234 Access-Challenge 1235 EAP GSS Request 1236 <- (Start) 1238 <-EAP GSS Request(Empty) 1240 EAP GSS 1241 Response [1] 1242 (SPNEGO) -> 1244 EAP GSS Response 1245 (SPNEGO) -> 1246 Access-Challenge 1247 EAP GSS Request 1248 <-(SPNEGO) 1250 EAP GSS Request 1251 <-(SPNEGO) 1253 EAP GSS IAKERB 1254 Response [2] 1255 (AS_REQ) -> 1257 EAP GSS IAKERB 1258 Response 1259 (AS_REQ) -> 1261 AS_REQ -> 1262 <- AS_REP 1264 Access-Challenge 1265 EAP GSS IAKERB Request 1267 <-(AS_REP) 1269 EAP GSS IAKERB 1270 Request 1271 <-(AS_REP) 1273 EAP GSS IAKERB 1274 Response [3] 1275 (TGS_REQ) -> 1277 EAP GSS IAKERB 1278 Response 1279 (TGS_REQ) -> 1281 TGS_REQ -> 1282 <- TGS_REP 1284 Access-Challenge 1285 EAP GSS IAKERB Request 1286 <-(TGS_REP) 1287 EAP GSS IAKERB 1288 Request 1289 <-(TGS_REP) 1291 EAP GSS IAKERB 1292 Response 1293 (Empty) -> 1295 EAP GSS IAKERB 1296 Response 1297 (Empty) -> 1298 Access-Accept [4] 1299 <- EAP-Success 1301 <- EAP-Success 1302 AP_REQ -> 1303 <- AP_REP [5] 1305 Notes: 1307 1. IAKERB may be requested by the EAP GSS client without the need for 1308 negotiation, or SPNEGO may be used. 1310 2. The AS_REQ requests a TGT from the KDC. It may or may not include 1311 PADATA. As a result, the AS_REQ may not authenticate the peer to 1312 the KDC, but the AS_REP authenticates the KDC to the peer. 1314 3. The TGS_REQ requests a ticket to the NAS service. The ticket is 1315 encrypted with the NAS's key so that it can only be validated by 1316 the NAS. 1318 4. On receiving a TGS_REP from the KDC rather than a KRB_ERROR, the 1319 RADIUS server can conclude that the peer has successfully 1320 authenticated, and thus that it is appropriate to reply to the NAS 1321 with an Access-Accept encapsulating an EAP-Success. 1323 5. The IAKERB exchange ends before the AP_REQ/AP_REP exchange occurs. 1324 As a result, the AP_REQ/AP_REP exchange either will not occur 1325 (preventing mutual authentication between peer and NAS or transport 1326 of the session key from peer to NAS), will occur out-of-band (e.g. 1327 after access is granted), or will occur in a subsequent EAP GSS 1328 conversation (e.g. using the GSS-API Kerberos V method). 1330 A.2 Kerberos KDC backend 1332 In this topology, there is no RADIUS server, and the NAS functions as an 1333 IAKERB proxy, de-capsulating EAP GSS/IAKERB frames and passing them on 1334 to the KDC. In turn, packets from the KDC are are encapsulated in EAP 1335 GSS/IAKERB frames and sent to the peer by the NAS. Where IAKERB is 1336 used, the NAS functions as an IAKERB proxy, de-capsulating EAP 1337 GSS/IAKERB messages and passing them on to the KDC. In addition, where 1338 the peer already has a valid TGT and ticket to the NAS, it may choose to 1339 use the Kerberos V mechanism within EAP. Note that in the case of 1340 802.11, the Kerberos AP_REQ/AP_REP messages are carried in messages 1341 outside the conventional EAP exchange [27] so that use of the Kerberos V 1342 mechanism within EAP is not necessary. 1344 In the Kerberos-only topology, messages from the KDC are encapsulated 1345 within EAP GSS/IAKERB and sent to the peer. In this case, the NAS needs 1346 to understand the EAP GSS, GSS-API IAKERB, as well as GSS-API Kerberos V 1347 mechanisms. 1349 A successful EAP GSS/IAKERB authentication occurring in a topology with 1350 a NAS acting as an IAKERB proxy to a Kerberos KDC will appear as 1351 follows: 1353 Peer NAS KDC 1354 ------ ------------- --------- 1355 EAP/Identity 1356 <-Request 1358 EAP/Identity 1359 Response -> 1361 <-EAP GSS Start 1363 EAP GSS IAKERB 1364 Response [1] 1365 (AS_REQ) -> 1367 AS_REQ -> 1368 <- AS_REP [2] 1370 EAP GSS IAKERB Request 1371 <-AS_REP) 1373 EAP GSS IAKERB 1374 Response [3] 1375 (TGS_REQ) -> 1377 TGS_REQ -> 1379 <- TGS_REP [4] 1381 EAP GSS IAKERB Request 1382 <-(TGS_REP) 1384 EAP GSS IAKERB 1385 Response 1386 (Empty) -> 1388 <- EAP-Success 1389 AP_REQ [5]-> 1390 <- AP_REP [6] 1391 Notes: 1393 1. If PADATA is not used in the AS_REQ, then the peer does not 1394 authenticate to the KDC. 1396 2. The KDC authenticates to the peer in the AS_REP. 1398 3. The peer authenticates to the KDC via the TGS_REQ. 1400 4. The KDC authenticates to the peer via the TGS_REP. The TGS_REP 1401 also provides the peer with a ticket and session-key for use with 1402 the NAS. 1404 5. Up until this point, the peer has not mutually authenticated with 1405 the NAS, or exchanged a key with it. As a result, the peer and NAS 1406 need to conclude an AP_REQ/AP_REP exchange. This can occur in-band 1407 or out-of-band. In the AP-REQ, the peer authenticates to the NAS 1408 and provides it with a session key. 1410 6. The NAS authenticates to the peer using the AP_REP. 1412 Appendix B - The Pseudorandom Function 1414 Given below is the description of the HMAC and pseudorandom function 1415 based on Section 5 of the TLS Protocol Version 1.0 specification [49]. 1417 Some of operations in the key derivation require a keyed MIC; this is a 1418 secure digest of some data protected by a secret. Forging the MIC is 1419 infeasible without knowledge of the MIC secret. The construction we use 1420 for this operation is known as HMAC, described in [50]. 1422 HMAC can be used with a variety of different hash algorithms. We use it 1423 with two different algorithms: MD5 and SHA-1, denoting these as 1424 HMAC_MD5(secret, data) and HMAC_SHA1(secret, data). Additional hash 1425 algorithms can be defined and used to protect record data, but MD5 and 1426 SHA-1 are hard coded into the protocol. 1428 In addition, a construction is required to do expansion of secrets into 1429 blocks of data for the purposes of key generation or validation. This 1430 pseudo-random function (PRF) takes as input a secret, a seed, and an 1431 identifying label and produces an output of arbitrary length. 1433 In order to make the PRF as secure as possible, it uses two hash 1434 algorithms in a way which should guarantee its security if either 1435 algorithm remains secure. 1437 First, we define a data expansion function, P_hash(secret, data) which 1438 uses a single hash function to expand a secret and seed into an 1439 arbitrary quantity of output: 1441 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 1442 HMAC_hash(secret, A(2) + seed) + 1443 HMAC_hash(secret, A(3) + seed) + ... 1445 Where + indicates concatenation. A() is defined as: 1447 A(0) = seed 1448 A(i) = HMAC_hash(secret, A(i-1)) 1450 P_hash can be iterated as many times as is necessary to produce the 1451 required quantity of data. For example, if P_SHA-1 was being used to 1452 create 64 bytes of data, it would have to be iterated 4 times (through 1453 A(4)), creating 80 bytes of output data; the last 16 bytes of the final 1454 iteration would then be discarded, leaving 64 bytes of output data. 1456 The PRF is created by splitting the secret into two halves and using one 1457 half to generate data with P_MD5 and the other half to generate data 1458 with P_SHA-1, then exclusive-or'ing the outputs of these two expansion 1459 functions together. 1461 S1 and S2 are the two halves of the secret and each is the same length. 1462 S1 is taken from the first half of the secret, S2 from the second half. 1463 Their length is created by rounding up the length of the overall secret 1464 divided by two; thus, if the original secret is an odd number of bytes 1465 long, the last byte of S1 will be the same as the first byte of S2. 1467 L_S = length in bytes of secret; 1468 L_S1 = L_S2 = ceil(L_S / 2); 1470 The secret is partitioned into two halves (with the possibility of one 1471 shared byte) as described above, S1 taking the first L_S1 bytes and S2 1472 the last L_S2 bytes. 1474 The PRF is then defined as the result of mixing the two pseudorandom 1475 streams by exclusive-or'ing them together. 1477 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR 1478 P_SHA-1(S2, label + seed); 1480 The label is an ASCII string. It should be included in the exact form it 1481 is given without a length byte or trailing null character. For example, 1482 the label "slithy toves" would be processed by hashing the following 1483 bytes: 1485 73 6C 69 74 68 79 20 74 6F 76 65 73 1487 Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 1488 byte outputs, the boundaries of their internal iterations will not be 1489 aligned; to generate a 80 byte output will involve P_MD5 being iterated 1490 through A(5), while P_SHA-1 will only iterate through A(4). 1492 Acknowledgments 1494 Thanks to Paul Leach of Microsoft, Glen Zorn of Cisco Systems, and Jesse 1495 Walker of Intel for useful discussions of this problem space. 1497 Authors' Addresses 1499 Bernard Aboba 1500 Microsoft Corporation 1501 One Microsoft Way 1502 Redmond, WA 98052 1504 Phone: +1 (425) 936-6605 1505 EMail: bernarda@microsoft.com 1507 Dan Simon 1508 Microsoft Research 1509 Microsoft Corporation 1510 One Microsoft Way 1511 Redmond, WA 98052 1513 EMail: dansimon@microsoft.com 1514 Phone: +1 425 936 6711 1515 Fax: +1 425 936 7329 1517 Intellectual Property Statement 1519 The IETF takes no position regarding the validity or scope of any 1520 intellectual property or other rights that might be claimed to pertain 1521 to the implementation or use of the technology described in this 1522 document or the extent to which any license under such rights might or 1523 might not be available; neither does it represent that it has made any 1524 effort to identify any such rights. Information on the IETF's 1525 procedures with respect to rights in standards-track and standards- 1526 related documentation can be found in BCP-11. Copies of claims of 1527 rights made available for publication and any assurances of licenses to 1528 be made available, or the result of an attempt made to obtain a general 1529 license or permission for the use of such proprietary rights by 1530 implementors or users of this specification can be obtained from the 1531 IETF Secretariat. 1533 The IETF invites any interested party to bring to its attention any 1534 copyrights, patents or patent applications, or other proprietary rights 1535 which may cover technology that may be required to practice this 1536 standard. Please address the information to the IETF Executive 1537 Director. 1539 Full Copyright Statement 1541 Copyright (C) The Internet Society (2001). All Rights Reserved. 1542 This document and translations of it may be copied and furnished to 1543 others, and derivative works that comment on or otherwise explain it or 1544 assist in its implementation may be prepared, copied, published and 1545 distributed, in whole or in part, without restriction of any kind, 1546 provided that the above copyright notice and this paragraph are included 1547 on all such copies and derivative works. However, this document itself 1548 may not be modified in any way, such as by removing the copyright notice 1549 or references to the Internet Society or other Internet organizations, 1550 except as needed for the purpose of developing Internet standards in 1551 which case the procedures for copyrights defined in the Internet 1552 Standards process must be followed, or as required to translate it into 1553 languages other than English. The limited permissions granted above are 1554 perpetual and will not be revoked by the Internet Society or its 1555 successors or assigns. This document and the information contained 1556 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1557 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1558 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1559 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1562 Expiration Date 1564 This memo is filed as , and expires 1565 May 23, 2002.