idnits 2.17.1 draft-ietf-radius-ext-03.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 10 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 311 has weird spacing: '...y a few piece...' == Line 373 has weird spacing: '...ute and perfo...' == Line 487 has weird spacing: '... passed in an...' == Line 884 has weird spacing: '...pecific code ...' == Line 1615 has weird spacing: '...ute and perfo...' == (2 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 (February 1999) is 9201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 1679 ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '2') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group C Rigney 3 INTERNET-DRAFT Livingston 4 W Willats 5 Cyno Technologies 6 P Calhoun 7 Sun Microsystems 8 expires September 1999 February 1999 10 RADIUS Extensions 11 draft-ietf-radius-ext-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 This document is a submission to the RADIUS Working Group of the 19 Internet Engineering Task Force (IETF). Comments should be submitted 20 to the ietf-radius@livingston.com mailing list. 22 Distribution of this memo is unlimited. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (1999). All Rights Reserved. 44 Abstract 46 This document describes additional attributes for carrying 47 authentication, authorization and accounting information between a 48 Network Access Server (NAS) and a shared Accounting Server using the 49 Remote Authentication Dial In User Service (RADIUS) protocol 50 described in RFC 2138 and RFC 2139. 52 Table of Contents 54 1. Introduction .......................................... 4 55 1.1 Specification of Requirements ................... 4 56 1.2 Terminology ..................................... 4 58 2. Operation ............................................. 5 59 2.1 RADIUS support for Interim Accounting Updates 5 60 2.2 RADIUS support for Apple Remote Access Protocol 6 61 2.3 RADIUS Support for Extensible Authentication 62 Protocol (EAP) ........................... 12 63 2.3.1 Protocol Overview ............................... 12 64 2.3.2 Retransmission .................................. 14 65 2.3.3 Fragmentation ................................... 15 66 2.3.4 Examples ........................................ 15 67 2.3.5 Alternative uses ................................ 20 69 3. Packet Format ......................................... 20 71 4. Packet Types .......................................... 20 73 5. Attributes ............................................ 20 74 5.1 Acct-Input-Gigawords ............................ 22 75 5.2 Acct-Output-Gigawords ........................... 23 76 5.3 Event-Timestamp ................................. 24 77 5.4 ARAP-Password ................................... 24 78 5.5 ARAP-Features ................................... 25 79 5.6 ARAP-Zone-Access ................................ 27 80 5.7 ARAP-Security ................................... 28 81 5.8 ARAP-Security-Data .............................. 28 82 5.9 Password-Retry .................................. 29 83 5.10 Prompt .......................................... 30 84 5.11 Connect-Info .................................... 31 85 5.12 Configuration-Token ............................. 32 86 5.13 EAP-Message ..................................... 32 87 5.14 Signature ....................................... 34 88 5.15 ARAP-Challenge-Response ......................... 36 89 5.16 Acct-Interim-Interval ........................... 37 90 5.17 Table of Attributes ............................. 37 92 6. Security Considerations ............................... 38 93 6.1 Separation of EAP server and PPP authenticator 94 6.2 Connection hijacking ............................ 39 95 6.3 Man in the middle attacks ....................... 40 96 6.4 Multiple databases .............................. 40 97 6.5 Negotiation attacks ............................. 40 99 7. References ............................................ 42 100 8. Acknowledgements ...................................... 42 101 9. Chair's Address ....................................... 43 102 10. Author's Address ...................................... 43 103 11. Full Copyright Statement .............................. 45 105 1. Introduction 107 RFC 2138 [1] describes the RADIUS Protocol as it is implemented and 108 deployed today, and RFC 2139 [2] describes how Accounting can be 109 performed with RADIUS. 111 This memo suggests several additional Attributes that can be added to 112 RADIUS to perform various useful functions. These Attributes do not 113 have extensive field experience yet and should therefore be 114 considered experimental. 116 The Extensible Authentication Protocol (EAP) [3] is a PPP extension 117 that provides support for additional authentication methods within 118 PPP. This memo describes how the EAP-Message and Signature 119 attributes may be used for providing EAP support within RADIUS. 121 All attributes are comprised of variable length Type-Length-Value 3- 122 tuples. New attribute values can be added without disturbing 123 existing implementations of the protocol. 125 1.1. Specification of Requirements 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [4]. 131 An implementation is not compliant if it fails to satisfy one or more 132 of the must or must not requirements for the protocols it implements. 133 An implementation that satisfies all the must, must not, should and 134 should not requirements for its protocols is said to be 135 "unconditionally compliant"; one that satisfies all the must and must 136 not requirements but not all the should or should not requirements 137 for its protocols is said to be "conditionally compliant." 139 A NAS that does not implement a given service MUST NOT implement the 140 RADIUS attributes for that service. For example, a NAS that is 141 unable to offer ARAP service MUST NOT implement the RADIUS attributes 142 for ARAP. A NAS MUST treat a RADIUS access-request requesting an 143 unavailable service as an access-reject instead. 145 1.2. Terminology 147 This document uses the following terms: 149 service The NAS provides a service to the dial-in user, such as PPP 150 or Telnet. 152 session Each service provided by the NAS to a dial-in user 153 constitutes a session, with the beginning of the session 154 defined as the point where service is first provided and 155 the end of the session defined as the point where service 156 is ended. A user may have multiple sessions in parallel or 157 series if the NAS supports that, with each session 158 generating a separate start and stop accounting record. 160 silently discard 161 This means the implementation discards the packet without 162 further processing. The implementation SHOULD provide the 163 capability of logging the error, including the contents of 164 the silently discarded packet, and SHOULD record the event 165 in a statistics counter. 167 2. Operation 169 Operation is identical to that defined in RFC 2138 and 2139. 171 2.1. RADIUS support for Interim Accounting Updates 173 When a user is authenticated, a RADIUS server issues an Access-Accept 174 in response to a successful Access-Request. If the server wishes to 175 receive interim accounting messages for the given user it must 176 include the Acct-Interim-Interval RADIUS attribute in the message, 177 which indicates the interval in seconds between interim messages. 179 It is also possible to statically configure an interim value on the 180 NAS itself. Note that a locally configured value on the NAS MUST 181 override the value found in an Access-Accept. 183 This scheme does not break backward interoperability since a RADIUS 184 server not supporting this extension will simply not add the new 185 Attribute. NASes not supporting this extension will ignore the 186 Attribute. 188 Note that all information in an interim message is cumulative (i.e. 189 number of packets sent is the total since the beginning of the 190 session, not since the last interim message). 192 It is envisioned that an Interim Accounting record (with Acct- 193 Status-Type = Interim-Update (3)) would contain all of the attributes 194 normally found in an Accounting Stop message with the exception of 195 the Acct-Term-Cause attribute. 197 Since all the information is cumulative, a NAS MUST ensure that only 198 a single generation of an interim Accounting message for a given 199 session is present in the retransmission queue at any given time. 201 A NAS MAY use a fudge factor to add a random delay between Interim 202 Accounting messages for separate sessions. This will ensure that a 203 cycle where all messages are sent at once is prevented, such as might 204 otherwise occur if a primary link was recently restored and many 205 dial-up users were directed to the same NAS at once. 207 The Network and NAS CPU load of using Interim Updates should be 208 carefully considered, and appropriate values of Acct-Interim-Interval 209 chosen. 211 2.2. RADIUS support for Apple Remote Access Protocol 213 The RADIUS (Remote Authentication Dial-In User Service) protocol 214 provides a method that allows multiple dial-in Network Access Server 215 (NAS) devices to share a common authentication database. 217 The Apple Remote Access Protocol (ARAP) provides a method for sending 218 AppleTalk network traffic over point-to-point links, typically, but 219 not exclusively, asynchronous and ISDN switched-circuit connections. 220 Though Apple is moving toward ATCP on PPP for future remote access 221 services, ARAP is still a common way for the installed base of 222 Macintosh users to make remote network connections, and is likely to 223 remain so for some time. 225 ARAP is supported by several NAS vendors who also support PPP, IPX 226 and other protocols in the same NAS. ARAP connections in these 227 multi-protocol devices are often not authenticated with RADIUS, or if 228 they are, each vendor creates an individual solution to the problem. 230 This section describes the use of additional RADIUS attributes to 231 support ARAP. RADIUS client and server implementations that implement 232 this specification should be able to authenticate ARAP connections in 233 an interoperable manner. 235 This section assumes prior knowledge of RADIUS, and will go into some 236 detail on the operation of ARAP before entering a detailed discussion 237 of the proposed ARAP RADIUS attributes. 239 There are two features of ARAP this document does not address: 241 1. User initiated password changing. This is not part of RADIUS, 242 but can be implemented through a software process other than 243 RADIUS. 245 2. Out-of-Band messages. At any time, the NAS can send messages to 246 an ARA client which appear in a dialog box on the dial-in user's 247 screen. These are not part of authentication and do not belong 248 here. However, we note that a Reply-Message attribute in an 249 Access-Accept may be sent down to the user as a sign-on message of 250 the day string using the out-of-band channel. 252 We have tried to respect the spirit of the existing RADIUS protocol 253 as much as possible, making design decisions compatible with prior 254 art. Further, we have tried to strike a balance between flooding the 255 RADIUS world with new attributes, and hiding all of ARAP operation 256 within a single multiplexed ARAP attribute string or within Extended 257 Authentication Protocol (EAP) [3] machinery. 259 However, we feel ARAP is enough of a departure from PPP to warrant a 260 small set of similarly named attributes of its own. 262 We have assumed that an ARAP-aware RADIUS server will be able to do 263 DES encryption and generate security module challenges. This is in 264 keeping with the general RADIUS goal of smart server / simple NAS. 266 ARAP authenticates a connection in two phases. The first is a "Two- 267 Way DES" random number exchange, using the user's password as a key. 268 We say "Two-Way" because the ARAP NAS challenges the dial-in client 269 to authenticate itself, and the dial-in client challenges the ARAP 270 NAS to authenticate itself. 272 Specifically, ARAP does the following: 274 1. The NAS sends two 32-bit random numbers to the dial-in client 275 in an ARAP msg_auth_challenge packet. 277 2. The dial-in client uses the user's password to DES encrypt the 278 two random numbers sent to it by the NAS. The dial-in client then 279 sends this result, the user's name and two 32-bit random numbers 280 of its own back to the NAS in an ARAP msg_auth_request packet. 282 3. The NAS verifies the encrypted random numbers sent by the 283 dial-in client are what it expected. If so, it encrypts the dial- 284 in client's challenge using the password and sends it back to the 285 dial-in client in an ARAP msg_auth_response packet. 287 Note that if the dial-in client's response was wrong, meaning the 288 user has the wrong password, the server can initiate a retry sequence 289 up to the maximum amount of retries allowed by the NAS. In this case, 290 when the dial-in client receives the ARAP msg_auth_response packet it 291 will acknowledge it with an ARAP msg_auth_again packet. 293 After this first "DES Phase" the ARAP NAS MAY initiate a secondary 294 authentication phase using what Apple calls "Add-In Security 295 Modules." Security Modules are small pieces of code which run on both 296 the client and server and are allowed to read and write arbitrary 297 data across the communications link to perform additional 298 authentication functions. Various security token vendors use this 299 mechanism to authenticate ARA callers. 301 Although ARAP allows security modules to read and write anything they 302 like, all existing security modules use simple challenge and response 303 cycles, with perhaps some overall control information. This document 304 assumes all existing security modules can be supported with one or 305 more challenge/response cycles. 307 To complicate RADIUS and ARAP integration, ARAP sends down some 308 profile information after the DES Phase and before the Security 309 Module phase. This means that besides the responses to challenges, 310 this profile information must also be present, at somewhat unusual 311 times. Fortunately the information is only a few pieces of numeric 312 data related to passwords, which this document packs into a single 313 new attribute. 315 Presenting an Access-Request to RADIUS on behalf of an ARAP 316 connection is straightforward. The ARAP NAS generates the random 317 number challenge, and then receives the dial-in client's response, 318 the dial-in client's challenge, and the user's name. Assuming the 319 user is not a guest, the following information is forwarded in an 320 Access-Request packet: User-Name (up to 31 characters long), Framed- 321 Protocol (set to 3, ARAP), ARAP-Password, and any additional 322 attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, 323 NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 325 The Request Authenticator is a NAS-generated 16 octet random number. 326 The low-order 8 octets of this number are sent to the dial-in user as 327 the two 4 octet random numbers required in the ARAP 328 msg_auth_challenge packet. Octets 0-3 are the first random number and 329 Octets 4-7 are the second random number. [Probably needs to make 330 ordering clearer.] 332 The ARAP-Password in the Access-Request contains a 16 octet random 333 number field, and is used to carry the dial-in user's response to the 334 NAS challenge and the client's own challenge to the NAS. The high- 335 order octets contain the dial-in user's challenge to the NAS (2 32- 336 bit numbers, 8 octets) and the low-order octets contain the dial-in 337 user's response to the NAS challenge (2 32-bit numbers, 8 octets). 339 Only one of User-Password, CHAP-Password, or ARAP-Password needs to 340 be present in an Access-Request, or one or more EAP-Messages. 342 If the RADIUS server does not support ARAP it SHOULD return an 343 Access-Reject to the NAS. 345 If the RADIUS server does support ARAP, it should verify the user's 346 response using the Challenge (from the lower order 8 octets of the 347 Request Authenticator) and the user's response (from the low order 8 348 octets of the ARAP-Password). 350 If that authentication fails, the RADIUS server should return an 351 Access-Reject packet to the NAS, with optional Password-Retry and 352 Reply-Messages attributes. The presence of Password-Retry indicates 353 the ARAP NAS MAY choose to initiate another challenge-response cycle, 354 up to a total number of times equal to the integer value of the 355 Password-Retry attribute. 357 If the user is authenticated, the RADIUS server should return an 358 Access-Accept packet (Code 2) to the NAS, with ID and Response 359 Authenticator as usual, and attributes as follows: 361 Service-Type of Framed-Protocol. 363 Framed-Protocol of ARAP (3). 365 Session-Timeout with the maximum connect time for the user in 366 seconds. If the user is to be given unlimited time, Session- 367 Timeout should not be included in the Access-Accept packet, and 368 ARAP will treat that as an unlimited timeout (-1). 370 ARAP-Challenge-Response, containing 8 octets with the response to 371 the dial-in client's challenge. The RADIUS server calculates this 372 value by taking the dial-in client's challenge from the high order 373 8 octets of the ARAP-Password attribute and performing DES 374 encryption on this value with the authenticating user's password 375 as the key. If the user's password is less than 8 octets in 376 length, the password is padded at the end with NULL octets to a 377 length of 8 before using it as a key. If the user's password is 378 greater than 8 octets in length, an Access-Reject MUST be sent 379 instead. 381 ARAP-Features, containing information that the NAS should send to 382 the user in an ARAP "feature flags" packet. 384 Octet 0: If zero, user cannot change their password. If non- 385 zero user can. (RADIUS does not handle the password changing, 386 just the attribute which indicates whether ARAP indicates they 387 can.) 389 Octet 1: Minimum acceptable password length (0-8). 391 Octet 2-5: Password creation date in Macintosh format, defined 392 as 32 bits unsigned representing seconds since Midnight GMT 393 January 1, 1904. 395 Octet 6-9 Password Expiration Delta from create date in 396 seconds. 398 Octet 10-13: Current RADIUS time in Macintosh format 400 Optionally, a single Reply-Message with a string up to 253 401 characters long which MAY be sent down to the user to be displayed 402 in a sign-on/message of the day dialog. 404 Framed-AppleTalk-Network may be included. 406 Framed-AppleTalk-Zone, up to 32 characters in length, may be 407 included. 409 ARAP defines the notion of a list of zones for a user. Along with 410 a list of zone names, a Zone Access Flag is defined (and used by 411 the NAS) which says how to use the list of zone names. That is, 412 the dial-in user may only be allowed to see the Default Zone, or 413 only the zones in the zone list (inclusive) or any zone except 414 those in the zone list (exclusive). 416 The ARAP NAS handles this by having a named filter which contains 417 (at least) zone names. This solves the problem where a single 418 RADIUS server is managing disparate NAS clients who may not be 419 able to "see" all of the zone names in a user zone list. Zone 420 names only have meaning "at the NAS." The disadvantage of this 421 approach is that zone filters must be set up on the NAS somehow, 422 then referenced by the RADIUS Filter-Id. 424 ARAP-Zone-Access contains an integer which specifies how the "zone 425 list" for this user should be used. If this attribute is present 426 and the value is 2 or 4 then a Filter-Id must also be present to 427 name a zone list filter to apply the access flag to. 429 The inclusion of a Callback-Number or Callback-Id attribute in the 430 Access-Accept MAY cause the ARAP NAS to disconnect after sending 431 the Feature Flags to begin callback processing in an ARAP specific 432 way. 434 Other attributes may be present in the Access-Accept packet as well. 436 An ARAP NAS will need other information to finish bringing up the 437 connection to the dial in client, but this information can be 438 provided by the ARAP NAS without any help from RADIUS, either through 439 configuration by SNMP, a NAS administration program, or deduced by 440 the AppleTalk stack in the NAS. Specifically: 442 1. AppearAsNet and AppearAsNode values, sent to the client to tell 443 it what network and node numbers it should use in its datagram 444 packets. AppearAsNet can be taken from the Framed-AppleTalk- 445 Network attribute or from the configuration or AppleTalk stack on 446 the NAS. 448 2. The "default" zone - that is the name of the AppleTalk zone in 449 which the dial-in client will appear. (Or can be specified with 450 the Framed-AppleTalk-Zone attribute.) 452 3. Other very NAS specific stuff such as the name of the NAS, and 453 smartbuffering information. (Smartbuffering is an ARAP mechanism 454 for replacing common AppleTalk datagrams with small tokens, to 455 improve slow link performance in a few common traffic situations.) 457 4. "Zone List" information for this user. The ARAP specification 458 defines a "zone count" field which is actually unused. 460 RADIUS supports ARAP Security Modules in the following manner. 462 After DES authentication has been completed, the RADIUS server may 463 instruct the ARAP NAS to run one or more security modules for the 464 dial-in user. Although the underlying protocol supports executing 465 multiple security modules in series, in practice all current 466 implementations only allow executing one. Through the use of 467 multiple Access-Challenge requests, multiple modules can be 468 supported, but this facility will probably never be used. 470 We also assume that, even though ARAP allows a free-form dialog 471 between security modules on each end of the point-to-point link, in 472 actual practice all security modules can be reduced to a simple 473 challenge/response cycle. 475 If the RADIUS server wishes to instruct the ARAP NAS to run a 476 security module, it should send an Access-Challenge packet to the NAS 477 with (optionally) the State attribute, plus the ARAP-Challenge- 478 Response, ARAP-Features, and two more attributes: 480 ARAP-Security: a four octet security module signature, containing a 481 Macintosh OSType. 483 ARAP-Security-Data, a string to carry the actual security module 484 challenge and response. 486 When the security module finishes executing, the security module 487 response is passed in an ARAP-Security-Data attribute from the NAS 488 to the RADIUS server in a second Access-Request, also including the 489 State from the Access-Challenge. The authenticator field contains no 490 special information in this case, and this can be discerned by the 491 presence of the State attribute. 493 2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 495 The Extensible Authentication Protocol (EAP), described in [3], 496 provides a standard mechanism for support of additional 497 authentication methods within PPP. Through the use of EAP, support 498 for a number of authentication schemes may be added, including smart 499 cards, Kerberos, Public Key, One Time Passwords, and others. In 500 order to provide for support of EAP within RADIUS, two new 501 attributes, EAP-Message and Signature, are introduced in this 502 document. This section describes how these new attributes may be used 503 for providing EAP support within RADIUS. 505 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 506 encapsulated EAP Packets between the NAS and a backend security 507 server. While the conversation between the RADIUS server and the 508 backend security server will typically occur using a proprietary 509 protocol developed by the backend security server vendor, it is also 510 possible to use RADIUS-encapsulated EAP via the EAP-Message 511 attribute. This has the advantage of allowing the RADIUS server to 512 support EAP without the need for authentication-specific code, which 513 can instead reside on the backend security server. 515 2.3.1. Protocol Overview 517 The EAP conversation between the authenticating peer (dial-in user) 518 and the NAS begins with the negotiation of EAP within LCP. Once EAP 519 has been negotiated, the NAS MUST send an EAP-Request/Identity 520 message to the authenticating peer, unless identity is determined via 521 some other means such as Called-Station-Id or Calling-Station-Id. 522 The peer will then respond with an EAP-Response/Identity which the 523 the NAS will then forward to the RADIUS server in the EAP-Message 524 attribute of a RADIUS Access-Request packet. The RADIUS Server will 525 typically use the EAP-Response/Identity to determine which EAP type 526 is to be applied to the user. 528 In order to permit non-EAP aware RADIUS proxies to forward the 529 Access-Request packet, if the NAS sends the EAP-Request/Identity, the 530 NAS MUST copy the contents of the EAP-Response/Identity into the 531 User-Name attribute and MUST include the EAP-Response/Identity in the 532 User-Name attribute in every subsequent Access-Request. NAS-Port 533 SHOULD be included in the attributes issued by the NAS in the 534 Access-Request packet, and either NAS-Identifier or NAS-IP-Address 535 MUST be included. In order to permit forwarding of the Access-Reply 536 by EAP-unaware proxies, if a User-Name attribute was included in an 537 Access-Request, the RADIUS Server MUST include the User-Name 538 attribute in subsequent Access-Challenge and Access-Accept packets. 539 Without the User-Name attribute, accounting and billing becomes very 540 difficult to manage. 542 If identity is determined via another means such as Called-Station-Id 543 or Calling-Station-Id, the NAS MUST include these identifying 544 attributes in every Access-Request, and the RADIUS Server MUST 545 include them in every Access-Challenge and Access-Accept. 547 While this approach will save a round-trip, it cannot be universally 548 employed. There are circumstances in which the user's identity may 549 not be needed (such as when authentication and accounting is handled 550 based on Called-Station-Id or Calling-Station-Id), and therefore an 551 EAP-Request/Identity packet may not necessarily be issued by the NAS 552 to the authenticating peer. In cases where an EAP-Request/Identity 553 packet will not be sent, the NAS will send to the RADIUS server a 554 RADIUS Access-Request packet containing an EAP-Message attribute 555 signifying EAP-Start. EAP-Start is indicated by sending an EAP- 556 Message attribute with a length of 2 (no data). However, it should be 557 noted that since no User-Name attribute is included in the Access- 558 Request, this approach is not compatible with RADIUS as specified in 559 [1], nor can it easily be applied in situations where proxies are 560 deployed, such as roaming or shared use networks. 562 If the RADIUS server supports EAP, it MUST respond with an Access- 563 Challenge packet containing an EAP-Message attribute. If the RADIUS 564 server does not support EAP, it MUST respond with an Access-Reject. 565 The EAP-Message attribute includes an encapsulated EAP packet which 566 is then passed on to the authenticating peer. In the case where the 567 NAS does not initially send an EAP-Request/Identity message to the 568 peer, the Access-Challenge typically will contain an EAP-Message 569 attribute encapsulating an EAP-Request/Identity message, requesting 570 the dial-in user to identify themself. The NAS will then respond with 571 a RADIUS Access-Request packet containing an EAP-Message attribute 572 encapsulating an EAP-Response. The conversation continues until 573 either a RADIUS Access-Reject or Access-Accept packet is received. 575 Reception of a RADIUS Access-Reject packet, with or without an EAP- 576 Message attribute encapsulating EAP-Failure, MUST result in the NAS 577 issuing an LCP Terminate Request to the authenticating peer. A 578 RADIUS Access-Accept packet with an EAP-Message attribute 579 encapsulating EAP-Success successfully ends the authentication phase. 580 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain 581 all of the expected attributes which are currently returned in an 582 Access-Accept packet. 584 The above scenario creates a situation in which the NAS never needs 585 to manipulate an EAP packet. An alternative may be used in 586 situations where an EAP-Request/Identity message will always be sent 587 by the NAS to the authenticating peer. 589 For proxied RADIUS requests there are two methods of processing. If 590 the domain is determined based on the Called-Station-Id, the RADIUS 591 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 592 domain is determined based on the user's identity, the local RADIUS 593 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 594 packet. The response from the authenticating peer MUST be proxied to 595 the final authentication server. 597 For proxied RADIUS requests, the NAS may receive an Access-Reject 598 packet in response to its Access-Request/EAP-Identity packet. This 599 would occur if the message was proxied to a RADIUS Server which does 600 not support the EAP-Message extension. On receiving an Access-Reject, 601 the NAS MUST send an LCP Terminate Request to the authenticating 602 peer, and disconnect. 604 2.3.2. Retransmission 606 As noted in [3], the EAP authenticator (NAS) is responsible for 607 retransmission of packets between the authenticating peer and the 608 NAS. Thus if an EAP packet is lost in transit between the 609 authenticating peer and the NAS (or vice versa), the NAS will 610 retransmit. As in RADIUS [1], the RADIUS client is responsible for 611 retransmission of packets between the RADIUS client and the RADIUS 612 server. 614 Note that it may be necessary to adjust retransmission strategies and 615 authentication timeouts in certain cases. For example, when a token 616 card is used additional time may be required to allow the user to 617 find the card and enter the token. Since the NAS will typically not 618 have knowledge of the required parameters, these need to be provided 619 by the RADIUS server. This can be accomplished by inclusion of 620 Session-Timeout and Password-Retry attributes within the Access- 621 Challenge packet. 623 If Session-Timeout is present in an Access-Challenge packet that also 624 contains an EAP-Message, the value of the Session-Timeout provides 625 the NAS with the maximum number of seconds the NAS should wait for an 626 EAP-Response before retransmitting the EAP-Message to the dial-in 627 user. 629 2.3.3. Fragmentation 631 Using the EAP-Message attribute, it is possible for the RADIUS server 632 to encapsulate an EAP packet that is larger than the MTU on the link 633 between the NAS and the peer. Since it is not possible for the RADIUS 634 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 635 attribute may be included in an Access-Request packet containing an 636 EAP-Message attribute so as to provide the RADIUS server with this 637 information. 639 2.3.4. Examples 641 The example below shows the conversation between the authenticating 642 peer, NAS, and RADIUS server, for the case of a One Time Password 643 (OTP) authentication. OTP is used only for illustrative purposes; 644 other authentication protocols could also have been used, although 645 they might show somewhat different behavior. 647 Authenticating Peer NAS RADIUS Server 648 ------------------- --- ------------- 650 <- PPP LCP Request-EAP 651 auth 652 PPP LCP ACK-EAP 653 auth -> 654 <- PPP EAP-Request/ 655 Identity 656 PPP EAP-Response/ 657 Identity (MyID) -> 658 RADIUS 659 Access-Request/ 660 EAP-Message/ 661 EAP-Response/ 662 (MyID) -> 663 <- RADIUS 664 Access-Challenge/ 665 EAP-Message/EAP-Request 666 OTP/OTP Challenge 667 <- PPP EAP-Request/ 668 OTP/OTP Challenge 669 PPP EAP-Response/ 670 OTP, OTPpw -> 671 RADIUS 672 Access-Request/ 673 EAP-Message/ 674 EAP-Response/ 675 OTP, OTPpw -> 676 <- RADIUS 677 Access-Accept/ 678 EAP-Message/EAP-Success 679 (other attributes) 680 <- PPP EAP-Success 681 PPP Authentication 682 Phase complete, 683 NCP Phase starts 685 In the case where the NAS first sends an EAP-Start packet to the 686 RADIUS server, the conversation would appear as follows: 688 Authenticating Peer NAS RADIUS Server 689 ------------------- --- ------------- 691 <- PPP LCP Request-EAP 692 auth 693 PPP LCP ACK-EAP 694 auth -> 695 RADIUS 696 Access-Request/ 697 EAP-Message/Start -> 698 <- RADIUS 699 Access-Challenge/ 700 EAP-Message/Identity 701 <- PPP EA-Request/ 702 Identity 703 PPP EAP-Response/ 704 Identity (MyID) -> 705 RADIUS 706 Access-Request/ 707 EAP-Message/ 708 EAP-Response/ 709 (MyID) -> 710 <- RADIUS 711 Access-Challenge/ 712 EAP-Message/EAP-Request 713 OTP/OTP Challenge 714 <- PPP EAP-Request/ 715 OTP/OTP Challenge 716 PPP EAP-Response/ 717 OTP, OTPpw -> 718 RADIUS 719 Access-Request/ 720 EAP-Message/ 721 EAP-Response/ 722 OTP, OTPpw -> 723 <- RADIUS 724 Access-Accept/ 725 EAP-Message/EAP-Success 726 (other attributes) 727 <- PPP EAP-Success 728 PPP Authentication 729 Phase complete, 730 NCP Phase starts 732 In the case where the client fails EAP authentication, the 733 conversation would appear as follows: 735 Autheticating Peer NAS RADIUS Server 736 ------------------- --- ------------- 738 <- PPP LCP Request-EAP 739 auth 740 PPP LCP ACK-EAP 741 auth -> 742 Access-Request/ 743 EAP-Message/Start -> 744 <- RADIUS 745 Access-Challenge/ 746 EAP-Message/Identity 747 <- PPP EAP-Request/ 748 Identity 749 PPP EAP-Response/ 750 Identity (MyID) -> 751 RADIUS 752 Access-Request/ 753 EAP-Message/ 754 EAP-Response/ 755 (MyID) -> 756 <- RADIUS 757 Access-Challenge/ 758 EAP-Message/EAP-Request 759 OTP/OTP Challenge 760 <- PPP EAP-Request/ 761 OTP/OTP Challenge 762 PPP EAP-Response/ 763 OTP, OTPpw -> 764 RADIUS 765 Access-Request/ 766 EAP-Message/ 767 EAP-Response/ 768 OTP, OTPpw -> 769 <- RADIUS 770 Access-Reject/ 771 EAP-Message/EAP-Failure 773 <- PPP EAP-Failure 774 (client disconnected) 776 In the case that the RADIUS server or proxy does not support EAP- 777 Message, the conversation would appear as follows: 779 Authenticating Peer NAS RADIUS Server 780 ------------------- --- ------------- 782 <- PPP LCP Request-EAP 783 auth 784 PPP LCP ACK-EAP 785 auth -> 786 RADIUS 787 Access-Request/ 788 EAP-Message/Start -> 789 <- RADIUS 790 Access-Reject 791 <- PPP LCP Terminate 792 (User Disconnected) 794 In the case where the local RADIUS Server does support EAP-Message, 795 but the remote RADIUS Server does not, the conversation would appear 796 as follows: 798 Authenticating Peer NAS RADIUS Server 799 ------------------- --- ------------- 801 <- PPP LCP Request-EAP 802 auth 803 PPP LCP ACK-EAP 804 auth -> 805 RADIUS 806 Access-Request/ 807 EAP-Message/Start -> 808 <- RADIUS 809 Access-Challenge/ 810 EAP-Message/Identity 811 <- PPP EAP-Request/ 812 Identity 813 PPP EAP-Response/ 814 Identity 815 (MyID) -> 816 RADIUS 817 Access-Request/ 818 EAP-Message/EAP-Response/ 819 (MyID) -> 820 <- RADIUS 821 Access-Reject 822 (proxied from remote 823 RADIUS Server) 824 <- PPP LCP Terminate 825 (User Disconnected) 827 In the case where the authenticating peer does not support EAP, but 828 where EAP is required for that user, the conversation would appear as 829 follows: 831 Authenticating Peer NAS RADIUS Server 832 ------------------- --- ------------- 834 <- PPP LCP Request-EAP 835 auth 836 PPP LCP NAK-EAP 837 auth -> 838 <- PPP LCP Request-CHAP 839 auth 840 PPP LCP ACK-CHAP 841 auth -> 842 <- PPP CHAP Challenge 843 PPP CHAP Response -> 844 RADIUS 845 Access-Request/ 846 User-Name, 847 CHAP-Password -> 848 <- RADIUS 849 Access-Reject 850 <- PPP LCP Terminate 851 (User Disconnected) 853 In the case where the NAS does not support EAP, but where EAP is 854 required for that user, the conversation would appear as follows: 856 Authenticating Peer NAS RADIUS Server 857 ---------------- --- ------------- 859 <- PPP LCP Request-CHAP 860 auth 861 PP LCP ACK-CHAP 862 auth -> 863 <- PPP CHAP Challenge 864 PPP CHAP Response -> 865 RADIUS 866 Access-Request/ 867 User-Name, 868 CHAP-Password -> 869 <- RADIUS 870 Access-Reject 871 <- PPP LCP Terminate 872 (User Disconnected) 874 2.3.5. Alternative uses 876 Currently the conversation between the backend security server and 877 the RADIUS server is proprietary because of lack of standardization. 878 In order to increase standardization and provide interoperability 879 between Radius vendors and backend security vendors, it is 880 recommended that RADIUS-encapsulated EAP be used for this 881 conversation. 883 This has the advantage of allowing the RADIUS server to support EAP 884 without the need for authentication-specific code within the RADIUS 885 server. Authentication-specific code can then reside on a backend 886 security server instead. 888 In the case where RADIUS-encapsulated EAP is used in a conversation 889 between a RADIUS server and a backend security server, the security 890 server will typically return an Access-Accept/EAP-Success message 891 without inclusion of the expected attributes currently returned in an 892 Access-Accept. This means that the RADIUS server MUST add these 893 attributes prior to sending an Access-Accept/EAP-Success message to 894 the NAS. 896 3. Packet Format 898 Packet Format is identical to that defined in RFC 2138 and 2139. 900 4. Packet Types 902 Packet types are identical to those defined in RFC 2138 and 2139. 904 See "Table of Attributes" below to determine which types of packets 905 can contain which attributes defined here. 907 5. Attributes 909 RADIUS Attributes carry the specific authentication, authorization 910 and accounting details for the request and response. 912 Some attributes MAY be included more than once. The effect of this 913 is attribute specific, and is specified in each attribute 914 description. The order of attributes of the same type SHOULD be 915 preserved. The order of attributes of different types is not 916 required to be preserved. 918 The end of the list of attributes is indicated by the Length of the 919 RADIUS packet. 921 A summary of the attribute format is the same as in RFC 2138 but is 922 included here for ease of reference. The fields are transmitted from 923 left to right. 925 0 1 2 926 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Type | Length | Value ... 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Type 933 The Type field is one octet. Up-to-date values of the RADIUS Type 934 field are specified in the most recent "Assigned Numbers" RFC [5]. 935 Values 192-223 are reserved for experimental use, values 224-240 936 are reserved for implementation-specific use, and values 241-255 937 are reserved and should not be used. This specification concerns 938 the following values: 940 1-39 (refer to RFC 2138, "RADIUS") 941 40-51 (refer to RFC 2139, "RADIUS Accounting") 942 52 Acct-Input-Gigawords 943 53 Acct-Output-Gigawords 944 54 Unused 945 55 Event-Timestamp 946 56-59 Unused 947 60-63 (refer to RFC 2138, "RADIUS") 948 64-69 (refer to "RADIUS Attributes for Tunneling Support" draft) 949 70 ARAP-Password 950 71 ARAP-Features 951 72 ARAP-Zone-Access 952 73 ARAP-Security 953 74 ARAP-Security-Data 954 75 Password-Retry 955 76 Prompt 956 77 Connect-Info 957 78 Configuration-Token 958 79 EAP-Message 959 80 Signature 960 81-83 (refer to "RADIUS Attributes for Tunneling Support" draft) 961 84 ARAP-Challenge-Response 962 85 Acct-Interval-Time 963 86-191 Unused 965 Length 967 The Length field is one octet, and indicates the length of this 968 attribute including the Type, Length and Value fields. If an 969 attribute is received in a packet with an invalid Length, the 970 entire request should be silently discarded. 972 Value 974 The Value field is zero or more octets and contains information 975 specific to the attribute. The format and length of the Value 976 field is determined by the Type and Length fields. 978 The format of the value field is one of four data types. 980 string 0-253 octets 982 address 32 bit unsigned value, most significant octet first. 984 integer 32 bit unsigned value, most significant octet first. 986 time 32 bit unsigned value, most significant octet first -- 987 seconds since 00:00:00 GMT, January 1, 1970. 989 5.1. Acct-Input-Gigawords 991 Description 993 This attribute indicates how many times the Acct-Input-Octets 994 counter has wrapped around 2^32 over the course of this service 995 being provided, and can only be present in Accounting-Request 996 records where the Acct-Status-Type is set to Stop or Interim- 997 Update. 999 A summary of the Acct-Input-Gigawords attribute format is shown 1000 below. The fields are transmitted from left to right. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Type | Length | Value 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Value (cont) | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 Type 1012 52 for Acct-Input-Gigawords. 1014 Length 1016 6 1018 Value 1020 The Value field is four octets. 1022 5.2. Acct-Output-Gigawords 1024 Description 1026 This attribute indicates how many times the Acct-Output-Octets 1027 counter has wrapped around 2^32 in the course of delivering this 1028 service, and can only be present in Accounting-Request records 1029 where the Acct-Status-Type is set to Stop or Interim-Update. 1031 A summary of the Acct-Output-Gigawords attribute format is shown 1032 below. The fields are transmitted from left to right. 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Type | Length | Value 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Value (cont) | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Type 1044 53 for Acct-Output-Gigawords. 1046 Length 1048 6 1050 Value 1052 The Value field is four octets. 1054 5.3. Event-Timestamp 1056 Description 1058 This attribute is included in an Accounting-Request packet to 1059 record the time that this event occured on the NAS, in seconds 1060 since January 1, 1970 00:00 UTC. 1062 A summary of the Event-Timestamp attribute format is shown below. 1063 The fields are transmitted from left to right. 1065 0 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Type | Length | Value 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Value (cont) | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Type 1075 55 for Event-Timestamp 1077 Length 1079 6 1081 Value 1083 The Value field is four octets encoding an unsigned integer with 1084 the number of seconds since January 1, 1970 00:00 UTC. 1086 5.4. ARAP-Password 1088 Description 1089 This attribute is only present in an Access-Request packet 1090 containing a Framed-Protocol of ARAP. 1092 Only one of User-Password, CHAP-Password, or ARAP-Password needs 1093 to be present in an Access-Request, or one or more EAP-Messages. 1095 A summary of the ARAP-Password attribute format is shown below. The 1096 fields are transmitted from left to right. 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Type | Length | Value1 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Value2 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Value3 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Value4 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Type 1114 70 for ARAP-Password. 1116 Length 1118 18 1120 Value 1122 This attribute contains a 16 octet string, used to carry the 1123 dial-in user's response to the NAS challenge and the client's own 1124 challenge to the NAS. The high-order octets (Value1 and Value2) 1125 contain the dial-in user's challenge to the NAS (2 32-bit numbers, 1126 8 octets) and the low-order octets (Value3 and Value4) contain the 1127 dial-in user's response to the NAS challenge (2 32-bit numbers, 8 1128 octets). 1130 5.5. ARAP-Features 1132 Description 1133 This attribute is sent in an Access-Accept packet with Framed- 1134 Protocol of ARAP, and includes password information that the NAS 1135 should sent to the user in an ARAP "feature flags" packet. 1137 A summary of the ARAP-Features attribute format is shown below. The 1138 fields are transmitted from left to right. 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Type | Length | Value1 | Value2 | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Value3 | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Value4 | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Value5 | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 Type 1154 71 for ARAP-Features. 1156 Length 1158 16 1160 Value 1162 The Value field is a compound string containing information the 1163 NAS should send to the user in the ARAP "feature flags" packet. 1165 Value1: If zero, user cannot change their password. If non-zero 1166 user can. (RADIUS does not handle the password changing, just 1167 the attribute which indicates whether ARAP indicates they can.) 1169 Value2: Minimum acceptable password length, from 0 to 8. 1171 Value3: Password creation date in Macintosh format, defined as 1172 32 unsigned bits representing seconds since Midnight GMT 1173 January 1, 1904. 1175 Value4: Password Expiration Delta from create date in seconds. 1177 Value5: Current RADIUS time in Macintosh format. 1179 5.6. ARAP-Zone-Access 1181 Description 1183 This attribute is included in an Access-Accept packet with 1184 Framed-Protocol of ARAP to indicate how the ARAP zone list for the 1185 user should be used. 1187 A summary of the ARAP-Zone-Access attribute format is shown below. 1188 The fields are transmitted from left to right. 1190 0 1 2 3 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Type | Length | Value 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Value (cont) | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Type 1200 72 for ARAP-Zone-Access. 1202 Length 1204 6 1206 Value 1208 The Value field is four octets encoding an integer with one of the 1209 following values: 1211 1 Only allow access to default zone 1212 2 Use zone filter inclusively 1213 4 Use zone filter exclusively 1215 The value 3 is skipped, not because these are bit flags, but 1216 because 3 in some ARAP implementations means "all zones" which is 1217 the same as not specifying a list at all under RADIUS. 1219 If this attribute is present and the value is 2 or 4 then a 1220 Filter-Id must also be present to name a zone list filter to apply 1221 the access flag to. 1223 5.7. ARAP-Security 1225 Description 1227 This attribute identifies the ARAP Security Module to be used in 1228 an Access-Challenge packet. 1230 A summary of the ARAP-Security attribute format is shown below. The 1231 fields are transmitted from left to right. 1233 0 1 2 3 1234 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 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Type | Length | Value 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Value (cont) | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Type 1243 73 for ARAP-Security. 1245 Length 1247 6 1249 Value 1251 The Value field is four octets, containing an integer specifying 1252 the security module signature, which is a Macintosh OSType. 1253 (Macintosh OSTypes are 4 ascii characters cast as a 32-bit 1254 integer) 1256 5.8. ARAP-Security-Data 1258 Description 1260 This attribute contains the actual security module challenge or 1261 response, and can be found in Access-Challenge and Access-Request 1262 packets. 1264 A summary of the ARAP-Security-Data attribute format is shown below. 1265 The fields are transmitted from left to right. 1267 0 1 2 1268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Type | Length | String... 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Type 1275 74 for ARAP-Security-Data. 1277 Length 1279 >=3 1281 String 1283 The String field contains the security module challenge or 1284 response associated with the ARAP Security Module specified in 1285 ARAP-Security. 1287 5.9. Password-Retry 1289 Description 1291 This attribute MAY be included in an Access-Reject to indicate how 1292 many authentication attempts a user may be allowed to attempt 1293 before being disconnected. 1295 It is primarily intended for use with ARAP authentication. 1297 A summary of the Password-Retry attribute format is shown below. The 1298 fields are transmitted from left to right. 1300 0 1 2 3 1301 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 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Type | Length | Value 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Value (cont) | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Type 1309 75 for Password-Retry. 1311 Length 1313 6 1315 Value 1317 The Value field is four octets, containing an integer specifying 1318 the number of password retry attempts to permit the user. 1320 5.10. Prompt 1322 Description 1324 This attribute is used only in Access-Challenge packets, and 1325 indicates to the NAS whether it should echo the user's response as 1326 it is entered, or not echo it. 1328 A summary of the Prompt attribute format is shown below. The fields 1329 are transmitted from left to right. 1331 0 1 2 3 1332 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 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Type | Length | Value 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 Value (cont) | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 Type 1341 76 for Prompt. 1343 Length 1345 6 1347 Value 1349 The Value field is four octets. 1351 0 No Echo 1352 1 Echo 1354 5.11. Connect-Info 1356 Description 1358 This attribute is sent from the NAS to indicate the nature of the 1359 user's connection. 1361 The NAS MAY send this attribute in an Access-Request or 1362 Accounting-Request to indicate the nature of the user's 1363 connection. 1365 A summary of the Connect-Info attribute format is shown below. The 1366 fields are transmitted from left to right. 1368 0 1 2 1369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Type | Length | String... 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Type 1376 77 for Connect-Info. 1378 Length 1380 >= 3 1382 String 1384 The String field is encoded as UTF-8 [6] characters. The 1385 connection speed SHOULD be included at the beginning of the first 1386 Connect-Info attribute in the packet. If the transmit and receive 1387 connection speeds differ, they may both be included in the first 1388 attribute with the transmit speed first (the speed the NAS modem 1389 transmits at), a slash (/), the receive speed, then optionally 1390 other information. 1392 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1393 More than one Connect-Info attribute may be present in an 1394 Accounting-Request packet to accommodate expected efforts by ITU 1395 to have modems report more connection information in a standard 1396 format that might exceed 252 octets. 1398 5.12. Configuration-Token 1400 Description 1402 This attribute is for use in large distributed authentication 1403 networks based on proxy. It is sent from a RADIUS Proxy Server to 1404 a RADIUS Proxy Client in an Access-Accept to indicate a type of 1405 user profile to be used. It should not be sent to a NAS. 1407 A summary of the Configuration-Token attribute format is shown below. 1408 The fields are transmitted from left to right. 1410 0 1 2 1411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Type | Length | String ... 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 Type 1418 78 for Configuration-Token. 1420 Length 1422 >= 3 1424 String 1426 The String field is one or more octets. The actual format of the 1427 information is site or application specific, and a robust 1428 implementation SHOULD support the field as undistinguished octets. 1430 The codification of the range of allowed usage of this field is 1431 outside the scope of this specification. 1433 5.13. EAP-Message 1435 Description 1436 This attribute encapsulates Extended Access Protocol [3] packets 1437 so as to allow the NAS to authenticate dial-in users via EAP 1438 without having to understand the EAP protocol. 1440 The NAS places any EAP messages received from the user into one or 1441 more EAP attributes and forwards them to the RADIUS Server as part 1442 of the Access-Request, which can return EAP messages in Access- 1443 Challenge, Access-Accept and Access-Reject packets. 1445 A RADIUS Server receiving EAP messages that it does not understand 1446 SHOULD return an Access-Reject. 1448 The NAS places EAP messages received from the authenticating peer 1449 into one or more EAP-Message attributes and forwards them to the 1450 RADIUS Server within an Access-Request message. If multiple EAP- 1451 Messages are contained within an Access-Request or Access- 1452 Challenge packet, they MUST be in order and they MUST be 1453 consecutive attributes in the Access-Request or Access-Challenge 1454 packet. Access-Accept and Access-Reject packets SHOULD only have 1455 ONE EAP-Message attribute in them, containing EAP-Success or EAP- 1456 Failure. 1458 It is expected that EAP will be used to implement a variety of 1459 authentication methods, including methods involving strong 1460 cryptography. In order to prevent attackers from subverting EAP by 1461 attacking RADIUS/EAP, (for example, by modifying the EAP-Success 1462 or EAP-Failure packets) it is necessary that RADIUS/EAP provide 1463 integrity protection at least as strong as those used in the EAP 1464 methods themselves. 1466 Therefore the Signature attribute MUST be used to protect all 1467 Access-Request, Access-Challenge, Access-Accept, and Access-Reject 1468 packets containing an EAP-Message attribute. 1470 Access-Request packets including an EAP-Message attribute without 1471 a Signature attribute SHOULD be silently discarded by the RADIUS 1472 server. A RADIUS Server supporting EAP-Message MUST calculate the 1473 correct value of the Signature and silently discard the packet if 1474 it does not match the value sent. A RADIUS Server not supporting 1475 EAP-Message MUST return an Access-Reject if it receives an 1476 Access-Request containing an EAP-Message attribute. A RADIUS 1477 Server receiving an EAP-Message attribute that it does not 1478 understand MUST return an Access-Reject. 1480 Access-Challenge, Access-Accept, or Access-Reject packets 1481 including an EAP-Message attribute without a Signature attribute 1482 SHOULD be silently discarded by the NAS. A NAS supporting EAP- 1483 Message MUST calculate the correct value of the Signature and 1484 silently discard the packet if it does not match the value sent. 1486 A summary of the EAP-Message attribute format is shown below. The 1487 fields are transmitted from left to right. 1489 0 1 2 1490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Type | Length | String... 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 Type 1497 79 for EAP-Message. 1499 Length 1501 >= 3 (EAP packet enclosed) 1502 = 2 (EAP-Start message) 1504 String 1506 The String field contains EAP packets, as defined in [3]. If 1507 multiple EAP-Message attributes are present in a packet their 1508 values should be concatenated; this allows EAP packets longer than 1509 253 octets to be passed by RADIUS. 1511 5.14. Signature 1513 Description 1515 This attribute MAY be used to sign Access-Requests to prevent 1516 dictionary attacks on CHAP, ARAP or EAP authentication methods. 1517 It MAY be used in any Access-Request. It MUST be used in any 1518 Access-Request, Access-Accept, Access-Reject or Access-Challenge 1519 that includes an EAP-Message attribute. 1521 A RADIUS Server receiving an Access-Request with a Signature 1522 Attribute present MUST calculate the correct value of the 1523 Signature and silently discard the packet if it does not match the 1524 value sent. 1526 A RADIUS Client receiving an Access-Accept, Access-Reject or 1527 Access-Challenge with a Signature Attribute present MUST calculate 1528 the correct value of the Signature and silently discard the packet 1529 if it does not match the value sent. 1531 A summary of the Signature attribute format is shown below. The 1532 fields are transmitted from left to right. 1534 0 1 2 1535 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Type | Length | String... 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Type 1542 80 for Signature. 1544 Length 1546 18 1548 String 1550 When present in an Access-Request packet, Signature is an HMAC-MD5 1551 [7] checksum of the entire Access-Request packet, including Type, 1552 ID, Length and authenticator, using the shared secret as the key, 1553 as follows. 1555 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1556 Authenticator, Attributes) 1558 When the checksum is calculated the signature string should be 1559 considered to be sixteen octets of zero. 1561 For Access-Challenge, Access-Accept, and Access-Reject packets, 1562 the Signature is calculated as follows, using the Request- 1563 Authenticator from the Access-Request this packet is in reply to: 1565 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1566 Authenticator, Attributes) 1568 When the checksum is calculated the signature string should be 1569 considered to be sixteen octets of zero. The shared secret is 1570 used as the key for the HMAC-MD5 hash. The Signature is 1571 calculated and inserted in the packet before the Response 1572 Authenticator is calculated. 1574 This attribute is not needed if the User-Password attribute is 1575 present, but is useful for preventing dictionary attacks on other 1576 types of authentication. 1578 IP Security will eventually make this attribute unnecessary, so it 1579 should be considered an interim measure. 1581 5.15. ARAP-Challenge-Response 1583 Description 1585 This attribute is sent in an Access-Accept packet with Framed- 1586 Protocol of ARAP, and contains the response to the dial-in 1587 client's challenge. 1589 A summary of the ARAP-Challenge-Response attribute format is shown 1590 below. The fields are transmitted from left to right. 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Type | Length | Value... 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Type 1604 84 for ARAP-Challenge-Response. 1606 Length 1608 10 1610 Value 1612 The Value field contains an 8 octet response to the dial-in 1613 client's challenge. The RADIUS server calculates this value by 1614 taking the dial-in client's challenge from the high order 8 octets 1615 of the ARAP-Password attribute and performing DES encryption on 1616 this value with the authenticating user's password as the key. If 1617 the user's password is less than 8 octets in length, the password 1618 is padded at the end with NULL octets to a length of 8 before 1619 using it as a key. 1621 5.16. Acct-Interim-Interval 1623 Description 1625 This attribute indicates the number of seconds between each 1626 interim update in seconds for this specific session. This value 1627 can only appear in the Access-Accept message. 1629 A summary of the Acct-Interim-Interval attribute format is shown 1630 below. The fields are transmitted from left to right. 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Type | Length | Value 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Value (cont) | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Type 1642 85 for Acct-Interim-Interval. 1644 Length 1646 6 1648 Value 1650 The Value field contains the number of seconds between each 1651 interim update to be sent from the NAS for this session. The value 1652 MUST NOT be smaller than 60 and SHOULD NOT be less than 600. 1654 5.17. Table of Attributes 1656 The following table provides a guide to which attributes may be found 1657 in which kind of packets. Acct-Input-Gigawords, Acct-Output- 1658 Gigawords, and Event-Timestamp may have 0-1 instances in an 1659 Accounting-Request packet. Connect-Info may have 0+ instances in an 1660 Accounting-Request packet. The other attributes added in this 1661 document must not be present in an Accounting-Request. 1663 Request Accept Reject Challenge # Attribute 1664 0-1 0 0 0 70 ARAP-Password [Note 1] 1665 0 0-1 0 0-1 71 ARAP-Features 1666 0 0-1 0 0 72 ARAP-Zone-Access 1667 0-1 0 0 0-1 73 ARAP-Security 1668 0+ 0 0 0+ 74 ARAP-Security-Data 1669 0 0 0-1 0 75 Password-Retry 1670 0 0 0 0-1 76 Prompt 1671 0-1 0 0 0 77 Connect-Info 1672 0 0+ 0 0 78 Configuration-Token 1673 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 1674 0-1 0-1 0-1 0-1 80 Signature [Note 1] 1675 0 0-1 0 0-1 84 ARAP-Challenge-Response 1676 0 0-1 0 0 85 Acct-Interim-Interval 1677 Request Accept Reject Challenge # Attribute 1679 [Note 1] An Access-Request that contains either a User-Password or 1680 CHAP-Password or ARAP-Password or one or more EAP-Message attributes 1681 MUST NOT contain more than one type of those four attributes. If it 1682 does not contain any of those four attributes, it SHOULD contain a 1683 Signature. If any packet type contains an EAP-Message attribute it 1684 MUST also contain a Signature. 1686 The following table defines the above table entries. 1688 0 This attribute MUST NOT be present 1689 0+ Zero or more instances of this attribute MAY be present. 1690 0-1 Zero or one instance of this attribute MAY be present. 1691 1 Exactly one instance of this attribute MUST be present. 1693 6. Security Considerations 1695 Security issues are the primary topic of this document. 1697 Since the purpose of EAP is to provide enhanced security for PPP 1698 authentication, it is critical that RADIUS support for EAP be secure. 1699 In particular, the following issues must be addressed: 1701 Separation of EAP server and PPP authenticator 1702 Connection hijacking 1703 Man in the middle attacks 1704 Multiple databases 1705 Negotiation attacks 1707 6.1. Separation of EAP server and PPP authenticator 1709 It is possible for the EAP endpoints to mutually authenticate, 1710 negotiate a ciphersuite, and derive a session key for subsequent use 1711 in PPP encryption. 1713 This does not present an issue on the peer, since the peer and EAP 1714 client reside on the same machine; all that is required is for the 1715 EAP client module to pass the session key to the PPP encryption 1716 module. 1718 The situation may be more complex when EAP/RADIUS is used, since the 1719 PPP authenticator will typically not reside on the same machine as 1720 the EAP server. For example, the EAP server may be a backend security 1721 server, or a module residing on the RADIUS server. 1723 In the case where the EAP server and PPP authenticator reside on 1724 different machines, there are several implications for security. 1725 Firstly, mutual authentication will occur between the peer and the 1726 EAP server, not between the peer and the authenticator. This means 1727 that it is not possible for the peer to validate the identity of the 1728 NAS or tunnel server that it is speaking to. 1730 As described earlier, when EAP/RADIUS is used to encapsulate EAP 1731 packets, the Signature attribute is required in EAP/RADIUS Access- 1732 Requests sent from the NAS or tunnel server to the RADIUS server. 1733 Since the Signature attribute involves a HMAC-MD5 hash, it is 1734 possible for the RADIUS server to verify the integrity of the 1735 Access-Request as well as the NAS or tunnel server's identity. 1736 Similarly, Access-Challenge packets sent from the RADIUS server to 1737 the NAS are also authenticated and integrity protected using an 1738 HMAC-MD5 hash, enabling the NAS or tunnel server to determine the 1739 integrity of the packet and verify the identity of the RADIUS server. 1740 Morever, EAP packets sent via methods that contain their own 1741 integrity protection cannot be successfully modified by a rogue NAS 1742 or tunnel server. 1744 The second issue that arises in the case of an EAP server and PPP 1745 authenticator residing on different machines is that the session key 1746 negotiated between the peer and EAP server will need to be 1747 transmitted to the authenticator. Therefore a mechanism needs to be 1748 provided to transmit the session key from the EAP server to the 1749 authenticator or tunnel server that needs to use the key. The 1750 specification of this transit mechanism is outside the scope of this 1751 document. 1753 6.2. Connection hijacking 1755 In this form of attack, the attacker attempts to inject packets into 1756 the conversation between the NAS and the RADIUS server, or between 1757 the RADIUS server and the backend security server. RADIUS does not 1758 support encryption, and as described in [1], only Access-Reply and 1759 Access-Challenge packets are integrity protected. Moreover, the 1760 integrity protection mechanism described in [1] is weaker than that 1761 likely to be used by some EAP methods, making it possible to subvert 1762 those methods by attacking EAP/RADIUS. 1764 In order to provide for authentication of all packets in the EAP 1765 exchange, all EAP/RADIUS packets MUST be authenticated using the 1766 Signature attribute, as described previously. 1768 6.3. Man in the middle attacks 1770 Since RADIUS security is based on shared secrets, end-to-end security 1771 is not provided in the case where authentication or accounting 1772 packets are forwarded along a proxy chain. As a result, attackers 1773 gaining control of a RADIUS proxy will be able to modify EAP packets 1774 in transit. 1776 6.4. Multiple databases 1778 In many cases a backend security server will be deployed along with a 1779 RADIUS server in order to provide EAP services. Unless the backend 1780 security server also functions as a RADIUS server, two separate user 1781 databases will exist, each containing information about the security 1782 requirements for the user. This represents a weakness, since security 1783 may be compromised by a successful attack on either of the servers, 1784 or their backend databases. With multiple user databases, adding a 1785 new user may require multiple operations, increasing the chances for 1786 error. The problems are further magnified in the case where user 1787 information is also being kept in an LDAP server. In this case, three 1788 stores of user information may exist. 1790 In order to address these threats, consolidation of databases is 1791 recommended. This can be achieved by having both the RADIUS server 1792 and backend security server store information in the same backend 1793 database; by having the backend security server provide a full RADIUS 1794 implementation; or by consolidating both the backend security server 1795 and the RADIUS server onto the same machine. 1797 6.5. Negotiation attacks 1799 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 1800 RADIUS server causes the authenticating peer to choose a less secure 1801 authentication method so as to make it easier to obtain the user's 1802 password. For example, a session that would normally be authenticated 1803 with EAP would instead authenticated via CHAP or PAP; alternatively, 1804 a connection that would normally be authenticated via one EAP type 1805 occurs via a less secure EAP type, such as MD5. The threat posed by 1806 rogue devices, once thought to be remote, has gained currency given 1807 compromises of telephone company switching systems, such as those 1808 described in [8]. 1810 Protection against negotiation attacks requires the elimination of 1811 downward negotiations. This can be achieved via implementation of 1812 per-connection policy on the part of the authenticating peer, and 1813 per-user policy on the part of the RADIUS server. 1815 For the authenticating peer, authentication policy should be set on a 1816 per-connection basis. Per-connection policy allows an authenticating 1817 peer to negotiate EAP when calling one service, while negotiating 1818 CHAP for another service, even if both services are accessible via 1819 the same phone number. 1821 With per-connection policy, an authenticating peer will only attempt 1822 to negotiate EAP for a session in which EAP support is expected. As a 1823 result, there is a presumption that an authenticating peer selecting 1824 EAP requires that level of security. If it cannot be provided, it is 1825 likely that there is some kind of misconfiguration, or even that the 1826 authenticating peer is contacting the wrong server. Should the NAS 1827 not be able to negotiate EAP, or should the EAP-Request sent by the 1828 NAS be of a different EAP type than what is expected, the 1829 authenticating peer MUST disconnect. An authenticating peer expecting 1830 EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. 1832 For a NAS, it may not be possible to determine whether a user is 1833 required to authenticate with EAP until the user's identity is known. 1834 For example, for shared-uses NASes it is possible for one reseller to 1835 implement EAP while another does not. In such cases, if any users of 1836 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 1837 every call. This avoids forcing an EAP-capable client to do more than 1838 one authentication, which weakens security. 1840 If CHAP is negotiated, the NAS will pass the User-Name and CHAP- 1841 Password attributes to the RADIUS Server in an Access-Request packet. 1842 If the user is not required to use EAP, then the RADIUS Server will 1843 respond with an Access-Accept or Access-Reject packet as appropriate. 1844 However, if CHAP has been negotiated but EAP is required, the RADIUS 1845 server MUST respond with an Access-Reject, rather than an Access- 1846 Challenge/EAP-Message/EAP-Request packet. The authenticating peer 1847 MUST refuse to renegotiate authentication, even if the renegotiation 1848 is from CHAP to EAP. 1850 If EAP is negotiated but is not supported by the RADIUS proxy or 1851 server, then the server or proxy MUST respond with an Access-Reject. 1852 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 1853 user. This is the correct behavior since the authenticating peer is 1854 expecting EAP to be negotiated, and that expectation cannot be 1855 fulfilled. An EAP-capable authenticating peer MUST refuse to 1856 renegotiate the authentication protocol if EAP had initially been 1857 negotiated. Note that problems with a non-EAP capable RADIUS proxy 1858 could prove difficult to diagnose, since a user dialing in from one 1859 location (with an EAP-capable proxy) might be able to successfully 1860 authenticate via EAP, while the same user dialing into another 1861 location (and encountering an EAP-incapable proxy) might be 1862 consistently disconnected. 1864 7. References 1866 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 1867 Authentication Dial In User Service (RADIUS)", RFC 2138, April 1868 1997. 1870 [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1872 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 1873 Protocol (EAP)", RFC 2284, March 1998. 1875 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1876 Levels." BCP 14, RFC 2119, Harvard University, March, 1997. 1878 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1879 1700, USC/Information Sciences Institute, October 1994. 1881 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1882 2279, January 1998. 1884 [7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1885 for Message Authentication", RFC 2104, February 1997. 1887 [8] Slatalla, M., and Quittner, J., "Masters of Deception." 1888 HarperCollins, New York, 1995. 1890 8. Acknowledgements 1892 RADIUS and RADIUS Accounting were originally developed by Livingston 1893 Enterprises (now Lucent Remote Access Business Unit) for their 1894 PortMaster series of Network Access Servers. 1896 The section on ARAP is adopted with permission from "Using RADIUS to 1897 Authenticate Apple Remote Access Connections" by Ward Willats of Cyno 1898 Technologies (ward@cyno.com). 1900 The section on Acct-Interim-Interval is adopted with permission from 1901 an earlier Internet-Draft by Pat Calhoun of Sun Microsystems, Mark 1902 Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. 1904 The section on EAP is adopted with permission from an earlier 1905 Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of 1906 Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave 1907 Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of 1908 Microsoft for useful discussions of this problem space. 1910 9. Chair's Address 1912 The RADIUS working group can be contacted via the current chair: 1914 Carl Rigney 1915 Livingston Enterprises 1916 4464 Willow Road 1917 Pleasanton, California 94588 1918 Phone: +1 925 737 2100 1919 E-Mail: cdr@livingston.com 1921 10. Author's Address 1923 Questions about this memo can also be directed to: 1925 Carl Rigney 1926 Livingston Enterprises 1927 4464 Willow Road 1928 Pleasanton, California 94588 1930 E-Mail: cdr@livingston.com 1932 Questions on ARAP and RADIUS may be directed to: 1934 Ward Willats 1935 Cyno Technologies 1936 1082 Glen Echo Ave 1937 San Jose, CA 95125 1938 Phone: +1 408 297 7766 1939 E-Mail: ward@cyno.com 1941 Questions on EAP and RADIUS may be directed to any of the following: 1943 Pat R. Calhoun 1944 Network and Security Research Center 1945 Sun Microsystems, Inc. 1946 15 Network Circle 1947 Menlo Park, CA 94025 1948 Phone: +1 650 786 7733 1949 E-Mail: pcalhoun@eng.sun.com 1951 Allan C. Rubens 1952 Merit Network, Inc. 1953 4251 Plymouth Rd. 1954 Ann Arbor, MI 48105-2785 1955 Phone: +1 313 647 0417 1956 E-Mail: acr@merit.edu 1958 Bernard Aboba 1959 Microsoft Corporation 1960 One Microsoft Way 1961 Redmond, WA 98052 1962 Phone: +1 425 936 6605 1963 E-Mail: bernarda@microsoft.com 1965 11. Full Copyright Statement 1967 Copyright (C) The Internet Society (1997). All Rights Reserved. 1969 This document and translations of it may be copied and furnished to 1970 others, and derivative works that comment on or otherwise explain it 1971 or assist in its implmentation may be prepared, copied, published and 1972 distributed, in whole or in part, without restriction of any kind, 1973 provided that the above copyright notice and this paragraph are 1974 included on all such copies and derivative works. However, this 1975 document itself may not be modified in any way, such as by removing 1976 the copyright notice or references to the Internet Society or other 1977 Internet organizations, except as needed for the purpose of 1978 developing Internet standards in which case the procedures for 1979 copyrights defined in the Internet Standards process must be 1980 followed, or as required to translate it into languages other than 1981 English. 1983 The limited permissions granted above are perpetual and will not be 1984 revoked by the Internet Society or its successors or assigns. 1986 This document and the information contained herein is provided on an 1987 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1988 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1989 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1990 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1991 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1992 Table of Contents 1994 1. Introduction .......................................... 4 1995 1.1 Specification of Requirements ................... 4 1996 1.2 Terminology ..................................... 4 1998 2. Operation ............................................. 5 1999 2.1 RADIUS support for Interim Accounting Updates 2000 2.2 RADIUS support for Apple Remote Access 2001 Protocol .......................................................... 6 2002 2.3 RADIUS Support for Extensible Authentication 2003 Protocol (EAP) .................................................... 12 2004 2.3.1 Protocol Overview ............................... 12 2005 2.3.2 Retransmission .................................. 14 2006 2.3.3 Fragmentation ................................... 15 2007 2.3.4 Examples ........................................ 15 2008 2.3.5 Alternative uses ................................ 20 2010 3. Packet Format ......................................... 20 2012 4. Packet Types .......................................... 20 2014 5. Attributes ............................................ 20 2015 5.1 Acct-Input-Gigawords ............................ 22 2016 5.2 Acct-Output-Gigawords ........................... 23 2017 5.3 Event-Timestamp ................................. 24 2018 5.4 ARAP-Password ................................... 24 2019 5.5 ARAP-Features ................................... 25 2020 5.6 ARAP-Zone-Access ................................ 27 2021 5.7 ARAP-Security ................................... 28 2022 5.8 ARAP-Security-Data .............................. 28 2023 5.9 Password-Retry .................................. 29 2024 5.10 Prompt .......................................... 30 2025 5.11 Connect-Info .................................... 31 2026 5.12 Configuration-Token ............................. 32 2027 5.13 EAP-Message ..................................... 32 2028 5.14 Signature ....................................... 34 2029 5.15 ARAP-Challenge-Response ......................... 36 2030 5.16 Acct-Interim-Interval ........................... 37 2031 5.17 Table of Attributes ............................. 37 2033 6. Security Considerations ............................... 38 2034 6.1 Separation of EAP server and PPP authenticator 2035 6.2 Connection hijacking ............................ 39 2036 6.3 Man in the middle attacks ....................... 40 2037 6.4 Multiple databases .............................. 40 2038 6.5 Negotiation attacks ............................. 40 2040 7. References ............................................ 42 2042 8. Acknowledgements ...................................... 42 2044 9. Chair's Address ....................................... 43 2046 10. Author's Address ...................................... 43 2048 11. Full Copyright Statement .............................. 45