idnits 2.17.1 draft-ietf-radius-ext-04.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 47 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 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 318 has weird spacing: '...y a few piece...' == Line 380 has weird spacing: '...ute and perfo...' == Line 494 has weird spacing: '... passed in an...' == Line 891 has weird spacing: '...pecific code ...' == Line 1634 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 (May 1999) is 9111 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 1772 ** 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 (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RADIUS Working Group C Rigney 2 INTERNET-DRAFT Livingston 3 W Willats 4 Cyno Technologies 5 P Calhoun 6 Sun Microsystems 7 expires October 1999 May 1999 9 RADIUS Extensions 10 draft-ietf-radius-ext-04.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 This document is a submission to the RADIUS Working Group of the 18 Internet Engineering Task Force (IETF). Comments should be submitted 19 to the ietf-radius@livingston.com mailing list. 21 Distribution of this memo is unlimited. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 Abstract 45 This document describes additional attributes for carrying 46 authentication, authorization and accounting information between a 47 Network Access Server (NAS) and a shared Accounting Server using the 48 Remote Authentication Dial In User Service (RADIUS) protocol 49 described in RFC 2138 and RFC 2139. 51 Table of Contents 53 1. Introduction .......................................... 4 54 1.1 Specification of Requirements ................... 4 55 1.2 Terminology ..................................... 4 57 2. Operation ............................................. 5 58 2.1 RADIUS support for Interim Accounting Updates 5 59 2.2 RADIUS support for Apple Remote Access Protocol 6 60 2.3 RADIUS Support for Extensible Authentication 61 Protocol (EAP) ........................... 12 62 2.3.1 Protocol Overview ............................... 12 63 2.3.2 Retransmission .................................. 14 64 2.3.3 Fragmentation ................................... 14 65 2.3.4 Examples ........................................ 15 66 2.3.5 Alternative uses ................................ 20 68 3. Packet Format ......................................... 20 70 4. Packet Types .......................................... 20 72 5. Attributes ............................................ 20 73 5.1 Acct-Input-Gigawords ............................ 22 74 5.2 Acct-Output-Gigawords ........................... 23 75 5.3 Event-Timestamp ................................. 24 76 5.4 ARAP-Password ................................... 24 77 5.5 ARAP-Features ................................... 25 78 5.6 ARAP-Zone-Access ................................ 27 79 5.7 ARAP-Security ................................... 28 80 5.8 ARAP-Security-Data .............................. 28 81 5.9 Password-Retry .................................. 29 82 5.10 Prompt .......................................... 30 83 5.11 Connect-Info .................................... 31 84 5.12 Configuration-Token ............................. 32 85 5.13 EAP-Message ..................................... 32 86 5.14 Signature ....................................... 34 87 5.15 ARAP-Challenge-Response ......................... 36 88 5.16 Acct-Interim-Interval ........................... 37 89 5.17 Table of Attributes ............................. 37 90 5.18 Framed-Pool ..................................... 38 91 5.19 Table of Attributes ............................. 39 93 6. Security Considerations ............................... 40 94 6.1 Signature Security .............................. 40 95 6.2 EAP Security .................................... 40 96 6.2.1 Separation of EAP server and PPP authenticator 97 6.2.2 Connection hijacking ............................ 42 98 6.2.3 Man in the middle attacks ....................... 42 99 6.2.4 Multiple databases .............................. 42 100 6.2.5 Negotiation attacks ............................. 43 102 7. References ............................................ 44 104 8. Acknowledgements ...................................... 45 106 9. Chair's Address ....................................... 45 108 10. Author's Address ...................................... 45 110 11. Full Copyright Statement .............................. 47 112 1. Introduction 114 RFC 2138 [1] describes the RADIUS Protocol as it is implemented and 115 deployed today, and RFC 2139 [2] describes how Accounting can be 116 performed with RADIUS. 118 This memo suggests several additional Attributes that can be added to 119 RADIUS to perform various useful functions. These Attributes do not 120 have extensive field experience yet and should therefore be 121 considered experimental. 123 The Extensible Authentication Protocol (EAP) [3] is a PPP extension 124 that provides support for additional authentication methods within 125 PPP. This memo describes how the EAP-Message and Signature 126 attributes may be used for providing EAP support within RADIUS. 128 All attributes are comprised of variable length Type-Length-Value 3- 129 tuples. New attribute values can be added without disturbing 130 existing implementations of the protocol. 132 1.1. Specification of Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [4]. 138 An implementation is not compliant if it fails to satisfy one or more 139 of the must or must not requirements for the protocols it implements. 140 An implementation that satisfies all the must, must not, should and 141 should not requirements for its protocols is said to be 142 "unconditionally compliant"; one that satisfies all the must and must 143 not requirements but not all the should or should not requirements 144 for its protocols is said to be "conditionally compliant." 146 A NAS that does not implement a given service MUST NOT implement the 147 RADIUS attributes for that service. For example, a NAS that is 148 unable to offer ARAP service MUST NOT implement the RADIUS attributes 149 for ARAP. A NAS MUST treat a RADIUS access-request requesting an 150 unavailable service as an access-reject instead. 152 1.2. Terminology 154 This document uses the following terms: 156 service The NAS provides a service to the dial-in user, such as PPP 157 or Telnet. 159 session Each service provided by the NAS to a dial-in user 160 constitutes a session, with the beginning of the session 161 defined as the point where service is first provided and 162 the end of the session defined as the point where service 163 is ended. A user may have multiple sessions in parallel or 164 series if the NAS supports that, with each session 165 generating a separate start and stop accounting record. 167 silently discard 168 This means the implementation discards the packet without 169 further processing. The implementation SHOULD provide the 170 capability of logging the error, including the contents of 171 the silently discarded packet, and SHOULD record the event 172 in a statistics counter. 174 2. Operation 176 Operation is identical to that defined in RFC 2138 and 2139. 178 2.1. RADIUS support for Interim Accounting Updates 180 When a user is authenticated, a RADIUS server issues an Access-Accept 181 in response to a successful Access-Request. If the server wishes to 182 receive interim accounting messages for the given user it must 183 include the Acct-Interim-Interval RADIUS attribute in the message, 184 which indicates the interval in seconds between interim messages. 186 It is also possible to statically configure an interim value on the 187 NAS itself. Note that a locally configured value on the NAS MUST 188 override the value found in an Access-Accept. 190 This scheme does not break backward interoperability since a RADIUS 191 server not supporting this extension will simply not add the new 192 Attribute. NASes not supporting this extension will ignore the 193 Attribute. 195 Note that all information in an interim message is cumulative (i.e. 196 number of packets sent is the total since the beginning of the 197 session, not since the last interim message). 199 It is envisioned that an Interim Accounting record (with Acct- 200 Status-Type = Interim-Update (3)) would contain all of the attributes 201 normally found in an Accounting Stop message with the exception of 202 the Acct-Term-Cause attribute. 204 Since all the information is cumulative, a NAS MUST ensure that only 205 a single generation of an interim Accounting message for a given 206 session is present in the retransmission queue at any given time. 208 A NAS MAY use a fudge factor to add a random delay between Interim 209 Accounting messages for separate sessions. This will ensure that a 210 cycle where all messages are sent at once is prevented, such as might 211 otherwise occur if a primary link was recently restored and many 212 dial-up users were directed to the same NAS at once. 214 The Network and NAS CPU load of using Interim Updates should be 215 carefully considered, and appropriate values of Acct-Interim-Interval 216 chosen. 218 2.2. RADIUS support for Apple Remote Access Protocol 220 The RADIUS (Remote Authentication Dial-In User Service) protocol 221 provides a method that allows multiple dial-in Network Access Server 222 (NAS) devices to share a common authentication database. 224 The Apple Remote Access Protocol (ARAP) provides a method for sending 225 AppleTalk network traffic over point-to-point links, typically, but 226 not exclusively, asynchronous and ISDN switched-circuit connections. 227 Though Apple is moving toward ATCP on PPP for future remote access 228 services, ARAP is still a common way for the installed base of 229 Macintosh users to make remote network connections, and is likely to 230 remain so for some time. 232 ARAP is supported by several NAS vendors who also support PPP, IPX 233 and other protocols in the same NAS. ARAP connections in these 234 multi-protocol devices are often not authenticated with RADIUS, or if 235 they are, each vendor creates an individual solution to the problem. 237 This section describes the use of additional RADIUS attributes to 238 support ARAP. RADIUS client and server implementations that implement 239 this specification should be able to authenticate ARAP connections in 240 an interoperable manner. 242 This section assumes prior knowledge of RADIUS, and will go into some 243 detail on the operation of ARAP before entering a detailed discussion 244 of the proposed ARAP RADIUS attributes. 246 There are two features of ARAP this document does not address: 248 1. User initiated password changing. This is not part of RADIUS, 249 but can be implemented through a software process other than 250 RADIUS. 252 2. Out-of-Band messages. At any time, the NAS can send messages to 253 an ARA client which appear in a dialog box on the dial-in user's 254 screen. These are not part of authentication and do not belong 255 here. However, we note that a Reply-Message attribute in an 256 Access-Accept may be sent down to the user as a sign-on message of 257 the day string using the out-of-band channel. 259 We have tried to respect the spirit of the existing RADIUS protocol 260 as much as possible, making design decisions compatible with prior 261 art. Further, we have tried to strike a balance between flooding the 262 RADIUS world with new attributes, and hiding all of ARAP operation 263 within a single multiplexed ARAP attribute string or within Extended 264 Authentication Protocol (EAP) [3] machinery. 266 However, we feel ARAP is enough of a departure from PPP to warrant a 267 small set of similarly named attributes of its own. 269 We have assumed that an ARAP-aware RADIUS server will be able to do 270 DES encryption and generate security module challenges. This is in 271 keeping with the general RADIUS goal of smart server / simple NAS. 273 ARAP authenticates a connection in two phases. The first is a "Two- 274 Way DES" random number exchange, using the user's password as a key. 275 We say "Two-Way" because the ARAP NAS challenges the dial-in client 276 to authenticate itself, and the dial-in client challenges the ARAP 277 NAS to authenticate itself. 279 Specifically, ARAP does the following: 281 1. The NAS sends two 32-bit random numbers to the dial-in client 282 in an ARAP msg_auth_challenge packet. 284 2. The dial-in client uses the user's password to DES encrypt the 285 two random numbers sent to it by the NAS. The dial-in client then 286 sends this result, the user's name and two 32-bit random numbers 287 of its own back to the NAS in an ARAP msg_auth_request packet. 289 3. The NAS verifies the encrypted random numbers sent by the 290 dial-in client are what it expected. If so, it encrypts the dial- 291 in client's challenge using the password and sends it back to the 292 dial-in client in an ARAP msg_auth_response packet. 294 Note that if the dial-in client's response was wrong, meaning the 295 user has the wrong password, the server can initiate a retry sequence 296 up to the maximum amount of retries allowed by the NAS. In this case, 297 when the dial-in client receives the ARAP msg_auth_response packet it 298 will acknowledge it with an ARAP msg_auth_again packet. 300 After this first "DES Phase" the ARAP NAS MAY initiate a secondary 301 authentication phase using what Apple calls "Add-In Security 302 Modules." Security Modules are small pieces of code which run on both 303 the client and server and are allowed to read and write arbitrary 304 data across the communications link to perform additional 305 authentication functions. Various security token vendors use this 306 mechanism to authenticate ARA callers. 308 Although ARAP allows security modules to read and write anything they 309 like, all existing security modules use simple challenge and response 310 cycles, with perhaps some overall control information. This document 311 assumes all existing security modules can be supported with one or 312 more challenge/response cycles. 314 To complicate RADIUS and ARAP integration, ARAP sends down some 315 profile information after the DES Phase and before the Security 316 Module phase. This means that besides the responses to challenges, 317 this profile information must also be present, at somewhat unusual 318 times. Fortunately the information is only a few pieces of numeric 319 data related to passwords, which this document packs into a single 320 new attribute. 322 Presenting an Access-Request to RADIUS on behalf of an ARAP 323 connection is straightforward. The ARAP NAS generates the random 324 number challenge, and then receives the dial-in client's response, 325 the dial-in client's challenge, and the user's name. Assuming the 326 user is not a guest, the following information is forwarded in an 327 Access-Request packet: User-Name (up to 31 characters long), Framed- 328 Protocol (set to 3, ARAP), ARAP-Password, and any additional 329 attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, 330 NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 332 The Request Authenticator is a NAS-generated 16 octet random number. 333 The low-order 8 octets of this number are sent to the dial-in user as 334 the two 4 octet random numbers required in the ARAP 335 msg_auth_challenge packet. Octets 0-3 are the first random number and 336 Octets 4-7 are the second random number. [Probably needs to make 337 ordering clearer.] 339 The ARAP-Password in the Access-Request contains a 16 octet random 340 number field, and is used to carry the dial-in user's response to the 341 NAS challenge and the client's own challenge to the NAS. The high- 342 order octets contain the dial-in user's challenge to the NAS (2 32- 343 bit numbers, 8 octets) and the low-order octets contain the dial-in 344 user's response to the NAS challenge (2 32-bit numbers, 8 octets). 346 Only one of User-Password, CHAP-Password, or ARAP-Password needs to 347 be present in an Access-Request, or one or more EAP-Messages. 349 If the RADIUS server does not support ARAP it SHOULD return an 350 Access-Reject to the NAS. 352 If the RADIUS server does support ARAP, it should verify the user's 353 response using the Challenge (from the lower order 8 octets of the 354 Request Authenticator) and the user's response (from the low order 8 355 octets of the ARAP-Password). 357 If that authentication fails, the RADIUS server should return an 358 Access-Reject packet to the NAS, with optional Password-Retry and 359 Reply-Messages attributes. The presence of Password-Retry indicates 360 the ARAP NAS MAY choose to initiate another challenge-response cycle, 361 up to a total number of times equal to the integer value of the 362 Password-Retry attribute. 364 If the user is authenticated, the RADIUS server should return an 365 Access-Accept packet (Code 2) to the NAS, with ID and Response 366 Authenticator as usual, and attributes as follows: 368 Service-Type of Framed-Protocol. 370 Framed-Protocol of ARAP (3). 372 Session-Timeout with the maximum connect time for the user in 373 seconds. If the user is to be given unlimited time, Session- 374 Timeout should not be included in the Access-Accept packet, and 375 ARAP will treat that as an unlimited timeout (-1). 377 ARAP-Challenge-Response, containing 8 octets with the response to 378 the dial-in client's challenge. The RADIUS server calculates this 379 value by taking the dial-in client's challenge from the high order 380 8 octets of the ARAP-Password attribute and performing DES 381 encryption on this value with the authenticating user's password 382 as the key. If the user's password is less than 8 octets in 383 length, the password is padded at the end with NULL octets to a 384 length of 8 before using it as a key. If the user's password is 385 greater than 8 octets in length, an Access-Reject MUST be sent 386 instead. 388 ARAP-Features, containing information that the NAS should send to 389 the user in an ARAP "feature flags" packet. 391 Octet 0: If zero, user cannot change their password. If non- 392 zero user can. (RADIUS does not handle the password changing, 393 just the attribute which indicates whether ARAP indicates they 394 can.) 396 Octet 1: Minimum acceptable password length (0-8). 398 Octet 2-5: Password creation date in Macintosh format, defined 399 as 32 bits unsigned representing seconds since Midnight GMT 400 January 1, 1904. 402 Octet 6-9 Password Expiration Delta from create date in 403 seconds. 405 Octet 10-13: Current RADIUS time in Macintosh format 407 Optionally, a single Reply-Message with a string up to 253 408 characters long which MAY be sent down to the user to be displayed 409 in a sign-on/message of the day dialog. 411 Framed-AppleTalk-Network may be included. 413 Framed-AppleTalk-Zone, up to 32 characters in length, may be 414 included. 416 ARAP defines the notion of a list of zones for a user. Along with 417 a list of zone names, a Zone Access Flag is defined (and used by 418 the NAS) which says how to use the list of zone names. That is, 419 the dial-in user may only be allowed to see the Default Zone, or 420 only the zones in the zone list (inclusive) or any zone except 421 those in the zone list (exclusive). 423 The ARAP NAS handles this by having a named filter which contains 424 (at least) zone names. This solves the problem where a single 425 RADIUS server is managing disparate NAS clients who may not be 426 able to "see" all of the zone names in a user zone list. Zone 427 names only have meaning "at the NAS." The disadvantage of this 428 approach is that zone filters must be set up on the NAS somehow, 429 then referenced by the RADIUS Filter-Id. 431 ARAP-Zone-Access contains an integer which specifies how the "zone 432 list" for this user should be used. If this attribute is present 433 and the value is 2 or 4 then a Filter-Id must also be present to 434 name a zone list filter to apply the access flag to. 436 The inclusion of a Callback-Number or Callback-Id attribute in the 437 Access-Accept MAY cause the ARAP NAS to disconnect after sending 438 the Feature Flags to begin callback processing in an ARAP specific 439 way. 441 Other attributes may be present in the Access-Accept packet as well. 443 An ARAP NAS will need other information to finish bringing up the 444 connection to the dial in client, but this information can be 445 provided by the ARAP NAS without any help from RADIUS, either through 446 configuration by SNMP, a NAS administration program, or deduced by 447 the AppleTalk stack in the NAS. Specifically: 449 1. AppearAsNet and AppearAsNode values, sent to the client to tell 450 it what network and node numbers it should use in its datagram 451 packets. AppearAsNet can be taken from the Framed-AppleTalk- 452 Network attribute or from the configuration or AppleTalk stack on 453 the NAS. 455 2. The "default" zone - that is the name of the AppleTalk zone in 456 which the dial-in client will appear. (Or can be specified with 457 the Framed-AppleTalk-Zone attribute.) 459 3. Other very NAS specific stuff such as the name of the NAS, and 460 smartbuffering information. (Smartbuffering is an ARAP mechanism 461 for replacing common AppleTalk datagrams with small tokens, to 462 improve slow link performance in a few common traffic situations.) 464 4. "Zone List" information for this user. The ARAP specification 465 defines a "zone count" field which is actually unused. 467 RADIUS supports ARAP Security Modules in the following manner. 469 After DES authentication has been completed, the RADIUS server may 470 instruct the ARAP NAS to run one or more security modules for the 471 dial-in user. Although the underlying protocol supports executing 472 multiple security modules in series, in practice all current 473 implementations only allow executing one. Through the use of 474 multiple Access-Challenge requests, multiple modules can be 475 supported, but this facility will probably never be used. 477 We also assume that, even though ARAP allows a free-form dialog 478 between security modules on each end of the point-to-point link, in 479 actual practice all security modules can be reduced to a simple 480 challenge/response cycle. 482 If the RADIUS server wishes to instruct the ARAP NAS to run a 483 security module, it should send an Access-Challenge packet to the NAS 484 with (optionally) the State attribute, plus the ARAP-Challenge- 485 Response, ARAP-Features, and two more attributes: 487 ARAP-Security: a four octet security module signature, containing a 488 Macintosh OSType. 490 ARAP-Security-Data, a string to carry the actual security module 491 challenge and response. 493 When the security module finishes executing, the security module 494 response is passed in an ARAP-Security-Data attribute from the NAS 495 to the RADIUS server in a second Access-Request, also including the 496 State from the Access-Challenge. The authenticator field contains no 497 special information in this case, and this can be discerned by the 498 presence of the State attribute. 500 2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 502 The Extensible Authentication Protocol (EAP), described in [3], 503 provides a standard mechanism for support of additional 504 authentication methods within PPP. Through the use of EAP, support 505 for a number of authentication schemes may be added, including smart 506 cards, Kerberos, Public Key, One Time Passwords, and others. In 507 order to provide for support of EAP within RADIUS, two new 508 attributes, EAP-Message and Signature, are introduced in this 509 document. This section describes how these new attributes may be used 510 for providing EAP support within RADIUS. 512 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 513 encapsulated EAP Packets between the NAS and a backend security 514 server. While the conversation between the RADIUS server and the 515 backend security server will typically occur using a proprietary 516 protocol developed by the backend security server vendor, it is also 517 possible to use RADIUS-encapsulated EAP via the EAP-Message 518 attribute. This has the advantage of allowing the RADIUS server to 519 support EAP without the need for authentication-specific code, which 520 can instead reside on the backend security server. 522 2.3.1. Protocol Overview 524 The EAP conversation between the authenticating peer (dial-in user) 525 and the NAS begins with the negotiation of EAP within LCP. Once EAP 526 has been negotiated, the NAS MUST send an EAP-Request/Identity 527 message to the authenticating peer, unless identity is determined via 528 some other means such as Called-Station-Id or Calling-Station-Id. 529 The peer will then respond with an EAP-Response/Identity which the 530 the NAS will then forward to the RADIUS server in the EAP-Message 531 attribute of a RADIUS Access-Request packet. The RADIUS Server will 532 typically use the EAP-Response/Identity to determine which EAP type 533 is to be applied to the user. 535 In order to permit non-EAP aware RADIUS proxies to forward the 536 Access-Request packet, if the NAS sends the EAP-Request/Identity, the 537 NAS MUST copy the contents of the EAP-Response/Identity into the 538 User-Name attribute and MUST include the EAP-Response/Identity in the 539 User-Name attribute in every subsequent Access-Request. NAS-Port or 540 NAS-Port-Id SHOULD be included in the attributes issued by the NAS in 541 the Access-Request packet, and either NAS-Identifier or NAS-IP- 542 Address MUST be included. In order to permit forwarding of the 543 Access-Reply by EAP-unaware proxies, if a User-Name attribute was 544 included in an Access-Request, the RADIUS Server MUST include the 545 User-Name attribute in subsequent Access-Accept packets. Without the 546 User-Name attribute, accounting and billing becomes very difficult to 547 manage. 549 If identity is determined via another means such as Called-Station-Id 550 or Calling-Station-Id, the NAS MUST include these identifying 551 attributes in every Access-Request. 553 While this approach will save a round-trip, it cannot be universally 554 employed. There are circumstances in which the user's identity may 555 not be needed (such as when authentication and accounting is handled 556 based on Called-Station-Id or Calling-Station-Id), and therefore an 557 EAP-Request/Identity packet may not necessarily be issued by the NAS 558 to the authenticating peer. In cases where an EAP-Request/Identity 559 packet will not be sent, the NAS will send to the RADIUS server a 560 RADIUS Access-Request packet containing an EAP-Message attribute 561 signifying EAP-Start. EAP-Start is indicated by sending an EAP- 562 Message attribute with a length of 2 (no data). However, it should be 563 noted that since no User-Name attribute is included in the Access- 564 Request, this approach is not compatible with RADIUS as specified in 565 [1], nor can it easily be applied in situations where proxies are 566 deployed, such as roaming or shared use networks. 568 If the RADIUS server supports EAP, it MUST respond with an Access- 569 Challenge packet containing an EAP-Message attribute. If the RADIUS 570 server does not support EAP, it MUST respond with an Access-Reject. 571 The EAP-Message attribute includes an encapsulated EAP packet which 572 is then passed on to the authenticating peer. In the case where the 573 NAS does not initially send an EAP-Request/Identity message to the 574 peer, the Access-Challenge typically will contain an EAP-Message 575 attribute encapsulating an EAP-Request/Identity message, requesting 576 the dial-in user to identify themself. The NAS will then respond with 577 a RADIUS Access-Request packet containing an EAP-Message attribute 578 encapsulating an EAP-Response. The conversation continues until 579 either a RADIUS Access-Reject or Access-Accept packet is received. 581 Reception of a RADIUS Access-Reject packet, with or without an EAP- 582 Message attribute encapsulating EAP-Failure, MUST result in the NAS 583 issuing an LCP Terminate Request to the authenticating peer. A 584 RADIUS Access-Accept packet with an EAP-Message attribute 585 encapsulating EAP-Success successfully ends the authentication phase. 586 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain 587 all of the expected attributes which are currently returned in an 588 Access-Accept packet. 590 The above scenario creates a situation in which the NAS never needs 591 to manipulate an EAP packet. An alternative may be used in 592 situations where an EAP-Request/Identity message will always be sent 593 by the NAS to the authenticating peer. 595 For proxied RADIUS requests there are two methods of processing. If 596 the domain is determined based on the Called-Station-Id, the RADIUS 597 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 598 domain is determined based on the user's identity, the local RADIUS 599 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 600 packet. The response from the authenticating peer MUST be proxied to 601 the final authentication server. 603 For proxied RADIUS requests, the NAS may receive an Access-Reject 604 packet in response to its Access-Request/EAP-Identity packet. This 605 would occur if the message was proxied to a RADIUS Server which does 606 not support the EAP-Message extension. On receiving an Access-Reject, 607 the NAS MUST send an LCP Terminate Request to the authenticating 608 peer, and disconnect. 610 2.3.2. Retransmission 612 As noted in [3], the EAP authenticator (NAS) is responsible for 613 retransmission of packets between the authenticating peer and the 614 NAS. Thus if an EAP packet is lost in transit between the 615 authenticating peer and the NAS (or vice versa), the NAS will 616 retransmit. As in RADIUS [1], the RADIUS client is responsible for 617 retransmission of packets between the RADIUS client and the RADIUS 618 server. 620 Note that it may be necessary to adjust retransmission strategies and 621 authentication timeouts in certain cases. For example, when a token 622 card is used additional time may be required to allow the user to 623 find the card and enter the token. Since the NAS will typically not 624 have knowledge of the required parameters, these need to be provided 625 by the RADIUS server. This can be accomplished by inclusion of 626 Session-Timeout and Password-Retry attributes within the Access- 627 Challenge packet. 629 If Session-Timeout is present in an Access-Challenge packet that also 630 contains an EAP-Message, the value of the Session-Timeout provides 631 the NAS with the maximum number of seconds the NAS should wait for an 632 EAP-Response before retransmitting the EAP-Message to the dial-in 633 user. 635 2.3.3. Fragmentation 637 Using the EAP-Message attribute, it is possible for the RADIUS server 638 to encapsulate an EAP packet that is larger than the MTU on the link 639 between the NAS and the peer. Since it is not possible for the RADIUS 640 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 641 attribute may be included in an Access-Request packet containing an 642 EAP-Message attribute so as to provide the RADIUS server with this 643 information. 645 2.3.4. Examples 647 The example below shows the conversation between the authenticating 648 peer, NAS, and RADIUS server, for the case of a One Time Password 649 (OTP) authentication. OTP is used only for illustrative purposes; 650 other authentication protocols could also have been used, although 651 they might show somewhat different behavior. 653 Authenticating Peer NAS RADIUS Server 654 ------------------- --- ------------- 656 <- PPP LCP Request-EAP 657 auth 658 PPP LCP ACK-EAP 659 auth -> 660 <- PPP EAP-Request/ 661 Identity 662 PPP EAP-Response/ 663 Identity (MyID) -> 664 RADIUS 665 Access-Request/ 666 EAP-Message/ 667 EAP-Response/ 668 (MyID) -> 669 <- RADIUS 670 Access-Challenge/ 671 EAP-Message/EAP-Request 672 OTP/OTP Challenge 673 <- PPP EAP-Request/ 674 OTP/OTP Challenge 675 PPP EAP-Response/ 676 OTP, OTPpw -> 677 RADIUS 678 Access-Request/ 679 EAP-Message/ 680 EAP-Response/ 681 OTP, OTPpw -> 682 <- RADIUS 683 Access-Accept/ 684 EAP-Message/EAP-Success 685 (other attributes) 686 <- PPP EAP-Success 687 PPP Authentication 688 Phase complete, 689 NCP Phase starts 691 In the case where the NAS first sends an EAP-Start packet to the 692 RADIUS server, the conversation would appear as follows: 694 Authenticating Peer NAS RADIUS Server 695 ------------------- --- ------------- 697 <- PPP LCP Request-EAP 698 auth 699 PPP LCP ACK-EAP 700 auth -> 701 RADIUS 702 Access-Request/ 703 EAP-Message/Start -> 704 <- RADIUS 705 Access-Challenge/ 706 EAP-Message/Identity 707 <- PPP EA-Request/ 708 Identity 709 PPP EAP-Response/ 710 Identity (MyID) -> 711 RADIUS 712 Access-Request/ 713 EAP-Message/ 714 EAP-Response/ 715 (MyID) -> 716 <- RADIUS 717 Access-Challenge/ 718 EAP-Message/EAP-Request 719 OTP/OTP Challenge 720 <- PPP EAP-Request/ 721 OTP/OTP Challenge 722 PPP EAP-Response/ 723 OTP, OTPpw -> 724 RADIUS 725 Access-Request/ 726 EAP-Message/ 727 EAP-Response/ 728 OTP, OTPpw -> 729 <- RADIUS 730 Access-Accept/ 731 EAP-Message/EAP-Success 732 (other attributes) 734 <- PPP EAP-Success 735 PPP Authentication 736 Phase complete, 737 NCP Phase starts 739 In the case where the client fails EAP authentication, the 740 conversation would appear as follows: 742 Autheticating Peer NAS RADIUS Server 743 ------------------- --- ------------- 745 <- PPP LCP Request-EAP 746 auth 747 PPP LCP ACK-EAP 748 auth -> 749 Access-Request/ 750 EAP-Message/Start -> 751 <- RADIUS 752 Access-Challenge/ 753 EAP-Message/Identity 754 <- PPP EAP-Request/ 755 Identity 756 PPP EAP-Response/ 757 Identity (MyID) -> 758 RADIUS 759 Access-Request/ 760 EAP-Message/ 761 EAP-Response/ 762 (MyID) -> 763 <- RADIUS 764 Access-Challenge/ 765 EAP-Message/EAP-Request 766 OTP/OTP Challenge 767 <- PPP EAP-Request/ 768 OTP/OTP Challenge 769 PPP EAP-Response/ 770 OTP, OTPpw -> 771 RADIUS 772 Access-Request/ 773 EAP-Message/ 774 EAP-Response/ 775 OTP, OTPpw -> 776 <- RADIUS 777 Access-Reject/ 778 EAP-Message/EAP-Failure 779 <- PPP EAP-Failure 780 (client disconnected) 782 In the case that the RADIUS server or proxy does not support EAP- 783 Message, the conversation would appear as follows: 785 Authenticating Peer NAS RADIUS Server 786 ------------------- --- ------------- 788 <- PPP LCP Request-EAP 789 auth 790 PPP LCP ACK-EAP 791 auth -> 792 RADIUS 793 Access-Request/ 794 EAP-Message/Start -> 795 <- RADIUS 796 Access-Reject 797 <- PPP LCP Terminate 798 (User Disconnected) 800 In the case where the local RADIUS Server does support EAP-Message, 801 but the remote RADIUS Server does not, the conversation would appear 802 as follows: 804 Authenticating Peer NAS RADIUS Server 805 ------------------- --- ------------- 807 <- PPP LCP Request-EAP 808 auth 809 PPP LCP ACK-EAP 810 auth -> 811 RADIUS 812 Access-Request/ 813 EAP-Message/Start -> 814 <- RADIUS 815 Access-Challenge/ 816 EAP-Message/Identity 817 <- PPP EAP-Request/ 818 Identity 819 PPP EAP-Response/ 820 Identity 821 (MyID) -> 822 RADIUS 823 Access-Request/ 824 EAP-Message/EAP-Response/ 825 (MyID) -> 826 <- RADIUS 827 Access-Reject 828 (proxied from remote 829 RADIUS Server) 831 <- PPP LCP Terminate 832 (User Disconnected) 834 In the case where the authenticating peer does not support EAP, but 835 where EAP is required for that user, the conversation would appear as 836 follows: 838 Authenticating Peer NAS RADIUS Server 839 ------------------- --- ------------- 841 <- PPP LCP Request-EAP 842 auth 843 PPP LCP NAK-EAP 844 auth -> 845 <- PPP LCP Request-CHAP 846 auth 847 PPP LCP ACK-CHAP 848 auth -> 849 <- PPP CHAP Challenge 850 PPP CHAP Response -> 851 RADIUS 852 Access-Request/ 853 User-Name, 854 CHAP-Password -> 855 <- RADIUS 856 Access-Reject 857 <- PPP LCP Terminate 858 (User Disconnected) 860 In the case where the NAS does not support EAP, but where EAP is 861 required for that user, the conversation would appear as follows: 863 Authenticating Peer NAS RADIUS Server 864 ---------------- --- ------------- 866 <- PPP LCP Request-CHAP 867 auth 868 PP LCP ACK-CHAP 869 auth -> 870 <- PPP CHAP Challenge 871 PPP CHAP Response -> 872 RADIUS 873 Access-Request/ 874 User-Name, 875 CHAP-Password -> 876 <- RADIUS 877 Access-Reject 878 <- PPP LCP Terminate 879 (User Disconnected) 881 2.3.5. Alternative uses 883 Currently the conversation between the backend security server and 884 the RADIUS server is proprietary because of lack of standardization. 885 In order to increase standardization and provide interoperability 886 between Radius vendors and backend security vendors, it is 887 recommended that RADIUS-encapsulated EAP be used for this 888 conversation. 890 This has the advantage of allowing the RADIUS server to support EAP 891 without the need for authentication-specific code within the RADIUS 892 server. Authentication-specific code can then reside on a backend 893 security server instead. 895 In the case where RADIUS-encapsulated EAP is used in a conversation 896 between a RADIUS server and a backend security server, the security 897 server will typically return an Access-Accept/EAP-Success message 898 without inclusion of the expected attributes currently returned in an 899 Access-Accept. This means that the RADIUS server MUST add these 900 attributes prior to sending an Access-Accept/EAP-Success message to 901 the NAS. 903 3. Packet Format 905 Packet Format is identical to that defined in RFC 2138 and 2139. 907 4. Packet Types 909 Packet types are identical to those defined in RFC 2138 and 2139. 911 See "Table of Attributes" below to determine which types of packets 912 can contain which attributes defined here. 914 5. Attributes 916 RADIUS Attributes carry the specific authentication, authorization 917 and accounting details for the request and response. 919 Some attributes MAY be included more than once. The effect of this 920 is attribute specific, and is specified in each attribute 921 description. The order of attributes of the same type SHOULD be 922 preserved. The order of attributes of different types is not 923 required to be preserved. 925 The end of the list of attributes is indicated by the Length of the 926 RADIUS packet. 928 A summary of the attribute format is the same as in RFC 2138 but is 929 included here for ease of reference. The fields are transmitted from 930 left to right. 932 0 1 2 933 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Type | Length | Value ... 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Type 940 The Type field is one octet. Up-to-date values of the RADIUS Type 941 field are specified in the most recent "Assigned Numbers" RFC [5]. 942 Values 192-223 are reserved for experimental use, values 224-240 943 are reserved for implementation-specific use, and values 241-255 944 are reserved and should not be used. This specification concerns 945 the following values: 947 1-39 (refer to RFC 2138, "RADIUS") 948 40-51 (refer to RFC 2139, "RADIUS Accounting") 949 52 Acct-Input-Gigawords 950 53 Acct-Output-Gigawords 951 54 Unused 952 55 Event-Timestamp 953 56-59 Unused 954 60-63 (refer to RFC 2138, "RADIUS") 955 64-69 (refer to "RADIUS Attributes for Tunneling Support" draft) 956 70 ARAP-Password 957 71 ARAP-Features 958 72 ARAP-Zone-Access 959 73 ARAP-Security 960 74 ARAP-Security-Data 961 75 Password-Retry 962 76 Prompt 963 77 Connect-Info 964 78 Configuration-Token 965 79 EAP-Message 966 80 Signature 967 81-83 (refer to "RADIUS Attributes for Tunneling Support" draft) 968 84 ARAP-Challenge-Response 969 85 Acct-Interval-Time 970 86 (refer to "RADIUS Attributes for Tunneling Support" draft) 971 87 NAS-Port-Id 972 88 Framed-Pool 973 89-191 Unused 975 Length 977 The Length field is one octet, and indicates the length of this 978 attribute including the Type, Length and Value fields. If an 979 attribute is received in a packet with an invalid Length, the 980 entire request should be silently discarded. 982 Value 984 The Value field is zero or more octets and contains information 985 specific to the attribute. The format and length of the Value 986 field is determined by the Type and Length fields. 988 Note that a "string" in RADIUS does not terminate with a NUL (hex 989 00). The Attribute has a length field and does not use a 990 terminator. Strings may contain UTF-8 characters or 8-bit binary 991 data and servers and clients should be able to deal with embedded 992 nulls. RADIUS implementers using C are cautioned not to use 993 strcpy() when handling strings. 995 The format of the value field is one of four data types. 997 string 1-253 octets. Strings of length zero (0) MUST NOT be 998 sent; omit the entire attribute instead. 1000 address 32 bit unsigned value, most significant octet first. 1002 integer 32 bit unsigned value, most significant octet first. 1004 time 32 bit unsigned value, most significant octet first -- 1005 seconds since 00:00:00 UTC, January 1, 1970. 1007 5.1. Acct-Input-Gigawords 1009 Description 1011 This attribute indicates how many times the Acct-Input-Octets 1012 counter has wrapped around 2^32 over the course of this service 1013 being provided, and can only be present in Accounting-Request 1014 records where the Acct-Status-Type is set to Stop or Interim- 1015 Update. 1017 A summary of the Acct-Input-Gigawords attribute format is shown 1018 below. The fields are transmitted from left to right. 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Type | Length | Value 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Value (cont) | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Type 1030 52 for Acct-Input-Gigawords. 1032 Length 1034 6 1036 Value 1038 The Value field is four octets. 1040 5.2. Acct-Output-Gigawords 1042 Description 1044 This attribute indicates how many times the Acct-Output-Octets 1045 counter has wrapped around 2^32 in the course of delivering this 1046 service, and can only be present in Accounting-Request records 1047 where the Acct-Status-Type is set to Stop or Interim-Update. 1049 A summary of the Acct-Output-Gigawords attribute format is shown 1050 below. The fields are transmitted from left to right. 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Type | Length | Value 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Value (cont) | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 Type 1061 53 for Acct-Output-Gigawords. 1063 Length 1065 6 1067 Value 1069 The Value field is four octets. 1071 5.3. Event-Timestamp 1073 Description 1075 This attribute is included in an Accounting-Request packet to 1076 record the time that this event occured on the NAS, in seconds 1077 since January 1, 1970 00:00 UTC. 1079 A summary of the Event-Timestamp attribute format is shown below. 1080 The fields are transmitted from left to right. 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Type | Length | Value 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Value (cont) | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Type 1092 55 for Event-Timestamp 1094 Length 1096 6 1098 Value 1100 The Value field is four octets encoding an unsigned integer with 1101 the number of seconds since January 1, 1970 00:00 UTC. 1103 5.4. ARAP-Password 1105 Description 1107 This attribute is only present in an Access-Request packet 1108 containing a Framed-Protocol of ARAP. 1110 Only one of User-Password, CHAP-Password, or ARAP-Password needs 1111 to be present in an Access-Request, or one or more EAP-Messages. 1113 A summary of the ARAP-Password attribute format is shown below. The 1114 fields are transmitted from left to right. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Length | Value1 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Value2 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Value3 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Value4 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 Type 1132 70 for ARAP-Password. 1134 Length 1136 18 1138 Value 1140 This attribute contains a 16 octet string, used to carry the 1141 dial-in user's response to the NAS challenge and the client's own 1142 challenge to the NAS. The high-order octets (Value1 and Value2) 1143 contain the dial-in user's challenge to the NAS (2 32-bit numbers, 1144 8 octets) and the low-order octets (Value3 and Value4) contain the 1145 dial-in user's response to the NAS challenge (2 32-bit numbers, 8 1146 octets). 1148 5.5. ARAP-Features 1150 Description 1152 This attribute is sent in an Access-Accept packet with Framed- 1153 Protocol of ARAP, and includes password information that the NAS 1154 should sent to the user in an ARAP "feature flags" packet. 1156 A summary of the ARAP-Features attribute format is shown below. The 1157 fields are transmitted from left to right. 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Type | Length | Value1 | Value2 | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Value3 | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Value4 | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Value5 | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 Type 1173 71 for ARAP-Features. 1175 Length 1177 16 1179 Value 1181 The Value field is a compound string containing information the 1182 NAS should send to the user in the ARAP "feature flags" packet. 1184 Value1: If zero, user cannot change their password. If non-zero 1185 user can. (RADIUS does not handle the password changing, just 1186 the attribute which indicates whether ARAP indicates they can.) 1188 Value2: Minimum acceptable password length, from 0 to 8. 1190 Value3: Password creation date in Macintosh format, defined as 1191 32 unsigned bits representing seconds since Midnight GMT 1192 January 1, 1904. 1194 Value4: Password Expiration Delta from create date in seconds. 1196 Value5: Current RADIUS time in Macintosh format. 1198 5.6. ARAP-Zone-Access 1200 Description 1202 This attribute is included in an Access-Accept packet with 1203 Framed-Protocol of ARAP to indicate how the ARAP zone list for the 1204 user should be used. 1206 A summary of the ARAP-Zone-Access attribute format is shown below. 1207 The fields are transmitted from left to right. 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Type | Length | Value 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 Value (cont) | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 Type 1219 72 for ARAP-Zone-Access. 1221 Length 1223 6 1225 Value 1227 The Value field is four octets encoding an integer with one of the 1228 following values: 1230 1 Only allow access to default zone 1231 2 Use zone filter inclusively 1232 4 Use zone filter exclusively 1234 The value 3 is skipped, not because these are bit flags, but 1235 because 3 in some ARAP implementations means "all zones" which is 1236 the same as not specifying a list at all under RADIUS. 1238 If this attribute is present and the value is 2 or 4 then a 1239 Filter-Id must also be present to name a zone list filter to apply 1240 the access flag to. 1242 5.7. ARAP-Security 1244 Description 1246 This attribute identifies the ARAP Security Module to be used in 1247 an Access-Challenge packet. 1249 A summary of the ARAP-Security attribute format is shown below. The 1250 fields are transmitted from left to right. 1252 0 1 2 3 1253 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 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Type | Length | Value 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 Value (cont) | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Type 1262 73 for ARAP-Security. 1264 Length 1266 6 1268 Value 1270 The Value field is four octets, containing an integer specifying 1271 the security module signature, which is a Macintosh OSType. 1272 (Macintosh OSTypes are 4 ascii characters cast as a 32-bit 1273 integer) 1275 5.8. ARAP-Security-Data 1277 Description 1279 This attribute contains the actual security module challenge or 1280 response, and can be found in Access-Challenge and Access-Request 1281 packets. 1283 A summary of the ARAP-Security-Data attribute format is shown below. 1284 The fields are transmitted from left to right. 1286 0 1 2 1287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Type | Length | String... 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 Type 1294 74 for ARAP-Security-Data. 1296 Length 1298 >=3 1300 String 1302 The String field contains the security module challenge or 1303 response associated with the ARAP Security Module specified in 1304 ARAP-Security. 1306 5.9. Password-Retry 1308 Description 1310 This attribute MAY be included in an Access-Reject to indicate how 1311 many authentication attempts a user may be allowed to attempt 1312 before being disconnected. 1314 It is primarily intended for use with ARAP authentication. 1316 A summary of the Password-Retry attribute format is shown below. The 1317 fields are transmitted from left to right. 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Type | Length | Value 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 Value (cont) | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 Type 1328 75 for Password-Retry. 1330 Length 1332 6 1334 Value 1336 The Value field is four octets, containing an integer specifying 1337 the number of password retry attempts to permit the user. 1339 5.10. Prompt 1341 Description 1343 This attribute is used only in Access-Challenge packets, and 1344 indicates to the NAS whether it should echo the user's response as 1345 it is entered, or not echo it. 1347 A summary of the Prompt attribute format is shown below. The fields 1348 are transmitted from left to right. 1350 0 1 2 3 1351 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 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Type | Length | Value 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 Value (cont) | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 Type 1360 76 for Prompt. 1362 Length 1364 6 1366 Value 1368 The Value field is four octets. 1370 0 No Echo 1371 1 Echo 1373 5.11. Connect-Info 1375 Description 1377 This attribute is sent from the NAS to indicate the nature of the 1378 user's connection. 1380 The NAS MAY send this attribute in an Access-Request or 1381 Accounting-Request to indicate the nature of the user's 1382 connection. 1384 A summary of the Connect-Info attribute format is shown below. The 1385 fields are transmitted from left to right. 1387 0 1 2 1388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Type | Length | String... 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 Type 1395 77 for Connect-Info. 1397 Length 1399 >= 3 1401 String 1403 The String field is encoded as UTF-8 [6] characters. The 1404 connection speed SHOULD be included at the beginning of the first 1405 Connect-Info attribute in the packet. If the transmit and receive 1406 connection speeds differ, they may both be included in the first 1407 attribute with the transmit speed first (the speed the NAS modem 1408 transmits at), a slash (/), the receive speed, then optionally 1409 other information. 1411 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1412 More than one Connect-Info attribute may be present in an 1413 Accounting-Request packet to accommodate expected efforts by ITU 1414 to have modems report more connection information in a standard 1415 format that might exceed 252 octets. 1417 5.12. Configuration-Token 1419 Description 1421 This attribute is for use in large distributed authentication 1422 networks based on proxy. It is sent from a RADIUS Proxy Server to 1423 a RADIUS Proxy Client in an Access-Accept to indicate a type of 1424 user profile to be used. It should not be sent to a NAS. 1426 A summary of the Configuration-Token attribute format is shown below. 1427 The fields are transmitted from left to right. 1429 0 1 2 1430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Type | Length | String ... 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 Type 1437 78 for Configuration-Token. 1439 Length 1441 >= 3 1443 String 1445 The String field is one or more octets. The actual format of the 1446 information is site or application specific, and a robust 1447 implementation SHOULD support the field as undistinguished octets. 1449 The codification of the range of allowed usage of this field is 1450 outside the scope of this specification. 1452 5.13. EAP-Message 1454 Description 1455 This attribute encapsulates Extended Access Protocol [3] packets 1456 so as to allow the NAS to authenticate dial-in users via EAP 1457 without having to understand the EAP protocol. 1459 The NAS places any EAP messages received from the user into one or 1460 more EAP attributes and forwards them to the RADIUS Server as part 1461 of the Access-Request, which can return EAP messages in Access- 1462 Challenge, Access-Accept and Access-Reject packets. 1464 A RADIUS Server receiving EAP messages that it does not understand 1465 SHOULD return an Access-Reject. 1467 The NAS places EAP messages received from the authenticating peer 1468 into one or more EAP-Message attributes and forwards them to the 1469 RADIUS Server within an Access-Request message. If multiple EAP- 1470 Messages are contained within an Access-Request or Access- 1471 Challenge packet, they MUST be in order and they MUST be 1472 consecutive attributes in the Access-Request or Access-Challenge 1473 packet. Access-Accept and Access-Reject packets SHOULD only have 1474 ONE EAP-Message attribute in them, containing EAP-Success or EAP- 1475 Failure. 1477 It is expected that EAP will be used to implement a variety of 1478 authentication methods, including methods involving strong 1479 cryptography. In order to prevent attackers from subverting EAP by 1480 attacking RADIUS/EAP, (for example, by modifying the EAP-Success 1481 or EAP-Failure packets) it is necessary that RADIUS/EAP provide 1482 integrity protection at least as strong as those used in the EAP 1483 methods themselves. 1485 Therefore the Signature attribute MUST be used to protect all 1486 Access-Request, Access-Challenge, Access-Accept, and Access-Reject 1487 packets containing an EAP-Message attribute. 1489 Access-Request packets including an EAP-Message attribute without 1490 a Signature attribute SHOULD be silently discarded by the RADIUS 1491 server. A RADIUS Server supporting EAP-Message MUST calculate the 1492 correct value of the Signature and silently discard the packet if 1493 it does not match the value sent. A RADIUS Server not supporting 1494 EAP-Message MUST return an Access-Reject if it receives an 1495 Access-Request containing an EAP-Message attribute. A RADIUS 1496 Server receiving an EAP-Message attribute that it does not 1497 understand MUST return an Access-Reject. 1499 Access-Challenge, Access-Accept, or Access-Reject packets 1500 including an EAP-Message attribute without a Signature attribute 1501 SHOULD be silently discarded by the NAS. A NAS supporting EAP- 1502 Message MUST calculate the correct value of the Signature and 1503 silently discard the packet if it does not match the value sent. 1505 A summary of the EAP-Message attribute format is shown below. The 1506 fields are transmitted from left to right. 1508 0 1 2 1509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Type | Length | String... 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 Type 1516 79 for EAP-Message. 1518 Length 1520 >= 3 (EAP packet enclosed) 1521 = 2 (EAP-Start message) 1523 String 1525 The String field contains EAP packets, as defined in [3]. If 1526 multiple EAP-Message attributes are present in a packet their 1527 values should be concatenated; this allows EAP packets longer than 1528 253 octets to be passed by RADIUS. 1530 5.14. Signature 1532 Description 1534 This attribute MAY be used to sign Access-Requests to prevent 1535 dictionary attacks on CHAP, ARAP or EAP authentication methods. 1536 It MAY be used in any Access-Request. It MUST be used in any 1537 Access-Request, Access-Accept, Access-Reject or Access-Challenge 1538 that includes an EAP-Message attribute. 1540 A RADIUS Server receiving an Access-Request with a Signature 1541 Attribute present MUST calculate the correct value of the 1542 Signature and silently discard the packet if it does not match the 1543 value sent. 1545 A RADIUS Client receiving an Access-Accept, Access-Reject or 1546 Access-Challenge with a Signature Attribute present MUST calculate 1547 the correct value of the Signature and silently discard the packet 1548 if it does not match the value sent. 1550 A summary of the Signature attribute format is shown below. The 1551 fields are transmitted from left to right. 1553 0 1 2 1554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Type | Length | String... 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Type 1561 80 for Signature. 1563 Length 1565 18 1567 String 1569 When present in an Access-Request packet, Signature is an HMAC-MD5 1570 [7] checksum of the entire Access-Request packet, including Type, 1571 ID, Length and authenticator, using the shared secret as the key, 1572 as follows. 1574 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1575 Authenticator, Attributes) 1577 When the checksum is calculated the signature string should be 1578 considered to be sixteen octets of zero. 1580 For Access-Challenge, Access-Accept, and Access-Reject packets, 1581 the Signature is calculated as follows, using the Request- 1582 Authenticator from the Access-Request this packet is in reply to: 1584 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1585 Authenticator, Attributes) 1587 When the checksum is calculated the signature string should be 1588 considered to be sixteen octets of zero. The shared secret is 1589 used as the key for the HMAC-MD5 hash. The Signature is 1590 calculated and inserted in the packet before the Response 1591 Authenticator is calculated. 1593 This attribute is not needed if the User-Password attribute is 1594 present, but is useful for preventing dictionary attacks on other 1595 types of authentication. 1597 IP Security will eventually make this attribute unnecessary, so it 1598 should be considered an interim measure. 1600 5.15. ARAP-Challenge-Response 1602 Description 1604 This attribute is sent in an Access-Accept packet with Framed- 1605 Protocol of ARAP, and contains the response to the dial-in 1606 client's challenge. 1608 A summary of the ARAP-Challenge-Response attribute format is shown 1609 below. The fields are transmitted from left to right. 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Type | Length | Value... 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Type 1623 84 for ARAP-Challenge-Response. 1625 Length 1627 10 1629 Value 1631 The Value field contains an 8 octet response to the dial-in 1632 client's challenge. The RADIUS server calculates this value by 1633 taking the dial-in client's challenge from the high order 8 octets 1634 of the ARAP-Password attribute and performing DES encryption on 1635 this value with the authenticating user's password as the key. If 1636 the user's password is less than 8 octets in length, the password 1637 is padded at the end with NULL octets to a length of 8 before 1638 using it as a key. 1640 5.16. Acct-Interim-Interval 1642 Description 1644 This attribute indicates the number of seconds between each 1645 interim update in seconds for this specific session. This value 1646 can only appear in the Access-Accept message. 1648 A summary of the Acct-Interim-Interval attribute format is shown 1649 below. The fields are transmitted from left to right. 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Type | Length | Value 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Value (cont) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 Type 1661 85 for Acct-Interim-Interval. 1663 Length 1665 6 1667 Value 1669 The Value field contains the number of seconds between each 1670 interim update to be sent from the NAS for this session. The value 1671 MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 1672 600, and careful consideration should be given to its impact on 1673 network traffic. 1675 5.17. NAS-Port-Id 1677 Description 1679 This Attribute contains a string which identifies the port of the 1680 NAS which is authenticating the user. It is only used in Access- 1681 Request and Accounting-Request packets. Note that this is using 1682 "port" in its sense of a physical connection on the NAS, not in 1683 the sense of a TCP or UDP port number. 1685 Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- 1686 Request packet, if the NAS differentiates among its ports. NAS- 1687 Port-Id is intended for use by NASes which cannot conveniently 1688 number their ports. 1690 A summary of the NAS-Port-Id Attribute format is shown below. The 1691 fields are transmitted from left to right. 1693 0 1 2 1694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Type | Length | String... 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 Type 1701 87 for NAS-Port-Id. 1703 Length 1705 >= 3 1707 String 1709 The String field contains the name of the port in UTF-8 [6] 1710 format. 1712 5.18. Framed-Pool 1714 Description 1716 This Attribute contains the name of an assigned address pool that 1717 SHOULD be used to assign an address for the user. If a NAS does 1718 not support multiple address pools, the NAS should ignore this 1719 Attribute. Address pools are usually used for IP addresses, but 1720 can be used for other protocols if the NAS supports pools for 1721 those protocols. 1723 A summary of the Framed-Pool Attribute format is shown below. The 1724 fields are transmitted from left to right. 1726 0 1 2 1727 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Type | Length | String... 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 Type 1734 88 for Framed-Pool 1736 Length 1738 >= 3 1740 String 1742 The string field contains the name of an assigned address pool 1743 configured on the NAS. 1745 5.19. Table of Attributes 1747 The following table provides a guide to which attributes may be found 1748 in which kind of packets. Acct-Input-Gigawords, Acct-Output- 1749 Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in 1750 an Accounting-Request packet. Connect-Info may have 0+ instances in 1751 an Accounting-Request packet. The other attributes added in this 1752 document must not be present in an Accounting-Request. 1754 Request Accept Reject Challenge # Attribute 1755 0-1 0 0 0 70 ARAP-Password [Note 1] 1756 0 0-1 0 0-1 71 ARAP-Features 1757 0 0-1 0 0 72 ARAP-Zone-Access 1758 0-1 0 0 0-1 73 ARAP-Security 1759 0+ 0 0 0+ 74 ARAP-Security-Data 1760 0 0 0-1 0 75 Password-Retry 1761 0 0 0 0-1 76 Prompt 1762 0-1 0 0 0 77 Connect-Info 1763 0 0+ 0 0 78 Configuration-Token 1764 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 1765 0-1 0-1 0-1 0-1 80 Signature [Note 1] 1766 0 0-1 0 0-1 84 ARAP-Challenge-Response 1767 0 0-1 0 0 85 Acct-Interim-Interval 1768 0-1 0 0 0 87 NAS-Port-Id 1769 0 0-1 0 0 88 Framed-Pool 1770 Request Accept Reject Challenge # Attribute 1772 [Note 1] An Access-Request that contains either a User-Password or 1773 CHAP-Password or ARAP-Password or one or more EAP-Message attributes 1774 MUST NOT contain more than one type of those four attributes. If it 1775 does not contain any of those four attributes, it SHOULD contain a 1776 Signature. If any packet type contains an EAP-Message attribute it 1777 MUST also contain a Signature. 1779 The following table defines the above table entries. 1781 0 This attribute MUST NOT be present 1782 0+ Zero or more instances of this attribute MAY be present. 1783 0-1 Zero or one instance of this attribute MAY be present. 1784 1 Exactly one instance of this attribute MUST be present. 1786 6. Security Considerations 1788 The attributes other than Signature and EAP-Message in this document 1789 have no additional security considerations beyond those already 1790 identified in RFC 2138 [1]. 1792 6.1. Signature Security 1794 Access-Request packets with a User-Password establish the identity of 1795 both the user and the NAS sending the Access-Request, because of the 1796 way the shared secret between NAS and RADIUS server is used. 1797 Access-Request packets with CHAP-Password or EAP-Message do not have 1798 a User-Password attribute, so the Signature attribute should be used 1799 in access-request packets that do not have a User-Password, in order 1800 to establish the identity of the NAS sending the request. 1802 6.2. EAP Security 1804 Since the purpose of EAP is to provide enhanced security for PPP 1805 authentication, it is critical that RADIUS support for EAP be secure. 1806 In particular, the following issues must be addressed: 1807 Separation of EAP server and PPP authenticator 1808 Connection hijacking 1809 Man in the middle attacks 1810 Multiple databases 1811 Negotiation attacks 1813 6.2.1. Separation of EAP server and PPP authenticator 1815 It is possible for the EAP endpoints to mutually authenticate, 1816 negotiate a ciphersuite, and derive a session key for subsequent use 1817 in PPP encryption. 1819 This does not present an issue on the peer, since the peer and EAP 1820 client reside on the same machine; all that is required is for the 1821 EAP client module to pass the session key to the PPP encryption 1822 module. 1824 The situation is more complex when EAP is used with RADIUS, since the 1825 PPP authenticator will typically not reside on the same machine as 1826 the EAP server. For example, the EAP server may be a backend security 1827 server, or a module residing on the RADIUS server. 1829 In the case where the EAP server and PPP authenticator reside on 1830 different machines, there are several implications for security. 1831 Firstly, mutual authentication will occur between the peer and the 1832 EAP server, not between the peer and the authenticator. This means 1833 that it is not possible for the peer to validate the identity of the 1834 NAS or tunnel server that it is speaking to. 1836 As described earlier, when EAP/RADIUS is used to encapsulate EAP 1837 packets, the Signature attribute is required in EAP/RADIUS Access- 1838 Requests sent from the NAS or tunnel server to the RADIUS server. 1839 Since the Signature attribute involves a HMAC-MD5 hash, it is 1840 possible for the RADIUS server to verify the integrity of the 1841 Access-Request as well as the NAS or tunnel server's identity. 1842 Similarly, Access-Challenge packets sent from the RADIUS server to 1843 the NAS are also authenticated and integrity protected using an 1844 HMAC-MD5 hash, enabling the NAS or tunnel server to determine the 1845 integrity of the packet and verify the identity of the RADIUS server. 1846 Morever, EAP packets sent via methods that contain their own 1847 integrity protection cannot be successfully modified by a rogue NAS 1848 or tunnel server. 1850 The second issue that arises in the case of an EAP server and PPP 1851 authenticator residing on different machines is that the session key 1852 negotiated between the peer and EAP server will need to be 1853 transmitted to the authenticator. Therefore a mechanism needs to be 1854 provided to transmit the session key from the EAP server to the 1855 authenticator or tunnel server that needs to use the key. The 1856 specification of this transit mechanism is outside the scope of this 1857 document. 1859 6.2.2. Connection hijacking 1861 In this form of attack, the attacker attempts to inject packets into 1862 the conversation between the NAS and the RADIUS server, or between 1863 the RADIUS server and the backend security server. RADIUS does not 1864 support encryption, and as described in [1], only Access-Reply and 1865 Access-Challenge packets are integrity protected. Moreover, the 1866 integrity protection mechanism described in [1] is weaker than that 1867 likely to be used by some EAP methods, making it possible to subvert 1868 those methods by attacking EAP/RADIUS. 1870 In order to provide for authentication of all packets in the EAP 1871 exchange, all EAP/RADIUS packets MUST be authenticated using the 1872 Signature attribute, as described previously. 1874 6.2.3. Man in the middle attacks 1876 Since RADIUS security is based on shared secrets, end-to-end security 1877 is not provided in the case where authentication or accounting 1878 packets are forwarded along a proxy chain. As a result, attackers 1879 gaining control of a RADIUS proxy will be able to modify EAP packets 1880 in transit. 1882 6.2.4. Multiple databases 1884 In many cases a backend security server will be deployed along with a 1885 RADIUS server in order to provide EAP services. Unless the backend 1886 security server also functions as a RADIUS server, two separate user 1887 databases will exist, each containing information about the security 1888 requirements for the user. This represents a weakness, since security 1889 may be compromised by a successful attack on either of the servers, 1890 or their backend databases. With multiple user databases, adding a 1891 new user may require multiple operations, increasing the chances for 1892 error. The problems are further magnified in the case where user 1893 information is also being kept in an LDAP server. In this case, three 1894 stores of user information may exist. 1896 In order to address these threats, consolidation of databases is 1897 recommended. This can be achieved by having both the RADIUS server 1898 and backend security server store information in the same backend 1899 database; by having the backend security server provide a full RADIUS 1900 implementation; or by consolidating both the backend security server 1901 and the RADIUS server onto the same machine. 1903 6.2.5. Negotiation attacks 1905 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 1906 RADIUS server causes the authenticating peer to choose a less secure 1907 authentication method so as to make it easier to obtain the user's 1908 password. For example, a session that would normally be authenticated 1909 with EAP would instead authenticated via CHAP or PAP; alternatively, 1910 a connection that would normally be authenticated via one EAP type 1911 occurs via a less secure EAP type, such as MD5. The threat posed by 1912 rogue devices, once thought to be remote, has gained currency given 1913 compromises of telephone company switching systems, such as those 1914 described in [8]. 1916 Protection against negotiation attacks requires the elimination of 1917 downward negotiations. This can be achieved via implementation of 1918 per-connection policy on the part of the authenticating peer, and 1919 per-user policy on the part of the RADIUS server. 1921 For the authenticating peer, authentication policy should be set on a 1922 per-connection basis. Per-connection policy allows an authenticating 1923 peer to negotiate EAP when calling one service, while negotiating 1924 CHAP for another service, even if both services are accessible via 1925 the same phone number. 1927 With per-connection policy, an authenticating peer will only attempt 1928 to negotiate EAP for a session in which EAP support is expected. As a 1929 result, there is a presumption that an authenticating peer selecting 1930 EAP requires that level of security. If it cannot be provided, it is 1931 likely that there is some kind of misconfiguration, or even that the 1932 authenticating peer is contacting the wrong server. Should the NAS 1933 not be able to negotiate EAP, or should the EAP-Request sent by the 1934 NAS be of a different EAP type than what is expected, the 1935 authenticating peer MUST disconnect. An authenticating peer expecting 1936 EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. 1938 For a NAS, it may not be possible to determine whether a user is 1939 required to authenticate with EAP until the user's identity is known. 1940 For example, for shared-uses NASes it is possible for one reseller to 1941 implement EAP while another does not. In such cases, if any users of 1942 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 1943 every call. This avoids forcing an EAP-capable client to do more than 1944 one authentication, which weakens security. 1946 If CHAP is negotiated, the NAS will pass the User-Name and CHAP- 1947 Password attributes to the RADIUS Server in an Access-Request packet. 1948 If the user is not required to use EAP, then the RADIUS Server will 1949 respond with an Access-Accept or Access-Reject packet as appropriate. 1950 However, if CHAP has been negotiated but EAP is required, the RADIUS 1951 server MUST respond with an Access-Reject, rather than an Access- 1952 Challenge/EAP-Message/EAP-Request packet. The authenticating peer 1953 MUST refuse to renegotiate authentication, even if the renegotiation 1954 is from CHAP to EAP. 1956 If EAP is negotiated but is not supported by the RADIUS proxy or 1957 server, then the server or proxy MUST respond with an Access-Reject. 1958 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 1959 user. This is the correct behavior since the authenticating peer is 1960 expecting EAP to be negotiated, and that expectation cannot be 1961 fulfilled. An EAP-capable authenticating peer MUST refuse to 1962 renegotiate the authentication protocol if EAP had initially been 1963 negotiated. Note that problems with a non-EAP capable RADIUS proxy 1964 could prove difficult to diagnose, since a user dialing in from one 1965 location (with an EAP-capable proxy) might be able to successfully 1966 authenticate via EAP, while the same user dialing into another 1967 location (and encountering an EAP-incapable proxy) might be 1968 consistently disconnected. 1970 7. References 1972 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 1973 Authentication Dial In User Service (RADIUS)", RFC 2138, April 1974 1997. 1976 [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1978 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 1979 Protocol (EAP)", RFC 2284, March 1998. 1981 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1982 Levels." BCP 14, RFC 2119, Harvard University, March, 1997. 1984 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1985 1700, USC/Information Sciences Institute, October 1994. 1987 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1988 2279, January 1998. 1990 [7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1991 for Message Authentication", RFC 2104, February 1997. 1993 [8] Slatalla, M., and Quittner, J., "Masters of Deception." 1994 HarperCollins, New York, 1995. 1996 8. Acknowledgements 1998 RADIUS and RADIUS Accounting were originally developed by Livingston 1999 Enterprises (now Lucent Remote Access Business Unit) for their 2000 PortMaster series of Network Access Servers. 2002 The section on ARAP is adopted with permission from "Using RADIUS to 2003 Authenticate Apple Remote Access Connections" by Ward Willats of Cyno 2004 Technologies (ward@cyno.com). 2006 The section on Acct-Interim-Interval is adopted with permission from 2007 an earlier Internet-Draft by Pat Calhoun of Sun Microsystems, Mark 2008 Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. 2010 The section on EAP is adopted with permission from an earlier 2011 Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of 2012 Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave 2013 Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of 2014 Microsoft for useful discussions of this problem space. 2016 9. Chair's Address 2018 The RADIUS working group can be contacted via the current chair: 2020 Carl Rigney 2021 Livingston Enterprises 2022 4464 Willow Road 2023 Pleasanton, California 94588 2024 Phone: +1 925 737 2100 2025 E-Mail: cdr@livingston.com 2027 10. Author's Address 2029 Questions about this memo can also be directed to: 2031 Carl Rigney 2032 Livingston Enterprises 2033 4464 Willow Road 2034 Pleasanton, California 94588 2036 E-Mail: cdr@livingston.com 2038 Questions on ARAP and RADIUS may be directed to: 2040 Ward Willats 2041 Cyno Technologies 2042 1082 Glen Echo Ave 2043 San Jose, CA 95125 2044 Phone: +1 408 297 7766 2045 E-Mail: ward@cyno.com 2047 Questions on EAP and RADIUS may be directed to any of the following: 2049 Pat R. Calhoun 2050 Network and Security Research Center 2051 Sun Microsystems, Inc. 2052 15 Network Circle 2053 Menlo Park, CA 94025 2054 Phone: +1 650 786 7733 2055 E-Mail: pcalhoun@eng.sun.com 2057 Allan C. Rubens 2058 Merit Network, Inc. 2059 4251 Plymouth Rd. 2060 Ann Arbor, MI 48105-2785 2061 Phone: +1 313 647 0417 2062 E-Mail: acr@merit.edu 2064 Bernard Aboba 2065 Microsoft Corporation 2066 One Microsoft Way 2067 Redmond, WA 98052 2068 Phone: +1 425 936 6605 2069 E-Mail: bernarda@microsoft.com 2071 11. Full Copyright Statement 2073 Copyright (C) The Internet Society (1999). All Rights Reserved. 2075 This document and translations of it may be copied and furnished to 2076 others, and derivative works that comment on or otherwise explain it 2077 or assist in its implmentation may be prepared, copied, published and 2078 distributed, in whole or in part, without restriction of any kind, 2079 provided that the above copyright notice and this paragraph are 2080 included on all such copies and derivative works. However, this 2081 document itself may not be modified in any way, such as by removing 2082 the copyright notice or references to the Internet Society or other 2083 Internet organizations, except as needed for the purpose of 2084 developing Internet standards in which case the procedures for 2085 copyrights defined in the Internet Standards process must be 2086 followed, or as required to translate it into languages other than 2087 English. 2089 The limited permissions granted above are perpetual and will not be 2090 revoked by the Internet Society or its successors or assigns. 2092 This document and the information contained herein is provided on an 2093 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2094 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2095 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2096 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2097 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."