idnits 2.17.1 draft-ietf-radius-ext-05.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: ---------------------------------------------------------------------------- ** 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 12 instances of too long lines in the document, the longest one being 10 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 334 has weird spacing: '...y a few piece...' == Line 398 has weird spacing: '...ute and perfo...' == Line 517 has weird spacing: '... passed in an...' == Line 938 has weird spacing: '...pecific code ...' == Line 1727 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 (December 1999) is 8892 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 1874 ** 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: 11 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 May 2000 December 1999 9 RADIUS Extensions 10 draft-ietf-radius-ext-05.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 DRAFT RADIUS Extensions December 1999 45 Abstract 47 This document describes additional attributes for carrying 48 authentication, authorization and accounting information between a 49 Network Access Server (NAS) and a shared Accounting Server using the 50 Remote Authentication Dial In User Service (RADIUS) protocol 51 described in RFC 2138 and RFC 2139. 53 Table of Contents 55 1. Introduction .......................................... 4 56 1.1 Specification of Requirements ................... 4 57 1.2 Terminology ..................................... 4 59 2. Operation ............................................. 5 60 2.1 RADIUS support for Interim Accounting Updates 61 2.2 RADIUS support for Apple Remote Access Protocol 6 62 2.3 RADIUS Support for Extensible Authentication 63 Protocol (EAP) ........................... 12 64 2.3.1 Protocol Overview ............................... 12 65 2.3.2 Retransmission .................................. 14 66 2.3.3 Fragmentation ................................... 14 67 2.3.4 Examples ........................................ 15 68 2.3.5 Alternative uses ................................ 20 70 3. Packet Format ......................................... 20 72 4. Packet Types .......................................... 20 74 5. Attributes ............................................ 20 75 5.1 Acct-Input-Gigawords ............................ 22 76 5.2 Acct-Output-Gigawords ........................... 23 77 5.3 Event-Timestamp ................................. 24 78 5.4 ARAP-Password ................................... 25 79 5.5 ARAP-Features ................................... 26 80 5.6 ARAP-Zone-Access ................................ 27 81 5.7 ARAP-Security ................................... 28 82 5.8 ARAP-Security-Data .............................. 28 83 5.9 Password-Retry .................................. 29 84 5.10 Prompt .......................................... 30 85 5.11 Connect-Info .................................... 31 86 5.12 Configuration-Token ............................. 32 87 5.13 EAP-Message ..................................... 32 88 5.14 Signature ....................................... 34 89 5.15 ARAP-Challenge-Response ......................... 36 90 5.16 Acct-Interim-Interval ........................... 37 91 5.17 NAS-Port-Id ..................................... 37 92 5.18 Framed-Pool ..................................... 38 93 5.19 Table of Attributes ............................. 39 95 DRAFT RADIUS Extensions December 1999 97 6. Security Considerations ............................... 40 98 6.1 Signature Security .............................. 40 99 6.2 EAP Security .................................... 40 100 6.2.1 Separation of EAP server and PPP authenticator 101 6.2.2 Connection hijacking ............................ 42 102 6.2.3 Man in the middle attacks ....................... 42 103 6.2.4 Multiple databases .............................. 42 104 6.2.5 Negotiation attacks ............................. 43 106 7. References ............................................ 44 108 8. Acknowledgements ...................................... 45 110 9. Chair's Address ....................................... 45 112 10. Author's Address ...................................... 45 114 11. Full Copyright Statement .............................. 47 116 DRAFT RADIUS Extensions December 1999 118 1. Introduction 120 RFC 2138 [1] describes the RADIUS Protocol as it is implemented and 121 deployed today, and RFC 2139 [2] describes how Accounting can be 122 performed with RADIUS. 124 This memo suggests several additional Attributes that can be added to 125 RADIUS to perform various useful functions. These Attributes do not 126 have extensive field experience yet and should therefore be 127 considered experimental. 129 The Extensible Authentication Protocol (EAP) [3] is a PPP extension 130 that provides support for additional authentication methods within 131 PPP. This memo describes how the EAP-Message and Signature 132 attributes may be used for providing EAP support within RADIUS. 134 All attributes are comprised of variable length Type-Length-Value 3- 135 tuples. New attribute values can be added without disturbing 136 existing implementations of the protocol. 138 1.1. Specification of Requirements 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [4]. 144 An implementation is not compliant if it fails to satisfy one or more 145 of the must or must not requirements for the protocols it implements. 146 An implementation that satisfies all the must, must not, should and 147 should not requirements for its protocols is said to be 148 "unconditionally compliant"; one that satisfies all the must and must 149 not requirements but not all the should or should not requirements 150 for its protocols is said to be "conditionally compliant." 152 A NAS that does not implement a given service MUST NOT implement the 153 RADIUS attributes for that service. For example, a NAS that is 154 unable to offer ARAP service MUST NOT implement the RADIUS attributes 155 for ARAP. A NAS MUST treat a RADIUS access-request requesting an 156 unavailable service as an access-reject instead. 158 1.2. Terminology 160 This document uses the following terms: 162 service The NAS provides a service to the dial-in user, such as PPP 163 or Telnet. 165 DRAFT RADIUS Extensions December 1999 167 session Each service provided by the NAS to a dial-in user 168 constitutes a session, with the beginning of the session 169 defined as the point where service is first provided and 170 the end of the session defined as the point where service 171 is ended. A user may have multiple sessions in parallel or 172 series if the NAS supports that, with each session 173 generating a separate start and stop accounting record. 175 silently discard 176 This means the implementation discards the packet without 177 further processing. The implementation SHOULD provide the 178 capability of logging the error, including the contents of 179 the silently discarded packet, and SHOULD record the event 180 in a statistics counter. 182 2. Operation 184 Operation is identical to that defined in RFC 2138 and 2139. 186 2.1. RADIUS support for Interim Accounting Updates 188 When a user is authenticated, a RADIUS server issues an Access-Accept 189 in response to a successful Access-Request. If the server wishes to 190 receive interim accounting messages for the given user it must 191 include the Acct-Interim-Interval RADIUS attribute in the message, 192 which indicates the interval in seconds between interim messages. 194 It is also possible to statically configure an interim value on the 195 NAS itself. Note that a locally configured value on the NAS MUST 196 override the value found in an Access-Accept. 198 This scheme does not break backward interoperability since a RADIUS 199 server not supporting this extension will simply not add the new 200 Attribute. NASes not supporting this extension will ignore the 201 Attribute. 203 Note that all information in an interim message is cumulative (i.e. 204 number of packets sent is the total since the beginning of the 205 session, not since the last interim message). 207 It is envisioned that an Interim Accounting record (with Acct- 208 Status-Type = Interim-Update (3)) would contain all of the attributes 209 normally found in an Accounting Stop message with the exception of 210 the Acct-Term-Cause attribute. 212 Since all the information is cumulative, a NAS MUST ensure that only 213 a single generation of an interim Accounting message for a given 214 session is present in the retransmission queue at any given time. 216 DRAFT RADIUS Extensions December 1999 218 A NAS MAY use a fudge factor to add a random delay between Interim 219 Accounting messages for separate sessions. This will ensure that a 220 cycle where all messages are sent at once is prevented, such as might 221 otherwise occur if a primary link was recently restored and many 222 dial-up users were directed to the same NAS at once. 224 The Network and NAS CPU load of using Interim Updates should be 225 carefully considered, and appropriate values of Acct-Interim-Interval 226 chosen. 228 2.2. RADIUS support for Apple Remote Access Protocol 230 The RADIUS (Remote Authentication Dial-In User Service) protocol 231 provides a method that allows multiple dial-in Network Access Server 232 (NAS) devices to share a common authentication database. 234 The Apple Remote Access Protocol (ARAP) provides a method for sending 235 AppleTalk network traffic over point-to-point links, typically, but 236 not exclusively, asynchronous and ISDN switched-circuit connections. 237 Though Apple is moving toward ATCP on PPP for future remote access 238 services, ARAP is still a common way for the installed base of 239 Macintosh users to make remote network connections, and is likely to 240 remain so for some time. 242 ARAP is supported by several NAS vendors who also support PPP, IPX 243 and other protocols in the same NAS. ARAP connections in these 244 multi-protocol devices are often not authenticated with RADIUS, or if 245 they are, each vendor creates an individual solution to the problem. 247 This section describes the use of additional RADIUS attributes to 248 support ARAP. RADIUS client and server implementations that implement 249 this specification should be able to authenticate ARAP connections in 250 an interoperable manner. 252 This section assumes prior knowledge of RADIUS, and will go into some 253 detail on the operation of ARAP before entering a detailed discussion 254 of the proposed ARAP RADIUS attributes. 256 There are two features of ARAP this document does not address: 258 1. User initiated password changing. This is not part of RADIUS, 259 but can be implemented through a software process other than 260 RADIUS. 262 2. Out-of-Band messages. At any time, the NAS can send messages to 263 an ARA client which appear in a dialog box on the dial-in user's 264 screen. These are not part of authentication and do not belong 265 here. However, we note that a Reply-Message attribute in an 267 DRAFT RADIUS Extensions December 1999 269 Access-Accept may be sent down to the user as a sign-on message of 270 the day string using the out-of-band channel. 272 We have tried to respect the spirit of the existing RADIUS protocol 273 as much as possible, making design decisions compatible with prior 274 art. Further, we have tried to strike a balance between flooding the 275 RADIUS world with new attributes, and hiding all of ARAP operation 276 within a single multiplexed ARAP attribute string or within Extended 277 Authentication Protocol (EAP) [3] machinery. 279 However, we feel ARAP is enough of a departure from PPP to warrant a 280 small set of similarly named attributes of its own. 282 We have assumed that an ARAP-aware RADIUS server will be able to do 283 DES encryption and generate security module challenges. This is in 284 keeping with the general RADIUS goal of smart server / simple NAS. 286 ARAP authenticates a connection in two phases. The first is a "Two- 287 Way DES" random number exchange, using the user's password as a key. 288 We say "Two-Way" because the ARAP NAS challenges the dial-in client 289 to authenticate itself, and the dial-in client challenges the ARAP 290 NAS to authenticate itself. 292 Specifically, ARAP does the following: 294 1. The NAS sends two 32-bit random numbers to the dial-in client 295 in an ARAP msg_auth_challenge packet. 297 2. The dial-in client uses the user's password to DES encrypt the 298 two random numbers sent to it by the NAS. The dial-in client then 299 sends this result, the user's name and two 32-bit random numbers 300 of its own back to the NAS in an ARAP msg_auth_request packet. 302 3. The NAS verifies the encrypted random numbers sent by the 303 dial-in client are what it expected. If so, it encrypts the dial- 304 in client's challenge using the password and sends it back to the 305 dial-in client in an ARAP msg_auth_response packet. 307 Note that if the dial-in client's response was wrong, meaning the 308 user has the wrong password, the server can initiate a retry sequence 309 up to the maximum amount of retries allowed by the NAS. In this case, 310 when the dial-in client receives the ARAP msg_auth_response packet it 311 will acknowledge it with an ARAP msg_auth_again packet. 313 After this first "DES Phase" the ARAP NAS MAY initiate a secondary 314 authentication phase using what Apple calls "Add-In Security 315 Modules." Security Modules are small pieces of code which run on both 316 the client and server and are allowed to read and write arbitrary 318 DRAFT RADIUS Extensions December 1999 320 data across the communications link to perform additional 321 authentication functions. Various security token vendors use this 322 mechanism to authenticate ARA callers. 324 Although ARAP allows security modules to read and write anything they 325 like, all existing security modules use simple challenge and response 326 cycles, with perhaps some overall control information. This document 327 assumes all existing security modules can be supported with one or 328 more challenge/response cycles. 330 To complicate RADIUS and ARAP integration, ARAP sends down some 331 profile information after the DES Phase and before the Security 332 Module phase. This means that besides the responses to challenges, 333 this profile information must also be present, at somewhat unusual 334 times. Fortunately the information is only a few pieces of numeric 335 data related to passwords, which this document packs into a single 336 new attribute. 338 Presenting an Access-Request to RADIUS on behalf of an ARAP 339 connection is straightforward. The ARAP NAS generates the random 340 number challenge, and then receives the dial-in client's response, 341 the dial-in client's challenge, and the user's name. Assuming the 342 user is not a guest, the following information is forwarded in an 343 Access-Request packet: User-Name (up to 31 characters long), Framed- 344 Protocol (set to 3, ARAP), ARAP-Password, and any additional 345 attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, 346 NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 348 The Request Authenticator is a NAS-generated 16 octet random number. 349 The low-order 8 octets of this number are sent to the dial-in user as 350 the two 4 octet random numbers required in the ARAP 351 msg_auth_challenge packet. Octets 0-3 are the first random number and 352 Octets 4-7 are the second random number. [Probably needs to make 353 ordering clearer.] 355 The ARAP-Password in the Access-Request contains a 16 octet random 356 number field, and is used to carry the dial-in user's response to the 357 NAS challenge and the client's own challenge to the NAS. The high- 358 order octets contain the dial-in user's challenge to the NAS (2 32- 359 bit numbers, 8 octets) and the low-order octets contain the dial-in 360 user's response to the NAS challenge (2 32-bit numbers, 8 octets). 362 Only one of User-Password, CHAP-Password, or ARAP-Password needs to 363 be present in an Access-Request, or one or more EAP-Messages. 365 If the RADIUS server does not support ARAP it SHOULD return an 366 Access-Reject to the NAS. 368 DRAFT RADIUS Extensions December 1999 370 If the RADIUS server does support ARAP, it should verify the user's 371 response using the Challenge (from the lower order 8 octets of the 372 Request Authenticator) and the user's response (from the low order 8 373 octets of the ARAP-Password). 375 If that authentication fails, the RADIUS server should return an 376 Access-Reject packet to the NAS, with optional Password-Retry and 377 Reply-Messages attributes. The presence of Password-Retry indicates 378 the ARAP NAS MAY choose to initiate another challenge-response cycle, 379 up to a total number of times equal to the integer value of the 380 Password-Retry attribute. 382 If the user is authenticated, the RADIUS server should return an 383 Access-Accept packet (Code 2) to the NAS, with ID and Response 384 Authenticator as usual, and attributes as follows: 386 Service-Type of Framed-Protocol. 388 Framed-Protocol of ARAP (3). 390 Session-Timeout with the maximum connect time for the user in 391 seconds. If the user is to be given unlimited time, Session- 392 Timeout should not be included in the Access-Accept packet, and 393 ARAP will treat that as an unlimited timeout (-1). 395 ARAP-Challenge-Response, containing 8 octets with the response to 396 the dial-in client's challenge. The RADIUS server calculates this 397 value by taking the dial-in client's challenge from the high order 398 8 octets of the ARAP-Password attribute and performing DES 399 encryption on this value with the authenticating user's password 400 as the key. If the user's password is less than 8 octets in 401 length, the password is padded at the end with NULL octets to a 402 length of 8 before using it as a key. If the user's password is 403 greater than 8 octets in length, an Access-Reject MUST be sent 404 instead. 406 ARAP-Features, containing information that the NAS should send to 407 the user in an ARAP "feature flags" packet. 409 Octet 0: If zero, user cannot change their password. If non- 410 zero user can. (RADIUS does not handle the password changing, 411 just the attribute which indicates whether ARAP indicates they 412 can.) 414 Octet 1: Minimum acceptable password length (0-8). 416 Octet 2-5: Password creation date in Macintosh format, defined 417 as 32 bits unsigned representing seconds since Midnight GMT 419 DRAFT RADIUS Extensions December 1999 421 January 1, 1904. 423 Octet 6-9 Password Expiration Delta from create date in 424 seconds. 426 Octet 10-13: Current RADIUS time in Macintosh format 428 Optionally, a single Reply-Message with a string up to 253 429 characters long which MAY be sent down to the user to be displayed 430 in a sign-on/message of the day dialog. 432 Framed-AppleTalk-Network may be included. 434 Framed-AppleTalk-Zone, up to 32 characters in length, may be 435 included. 437 ARAP defines the notion of a list of zones for a user. Along with 438 a list of zone names, a Zone Access Flag is defined (and used by 439 the NAS) which says how to use the list of zone names. That is, 440 the dial-in user may only be allowed to see the Default Zone, or 441 only the zones in the zone list (inclusive) or any zone except 442 those in the zone list (exclusive). 444 The ARAP NAS handles this by having a named filter which contains 445 (at least) zone names. This solves the problem where a single 446 RADIUS server is managing disparate NAS clients who may not be 447 able to "see" all of the zone names in a user zone list. Zone 448 names only have meaning "at the NAS." The disadvantage of this 449 approach is that zone filters must be set up on the NAS somehow, 450 then referenced by the RADIUS Filter-Id. 452 ARAP-Zone-Access contains an integer which specifies how the "zone 453 list" for this user should be used. If this attribute is present 454 and the value is 2 or 4 then a Filter-Id must also be present to 455 name a zone list filter to apply the access flag to. 457 The inclusion of a Callback-Number or Callback-Id attribute in the 458 Access-Accept MAY cause the ARAP NAS to disconnect after sending 459 the Feature Flags to begin callback processing in an ARAP specific 460 way. 462 Other attributes may be present in the Access-Accept packet as well. 464 An ARAP NAS will need other information to finish bringing up the 465 connection to the dial in client, but this information can be 466 provided by the ARAP NAS without any help from RADIUS, either through 467 configuration by SNMP, a NAS administration program, or deduced by 468 the AppleTalk stack in the NAS. Specifically: 470 DRAFT RADIUS Extensions December 1999 472 1. AppearAsNet and AppearAsNode values, sent to the client to tell 473 it what network and node numbers it should use in its datagram 474 packets. AppearAsNet can be taken from the Framed-AppleTalk- 475 Network attribute or from the configuration or AppleTalk stack on 476 the NAS. 478 2. The "default" zone - that is the name of the AppleTalk zone in 479 which the dial-in client will appear. (Or can be specified with 480 the Framed-AppleTalk-Zone attribute.) 482 3. Other very NAS specific stuff such as the name of the NAS, and 483 smartbuffering information. (Smartbuffering is an ARAP mechanism 484 for replacing common AppleTalk datagrams with small tokens, to 485 improve slow link performance in a few common traffic situations.) 487 4. "Zone List" information for this user. The ARAP specification 488 defines a "zone count" field which is actually unused. 490 RADIUS supports ARAP Security Modules in the following manner. 492 After DES authentication has been completed, the RADIUS server may 493 instruct the ARAP NAS to run one or more security modules for the 494 dial-in user. Although the underlying protocol supports executing 495 multiple security modules in series, in practice all current 496 implementations only allow executing one. Through the use of 497 multiple Access-Challenge requests, multiple modules can be 498 supported, but this facility will probably never be used. 500 We also assume that, even though ARAP allows a free-form dialog 501 between security modules on each end of the point-to-point link, in 502 actual practice all security modules can be reduced to a simple 503 challenge/response cycle. 505 If the RADIUS server wishes to instruct the ARAP NAS to run a 506 security module, it should send an Access-Challenge packet to the NAS 507 with (optionally) the State attribute, plus the ARAP-Challenge- 508 Response, ARAP-Features, and two more attributes: 510 ARAP-Security: a four octet security module signature, containing a 511 Macintosh OSType. 513 ARAP-Security-Data, a string to carry the actual security module 514 challenge and response. 516 When the security module finishes executing, the security module 517 response is passed in an ARAP-Security-Data attribute from the NAS 518 to the RADIUS server in a second Access-Request, also including the 519 State from the Access-Challenge. The authenticator field contains no 521 DRAFT RADIUS Extensions December 1999 523 special information in this case, and this can be discerned by the 524 presence of the State attribute. 526 2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 528 The Extensible Authentication Protocol (EAP), described in [3], 529 provides a standard mechanism for support of additional 530 authentication methods within PPP. Through the use of EAP, support 531 for a number of authentication schemes may be added, including smart 532 cards, Kerberos, Public Key, One Time Passwords, and others. In 533 order to provide for support of EAP within RADIUS, two new 534 attributes, EAP-Message and Signature, are introduced in this 535 document. This section describes how these new attributes may be used 536 for providing EAP support within RADIUS. 538 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 539 encapsulated EAP Packets between the NAS and a backend security 540 server. While the conversation between the RADIUS server and the 541 backend security server will typically occur using a proprietary 542 protocol developed by the backend security server vendor, it is also 543 possible to use RADIUS-encapsulated EAP via the EAP-Message 544 attribute. This has the advantage of allowing the RADIUS server to 545 support EAP without the need for authentication-specific code, which 546 can instead reside on the backend security server. 548 2.3.1. Protocol Overview 550 The EAP conversation between the authenticating peer (dial-in user) 551 and the NAS begins with the negotiation of EAP within LCP. Once EAP 552 has been negotiated, the NAS MUST send an EAP-Request/Identity 553 message to the authenticating peer, unless identity is determined via 554 some other means such as Called-Station-Id or Calling-Station-Id. 555 The peer will then respond with an EAP-Response/Identity which the 556 the NAS will then forward to the RADIUS server in the EAP-Message 557 attribute of a RADIUS Access-Request packet. The RADIUS Server will 558 typically use the EAP-Response/Identity to determine which EAP type 559 is to be applied to the user. 561 In order to permit non-EAP aware RADIUS proxies to forward the 562 Access-Request packet, if the NAS sends the EAP-Request/Identity, the 563 NAS MUST copy the contents of the EAP-Response/Identity into the 564 User-Name attribute and MUST include the EAP-Response/Identity in the 565 User-Name attribute in every subsequent Access-Request. NAS-Port or 566 NAS-Port-Id SHOULD be included in the attributes issued by the NAS in 567 the Access-Request packet, and either NAS-Identifier or NAS-IP- 568 Address MUST be included. In order to permit forwarding of the 569 Access-Reply by EAP-unaware proxies, if a User-Name attribute was 571 DRAFT RADIUS Extensions December 1999 573 included in an Access-Request, the RADIUS Server MUST include the 574 User-Name attribute in subsequent Access-Accept packets. Without the 575 User-Name attribute, accounting and billing becomes very difficult to 576 manage. 578 If identity is determined via another means such as Called-Station-Id 579 or Calling-Station-Id, the NAS MUST include these identifying 580 attributes in every Access-Request. 582 While this approach will save a round-trip, it cannot be universally 583 employed. There are circumstances in which the user's identity may 584 not be needed (such as when authentication and accounting is handled 585 based on Called-Station-Id or Calling-Station-Id), and therefore an 586 EAP-Request/Identity packet may not necessarily be issued by the NAS 587 to the authenticating peer. In cases where an EAP-Request/Identity 588 packet will not be sent, the NAS will send to the RADIUS server a 589 RADIUS Access-Request packet containing an EAP-Message attribute 590 signifying EAP-Start. EAP-Start is indicated by sending an EAP- 591 Message attribute with a length of 2 (no data). However, it should be 592 noted that since no User-Name attribute is included in the Access- 593 Request, this approach is not compatible with RADIUS as specified in 594 [1], nor can it easily be applied in situations where proxies are 595 deployed, such as roaming or shared use networks. 597 If the RADIUS server supports EAP, it MUST respond with an Access- 598 Challenge packet containing an EAP-Message attribute. If the RADIUS 599 server does not support EAP, it MUST respond with an Access-Reject. 600 The EAP-Message attribute includes an encapsulated EAP packet which 601 is then passed on to the authenticating peer. In the case where the 602 NAS does not initially send an EAP-Request/Identity message to the 603 peer, the Access-Challenge typically will contain an EAP-Message 604 attribute encapsulating an EAP-Request/Identity message, requesting 605 the dial-in user to identify themself. The NAS will then respond with 606 a RADIUS Access-Request packet containing an EAP-Message attribute 607 encapsulating an EAP-Response. The conversation continues until 608 either a RADIUS Access-Reject or Access-Accept packet is received. 610 Reception of a RADIUS Access-Reject packet, with or without an EAP- 611 Message attribute encapsulating EAP-Failure, MUST result in the NAS 612 issuing an LCP Terminate Request to the authenticating peer. A 613 RADIUS Access-Accept packet with an EAP-Message attribute 614 encapsulating EAP-Success successfully ends the authentication phase. 615 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain 616 all of the expected attributes which are currently returned in an 617 Access-Accept packet. 619 The above scenario creates a situation in which the NAS never needs 620 to manipulate an EAP packet. An alternative may be used in 622 DRAFT RADIUS Extensions December 1999 624 situations where an EAP-Request/Identity message will always be sent 625 by the NAS to the authenticating peer. 627 For proxied RADIUS requests there are two methods of processing. If 628 the domain is determined based on the Called-Station-Id, the RADIUS 629 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 630 domain is determined based on the user's identity, the local RADIUS 631 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 632 packet. The response from the authenticating peer MUST be proxied to 633 the final authentication server. 635 For proxied RADIUS requests, the NAS may receive an Access-Reject 636 packet in response to its Access-Request/EAP-Identity packet. This 637 would occur if the message was proxied to a RADIUS Server which does 638 not support the EAP-Message extension. On receiving an Access-Reject, 639 the NAS MUST send an LCP Terminate Request to the authenticating 640 peer, and disconnect. 642 2.3.2. Retransmission 644 As noted in [3], the EAP authenticator (NAS) is responsible for 645 retransmission of packets between the authenticating peer and the 646 NAS. Thus if an EAP packet is lost in transit between the 647 authenticating peer and the NAS (or vice versa), the NAS will 648 retransmit. As in RADIUS [1], the RADIUS client is responsible for 649 retransmission of packets between the RADIUS client and the RADIUS 650 server. 652 Note that it may be necessary to adjust retransmission strategies and 653 authentication timeouts in certain cases. For example, when a token 654 card is used additional time may be required to allow the user to 655 find the card and enter the token. Since the NAS will typically not 656 have knowledge of the required parameters, these need to be provided 657 by the RADIUS server. This can be accomplished by inclusion of 658 Session-Timeout and Password-Retry attributes within the Access- 659 Challenge packet. 661 If Session-Timeout is present in an Access-Challenge packet that also 662 contains an EAP-Message, the value of the Session-Timeout provides 663 the NAS with the maximum number of seconds the NAS should wait for an 664 EAP-Response before retransmitting the EAP-Message to the dial-in 665 user. 667 2.3.3. Fragmentation 669 Using the EAP-Message attribute, it is possible for the RADIUS server 671 DRAFT RADIUS Extensions December 1999 673 to encapsulate an EAP packet that is larger than the MTU on the link 674 between the NAS and the peer. Since it is not possible for the RADIUS 675 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 676 attribute may be included in an Access-Request packet containing an 677 EAP-Message attribute so as to provide the RADIUS server with this 678 information. 680 2.3.4. Examples 682 The example below shows the conversation between the authenticating 683 peer, NAS, and RADIUS server, for the case of a One Time Password 684 (OTP) authentication. OTP is used only for illustrative purposes; 685 other authentication protocols could also have been used, although 686 they might show somewhat different behavior. 688 Authenticating Peer NAS RADIUS Server 689 ------------------- --- ------------- 691 <- PPP LCP Request-EAP 692 auth 693 PPP LCP ACK-EAP 694 auth -> 695 <- PPP EAP-Request/ 696 Identity 697 PPP EAP-Response/ 698 Identity (MyID) -> 699 RADIUS 700 Access-Request/ 701 EAP-Message/ 702 EAP-Response/ 703 (MyID) -> 704 <- RADIUS 705 Access-Challenge/ 706 EAP-Message/EAP-Request 707 OTP/OTP Challenge 708 <- PPP EAP-Request/ 709 OTP/OTP Challenge 710 PPP EAP-Response/ 711 OTP, OTPpw -> 712 RADIUS 713 Access-Request/ 714 EAP-Message/ 715 EAP-Response/ 716 OTP, OTPpw -> 717 <- RADIUS 718 Access-Accept/ 719 EAP-Message/EAP-Success 721 DRAFT RADIUS Extensions December 1999 723 (other attributes) 724 <- PPP EAP-Success 725 PPP Authentication 726 Phase complete, 727 NCP Phase starts 729 In the case where the NAS first sends an EAP-Start packet to the 730 RADIUS server, the conversation would appear as follows: 732 Authenticating Peer NAS RADIUS Server 733 ------------------- --- ------------- 735 <- PPP LCP Request-EAP 736 auth 737 PPP LCP ACK-EAP 738 auth -> 739 RADIUS 740 Access-Request/ 741 EAP-Message/Start -> 742 <- RADIUS 743 Access-Challenge/ 744 EAP-Message/Identity 745 <- PPP EA-Request/ 746 Identity 747 PPP EAP-Response/ 748 Identity (MyID) -> 749 RADIUS 750 Access-Request/ 751 EAP-Message/ 752 EAP-Response/ 753 (MyID) -> 754 <- RADIUS 755 Access-Challenge/ 756 EAP-Message/EAP-Request 757 OTP/OTP Challenge 758 <- PPP EAP-Request/ 759 OTP/OTP Challenge 760 PPP EAP-Response/ 761 OTP, OTPpw -> 762 RADIUS 763 Access-Request/ 764 EAP-Message/ 765 EAP-Response/ 766 OTP, OTPpw -> 767 <- RADIUS 768 Access-Accept/ 769 EAP-Message/EAP-Success 770 (other attributes) 772 DRAFT RADIUS Extensions December 1999 774 <- PPP EAP-Success 775 PPP Authentication 776 Phase complete, 777 NCP Phase starts 779 In the case where the client fails EAP authentication, the 780 conversation would appear as follows: 782 Autheticating Peer NAS RADIUS Server 783 ------------------- --- ------------- 785 <- PPP LCP Request-EAP 786 auth 787 PPP LCP ACK-EAP 788 auth -> 789 Access-Request/ 790 EAP-Message/Start -> 791 <- RADIUS 792 Access-Challenge/ 793 EAP-Message/Identity 794 <- PPP EAP-Request/ 795 Identity 796 PPP EAP-Response/ 797 Identity (MyID) -> 798 RADIUS 799 Access-Request/ 800 EAP-Message/ 801 EAP-Response/ 802 (MyID) -> 803 <- RADIUS 804 Access-Challenge/ 805 EAP-Message/EAP-Request 806 OTP/OTP Challenge 807 <- PPP EAP-Request/ 808 OTP/OTP Challenge 809 PPP EAP-Response/ 810 OTP, OTPpw -> 811 RADIUS 812 Access-Request/ 813 EAP-Message/ 814 EAP-Response/ 815 OTP, OTPpw -> 816 <- RADIUS 817 Access-Reject/ 818 EAP-Message/EAP-Failure 819 <- PPP EAP-Failure 820 (client disconnected) 822 DRAFT RADIUS Extensions December 1999 824 In the case that the RADIUS server or proxy does not support EAP- 825 Message, the conversation would appear as follows: 827 Authenticating Peer NAS RADIUS Server 828 ------------------- --- ------------- 830 <- PPP LCP Request-EAP 831 auth 832 PPP LCP ACK-EAP 833 auth -> 834 RADIUS 835 Access-Request/ 836 EAP-Message/Start -> 837 <- RADIUS 838 Access-Reject 839 <- PPP LCP Terminate 840 (User Disconnected) 842 In the case where the local RADIUS Server does support EAP-Message, 843 but the remote RADIUS Server does not, the conversation would appear 844 as follows: 846 Authenticating Peer NAS RADIUS Server 847 ------------------- --- ------------- 849 <- PPP LCP Request-EAP 850 auth 851 PPP LCP ACK-EAP 852 auth -> 853 RADIUS 854 Access-Request/ 855 EAP-Message/Start -> 856 <- RADIUS 857 Access-Challenge/ 858 EAP-Message/Identity 859 <- PPP EAP-Request/ 860 Identity 861 PPP EAP-Response/ 862 Identity 863 (MyID) -> 864 RADIUS 865 Access-Request/ 866 EAP-Message/EAP-Response/ 867 (MyID) -> 868 <- RADIUS 869 Access-Reject 870 (proxied from remote 871 RADIUS Server) 873 DRAFT RADIUS Extensions December 1999 875 <- PPP LCP Terminate 876 (User Disconnected) 878 In the case where the authenticating peer does not support EAP, but 879 where EAP is required for that user, the conversation would appear as 880 follows: 882 Authenticating Peer NAS RADIUS Server 883 ------------------- --- ------------- 885 <- PPP LCP Request-EAP 886 auth 887 PPP LCP NAK-EAP 888 auth -> 889 <- PPP LCP Request-CHAP 890 auth 891 PPP LCP ACK-CHAP 892 auth -> 893 <- PPP CHAP Challenge 894 PPP CHAP Response -> 895 RADIUS 896 Access-Request/ 897 User-Name, 898 CHAP-Password -> 899 <- RADIUS 900 Access-Reject 901 <- PPP LCP Terminate 902 (User Disconnected) 904 In the case where the NAS does not support EAP, but where EAP is 905 required for that user, the conversation would appear as follows: 907 Authenticating Peer NAS RADIUS Server 908 ---------------- --- ------------- 910 <- PPP LCP Request-CHAP 911 auth 912 PP LCP ACK-CHAP 913 auth -> 914 <- PPP CHAP Challenge 915 PPP CHAP Response -> 916 RADIUS 917 Access-Request/ 918 User-Name, 919 CHAP-Password -> 920 <- RADIUS 921 Access-Reject 922 <- PPP LCP Terminate 924 DRAFT RADIUS Extensions December 1999 926 (User Disconnected) 928 2.3.5. Alternative uses 930 Currently the conversation between the backend security server and 931 the RADIUS server is proprietary because of lack of standardization. 932 In order to increase standardization and provide interoperability 933 between Radius vendors and backend security vendors, it is 934 recommended that RADIUS-encapsulated EAP be used for this 935 conversation. 937 This has the advantage of allowing the RADIUS server to support EAP 938 without the need for authentication-specific code within the RADIUS 939 server. Authentication-specific code can then reside on a backend 940 security server instead. 942 In the case where RADIUS-encapsulated EAP is used in a conversation 943 between a RADIUS server and a backend security server, the security 944 server will typically return an Access-Accept/EAP-Success message 945 without inclusion of the expected attributes currently returned in an 946 Access-Accept. This means that the RADIUS server MUST add these 947 attributes prior to sending an Access-Accept/EAP-Success message to 948 the NAS. 950 3. Packet Format 952 Packet Format is identical to that defined in RFC 2138 and 2139. 954 4. Packet Types 956 Packet types are identical to those defined in RFC 2138 and 2139. 958 See "Table of Attributes" below to determine which types of packets 959 can contain which attributes defined here. 961 5. Attributes 963 RADIUS Attributes carry the specific authentication, authorization 964 and accounting details for the request and response. 966 Some attributes MAY be included more than once. The effect of this 967 is attribute specific, and is specified in each attribute 968 description. The order of attributes of the same type SHOULD be 969 preserved. The order of attributes of different types is not 970 required to be preserved. 972 DRAFT RADIUS Extensions December 1999 974 The end of the list of attributes is indicated by the Length of the 975 RADIUS packet. 977 A summary of the attribute format is the same as in RFC 2138 but is 978 included here for ease of reference. The fields are transmitted from 979 left to right. 981 0 1 2 982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Type | Length | Value ... 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Type 989 The Type field is one octet. Up-to-date values of the RADIUS Type 990 field are specified in the most recent "Assigned Numbers" RFC [5]. 991 Values 192-223 are reserved for experimental use, values 224-240 992 are reserved for implementation-specific use, and values 241-255 993 are reserved and should not be used. This specification concerns 994 the following values: 996 1-39 (refer to RFC 2138, "RADIUS") 997 40-51 (refer to RFC 2139, "RADIUS Accounting") 998 52 Acct-Input-Gigawords 999 53 Acct-Output-Gigawords 1000 54 Unused 1001 55 Event-Timestamp 1002 56-59 Unused 1003 60-63 (refer to RFC 2138, "RADIUS") 1004 64-67 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 1005 68 (refer to "RADIUS Tunnel Accounting Support" draft) 1006 69 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 1007 70 ARAP-Password 1008 71 ARAP-Features 1009 72 ARAP-Zone-Access 1010 73 ARAP-Security 1011 74 ARAP-Security-Data 1012 75 Password-Retry 1013 76 Prompt 1014 77 Connect-Info 1015 78 Configuration-Token 1016 79 EAP-Message 1017 80 Signature 1018 81-83 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 1019 84 ARAP-Challenge-Response 1020 85 Acct-Interim-Interval 1022 DRAFT RADIUS Extensions December 1999 1024 86 (refer to "RADIUS Tunneling Accounting Support" draft) 1025 87 NAS-Port-Id 1026 88 Framed-Pool 1027 89 Unused 1028 90-91 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 1029 92-191 Unused 1031 Length 1033 The Length field is one octet, and indicates the length of this 1034 attribute including the Type, Length and Value fields. If an 1035 attribute is received in a packet with an invalid Length, the 1036 entire request should be silently discarded. 1038 Value 1040 The Value field is zero or more octets and contains information 1041 specific to the attribute. The format and length of the Value 1042 field is determined by the Type and Length fields. 1044 Note that a "string" in RADIUS does not terminate with a NUL (hex 1045 00). The Attribute has a length field and does not use a 1046 terminator. Strings may contain UTF-8 characters or 8-bit binary 1047 data and servers and clients should be able to deal with embedded 1048 nulls. RADIUS implementers using C are cautioned not to use 1049 strcpy() when handling strings. 1051 The format of the value field is one of four data types. 1053 string 1-253 octets. Strings of length zero (0) MUST NOT be 1054 sent; omit the entire attribute instead. 1056 address 32 bit unsigned value, most significant octet first. 1058 integer 32 bit unsigned value, most significant octet first. 1060 time 32 bit unsigned value, most significant octet first -- 1061 seconds since 00:00:00 UTC, January 1, 1970. 1063 5.1. Acct-Input-Gigawords 1065 Description 1067 This attribute indicates how many times the Acct-Input-Octets 1068 counter has wrapped around 2^32 over the course of this service 1069 being provided, and can only be present in Accounting-Request 1071 DRAFT RADIUS Extensions December 1999 1073 records where the Acct-Status-Type is set to Stop or Interim- 1074 Update. 1076 A summary of the Acct-Input-Gigawords attribute format is shown 1077 below. The fields are transmitted from left to right. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type | Length | Value 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Value (cont) | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Type 1089 52 for Acct-Input-Gigawords. 1091 Length 1093 6 1095 Value 1097 The Value field is four octets. 1099 5.2. Acct-Output-Gigawords 1101 Description 1103 This attribute indicates how many times the Acct-Output-Octets 1104 counter has wrapped around 2^32 in the course of delivering this 1105 service, and can only be present in Accounting-Request records 1106 where the Acct-Status-Type is set to Stop or Interim-Update. 1108 A summary of the Acct-Output-Gigawords attribute format is shown 1109 below. The fields are transmitted from left to right. 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Type | Length | Value 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Value (cont) | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 DRAFT RADIUS Extensions December 1999 1121 Type 1123 53 for Acct-Output-Gigawords. 1125 Length 1127 6 1129 Value 1131 The Value field is four octets. 1133 5.3. Event-Timestamp 1135 Description 1137 This attribute is included in an Accounting-Request packet to 1138 record the time that this event occured on the NAS, in seconds 1139 since January 1, 1970 00:00 UTC. 1141 A summary of the Event-Timestamp attribute format is shown below. 1142 The fields are transmitted from left to right. 1144 0 1 2 3 1145 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 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Type | Length | Value 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Value (cont) | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 Type 1154 55 for Event-Timestamp 1156 Length 1158 6 1160 Value 1162 The Value field is four octets encoding an unsigned integer with 1163 the number of seconds since January 1, 1970 00:00 UTC. 1165 DRAFT RADIUS Extensions December 1999 1167 5.4. ARAP-Password 1169 Description 1171 This attribute is only present in an Access-Request packet 1172 containing a Framed-Protocol of ARAP. 1174 Only one of User-Password, CHAP-Password, or ARAP-Password needs 1175 to be present in an Access-Request, or one or more EAP-Messages. 1177 A summary of the ARAP-Password attribute format is shown below. The 1178 fields are transmitted from left to right. 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Type | Length | Value1 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Value2 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Value3 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Value4 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Type 1196 70 for ARAP-Password. 1198 Length 1200 18 1202 Value 1204 This attribute contains a 16 octet string, used to carry the 1205 dial-in user's response to the NAS challenge and the client's own 1206 challenge to the NAS. The high-order octets (Value1 and Value2) 1207 contain the dial-in user's challenge to the NAS (2 32-bit numbers, 1208 8 octets) and the low-order octets (Value3 and Value4) contain the 1209 dial-in user's response to the NAS challenge (2 32-bit numbers, 8 1210 octets). 1212 DRAFT RADIUS Extensions December 1999 1214 5.5. ARAP-Features 1216 Description 1218 This attribute is sent in an Access-Accept packet with Framed- 1219 Protocol of ARAP, and includes password information that the NAS 1220 should sent to the user in an ARAP "feature flags" packet. 1222 A summary of the ARAP-Features attribute format is shown below. The 1223 fields are transmitted from left to right. 1225 0 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Type | Length | Value1 | Value2 | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Value3 | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Value4 | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Value5 | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 Type 1239 71 for ARAP-Features. 1241 Length 1243 16 1245 Value 1247 The Value field is a compound string containing information the 1248 NAS should send to the user in the ARAP "feature flags" packet. 1250 Value1: If zero, user cannot change their password. If non-zero 1251 user can. (RADIUS does not handle the password changing, just 1252 the attribute which indicates whether ARAP indicates they can.) 1254 Value2: Minimum acceptable password length, from 0 to 8. 1256 Value3: Password creation date in Macintosh format, defined as 1257 32 unsigned bits representing seconds since Midnight GMT 1258 January 1, 1904. 1260 Value4: Password Expiration Delta from create date in seconds. 1262 DRAFT RADIUS Extensions December 1999 1264 Value5: Current RADIUS time in Macintosh format. 1266 5.6. ARAP-Zone-Access 1268 Description 1270 This attribute is included in an Access-Accept packet with 1271 Framed-Protocol of ARAP to indicate how the ARAP zone list for the 1272 user should be used. 1274 A summary of the ARAP-Zone-Access attribute format is shown below. 1275 The fields are transmitted from left to right. 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Type | Length | Value 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Value (cont) | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Type 1287 72 for ARAP-Zone-Access. 1289 Length 1291 6 1293 Value 1295 The Value field is four octets encoding an integer with one of the 1296 following values: 1298 1 Only allow access to default zone 1299 2 Use zone filter inclusively 1300 4 Use zone filter exclusively 1302 The value 3 is skipped, not because these are bit flags, but 1303 because 3 in some ARAP implementations means "all zones" which is 1304 the same as not specifying a list at all under RADIUS. 1306 If this attribute is present and the value is 2 or 4 then a 1307 Filter-Id must also be present to name a zone list filter to apply 1309 DRAFT RADIUS Extensions December 1999 1311 the access flag to. 1313 5.7. ARAP-Security 1315 Description 1317 This attribute identifies the ARAP Security Module to be used in 1318 an Access-Challenge packet. 1320 A summary of the ARAP-Security attribute format is shown below. The 1321 fields are transmitted from left to right. 1323 0 1 2 3 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Type | Length | Value 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 Value (cont) | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Type 1333 73 for ARAP-Security. 1335 Length 1337 6 1339 Value 1341 The Value field is four octets, containing an integer specifying 1342 the security module signature, which is a Macintosh OSType. 1343 (Macintosh OSTypes are 4 ascii characters cast as a 32-bit 1344 integer) 1346 5.8. ARAP-Security-Data 1348 Description 1350 This attribute contains the actual security module challenge or 1351 response, and can be found in Access-Challenge and Access-Request 1352 packets. 1354 DRAFT RADIUS Extensions December 1999 1356 A summary of the ARAP-Security-Data attribute format is shown below. 1357 The fields are transmitted from left to right. 1359 0 1 2 1360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Type | Length | String... 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Type 1367 74 for ARAP-Security-Data. 1369 Length 1371 >=3 1373 String 1375 The String field contains the security module challenge or 1376 response associated with the ARAP Security Module specified in 1377 ARAP-Security. 1379 5.9. Password-Retry 1381 Description 1383 This attribute MAY be included in an Access-Reject to indicate how 1384 many authentication attempts a user may be allowed to attempt 1385 before being disconnected. 1387 It is primarily intended for use with ARAP authentication. 1389 A summary of the Password-Retry attribute format is shown below. The 1390 fields are transmitted from left to right. 1392 0 1 2 3 1393 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 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Type | Length | Value 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Value (cont) | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 DRAFT RADIUS Extensions December 1999 1402 Type 1404 75 for Password-Retry. 1406 Length 1408 6 1410 Value 1412 The Value field is four octets, containing an integer specifying 1413 the number of password retry attempts to permit the user. 1415 5.10. Prompt 1417 Description 1419 This attribute is used only in Access-Challenge packets, and 1420 indicates to the NAS whether it should echo the user's response as 1421 it is entered, or not echo it. 1423 A summary of the Prompt attribute format is shown below. The fields 1424 are transmitted from left to right. 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Type | Length | Value 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 Value (cont) | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Type 1436 76 for Prompt. 1438 Length 1440 6 1442 Value 1444 The Value field is four octets. 1446 DRAFT RADIUS Extensions December 1999 1448 0 No Echo 1449 1 Echo 1451 5.11. Connect-Info 1453 Description 1455 This attribute is sent from the NAS to indicate the nature of the 1456 user's connection. 1458 The NAS MAY send this attribute in an Access-Request or 1459 Accounting-Request to indicate the nature of the user's 1460 connection. 1462 A summary of the Connect-Info attribute format is shown below. The 1463 fields are transmitted from left to right. 1465 0 1 2 1466 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Type | Length | String... 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Type 1473 77 for Connect-Info. 1475 Length 1477 >= 3 1479 String 1481 The String field is encoded as UTF-8 [6] characters. The 1482 connection speed SHOULD be included at the beginning of the first 1483 Connect-Info attribute in the packet. If the transmit and receive 1484 connection speeds differ, they may both be included in the first 1485 attribute with the transmit speed first (the speed the NAS modem 1486 transmits at), a slash (/), the receive speed, then optionally 1487 other information. 1489 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1491 DRAFT RADIUS Extensions December 1999 1493 More than one Connect-Info attribute may be present in an 1494 Accounting-Request packet to accommodate expected efforts by ITU 1495 to have modems report more connection information in a standard 1496 format that might exceed 252 octets. 1498 5.12. Configuration-Token 1500 Description 1502 This attribute is for use in large distributed authentication 1503 networks based on proxy. It is sent from a RADIUS Proxy Server to 1504 a RADIUS Proxy Client in an Access-Accept to indicate a type of 1505 user profile to be used. It should not be sent to a NAS. 1507 A summary of the Configuration-Token attribute format is shown below. 1508 The fields are transmitted from left to right. 1510 0 1 2 1511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Type | Length | String ... 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 Type 1518 78 for Configuration-Token. 1520 Length 1522 >= 3 1524 String 1526 The String field is one or more octets. The actual format of the 1527 information is site or application specific, and a robust 1528 implementation SHOULD support the field as undistinguished octets. 1530 The codification of the range of allowed usage of this field is 1531 outside the scope of this specification. 1533 5.13. EAP-Message 1535 Description 1537 DRAFT RADIUS Extensions December 1999 1539 This attribute encapsulates Extended Access Protocol [3] packets 1540 so as to allow the NAS to authenticate dial-in users via EAP 1541 without having to understand the EAP protocol. 1543 The NAS places any EAP messages received from the user into one or 1544 more EAP attributes and forwards them to the RADIUS Server as part 1545 of the Access-Request, which can return EAP messages in Access- 1546 Challenge, Access-Accept and Access-Reject packets. 1548 A RADIUS Server receiving EAP messages that it does not understand 1549 SHOULD return an Access-Reject. 1551 The NAS places EAP messages received from the authenticating peer 1552 into one or more EAP-Message attributes and forwards them to the 1553 RADIUS Server within an Access-Request message. If multiple EAP- 1554 Messages are contained within an Access-Request or Access- 1555 Challenge packet, they MUST be in order and they MUST be 1556 consecutive attributes in the Access-Request or Access-Challenge 1557 packet. Access-Accept and Access-Reject packets SHOULD only have 1558 ONE EAP-Message attribute in them, containing EAP-Success or EAP- 1559 Failure. 1561 It is expected that EAP will be used to implement a variety of 1562 authentication methods, including methods involving strong 1563 cryptography. In order to prevent attackers from subverting EAP by 1564 attacking RADIUS/EAP, (for example, by modifying the EAP-Success 1565 or EAP-Failure packets) it is necessary that RADIUS/EAP provide 1566 integrity protection at least as strong as those used in the EAP 1567 methods themselves. 1569 Therefore the Signature attribute MUST be used to protect all 1570 Access-Request, Access-Challenge, Access-Accept, and Access-Reject 1571 packets containing an EAP-Message attribute. 1573 Access-Request packets including an EAP-Message attribute without 1574 a Signature attribute SHOULD be silently discarded by the RADIUS 1575 server. A RADIUS Server supporting EAP-Message MUST calculate the 1576 correct value of the Signature and silently discard the packet if 1577 it does not match the value sent. A RADIUS Server not supporting 1578 EAP-Message MUST return an Access-Reject if it receives an 1579 Access-Request containing an EAP-Message attribute. A RADIUS 1580 Server receiving an EAP-Message attribute that it does not 1581 understand MUST return an Access-Reject. 1583 Access-Challenge, Access-Accept, or Access-Reject packets 1584 including an EAP-Message attribute without a Signature attribute 1585 SHOULD be silently discarded by the NAS. A NAS supporting EAP- 1586 Message MUST calculate the correct value of the Signature and 1588 DRAFT RADIUS Extensions December 1999 1590 silently discard the packet if it does not match the value sent. 1592 A summary of the EAP-Message attribute format is shown below. The 1593 fields are transmitted from left to right. 1595 0 1 2 1596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Type | Length | String... 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 Type 1603 79 for EAP-Message. 1605 Length 1607 >= 3 (EAP packet enclosed) 1608 = 2 (EAP-Start message) 1610 String 1612 The String field contains EAP packets, as defined in [3]. If 1613 multiple EAP-Message attributes are present in a packet their 1614 values should be concatenated; this allows EAP packets longer than 1615 253 octets to be passed by RADIUS. 1617 5.14. Signature 1619 Description 1621 This attribute MAY be used to sign Access-Requests to prevent 1622 dictionary attacks on CHAP, ARAP or EAP authentication methods. 1623 It MAY be used in any Access-Request. It MUST be used in any 1624 Access-Request, Access-Accept, Access-Reject or Access-Challenge 1625 that includes an EAP-Message attribute. 1627 A RADIUS Server receiving an Access-Request with a Signature 1628 Attribute present MUST calculate the correct value of the 1629 Signature and silently discard the packet if it does not match the 1630 value sent. 1632 A RADIUS Client receiving an Access-Accept, Access-Reject or 1633 Access-Challenge with a Signature Attribute present MUST calculate 1634 the correct value of the Signature and silently discard the packet 1636 DRAFT RADIUS Extensions December 1999 1638 if it does not match the value sent. 1640 A summary of the Signature attribute format is shown below. The 1641 fields are transmitted from left to right. 1643 0 1 2 1644 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Type | Length | String... 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 Type 1651 80 for Signature. 1653 Length 1655 18 1657 String 1659 When present in an Access-Request packet, Signature is an HMAC-MD5 1660 [7] checksum of the entire Access-Request packet, including Type, 1661 ID, Length and authenticator, using the shared secret as the key, 1662 as follows. 1664 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1665 Authenticator, Attributes) 1667 When the checksum is calculated the signature string should be 1668 considered to be sixteen octets of zero. 1670 For Access-Challenge, Access-Accept, and Access-Reject packets, 1671 the Signature is calculated as follows, using the Request- 1672 Authenticator from the Access-Request this packet is in reply to: 1674 Signature = HMAC-MD5 (Type, Identifier, Length, Request 1675 Authenticator, Attributes) 1677 When the checksum is calculated the signature string should be 1678 considered to be sixteen octets of zero. The shared secret is 1679 used as the key for the HMAC-MD5 hash. The Signature is 1680 calculated and inserted in the packet before the Response 1681 Authenticator is calculated. 1683 This attribute is not needed if the User-Password attribute is 1684 present, but is useful for preventing dictionary attacks on other 1686 DRAFT RADIUS Extensions December 1999 1688 types of authentication. 1690 IP Security will eventually make this attribute unnecessary, so it 1691 should be considered an interim measure. 1693 5.15. ARAP-Challenge-Response 1695 Description 1697 This attribute is sent in an Access-Accept packet with Framed- 1698 Protocol of ARAP, and contains the response to the dial-in 1699 client's challenge. 1701 A summary of the ARAP-Challenge-Response attribute format is shown 1702 below. The fields are transmitted from left to right. 1704 0 1 2 3 1705 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 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Type | Length | Value... 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 Type 1716 84 for ARAP-Challenge-Response. 1718 Length 1720 10 1722 Value 1724 The Value field contains an 8 octet response to the dial-in 1725 client's challenge. The RADIUS server calculates this value by 1726 taking the dial-in client's challenge from the high order 8 octets 1727 of the ARAP-Password attribute and performing DES encryption on 1728 this value with the authenticating user's password as the key. If 1729 the user's password is less than 8 octets in length, the password 1730 is padded at the end with NULL octets to a length of 8 before 1731 using it as a key. 1733 DRAFT RADIUS Extensions December 1999 1735 5.16. Acct-Interim-Interval 1737 Description 1739 This attribute indicates the number of seconds between each 1740 interim update in seconds for this specific session. This value 1741 can only appear in the Access-Accept message. 1743 A summary of the Acct-Interim-Interval attribute format is shown 1744 below. The fields are transmitted from left to right. 1746 0 1 2 3 1747 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 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Type | Length | Value 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Value (cont) | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 Type 1756 85 for Acct-Interim-Interval. 1758 Length 1760 6 1762 Value 1764 The Value field contains the number of seconds between each 1765 interim update to be sent from the NAS for this session. The value 1766 MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 1767 600, and careful consideration should be given to its impact on 1768 network traffic. 1770 5.17. NAS-Port-Id 1772 Description 1774 This Attribute contains a string which identifies the port of the 1775 NAS which is authenticating the user. It is only used in Access- 1776 Request and Accounting-Request packets. Note that this is using 1777 "port" in its sense of a physical connection on the NAS, not in 1778 the sense of a TCP or UDP port number. 1780 DRAFT RADIUS Extensions December 1999 1782 Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- 1783 Request packet, if the NAS differentiates among its ports. NAS- 1784 Port-Id is intended for use by NASes which cannot conveniently 1785 number their ports. 1787 A summary of the NAS-Port-Id Attribute format is shown below. The 1788 fields are transmitted from left to right. 1790 0 1 2 1791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Type | Length | String... 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 Type 1798 87 for NAS-Port-Id. 1800 Length 1802 >= 3 1804 String 1806 The String field contains the name of the port in UTF-8 [6] 1807 format. 1809 5.18. Framed-Pool 1811 Description 1813 This Attribute contains the name of an assigned address pool that 1814 SHOULD be used to assign an address for the user. If a NAS does 1815 not support multiple address pools, the NAS should ignore this 1816 Attribute. Address pools are usually used for IP addresses, but 1817 can be used for other protocols if the NAS supports pools for 1818 those protocols. 1820 A summary of the Framed-Pool Attribute format is shown below. The 1821 fields are transmitted from left to right. 1823 DRAFT RADIUS Extensions December 1999 1825 0 1 2 1826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Type | Length | String... 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 Type 1833 88 for Framed-Pool 1835 Length 1837 >= 3 1839 String 1841 The string field contains the name of an assigned address pool 1842 configured on the NAS. 1844 5.19. Table of Attributes 1846 The following table provides a guide to which attributes may be found 1847 in which kind of packets. Acct-Input-Gigawords, Acct-Output- 1848 Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in 1849 an Accounting-Request packet. Connect-Info may have 0+ instances in 1850 an Accounting-Request packet. The other attributes added in this 1851 document must not be present in an Accounting-Request. 1853 Request Accept Reject Challenge # Attribute 1854 0-1 0 0 0 70 ARAP-Password [Note 1] 1855 0 0-1 0 0-1 71 ARAP-Features 1856 0 0-1 0 0 72 ARAP-Zone-Access 1857 0-1 0 0 0-1 73 ARAP-Security 1858 0+ 0 0 0+ 74 ARAP-Security-Data 1859 0 0 0-1 0 75 Password-Retry 1860 0 0 0 0-1 76 Prompt 1861 0-1 0 0 0 77 Connect-Info 1862 0 0+ 0 0 78 Configuration-Token 1863 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 1864 0-1 0-1 0-1 0-1 80 Signature [Note 1] 1865 0 0-1 0 0-1 84 ARAP-Challenge-Response 1866 0 0-1 0 0 85 Acct-Interim-Interval 1868 DRAFT RADIUS Extensions December 1999 1870 0-1 0 0 0 87 NAS-Port-Id 1871 0 0-1 0 0 88 Framed-Pool 1872 Request Accept Reject Challenge # Attribute 1874 [Note 1] An Access-Request that contains either a User-Password or 1875 CHAP-Password or ARAP-Password or one or more EAP-Message attributes 1876 MUST NOT contain more than one type of those four attributes. If it 1877 does not contain any of those four attributes, it SHOULD contain a 1878 Signature. If any packet type contains an EAP-Message attribute it 1879 MUST also contain a Signature. 1881 The following table defines the above table entries. 1883 0 This attribute MUST NOT be present 1884 0+ Zero or more instances of this attribute MAY be present. 1885 0-1 Zero or one instance of this attribute MAY be present. 1886 1 Exactly one instance of this attribute MUST be present. 1888 6. Security Considerations 1890 The attributes other than Signature and EAP-Message in this document 1891 have no additional security considerations beyond those already 1892 identified in RFC 2138 [1]. 1894 6.1. Signature Security 1896 Access-Request packets with a User-Password establish the identity of 1897 both the user and the NAS sending the Access-Request, because of the 1898 way the shared secret between NAS and RADIUS server is used. 1899 Access-Request packets with CHAP-Password or EAP-Message do not have 1900 a User-Password attribute, so the Signature attribute should be used 1901 in access-request packets that do not have a User-Password, in order 1902 to establish the identity of the NAS sending the request. 1904 6.2. EAP Security 1906 Since the purpose of EAP is to provide enhanced security for PPP 1907 authentication, it is critical that RADIUS support for EAP be secure. 1908 In particular, the following issues must be addressed: 1909 Separation of EAP server and PPP authenticator 1910 Connection hijacking 1911 Man in the middle attacks 1912 Multiple databases 1913 Negotiation attacks 1915 DRAFT RADIUS Extensions December 1999 1917 6.2.1. Separation of EAP server and PPP authenticator 1919 It is possible for the EAP endpoints to mutually authenticate, 1920 negotiate a ciphersuite, and derive a session key for subsequent use 1921 in PPP encryption. 1923 This does not present an issue on the peer, since the peer and EAP 1924 client reside on the same machine; all that is required is for the 1925 EAP client module to pass the session key to the PPP encryption 1926 module. 1928 The situation is more complex when EAP is used with RADIUS, since the 1929 PPP authenticator will typically not reside on the same machine as 1930 the EAP server. For example, the EAP server may be a backend security 1931 server, or a module residing on the RADIUS server. 1933 In the case where the EAP server and PPP authenticator reside on 1934 different machines, there are several implications for security. 1935 Firstly, mutual authentication will occur between the peer and the 1936 EAP server, not between the peer and the authenticator. This means 1937 that it is not possible for the peer to validate the identity of the 1938 NAS or tunnel server that it is speaking to. 1940 As described earlier, when EAP/RADIUS is used to encapsulate EAP 1941 packets, the Signature attribute is required in EAP/RADIUS Access- 1942 Requests sent from the NAS or tunnel server to the RADIUS server. 1943 Since the Signature attribute involves a HMAC-MD5 hash, it is 1944 possible for the RADIUS server to verify the integrity of the 1945 Access-Request as well as the NAS or tunnel server's identity. 1946 Similarly, Access-Challenge packets sent from the RADIUS server to 1947 the NAS are also authenticated and integrity protected using an 1948 HMAC-MD5 hash, enabling the NAS or tunnel server to determine the 1949 integrity of the packet and verify the identity of the RADIUS server. 1950 Morever, EAP packets sent via methods that contain their own 1951 integrity protection cannot be successfully modified by a rogue NAS 1952 or tunnel server. 1954 The second issue that arises in the case of an EAP server and PPP 1955 authenticator residing on different machines is that the session key 1956 negotiated between the peer and EAP server will need to be 1957 transmitted to the authenticator. Therefore a mechanism needs to be 1958 provided to transmit the session key from the EAP server to the 1959 authenticator or tunnel server that needs to use the key. The 1960 specification of this transit mechanism is outside the scope of this 1961 document. 1963 DRAFT RADIUS Extensions December 1999 1965 6.2.2. Connection hijacking 1967 In this form of attack, the attacker attempts to inject packets into 1968 the conversation between the NAS and the RADIUS server, or between 1969 the RADIUS server and the backend security server. RADIUS does not 1970 support encryption, and as described in [1], only Access-Reply and 1971 Access-Challenge packets are integrity protected. Moreover, the 1972 integrity protection mechanism described in [1] is weaker than that 1973 likely to be used by some EAP methods, making it possible to subvert 1974 those methods by attacking EAP/RADIUS. 1976 In order to provide for authentication of all packets in the EAP 1977 exchange, all EAP/RADIUS packets MUST be authenticated using the 1978 Signature attribute, as described previously. 1980 6.2.3. Man in the middle attacks 1982 Since RADIUS security is based on shared secrets, end-to-end security 1983 is not provided in the case where authentication or accounting 1984 packets are forwarded along a proxy chain. As a result, attackers 1985 gaining control of a RADIUS proxy will be able to modify EAP packets 1986 in transit. 1988 6.2.4. Multiple databases 1990 In many cases a backend security server will be deployed along with a 1991 RADIUS server in order to provide EAP services. Unless the backend 1992 security server also functions as a RADIUS server, two separate user 1993 databases will exist, each containing information about the security 1994 requirements for the user. This represents a weakness, since security 1995 may be compromised by a successful attack on either of the servers, 1996 or their backend databases. With multiple user databases, adding a 1997 new user may require multiple operations, increasing the chances for 1998 error. The problems are further magnified in the case where user 1999 information is also being kept in an LDAP server. In this case, three 2000 stores of user information may exist. 2002 In order to address these threats, consolidation of databases is 2003 recommended. This can be achieved by having both the RADIUS server 2004 and backend security server store information in the same backend 2005 database; by having the backend security server provide a full RADIUS 2006 implementation; or by consolidating both the backend security server 2007 and the RADIUS server onto the same machine. 2009 DRAFT RADIUS Extensions December 1999 2011 6.2.5. Negotiation attacks 2013 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 2014 RADIUS server causes the authenticating peer to choose a less secure 2015 authentication method so as to make it easier to obtain the user's 2016 password. For example, a session that would normally be authenticated 2017 with EAP would instead authenticated via CHAP or PAP; alternatively, 2018 a connection that would normally be authenticated via one EAP type 2019 occurs via a less secure EAP type, such as MD5. The threat posed by 2020 rogue devices, once thought to be remote, has gained currency given 2021 compromises of telephone company switching systems, such as those 2022 described in [8]. 2024 Protection against negotiation attacks requires the elimination of 2025 downward negotiations. This can be achieved via implementation of 2026 per-connection policy on the part of the authenticating peer, and 2027 per-user policy on the part of the RADIUS server. 2029 For the authenticating peer, authentication policy should be set on a 2030 per-connection basis. Per-connection policy allows an authenticating 2031 peer to negotiate EAP when calling one service, while negotiating 2032 CHAP for another service, even if both services are accessible via 2033 the same phone number. 2035 With per-connection policy, an authenticating peer will only attempt 2036 to negotiate EAP for a session in which EAP support is expected. As a 2037 result, there is a presumption that an authenticating peer selecting 2038 EAP requires that level of security. If it cannot be provided, it is 2039 likely that there is some kind of misconfiguration, or even that the 2040 authenticating peer is contacting the wrong server. Should the NAS 2041 not be able to negotiate EAP, or should the EAP-Request sent by the 2042 NAS be of a different EAP type than what is expected, the 2043 authenticating peer MUST disconnect. An authenticating peer expecting 2044 EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. 2046 For a NAS, it may not be possible to determine whether a user is 2047 required to authenticate with EAP until the user's identity is known. 2048 For example, for shared-uses NASes it is possible for one reseller to 2049 implement EAP while another does not. In such cases, if any users of 2050 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 2051 every call. This avoids forcing an EAP-capable client to do more than 2052 one authentication, which weakens security. 2054 If CHAP is negotiated, the NAS will pass the User-Name and CHAP- 2055 Password attributes to the RADIUS Server in an Access-Request packet. 2056 If the user is not required to use EAP, then the RADIUS Server will 2057 respond with an Access-Accept or Access-Reject packet as appropriate. 2058 However, if CHAP has been negotiated but EAP is required, the RADIUS 2060 DRAFT RADIUS Extensions December 1999 2062 server MUST respond with an Access-Reject, rather than an Access- 2063 Challenge/EAP-Message/EAP-Request packet. The authenticating peer 2064 MUST refuse to renegotiate authentication, even if the renegotiation 2065 is from CHAP to EAP. 2067 If EAP is negotiated but is not supported by the RADIUS proxy or 2068 server, then the server or proxy MUST respond with an Access-Reject. 2069 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 2070 user. This is the correct behavior since the authenticating peer is 2071 expecting EAP to be negotiated, and that expectation cannot be 2072 fulfilled. An EAP-capable authenticating peer MUST refuse to 2073 renegotiate the authentication protocol if EAP had initially been 2074 negotiated. Note that problems with a non-EAP capable RADIUS proxy 2075 could prove difficult to diagnose, since a user dialing in from one 2076 location (with an EAP-capable proxy) might be able to successfully 2077 authenticate via EAP, while the same user dialing into another 2078 location (and encountering an EAP-incapable proxy) might be 2079 consistently disconnected. 2081 7. References 2083 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 2084 Authentication Dial In User Service (RADIUS)", RFC 2138, April 2085 1997. 2087 [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 2089 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 2090 Protocol (EAP)", RFC 2284, March 1998. 2092 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2093 Levels." BCP 14, RFC 2119, Harvard University, March, 1997. 2095 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 2096 1700, USC/Information Sciences Institute, October 1994. 2098 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2099 2279, January 1998. 2101 [7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2102 for Message Authentication", RFC 2104, February 1997. 2104 [8] Slatalla, M., and Quittner, J., "Masters of Deception." 2105 HarperCollins, New York, 1995. 2107 DRAFT RADIUS Extensions December 1999 2109 8. Acknowledgements 2111 RADIUS and RADIUS Accounting were originally developed by Livingston 2112 Enterprises (now part of Lucent Technologies) for their PortMaster 2113 series of Network Access Servers. 2115 The section on ARAP is adopted with permission from "Using RADIUS to 2116 Authenticate Apple Remote Access Connections" by Ward Willats of Cyno 2117 Technologies (ward@cyno.com). 2119 The section on Acct-Interim-Interval is adopted with permission from 2120 an earlier Internet-Draft by Pat Calhoun of Sun Microsystems, Mark 2121 Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. 2123 The section on EAP is adopted with permission from an earlier 2124 Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of 2125 Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave 2126 Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of 2127 Microsoft for useful discussions of this problem space. 2129 9. Chair's Address 2131 The RADIUS working group can be contacted via the current chair: 2133 Carl Rigney 2134 Livingston Enterprises 2135 4464 Willow Road 2136 Pleasanton, California 94588 2137 Phone: +1 925 737 2100 2138 E-Mail: cdr@livingston.com 2140 10. Author's Address 2142 Questions about this memo can also be directed to: 2144 Carl Rigney 2145 Livingston Enterprises 2146 4464 Willow Road 2147 Pleasanton, California 94588 2149 E-Mail: cdr@livingston.com 2151 Questions on ARAP and RADIUS may be directed to: 2153 Ward Willats 2155 DRAFT RADIUS Extensions December 1999 2157 Cyno Technologies 2158 1082 Glen Echo Ave 2159 San Jose, CA 95125 2160 Phone: +1 408 297 7766 2161 E-Mail: ward@cyno.com 2163 Questions on EAP and RADIUS may be directed to any of the following: 2165 Pat R. Calhoun 2166 Network and Security Research Center 2167 Sun Microsystems, Inc. 2168 15 Network Circle 2169 Menlo Park, CA 94025 2170 Phone: +1 650 786 7733 2171 E-Mail: pcalhoun@eng.sun.com 2173 Allan C. Rubens 2174 Merit Network, Inc. 2175 4251 Plymouth Rd. 2176 Ann Arbor, MI 48105-2785 2177 Phone: +1 313 647 0417 2178 E-Mail: acr@merit.edu 2180 Bernard Aboba 2181 Microsoft Corporation 2182 One Microsoft Way 2183 Redmond, WA 98052 2184 Phone: +1 425 936 6605 2185 E-Mail: bernarda@microsoft.com 2187 DRAFT RADIUS Extensions December 1999 2189 11. Full Copyright Statement 2191 Copyright (C) The Internet Society (1999). All Rights Reserved. 2193 This document and translations of it may be copied and furnished to 2194 others, and derivative works that comment on or otherwise explain it 2195 or assist in its implmentation may be prepared, copied, published and 2196 distributed, in whole or in part, without restriction of any kind, 2197 provided that the above copyright notice and this paragraph are 2198 included on all such copies and derivative works. However, this 2199 document itself may not be modified in any way, such as by removing 2200 the copyright notice or references to the Internet Society or other 2201 Internet organizations, except as needed for the purpose of 2202 developing Internet standards in which case the procedures for 2203 copyrights defined in the Internet Standards process must be 2204 followed, or as required to translate it into languages other than 2205 English. 2207 The limited permissions granted above are perpetual and will not be 2208 revoked by the Internet Society or its successors or assigns. 2210 This document and the information contained herein is provided on an 2211 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2212 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2213 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2214 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2215 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."