idnits 2.17.1 draft-ietf-radius-ext-06.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 323 has weird spacing: '...y a few piece...' == Line 384 has weird spacing: '...ute and perfo...' == Line 498 has weird spacing: '... passed in an...' == Line 894 has weird spacing: '...pecific code ...' == Line 1655 has weird spacing: '...ute and perfo...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8838 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 1792 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) -- Unexpected draft version: The latest known version of draft-ietf-radius-tunnel-auth is -08, but you're referring to -09. ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '6') -- Unexpected draft version: The latest known version of draft-ietf-radius-tunnel-acct is -04, but you're referring to -05. ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-acct (ref. '7') ** Obsolete normative reference: RFC 2279 (ref. '8') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '9') ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 August 2000 February 2000 9 RADIUS Extensions 10 draft-ietf-radius-ext-06.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 RFC 2026. 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 (2000). 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 xxxx [1] and RFC yyyy [2]. 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 59 2.2 RADIUS support for Apple Remote Access 60 Protocol ........................................ 6 61 2.3 RADIUS Support for Extensible Authentication 62 Protocol (EAP) .................................. 12 63 2.3.1 Protocol Overview ............................... 12 64 2.3.2 Retransmission .................................. 14 65 2.3.3 Fragmentation ................................... 15 66 2.3.4 Examples ........................................ 15 67 2.3.5 Alternative uses ................................ 20 69 3. Packet Format ......................................... 20 71 4. Packet Types .......................................... 20 73 5. Attributes ............................................ 20 74 5.1 Acct-Input-Gigawords ............................ 23 75 5.2 Acct-Output-Gigawords ........................... 23 76 5.3 Event-Timestamp ................................. 24 77 5.4 ARAP-Password ................................... 25 78 5.5 ARAP-Features ................................... 26 79 5.6 ARAP-Zone-Access ................................ 27 80 5.7 ARAP-Security ................................... 28 81 5.8 ARAP-Security-Data .............................. 29 82 5.9 Password-Retry .................................. 29 83 5.10 Prompt .......................................... 30 84 5.11 Connect-Info .................................... 31 85 5.12 Configuration-Token ............................. 32 86 5.13 EAP-Message ..................................... 33 87 5.14 Message-Authenticator ........................... 34 88 5.15 ARAP-Challenge-Response ......................... 36 89 5.16 Acct-Interim-Interval ........................... 37 90 5.17 NAS-Port-Id ..................................... 38 91 5.18 Framed-Pool ..................................... 39 92 5.19 Table of Attributes ............................. 40 94 6. IANA Considerations ................................... 41 96 7. Security Considerations ............................... 41 97 7.1 Message-Authenticator Security .................. 41 98 7.2 EAP Security .................................... 41 99 7.2.1 Separation of EAP server and PPP authenticator 100 7.2.2 Connection hijacking ............................ 43 101 7.2.3 Man in the middle attacks ....................... 43 102 7.2.4 Multiple databases .............................. 43 103 7.2.5 Negotiation attacks ............................. 44 105 8. References ............................................ 45 107 9. Acknowledgements ...................................... 46 109 10. Chair's Address ....................................... 46 111 11. Author's Address ...................................... 47 113 12. Full Copyright Statement .............................. 48 115 1. Introduction 117 RFC xxxx [1] describes the RADIUS Protocol as it is implemented and 118 deployed today, and RFC yyyy [2] describes how Accounting can be 119 performed with RADIUS. 121 This memo suggests several additional Attributes that can be added to 122 RADIUS to perform various useful functions. These Attributes do not 123 have extensive field experience yet and should therefore be 124 considered experimental. 126 The Extensible Authentication Protocol (EAP) [3] is a PPP extension 127 that provides support for additional authentication methods within 128 PPP. This memo describes how the EAP-Message and Message- 129 Authenticator attributes may be used for providing EAP support within 130 RADIUS. 132 All attributes are comprised of variable length Type-Length-Value 3- 133 tuples. New attribute values can be added without disturbing 134 existing implementations of the protocol. 136 1.1. Specification of Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [4]. 142 An implementation is not compliant if it fails to satisfy one or more 143 of the must or must not requirements for the protocols it implements. 144 An implementation that satisfies all the must, must not, should and 145 should not requirements for its protocols is said to be 146 "unconditionally compliant"; one that satisfies all the must and must 147 not requirements but not all the should or should not requirements 148 for its protocols is said to be "conditionally compliant." 150 A NAS that does not implement a given service MUST NOT implement the 151 RADIUS attributes for that service. For example, a NAS that is 152 unable to offer ARAP service MUST NOT implement the RADIUS attributes 153 for ARAP. A NAS MUST treat a RADIUS access-request requesting an 154 unavailable service as an access-reject instead. 156 1.2. Terminology 158 This document uses the following terms: 160 service The NAS provides a service to the dial-in user, such as PPP 161 or Telnet. 163 session Each service provided by the NAS to a dial-in user 164 constitutes a session, with the beginning of the session 165 defined as the point where service is first provided and 166 the end of the session defined as the point where service 167 is ended. A user may have multiple sessions in parallel or 168 series if the NAS supports that, with each session 169 generating a separate start and stop accounting record. 171 silently discard 172 This means the implementation discards the packet without 173 further processing. The implementation SHOULD provide the 174 capability of logging the error, including the contents of 175 the silently discarded packet, and SHOULD record the event 176 in a statistics counter. 178 2. Operation 180 Operation is identical to that defined in RFC xxxx [1] and RFC yyyy 181 [2]. 183 2.1. RADIUS support for Interim Accounting Updates 185 When a user is authenticated, a RADIUS server issues an Access-Accept 186 in response to a successful Access-Request. If the server wishes to 187 receive interim accounting messages for the given user it must 188 include the Acct-Interim-Interval RADIUS attribute in the message, 189 which indicates the interval in seconds between interim messages. 191 It is also possible to statically configure an interim value on the 192 NAS itself. Note that a locally configured value on the NAS MUST 193 override the value found in an Access-Accept. 195 This scheme does not break backward interoperability since a RADIUS 196 server not supporting this extension will simply not add the new 197 Attribute. NASes not supporting this extension will ignore the 198 Attribute. 200 Note that all information in an interim message is cumulative (i.e. 201 number of packets sent is the total since the beginning of the 202 session, not since the last interim message). 204 It is envisioned that an Interim Accounting record (with Acct- 205 Status-Type = Interim-Update (3)) would contain all of the attributes 206 normally found in an Accounting Stop message with the exception of 207 the Acct-Term-Cause attribute. 209 Since all the information is cumulative, a NAS MUST ensure that only 210 a single generation of an interim Accounting message for a given 211 session is present in the retransmission queue at any given time. 213 A NAS MAY use a fudge factor to add a random delay between Interim 214 Accounting messages for separate sessions. This will ensure that a 215 cycle where all messages are sent at once is prevented, such as might 216 otherwise occur if a primary link was recently restored and many 217 dial-up users were directed to the same NAS at once. 219 The Network and NAS CPU load of using Interim Updates should be 220 carefully considered, and appropriate values of Acct-Interim-Interval 221 chosen. 223 2.2. RADIUS support for Apple Remote Access Protocol 225 The RADIUS (Remote Authentication Dial-In User Service) protocol 226 provides a method that allows multiple dial-in Network Access Server 227 (NAS) devices to share a common authentication database. 229 The Apple Remote Access Protocol (ARAP) provides a method for sending 230 AppleTalk network traffic over point-to-point links, typically, but 231 not exclusively, asynchronous and ISDN switched-circuit connections. 232 Though Apple is moving toward ATCP on PPP for future remote access 233 services, ARAP is still a common way for the installed base of 234 Macintosh users to make remote network connections, and is likely to 235 remain so for some time. 237 ARAP is supported by several NAS vendors who also support PPP, IPX 238 and other protocols in the same NAS. ARAP connections in these 239 multi-protocol devices are often not authenticated with RADIUS, or if 240 they are, each vendor creates an individual solution to the problem. 242 This section describes the use of additional RADIUS attributes to 243 support ARAP. RADIUS client and server implementations that implement 244 this specification should be able to authenticate ARAP connections in 245 an interoperable manner. 247 This section assumes prior knowledge of RADIUS, and will go into some 248 detail on the operation of ARAP before entering a detailed discussion 249 of the proposed ARAP RADIUS attributes. 251 There are two features of ARAP this document does not address: 253 1. User initiated password changing. This is not part of RADIUS, 254 but can be implemented through a software process other than 255 RADIUS. 257 2. Out-of-Band messages. At any time, the NAS can send messages to 258 an ARA client which appear in a dialog box on the dial-in user's 259 screen. These are not part of authentication and do not belong 260 here. However, we note that a Reply-Message attribute in an 261 Access-Accept may be sent down to the user as a sign-on message of 262 the day string using the out-of-band channel. 264 We have tried to respect the spirit of the existing RADIUS protocol 265 as much as possible, making design decisions compatible with prior 266 art. Further, we have tried to strike a balance between flooding the 267 RADIUS world with new attributes, and hiding all of ARAP operation 268 within a single multiplexed ARAP attribute string or within Extended 269 Authentication Protocol (EAP) [3] machinery. 271 However, we feel ARAP is enough of a departure from PPP to warrant a 272 small set of similarly named attributes of its own. 274 We have assumed that an ARAP-aware RADIUS server will be able to do 275 DES encryption and generate security module challenges. This is in 276 keeping with the general RADIUS goal of smart server / simple NAS. 278 ARAP authenticates a connection in two phases. The first is a "Two- 279 Way DES" random number exchange, using the user's password as a key. 280 We say "Two-Way" because the ARAP NAS challenges the dial-in client 281 to authenticate itself, and the dial-in client challenges the ARAP 282 NAS to authenticate itself. 284 Specifically, ARAP does the following: 286 1. The NAS sends two 32-bit random numbers to the dial-in client 287 in an ARAP msg_auth_challenge packet. 289 2. The dial-in client uses the user's password to DES encrypt the 290 two random numbers sent to it by the NAS. The dial-in client then 291 sends this result, the user's name and two 32-bit random numbers 292 of its own back to the NAS in an ARAP msg_auth_request packet. 294 3. The NAS verifies the encrypted random numbers sent by the 295 dial-in client are what it expected. If so, it encrypts the dial- 296 in client's challenge using the password and sends it back to the 297 dial-in client in an ARAP msg_auth_response packet. 299 Note that if the dial-in client's response was wrong, meaning the 300 user has the wrong password, the server can initiate a retry sequence 301 up to the maximum amount of retries allowed by the NAS. In this case, 302 when the dial-in client receives the ARAP msg_auth_response packet it 303 will acknowledge it with an ARAP msg_auth_again packet. 305 After this first "DES Phase" the ARAP NAS MAY initiate a secondary 306 authentication phase using what Apple calls "Add-In Security 307 Modules." Security Modules are small pieces of code which run on both 308 the client and server and are allowed to read and write arbitrary 309 data across the communications link to perform additional 310 authentication functions. Various security token vendors use this 311 mechanism to authenticate ARA callers. 313 Although ARAP allows security modules to read and write anything they 314 like, all existing security modules use simple challenge and response 315 cycles, with perhaps some overall control information. This document 316 assumes all existing security modules can be supported with one or 317 more challenge/response cycles. 319 To complicate RADIUS and ARAP integration, ARAP sends down some 320 profile information after the DES Phase and before the Security 321 Module phase. This means that besides the responses to challenges, 322 this profile information must also be present, at somewhat unusual 323 times. Fortunately the information is only a few pieces of numeric 324 data related to passwords, which this document packs into a single 325 new attribute. 327 Presenting an Access-Request to RADIUS on behalf of an ARAP 328 connection is straightforward. The ARAP NAS generates the random 329 number challenge, and then receives the dial-in client's response, 330 the dial-in client's challenge, and the user's name. Assuming the 331 user is not a guest, the following information is forwarded in an 332 Access-Request packet: User-Name (up to 31 characters long), Framed- 333 Protocol (set to 3, ARAP), ARAP-Password, and any additional 334 attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, 335 NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 337 The Request Authenticator is a NAS-generated 16 octet random number. 338 The low-order 8 octets of this number are sent to the dial-in user as 339 the two 4 octet random numbers required in the ARAP 340 msg_auth_challenge packet. Octets 0-3 are the first random number and 341 Octets 4-7 are the second random number. 343 The ARAP-Password in the Access-Request contains a 16 octet random 344 number field, and is used to carry the dial-in user's response to the 345 NAS challenge and the client's own challenge to the NAS. The high- 346 order octets contain the dial-in user's challenge to the NAS (2 32- 347 bit numbers, 8 octets) and the low-order octets contain the dial-in 348 user's response to the NAS challenge (2 32-bit numbers, 8 octets). 350 Only one of User-Password, CHAP-Password, or ARAP-Password needs to 351 be present in an Access-Request, or one or more EAP-Messages. 353 If the RADIUS server does not support ARAP it SHOULD return an 354 Access-Reject to the NAS. 356 If the RADIUS server does support ARAP, it should verify the user's 357 response using the Challenge (from the lower order 8 octets of the 358 Request Authenticator) and the user's response (from the low order 8 359 octets of the ARAP-Password). 361 If that authentication fails, the RADIUS server should return an 362 Access-Reject packet to the NAS, with optional Password-Retry and 363 Reply-Messages attributes. The presence of Password-Retry indicates 364 the ARAP NAS MAY choose to initiate another challenge-response cycle, 365 up to a total number of times equal to the integer value of the 366 Password-Retry attribute. 368 If the user is authenticated, the RADIUS server should return an 369 Access-Accept packet (Code 2) to the NAS, with ID and Response 370 Authenticator as usual, and attributes as follows: 372 Service-Type of Framed-Protocol. 374 Framed-Protocol of ARAP (3). 376 Session-Timeout with the maximum connect time for the user in 377 seconds. If the user is to be given unlimited time, Session- 378 Timeout should not be included in the Access-Accept packet, and 379 ARAP will treat that as an unlimited timeout (-1). 381 ARAP-Challenge-Response, containing 8 octets with the response to 382 the dial-in client's challenge. The RADIUS server calculates this 383 value by taking the dial-in client's challenge from the high order 384 8 octets of the ARAP-Password attribute and performing DES 385 encryption on this value with the authenticating user's password 386 as the key. If the user's password is less than 8 octets in 387 length, the password is padded at the end with NULL octets to a 388 length of 8 before using it as a key. If the user's password is 389 greater than 8 octets in length, an Access-Reject MUST be sent 390 instead. 392 ARAP-Features, containing information that the NAS should send to 393 the user in an ARAP "feature flags" packet. 395 Octet 0: If zero, user cannot change their password. If non- 396 zero user can. (RADIUS does not handle the password changing, 397 just the attribute which indicates whether ARAP indicates they 398 can.) 400 Octet 1: Minimum acceptable password length (0-8). 402 Octet 2-5: Password creation date in Macintosh format, defined 403 as 32 bits unsigned representing seconds since Midnight GMT 404 January 1, 1904. 406 Octet 6-9 Password Expiration Delta from create date in 407 seconds. 409 Octet 10-13: Current RADIUS time in Macintosh format 411 Optionally, a single Reply-Message with a string up to 253 412 characters long which MAY be sent down to the user to be displayed 413 in a sign-on/message of the day dialog. 415 Framed-AppleTalk-Network may be included. 417 Framed-AppleTalk-Zone, up to 32 characters in length, may be 418 included. 420 ARAP defines the notion of a list of zones for a user. Along with 421 a list of zone names, a Zone Access Flag is defined (and used by 422 the NAS) which says how to use the list of zone names. That is, 423 the dial-in user may only be allowed to see the Default Zone, or 424 only the zones in the zone list (inclusive) or any zone except 425 those in the zone list (exclusive). 427 The ARAP NAS handles this by having a named filter which contains 428 (at least) zone names. This solves the problem where a single 429 RADIUS server is managing disparate NAS clients who may not be 430 able to "see" all of the zone names in a user zone list. Zone 431 names only have meaning "at the NAS." The disadvantage of this 432 approach is that zone filters must be set up on the NAS somehow, 433 then referenced by the RADIUS Filter-Id. 435 ARAP-Zone-Access contains an integer which specifies how the "zone 436 list" for this user should be used. If this attribute is present 437 and the value is 2 or 4 then a Filter-Id must also be present to 438 name a zone list filter to apply the access flag to. 440 The inclusion of a Callback-Number or Callback-Id attribute in the 441 Access-Accept MAY cause the ARAP NAS to disconnect after sending 442 the Feature Flags to begin callback processing in an ARAP specific 443 way. 445 Other attributes may be present in the Access-Accept packet as well. 447 An ARAP NAS will need other information to finish bringing up the 448 connection to the dial in client, but this information can be 449 provided by the ARAP NAS without any help from RADIUS, either through 450 configuration by SNMP, a NAS administration program, or deduced by 451 the AppleTalk stack in the NAS. Specifically: 453 1. AppearAsNet and AppearAsNode values, sent to the client to tell 454 it what network and node numbers it should use in its datagram 455 packets. AppearAsNet can be taken from the Framed-AppleTalk- 456 Network attribute or from the configuration or AppleTalk stack on 457 the NAS. 459 2. The "default" zone - that is the name of the AppleTalk zone in 460 which the dial-in client will appear. (Or can be specified with 461 the Framed-AppleTalk-Zone attribute.) 463 3. Other very NAS specific stuff such as the name of the NAS, and 464 smartbuffering information. (Smartbuffering is an ARAP mechanism 465 for replacing common AppleTalk datagrams with small tokens, to 466 improve slow link performance in a few common traffic situations.) 468 4. "Zone List" information for this user. The ARAP specification 469 defines a "zone count" field which is actually unused. 471 RADIUS supports ARAP Security Modules in the following manner. 473 After DES authentication has been completed, the RADIUS server may 474 instruct the ARAP NAS to run one or more security modules for the 475 dial-in user. Although the underlying protocol supports executing 476 multiple security modules in series, in practice all current 477 implementations only allow executing one. Through the use of 478 multiple Access-Challenge requests, multiple modules can be 479 supported, but this facility will probably never be used. 481 We also assume that, even though ARAP allows a free-form dialog 482 between security modules on each end of the point-to-point link, in 483 actual practice all security modules can be reduced to a simple 484 challenge/response cycle. 486 If the RADIUS server wishes to instruct the ARAP NAS to run a 487 security module, it should send an Access-Challenge packet to the NAS 488 with (optionally) the State attribute, plus the ARAP-Challenge- 489 Response, ARAP-Features, and two more attributes: 491 ARAP-Security: a four octet security module signature, containing a 492 Macintosh OSType. 494 ARAP-Security-Data, a string to carry the actual security module 495 challenge and response. 497 When the security module finishes executing, the security module 498 response is passed in an ARAP-Security-Data attribute from the NAS 499 to the RADIUS server in a second Access-Request, also including the 500 State from the Access-Challenge. The authenticator field contains no 501 special information in this case, and this can be discerned by the 502 presence of the State attribute. 504 2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 506 The Extensible Authentication Protocol (EAP), described in [3], 507 provides a standard mechanism for support of additional 508 authentication methods within PPP. Through the use of EAP, support 509 for a number of authentication schemes may be added, including smart 510 cards, Kerberos, Public Key, One Time Passwords, and others. In 511 order to provide for support of EAP within RADIUS, two new 512 attributes, EAP-Message and Message-Authenticator, are introduced in 513 this document. This section describes how these new attributes may be 514 used for providing EAP support within RADIUS. 516 In the proposed scheme, the RADIUS server is used to shuttle RADIUS- 517 encapsulated EAP Packets between the NAS and a backend security 518 server. While the conversation between the RADIUS server and the 519 backend security server will typically occur using a proprietary 520 protocol developed by the backend security server vendor, it is also 521 possible to use RADIUS-encapsulated EAP via the EAP-Message 522 attribute. This has the advantage of allowing the RADIUS server to 523 support EAP without the need for authentication-specific code, which 524 can instead reside on the backend security server. 526 2.3.1. Protocol Overview 528 The EAP conversation between the authenticating peer (dial-in user) 529 and the NAS begins with the negotiation of EAP within LCP. Once EAP 530 has been negotiated, the NAS MUST send an EAP-Request/Identity 531 message to the authenticating peer, unless identity is determined via 532 some other means such as Called-Station-Id or Calling-Station-Id. 533 The peer will then respond with an EAP-Response/Identity which the 534 the NAS will then forward to the RADIUS server in the EAP-Message 535 attribute of a RADIUS Access-Request packet. The RADIUS Server will 536 typically use the EAP-Response/Identity to determine which EAP type 537 is to be applied to the user. 539 In order to permit non-EAP aware RADIUS proxies to forward the 540 Access-Request packet, if the NAS sends the EAP-Request/Identity, the 541 NAS MUST copy the contents of the EAP-Response/Identity into the 542 User-Name attribute and MUST include the EAP-Response/Identity in the 543 User-Name attribute in every subsequent Access-Request. NAS-Port or 544 NAS-Port-Id SHOULD be included in the attributes issued by the NAS in 545 the Access-Request packet, and either NAS-Identifier or NAS-IP- 546 Address MUST be included. In order to permit forwarding of the 547 Access-Reply by EAP-unaware proxies, if a User-Name attribute was 548 included in an Access-Request, the RADIUS Server MUST include the 549 User-Name attribute in subsequent Access-Accept packets. Without the 550 User-Name attribute, accounting and billing becomes very difficult to 551 manage. 553 If identity is determined via another means such as Called-Station-Id 554 or Calling-Station-Id, the NAS MUST include these identifying 555 attributes in every Access-Request. 557 While this approach will save a round-trip, it cannot be universally 558 employed. There are circumstances in which the user's identity may 559 not be needed (such as when authentication and accounting is handled 560 based on Called-Station-Id or Calling-Station-Id), and therefore an 561 EAP-Request/Identity packet may not necessarily be issued by the NAS 562 to the authenticating peer. In cases where an EAP-Request/Identity 563 packet will not be sent, the NAS will send to the RADIUS server a 564 RADIUS Access-Request packet containing an EAP-Message attribute 565 signifying EAP-Start. EAP-Start is indicated by sending an EAP- 566 Message attribute with a length of 2 (no data). However, it should be 567 noted that since no User-Name attribute is included in the Access- 568 Request, this approach is not compatible with RADIUS as specified in 569 [1], nor can it easily be applied in situations where proxies are 570 deployed, such as roaming or shared use networks. 572 If the RADIUS server supports EAP, it MUST respond with an Access- 573 Challenge packet containing an EAP-Message attribute. If the RADIUS 574 server does not support EAP, it MUST respond with an Access-Reject. 575 The EAP-Message attribute includes an encapsulated EAP packet which 576 is then passed on to the authenticating peer. In the case where the 577 NAS does not initially send an EAP-Request/Identity message to the 578 peer, the Access-Challenge typically will contain an EAP-Message 579 attribute encapsulating an EAP-Request/Identity message, requesting 580 the dial-in user to identify themself. The NAS will then respond with 581 a RADIUS Access-Request packet containing an EAP-Message attribute 582 encapsulating an EAP-Response. The conversation continues until 583 either a RADIUS Access-Reject or Access-Accept packet is received. 585 Reception of a RADIUS Access-Reject packet, with or without an EAP- 586 Message attribute encapsulating EAP-Failure, MUST result in the NAS 587 issuing an LCP Terminate Request to the authenticating peer. A 588 RADIUS Access-Accept packet with an EAP-Message attribute 589 encapsulating EAP-Success successfully ends the authentication phase. 590 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain 591 all of the expected attributes which are currently returned in an 592 Access-Accept packet. 594 The above scenario creates a situation in which the NAS never needs 595 to manipulate an EAP packet. An alternative may be used in 596 situations where an EAP-Request/Identity message will always be sent 597 by the NAS to the authenticating peer. 599 For proxied RADIUS requests there are two methods of processing. If 600 the domain is determined based on the Called-Station-Id, the RADIUS 601 Server may proxy the initial RADIUS Access-Request/EAP-Start. If the 602 domain is determined based on the user's identity, the local RADIUS 603 Server MUST respond with a RADIUS Access-Challenge/EAP-Identity 604 packet. The response from the authenticating peer MUST be proxied to 605 the final authentication server. 607 For proxied RADIUS requests, the NAS may receive an Access-Reject 608 packet in response to its Access-Request/EAP-Identity packet. This 609 would occur if the message was proxied to a RADIUS Server which does 610 not support the EAP-Message extension. On receiving an Access-Reject, 611 the NAS MUST send an LCP Terminate Request to the authenticating 612 peer, and disconnect. 614 2.3.2. Retransmission 616 As noted in [3], the EAP authenticator (NAS) is responsible for 617 retransmission of packets between the authenticating peer and the 618 NAS. Thus if an EAP packet is lost in transit between the 619 authenticating peer and the NAS (or vice versa), the NAS will 620 retransmit. As in RADIUS [1], the RADIUS client is responsible for 621 retransmission of packets between the RADIUS client and the RADIUS 622 server. 624 Note that it may be necessary to adjust retransmission strategies and 625 authentication timeouts in certain cases. For example, when a token 626 card is used additional time may be required to allow the user to 627 find the card and enter the token. Since the NAS will typically not 628 have knowledge of the required parameters, these need to be provided 629 by the RADIUS server. This can be accomplished by inclusion of 630 Session-Timeout and Password-Retry attributes within the Access- 631 Challenge packet. 633 If Session-Timeout is present in an Access-Challenge packet that also 634 contains an EAP-Message, the value of the Session-Timeout provides 635 the NAS with the maximum number of seconds the NAS should wait for an 636 EAP-Response before retransmitting the EAP-Message to the dial-in 637 user. 639 2.3.3. Fragmentation 641 Using the EAP-Message attribute, it is possible for the RADIUS server 642 to encapsulate an EAP packet that is larger than the MTU on the link 643 between the NAS and the peer. Since it is not possible for the RADIUS 644 server to use MTU discovery to ascertain the link MTU, the Framed-MTU 645 attribute may be included in an Access-Request packet containing an 646 EAP-Message attribute so as to provide the RADIUS server with this 647 information. 649 2.3.4. Examples 651 The example below shows the conversation between the authenticating 652 peer, NAS, and RADIUS server, for the case of a One Time Password 653 (OTP) authentication. OTP is used only for illustrative purposes; 654 other authentication protocols could also have been used, although 655 they might show somewhat different behavior. 657 Authenticating Peer NAS RADIUS Server 658 ------------------- --- ------------- 660 <- PPP LCP Request-EAP 661 auth 662 PPP LCP ACK-EAP 663 auth -> 664 <- PPP EAP-Request/ 665 Identity 666 PPP EAP-Response/ 667 Identity (MyID) -> 668 RADIUS 669 Access-Request/ 670 EAP-Message/ 671 EAP-Response/ 672 (MyID) -> 673 <- RADIUS 674 Access-Challenge/ 675 EAP-Message/EAP-Request 676 OTP/OTP Challenge 677 <- PPP EAP-Request/ 678 OTP/OTP Challenge 679 PPP EAP-Response/ 680 OTP, OTPpw -> 681 RADIUS 682 Access-Request/ 683 EAP-Message/ 684 EAP-Response/ 685 OTP, OTPpw -> 686 <- RADIUS 687 Access-Accept/ 688 EAP-Message/EAP-Success 689 (other attributes) 690 <- PPP EAP-Success 691 PPP Authentication 692 Phase complete, 693 NCP Phase starts 695 In the case where the NAS first sends an EAP-Start packet to the 696 RADIUS server, the conversation would appear as follows: 698 Authenticating Peer NAS RADIUS Server 699 ------------------- --- ------------- 701 <- PPP LCP Request-EAP 702 auth 703 PPP LCP ACK-EAP 704 auth -> 705 RADIUS 706 Access-Request/ 707 EAP-Message/Start -> 708 <- RADIUS 709 Access-Challenge/ 710 EAP-Message/Identity 711 <- PPP EA-Request/ 712 Identity 713 PPP EAP-Response/ 714 Identity (MyID) -> 715 RADIUS 716 Access-Request/ 717 EAP-Message/ 718 EAP-Response/ 719 (MyID) -> 720 <- RADIUS 721 Access-Challenge/ 722 EAP-Message/EAP-Request 723 OTP/OTP Challenge 724 <- PPP EAP-Request/ 725 OTP/OTP Challenge 726 PPP EAP-Response/ 727 OTP, OTPpw -> 728 RADIUS 729 Access-Request/ 730 EAP-Message/ 731 EAP-Response/ 732 OTP, OTPpw -> 733 <- RADIUS 734 Access-Accept/ 735 EAP-Message/EAP-Success 736 (other attributes) 737 <- PPP EAP-Success 738 PPP Authentication 739 Phase complete, 740 NCP Phase starts 742 In the case where the client fails EAP authentication, the 743 conversation would appear as follows: 745 Autheticating Peer NAS RADIUS Server 746 ------------------- --- ------------- 748 <- PPP LCP Request-EAP 749 auth 750 PPP LCP ACK-EAP 751 auth -> 752 Access-Request/ 753 EAP-Message/Start -> 754 <- RADIUS 755 Access-Challenge/ 756 EAP-Message/Identity 757 <- PPP EAP-Request/ 758 Identity 759 PPP EAP-Response/ 760 Identity (MyID) -> 761 RADIUS 762 Access-Request/ 763 EAP-Message/ 764 EAP-Response/ 765 (MyID) -> 766 <- RADIUS 767 Access-Challenge/ 768 EAP-Message/EAP-Request 769 OTP/OTP Challenge 770 <- PPP EAP-Request/ 771 OTP/OTP Challenge 772 PPP EAP-Response/ 773 OTP, OTPpw -> 774 RADIUS 775 Access-Request/ 776 EAP-Message/ 777 EAP-Response/ 778 OTP, OTPpw -> 779 <- RADIUS 780 Access-Reject/ 781 EAP-Message/EAP-Failure 783 <- PPP EAP-Failure 784 (client disconnected) 786 In the case that the RADIUS server or proxy does not support EAP- 787 Message, the conversation would appear as follows: 789 Authenticating Peer NAS RADIUS Server 790 ------------------- --- ------------- 792 <- PPP LCP Request-EAP 793 auth 794 PPP LCP ACK-EAP 795 auth -> 796 RADIUS 797 Access-Request/ 798 EAP-Message/Start -> 799 <- RADIUS 800 Access-Reject 801 <- PPP LCP Terminate 802 (User Disconnected) 804 In the case where the local RADIUS Server does support EAP-Message, 805 but the remote RADIUS Server does not, the conversation would appear 806 as follows: 808 Authenticating Peer NAS RADIUS Server 809 ------------------- --- ------------- 811 <- PPP LCP Request-EAP 812 auth 813 PPP LCP ACK-EAP 814 auth -> 815 RADIUS 816 Access-Request/ 817 EAP-Message/Start -> 818 <- RADIUS 819 Access-Challenge/ 820 EAP-Message/Identity 821 <- PPP EAP-Request/ 822 Identity 823 PPP EAP-Response/ 824 Identity 825 (MyID) -> 826 RADIUS 827 Access-Request/ 828 EAP-Message/EAP-Response/ 829 (MyID) -> 830 <- RADIUS 831 Access-Reject 832 (proxied from remote 833 RADIUS Server) 834 <- PPP LCP Terminate 835 (User Disconnected) 837 In the case where the authenticating peer does not support EAP, but 838 where EAP is required for that user, the conversation would appear as 839 follows: 841 Authenticating Peer NAS RADIUS Server 842 ------------------- --- ------------- 844 <- PPP LCP Request-EAP 845 auth 846 PPP LCP NAK-EAP 847 auth -> 848 <- PPP LCP Request-CHAP 849 auth 850 PPP LCP ACK-CHAP 851 auth -> 852 <- PPP CHAP Challenge 853 PPP CHAP Response -> 854 RADIUS 855 Access-Request/ 856 User-Name, 857 CHAP-Password -> 858 <- RADIUS 859 Access-Reject 860 <- PPP LCP Terminate 861 (User Disconnected) 863 In the case where the NAS does not support EAP, but where EAP is 864 required for that user, the conversation would appear as follows: 866 Authenticating Peer NAS RADIUS Server 867 ---------------- --- ------------- 869 <- PPP LCP Request-CHAP 870 auth 871 PP LCP ACK-CHAP 872 auth -> 873 <- PPP CHAP Challenge 874 PPP CHAP Response -> 875 RADIUS 876 Access-Request/ 877 User-Name, 878 CHAP-Password -> 879 <- RADIUS 880 Access-Reject 881 <- PPP LCP Terminate 882 (User Disconnected) 884 2.3.5. Alternative uses 886 Currently the conversation between the backend security server and 887 the RADIUS server is proprietary because of lack of standardization. 888 In order to increase standardization and provide interoperability 889 between Radius vendors and backend security vendors, it is 890 recommended that RADIUS-encapsulated EAP be used for this 891 conversation. 893 This has the advantage of allowing the RADIUS server to support EAP 894 without the need for authentication-specific code within the RADIUS 895 server. Authentication-specific code can then reside on a backend 896 security server instead. 898 In the case where RADIUS-encapsulated EAP is used in a conversation 899 between a RADIUS server and a backend security server, the security 900 server will typically return an Access-Accept/EAP-Success message 901 without inclusion of the expected attributes currently returned in an 902 Access-Accept. This means that the RADIUS server MUST add these 903 attributes prior to sending an Access-Accept/EAP-Success message to 904 the NAS. 906 3. Packet Format 908 Packet Format is identical to that defined in RFC xxxx [1] and yyyy 909 [2] 911 4. Packet Types 913 Packet types are identical to those defined in RFC xxxx [1] and yyyy 914 [2]. 916 See "Table of Attributes" below to determine which types of packets 917 can contain which attributes defined here. 919 5. Attributes 921 RADIUS Attributes carry the specific authentication, authorization 922 and accounting details for the request and response. 924 Some attributes MAY be included more than once. The effect of this 925 is attribute specific, and is specified in each attribute 926 description. The order of attributes of the same type SHOULD be 927 preserved. The order of attributes of different types is not 928 required to be preserved. 930 The end of the list of attributes is indicated by the Length of the 931 RADIUS packet. 933 A summary of the attribute format is the same as in RFC xxxx [1] but 934 is included here for ease of reference. The fields are transmitted 935 from left to right. 937 0 1 2 938 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Type | Length | Value ... 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Type 945 The Type field is one octet. Up-to-date values of the RADIUS Type 946 field are specified in the most recent "Assigned Numbers" RFC [5]. 947 Values 192-223 are reserved for experimental use, values 224-240 948 are reserved for implementation-specific use, and values 241-255 949 are reserved and should not be used. This specification concerns 950 the following values: 952 1-39 (refer to RFC xxxx [1], "RADIUS") 953 40-51 (refer to RFC yyyy [2], "RADIUS Accounting") 954 52 Acct-Input-Gigawords 955 53 Acct-Output-Gigawords 956 54 Unused 957 55 Event-Timestamp 958 56-59 Unused 959 60-63 (refer to RFC xxxx [1], "RADIUS") 960 64-67 (refer to [6]) 961 68 (refer to [7]) 962 69 (refer to [6]) 963 70 ARAP-Password 964 71 ARAP-Features 965 72 ARAP-Zone-Access 966 73 ARAP-Security 967 74 ARAP-Security-Data 968 75 Password-Retry 969 76 Prompt 970 77 Connect-Info 971 78 Configuration-Token 972 79 EAP-Message 973 80 Message-Authenticator 974 81-83 (refer to [6]) 975 84 ARAP-Challenge-Response 976 85 Acct-Interim-Interval 977 86 (refer to [7]) 978 87 NAS-Port-Id 979 88 Framed-Pool 980 89 Unused 981 90-91 (refer to [6]) 982 92-191 Unused 984 Length 986 The Length field is one octet, and indicates the length of this 987 attribute including the Type, Length and Value fields. If an 988 attribute is received in a packet with an invalid Length, the 989 entire request should be silently discarded. 991 Value 993 The Value field is zero or more octets and contains information 994 specific to the attribute. The format and length of the Value 995 field is determined by the Type and Length fields. 997 Note that a "string" in RADIUS does not terminate with a NUL (hex 998 00). The Attribute has a length field and does not use a 999 terminator. Strings may contain UTF-8 characters or 8-bit binary 1000 data and servers and clients should be able to deal with embedded 1001 nulls. RADIUS implementers using C are cautioned not to use 1002 strcpy() when handling strings. 1004 The format of the value field is one of four data types. 1006 string 1-253 octets. Strings of length zero (0) MUST NOT be 1007 sent; omit the entire attribute instead. 1009 address 32 bit unsigned value, most significant octet first. 1011 integer 32 bit unsigned value, most significant octet first. 1013 time 32 bit unsigned value, most significant octet first -- 1014 seconds since 00:00:00 UTC, January 1, 1970. 1016 5.1. Acct-Input-Gigawords 1018 Description 1020 This attribute indicates how many times the Acct-Input-Octets 1021 counter has wrapped around 2^32 over the course of this service 1022 being provided, and can only be present in Accounting-Request 1023 records where the Acct-Status-Type is set to Stop or Interim- 1024 Update. 1026 A summary of the Acct-Input-Gigawords attribute format is shown 1027 below. The fields are transmitted from left to right. 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Type | Length | Value 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Value (cont) | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 Type 1039 52 for Acct-Input-Gigawords. 1041 Length 1043 6 1045 Value 1047 The Value field is four octets. 1049 5.2. Acct-Output-Gigawords 1051 Description 1053 This attribute indicates how many times the Acct-Output-Octets 1054 counter has wrapped around 2^32 in the course of delivering this 1055 service, and can only be present in Accounting-Request records 1056 where the Acct-Status-Type is set to Stop or Interim-Update. 1058 A summary of the Acct-Output-Gigawords attribute format is shown 1059 below. The fields are transmitted from left to right. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Length | Value 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Value (cont) | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 Type 1071 53 for Acct-Output-Gigawords. 1073 Length 1075 6 1077 Value 1079 The Value field is four octets. 1081 5.3. Event-Timestamp 1083 Description 1085 This attribute is included in an Accounting-Request packet to 1086 record the time that this event occured on the NAS, in seconds 1087 since January 1, 1970 00:00 UTC. 1089 A summary of the Event-Timestamp attribute format is shown below. 1090 The fields are transmitted from left to right. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Value 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 Value (cont) | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Type 1102 55 for Event-Timestamp 1104 Length 1106 6 1108 Value 1110 The Value field is four octets encoding an unsigned integer with 1111 the number of seconds since January 1, 1970 00:00 UTC. 1113 5.4. ARAP-Password 1115 Description 1117 This attribute is only present in an Access-Request packet 1118 containing a Framed-Protocol of ARAP. 1120 Only one of User-Password, CHAP-Password, or ARAP-Password needs 1121 to be present in an Access-Request, or one or more EAP-Messages. 1123 A summary of the ARAP-Password attribute format is shown below. The 1124 fields are transmitted from left to right. 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Type | Length | Value1 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Value2 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Value3 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Value4 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 Type 1142 70 for ARAP-Password. 1144 Length 1146 18 1148 Value 1150 This attribute contains a 16 octet string, used to carry the 1151 dial-in user's response to the NAS challenge and the client's own 1152 challenge to the NAS. The high-order octets (Value1 and Value2) 1153 contain the dial-in user's challenge to the NAS (2 32-bit numbers, 1154 8 octets) and the low-order octets (Value3 and Value4) contain the 1155 dial-in user's response to the NAS challenge (2 32-bit numbers, 8 1156 octets). 1158 5.5. ARAP-Features 1160 Description 1162 This attribute is sent in an Access-Accept packet with Framed- 1163 Protocol of ARAP, and includes password information that the NAS 1164 should sent to the user in an ARAP "feature flags" packet. 1166 A summary of the ARAP-Features attribute format is shown below. The 1167 fields are transmitted from left to right. 1169 0 1 2 3 1170 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 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Type | Length | Value1 | Value2 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Value3 | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Value4 | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Value5 | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 Type 1183 71 for ARAP-Features. 1185 Length 1187 16 1189 Value 1191 The Value field is a compound string containing information the 1192 NAS should send to the user in the ARAP "feature flags" packet. 1194 Value1: If zero, user cannot change their password. If non-zero 1195 user can. (RADIUS does not handle the password changing, just 1196 the attribute which indicates whether ARAP indicates they can.) 1198 Value2: Minimum acceptable password length, from 0 to 8. 1200 Value3: Password creation date in Macintosh format, defined as 1201 32 unsigned bits representing seconds since Midnight GMT 1202 January 1, 1904. 1204 Value4: Password Expiration Delta from create date in seconds. 1206 Value5: Current RADIUS time in Macintosh format. 1208 5.6. ARAP-Zone-Access 1210 Description 1212 This attribute is included in an Access-Accept packet with 1213 Framed-Protocol of ARAP to indicate how the ARAP zone list for the 1214 user should be used. 1216 A summary of the ARAP-Zone-Access attribute format is shown below. 1217 The fields are transmitted from left to right. 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Type | Length | Value 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 Value (cont) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Type 1229 72 for ARAP-Zone-Access. 1231 Length 1233 6 1235 Value 1237 The Value field is four octets encoding an integer with one of the 1238 following values: 1240 1 Only allow access to default zone 1241 2 Use zone filter inclusively 1242 4 Use zone filter exclusively 1244 The value 3 is skipped, not because these are bit flags, but 1245 because 3 in some ARAP implementations means "all zones" which is 1246 the same as not specifying a list at all under RADIUS. 1248 If this attribute is present and the value is 2 or 4 then a 1249 Filter-Id must also be present to name a zone list filter to apply 1250 the access flag to. 1252 5.7. ARAP-Security 1254 Description 1256 This attribute identifies the ARAP Security Module to be used in 1257 an Access-Challenge packet. 1259 A summary of the ARAP-Security attribute format is shown below. The 1260 fields are transmitted from left to right. 1262 0 1 2 3 1263 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 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Type | Length | Value 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Value (cont) | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 Type 1272 73 for ARAP-Security. 1274 Length 1276 6 1278 Value 1280 The Value field is four octets, containing an integer specifying 1281 the security module signature, which is a Macintosh OSType. 1282 (Macintosh OSTypes are 4 ascii characters cast as a 32-bit 1283 integer) 1285 5.8. ARAP-Security-Data 1287 Description 1289 This attribute contains the actual security module challenge or 1290 response, and can be found in Access-Challenge and Access-Request 1291 packets. 1293 A summary of the ARAP-Security-Data attribute format is shown below. 1294 The fields are transmitted from left to right. 1296 0 1 2 1297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Type | Length | String... 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 Type 1304 74 for ARAP-Security-Data. 1306 Length 1308 >=3 1310 String 1312 The String field contains the security module challenge or 1313 response associated with the ARAP Security Module specified in 1314 ARAP-Security. 1316 5.9. Password-Retry 1318 Description 1320 This attribute MAY be included in an Access-Reject to indicate how 1321 many authentication attempts a user may be allowed to attempt 1322 before being disconnected. 1324 It is primarily intended for use with ARAP authentication. 1326 A summary of the Password-Retry attribute format is shown below. The 1327 fields are transmitted from left to right. 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Type | Length | Value 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 Value (cont) | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 Type 1339 75 for Password-Retry. 1341 Length 1343 6 1345 Value 1347 The Value field is four octets, containing an integer specifying 1348 the number of password retry attempts to permit the user. 1350 5.10. Prompt 1352 Description 1354 This attribute is used only in Access-Challenge packets, and 1355 indicates to the NAS whether it should echo the user's response as 1356 it is entered, or not echo it. 1358 A summary of the Prompt attribute format is shown below. The fields 1359 are transmitted from left to right. 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Type | Length | Value 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Value (cont) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 Type 1370 76 for Prompt. 1372 Length 1374 6 1376 Value 1378 The Value field is four octets. 1380 0 No Echo 1381 1 Echo 1383 5.11. Connect-Info 1385 Description 1387 This attribute is sent from the NAS to indicate the nature of the 1388 user's connection. 1390 The NAS MAY send this attribute in an Access-Request or 1391 Accounting-Request to indicate the nature of the user's 1392 connection. 1394 A summary of the Connect-Info attribute format is shown below. The 1395 fields are transmitted from left to right. 1397 0 1 2 1398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Type | Length | String... 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 Type 1405 77 for Connect-Info. 1407 Length 1409 >= 3 1411 String 1413 The String field is encoded as UTF-8 [8] characters. The 1414 connection speed SHOULD be included at the beginning of the first 1415 Connect-Info attribute in the packet. If the transmit and receive 1416 connection speeds differ, they may both be included in the first 1417 attribute with the transmit speed first (the speed the NAS modem 1418 transmits at), a slash (/), the receive speed, then optionally 1419 other information. 1421 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1423 More than one Connect-Info attribute may be present in an 1424 Accounting-Request packet to accommodate expected efforts by ITU 1425 to have modems report more connection information in a standard 1426 format that might exceed 252 octets. 1428 5.12. Configuration-Token 1430 Description 1432 This attribute is for use in large distributed authentication 1433 networks based on proxy. It is sent from a RADIUS Proxy Server to 1434 a RADIUS Proxy Client in an Access-Accept to indicate a type of 1435 user profile to be used. It should not be sent to a NAS. 1437 A summary of the Configuration-Token attribute format is shown below. 1438 The fields are transmitted from left to right. 1440 0 1 2 1441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | Type | Length | String ... 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 Type 1448 78 for Configuration-Token. 1450 Length 1452 >= 3 1454 String 1456 The String field is one or more octets. The actual format of the 1457 information is site or application specific, and a robust 1458 implementation SHOULD support the field as undistinguished octets. 1460 The codification of the range of allowed usage of this field is 1461 outside the scope of this specification. 1463 5.13. EAP-Message 1465 Description 1467 This attribute encapsulates Extended Access Protocol [3] packets 1468 so as to allow the NAS to authenticate dial-in users via EAP 1469 without having to understand the EAP protocol. 1471 The NAS places any EAP messages received from the user into one or 1472 more EAP attributes and forwards them to the RADIUS Server as part 1473 of the Access-Request, which can return EAP messages in Access- 1474 Challenge, Access-Accept and Access-Reject packets. 1476 A RADIUS Server receiving EAP messages that it does not understand 1477 SHOULD return an Access-Reject. 1479 The NAS places EAP messages received from the authenticating peer 1480 into one or more EAP-Message attributes and forwards them to the 1481 RADIUS Server within an Access-Request message. If multiple EAP- 1482 Messages are contained within an Access-Request or Access- 1483 Challenge packet, they MUST be in order and they MUST be 1484 consecutive attributes in the Access-Request or Access-Challenge 1485 packet. Access-Accept and Access-Reject packets SHOULD only have 1486 ONE EAP-Message attribute in them, containing EAP-Success or EAP- 1487 Failure. 1489 It is expected that EAP will be used to implement a variety of 1490 authentication methods, including methods involving strong 1491 cryptography. In order to prevent attackers from subverting EAP by 1492 attacking RADIUS/EAP, (for example, by modifying the EAP-Success 1493 or EAP-Failure packets) it is necessary that RADIUS/EAP provide 1494 integrity protection at least as strong as those used in the EAP 1495 methods themselves. 1497 Therefore the Message-Authenticator attribute MUST be used to 1498 protect all Access-Request, Access-Challenge, Access-Accept, and 1499 Access-Reject packets containing an EAP-Message attribute. 1501 Access-Request packets including an EAP-Message attribute without 1502 a Message-Authenticator attribute SHOULD be silently discarded by 1503 the RADIUS server. A RADIUS Server supporting EAP-Message MUST 1504 calculate the correct value of the Message-Authenticator and 1505 silently discard the packet if it does not match the value sent. 1506 A RADIUS Server not supporting EAP-Message MUST return an Access- 1507 Reject if it receives an Access-Request containing an EAP-Message 1508 attribute. A RADIUS Server receiving an EAP-Message attribute that 1509 it does not understand MUST return an Access-Reject. 1511 Access-Challenge, Access-Accept, or Access-Reject packets 1512 including an EAP-Message attribute without a Message-Authenticator 1513 attribute SHOULD be silently discarded by the NAS. A NAS 1514 supporting EAP-Message MUST calculate the correct value of the 1515 Message-Authenticator and silently discard the packet if it does 1516 not match the value sent. 1518 A summary of the EAP-Message attribute format is shown below. The 1519 fields are transmitted from left to right. 1521 0 1 2 1522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Type | Length | String... 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 Type 1529 79 for EAP-Message. 1531 Length 1533 >= 3 (EAP packet enclosed) 1534 = 2 (EAP-Start message) 1536 String 1538 The String field contains EAP packets, as defined in [3]. If 1539 multiple EAP-Message attributes are present in a packet their 1540 values should be concatenated; this allows EAP packets longer than 1541 253 octets to be passed by RADIUS. 1543 5.14. Message-Authenticator 1545 Description 1546 This attribute MAY be used to sign Access-Requests to prevent 1547 spoofing Access-Requests using CHAP, ARAP or EAP authentication 1548 methods. It MAY be used in any Access-Request. It MUST be used 1549 in any Access-Request, Access-Accept, Access-Reject or Access- 1550 Challenge that includes an EAP-Message attribute. 1552 A RADIUS Server receiving an Access-Request with a Message- 1553 Authenticator Attribute present MUST calculate the correct value 1554 of the Message-Authenticator and silently discard the packet if it 1555 does not match the value sent. 1557 A RADIUS Client receiving an Access-Accept, Access-Reject or 1558 Access-Challenge with a Message-Authenticator Attribute present 1559 MUST calculate the correct value of the Message-Authenticator and 1560 silently discard the packet if it does not match the value sent. 1562 Earlier drafts of this memo used "Signature" as the name of this 1563 attribute, but Message-Authenticator is more precise. Its 1564 operation has not changed, just the name. 1566 A summary of the Message-Authenticator attribute format is shown 1567 below. The fields are transmitted from left to right. 1569 0 1 2 1570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Type | Length | String... 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Type 1577 80 for Message-Authenticator 1579 Length 1581 18 1583 String 1585 When present in an Access-Request packet, Message-Authenticator is 1586 an HMAC-MD5 [9] checksum of the entire Access-Request packet, 1587 including Type, ID, Length and authenticator, using the shared 1588 secret as the key, as follows. 1590 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 1591 Request Authenticator, Attributes) 1592 When the checksum is calculated the signature string should be 1593 considered to be sixteen octets of zero. 1595 For Access-Challenge, Access-Accept, and Access-Reject packets, 1596 the Message-Authenticator is calculated as follows, using the 1597 Request-Authenticator from the Access-Request this packet is in 1598 reply to: 1600 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 1601 Request Authenticator, Attributes) 1603 When the checksum is calculated the signature string should be 1604 considered to be sixteen octets of zero. The shared secret is 1605 used as the key for the HMAC-MD5 hash. The is calculated and 1606 inserted in the packet before the Response Authenticator is 1607 calculated. 1609 This attribute is not needed if the User-Password attribute is 1610 present, but is useful for preventing attacks on other types of 1611 authentication. This attribute is intended to thwart attempts by 1612 an attacker to setup a "rogue" NAS, and perform online dictionary 1613 attacks against the RADIUS server. It does not afford protection 1614 against "offline" attacks where the attacker intercepts packets 1615 containing (for example) CHAP challenge and response, and performs 1616 a dictionary attack against those packets offline. 1618 IP Security will eventually make this attribute unnecessary, so it 1619 should be considered an interim measure. 1621 5.15. ARAP-Challenge-Response 1623 Description 1625 This attribute is sent in an Access-Accept packet with Framed- 1626 Protocol of ARAP, and contains the response to the dial-in 1627 client's challenge. 1629 A summary of the ARAP-Challenge-Response attribute format is shown 1630 below. The fields are transmitted from left to right. 1632 0 1 2 3 1633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Type | Length | Value... 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 Type 1644 84 for ARAP-Challenge-Response. 1646 Length 1648 10 1650 Value 1652 The Value field contains an 8 octet response to the dial-in 1653 client's challenge. The RADIUS server calculates this value by 1654 taking the dial-in client's challenge from the high order 8 octets 1655 of the ARAP-Password attribute and performing DES encryption on 1656 this value with the authenticating user's password as the key. If 1657 the user's password is less than 8 octets in length, the password 1658 is padded at the end with NULL octets to a length of 8 before 1659 using it as a key. 1661 5.16. Acct-Interim-Interval 1663 Description 1665 This attribute indicates the number of seconds between each 1666 interim update in seconds for this specific session. This value 1667 can only appear in the Access-Accept message. 1669 A summary of the Acct-Interim-Interval attribute format is shown 1670 below. The fields are transmitted from left to right. 1672 0 1 2 3 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Type | Length | Value 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Value (cont) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Type 1682 85 for Acct-Interim-Interval. 1684 Length 1686 6 1688 Value 1690 The Value field contains the number of seconds between each 1691 interim update to be sent from the NAS for this session. The value 1692 MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 1693 600, and careful consideration should be given to its impact on 1694 network traffic. 1696 5.17. NAS-Port-Id 1698 Description 1700 This Attribute contains a string which identifies the port of the 1701 NAS which is authenticating the user. It is only used in Access- 1702 Request and Accounting-Request packets. Note that this is using 1703 "port" in its sense of a physical connection on the NAS, not in 1704 the sense of a TCP or UDP port number. 1706 Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- 1707 Request packet, if the NAS differentiates among its ports. NAS- 1708 Port-Id is intended for use by NASes which cannot conveniently 1709 number their ports. 1711 A summary of the NAS-Port-Id Attribute format is shown below. The 1712 fields are transmitted from left to right. 1714 0 1 2 1715 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Type | Length | String... 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 Type 1722 87 for NAS-Port-Id. 1724 Length 1726 >= 3 1728 String 1730 The String field contains the name of the port in UTF-8 [8] 1731 format. 1733 5.18. Framed-Pool 1735 Description 1737 This Attribute contains the name of an assigned address pool that 1738 SHOULD be used to assign an address for the user. If a NAS does 1739 not support multiple address pools, the NAS should ignore this 1740 Attribute. Address pools are usually used for IP addresses, but 1741 can be used for other protocols if the NAS supports pools for 1742 those protocols. 1744 A summary of the Framed-Pool Attribute format is shown below. The 1745 fields are transmitted from left to right. 1747 0 1 2 1748 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Type | Length | String... 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 Type 1754 88 for Framed-Pool 1756 Length 1758 >= 3 1760 String 1762 The string field contains the name of an assigned address pool 1763 configured on the NAS. 1765 5.19. Table of Attributes 1767 The following table provides a guide to which attributes may be found 1768 in which kind of packets. Acct-Input-Gigawords, Acct-Output- 1769 Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in 1770 an Accounting-Request packet. Connect-Info may have 0+ instances in 1771 an Accounting-Request packet. The other attributes added in this 1772 document must not be present in an Accounting-Request. 1774 Request Accept Reject Challenge # Attribute 1775 0-1 0 0 0 70 ARAP-Password [Note 1] 1776 0 0-1 0 0-1 71 ARAP-Features 1777 0 0-1 0 0 72 ARAP-Zone-Access 1778 0-1 0 0 0-1 73 ARAP-Security 1779 0+ 0 0 0+ 74 ARAP-Security-Data 1780 0 0 0-1 0 75 Password-Retry 1781 0 0 0 0-1 76 Prompt 1782 0-1 0 0 0 77 Connect-Info 1783 0 0+ 0 0 78 Configuration-Token 1784 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 1785 0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1] 1786 0 0-1 0 0-1 84 ARAP-Challenge-Response 1787 0 0-1 0 0 85 Acct-Interim-Interval 1788 0-1 0 0 0 87 NAS-Port-Id 1789 0 0-1 0 0 88 Framed-Pool 1790 Request Accept Reject Challenge # Attribute 1792 [Note 1] An Access-Request that contains either a User-Password or 1793 CHAP-Password or ARAP-Password or one or more EAP-Message attributes 1794 MUST NOT contain more than one type of those four attributes. If it 1795 does not contain any of those four attributes, it SHOULD contain a 1796 Message-Authenticator. If any packet type contains an EAP-Message 1797 attribute it MUST also contain a Message-Authenticator. 1799 The following table defines the above table entries. 1801 0 This attribute MUST NOT be present 1802 0+ Zero or more instances of this attribute MAY be present. 1803 0-1 Zero or one instance of this attribute MAY be present. 1804 1 Exactly one instance of this attribute MUST be present. 1806 6. IANA Considerations 1808 The Packet Type Codes, Attribute Types, and Attribute Values defined 1809 in this document are registered by the Internet Assigned Numbers 1810 Authority (IANA) from the RADIUS name spaces as described in the 1811 "IANA Considerations" section of [1], in accordance with BCP 26 [10]. 1813 7. Security Considerations 1815 The attributes other than Message-Authenticator and EAP-Message in 1816 this document have no additional security considerations beyond those 1817 already identified in [1]. 1819 7.1. Message-Authenticator Security 1821 Access-Request packets with a User-Password establish the identity of 1822 both the user and the NAS sending the Access-Request, because of the 1823 way the shared secret between NAS and RADIUS server is used. 1824 Access-Request packets with CHAP-Password or EAP-Message do not have 1825 a User-Password attribute, so the Message-Authenticator attribute 1826 should be used in access-request packets that do not have a User- 1827 Password, in order to establish the identity of the NAS sending the 1828 request. 1830 7.2. EAP Security 1832 Since the purpose of EAP is to provide enhanced security for PPP 1833 authentication, it is critical that RADIUS support for EAP be secure. 1834 In particular, the following issues must be addressed: 1835 Separation of EAP server and PPP authenticator 1836 Connection hijacking 1837 Man in the middle attacks 1838 Multiple databases 1839 Negotiation attacks 1841 7.2.1. Separation of EAP server and PPP authenticator 1843 It is possible for the EAP endpoints to mutually authenticate, 1844 negotiate a ciphersuite, and derive a session key for subsequent use 1845 in PPP encryption. 1847 This does not present an issue on the peer, since the peer and EAP 1848 client reside on the same machine; all that is required is for the 1849 EAP client module to pass the session key to the PPP encryption 1850 module. 1852 The situation is more complex when EAP is used with RADIUS, since the 1853 PPP authenticator will typically not reside on the same machine as 1854 the EAP server. For example, the EAP server may be a backend security 1855 server, or a module residing on the RADIUS server. 1857 In the case where the EAP server and PPP authenticator reside on 1858 different machines, there are several implications for security. 1859 Firstly, mutual authentication will occur between the peer and the 1860 EAP server, not between the peer and the authenticator. This means 1861 that it is not possible for the peer to validate the identity of the 1862 NAS or tunnel server that it is speaking to. 1864 As described earlier, when EAP/RADIUS is used to encapsulate EAP 1865 packets, the Message-Authenticator attribute is required in 1866 EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the 1867 RADIUS server. Since the Message-Authenticator attribute involves a 1868 HMAC-MD5 hash, it is possible for the RADIUS server to verify the 1869 integrity of the Access-Request as well as the NAS or tunnel server's 1870 identity. Similarly, Access-Challenge packets sent from the RADIUS 1871 server to the NAS are also authenticated and integrity protected 1872 using an HMAC-MD5 hash, enabling the NAS or tunnel server to 1873 determine the integrity of the packet and verify the identity of the 1874 RADIUS server. Morever, EAP packets sent via methods that contain 1875 their own integrity protection cannot be successfully modified by a 1876 rogue NAS or tunnel server. 1878 The second issue that arises in the case of an EAP server and PPP 1879 authenticator residing on different machines is that the session key 1880 negotiated between the peer and EAP server will need to be 1881 transmitted to the authenticator. Therefore a mechanism needs to be 1882 provided to transmit the session key from the EAP server to the 1883 authenticator or tunnel server that needs to use the key. The 1884 specification of this transit mechanism is outside the scope of this 1885 document. 1887 7.2.2. Connection hijacking 1889 In this form of attack, the attacker attempts to inject packets into 1890 the conversation between the NAS and the RADIUS server, or between 1891 the RADIUS server and the backend security server. RADIUS does not 1892 support encryption, and as described in [1], only Access-Reply and 1893 Access-Challenge packets are integrity protected. Moreover, the 1894 integrity protection mechanism described in [1] is weaker than that 1895 likely to be used by some EAP methods, making it possible to subvert 1896 those methods by attacking EAP/RADIUS. 1898 In order to provide for authentication of all packets in the EAP 1899 exchange, all EAP/RADIUS packets MUST be authenticated using the 1900 Message-Authenticator attribute, as described previously. 1902 7.2.3. Man in the middle attacks 1904 Since RADIUS security is based on shared secrets, end-to-end security 1905 is not provided in the case where authentication or accounting 1906 packets are forwarded along a proxy chain. As a result, attackers 1907 gaining control of a RADIUS proxy will be able to modify EAP packets 1908 in transit. 1910 7.2.4. Multiple databases 1912 In many cases a backend security server will be deployed along with a 1913 RADIUS server in order to provide EAP services. Unless the backend 1914 security server also functions as a RADIUS server, two separate user 1915 databases will exist, each containing information about the security 1916 requirements for the user. This represents a weakness, since security 1917 may be compromised by a successful attack on either of the servers, 1918 or their backend databases. With multiple user databases, adding a 1919 new user may require multiple operations, increasing the chances for 1920 error. The problems are further magnified in the case where user 1921 information is also being kept in an LDAP server. In this case, three 1922 stores of user information may exist. 1924 In order to address these threats, consolidation of databases is 1925 recommended. This can be achieved by having both the RADIUS server 1926 and backend security server store information in the same backend 1927 database; by having the backend security server provide a full RADIUS 1928 implementation; or by consolidating both the backend security server 1929 and the RADIUS server onto the same machine. 1931 7.2.5. Negotiation attacks 1933 In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or 1934 RADIUS server causes the authenticating peer to choose a less secure 1935 authentication method so as to make it easier to obtain the user's 1936 password. For example, a session that would normally be authenticated 1937 with EAP would instead authenticated via CHAP or PAP; alternatively, 1938 a connection that would normally be authenticated via one EAP type 1939 occurs via a less secure EAP type, such as MD5. The threat posed by 1940 rogue devices, once thought to be remote, has gained currency given 1941 compromises of telephone company switching systems, such as those 1942 described in [11]. 1944 Protection against negotiation attacks requires the elimination of 1945 downward negotiations. This can be achieved via implementation of 1946 per-connection policy on the part of the authenticating peer, and 1947 per-user policy on the part of the RADIUS server. 1949 For the authenticating peer, authentication policy should be set on a 1950 per-connection basis. Per-connection policy allows an authenticating 1951 peer to negotiate EAP when calling one service, while negotiating 1952 CHAP for another service, even if both services are accessible via 1953 the same phone number. 1955 With per-connection policy, an authenticating peer will only attempt 1956 to negotiate EAP for a session in which EAP support is expected. As a 1957 result, there is a presumption that an authenticating peer selecting 1958 EAP requires that level of security. If it cannot be provided, it is 1959 likely that there is some kind of misconfiguration, or even that the 1960 authenticating peer is contacting the wrong server. Should the NAS 1961 not be able to negotiate EAP, or should the EAP-Request sent by the 1962 NAS be of a different EAP type than what is expected, the 1963 authenticating peer MUST disconnect. An authenticating peer expecting 1964 EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. 1966 For a NAS, it may not be possible to determine whether a user is 1967 required to authenticate with EAP until the user's identity is known. 1968 For example, for shared-uses NASes it is possible for one reseller to 1969 implement EAP while another does not. In such cases, if any users of 1970 the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for 1971 every call. This avoids forcing an EAP-capable client to do more than 1972 one authentication, which weakens security. 1974 If CHAP is negotiated, the NAS will pass the User-Name and CHAP- 1975 Password attributes to the RADIUS Server in an Access-Request packet. 1976 If the user is not required to use EAP, then the RADIUS Server will 1977 respond with an Access-Accept or Access-Reject packet as appropriate. 1978 However, if CHAP has been negotiated but EAP is required, the RADIUS 1979 server MUST respond with an Access-Reject, rather than an Access- 1980 Challenge/EAP-Message/EAP-Request packet. The authenticating peer 1981 MUST refuse to renegotiate authentication, even if the renegotiation 1982 is from CHAP to EAP. 1984 If EAP is negotiated but is not supported by the RADIUS proxy or 1985 server, then the server or proxy MUST respond with an Access-Reject. 1986 In these cases, the NAS MUST send an LCP-Terminate and disconnect the 1987 user. This is the correct behavior since the authenticating peer is 1988 expecting EAP to be negotiated, and that expectation cannot be 1989 fulfilled. An EAP-capable authenticating peer MUST refuse to 1990 renegotiate the authentication protocol if EAP had initially been 1991 negotiated. Note that problems with a non-EAP capable RADIUS proxy 1992 could prove difficult to diagnose, since a user dialing in from one 1993 location (with an EAP-capable proxy) might be able to successfully 1994 authenticate via EAP, while the same user dialing into another 1995 location (and encountering an EAP-incapable proxy) might be 1996 consistently disconnected. 1998 8. References 2000 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 2001 Authentication Dial In User Service (RADIUS)", RFC xxxx, 2002 February 2000. 2004 [2] Rigney, C., "RADIUS Accounting", RFC yyyy, February 2000. 2006 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 2007 Protocol (EAP)", RFC 2284, March 1998. 2009 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2010 Levels." BCP 14, RFC 2119, Harvard University, March, 1997. 2012 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 2013 1700, USC/Information Sciences Institute, October 1994. 2015 [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 2016 and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", 2017 draft-ietf-radius-tunnel-auth-09.txt, August 1999. 2019 [7] Zorn, G., Mitton, D., and B. Aboba, "RADIUS Accounting 2020 Modifications for Tunnel Protocol Support" draft-ietf-radius- 2021 tunnel-acct-05.txt, October 1999. 2023 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2024 2279, January 1998. 2026 [9] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2027 for Message Authentication", RFC 2104, February 1997. 2029 [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 2030 Considerations Section in RFCs", BCP 26, RFC 2434, October 2031 1998. 2033 [11] Slatalla, M., and Quittner, J., "Masters of Deception." 2034 HarperCollins, New York, 1995. 2036 9. Acknowledgements 2038 RADIUS and RADIUS Accounting were originally developed by Livingston 2039 Enterprises (now part of Lucent Technologies) for their PortMaster 2040 series of Network Access Servers. 2042 The section on ARAP is adopted with permission from "Using RADIUS to 2043 Authenticate Apple Remote Access Connections" by Ward Willats of Cyno 2044 Technologies (ward@cyno.com). 2046 The section on Acct-Interim-Interval is adopted with permission from 2047 an earlier Internet-Draft by Pat Calhoun of Sun Microsystems, Mark 2048 Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. 2050 The section on EAP is adopted with permission from an earlier 2051 Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of 2052 Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave 2053 Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of 2054 Microsoft for useful discussions of this problem space. 2056 10. Chair's Address 2058 The RADIUS working group can be contacted via the current chair: 2060 Carl Rigney 2061 Livingston Enterprises 2062 4464 Willow Road 2063 Pleasanton, California 94588 2064 Phone: +1 925 737 2100 2065 E-Mail: cdr@livingston.com 2067 11. Author's Address 2069 Questions about this memo can also be directed to: 2071 Carl Rigney 2072 Livingston Enterprises 2073 4464 Willow Road 2074 Pleasanton, California 94588 2076 E-Mail: cdr@livingston.com 2078 Questions on ARAP and RADIUS may be directed to: 2080 Ward Willats 2081 Cyno Technologies 2082 1082 Glen Echo Ave 2083 San Jose, CA 95125 2084 Phone: +1 408 297 7766 2085 E-Mail: ward@cyno.com 2087 Questions on EAP and RADIUS may be directed to any of the following: 2089 Pat R. Calhoun 2090 Network and Security Research Center 2091 Sun Microsystems, Inc. 2092 15 Network Circle 2093 Menlo Park, CA 94025 2094 Phone: +1 650 786 7733 2095 E-Mail: pcalhoun@eng.sun.com 2097 Allan C. Rubens 2098 Merit Network, Inc. 2099 4251 Plymouth Rd. 2100 Ann Arbor, MI 48105-2785 2101 Phone: +1 313 647 0417 2102 E-Mail: acr@merit.edu 2104 Bernard Aboba 2105 Microsoft Corporation 2106 One Microsoft Way 2107 Redmond, WA 98052 2108 Phone: +1 425 936 6605 2109 E-Mail: bernarda@microsoft.com 2111 12. Full Copyright Statement 2113 Copyright (C) The Internet Society (2000). All Rights Reserved. 2115 This document and translations of it may be copied and furnished to 2116 others, and derivative works that comment on or otherwise explain it 2117 or assist in its implmentation may be prepared, copied, published and 2118 distributed, in whole or in part, without restriction of any kind, 2119 provided that the above copyright notice and this paragraph are 2120 included on all such copies and derivative works. However, this 2121 document itself may not be modified in any way, such as by removing 2122 the copyright notice or references to the Internet Society or other 2123 Internet organizations, except as needed for the purpose of 2124 developing Internet standards in which case the procedures for 2125 copyrights defined in the Internet Standards process must be 2126 followed, or as required to translate it into languages other than 2127 English. 2129 The limited permissions granted above are perpetual and will not be 2130 revoked by the Internet Society or its successors or assigns. 2132 This document and the information contained herein is provided on an 2133 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2134 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2135 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2136 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2137 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."