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