idnits 2.17.1 draft-aboba-radius-rfc2869bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages 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.) ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC2869, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 238 has weird spacing: '...eer and authe...' == Line 352 has weird spacing: '...e final authe...' == Line 438 has weird spacing: '...between secur...' == Line 441 has weird spacing: '...ors and secur...' == Line 445 has weird spacing: '...pecific code ...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 February 2003) is 7748 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 777 -- Looks like a reference, but probably isn't: '2' on line 780 -- Looks like a reference, but probably isn't: '3' on line 783 == Missing Reference: 'RFC2869' is mentioned on line 735, but not defined == Missing Reference: 'Note 1' is mentioned on line 753, but not defined == Missing Reference: 'RFC2607' is mentioned on line 774, but not defined -- Looks like a reference, but probably isn't: '4' on line 786 -- Looks like a reference, but probably isn't: '5' on line 789 -- Looks like a reference, but probably isn't: '6' on line 792 -- Looks like a reference, but probably isn't: '7' on line 794 -- Looks like a reference, but probably isn't: '8' on line 798 -- Looks like a reference, but probably isn't: '9' on line 802 -- Looks like a reference, but probably isn't: '10' on line 805 == Missing Reference: 'RFC1321' is mentioned on line 992, but not defined == Unused Reference: 'RFC2486' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'MD5Attack' is defined on line 1286, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Informational P. Calhoun 5 Black Storm Networks 6 9 February 2003 7 Updates: RFC 2869 9 RADIUS Support For Extensible Authentication Protocol (EAP) 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working 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 material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 This document defines RADIUS support for the Extensible Authentication 36 Protocol (EAP), an authentication framework which supports multiple 37 authentication mechanisms. While EAP was originally developed for use 38 with PPP, it is also now in use with IEEE 802. 40 This document updates RFC 2869. 42 Table of Contents 44 1. Introduction .......................................... 3 45 1.1 Specification of Requirements ................... 3 46 1.2 Terminology ..................................... 4 47 2. RADIUS support for EAP ................................ 5 48 2.1 Protocol overview ............................... 5 49 2.2 Role reversal ................................... 9 50 2.3 Retransmission .................................. 9 51 2.4 Fragmentation ................................... 9 52 2.5 Invalid packet .................................. 10 53 2.6 Alternative uses ................................ 10 54 2.7 Usage guidelines ................................ 11 55 3. Attributes ............................................ 13 56 3.1 EAP-Message ..................................... 13 57 3.2 Message-Authenticator ........................... 15 58 3.3 Table of attributes ............................. 16 59 4. Security considerations ............................... 17 60 4.1 Security requirements ........................... 17 61 4.2 Security protocol ............................... 18 62 4.3 Security issues ................................ 20 63 5. Normative references .................................. 27 64 6. Informative references ................................ 27 65 Appendix A - Examples ........................................ 29 66 Appendix B - Change log ...................................... 37 67 ACKNOWLEDGMENTS .............................................. 38 68 AUTHORS' ADDRESSES ........................................... 38 69 Intellectual property statement .............................. 38 70 Full Copyright Statement ..................................... 39 71 1. Introduction 73 The Remote Authentication Dial In User Service (RADIUS) is an 74 authentication, authorization and accounting protocol used to control 75 network access. RADIUS authentication and authorization is specified in 76 [RFC2865], and RADIUS accounting is specified in [RFC2866]. 78 The Extensible Authentication Protocol (EAP), defined in [RFC2284], is 79 an authentication framework which supports multiple authentication 80 mechanisms. EAP may be used on dedicated links as well as switched 81 circuits, and wired as well as wireless links. 83 To date, EAP has been implemented with hosts and routers that connect 84 via switched circuits or dial-up lines using PPP [RFC1661]. It has also 85 been implemented with switches supporting [IEEE802]. EAP encapsulation 86 on IEEE 802 wired media is described in [IEEE8021X]. 88 This specification describes RADIUS attributes supporting the Extensible 89 Authentication Protocol (EAP): EAP-Message and Message-Authenticator. 90 These attributes now have extensive field experience, and so the purpose 91 of this document is to provide clarification and resolve 92 interoperability issues. 94 As noted in [RFC2865], a Network Access Server (NAS) that does not 95 implement a given service MUST NOT implement the RADIUS attributes for 96 that service. This implies that a NAS that is unable to offer EAP 97 service MUST NOT implement the RADIUS attributes for EAP. A NAS MUST 98 treat a RADIUS Access-Accept requesting an unavailable service as an 99 Access-Reject instead. 101 All attributes are comprised of variable length Type-Length-Value 3- 102 tuples. New attribute values can be added without disturbing existing 103 implementations of the protocol. 105 1.1. Specification of Requirements 107 In this document, several words are used to signify the requirements of 108 the specification. These words are often capitalized. The key words 109 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 110 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 111 interpreted as described in [RFC2119]. 113 1.2. Terminology 115 This document frequently uses the following terms: 117 authenticator 118 The end of the link requiring the authentication. 120 peer The other end of the point-to-point link (PPP), point-to-point 121 LAN segment (IEEE 802.1X) or wireless link, which being 122 authenticated by the authenticator. In IEEE 802.1X, this end 123 is known as the Supplicant. Throughout this specification, the 124 term "user" is used synonymously with peer. 126 authentication server 127 An authentication server is an entity that provides an 128 authentication service to an authenticator. This service 129 verifies from the credentials provided by the peer, the claim 130 of identity made by the peer. 132 Port Access Entity (PAE) 133 The protocol entity associated with a physical or virtual 134 Port. A given PAE may support the protocol functionality 135 associated with the authenticator, peer or both. 137 Silently Discard 138 This means the implementation discards the packet without 139 further processing. The implementation SHOULD provide the 140 capability of logging the error, including the contents of the 141 silently discarded packet, and SHOULD record the event in a 142 statistics counter. 144 Displayable Message 145 This is interpreted to be a human readable string of 146 characters, and MUST NOT affect operation of the protocol. 147 The message encoding MUST follow the UTF-8 transformation 148 format [RFC2279]. 150 Network Access Server (NAS) 151 The device providing access to the network. 153 Service The NAS provides a service to the user, such as IEEE 802 or 154 PPP. 156 Session Each service provided by the NAS to a peer constitutes a 157 session, with the beginning of the session defined as the 158 point where service is first provided and the end of the 159 session defined as the point where service is ended. A peer 160 may have multiple sessions in parallel or series if the NAS 161 supports that, with each session generating a separate start 162 and stop accounting record. 164 2. RADIUS Support for EAP 166 The Extensible Authentication Protocol (EAP), described in [RFC2284], 167 provides a standard mechanism for support of additional authentication 168 methods without requiring additional functionality on the NAS. Through 169 the use of EAP, support for a number of authentication schemes may be 170 added, including smart cards, Kerberos [RFC1510], Public Key [RFC2716], 171 One Time Passwords [RFC2284], and others. 173 One of the advantages of the EAP architecture is its flexibility. EAP 174 is used to select a specific authentication mechanism. Rather than 175 requiring the NAS to be updated to support each new authentication 176 method, EAP permits the use of an authentication server which may 177 implement some or all authentication methods, with the NAS acting as a 178 pass-through for some or all methods and peers. 180 A NAS MAY authenticate local users while at the same time acting as a 181 pass-through for non-local users and authentication methods it does not 182 implement locally. This means that a NAS implementing RADIUS/EAP is not 183 required to use RADIUS to authenticate every peer. However, once the NAS 184 begins acting as a pass-through for a particular session, it can no 185 longer perform local authentication for that session. 187 In order to support EAP within RADIUS, two new attributes, EAP-Message 188 and Message-Authenticator, are introduced in this document. This section 189 describes how these new attributes may be used for providing EAP support 190 within RADIUS. 192 2.1. Protocol Overview 194 In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP Packets 195 between the NAS and an authentication server. 197 The authenticating peer and the NAS begin the EAP conversation by 198 negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD 199 send an initial EAP-Request message to the authenticating peer. This 200 will typically be an EAP-Request/Identity, although an EAP-Request for 201 an authentication method (Types 4 and greater) is possible. For example, 202 a NAS might be configured to initiate with a default authentication 203 method. This could be useful in cases where the identity is determined 204 by another means (such as the Called-Station-Id or Calling-Station-Id), 205 a single authentication method is required (so that the identity is not 206 needed to determine the method), or where identity hiding is desired, so 207 that the identity is not requested until after a protected channel has 208 been set up. 210 The peer replies with an EAP-Response. The NAS MAY determine from the 211 Response that it should proceed with local authentication. 212 Alternatively, it MAY act as a pass-through, encapsulating the EAP- 213 Response within EAP-Message attribute(s) within a RADIUS Access-Request 214 packet, sent to the RADIUS server. 216 For example, if an EAP-Request/Identity message is sent by the NAS as 217 the first packet, the peer responds with an EAP-Response/Identity. The 218 NAS may determine that the user is local and proceed with local 219 authentication. If no match is found against the list of local users, 220 the NAS encapsulates the EAP-Response/Identity message within EAP- 221 Message attribute(s), enclosed within an Access-Request sent to the 222 RADIUS server. 224 On receiving a valid Access-Request packet containing EAP-Message 225 attribute(s), a RADIUS server supporting and wishing to authenticate 226 with EAP MUST respond with an Access-Challenge packet containing EAP- 227 Message attribute(s). If the RADIUS server does not support EAP or does 228 not wish to authenticate with EAP, it MUST respond with an Access- 229 Reject. The EAP-Message attribute(s) encapsulate a single EAP packet 230 which the NAS decapsulates and passes on to the authenticating peer. 231 The conversation continues until either a RADIUS Access-Reject or 232 Access-Accept packet is received from the RADIUS server. Reception of a 233 RADIUS Access-Reject packet MUST result in the NAS denying access to the 234 authenticating peer. A RADIUS Access-Accept packet successfully ends 235 the authentication phase. 237 Using RADIUS, the NAS can act as a pass-through for an EAP conversation 238 between the peer and authentication server, without needing to 239 implement the EAP method used between them. Where the NAS initiates the 240 conversation by sending an EAP-Request for an authentication method, it 241 may not be required that the NAS fully implement the EAP method sent in 242 the first packet. Depending on the initial method, it may be sufficient 243 for the NAS to be configured with the initial packet to be sent to the 244 peer, and for the NAS to act as a pass-through for subsequent messages. 245 However, this only works well for methods where the initial Request is 246 largely static; otherwise the NAS will need to fully implement the 247 method so as to be able to authenticate the user locally. 249 Where an initial EAP-Request for an authentication Type (4 or greater) 250 is sent by the NAS, the peer may respond with a Nak indicating that it 251 would prefer another authentication method that is not implemented 252 locally. In this case, Access-Request sent by the NAS MAY include an 253 EAP-message attribute encapsulating the received EAP-Response/Nak. This 254 provides the RADIUS server with a hint about the authentication 255 method(s) preferred by the peer, although it does not provide 256 information on the Type of the original Request. In order to evaluate 257 whether the alternatives preferred by the peer are allowed, the RADIUS 258 server will typically need to determine the peer identity, so as to be 259 able to retrieve the associated authentication policy. 261 In order to permit non-EAP aware RADIUS proxies to forward the Access- 262 Request packet, if the NAS initially sends an EAP-Request/Identity 263 message to the peer, the NAS MUST copy the contents of the Type-Data 264 field of the EAP-Response/Identity received from the peer into the User- 265 Name attribute and MUST include the Type-Data field of the EAP- 266 Response/Identity in the User-Name attribute in every subsequent Access- 267 Request. Since RADIUS proxies are assumed to act as a pass-through, they 268 cannot be expected to parse an EAP-Response/Identity encapsulated within 269 EAP-Message attribute(s). 271 The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in 272 the Access-Request packet, and either NAS-Identifier or NAS-IP-Address 273 attributes MUST be included. In order to permit forwarding of the 274 Access-Reply by EAP-unaware proxies, if a User-Name attribute was 275 included in an Access-Request, the RADIUS server MUST include the User- 276 Name attribute in subsequent Access-Challenge, Access-Accept or Access- 277 Reject packets. Without the User-Name attribute, accounting and billing 278 becomes difficult to manage. If the identity is determined by another 279 means, such as the Calling-Station-Id, the NAS MUST include these 280 identifying attributes in every Access-Request, and the RADIUS server 281 MUST copy these identifying attributes into subsequent Access-Challenge, 282 Access-Accept or Access-Reject packets. 284 Having the NAS send the initial EAP-Request packet has a number of 285 advantages: 287 [1] It saves a round trip between the NAS and RADIUS server. 289 [2] An Access-Request is only sent to the RADIUS server if the 290 authenticating peer sends an EAP-Response, confirming that it 291 supports EAP. In situations where peers may be EAP unaware (such as 292 in the case of a switch implementing [IEEE8021X], where there are 293 IEEE 802.1X-unaware hosts), initiating a RADIUS Access-Request on a 294 "carrier sense" or "media up" indication may initiate many 295 authentication exchanges that cannot complete successfully. 297 [3] It allows some users to be authenticated locally. 299 Although having the NAS send the initial EAP-Request packet has 300 substantial advantages, this technique cannot be universally employed. 301 There are circumstances in which the user's identity is already known 302 (such as when authentication and accounting is handled based on Called- 303 Station-Id or Calling-Station-Id), but where the appropriate EAP method 304 may vary based on that identity. 306 Rather than sending an initial EAP-Request packet to the authenticating 307 peer, on detecting the presence of the peer, the NAS MAY send an Access- 308 Request packet to the RADIUS server containing an EAP-Message attribute 309 signifying EAP-Start. The NAS also MAY send an Access-Request packet 310 containing an EAP-Start if, after sending an initial Request for an 311 authentication Type, the peer responds with a Nak. This allows the 312 RADIUS server to take over the task of negotiating a more suitable 313 method. Typically the RADIUS server will respond with an Access- 314 Challenge containing an EAP-Message attribute with an encapsulated EAP- 315 Request/Identity. On receiving an Access-Request containing an 316 encapsulated EAP-Response/Identity, the RADIUS server can retrieve the 317 authentication policy for the peer, in order to choose a suitable 318 method. However, because the RADIUS server is not provided with the 319 contents of the EAP-Response/Nak, it is possible for the RADIUS server 320 to choose an unacceptable method, and for the peer to respond with 321 another Nak. 323 EAP-Start is indicated by sending an EAP-Message attribute with a length 324 of 2 (no data). The Calling-Station-Id SHOULD be included in the User- 325 Name attribute. This results in a RADIUS Access-Request being sent by 326 the NAS to the RADIUS server without first confirming that the peer 327 supports EAP. Since this technique can result in a a large number of 328 uncompleted RADIUS conversations, in situations where EAP unaware peers 329 are common, it SHOULD NOT be employed by default. EAP-Message 330 attributes containing EAP-Start and an EAP-Response/Nak packets MUST NOT 331 be sent together within the same Access-Request. 333 Where the NAS initiates the RADIUS exchange by sending an Access-Request 334 to the server containing an EAP-Start, the Access-Challenge sent by the 335 RADIUS server will typically contain EAP-Message attribute(s) 336 encapsulating an EAP-Request/Identity packet, requesting the peer to 337 identify itself. However, an Access-Challenge containing an EAP-Message 338 attribute encapsulating an EAP-Request for an authentication method 339 (Type 4 or greater) MAY also be sent. The NAS will decapsulate the EAP 340 packet contained within the EAP-Message attribute, send it to the peer, 341 and receive an EAP-Response packet from the peer in return. The NAS will 342 then send a RADIUS Access-Request packet to the RADIUS server, 343 containing EAP-Message attribute(s) encapsulating the EAP-Response 344 packet. 346 For proxied RADIUS requests, there are two methods of processing. If 347 the domain is determined based on the Calling-Station-Id and Called- 348 Station-Id, the RADIUS Server may proxy the initial RADIUS Access- 349 Request/EAP-Start. If the domain is determined based on the user's 350 identity, the local RADIUS Server MUST respond with a RADIUS Access- 351 Challenge/EAP-Identity packet. The response from the authenticating 352 peer MUST be proxied to the final authentication server. 354 For proxied RADIUS requests, the NAS may receive an Access-Reject packet 355 in response to the initial Access-Request packet. This would occur if 356 the message was proxied to a RADIUS server which does not support the 357 EAP-Message attribute. On receiving an Access-Reject, the NAS MUST deny 358 access to the authenticating peer. 360 2.2. Role reversal 362 Since EAP is a peer-to-peer protocol, an independent and simultaneous 363 authentication may take place in the reverse direction. Both peers may 364 act as authenticators and authenticatees at the same time. 366 However, role reversal is not supported by this specification. A RADIUS 367 server MUST respond to an Access-Request encapsulating an EAP-Request 368 with an Access-Reject. In order to avoid retransmissions by the peer, 369 the Access-Reject MAY include an EAP-Response/Nak packet indicating no 370 preferred method, encapsulated within EAP-Message attribute(s). 372 2.3. Retransmission 374 As noted in [RFC2284], the EAP authenticator (NAS) is responsible for 375 retransmission of packets between the authenticating peer and the NAS. 376 If an EAP packet is lost in transit between the authenticating peer and 377 the NAS (or vice versa), the NAS will retransmit. As in RADIUS 378 [RFC2865], the RADIUS client is responsible for retransmission of 379 packets between the RADIUS client and the RADIUS server. 381 It may be necessary to adjust retransmission strategies and 382 authentication timeouts in certain cases. For example, when a token card 383 is used additional time may be required to allow the user to find the 384 card and enter the token. Since the NAS will typically not have 385 knowledge of the required parameters, these need to be provided by the 386 RADIUS server. This can be accomplished by inclusion of Session-Timeout 387 attribute within the Access-Challenge packet. 389 If Session-Timeout is present in an Access-Challenge packet that also 390 contains an EAP-Message, the value of the Session-Timeout is used to set 391 the EAP retransmission timer for that EAP Request, and that Request 392 alone. Once the EAP-Request has been sent, the NAS sets the 393 retransmission timer, and if it expires without having received an EAP- 394 Response corresponding to the Request, then the EAP-Request is 395 retransmitted. 397 2.4. Fragmentation 399 Using the EAP-Message attribute, it is possible for the RADIUS server to 400 encapsulate an EAP packet that is larger than the MTU on the link 401 between the NAS and the peer. Since it is not possible for the RADIUS 402 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 403 attribute may be included in an Access-Request packet containing an EAP- 404 Message attribute so as to provide the RADIUS server with this 405 information. 407 2.5. Invalid packets 409 EAP methods may contain a per-packet Message Integrity Check (MIC). 410 Although EAP methods such as EAP-TLS [RFC2716] treat MIC check failures 411 as fatal errors, it may be desirable for an EAP method to silently 412 discard an invalid EAP packet, and subsequently continue the 413 conversation. This provides additional resilience against Denial of 414 Service (DoS) attacks. 416 When a RADIUS server receives an Access-Request containing an EAP- 417 Message attribute encapsulating an invalid EAP packet, it SHOULD NOT 418 silently discard the Access-Request without informing the NAS. This 419 would cause the NAS to retransmit the Access-Request, then eventually 420 time-out and initiate failover. As a result, it is best for the RADIUS 421 server to formulate a response of some kind. 423 If the error is considered fatal, an Access-Reject can be sent. In 424 order for the RADIUS server to communicate that an invalid EAP packet 425 has been received, but that the problem is non-fatal, an Access- 426 Challenge containing an EAP-Start MAY be sent. A NAS receiving an 427 Access-Challenge with an EAP-Start MUST discard the EAP packet that it 428 had previously encapsulated within an Access-Request. It will then check 429 whether it has received additional EAP Response packets with an 430 Identifier matching that of the last Request. If so, a new EAP Response 431 packet will be sent to the RADIUS server within an Access-Request 432 packet. Once the RADIUS server responds with a packet containing a non- 433 null EAP-Message attribute, the NAS updates the Identifier value, and 434 any pending Responses that do not match this value can be discarded. 436 2.6. Alternative uses 438 Currently the conversation between security servers and the RADIUS 439 server is often proprietary because of lack of standardization. In 440 order to increase standardization and provide interoperability between 441 RADIUS vendors and security vendors, it is recommended that RADIUS- 442 encapsulated EAP be used for this conversation. 444 This has the advantage of allowing the RADIUS server to support EAP 445 without the need for authentication-specific code within the RADIUS 446 server. Authentication-specific code can then reside on a security 447 server instead. 449 In the case where RADIUS-encapsulated EAP is used in a conversation 450 between a RADIUS server and a security server, the security server will 451 typically return an Access-Accept message without inclusion of the 452 expected attributes currently returned in an Access-Accept. This means 453 that the RADIUS server MUST add these attributes prior to sending an 454 Access-Accept message to the NAS. 456 2.7. Usage guidelines 458 2.7.1. Conflicting messages 460 Within an EAP conversation, a RADIUS Access-Accept will typically 461 contain an EAP-Message attribute encapsulating an EAP Success packet. 462 Similarly, a RADIUS Access-Reject will typically contain an EAP-Message 463 attribute encapsulating an EAP Failure packet. However, in some cases, 464 the authentication result implied by the encapsulated EAP packet may not 465 match the result communicated in the RADIUS message. For example, an EAP 466 Failure packet may be encapsulated within an Access-Accept message and 467 an EAP Success packet may be encapsulated within an Access-Reject. 468 Alternatively, an EAP-Message attribute may not be included within a 469 RADIUS Access-Accept or Access-Reject. 471 Such combinations are likely to cause confusion, because the NAS and 472 peer will arrive at different conclusions as to the outcome of the 473 authentication. For example, if the NAS receives an Access-Reject with 474 an encapsulated EAP Success, it will not grant access to the peer. 475 However, on receiving the Success, the peer will be lead to believe that 476 it authenticated successfully. 478 Similarly, if the NAS receives an Access-Accept with an encapsulated EAP 479 Failure, it will grant access to the peer. However, on receiving an EAP 480 Failure, the peer will be lead to believe that it failed authentication. 481 If no EAP-Message attribute is included within an Access-Accept or 482 Access-Reject, then the peer may not be informed as to the outcome of 483 the authentication, while the NAS will take action to allow or deny 484 access. 486 As described in [RFC2284], the EAP Success and Failure packets are not 487 acknowledged, and these packets terminate the EAP conversation. As a 488 result, if these packets are encapsulated within an Access-Challenge, no 489 response will be received, and therefore no further Access-Requests will 490 be sent to the RADIUS server. As a result, the NAS will not be given an 491 indication of whether to allow or deny access while the peer will be 492 informed as to the outcome of the authentication. 494 To avoid these conflicts, the RADIUS server SHOULD check for agreement 495 between the EAP-Message attribute and the RADIUS message, and SHOULD 496 resolve conflicts before sending the packet. The following combinations 497 SHOULD NOT be sent by a RADIUS server as part of an EAP conversation: 499 Access-Accept/EAP-Message/EAP Failure 500 Access-Accept/no EAP-Message attribute 501 Access-Reject/EAP-Message/EAP Success 502 Access-Reject/no EAP-Message attribute 503 Access-Challenge/EAP-Message/EAP Success 504 Access-Challenge/EAP-Message/EAP Failure 505 Access-Challenge/no EAP-Message attribute 507 Since the responsibility for avoiding these conflicts lies with the 508 RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to 509 correct contradictory messages that it receives. This behavior, 510 originally mandated within [IEEE8021X], is likely to be deprecated. 512 2.7.2. Priority 514 In addition to containing EAP-Message attributes, RADIUS messages may 515 also contain other attributes. In order to ensure the correct processing 516 of RADIUS messages, on receiving an Access-Accept, Access-Reject or 517 Access-Challenge, the NAS SHOULD process other attributes first, then 518 decapsulate EAP-Message attribute(s), reconstitute the EAP packet and 519 send it to the peer. 521 2.7.3. Displayable messages 523 The Reply-Message attribute, defined in section 5.18 of [RFC2865], 524 indicates text which may be displayed to the user. This is similar in 525 concept to EAP Notification, defined in [RFC2284]. When sending a 526 displayable message to a NAS during an EAP conversation, the RADIUS 527 server MUST encapsulate displayable messages within EAP-Message/EAP- 528 Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT 529 be included in any RADIUS message containing an EAP-Message attribute. 530 An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an 531 Access-Accept or Access-Reject packet. 533 In some existing implementations, a NAS receiving Reply-Message 534 attribute(s) copies the Text field(s) into the Type-Data field of an 535 EAP-Request/Notification packet, fills in the Identifier field, and 536 sends this to the peer. However, several issues arise from this: 538 [1] Unexpected Responses. On receiving an EAP-Request/Notification, the 539 peer will send an EAP-Response/Notification, and the NAS will pass 540 this on to the RADIUS server, encapsulated within EAP-Message 541 attribute(s). However, the RADIUS server may not be expecting an 542 Access-Request containing an EAP-Message/EAP-Response/Notification 543 attribute. 545 For example, consider what happens when a Reply-Message is included 546 within an Access-Accept or Access-Reject packet with no EAP-Message 547 attribute(s) present. If the value of the Reply-Message attribute 548 is copied into the Type-Data of an EAP-Request/Notification and 549 sent to the peer, this will result in an Access-Request containing 550 an EAP-Message/EAP-Response/Notification attribute being sent by 551 the NAS to the RADIUS server. Since an Access-Accept or Access- 552 Reject packet terminates the RADIUS conversation, such an Access- 553 Request would not be expected, and could be interpreted as the 554 start of another conversation. 556 [2] Identifier conflicts. While the EAP-Request/Notification is an EAP 557 packet containing an Identifier field, the Reply-Message attribute 558 does not contain an Identifier field. As a result, a NAS receiving 559 a Reply-Message attribute and wishing to translate this to an EAP- 560 Request/Notification will need to choose an Identifier value. It is 561 possible that the chosen Identifier value will conflict with a 562 value chosen by the RADIUS server for another packet within the EAP 563 conversation, potentially causing confusion between a new packet 564 and a retransmission. 566 In order to avoid these problems, a NAS in pass-through mode receiving a 567 Reply-Message attribute from the RADIUS server SHOULD silently discard 568 the attribute. 570 2.7.4. Multiple EAP-Message attributes 572 When RADIUS is used to enable EAP authentication, Access-Request, 573 Access-Challenge, Access-Accept, and Access-Reject packets SHOULD 574 contain one or more EAP-Message attributes. Where more than one EAP- 575 Message attribute is included, it is assumed that the attributes are to 576 be concatenated to form a single EAP packet. As a result, multiple EAP 577 packets MUST NOT be encoded within EAP-Message attributes contained 578 within a single Access-Challenge, Access-Accept, Access-Reject or 579 Access-Request packet. 581 3. Attributes 583 3.1. EAP-Message 585 Description 587 This attribute encapsulates EAP [RFC2284] packets so as to allow the 588 NAS to authenticate users via EAP without having to understand the 589 EAP method it is passing through. 591 The NAS places any EAP messages received from the user into one or 592 more EAP-Message attributes and forwards them to the RADIUS server as 593 part of the Access-Request, which can return EAP messages in Access- 594 Challenge, Access-Accept and Access-Reject packets. 596 The NAS places EAP messages received from the authenticating peer 597 into one or more EAP-Message attributes and forwards them to the 598 RADIUS server within an Access-Request message. If multiple EAP- 599 Messages are contained within an Access-Request or Access- Challenge 600 packet, they MUST be in order and they MUST be consecutive attributes 601 in the Access-Request or Access-Challenge packet. 603 It is expected that EAP will be used to implement a variety of 604 authentication methods, including methods involving strong 605 cryptography. In order to prevent attackers from subverting EAP by 606 attacking RADIUS/EAP, (for example, by modifying the EAP-Success or 607 EAP-Failure packets) it is necessary that RADIUS/EAP provide 608 integrity protection. 610 Therefore the Message-Authenticator attribute MUST be used to protect 611 all Access-Request, Access-Challenge, Access-Accept, and Access- 612 Reject packets containing an EAP-Message attribute. 614 Access-Request packets including EAP-Message attribute(s) without a 615 Message-Authenticator attribute SHOULD be silently discarded by the 616 RADIUS server. A RADIUS server supporting the EAP-Message attribute 617 MUST calculate the correct value of the Message-Authenticator and 618 silently discard the packet if it does not match the value sent. A 619 RADIUS server not supporting the EAP-Message attribute MUST return an 620 Access-Reject if it receives an Access-Request containing an EAP- 621 Message attribute. A RADIUS server receiving an EAP-Message attribute 622 that it does not understand MUST return an Access-Reject. 624 Access-Challenge, Access-Accept, or Access-Reject packets including 625 EAP-Message attribute(s) without a Message-Authenticator attribute 626 SHOULD be silently discarded by the NAS. A NAS supporting the EAP- 627 Message attribute MUST calculate the correct value of the Message- 628 Authenticator and silently discard the packet if it does not match 629 the value sent. 631 A summary of the EAP-Message attribute format is shown below. The 632 fields are transmitted from left to right. 634 0 1 2 635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | String... 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Type 641 79 for EAP-Message. 643 Length 645 >= 3 647 String 649 The String field contains EAP packets, as defined in [RFC2284]. If 650 multiple EAP-Message attributes are present in a packet their values 651 should be concatenated; this allows EAP packets longer than 253 652 octets to be transported by RADIUS. 654 3.2. Message-Authenticator 656 Description 658 This attribute MAY be used to authenticate and integrity-protect 659 Access-Requests in order to prevent spoofing. It MAY be used in any 660 Access-Request. It MUST be used in any Access-Request, Access- 661 Accept, Access-Reject or Access-Challenge that includes an EAP- 662 Message attribute. 664 A RADIUS server receiving an Access-Request with a Message- 665 Authenticator Attribute present MUST calculate the correct value of 666 the Message-Authenticator and silently discard the packet if it does 667 not match the value sent. 669 A RADIUS Client receiving an Access-Accept, Access-Reject or Access- 670 Challenge with a Message-Authenticator Attribute present MUST 671 calculate the correct value of the Message-Authenticator and silently 672 discard the packet if it does not match the value sent. 674 A summary of the Message-Authenticator attribute format is shown 675 below. The fields are transmitted from left to right. 677 0 1 2 678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Type | Length | String... 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Type 685 80 for Message-Authenticator 687 Length 688 18 690 String 692 When present in an Access-Request packet, Message-Authenticator is an 693 HMAC-MD5 [RFC2104] hash of the entire Access-Request packet, 694 including Type, ID, Length and authenticator, using the shared secret 695 as the key, as follows. 697 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request 698 Authenticator, Attributes) 700 When the message integrity check is calculated the signature string 701 should be considered to be sixteen octets of zero. 703 For Access-Challenge, Access-Accept, and Access-Reject packets, the 704 Message-Authenticator is calculated as follows, using the Request- 705 authenticator from the Access-Request this packet is in reply to: 707 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request 708 Authenticator, Attributes) 710 When the message integrity check is calculated the signature string 711 should be considered to be sixteen octets of zero. The shared secret 712 is used as the key for the HMAC-MD5 message integrity check. The is 713 calculated and inserted in the packet before the Response 714 authenticator is calculated. 716 This attribute is not needed if the User-Password attribute is 717 present, but is useful for preventing attacks on other types of 718 authentication. This attribute is intended to thwart attempts by an 719 attacker to setup a "rogue" NAS, and perform online dictionary 720 attacks against the RADIUS server. It does not afford protection 721 against "offline" attacks where the attacker intercepts packets 722 containing (for example) CHAP challenge and response, and performs a 723 dictionary attack against those packets offline. 725 3.3. Table of Attributes 727 The following table provides a guide to which attributes may be found in 728 which kind of packets. The EAP-Message and Message-Authenticator 729 attributes specified in this document MUST NOT be present in an 730 Accounting-Request. 732 The following table provides a guide to which attributes may be found in 733 packets sent as part of an EAP conversation, and in what quantity. If a 734 table entry is omitted, the values found in [RFC2548], 735 [RFC2865]-[RFC2869] and [RFC3162] should be assumed. 737 Request Accept Reject Challenge # Attribute 738 0-1 0-1 0 0 1 User-Name 739 0 0 0 0 2 User-Password [Note 1] 740 0 0 0 0 3 CHAP-Password [Note 1] 741 0 0 0 0 18 Reply-Message 742 0-1 0-1 0 0-1 24 State 743 0 0+ 0 0 25 Class 744 0 0-1 0 0-1 27 Session-Timeout 745 0+ 0+ 0+ 0+ 33 Proxy-State 746 0 0 0 0 60 CHAP-Challenge 747 0-1 0 0 0 70 ARAP-Password [Note 1] 748 0 0 0 0 75 Password-Retry 749 1+ 1+ 1+ 1+ 79 EAP-Message [Note 1] 750 1 1 1 1 80 Message-Authenticator [Note 1] 751 Request Accept Reject Challenge # Attribute 753 [Note 1] An Access-Request that contains either a User-Password or CHAP- 754 Password or ARAP-Password or one or more EAP-Message attributes MUST NOT 755 contain more than one type of those four attributes. If it does not 756 contain any of those four attributes, it SHOULD contain a Message- 757 Authenticator. If any packet type contains an EAP-Message attribute it 758 MUST also contain a Message-Authenticator. 760 The following table defines the meaning of the above table entries. 762 0 This attribute MUST NOT be present. 763 0+ Zero or more instances of this attribute MAY be present. 764 0-1 Zero or one instance of this attribute MAY be present. 765 1 Exactly one instance of this attribute MUST be present. 766 1+ One or more of these attributes MUST be present. 768 4. Security Considerations 770 4.1. Security requirements 772 RADIUS/EAP is used in order to provide authentication and authorization 773 for network access. As a result, both the RADIUS and EAP portions of the 774 conversation are open to attack. Threats are discussed in [RFC2607], 775 [RFC2865], and [RFC3162]. Examples include: 777 [1] An adversary may attempt to acquire confidential data and 778 identities by snooping RADIUS packets. 780 [2] An adversary may attempt to modify packets containing RADIUS 781 messages. 783 [3] An adversary may attempt to inject packets into a RADIUS 784 conversation. 786 [4] An adversary may launch a dictionary attack against 787 the RADIUS shared secret. 789 [5] An adversary may launch a known plaintext attack, hoping to 790 recover the key stream corresponding to a Request Authenticator. 792 [6] An adversary may attempt to replay a RADIUS exchange. 794 [7] An adversary may attempt to disrupt the EAP negotiation, 795 in order to weaken the authentication, or gain access to user 796 passwords. 798 [8] An authenticated NAS may attempt to forge attributes, 799 including NAS-IP-Address, NAS-Identifier, Called-Station-Id, 800 or Calling-Station-Id. 802 [9] A rogue (unauthenticated) NAS may attempt to impersonate a 803 legitimate NAS. 805 [10] An attacker may attempt to act as a man-in-the-middle. 807 To address these threats, it is necessary to support confidentiality, 808 data origin authentication, integrity, and replay protection on a per- 809 packet basis. Bi-directional authentication between the RADIUS client 810 and server also needs to be provided. There is no requirement that the 811 identities of RADIUS clients and servers be kept confidential (e.g., 812 from a passive eavesdropper). 814 4.2. Security protocol 816 To address the security threats for RADIUS/EAP, in addition to 817 supporting RADIUS security as defined in [RFC2865] and [RFC2866], 818 RADIUS/EAP implementations SHOULD support IPsec [RFC2401] along with IKE 819 [RFC2409] for key management. IPsec ESP [RFC2406] with non-null 820 transform, and per-packet authentication, integrity and replay 821 protection SHOULD be used, along with IKE for key management. 823 Within RADIUS [RFC2865], a shared secret is used for hiding of 824 attributes such as User-Password, as well as in computation of the 825 Response Authenticator. In RADIUS accounting [RFC2866], the shared 826 secret is used in computation of both the Request Authenticator and the 827 Response Authenticator. 829 Since in RADIUS a shared secret is used to provide confidentiality as 830 well as integrity protection and authentication, only use of IPsec ESP 831 with a non-null transform can provide security services sufficient to 832 substitute for RADIUS application-layer security. Therefore, where 833 IPSEC AH or ESP null is used, it will typically still be necessary to 834 configure a RADIUS shared secret. 836 Where RADIUS is run over IPsec ESP with a non-null transform, the secret 837 shared between the NAS and the RADIUS server may not be configured. In 838 this case, a shared secret of zero length MUST be assumed. However, a 839 RADIUS server that cannot know whether incoming traffic is IPsec- 840 protected MUST be configured with a non-null RADIUS shared secret. 842 When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the 843 encryption transform, and per-packet authentication, integrity and 844 replay protection MUST be used. A typical IPsec policy for an IPsec- 845 capable RADIUS client is "Initiate IPsec, from me to any, destination 846 port UDP 1812". 848 This causes an IPsec SA to be set up by the RADIUS client prior to 849 sending RADIUS traffic to any RADIUS server. If some RADIUS servers 850 contacted by the client do not support IPsec, then a more granular 851 policy will be required. 853 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 854 IPsec, from any to me, destination port 1812". This causes the RADIUS 855 server to accept (but not require) use of IPsec. It may not be 856 appropriate to require IPsec for all RADIUS clients connecting to an 857 IPsec-enabled RADIUS server, since some RADIUS clients may not support 858 IPsec. 860 Where IPsec is used for security, and no RADIUS shared secret is 861 configured, it is important that trust be demonstrated between the 862 RADIUS client and RADIUS server by some means. For example, before 863 enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS 864 server should check whether the host is authorized to provide network 865 access. For example, the RADIUS server can be configured with the IP 866 addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for 867 certificate authentication) of RADIUS clients. 869 Alternatively, if a separate CA exists for RADIUS clients, then the 870 RADIUS server can configure this CA as a trusted root for use with 871 IPsec. However, unlike SSL/TLS, IKE does not permit certificate policies 872 to be set on a per-port basis, such a policy would need to apply to all 873 uses of IPsec on RADIUS clients and servers. Assuming that only 874 certificate authentication is supported in the deployment, a management 875 station initiating an IPsec-protected telnet session to the RADIUS 876 server would need to obtain a certificate chaining to the RADIUS client 877 CA. Issuing such a certificate might not be appropriate if the 878 management station was not authorized as a RADIUS client. 880 Where RADIUS clients may obtain their IP address dynamically (such as an 881 Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] 882 SHOULD NOT be used, since this requires use of a group pre-shared key; 883 instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses 884 are statically assigned either Aggressive Mode or Main Mode MAY be used. 885 With certificate authentication, Main Mode SHOULD be used. 887 Care needs to be taken with IKE Phase 1 Identity Payload selection in 888 order to enable mapping of identities to pre-shared keys even with 889 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 890 Payloads are used and addresses are dynamically assigned, mapping of 891 identities to keys is not possible, so that group pre-shared keys are 892 still a practical necessity. As a result, the ID_FQDN identity payload 893 SHOULD be employed in situations where Aggressive mode is utilized along 894 with pre-shared keys and IP addresses are dynamically assigned. This 895 approach also has other advantages, since it allows the RADIUS server 896 and client to configure themselves based on the fully qualified domain 897 name of their peers. 899 Note that with IPsec, security services are negotiated at the 900 granularity of an IPsec SA, so that RADIUS exchanges requiring a set of 901 security services different from those negotiated with existing IPsec 902 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also 903 advisable where quality of service considerations dictate different 904 handling RADIUS conversations. Attempting to apply different quality of 905 service to connections handled by the same IPsec SA can result in 906 reordering, and falling outside the replay window. For a discussion of 907 the issues, see [RFC2983]. 909 4.3. Security issues 911 This section provides more detail on the vulnerabilities identified in 912 Section 4.1, and how they may be mitigated. Vulnerabilities include: 914 Privacy issues 915 Message-Authenticator security 916 Connection hijacking 917 Dictionary attacks 918 Known plaintext attacks 919 Replay attacks 920 Negotiation attacks 921 Impersonation 922 Man in the middle attacks 923 Separation of EAP server and authenticator 924 Multiple databases 926 4.3.1. Privacy issues 928 Since RADIUS messages may contain the User-Name attribute as well as 929 NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on 930 RADIUS traffic may be able to determine the geographic location of users 931 in real time. In wireless networks, it is often assumed that RADIUS 932 traffic is physically secure, since it typically travels over the wired 933 network and that this limits the release of location information. 935 However, it is possible for an authenticated attacker send false ARP 936 messages claiming the address of an Access Point in order to cause 937 diversion of RADIUS traffic onto the wireless network. In this way an 938 attacker may obtain RADIUS packets from which it can glean location 939 information, or which it can subject to an offline dictionary attack. 940 To address this vulnerabilities, IPsec ESP with non-null transform and 941 per-packet authentication, integrity and replay protection SHOULD be 942 used to protect both RADIUS authentication [RFC2865] and accounting 943 [RFC2866] traffic. 945 4.3.2. Message-Authenticator security 947 Access-Request packets with a User-Password attribute establish the 948 identity of both the user and the NAS sending the Access-Request, 949 because of the way the shared secret between NAS and RADIUS server is 950 used. Access-Request packets with CHAP-Password or EAP-Message 951 attributes do not have a User-Password attribute, so the Message- 952 Authenticator attribute SHOULD be used in Access-Request packets that do 953 not have a User-Password attribute, in order to establish the identity 954 of the NAS sending the request. The Message-Authenticator attribute MUST 955 be present in all RADIUS/EAP packets. 957 4.3.3. Connection hijacking 959 An attacker may attempt to inject packets into the conversation between 960 the NAS and the RADIUS server, or between the RADIUS server and the 961 security server. RADIUS does not support encryption other than attribute 962 hiding, and as described in [RFC2865], only Access-Reply and Access- 963 Challenge packets are integrity protected. Moreover, the integrity 964 protection mechanism described in [RFC2865] is weaker than that likely 965 to be used by some EAP methods, making it possible to subvert those 966 methods by attacking EAP/RADIUS. 968 In order to provide for authentication of all packets in the EAP 969 exchange, all RADIUS/EAP packets MUST include the Message-Authenticator 970 attribute. 972 4.3.4. Dictionary attacks 974 The RADIUS shared secret is vulnerable to offline dictionary attack, 975 based on capture of the Response authenticator or Message-Authenticator 976 attribute. In order to decrease the level of vulnerability, [RFC2865] 977 recommends: 979 The secret (password shared between the client and the RADIUS server) 980 SHOULD be at least as large and unguessable as a well- chosen 981 password. It is preferred that the secret be at least 16 octets. 983 The risk of an offline dictionary attack can be further reduced by 984 employing IPsec ESP with non-null transform in order to encrypt the 985 RADIUS conversation, as described in Section 4.2. 987 4.3.5. Known plaintext attacks 989 Since EAP [RFC2284] does not support PAP, the RADIUS User-Password 990 attribute is not used to carry hidden user passwords within EAP 991 conversations. The User-Password hiding mechanism, defined in [RFC2865] 992 utilizes MD5, defined in [RFC1321], in order to generate a key stream 993 based on the RADIUS shared secret and the Request authenticator. Where 994 PAP is in use, it is possible to collect key streams corresponding to a 995 given Request Authenticator value, by capturing RADIUS conversations 996 corresponding to a PAP authentication attempt using a known password. 997 Since the User-Password is known, the key stream corresponding to a 998 given Request Authenticator can be determined and stored. 1000 Since the key stream may have been determined previously from a known 1001 plaintext attack, if the Request Authenticator repeats, attributes 1002 encrypted using the RADIUS attribute hiding mechanism should be 1003 considered compromised. In addition to the User-Password attribute, 1004 which is not used with EAP, this includes attributes such as Tunnel- 1005 Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv- 1006 Key attributes [RFC2548, section 2.4]. 1008 Even though EAP does not support PAP authentication, a security 1009 vulnerability can still exist where the same RADIUS shared secret is 1010 used for hiding User-Password as well as other attributes. This can 1011 occur, for example, if the same RADIUS proxy handles authentication 1012 requests for both EAP and PAP. 1014 The threat can be mitigated by protecting RADIUS with IPsec ESP with 1015 non-null transform, as described in Section 4.2. Where RADIUS shared 1016 secrets are configured, the RADIUS shared secret used by a NAS 1017 supporting EAP MUST NOT be reused by a NAS supporting PAP 1018 authentication, since improper shared secret hygiene could lead to 1019 compromise of hidden attributes. 1021 4.3.6. Replay attacks 1023 The RADIUS protocol provides only limited support for replay protection. 1024 RADIUS Access-Requests include liveness via the 128-bit Request 1025 authenticator. However, the Request Authenticator is not a replay 1026 counter. Since RADIUS servers may not maintain a cache of previous 1027 Request Authenticators, the Request Authenticator does not provide 1028 replay protection. 1030 Since RADIUS accounting [RFC2866] does not include a nonce within the 1031 Request Authenticator, it does not guarantee liveness of the exchange at 1032 the protocol level, although an Event-Timestamp attribute may be 1033 included to protect against replay. 1035 Strong replay protection for RADIUS authentication and accounting can be 1036 provided by enabling IPsec replay protection with RADIUS, as described 1037 in Section 4.2. 1039 4.3.7. Negotiation attacks 1041 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 1042 RADIUS server causes the authenticating peer to choose a less secure 1043 authentication method so as to make it easier to obtain the user's 1044 password. For example, a session that would normally be authenticated 1045 with EAP would instead authenticated via CHAP or PAP; alternatively, a 1046 connection that would normally be authenticated via one EAP type occurs 1047 via a less secure EAP type, such as MD5. The threat posed by rogue 1048 devices, once thought to be remote, has gained currency given 1049 compromises of telephone company switching systems, such as those 1050 described in [Masters]. 1052 Protection against negotiation attacks requires the elimination of 1053 downward negotiations. This can be achieved by protecting the RADIUS 1054 exchange using IPsec as described in Section 4.2. Alternatively, where 1055 IPsec is not used, the vulnerability can be mitigated via implementation 1056 of per-connection policy on the part of the authenticating peer, and 1057 per-user policy on the part of the RADIUS server. For the 1058 authenticating peer, authentication policy should be set on a per- 1059 connection basis. Per-connection policy allows an authenticating peer to 1060 negotiate a strong EAP method when connecting to one service, while 1061 negotiating a weaker EAP method for another service. 1063 With per-connection policy, an authenticating peer will only attempt to 1064 negotiate EAP for a session in which EAP support is expected. As a 1065 result, there is a presumption that an authenticating peer selecting EAP 1066 requires that level of security. If it cannot be provided, it is likely 1067 that there is some kind of misconfiguration, or even that the 1068 authenticating peer is contacting the wrong server. Should the NAS not 1069 be able to negotiate EAP, or should the EAP-Request sent by the NAS be 1070 of a different EAP type than what is expected, the authenticating peer 1071 MUST disconnect. An authenticating peer expecting EAP to be negotiated 1072 for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. 1073 In wireless networks, the service advertisement itself may be spoof- 1074 able, so that an attacker could fool the peer into negotiating an 1075 authentication method suitable for a less secure network. 1077 For a NAS, it may not be possible to determine whether a peer is 1078 required to authenticate with EAP until the peer's identity is known. 1079 For example, for shared-uses NASes it is possible for one reseller to 1080 implement EAP while another does not. Alternatively, some peer might be 1081 authenticated locally by the NAS while other peers are authenticated via 1082 RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS 1083 MUST attempt to negotiate EAP for every session. This avoids forcing an 1084 EAP-capable client to support more than one authentication type, which 1085 could weaken security. 1087 If CHAP is negotiated, the NAS will pass the User-Name and CHAP- 1088 Password attributes to the RADIUS server in an Access-Request packet. 1089 If the user is not required to use EAP, then the RADIUS server will 1090 respond with an Access-Accept or Access-Reject packet as appropriate. 1091 However, if CHAP has been negotiated but EAP is required, the RADIUS 1092 server MUST respond with an Access-Reject, rather than an Access- 1093 Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST 1094 refuse to renegotiate authentication, even if the renegotiation is from 1095 CHAP to EAP. 1097 If EAP is negotiated but is not supported by the RADIUS proxy or server, 1098 then the server or proxy MUST respond with an Access-Reject. In these 1099 cases, a PPP NAS MUST send an LCP-Terminate and disconnect the user. 1100 This is the correct behavior since the authenticating peer is expecting 1101 EAP to be negotiated, and that expectation cannot be fulfilled. An EAP- 1102 capable authenticating peer MUST refuse to renegotiate the 1103 authentication protocol if EAP had initially been negotiated. Note that 1104 problems with a non-EAP capable RADIUS proxy could prove difficult to 1105 diagnose, since a user connecting from one location (with an EAP-capable 1106 proxy) might be able to successfully authenticate via EAP, while the 1107 same user connecting at another location (and encountering an EAP- 1108 incapable proxy) might be consistently disconnected. 1110 4.3.8. Impersonation 1112 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address 1113 attribute may not correspond to the source address. Since the NAS- 1114 Identifier attribute need not contain an FQDN, it also may not 1115 correspond to the source address, even indirectly. [RFC2865] Section 3 1116 states: 1118 A RADIUS server MUST use the source IP address of the RADIUS 1119 UDP packet to decide which shared secret to use, so that 1120 RADIUS requests can be proxied. 1122 This implies that it is possible for a rogue NAS to forge NAS-IP-Address 1123 or NAS-Identifier attributes within a RADIUS Access-Request in order to 1124 impersonate another NAS. Since the rogue NAS is authenticated by the 1125 RADIUS proxy or server purely based on the source address, other 1126 mechanisms are required to detect the forgery. In addition, it is 1127 possible for attributes such as the Called-Station-Id and calling- 1128 Station-Id to be forged as well. 1130 To address this vulnerability RADIUS proxies used with RADIUS/EAP SHOULD 1131 check whether the NAS-IP-Address attribute matches the source address of 1132 packets originating from the NAS. If the NAS-Identifier attribute is 1133 used instead, such a check may not be possible since the NAS-Identifier 1134 may not correspond to an FQDN, and therefore may not be resolvable to an 1135 IP address to be matched against the source address. Also, where a NAT 1136 exists between the RADIUS client and server, checking the NAS-IP-Address 1137 attribute may not be feasible. 1139 To allow verification of session parameters such as the Called-Station- 1140 Id and Calling-Station-Id, they can be sent by the EAP peer to the EAP 1141 server, and covered by an EAP methode-specific message integrity check. 1142 The RADIUS server can then check the parameters sent by the EAP client 1143 against those claimed by the NAS. If a discrepancy is found, an error 1144 can be logged. 1146 4.3.9. Man in the middle attacks 1148 Since RADIUS security is based on shared secrets, end-to-end security is 1149 not provided in the case where authentication or accounting packets are 1150 forwarded along a proxy chain. As a result, attackers gaining control 1151 of a RADIUS proxy will be able to modify EAP packets in transit. This is 1152 the case even where IPsec is used to protect RADIUS. 1154 4.3.10. Separation of EAP server and authenticator 1156 It is possible for the EAP peer and authenticator to mutually 1157 authenticate, and derive a Master Session Key (MSK) for a ciphersuite 1158 used to protect subsequent data traffic. This does not present an issue 1159 on the peer, since the peer and EAP client reside on the same machine; 1160 all that is required is for the EAP client module to derive and pass a 1161 Transient Session Key (TSK) to the ciphersuite module. 1163 The situation is more complex when EAP is used with RADIUS, since the 1164 authenticator will typically not reside on the same machine as the EAP 1165 server. For example, the EAP server may be a security server, or a 1166 module residing on the RADIUS server. 1168 In the case where the EAP server and authenticator reside on different 1169 machines, there are several implications for security. First, mutual 1170 authentication will occur between the peer and the EAP server, not 1171 between the peer and the authenticator. This means that it is not 1172 possible for the peer to validate the identity of the NAS or tunnel 1173 server that it is speaking to, using EAP alone. 1175 As described in Section 4, when EAP/RADIUS is used to encapsulate EAP 1176 packets, IPsec SHOULD be used to provide per-packet authentication, 1177 integrity, replay protection and confidentiality. The Message- 1178 Authenticator attribute is also required in EAP/RADIUS Access-Requests 1179 sent from the NAS or tunnel server to the RADIUS server. Since the 1180 Message-Authenticator attribute involves a HMAC-MD5 message integrity 1181 check, it is possible for the RADIUS server to verify the integrity of 1182 the Access-Request as well as the NAS or tunnel server's identity, even 1183 where IPsec is not used. Similarly, Access-Challenge packets sent from 1184 the RADIUS server to the NAS are also authenticated and integrity 1185 protected using an HMAC-MD5 message integrity check, enabling the NAS or 1186 tunnel server to determine the integrity of the packet and verify the 1187 identity of the RADIUS server, even where IPsec is not used. Moreover, 1188 EAP packets sent using methods that contain their own integrity 1189 protection cannot be successfully modified by a rogue NAS or tunnel 1190 server. 1192 The second issue that arises in the case of an EAP server and 1193 authenticator residing on different machines is that the EAP Master 1194 Session Key (MSK) negotiated between the peer and EAP server will need 1195 to be transmitted to the authenticator. Therefore a mechanism needs to 1196 be provided to transmit the MSK from the EAP server to the authenticator 1197 or tunnel server that needs it. The specification of the key transport 1198 and wrapping mechanism is outside the scope of this document. 1200 4.3.11. Multiple databases 1202 In many cases a security server will be deployed along with a RADIUS 1203 server in order to provide EAP services. Unless the security server also 1204 functions as a RADIUS server, two separate user databases will exist, 1205 each containing information about the security requirements for the 1206 user. This represents a weakness, since security may be compromised by a 1207 successful attack on either of the servers, or their databases. With 1208 multiple user databases, adding a new user may require multiple 1209 operations, increasing the chances for error. The problems are further 1210 magnified in the case where user information is also being kept in an 1211 LDAP server. In this case, three stores of user information may exist. 1213 In order to address these threats, consolidation of databases is 1214 recommended. This can be achieved by having both the RADIUS server and 1215 security server store information in the same database; by having the 1216 security server provide a full RADIUS implementation; or by 1217 consolidating both the security server and the RADIUS server onto the 1218 same machine. 1220 5. Normative references 1222 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1223 Hashing for Message Authentication", RFC 2104, February 1224 1997. 1226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1227 Requirement Levels", RFC 2119, March 1997.] 1229 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 1230 10646", RFC 2279, January 1998. 1232 [RFC2284] Blunk, L., and J. Vollbrecht, "Extensible Authentication 1233 Protocol (EAP)", RFC 2284, March 1998. 1235 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 1236 Internet Protocol", RFC 2401, November 1998. 1238 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security 1239 Payload (ESP)", RFC 2406, November 1998 1241 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1242 (IKE)", RFC 2409, November 1998 1244 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1245 "Remote Authentication Dial In User Service (RADIUS)", 1246 RFC 2865, June 2000. 1248 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1249 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1251 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 1252 Port based Network Access Control, IEEE Std 802.1X-2001, 1253 June 2001. 1255 6. Informative references 1257 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 1258 Authentication Service (V5)", RFC 1510, September 1993. 1260 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1261 RFC 1661, July 1994. 1263 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 1264 RFC 2486, January 1999. 1266 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1267 RFC 2548, March 1999. 1269 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 1270 Protocol", RFC 2716, October 1999. 1272 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1274 [RFC2868] Zorn, G. et. al, "RADIUS Attributes for Tunnel Protocol 1275 Support", RFC 2868, June 2000. 1277 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 1278 2983, October 2000. 1280 [RFC3162] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IP6", RFC 1281 3162, August 2001. 1283 [Masters] Slatalla, M., and Quittner, J., "Masters of Deception." 1284 HarperCollins, New York, 1995. 1286 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", 1287 CryptoBytes Vol.2 No.2, Summer 1996. 1289 Appendix A - Examples 1291 The examples below illustrate conversations between an authenticating 1292 peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used 1293 only for illustrative purposes; other authentication protocols could 1294 also have been used, although they might show somewhat different 1295 behavior. 1297 Where the NAS sends an EAP-Request/Identity as the initial packet, the 1298 exchange appears as follows: 1300 Authenticating peer NAS RADIUS server 1301 ------------------- --- ------------- 1302 <- EAP-Request/ 1303 Identity 1304 EAP-Response/ 1305 Identity (MyID) -> 1306 RADIUS Access-Request/ 1307 EAP-Message/EAP-Response/ 1308 (MyID) -> 1309 <- RADIUS 1310 Access-Challenge/ 1311 EAP-Message/EAP-Request 1312 OTP/OTP Challenge 1313 <- EAP-Request/ 1314 OTP/OTP Challenge 1315 EAP-Response/ 1316 OTP, OTPpw -> 1317 RADIUS Access-Request/ 1318 EAP-Message/EAP-Response/ 1319 OTP, OTPpw -> 1320 <- RADIUS 1321 Access-Accept/ 1322 EAP-Message/EAP-Success 1323 (other attributes) 1324 <- EAP-Success 1326 In the case where the NAS initiates with an EAP-Request for EAP TLS 1327 [RFC2716], and the identity is determined based on the contents of the 1328 client certificate, the exchange will appear as follows: 1330 Authenticating peer NAS RADIUS server 1331 ------------------- --- ------------- 1332 <- EAP-Request/ 1333 EAP-Type=EAP-TLS 1334 (TLS Start, S bit set) 1335 EAP-Response/ 1336 EAP-Type=EAP-TLS 1337 (TLS client_hello)-> 1338 RADIUS Access-Request/ 1339 EAP-Message/EAP-Response/ 1340 EAP-Type=EAP-TLS-> 1341 <-RADIUS Access-Challenge/ 1342 EAP-Message/ 1343 EAP-Request/ 1344 EAP-Type=EAP-TLS 1345 <- EAP-Request/ 1346 EAP-Type=EAP-TLS 1347 (TLS server_hello, 1348 TLS certificate, 1349 [TLS server_key_exchange,] 1350 [TLS certificate_request,] 1351 TLS server_hello_done) 1352 EAP-Response/ 1353 EAP-Type=EAP-TLS 1354 (TLS certificate, 1355 TLS client_key_exchange, 1356 [TLS certificate_verify,] 1357 TLS change_cipher_spec, 1358 TLS finished)-> 1359 RADIUS Access-Request/ 1360 EAP-Message/EAP-Response/ 1361 EAP-Type=EAP-TLS-> 1362 <-RADIUS Access-Challenge/ 1363 EAP-Message/ 1364 EAP-Request/ 1365 EAP-Type=EAP-TLS 1366 <- EAP-Request/ 1367 EAP-Type=EAP-TLS 1368 (TLS change_cipher_spec, 1369 TLS finished) 1370 EAP-Response/ 1371 EAP-Type=EAP-TLS -> 1372 RADIUS Access-Request/ 1373 EAP-Message/EAP-Response/ 1374 EAP-Type=EAP-TLS-> 1375 <-RADIUS Access-Accept/ 1376 EAP-Message/ 1377 EAP-Request/ 1378 EAP-Success 1379 (other attributes) 1380 <- EAP-Success 1382 In the case where the NAS first sends an EAP-Start packet to the RADIUS 1383 server, the conversation would appear as follows: 1385 Authenticating peer NAS RADIUS server 1386 ------------------- --- ------------- 1387 RADIUS Access-Request/ 1388 EAP-Message/Start -> 1389 <- RADIUS 1390 Access-Challenge/ 1391 EAP-Message/Identity 1392 <- EAP-Request/ 1393 Identity 1394 EAP-Response/ 1395 Identity (MyID) -> 1396 RADIUS Access-Request/ 1397 EAP-Message/EAP-Response/ 1398 (MyID) -> 1399 <- RADIUS 1400 Access-Challenge/ 1401 EAP-Message/EAP-Request 1402 OTP/OTP Challenge 1403 <- EAP-Request/ 1404 OTP/OTP Challenge 1405 EAP-Response/ 1406 OTP, OTPpw -> 1407 RADIUS Access-Request/ 1408 EAP-Message/EAP-Response/ 1409 OTP, OTPpw -> 1410 <- RADIUS 1411 Access-Accept/ 1412 EAP-Message/EAP-Success 1413 (other attributes) 1414 <- EAP-Success 1416 In the case where the NAS initiates with an EAP-Request for EAP TLS 1417 [RFC2716], but the peer responds with a Nak, indicating that it would 1418 prefer another method not implemented locally on the NAS, the exchange 1419 will appear as follows: 1421 Authenticating peer NAS RADIUS server 1422 ------------------- --- ------------- 1423 <- EAP-Request/ 1424 EAP-Type=EAP-TLS 1425 (TLS Start, S bit set) 1426 EAP-Response/ 1427 EAP-Type=Nak 1428 (Alternative(s))-> 1429 RADIUS Access-Request/ 1430 EAP-Message/Start -> 1431 <- RADIUS 1432 Access-Challenge/ 1433 EAP-Message/Identity 1434 <- EAP-Request/ 1435 Identity 1436 EAP-Response/ 1437 Identity (MyID) -> 1438 RADIUS Access-Request/ 1439 EAP-Message/EAP-Response/ 1440 (MyID) -> 1441 <- RADIUS 1442 Access-Challenge/ 1443 EAP-Message/EAP-Request 1444 OTP/OTP Challenge 1445 <- EAP-Request/ 1446 OTP/OTP Challenge 1447 EAP-Response/ 1448 OTP, OTPpw -> 1449 RADIUS Access-Request/ 1450 EAP-Message/EAP-Response/ 1451 OTP, OTPpw -> 1452 <- RADIUS 1453 Access-Accept/ 1454 EAP-Message/EAP-Success 1455 (other attributes) 1456 <- EAP-Success 1458 In the case where the authenticating peer attempts to authenticate the 1459 NAS, the conversation would appear as follows: 1461 Authenticating Peer NAS RADIUS Server 1462 ------------------- --- ------------- 1463 EAP-Request/ 1464 Challenge, MD5 -> 1465 RADIUS Access-Request/ 1466 EAP-Message/EAP-Request/ 1467 Challenge, MD5 -> 1468 <- RADIUS 1469 Access-Reject/ 1470 EAP-Message/ 1471 EAP-Response/ 1472 Nak (no alternative) 1474 <- EAP-Response/Nak 1475 (no alternative) 1476 EAP-Failure -> 1478 In the case where an invalid EAP Response is inserted by an attacker, 1479 the conversation would appear as follows: 1481 Authenticating peer NAS RADIUS server 1482 ------------------- --- ------------- 1483 <- EAP-Request/ 1484 EAP-Type=Foo 1485 EAP-Response/ 1486 EAP-Type=Foo -> 1487 RADIUS Access-Request/ 1488 EAP-Message/EAP-Response/ 1489 EAP-Type=Foo -> 1490 <- RADIUS 1491 Access-Challenge/ 1492 EAP-Message/EAP-Request/ 1493 EAP-Type=Foo 1494 <- EAP-Request/ 1495 EAP-Type=Foo 1496 Attacker spoof: 1497 EAP-Response/ 1498 EAP-Type=Foo -> 1499 RADIUS Access-Request/ 1500 EAP-Message/EAP-Response/ 1501 EAP-Type=Foo -> 1502 <- RADIUS 1503 Access-Challenge/ 1504 EAP-Message/Start 1505 EAP-Response/ 1506 EAP-Type=Foo -> 1507 RADIUS Access-Request/ 1508 EAP-Message/EAP-Response/ 1509 EAP-Type=Foo -> 1510 Access-Accept/ 1511 EAP-Message/Success 1512 <- EAP Success 1514 In the case where the client fails EAP authentication, and an error 1515 message is sent prior to disconnection, the conversation would appear as 1516 follows: 1518 Authenticating peer NAS RADIUS server 1519 ------------------- --- ------------- 1520 RADIUS Access-Request/ 1521 EAP-Message/Start -> 1522 <- RADIUS 1523 Access-Challenge/ 1524 EAP-Message/Identity 1525 <- EAP-Request/ 1526 Identity 1527 EAP-Response/ 1528 Identity (MyID) -> 1529 RADIUS Access-Request/ 1530 EAP-Message/EAP-Response/ 1531 (MyID) -> 1532 <- RADIUS 1533 Access-Challenge/ 1534 EAP-Message/EAP-Request 1535 OTP/OTP Challenge 1536 <- EAP-Request/ 1537 OTP/OTP Challenge 1538 EAP-Response/ 1539 OTP, OTPpw -> 1540 RADIUS Access-Request/ 1541 EAP-Message/EAP-Response/ 1542 OTP, OTPpw -> 1543 <- RADIUS 1544 Access-Challenge/ 1545 EAP-Message/EAP-Request/ 1546 Notification 1547 <- EAP-Request/ 1548 Notification 1549 EAP-Response/ 1550 Notification -> 1551 RADIUS Access-Request/ 1552 EAP-Message/EAP-Response/ 1553 Notification -> 1554 <- RADIUS 1555 Access-Reject/ 1556 EAP-Message/EAP-Failure 1557 <- EAP-Failure 1558 (client disconnected) 1560 In the case that the RADIUS server or proxy does not support EAP- 1561 Message, but no error message is sent, the conversation would appear as 1562 follows: 1564 Authenticating peer NAS RADIUS server 1565 ------------------- --- ------------- 1566 RADIUS Access-Request/ 1567 EAP-Message/Start -> 1568 <- RADIUS 1569 Access-Reject 1570 (User Disconnected) 1572 In the case where the local RADIUS server does support EAP-Message, but 1573 the remote RADIUS server does not, the conversation would appear as 1574 follows: 1576 Authenticating peer NAS RADIUS server 1577 ------------------- --- ------------- 1578 RADIUS Access-Request/ 1579 EAP-Message/Start -> 1580 <- RADIUS 1581 Access-Challenge/ 1582 EAP-Message/Identity 1583 <- EAP-Request/ 1584 Identity 1586 EAP-Response/ 1587 Identity 1588 (MyID) -> 1589 RADIUS Access-Request/ 1590 EAP-Message/EAP-Response/ 1591 (MyID) -> 1592 <- RADIUS 1593 Access-Reject 1594 (proxied from remote 1595 RADIUS server) 1596 (User Disconnected) 1598 In the case where PPP is the link and the authenticating peer does not 1599 support EAP, but where EAP is required for that user, the conversation 1600 would appear as follows: 1602 Authenticating peer NAS RADIUS server 1603 ------------------- --- ------------- 1604 <- PPP LCP Request-EAP 1605 auth 1606 PPP LCP NAK-EAP 1607 auth -> 1608 <- PPP LCP Request-CHAP 1609 auth 1610 PPP LCP ACK-CHAP 1611 auth -> 1612 <- PPP CHAP Challenge 1613 PPP CHAP Response -> 1614 RADIUS Access-Request/ 1615 User-Name, 1616 CHAP-Password -> 1617 <- RADIUS 1618 Access-Reject 1619 <- PPP LCP Terminate 1620 (User Disconnected) 1622 In the case where PPP is the link, the NAS does not support EAP, but 1623 where EAP is required for that user, the conversation would appear as 1624 follows: 1626 Authenticating peer NAS RADIUS server 1627 ------------------- --- ------------- 1628 <- PPP LCP Request-CHAP 1629 auth 1631 PP LCP ACK-CHAP 1632 auth -> 1633 <- PPP CHAP Challenge 1634 PPP CHAP Response -> 1635 RADIUS Access-Request/ 1636 User-Name, 1637 CHAP-Password -> 1639 <- RADIUS 1640 Access-Reject 1641 <- PPP LCP Terminate 1642 (User Disconnected) 1644 Appendix B - Change log 1646 The following changes have been made from RFC 2869: 1648 A NAS may simultaneously support both local authentication and pass- 1649 through; once the NAS enters pass-through mode within a session, it 1650 cannot revert back to local authentication (Section 2). 1652 The NAS may initiate with an EAP-Request for an authentication Type. If 1653 the Request is NAK'd, the NAS may send an initial Access-Request with an 1654 EAP-Message attribute containing an EAP-Response/Nak. In such a packet, 1655 an EAP-Start must not also be included (Section 2.1) 1657 Role reversal is not supported (Section 2.2). 1659 The Password-Retry (Section 2.2) and Reply-Message (2.7.3) attributes 1660 are deprecated. 1662 The RADIUS server is now permitted to treat an invalid EAP Response as a 1663 non-fatal error (Section 2.5) 1665 Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are 1666 discouraged (Section 2.7.1). 1668 EAP-Message attributes are processed last (Section 2.7.2). 1670 Only a single EAP packet may be encapsulated within a RADIUS message 1671 (Section 2.7.4). 1673 IPsec ESP with non-null transform SHOULD be used and the usage model is 1674 described in detail (Section 4.2). 1676 Additional discussion of security vulnerabilities (Section 4.1) and 1677 potential fixes (Section 4.3). 1679 Separated normative (Section 5) and informative (Section 6) references. 1681 Added additional examples (Appendix A): the NAS initiating with an EAP- 1682 Request for an authentication Type; attempted role reversal. 1684 Acknowledgments 1686 Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco 1687 Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and 1688 Narendra Gidwani of Microsoft for useful discussions of this problem 1689 space. The authors would also like to acknowledge Tony Jeffree, Chair of 1690 IEEE 802.1 for his assistance in resolving RADIUS/EAP issues in IEEE 1691 802.1X. 1693 Author's Addresses 1695 Bernard Aboba 1696 Microsoft Corporation 1697 One Microsoft Way 1698 Redmond, WA 98052 1700 Phone: +1 425 706 6605 1701 Fax: +1 425 936 7329 1702 EMail: bernarda@microsoft.com 1704 Pat R. Calhoun 1705 Black Storm Networks 1706 250 Cambridge Avenue, Suite 200 1707 Palo Alto, California, 94306 1708 USA 1710 Phone: +1 650-617-2932 1711 Fax: +1 650-786-6445 1712 E-mail: pcalhoun@bstormnetworks.com 1714 Intellectual Property Statement 1716 The IETF takes no position regarding the validity or scope of any 1717 intellectual property or other rights that might be claimed to pertain 1718 to the implementation or use of the technology described in this 1719 document or the extent to which any license under such rights might or 1720 might not be available; neither does it represent that it has made any 1721 effort to identify any such rights. Information on the IETF's 1722 procedures with respect to rights in standards-track and standards- 1723 related documentation can be found in BCP-11. Copies of claims of 1724 rights made available for publication and any assurances of licenses to 1725 be made available, or the result of an attempt made to obtain a general 1726 license or permission for the use of such proprietary rights by 1727 implementors or users of this specification can be obtained from the 1728 IETF Secretariat. 1730 The IETF invites any interested party to bring to its attention any 1731 copyrights, patents or patent applications, or other proprietary rights 1732 which may cover technology that may be required to practice this 1733 standard. Please address the information to the IETF Executive 1734 Director. 1736 Full Copyright Statement 1738 Copyright (C) The Internet Society (2003). All Rights Reserved. 1739 This document and translations of it may be copied and furnished to 1740 others, and derivative works that comment on or otherwise explain it or 1741 assist in its implementation may be prepared, copied, published and 1742 distributed, in whole or in part, without restriction of any kind, 1743 provided that the above copyright notice and this paragraph are included 1744 on all such copies and derivative works. However, this document itself 1745 may not be modified in any way, such as by removing the copyright notice 1746 or references to the Internet Society or other Internet organizations, 1747 except as needed for the purpose of developing Internet standards in 1748 which case the procedures for copyrights defined in the Internet 1749 Standards process must be followed, or as required to translate it into 1750 languages other than English. The limited permissions granted above are 1751 perpetual and will not be revoked by the Internet Society or its 1752 successors or assigns. This document and the information contained 1753 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1754 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1755 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1756 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1759 Open issues 1761 Open issues relating to this specification are tracked on the following 1762 web site: 1764 http://www.drizzle.com/~aboba/EAP/eapissues.html 1766 Expiration Date 1768 This memo is filed as , and 1769 expires September 24, 2003.