idnits 2.17.1 draft-ietf-radius-eap-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 231 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 366 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...), its areas...' == Line 15 has weird spacing: '... its worki...' == Line 19 has weird spacing: '... and may ...' == Line 20 has weird spacing: '...afts as refer...' == Line 30 has weird spacing: '... The distr...' == (226 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 791, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 797, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '1') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '3') (Obsoleted by RFC 2866) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-01 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-06) exists of draft-ietf-pppext-eaptls-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-pppext-eaptls (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' Summary: 19 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group Pat Calhoun 3 INTERNET-DRAFT Sun Microsystems 4 Updates: RFC 2138 Allan C. Rubens 5 Category: Standards Track Merit Network, Inc. 6 Bernard Aboba 7 8 May 1998 Microsoft 9 Extensible Authentication Protocol Support in RADIUS 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work- 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference mate- 21 rial or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 The distribution of this memo is unlimited. It is filed as , and expires November 1, 1998. Please send 32 comments to the authors. 34 2. Abstract 36 The Extensible Authentication Protocol (EAP) is a PPP extension that 37 provides support for additional authentication methods within PPP. 38 This document describes how the EAP-Message and Signature attributes 39 may be used for providing EAP support within RADIUS. 41 3. Changes from -04 draft 43 Updated section on retransmission 44 Added section on fragmentation 45 Added EAP-Timeout attribute 46 Updated references. 48 4. Introduction 50 The Extensible Authentication Protocol (EAP), described in [1], pro- 51 vides a standard mechanism for support of additional authentication 52 methods within PPP. Through the use of EAP, support for a number of 53 authentication schemes may be added, including smart cards, Kerberos, 54 Public Key, One Time Passwords, and others. In order to provide for 55 support of EAP within RADIUS, two new attributes, EAP-Message and Sig- 56 nature, were introduced as RADIUS extensions in [4]. This document 57 describes how these new attributes may be used for providing EAP sup- 58 port within RADIUS. 60 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 61 encapsulated EAP Packets between the NAS and a backend security 62 server. While the conversation between the RADIUS server and the 63 backend security server will typically occur using a proprietary pro- 64 tocol developed by the backend security server vendor, it is also pos- 65 sible to use RADIUS-encapsulated EAP via the EAP-Message attribute. 66 This has the advantage of allowing the RADIUS server to support EAP 67 without the need for authentication-specific code, which can instead 68 reside on a backend security server. 70 4.1. Requirements language 72 This specification uses the same words as [6] for defining the signif- 73 icance of each particular requirement. These words are: 75 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 76 that the definition is an absolute requirement of the speci- 77 fication. 79 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 80 nition is an absolute prohibition of the specification. 82 SHOULD This word, or the adjective "RECOMMENDED", means that there 83 may exist valid reasons in particular circumstances to 84 ignore a particular item, but the full implications must be 85 understood and carefully weighed before choosing a different 86 course. 88 SHOULD NOT 89 This phrase means that there may exist valid reasons in par- 90 ticular circumstances when the particular behavior is 91 acceptable or even useful, but the full implications should 92 be understood and the case carefully weighed before imple- 93 menting any behavior described with this label. 95 MAY This word, or the adjective "", means that an item is truly 96 optional. One vendor may choose to include the item because 97 a particular marketplace requires it or because the vendor 98 feels that it enhances the product while another vendor may 99 omit the same item. An implementation which does not 100 include a particular option MUST be prepared to interoperate 101 with another implementation which does include the option, 102 though perhaps with reduced functionality. In the same vein 103 an implementation which does include a particular option 104 MUST be prepared to interoperate with another implementation 105 which does not include the option.(except, of course, for 106 the feature the option provides) 108 An implementation is not compliant if it fails to satisfy one or more 109 of the must or must not requirements for the protocols it implements. 110 An implementation that satisfies all the must, must not, should and 111 should not requirements for its protocols is said to be "uncondition- 112 ally compliant"; one that satisfies all the must and must not require- 113 ments but not all the should or should not requirements for its proto- 114 cols is said to be "conditionally compliant." 116 5. Protocol overview 118 The EAP conversation between the authenticating peer (dial-in user) 119 and the NAS begins with the negotiation of EAP within LCP. Once EAP 120 has been negotiated, the NAS MUST send an EAP-Request/Identity message 121 to the authenticating peer, unless identity is determined via some 122 other means such as Called-Station-Id or Calling-Station-Id. The peer 123 will then respond with an EAP-Response/Identity which the the NAS will 124 then forward to the RADIUS server in the EAP-Message attribute of a 125 RADIUS Access-Request packet. The RADIUS Server will typically use the 126 EAP-Response/Identity to determine which EAP type is to be applied to 127 the user. 129 In order to permit non-EAP aware RADIUS proxies to forward the Access- 130 Request packet, if the NAS sends the EAP-Request/Identity, the NAS 131 MUST copy the contents of the EAP-Response/Identity into the User-Name 132 attribute and MUST include the EAP-Response/Identity in the User-Name 133 attribute in every subsequent Access-Request. NAS-Port SHOULD be 134 included in the attributes issued by the NAS in the Access-Request 135 packet, and either NAS-Identifier or NAS-IP-Address MUST be included. 136 In order to permit forwarding of the Access-Reply by EAP-unaware prox- 137 ies, if a User-Name attribute was included in an Access-Request, the 138 RADIUS Server MUST include the User-Name attribute in subsequent 139 Access-Challenge and Access-Accept packets. Without the User-Name 140 attribute, accounting and billing becomes very difficult to manage. 142 If identity is determined via another means such as Called-Station-Id 143 or Calling-Station-Id, the NAS MUST include these identifying 144 attributes in every Access-Request, and the RADIUS Server MUST include 145 them in every Access-Challenge and Access-Accept. 147 While this approach will save a round-trip, it cannot be universally 148 employed. There are circumstances in which the user's identity may 149 not be needed (such as when authentication and accounting is handled 150 based on Called-Station-Id or Calling-Station-Id), and therefore an 151 EAP-Request/Identity packet may not necessarily be issued by the NAS 152 to the authenticating peer. In cases where an EAP-Request/Identity 153 packet will not be sent, the NAS will send to the RADIUS server a 154 RADIUS Access-Request packet containing an EAP-Message attribute sig- 155 nifying EAP-Start. EAP-Start is indicated by sending an EAP-Message 156 attribute with a length of 2 (no data). However, it should be noted 157 that since no User-Name attribute is included in the Access-Request, 158 this approach is not compatible with RADIUS as specified in [2], nor 159 can it easily be applied in situations where proxies are deployed, 160 such as roaming or shared use networks. 162 If the RADIUS server supports EAP, it MUST respond with an Access- 163 Challenge packet containing an EAP-Message attribute. If the RADIUS 164 server does not support EAP, it MUST respond with an Access-Reject. 165 The EAP-Message attribute includes an encapsulated EAP packet which is 166 then passed on to the authenticating peer. In the case where the NAS 167 does not initially send an EAP-Request/Identity message to the peer, 168 the Access-Challenge typically will contain an EAP-Message attribute 169 encapsulating an EAP-Request/Identity message, requesting the dial-in 170 user to identify themself. The NAS will then respond with a RADIUS 171 Access-Request packet containing an EAP-Message attribute encapsulat- 172 ing an EAP-Response. The conversation continues until either a RADIUS 173 Access-Reject or Access-Accept packet is received. 175 Reception of a RADIUS Access-Reject packet, with or without an EAP- 176 Message attribute encapsulating EAP-Failure, MUST result in the NAS 177 issuing an LCP Terminate Request to the authenticating peer. A RADIUS 178 Access-Accept packet with an EAP-Message attribute encapsulating EAP- 179 Success successfully ends the authentication phase. The RADIUS Access- 180 Accept/EAP-Message/EAP-Success packet MUST contain all of the expected 181 attributes which are currently returned in an Access-Accept packet. 183 The above scenario creates a situation in which the NAS never needs to 184 manipulate an EAP packet. An alternative may be used in situations 185 where an EAP-Request/Identity message will always be sent by the NAS 186 to the authenticating peer. 188 For proxied RADIUS requests there are two methods of processing. If 189 the domain is determined based on the Called-Station-Id, the RADIUS 190 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 191 domain is determined based on the user's identity, the local RADIUS 192 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 193 packet. The response from the authenticating peer MUST be proxied to 194 the final authentication server. 196 For proxied RADIUS requests, the NAS may receive an Access-Reject 197 packet in response to its Access-Request/EAP-Identity packet. This 198 would occur if the message was proxied to a RADIUS Server which does 199 not support the EAP-Message extension. On receiving an Access-Reject, 200 the NAS MUST send an LCP Terminate Request to the authenticating peer, 201 and disconnect. 203 5.1. Retransmission 205 As noted in [1], the EAP authenticator (NAS) is responsible for 206 retransmission of packets between the authenticating peer and the NAS. 207 Thus if an EAP packet is lost in transit between the authenticating 208 peer and the NAS (or vice versa), the NAS will retransmit. As in 209 RADIUS [2], the RADIUS client is responsible for retransmission of 210 packets between the RADIUS client and the RADIUS server. 212 Note that it may be necessary to adjust retransmission strategies and 213 authentication timeouts in certain cases. For example, when a token 214 card is used additional time may be required to allow the user to find 215 the card and enter the token. Since the NAS will typically not have 216 knowledge of the required parameters, these need to be provided by the 217 RADIUS server. This can be accomplished by inclusion of EAP-Timeout 218 and Password-Retry attributes within the Access-Challenge packet. 220 5.2. Fragmentation 222 Using the EAP-Message attribute, it is possible for the RADIUS server 223 to encapsulate an EAP packet that is larger than the MTU on the link 224 between the NAS and the peer. Since it is not possible for the RADIUS 225 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 226 attribute may be included in an Access-Request packet containing an 227 EAP-Message attribute so as to provide the RADIUS server with this 228 information. 230 5.3. Examples 232 The example below shows the conversation between the authenticating 233 peer, NAS, and RADIUS server, for the case of a One Time Password 234 (OTP) authentication. OTP is used only for illustrative purposes; 235 other authentication protocols could also have been used, although 236 they might show somewhat different behavior. 238 Authenticating Peer NAS RADIUS Server 239 ------------------- --- ------------- 241 <- PPP LCP Request-EAP 242 auth 243 PPP LCP ACK-EAP 244 auth -> 245 <- PPP EAP-Request/ 246 Identity 247 PPP EAP-Response/ 248 Identity (MyID) -> 249 RADIUS 250 Access-Request/ 251 EAP-Message/ 252 EAP-Response/ 253 (MyID) -> 254 <- RADIUS 255 Access-Challenge/ 256 EAP-Message/EAP-Request 257 OTP/OTP Challenge 258 <- PPP EAP-Request/ 259 OTP/OTP Challenge 260 PPP EAP-Response/ 261 OTP, OTPpw -> 262 RADIUS 263 Access-Request/ 264 EAP-Message/ 265 EAP-Response/ 266 OTP, OTPpw -> 267 <- RADIUS 268 Access-Accept/ 269 EAP-Message/EAP-Success 270 (other attributes) 271 <- PPP EAP-Success 272 PPP Authentication 273 Phase complete, 274 NCP Phase starts 276 In the case where the NAS first sends an EAP-Start packet to the 277 RADIUS server, the conversation would appear as follows: 279 Authenticating Peer NAS RADIUS Server 280 ------------------- --- ------------- 282 <- PPP LCP Request-EAP 283 auth 284 PPP LCP ACK-EAP 285 auth -> 286 RADIUS 287 Access-Request/ 288 EAP-Message/Start -> 289 <- RADIUS 290 Access-Challenge/ 291 EAP-Message/Identity 292 <- PPP EA-Request/ 293 Identity 294 PPP EAP-Response/ 295 Identity (MyID) -> 296 RADIUS 297 Access-Request/ 298 EAP-Message/ 299 EAP-Response/ 300 (MyID) -> 301 <- RADIUS 302 Access-Challenge/ 303 EAP-Message/EAP-Request 304 OTP/OTP Challenge 305 <- PPP EAP-Request/ 306 OTP/OTP Challenge 307 PPP EAP-Response/ 308 OTP, OTPpw -> 309 RADIUS 310 Access-Request/ 311 EAP-Message/ 312 EAP-Response/ 313 OTP, OTPpw -> 314 <- RADIUS 315 Access-Accept/ 316 EAP-Message/EAP-Success 317 (other attributes) 318 <- PPP EAP-Success 319 PPP Authentication 320 Phase complete, 321 NCP Phase starts 323 In the case where the client fails EAP authentication, the conversa- 324 tion would appear as follows: 326 Autheticating Peer NAS RADIUS Server 327 ------------------- --- ------------- 329 <- PPP LCP Request-EAP 330 auth 331 PPP LCP ACK-EAP 332 auth -> 333 Access-Request/ 334 EAP-Message/Start -> 335 <- RADIUS 336 Access-Challenge/ 337 EAP-Message/Identity 338 <- PPP EAP-Request/ 339 Identity 340 PPP EAP-Response/ 341 Identity (MyID) -> 342 RADIUS 343 Access-Request/ 344 EAP-Message/ 345 EAP-Response/ 346 (MyID) -> 347 <- RADIUS 348 Access-Challenge/ 349 EAP-Message/EAP-Request 350 OTP/OTP Challenge 351 <- PPP EAP-Request/ 352 OTP/OTP Challenge 353 PPP EAP-Response/ 354 OTP, OTPpw -> 355 RADIUS 356 Access-Request/ 357 EAP-Message/ 358 EAP-Response/ 359 OTP, OTPpw -> 360 <- RADIUS 361 Access-Reject/ 362 EAP-Message/EAP-Failure 363 <- PPP EAP-Failure 364 (client disconnected) 366 In the case that the RADIUS server or proxy does not support EAP-Mes- 367 sage, the conversation would appear as follows: 369 Authenticating Peer NAS RADIUS Server 370 ------------------- --- ------------- 372 <- PPP LCP Request-EAP 373 auth 374 PPP LCP ACK-EAP 375 auth -> 376 RADIUS 377 Access-Request/ 378 EAP-Message/Start -> 379 <- RADIUS 380 Access-Reject 381 <- PPP LCP Terminate 382 (User Disconnected) 384 In the case where the local RADIUS Server does support EAP-Message, 385 but the remote RADIUS Server does not, the conversation would appear 386 as follows: 388 Authenticating Peer NAS RADIUS Server 389 ------------------- --- ------------- 391 <- PPP LCP Request-EAP 392 auth 393 PPP LCP ACK-EAP 394 auth -> 395 RADIUS 396 Access-Request/ 397 EAP-Message/Start -> 398 <- RADIUS 399 Access-Challenge/ 400 EAP-Message/Identity 401 <- PPP EAP-Request/ 402 Identity 403 PPP EAP-Response/ 404 Identity 405 (MyID) -> 406 RADIUS 407 Access-Request/ 408 EAP-Message/EAP-Response/ 409 (MyID) -> 410 <- RADIUS 411 Access-Reject 412 (proxied from remote 413 RADIUS Server) 414 <- PPP LCP Terminate 415 (User Disconnected) 417 In the case where the authenticating peer does not support EAP, but 418 where EAP is required for that user, the conversation would appear as 419 follows: 421 Authenticating Peer NAS RADIUS Server 422 ------------------- --- ------------- 423 <- PPP LCP Request-EAP 424 auth 425 PPP LCP NAK-EAP 426 auth -> 427 <- PPP LCP Request-CHAP 428 auth 429 PPP LCP ACK-CHAP 430 auth -> 431 <- PPP CHAP Challenge 432 PPP CHAP Response -> 433 RADIUS 434 Access-Request/ 435 User-Name, 436 CHAP-Password -> 437 <- RADIUS 438 Access-Reject 439 <- PPP LCP Terminate 440 (User Disconnected) 442 In the case where the NAS does not support EAP, but where EAP is 443 required for that user, the conversation would appear as follows: 445 Authenticating Peer NAS RADIUS Server 446 ---------------- --- ------------- 448 <- PPP LCP Request-CHAP 449 auth 450 PP LCP ACK-CHAP 451 auth -> 452 <- PPP CHAP Challenge 453 PPP CHAP Response -> 454 RADIUS 455 Access-Request/ 456 User-Name, 457 CHAP-Password -> 458 <- RADIUS 459 Access-Reject 460 <- PPP LCP Terminate 461 (User Disconnected) 463 6. Alternative uses 465 Currently the conversation between the backend security server and the 466 RADIUS server is proprietary because of lack of standardization. In 467 order to increase standardization and provide interoperability between 468 Radius vendors and backend security vendors, it is recommended that 469 RADIUS-encapsulated EAP be used for this conversation. 471 This has the advantage of allowing the RADIUS server to support EAP 472 without the need for authentication-specific code within the RADIUS 473 server. Authentication-specific code can then reside on a backend 474 security server instead. 476 In the case where RADIUS-encapsulated EAP is used in a conversation 477 between a RADIUS server and a backend security server, the security 478 server will typically return an Access-Accept/EAP-Success message 479 without inclusion of the expected attributes currently returned in an 480 Access-Accept. This means that the RADIUS server MUST add these 481 attributes prior to sending an Access-Accept/EAP-Success message to 482 the NAS. 484 7. Attributes 486 7.1. EAP-Message 488 Description 490 This attribute encapsulates Extensible Authentication Protocol [1] 491 packets so as to allow the NAS to authenticate dial-in users via 492 EAP without having to understand the protocol. 494 The NAS places EAP messages received from the authenticating peer 495 into one or more EAP-Message attributes and forwards them to the 496 RADIUS Server within an Access-Request message. If multiple EAP- 497 Messages are contained within an Access-Request or Access-Challenge 498 packet, they MUST be in order and they MUST be consecutive 499 attributes in the Access-Request or Access-Challenge packet. 500 Access-Accept and Access-Reject packets SHOULD only have ONE EAP- 501 Message attribute in them, containing EAP-Success or EAP-Failure. 503 It is expected that EAP will be used to implement a variety of 504 authentication methods, including methods involving strong cryptog- 505 raphy. In order to prevent attackers from subverting EAP by attack- 506 ing RADIUS/EAP, (for example, by modifying the EAP-Success o EAP- 507 Failure packets) it is necessary that RADIUS/EAP provide integrity 508 protection at least as strong as those used in the EAP methods 509 themselves. 511 The Signature attribute specified in [4] MUST be used to protect 512 all Access-Request, Access-Challenge, Access-Accept, and Access- 513 Reject packets containing an EAP-Message attribute. For Access- 514 Accepts the Signature is calculated as specified in [4]. For 515 Access-Challenge, Access-Accept, and Access-Reject packets, the 516 Signature is calculated as follows: 518 Signature = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) 520 The Signature attribute is zeroed for the purposes of the calcula- 521 tion and the shared secret is used as the key for the HMAC-MD5 522 hash. The Signature is calculated and inserted in the packet 523 before the Authenticator is calculated. 525 Access-Request packets including an EAP-Message attribute without a 526 Signature attribute SHOULD be silently discarded by the RADIUS 527 server. A RADIUS Server supporting EAP-Message MUST calculate the 528 correct value of the Signature and silently discard the packet if 529 it does not match the value sent. A RADIUS Server not supporting 530 EAP-Message MUST return an Access-Reject if it receives an Access- 531 Request containing an EAP-Message attribute. A RADIUS Server 532 receiving an EAP-Message attribute that it does not understand MUST 533 return an Access-Reject. 535 Access-Challenge, Access-Accept, or Access-Reject packets including 536 an EAP-Message attribute without a Signature attribute SHOULD be 537 silently discarded by the NAS. A NAS supporting EAP-Message MUST 538 calculate the correct value of the Signature and silently discard 539 the packet if it does not match the value sent. 541 A summary of the EAP-Message attribute format is shown below. The 542 fields are transmitted from left to right. 544 0 1 2 3 545 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 2 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | Length | String... 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Type 552 79 for EAP-Message 554 Length 556 >=3 (EAP packet enclosed) 557 =2 (EAP-Start message) 559 String 561 The String field includes EAP packets, as defined in [1]. If mul- 562 tiple EAP-Message attributes are present in a packet their values 563 should be concatenated; this allows EAP packets longer than 253 564 octets to be passed by RADIUS. 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Code | Identifier | Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 / / 571 / Data / 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 7.2. EAP-Timeout 577 Description 579 This attribute is used only in Access-Challenge packets and 580 provides the NAS with the timeout interval to apply during EAP 581 authentication. 583 A summary of the EAP-Timeout attribute format is shown below. The 584 fields are transmitted from left to right. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type | Length | Value 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Value (cont) | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Type 596 ? for EAP-Timeout 598 Length 600 6 602 Value 604 The field is 4 octets, containing a 32-bit unsigned integer with 605 the maximum number of seconds the NAS should wait for an EAP- 606 Response before retransmitting. 608 8. Security considerations 610 Since the purpose of EAP is to provide enhanced security for PPP 611 authentication, it is critical that RADIUS support for EAP be secure. 612 In particular, the following issues must be addressed: 614 Separation of the EAP server and PPP authenticator 615 Connection hijacking 616 Man in the middle attacks 617 Multiple databases 618 Negotiation attacks 620 8.1. Separation of the EAP server and PPP authenticator 622 As described in [8] and [9], it is possible for the EAP endpoints to 623 mutually authenticate, negotiate a ciphersuite, and derive a session 624 key for subsequent use in PPP encryption. 626 This does not present an issue on the peer, since the peer and EAP 627 client reside on the same machine; all that is required is for the EAP 628 client module to pass the session key to the PPP encryption module. 630 The situation may be more complex when EAP/RADIUS is used, since the 631 PPP authenticator will typically not reside on the same machine as the 632 EAP server. For example, the EAP server may be a backend security 633 server, or a module residing on the RADIUS server. 635 In the case where the EAP server and PPP authenticator reside on dif- 636 ferent machines, there are several implications for security. 637 Firstly, mutual authentication will occur between the peer and the EAP 638 server, not between the peer and the authenticator. This means that it 639 is not possible for the peer to validate the identity of the NAS or 640 tunnel server that it is speaking to. 642 As described earlier, when EAP/RADIUS is used to encapsulate EAP pack- 643 ets, the Signature attribute is required in EAP/RADIUS Access-Requests 644 sent from the NAS or tunnel server to the RADIUS server. Since the 645 Signature attribute involves a HMAC-MD5 hash, it is possible for the 646 RADIUS server to verify the integrity of the Access-Request as well as 647 the NAS or tunnel server's identity. Similarly, Access-Challenge pack- 648 ets sent from the RADIUS server to the NAS are also authenticated and 649 integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel 650 server to determine the integrity of the packet and verify the iden- 651 tity of the RADIUS server. Morever, EAP packets sent via the methods 652 described in [8] and [9] contain their own integrity protection, so 653 that they cannot be successfully modified by a rogue NAS or tunnel 654 server. 656 The second issue that arises in the case of an EAP server and PPP 657 authenticator residing on different machines is that the session key 658 negotiated between the peer and EAP server will need to be transmitted 659 to the authenticator. Therefore a mechanism needs to be provided to 660 transmit the session key from the EAP server to the authenticator or 661 tunnel server that needs to use the key. The specification of this 662 transit mechanism is outside the scope of this document. 664 8.2. Connection hijacking 666 In this form of attack, the attacker attempts to inject packets into 667 the conversation between the NAS and the RADIUS server, or between the 668 RADIUS server and the backend security server. RADIUS does not support 669 encryption, and as described in [2], only Access-Reply and Access- 670 Challenge packets are integrity protected. Moreover, the integrity 671 protection mechanism described in [2] is weaker than that likely to be 672 used by some EAP methods, making it possible to subvert those methods 673 by attacking EAP/RADIUS. 675 In order to provide for authentication of all packets in the EAP 676 exchange, all EAP/RADIUS packets MUST be authenticated using the Sig- 677 nature attribute, as described previously. 679 8.3. Man in the middle attacks 681 Since RADIUS security is based on shared secrets, end-to-end security 682 is not provided in the case where authentication or accounting packets 683 are forwarded along a proxy chain. As a result, attackers gaining 684 control of a RADIUS proxy will be able to modify EAP packets in tran- 685 sit without fear of detection. 687 This represents a weakness of RADIUS which cannot be remedied without 688 providing end-to-end data object security. 690 8.4. Multiple databases 692 In many cases a backend security server will be deployed along with a 693 RADIUS server in order to provide EAP services. Unless the backend 694 security server also functions as a RADIUS server, two separate user 695 databases will exist, each containing information about the security 696 requirements for the user. This represents a weakness, since security 697 may be compromised by a successful attack on either of the servers, or 698 their backend databases. With multiple user databases, adding a new 699 user may require multiple operations, increasing the chances for 700 error. The problems are further magnified in the case where user 701 information is also being kept in an LDAP server. In this case, three 702 stores of user information may exist. 704 In order to address these threats, consolidation of databases is rec- 705 ommended. This can be achieved by having both the RADIUS server and 706 backend security server store information in the same backend 707 database; by having the backend security server provide a full RADIUS 708 implementation; or by consolidating both the backend security server 709 and the RADIUS server onto the same machine. 711 8.5. Negotiation attacks 713 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 714 RADIUS server causes the authenticating peer to choose a less secure 715 authentication method so as to make it easier to obtain the user's 716 password. For example, a session that would normally be authenticated 717 with EAP would instead authenticated via CHAP or PAP; alternatively, a 718 connection that would normally be authenticated via one EAP type 719 occurs via a less secure EAP type, such as MD5. The threat posed by 720 rogue devices, once thought to be remote, has gained currency given 721 compromises of telephone company switching systems, such as those 722 described in [7]. 724 Protection against negotiation attacks requires the elimination of 725 downward negotiations. This can be achieved via implementation of per- 726 connection policy on the part of the authenticating peer, and per-user 727 policy on the part of the RADIUS server. 729 For the authenticating peer, authentication policy should be set on a 730 per-connection basis. Per-connection policy allows an authenticating 731 peer to negotiate EAP when calling one service, while negotiating CHAP 732 for another service, even if both services are accessible via the same 733 phone number. 735 With per-connection policy, an authenticating peer will only attempt 736 to negotiate EAP for a session in which EAP support is expected. As a 737 result, there is a presumption that an authenticating peer selecting 738 EAP requires that level of security. If it cannot be provided, it is 739 likely that there is some kind of misconfiguration, or even that the 740 authenticating peer is contacting the wrong server. Should the NAS not 741 be able to negotiate EAP, or should the EAP-Request sent by the NAS be 742 of a different EAP type than what is expected, the authenticating peer 743 MUST disconnect. An authenticating peer expecting EAP to be negotiated 744 for a session MUST NOT negotiate CHAP or PAP. 746 For a NAS, it may not be possible to determine whether a user is 747 required to authenticate with EAP until the user's identity is known. 748 For example, for shared-uses NASes it is possible for one reseller to 749 implement EAP while another does not. In such cases, if any users of 750 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 751 every call. This avoids forcing an EAP-capable client to do more than 752 one authentication, which weakens security. 754 If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Pass- 755 word attributes to the RADIUS Server in an Access-Request packet. If 756 the user is not required to use EAP, then the RADIUS Server will 757 respond with an Access-Accept or Access-Reject packet as appropriate. 758 However, if CHAP has been negotiated but EAP is required, the RADIUS 759 server MUST respond with an Access-Reject, rather than an Access-Chal- 760 lenge/EAP-Message/EAP-Request packet. The authenticating peer MUST 761 refuse to renegotiate authentication, even if the renegotiation is 762 from CHAP to EAP. 764 If EAP is negotiated but is not supported by the RADIUS proxy or 765 server, then the server or proxy MUST respond with an Access-Reject. 766 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 767 user. This is the correct behavior since the authenticating peer is 768 expecting EAP to be negotiated, and that expectation cannot be ful- 769 filled. An EAP-capable authenticating peer MUST refuse to renegotiate 770 the authentication protocol if EAP had initially been negotiated. 771 Note that problems with a non-EAP capable RADIUS proxy could prove 772 difficult to diagnose, since a user dialing in from one location (with 773 an EAP-capable proxy) might be able to successfully authenticate via 774 EAP, while the same user dialing into another location (and encounter- 775 ing an EAP-incapable proxy) might be consistently disconnected. 777 9. Acknowledgments 779 Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren- 780 dra Gidwani of Microsoft for useful discussions of this problem space. 782 10. References 784 [1] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Protocol 785 (EAP)." RFC 2284, Merit Network, Inc., March 1998. 787 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 788 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 789 Daydreamer, April 1997. 791 [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 792 1997. 794 [4] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 795 draft-ietf-radius-ext-01.txt, Livingston, June, 1997. 797 [5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC 798 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 799 April 1992. 801 [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement 802 Levels." RFC 2119, Harvard University, March, 1997. 804 [7] M. Slatalla, J. Quittner. "Masters of Deception." HarperCollins, 805 New York, 1995. 807 [8] B. Aboba, D. Simon. "PPP EAP TLS Authentication Protocol." Work 808 in progress, draft-ietf-pppext-eaptls-03.txt, Microsoft, April 1998. 810 [9] G. Carter. "PPP EAP ISAKMP Authentication Protocol." Work in 811 progress, draft-ietf-pppext-eapisakmp-00.txt, Entrust, November 1997. 813 11. Authors' Addresses 815 Pat R. Calhoun 816 Technology Development 817 Sun Microsystems, Inc. 818 15 Network Circle 819 Menlo Park, CA 94025 821 Phone: 847-548-0926 822 Fax: 650-786-6445 823 EMail: pcalhoun@toast.net 825 Allan C. Rubens 826 Merit Network, Inc. 827 4251 Plymouth Rd. 828 Ann Arbor, MI 48105-2785 830 Phone: 313-647-0417 831 EMail: acr@merit.edu 833 Bernard Aboba 834 Microsoft Corporation 835 One Microsoft Way 836 Redmond, WA 98052 838 Phone: 425-936-6605 839 EMail: bernarda@microsoft.com 841 r