idnits 2.17.1 draft-ietf-radius-eap-04.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 page length should not exceed 58 lines per page, but there was 15 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 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 216 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 349 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 23 has weird spacing: '... To learn...' == (211 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 730, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 736, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-pppext-eap-auth is -02, but you're referring to -03. ** Obsolete normative reference: RFC 2058 (ref. '2') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '3') (Obsoleted by RFC 2139) == 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-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-pppext-eaptls (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 5 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 10 March 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 learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1998. Please send com- 30 ments to the authors. 32 2. Abstract 34 The Extensible Authentication Protocol (EAP) is a PPP extension that 35 provides support for additional authentication methods within PPP. 36 This document describes how the EAP-Message and Signature attributes 37 may be used for providing EAP support within RADIUS. 39 3. Introduction 41 The Extensible Authentication Protocol (EAP), described in [1], pro- 42 vides a standard mechanism for support of additional authentication 43 methods within PPP. Through the use of EAP, support for a number of 44 authentication schemes may be added, including smart cards, Kerberos, 45 Public Key, One Time Passwords, and others. In order to provide for 46 support of EAP within RADIUS, two new attributes, EAP-Message and Sig- 47 nature, were introduced as RADIUS extensions in [4]. This document 48 describes how these new attributes may be used for providing EAP sup- 49 port within RADIUS. 51 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 52 encapsulated EAP Packets between the NAS and a backend security 53 server. While the conversation between the RADIUS server and the 54 backend security server will typically occur using a proprietary pro- 55 tocol developed by the backend security server vendor, it is also pos- 56 sible to use RADIUS-encapsulated EAP via the EAP-Message attribute. 57 This has the advantage of allowing the RADIUS server to support EAP 58 without the need for authentication-specific code, which can instead 59 reside on a backend security server. 61 3.1. Requirements language 63 This specification uses the same words as [6] for defining the signif- 64 icance of each particular requirement. These words are: 66 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 67 that the definition is an absolute requirement of the speci- 68 fication. 70 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 71 nition is an absolute prohibition of the specification. 73 SHOULD This word, or the adjective "RECOMMENDED", means that there 74 may exist valid reasons in particular circumstances to 75 ignore a particular item, but the full implications must be 76 understood and carefully weighed before choosing a different 77 course. 79 SHOULD NOT 80 This phrase means that there may exist valid reasons in par- 81 ticular circumstances when the particular behavior is 82 acceptable or even useful, but the full implications should 83 be understood and the case carefully weighed before imple- 84 menting any behavior described with this label. 86 MAY This word, or the adjective "", means that an item is truly 87 optional. One vendor may choose to include the item because 88 a particular marketplace requires it or because the vendor 89 feels that it enhances the product while another vendor may 90 omit the same item. An implementation which does not 91 include a particular option MUST be prepared to interoperate 92 with another implementation which does include the option, 93 though perhaps with reduced functionality. In the same vein 94 an implementation which does include a particular option 95 MUST be prepared to interoperate with another implementation 96 which does not include the option.(except, of course, for 97 the feature the option provides) 99 An implementation is not compliant if it fails to satisfy one or more 100 of the must or must not requirements for the protocols it implements. 101 An implementation that satisfies all the must, must not, should and 102 should not requirements for its protocols is said to be 103 "unconditionally compliant"; one that satisfies all the must and must 104 not requirements but not all the should or should not requirements for 105 its protocols is said to be "conditionally compliant." 107 4. Protocol overview 109 The EAP conversation between the authenticating peer (dial-in user) 110 and the NAS begins with the negotiation of EAP within LCP. Once EAP 111 has been negotiated, the NAS MUST send an EAP-Request/Identity message 112 to the authenticating peer, unless identity is determined via some 113 other means such as Called-Station-Id or Calling-Station-Id. The peer 114 will then respond with an EAP-Response/Identity which the the NAS will 115 then forward to the RADIUS server in the EAP-Message attribute of a 116 RADIUS Access-Request packet. The RADIUS Server will typically use the 117 EAP-Response/Identity to determine which EAP type is to be applied to 118 the user. 120 In order to permit non-EAP aware RADIUS proxies to forward the Access- 121 Request packet, if the NAS sends the EAP-Request/Identity, the NAS 122 MUST copy the contents of the EAP-Response/Identity into the User-Name 123 attribute and MUST include the EAP-Response/Identity in the User-Name 124 attribute in every subsequent Access-Request. NAS-Port SHOULD be 125 included in the attributes issued by the NAS in the Access-Request 126 packet, and either NAS-Identifier or NAS-IP-Address MUST be included. 127 In order to permit forwarding of the Access-Reply by EAP-unaware prox- 128 ies, if a User-Name attribute was included in an Access-Request, the 129 RADIUS Server MUST include the User-Name attribute in subsequent 130 Access-Challenge and Access-Accept packets. Without the User-Name 131 attribute, accounting and billing becomes very difficult to manage. 133 If identity is determined via another means such as Called-Station-Id 134 or Calling-Station-Id, the NAS MUST include these identifying 135 attributes in every Access-Request, and the RADIUS Server MUST include 136 them in every Access-Challenge and Access-Accept. 138 While this approach will save a round-trip, it cannot be universally 139 employed. There are circumstances in which the user's identity may 140 not be needed (such as when authentication and accounting is handled 141 based on Called-Station-Id or Calling-Station-Id), and therefore an 142 EAP-Request/Identity packet may not necessarily be issued by the NAS 143 to the authenticating peer. In cases where an EAP-Request/Identity 144 packet will not be sent, the NAS will send to the RADIUS server a 145 RADIUS Access-Request packet containing an EAP-Message attribute sig- 146 nifying EAP-Start. EAP-Start is indicated by sending an EAP-Message 147 attribute with a length of 2 (no data). However, it should be noted 148 that since no User-Name attribute is included in the Access-Request, 149 this approach is not compatible with RADIUS as specified in [2], nor 150 can it easily be applied in situations where proxies are deployed, 151 such as roaming or shared use networks. 153 If the RADIUS server supports EAP, it MUST respond with an Access- 154 Challenge packet containing an EAP-Message attribute. If the RADIUS 155 server does not support EAP, it MUST respond with an Access-Reject. 157 The EAP-Message attribute includes an encapsulated EAP packet which is 158 then passed on to the authenticating peer. In the case where the NAS 159 does not initially send an EAP-Request/Identity message to the peer, 160 the Access-Challenge typically will contain an EAP-Message attribute 161 encapsulating an EAP-Request/Identity message, requesting the dial-in 162 user to identify themself. The NAS will then respond with a RADIUS 163 Access-Request packet containing an EAP-Message attribute encapsulat- 164 ing an EAP-Response. The conversation continues until either a RADIUS 165 Access-Reject or Access-Accept packet is received. 167 Reception of a RADIUS Access-Reject packet, with or without an EAP- 168 Message attribute encapsulating EAP-Failure, MUST result in the NAS 169 issuing an LCP Terminate Request to the authenticating peer. A RADIUS 170 Access-Accept packet with an EAP-Message attribute encapsulating EAP- 171 Success successfully ends the authentication phase. The RADIUS Access- 172 Accept/EAP-Message/EAP-Success packet MUST contain all of the expected 173 attributes which are currently returned in an Access-Accept packet. 175 The above scenario creates a situation in which the NAS never needs to 176 manipulate an EAP packet. An alternative may be used in situations 177 where an EAP-Request/Identity message will always be sent by the NAS 178 to the authenticating peer. 180 For proxied RADIUS requests there are two methods of processing. If 181 the domain is determined based on the Called-Station-Id, the RADIUS 182 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 183 domain is determined based on the user's identity, the local RADIUS 184 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 185 packet. The response from the authenticating peer MUST be proxied to 186 the final authentication server. 188 For proxied RADIUS requests, the NAS may receive an Access-Reject 189 packet in response to its Access-Request/EAP-Identity packet. This 190 would occur if the message was proxied to a RADIUS Server which does 191 not support the EAP-Message extension. On receiving an Access-Reject, 192 the NAS MUST send an LCP Terminate Request to the authenticating peer, 193 and disconnect. 195 The NAS is not responsible for the retransmission of any AP messages. 196 The authenticating peer and the RADIUS Server are responsible for any 197 retransmissions. 199 4.1. Examples 201 The example below shows the conversation between the authenticating 202 peer, NAS, and RADIUS server, for the case of a One Time Password 203 (OTP) authentication. OTP is used only for illustrative purposes; 204 other authentication protocols could also have been used, although 205 they might show somewhat different behavior. 207 Authenticating Peer NAS RADIUS Server 208 ------------------- --- ------------- 209 <- PPP LCP Request-EAP 210 auth 211 PPP LCP ACK-EAP 212 auth -> 213 <- PPP EAP-Request/ 214 Identity 215 PPP EAP-Response/ 216 Identity (MyID) -> 217 RADIUS 218 Access-Request/ 219 EAP-Message/ 220 EAP-Response/ 221 (MyID) -> 222 <- RADIUS 223 Access-Challenge/ 224 EAP-Message/EAP-Request 225 OTP/OTP Challenge 226 <- PPP EAP-Request/ 227 OTP/OTP Challenge 228 PPP EAP-Response/ 229 OTP, OTPpw -> 230 RADIUS 231 Access-Request/ 232 EAP-Message/ 233 EAP-Response/ 234 OTP, OTPpw -> 235 <- RADIUS 236 Access-Accept/ 237 EAP-Message/EAP-Success 238 (other attributes) 239 <- PPP EAP-Success 240 PPP Authentication 241 Phase complete, 242 NCP Phase starts 244 In the case where the NAS first sends an EAP-Start packet to the 245 RADIUS server, the conversation would appear as follows: 247 Authenticating Peer NAS RADIUS Server 248 ------------------- --- ------------- 250 <- PPP LCP Request-EAP 251 auth 252 PPP LCP ACK-EAP 253 auth -> 254 RADIUS 255 Access-Request/ 256 EAP-Message/Start -> 257 <- RADIUS 258 Access-Challenge/ 259 EAP-Message/Identity 260 <- PPP EA-Request/ 261 Identity 262 PPP EAP-Response/ 263 Identity (MyID) -> 264 RADIUS 265 Access-Request/ 266 EAP-Message/ 267 EAP-Response/ 268 (MyID) -> 269 <- RADIUS 270 Access-Challenge/ 271 EAP-Message/EAP-Request 272 OTP/OTP Challenge 273 <- PPP EAP-Request/ 274 OTP/OTP Challenge 275 PPP EAP-Response/ 276 OTP, OTPpw -> 277 RADIUS 278 Access-Request/ 279 EAP-Message/ 280 EAP-Response/ 281 OTP, OTPpw -> 282 <- RADIUS 283 Access-Accept/ 284 EAP-Message/EAP-Success 285 (other attributes) 286 <- PPP EAP-Success 287 PPP Authentication 288 Phase complete, 289 NCP Phase starts 291 In the case where the client fails EAP authentication, the conversa- 292 tion would appear as follows: 294 Autheticating Peer NAS RADIUS Server 295 ------------------- --- ------------- 297 <- PPP LCP Request-EAP 298 auth 299 PPP LCP ACK-EAP 300 auth -> 301 Access-Request/ 302 EAP-Message/Start -> 303 <- RADIUS 304 Access-Challenge/ 305 EAP-Message/Identity 306 <- PPP EAP-Request/ 307 Identity 308 PPP EAP-Response/ 309 Identity (MyID) -> 310 RADIUS 311 Access-Request/ 312 EAP-Message/ 313 EAP-Response/ 314 (MyID) -> 315 <- RADIUS 316 Access-Challenge/ 317 EAP-Message/EAP-Request 318 OTP/OTP Challenge 319 <- PPP EAP-Request/ 320 OTP/OTP Challenge 321 PPP EAP-Response/ 322 OTP, OTPpw -> 323 RADIUS 324 Access-Request/ 325 EAP-Message/ 326 EAP-Response/ 327 OTP, OTPpw -> 328 <- RADIUS 329 Access-Reject/ 330 EAP-Message/EAP-Failure 331 <- PPP EAP-Failure 332 (client disconnected) 334 In the case that the RADIUS server or proxy does not support EAP-Mes- 335 sage, the conversation would appear as follows: 337 Authenticating Peer NAS RADIUS Server 338 ------------------- --- ------------- 340 <- PPP LCP Request-EAP 341 auth 342 PPP LCP ACK-EAP 343 auth -> 344 RADIUS 345 Access-Request/ 346 EAP-Message/Start -> 347 <- RADIUS 348 Access-Reject 349 <- PPP LCP Terminate 350 (User Disconnected) 352 In the case where the local RADIUS Server does support EAP-Message, 353 but the remote RADIUS Server does not, the conversation would appear 354 as follows: 356 Authenticating Peer NAS RADIUS Server 357 ------------------- --- ------------- 359 <- PPP LCP Request-EAP 360 auth 361 PPP LCP ACK-EAP 362 auth -> 363 RADIUS 364 Access-Request/ 365 EAP-Message/Start -> 366 <- RADIUS 367 Access-Challenge/ 368 EAP-Message/Identity 370 <- PPP EAP-Request/ 371 Identity 372 PPP EAP-Response/ 373 Identity 374 (MyID) -> 375 RADIUS 376 Access-Request/ 377 EAP-Message/EAP-Response/ 378 (MyID) -> 379 <- RADIUS 380 Access-Reject 381 (proxied from remote 382 RADIUS Server) 383 <- PPP LCP Terminate 384 (User Disconnected) 386 In the case where the authenticating peer does not support EAP, but 387 where EAP is required for that user, the conversation would appear as 388 follows: 390 Authenticating Peer NAS RADIUS Server 391 ------------------- --- ------------- 393 <- PPP LCP Request-EAP 394 auth 395 PPP LCP NAK-EAP 396 auth -> 397 <- PPP LCP Request-CHAP 398 auth 399 PPP LCP ACK-CHAP 400 auth -> 401 <- PPP CHAP Challenge 402 PPP CHAP Response -> 403 RADIUS 404 Access-Request/ 405 User-Name, 406 CHAP-assword -> 407 <- RADIUS 408 Access-Reject 409 <- PPP LCP Terminate 410 (User Disconnected) 412 In the case where the NAS does not support EAP, but where EAP is 413 required for that user, the conversation would appear as follows: 415 Authenticating Peer NAS RADIUS Server 416 ------------------ --- ------------- 418 <- PPP LCP Request-CHAP 419 auth 420 PP LCP ACK-CHAP 421 auth -> 422 <- PPP CHAP Challenge 423 PPP CHAP Response -> 424 RADIUS 425 Access-Request/ 426 User-Name, 427 CHAP-Password -> 428 <- RADIUS 429 Access-Reject 430 <- PPP LCP Terminate 431 (User Disconnected) 433 5. Alternative uses 435 Currently the conversation between the backend security server and the 436 RADIUS server is proprietary because of lack of standardization. In 437 order to increase standardization and provide interoperability between 438 Radius vendors and backend security vendors, it is recommended that 439 RADIUS-encapsulated EAP be used for this conversation. 441 This has the advantage of allowing the RADIUS server to support EAP 442 without the need for authentication-specific code within the RADIUS 443 server. Authentication-specific code can then reside on a backend 444 security server instead. 446 In the case where RADIUS-encapsulated EAP is used in a conversation 447 between a RADIUS server and a backend security server, the security 448 server will typically return an Access-Accept/EAP-Success message 449 without inclusion of the expected attributes currently returned in an 450 Access-Accept. This means that the RADIUS server MUST add these 451 attributes prior to sending an Access-Accept/EAP-Success message to 452 the NAS. 454 6. Attributes 456 6.1. EAP-Message 458 Description 460 This attribute encapsulates Extensible Authentication Protocol [1] 461 packets so as to allow the NAS to authenticate dial-in users via 462 EAP without having to understand the protocol. 464 The NAS places EAP messages received from the authenticating peer 465 into one or more EAP-Message attributes and forwards them to the 466 RADIUS Server within an Access-Request message. If multiple EAP- 467 Messages are contained within an Access-Request or Access-Challenge 468 packet, they MUST be in order and they MUST be consecutive 469 attributes in the Access-Request or Access-Challenge packet. 470 Access-Accept and Access-Reject packets SHOULD only have ONE EAP- 471 Message attribute in them, containing EAP-Success or EAP-Failure. 473 It is expected that EAP will be used to implement a variety of 474 authentication methods, including methods involving strong 475 cryptography. In order to prevent attackers from subverting EAP by 476 attacking RADIUS/EAP, (for example, by modifying the EAP-Success or 477 EAP-Failure packets) it is necessary that RADIUS/EAP provide 478 integrity protection at least as strong as those used in the EAP 479 methods themselves. 481 The Signature attribute specified in [4] MUST be used to protect 482 all Access-Request, Access-Challenge, Access-Accept, and Access- 483 Reject packets containing an EAP-Message attribute. For Access- 484 Accepts the Signature is calculated as specified in [4]. For 485 Access-Challenge, Access-Accept, and Access-Reject packets, the 486 Signature is calculated as follows: 488 Signature = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) 490 The Signature attribute is zeroed for the purposes of the calcula- 491 tion and the shared secret is used as the key for the HMAC-MD5 492 hash. The Signature is calculated and inserted in the packet 493 before the Authenticator is calculated. 495 Access-Request packets including an EAP-Message attribute without a 496 Signature attribute SHOULD be silently discarded by the RADIUS 497 server. A RADIUS Server supporting EAP-Message MUST calculate the 498 correct value of the Signature and silently discard the packet if 499 it does not match the value sent. A RADIUS Server not supporting 500 EAP-Message MUST return an Access-Reject if it receives an Access- 501 Request containing an EAP-Message attribute. A RADIUS Server 502 receiving an EAP-Message attribute that it does not understand MUST 503 return an Access-Reject. 505 Access-Challenge, Access-Accept, or Access-Reject packets including 506 an EAP-Message attribute without a Signature attribute SHOULD be 507 silently discarded by the NAS. A NAS supporting EAP-Message MUST 508 calculate the correct value of the Signature and silently discard 509 the packet if it does not match the value sent. 511 A summary of the EAP-Message attribute format is shown below. The 512 fields are transmitted from left to right. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | String... 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Type 522 79 for EAP-Message 524 Length 526 >=3 (EAP packet enclosed) 527 =2 (EAP-Start message) 529 String 531 The String field includes EAP packets, as defined in [1]. If mul- 532 tiple EAP-Message attributes are present in a packet their values 533 should be concatenated; this allows EAP packets longer than 253 534 octets to be passed by RADIUS. 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Code | Identifier | Length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 / / 541 / Data / 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 7. Security considerations 547 Since the purpose of EAP is to provide enhanced security for PPP 548 authentication, it is critical that RADIUS support for EAP be secure. 549 In particular, the following issues must be addressed: 551 Separation of the EAP server and PPP authenticator 552 Connection hijacking 553 Man in the middle attacks 554 Multiple databases 555 Negotiation attacks 557 7.1. Separation of the EAP server and PPP authenticator 559 As described in [8] and [9], it is possible for the EAP endpoints to 560 mutually authenticate, negotiate a ciphersuite, and derive a session 561 key for subsequent use in PPP encryption. 563 This does not present an issue on the peer, since the peer and EAP 564 client reside on the same machine; all that is required is for the EAP 565 client module to pass the session key to the PPP encryption module. 567 The situation may be more complex when EAP/RADIUS is used, since the 568 PPP authenticator will typically not reside on the same machine as the 569 EAP server. For example, the EAP server may be a backend security 570 server, or a module residing on the RADIUS server. 572 In the case where the EAP server and PPP authenticator reside on dif- 573 ferent machines, there are several implications for security. 574 Firstly, mutual authentication will occur between the peer and the EAP 575 server, not between the peer and the authenticator. This means that it 576 is not possible for the peer to validate the identity of the NAS or 577 tunnel server that it is speaking to. 579 As described earlier, when EAP/RADIUS is used to encapsulate EAP pack- 580 ets, the Signature attribute is required in EAP/RADIUS Access-Requests 581 sent from the NAS or tunnel server to the RADIUS server. Since the 582 Signature attribute involves a HMAC-MD5 hash, it is possible for the 583 RADIUS server to verify the integrity of the Access-Request as well as 584 the NAS or tunnel server's identity. Similarly, Access-Challenge pack- 585 ets sent from the RADIUS server to the NAS are also authenticated and 586 integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel 587 server to determine the integrity of the packet and verify the iden- 588 tity of the RADIUS server. Morever, EAP packets sent via the methods 589 described in [8] and [9] contain their own integrity protection, so 590 that they cannot be successfully modified by a rogue NAS or tunnel 591 server. 593 The second issue that arises in the case of an EAP server and PPP 594 authenticator residing on different machines is that the session key 595 negotiated between the peer and EAP server will need to be transmitted 596 to the authenticator. Therefore a mechanism needs to be provided to 597 transmit the session key from the EAP server to the authenticator or 598 tunnel server that needs to use the key. The specification of this 599 transit mechanism is outside the scope of this document. 601 7.2. Connection hijacking 603 In this form of attack, the attacker attempts to inject packets into 604 the conversation between the NAS and the RADIUS server, or between the 605 RADIUS server and the backend security server. RADIUS does not support 606 encryption, and as described in [2], only Access-Reply and Access- 607 Challenge packets are integrity protected. Moreover, the integrity 608 protection mechanism described in [2] is weaker than that likely to be 609 used by some EAP methods, making it possible to subvert those methods 610 by attacking EAP/RADIUS. 612 In order to provide for authentication of all packets in the EAP 613 exchange, all EAP/RADIUS packets MUST be authenticated using the Sig- 614 nature attribute, as described previously. 616 7.3. Man in the middle attacks 618 Since RADIUS security is based on shared secrets, end-to-end security 619 is not provided in the case where authentication or accounting packets 620 are forwarded along a proxy chain. As a result, attackers gaining 621 control of a RADIUS proxy will be able to modify EAP packets in tran- 622 sit without fear of detection. 624 This represents a weakness of RADIUS which cannot be remedied without 625 providing end-to-end data object security. 627 7.4. Multiple databases 629 In many cases a backend security server will be deployed along with a 630 RADIUS server in order to provide EAP services. Unless the backend 631 security server also functions as a RADIUS server, two separate user 632 databases will exist, each containing information about the security 633 requirements for the user. This represents a weakness, since security 634 may be compromised by a successful attack on either of the servers, or 635 their backend databases. With multiple user databases, adding a new 636 user may require multiple operations, increasing the chances for 637 error. The problems are further magnified in the case where user 638 information is also being kept in an LDAP server. In this case, three 639 stores of user information may exist. 641 In order to address these threats, consolidation of databases is rec- 642 ommended. This can be achieved by having both the RADIUS server and 643 backend security server store information in the same backend 644 database; by having the backend security server provide a full RADIUS 645 implementation; or by consolidating both the backend security server 646 and the RADIUS server onto the same machine. 648 7.5. Negotiation attacks 650 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 651 RADIUS server causes the authenticating peer to choose a less secure 652 authentication method so as to make it easier to obtain the user's 653 password. For example, a session that would normally be authenticated 654 with EAP would instead authenticated via CHAP or PAP; alternatively, a 655 connection that would normally be authenticated via one EAP type 656 occurs via a less secure EAP type, such as MD5. The threat posed by 657 rogue devices, once thought to be remote, has gained currency given 658 compromises of telephone company switching systems, such as those 659 described in [7]. 661 Protection against negotiation attacks requires the elimination of 662 downward negotiations. This can be achieved via implementation of per- 663 connection policy on the part of the authenticating peer, and per-user 664 policy on the part of the RADIUS server. 666 For the authenticating peer, authentication policy should be set on a 667 per-connection basis. Per-connection policy allows an authenticating 668 peer to negotiate EAP when calling one service, while negotiating CHAP 669 for another service, even if both services are accessible via the same 670 phone number. 672 With per-connection policy, an authenticating peer will only attempt 673 to negotiate EAP for a session in which EAP support is expected. As a 674 result, there is a presumption that an authenticating peer selecting 675 EAP requires that level of security. If it cannot be provided, it is 676 likely that there is some kind of misconfiguration, or even that the 677 authenticating peer is contacting the wrong server. Should the NAS not 678 be able to negotiate EAP, or should the EAP-Request sent by the NAS be 679 of a different EAP type than what is expected, the authenticating peer 680 MUST disconnect. An authenticating peer expecting EAP to be negotiated 681 for a session MUST NOT negotiate CHAP or PAP. 683 For a NAS, it may not be possible to determine whether a user is 684 required to authenticate with EAP until the user's identity is known. 686 For example, for shared-uses NASes it is possible for one reseller to 687 implement EAP while another does not. In such cases, if any users of 688 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 689 every call. This avoids forcing an EAP-capable client to do more than 690 one authentication, which weakens security. 692 If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Pass- 693 word attributes to the RADIUS Server in an Access-Request packet. If 694 the user is not required to use EAP, then the RADIUS Server will 695 respond with an Access-Accept or Access-Reject packet as appropriate. 696 However, if CHAP has been negotiated but EAP is required, the RADIUS 697 server MUST respond with an Access-Reject, rather than an Access-Chal- 698 lenge/EAP-Message/EAP-Request packet. The authenticating peer MUST 699 refuse to renegotiate authentication, even if the renegotiation is 700 from CHAP to EAP. 702 If EAP is negotiated but is not supported by the RADIUS proxy or 703 server, then the server or proxy MUST respond with an Access-Reject. 704 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 705 user. This is the correct behavior since the authenticating peer is 706 expecting EAP to be negotiated, and that expectation cannot be ful- 707 filled. An EAP-capable authenticating peer MUST refuse to renegotiate 708 the authentication protocol if EAP had initially been negotiated. 709 Note that problems with a non-EAP capable RADIUS proxy could prove 710 difficult to diagnose, since a user dialing in from one location (with 711 an EAP-capable proxy) might be able to successfully authenticate via 712 EAP, while the same user dialing into another location (and encounter- 713 ing an EAP-incapable proxy) might be consistently disconnected. 715 8. Acknowledgments 717 Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren- 718 dra Gidwani of Microsoft for useful discussions of this problem space. 720 9. References 722 [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 723 Protocol (EAP)." Work in progress, draft-ietf-pppext-eap-auth-03.txt, 724 Merit Network, Inc., June, 1996. 726 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 727 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 728 Daydreamer, January, 1997. 730 [3] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 731 1997. 733 [4] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 734 draft-ietf-radius-ext-01.txt, Livingston, June, 1997. 736 [5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC 737 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 738 April 1992. 740 [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement 741 Levels." RFC 2119, Harvard University, March, 1997. 743 [7] M. Slatalla, J. Quittner. "Masters of Deception." HarperCollins, 744 New York, 1995. 746 [8] B. Aboba, D. Simon. "PPP EAP TLS Authentication Protocol." Work 747 in progress, draft-ietf-pppext-eaptls-02.txt, Microsoft, October 1997. 749 [9] G. Carter. "PPP EAP ISAKMP Authentication Protocol." Work in 750 progress, draft-ietf-pppext-eapisakmp-00.txt, Entrust, November 1997. 752 10. Authors' Addresses 754 Pat R. Calhoun 755 Technology Development 756 Sun Microsystems, Inc. 757 15 Network Circle 758 Menlo Park, CA 94025 760 Phone: 847-548-0926 761 Fax: 650-786-6445 762 EMail: pcalhoun@toast.net 764 Allan C. Rubens 765 Merit Network, Inc. 766 4251 Plymouth Rd. 767 Ann Arbor, MI 48105-2785 769 Phone: 313-647-0417 770 EMail: acr@merit.edu 772 Bernard Aboba 773 Microsoft Corporation 774 One Microsoft Way 775 Redmond, WA 98052 777 Phone: 425-936-6605 778 EMail: bernarda@microsoft.com 779 -