diff options
| author | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
|---|---|---|
| committer | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
| commit | b6a1268714671904e96a49b88680dc3ff07aaa1c (patch) | |
| tree | 60424372b94312710b9f583b1bcc641de4020316 /rfc/rfc2869.txt | |
| parent | 5cf93f33f2350ed3b92f73ead1d2829a6883810a (diff) | |
| download | accel-ppp-b6a1268714671904e96a49b88680dc3ff07aaa1c.tar.gz accel-ppp-b6a1268714671904e96a49b88680dc3ff07aaa1c.zip | |
project cleanup and prepare to release
Diffstat (limited to 'rfc/rfc2869.txt')
| -rw-r--r-- | rfc/rfc2869.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/rfc/rfc2869.txt b/rfc/rfc2869.txt new file mode 100644 index 00000000..74ed7f6a --- /dev/null +++ b/rfc/rfc2869.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2869 Livingston +Category: Informational W. Willats + Cyno Technologies + P. Calhoun + Sun Microsystems + June 2000 + + + RADIUS Extensions + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document describes additional attributes for carrying + authentication, authorization and accounting information between a + Network Access Server (NAS) and a shared Accounting Server using the + Remote Authentication Dial In User Service (RADIUS) protocol + described in RFC 2865 [1] and RFC 2866 [2]. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 3 + 1.2 Terminology ..................................... 3 + 2. Operation ............................................. 4 + 2.1 RADIUS support for Interim Accounting Updates.... 4 + 2.2 RADIUS support for Apple Remote Access + Protocol ........................................ 5 + 2.3 RADIUS Support for Extensible Authentication + Protocol (EAP) .................................. 11 + 2.3.1 Protocol Overview ............................... 11 + 2.3.2 Retransmission .................................. 13 + 2.3.3 Fragmentation ................................... 14 + 2.3.4 Examples ........................................ 14 + 2.3.5 Alternative uses ................................ 19 + 3. Packet Format ......................................... 19 + 4. Packet Types .......................................... 19 + 5. Attributes ............................................ 20 + + + +Rigney, et al. Informational [Page 1] + +RFC 2869 RADIUS Extensions June 2000 + + + 5.1 Acct-Input-Gigawords ............................ 22 + 5.2 Acct-Output-Gigawords ........................... 23 + 5.3 Event-Timestamp ................................. 23 + 5.4 ARAP-Password ................................... 24 + 5.5 ARAP-Features ................................... 25 + 5.6 ARAP-Zone-Access ................................ 26 + 5.7 ARAP-Security ................................... 27 + 5.8 ARAP-Security-Data .............................. 28 + 5.9 Password-Retry .................................. 28 + 5.10 Prompt .......................................... 29 + 5.11 Connect-Info .................................... 30 + 5.12 Configuration-Token ............................. 31 + 5.13 EAP-Message ..................................... 32 + 5.14 Message-Authenticator ........................... 33 + 5.15 ARAP-Challenge-Response ......................... 35 + 5.16 Acct-Interim-Interval ........................... 36 + 5.17 NAS-Port-Id ..................................... 37 + 5.18 Framed-Pool ..................................... 37 + 5.19 Table of Attributes ............................. 38 + 6. IANA Considerations ................................... 39 + 7. Security Considerations ............................... 39 + 7.1 Message-Authenticator Security .................. 39 + 7.2 EAP Security .................................... 39 + 7.2.1 Separation of EAP server and PPP authenticator .. 40 + 7.2.2 Connection hijacking ............................ 41 + 7.2.3 Man in the middle attacks ....................... 41 + 7.2.4 Multiple databases .............................. 41 + 7.2.5 Negotiation attacks ............................. 42 + 8. References ............................................ 43 + 9. Acknowledgements ...................................... 44 + 10. Chair's Address ....................................... 44 + 11. Authors' Addresses .................................... 45 + 12. Full Copyright Statement .............................. 47 + +1. Introduction + + RFC 2865 [1] describes the RADIUS Protocol as it is implemented and + deployed today, and RFC 2866 [2] describes how Accounting can be + performed with RADIUS. + + + + + + + + + + + + +Rigney, et al. Informational [Page 2] + +RFC 2869 RADIUS Extensions June 2000 + + + This memo suggests several additional Attributes that can be added to + RADIUS to perform various useful functions. These Attributes do not + have extensive field experience yet and should therefore be + considered experimental. + + The Extensible Authentication Protocol (EAP) [3] is a PPP extension + that provides support for additional authentication methods within + PPP. This memo describes how the EAP-Message and Message- + Authenticator attributes may be used for providing EAP support within + RADIUS. + + All attributes are comprised of variable length Type-Length-Value 3- + tuples. New attribute values can be added without disturbing + existing implementations of the protocol. + +1.1. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + An implementation is not compliant if it fails to satisfy one or more + of the must or must not requirements for the protocols it implements. + An implementation that satisfies all the must, must not, should and + should not requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the must and must + not requirements but not all the should or should not requirements + for its protocols is said to be "conditionally compliant." + + A NAS that does not implement a given service MUST NOT implement the + RADIUS attributes for that service. For example, a NAS that is + unable to offer ARAP service MUST NOT implement the RADIUS attributes + for ARAP. A NAS MUST treat a RADIUS access-request requesting an + unavailable service as an access-reject instead. + +1.2. Terminology + + This document uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + + + + + +Rigney, et al. Informational [Page 3] + +RFC 2869 RADIUS Extensions June 2000 + + + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that, with each session + generating a separate start and stop accounting record. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + Operation is identical to that defined in RFC 2865 [1] and RFC 2866 + [2]. + +2.1. RADIUS support for Interim Accounting Updates + + When a user is authenticated, a RADIUS server issues an Access-Accept + in response to a successful Access-Request. If the server wishes to + receive interim accounting messages for the given user it must + include the Acct-Interim-Interval RADIUS attribute in the message, + which indicates the interval in seconds between interim messages. + + It is also possible to statically configure an interim value on the + NAS itself. Note that a locally configured value on the NAS MUST + override the value found in an Access-Accept. + + This scheme does not break backward interoperability since a RADIUS + server not supporting this extension will simply not add the new + Attribute. NASes not supporting this extension will ignore the + Attribute. + + Note that all information in an interim message is cumulative (i.e. + number of packets sent is the total since the beginning of the + session, not since the last interim message). + + It is envisioned that an Interim Accounting record (with Acct- + Status-Type = Interim-Update (3)) would contain all of the attributes + normally found in an Accounting Stop message with the exception of + the Acct-Term-Cause attribute. + + Since all the information is cumulative, a NAS MUST ensure that only + a single generation of an interim Accounting message for a given + session is present in the retransmission queue at any given time. + + + + + + +Rigney, et al. Informational [Page 4] + +RFC 2869 RADIUS Extensions June 2000 + + + A NAS MAY use a fudge factor to add a random delay between Interim + Accounting messages for separate sessions. This will ensure that a + cycle where all messages are sent at once is prevented, such as might + otherwise occur if a primary link was recently restored and many + dial-up users were directed to the same NAS at once. + + The Network and NAS CPU load of using Interim Updates should be + carefully considered, and appropriate values of Acct-Interim-Interval + chosen. + +2.2. RADIUS support for Apple Remote Access Protocol + + The RADIUS (Remote Authentication Dial-In User Service) protocol + provides a method that allows multiple dial-in Network Access Server + (NAS) devices to share a common authentication database. + + The Apple Remote Access Protocol (ARAP) provides a method for sending + AppleTalk network traffic over point-to-point links, typically, but + not exclusively, asynchronous and ISDN switched-circuit connections. + Though Apple is moving toward ATCP on PPP for future remote access + services, ARAP is still a common way for the installed base of + Macintosh users to make remote network connections, and is likely to + remain so for some time. + + ARAP is supported by several NAS vendors who also support PPP, IPX + and other protocols in the same NAS. ARAP connections in these + multi-protocol devices are often not authenticated with RADIUS, or if + they are, each vendor creates an individual solution to the problem. + + This section describes the use of additional RADIUS attributes to + support ARAP. RADIUS client and server implementations that implement + this specification should be able to authenticate ARAP connections in + an interoperable manner. + + This section assumes prior knowledge of RADIUS, and will go into some + detail on the operation of ARAP before entering a detailed discussion + of the proposed ARAP RADIUS attributes. + + There are two features of ARAP this document does not address: + + 1. User initiated password changing. This is not part of RADIUS, + but can be implemented through a software process other than + RADIUS. + + 2. Out-of-Band messages. At any time, the NAS can send messages to + an ARA client which appear in a dialog box on the dial-in + user's screen. These are not part of authentication and do not + belong here. However, we note that a Reply-Message attribute in + + + +Rigney, et al. Informational [Page 5] + +RFC 2869 RADIUS Extensions June 2000 + + + an Access-Accept may be sent down to the user as a sign-on + message of the day string using the out-of-band channel. + + We have tried to respect the spirit of the existing RADIUS protocol + as much as possible, making design decisions compatible with prior + art. Further, we have tried to strike a balance between flooding the + RADIUS world with new attributes, and hiding all of ARAP operation + within a single multiplexed ARAP attribute string or within Extended + Authentication Protocol (EAP) [3] machinery. + + However, we feel ARAP is enough of a departure from PPP to warrant a + small set of similarly named attributes of its own. + + We have assumed that an ARAP-aware RADIUS server will be able to do + DES encryption and generate security module challenges. This is in + keeping with the general RADIUS goal of smart server / simple NAS. + + ARAP authenticates a connection in two phases. The first is a "Two- + Way DES" random number exchange, using the user's password as a key. + We say "Two-Way" because the ARAP NAS challenges the dial-in client + to authenticate itself, and the dial-in client challenges the ARAP + NAS to authenticate itself. + + Specifically, ARAP does the following: + + 1. The NAS sends two 32-bit random numbers to the dial-in client + in an ARAP msg_auth_challenge packet. + + 2. The dial-in client uses the user's password to DES encrypt the + two random numbers sent to it by the NAS. The dial-in client + then sends this result, the user's name and two 32-bit random + numbers of its own back to the NAS in an ARAP msg_auth_request + packet. + + 3. The NAS verifies the encrypted random numbers sent by the + dial-in client are what it expected. If so, it encrypts the + dial-in client's challenge using the password and sends it back + to the dial-in client in an ARAP msg_auth_response packet. + + Note that if the dial-in client's response was wrong, meaning the + user has the wrong password, the server can initiate a retry sequence + up to the maximum amount of retries allowed by the NAS. In this case, + when the dial-in client receives the ARAP msg_auth_response packet it + will acknowledge it with an ARAP msg_auth_again packet. + + After this first "DES Phase" the ARAP NAS MAY initiate a secondary + authentication phase using what Apple calls "Add-In Security + Modules." Security Modules are small pieces of code which run on + + + +Rigney, et al. Informational [Page 6] + +RFC 2869 RADIUS Extensions June 2000 + + + both the client and server and are allowed to read and write + arbitrary data across the communications link to perform additional + authentication functions. Various security token vendors use this + mechanism to authenticate ARA callers. + + Although ARAP allows security modules to read and write anything they + like, all existing security modules use simple challenge and response + cycles, with perhaps some overall control information. This document + assumes all existing security modules can be supported with one or + more challenge/response cycles. + + To complicate RADIUS and ARAP integration, ARAP sends down some + profile information after the DES Phase and before the Security + Module phase. This means that besides the responses to challenges, + this profile information must also be present, at somewhat unusual + times. Fortunately the information is only a few pieces of numeric + data related to passwords, which this document packs into a single + new attribute. + + Presenting an Access-Request to RADIUS on behalf of an ARAP + connection is straightforward. The ARAP NAS generates the random + number challenge, and then receives the dial-in client's response, + the dial-in client's challenge, and the user's name. Assuming the + user is not a guest, the following information is forwarded in an + Access-Request packet: User-Name (up to 31 characters long), + Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional + attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, + NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. + + The Request Authenticator is a NAS-generated 16 octet random number. + The low-order 8 octets of this number are sent to the dial-in user as + the two 4 octet random numbers required in the ARAP + msg_auth_challenge packet. Octets 0-3 are the first random number and + Octets 4-7 are the second random number. + + The ARAP-Password in the Access-Request contains a 16 octet random + number field, and is used to carry the dial-in user's response to the + NAS challenge and the client's own challenge to the NAS. The high- + order octets contain the dial-in user's challenge to the NAS (2 32- + bit numbers, 8 octets) and the low-order octets contain the dial-in + user's response to the NAS challenge (2 32-bit numbers, 8 octets). + + Only one of User-Password, CHAP-Password, or ARAP-Password needs to + be present in an Access-Request, or one or more EAP-Messages. + + If the RADIUS server does not support ARAP it SHOULD return an + Access-Reject to the NAS. + + + + +Rigney, et al. Informational [Page 7] + +RFC 2869 RADIUS Extensions June 2000 + + + If the RADIUS server does support ARAP, it should verify the user's + response using the Challenge (from the lower order 8 octets of the + Request Authenticator) and the user's response (from the low order 8 + octets of the ARAP-Password). + + If that authentication fails, the RADIUS server should return an + Access-Reject packet to the NAS, with optional Password-Retry and + Reply-Messages attributes. The presence of Password-Retry indicates + the ARAP NAS MAY choose to initiate another challenge-response cycle, + up to a total number of times equal to the integer value of the + Password-Retry attribute. + + If the user is authenticated, the RADIUS server should return an + Access-Accept packet (Code 2) to the NAS, with ID and Response + Authenticator as usual, and attributes as follows: + + Service-Type of Framed-Protocol. + + Framed-Protocol of ARAP (3). + + Session-Timeout with the maximum connect time for the user in + seconds. If the user is to be given unlimited time, + Session-Timeout should not be included in the Access-Accept + packet, and ARAP will treat that as an unlimited timeout (-1). + + ARAP-Challenge-Response, containing 8 octets with the response to + the dial-in client's challenge. The RADIUS server calculates this + value by taking the dial-in client's challenge from the high order + 8 octets of the ARAP-Password attribute and performing DES + encryption on this value with the authenticating user's password + as the key. If the user's password is less than 8 octets in + length, the password is padded at the end with NULL octets to a + length of 8 before using it as a key. If the user's password is + greater than 8 octets in length, an Access-Reject MUST be sent + instead. + + ARAP-Features, containing information that the NAS should send to + the user in an ARAP "feature flags" packet. + + Octet 0: If zero, user cannot change their password. If non- + zero user can. (RADIUS does not handle the password changing, + just the attribute which indicates whether ARAP indicates they + can.) + + Octet 1: Minimum acceptable password length (0-8). + + + + + + +Rigney, et al. Informational [Page 8] + +RFC 2869 RADIUS Extensions June 2000 + + + Octet 2-5: Password creation date in Macintosh format, defined + as 32 bits unsigned representing seconds since Midnight GMT + January 1, 1904. + + Octet 6-9 Password Expiration Delta from create date in + seconds. + + Octet 10-13: Current RADIUS time in Macintosh format + + Optionally, a single Reply-Message with a text string up to 253 + characters long which MAY be sent down to the user to be displayed + in a sign-on/message of the day dialog. + + Framed-AppleTalk-Network may be included. + + Framed-AppleTalk-Zone, up to 32 characters in length, may be + included. + + ARAP defines the notion of a list of zones for a user. Along with + a list of zone names, a Zone Access Flag is defined (and used by + the NAS) which says how to use the list of zone names. That is, + the dial-in user may only be allowed to see the Default Zone, or + only the zones in the zone list (inclusive) or any zone except + those in the zone list (exclusive). + + The ARAP NAS handles this by having a named filter which contains + (at least) zone names. This solves the problem where a single + RADIUS server is managing disparate NAS clients who may not be + able to "see" all of the zone names in a user zone list. Zone + names only have meaning "at the NAS." The disadvantage of this + approach is that zone filters must be set up on the NAS somehow, + then referenced by the RADIUS Filter-Id. + + ARAP-Zone-Access contains an integer which specifies how the "zone + list" for this user should be used. If this attribute is present + and the value is 2 or 4 then a Filter-Id must also be present to + name a zone list filter to apply the access flag to. + + The inclusion of a Callback-Number or Callback-Id attribute in the + Access-Accept MAY cause the ARAP NAS to disconnect after sending + the Feature Flags to begin callback processing in an ARAP specific + way. + + + + + + + + + +Rigney, et al. Informational [Page 9] + +RFC 2869 RADIUS Extensions June 2000 + + + Other attributes may be present in the Access-Accept packet as well. + + An ARAP NAS will need other information to finish bringing up the + connection to the dial in client, but this information can be + provided by the ARAP NAS without any help from RADIUS, either through + configuration by SNMP, a NAS administration program, or deduced by + the AppleTalk stack in the NAS. Specifically: + + 1. AppearAsNet and AppearAsNode values, sent to the client to tell + it what network and node numbers it should use in its datagram + packets. AppearAsNet can be taken from the Framed-AppleTalk- + Network attribute or from the configuration or AppleTalk stack + onthe NAS. + + 2. The "default" zone - that is the name of the AppleTalk zone in + which the dial-in client will appear. (Or can be specified + with the Framed-AppleTalk-Zone attribute.) + + 3. Other very NAS specific stuff such as the name of the NAS, and + smartbuffering information. (Smartbuffering is an ARAP + mechanism for replacing common AppleTalk datagrams with small + tokens, to improve slow link performance in a few common + traffic situations.) + + 4. "Zone List" information for this user. The ARAP specification + defines a "zone count" field which is actually unused. + + RADIUS supports ARAP Security Modules in the following manner. + + After DES authentication has been completed, the RADIUS server may + instruct the ARAP NAS to run one or more security modules for the + dial-in user. Although the underlying protocol supports executing + multiple security modules in series, in practice all current + implementations only allow executing one. Through the use of + multiple Access-Challenge requests, multiple modules can be + supported, but this facility will probably never be used. + + We also assume that, even though ARAP allows a free-form dialog + between security modules on each end of the point-to-point link, in + actual practice all security modules can be reduced to a simple + challenge/response cycle. + + If the RADIUS server wishes to instruct the ARAP NAS to run a + security module, it should send an Access-Challenge packet to the NAS + with (optionally) the State attribute, plus the ARAP-Challenge- + Response, ARAP-Features, and two more attributes: + + + + + +Rigney, et al. Informational [Page 10] + +RFC 2869 RADIUS Extensions June 2000 + + + ARAP-Security: a four octet security module signature, containing a + Macintosh OSType. + + ARAP-Security-Data, a string to carry the actual security module + challenge and response. + + When the security module finishes executing, the security module + response is passed in an ARAP-Security-Data attribute from the NAS + to the RADIUS server in a second Access-Request, also including the + State from the Access-Challenge. The authenticator field contains no + special information in this case, and this can be discerned by the + presence of the State attribute. + +2.3. RADIUS Support for Extensible Authentication Protocol (EAP) + + The Extensible Authentication Protocol (EAP), described in [3], + provides a standard mechanism for support of additional + authentication methods within PPP. Through the use of EAP, support + for a number of authentication schemes may be added, including smart + cards, Kerberos, Public Key, One Time Passwords, and others. In + order to provide for support of EAP within RADIUS, two new + attributes, EAP-Message and Message-Authenticator, are introduced in + this document. This section describes how these new attributes may be + used for providing EAP support within RADIUS. + + In the proposed scheme, the RADIUS server is used to shuttle RADIUS- + encapsulated EAP Packets between the NAS and a backend security + server. While the conversation between the RADIUS server and the + backend security server will typically occur using a proprietary + protocol developed by the backend security server vendor, it is also + possible to use RADIUS-encapsulated EAP via the EAP-Message + attribute. This has the advantage of allowing the RADIUS server to + support EAP without the need for authentication-specific code, which + can instead reside on the backend security server. + +2.3.1. Protocol Overview + + The EAP conversation between the authenticating peer (dial-in user) + and the NAS begins with the negotiation of EAP within LCP. Once EAP + has been negotiated, the NAS MUST send an EAP-Request/Identity + message to the authenticating peer, unless identity is determined via + some other means such as Called-Station-Id or Calling-Station-Id. + The peer will then respond with an EAP-Response/Identity which the + the NAS will then forward to the RADIUS server in the EAP-Message + attribute of a RADIUS Access-Request packet. The RADIUS Server will + typically use the EAP-Response/Identity to determine which EAP type + is to be applied to the user. + + + + +Rigney, et al. Informational [Page 11] + +RFC 2869 RADIUS Extensions June 2000 + + + In order to permit non-EAP aware RADIUS proxies to forward the + Access-Request packet, if the NAS sends the EAP-Request/Identity, the + NAS MUST copy the contents of the EAP-Response/Identity into the + User-Name attribute and MUST include the EAP-Response/Identity in the + User-Name attribute in every subsequent Access-Request. NAS-Port or + NAS-Port-Id SHOULD be included in the attributes issued by the NAS in + the Access-Request packet, and either NAS-Identifier or NAS-IP- + Address MUST be included. In order to permit forwarding of the + Access-Reply by EAP-unaware proxies, if a User-Name attribute was + included in an Access-Request, the RADIUS Server MUST include the + User-Name attribute in subsequent Access-Accept packets. Without the + User-Name attribute, accounting and billing becomes very difficult to + manage. + + If identity is determined via another means such as Called-Station-Id + or Calling-Station-Id, the NAS MUST include these identifying + attributes in every Access-Request. + + While this approach will save a round-trip, it cannot be universally + employed. There are circumstances in which the user's identity may + not be needed (such as when authentication and accounting is handled + based on Called-Station-Id or Calling-Station-Id), and therefore an + EAP-Request/Identity packet may not necessarily be issued by the NAS + to the authenticating peer. In cases where an EAP-Request/Identity + packet will not be sent, the NAS will send to the RADIUS server a + RADIUS Access-Request packet containing an EAP-Message attribute + signifying EAP-Start. EAP-Start is indicated by sending an EAP- + Message attribute with a length of 2 (no data). However, it should be + noted that since no User-Name attribute is included in the Access- + Request, this approach is not compatible with RADIUS as specified in + [1], nor can it easily be applied in situations where proxies are + deployed, such as roaming or shared use networks. + + If the RADIUS server supports EAP, it MUST respond with an Access- + Challenge packet containing an EAP-Message attribute. If the RADIUS + server does not support EAP, it MUST respond with an Access-Reject. + The EAP-Message attribute includes an encapsulated EAP packet which + is then passed on to the authenticating peer. In the case where the + NAS does not initially send an EAP-Request/Identity message to the + peer, the Access-Challenge typically will contain an EAP-Message + attribute encapsulating an EAP-Request/Identity message, requesting + the dial-in user to identify themself. The NAS will then respond with + a RADIUS Access-Request packet containing an EAP-Message attribute + encapsulating an EAP-Response. The conversation continues until + either a RADIUS Access-Reject or Access-Accept packet is received. + + + + + + +Rigney, et al. Informational [Page 12] + +RFC 2869 RADIUS Extensions June 2000 + + + Reception of a RADIUS Access-Reject packet, with or without an EAP- + Message attribute encapsulating EAP-Failure, MUST result in the NAS + issuing an LCP Terminate Request to the authenticating peer. A + RADIUS Access-Accept packet with an EAP-Message attribute + encapsulating EAP-Success successfully ends the authentication phase. + The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain + all of the expected attributes which are currently returned in an + Access-Accept packet. + + The above scenario creates a situation in which the NAS never needs + to manipulate an EAP packet. An alternative may be used in + situations where an EAP-Request/Identity message will always be sent + by the NAS to the authenticating peer. + + For proxied RADIUS requests there are two methods of processing. If + the domain is determined based on the Called-Station-Id, the RADIUS + Server may proxy the initial RADIUS Access-Request/EAP-Start. If the + domain is determined based on the user's identity, the local RADIUS + Server MUST respond with a RADIUS Access-Challenge/EAP-Identity + packet. The response from the authenticating peer MUST be proxied to + the final authentication server. + + For proxied RADIUS requests, the NAS may receive an Access-Reject + packet in response to its Access-Request/EAP-Identity packet. This + would occur if the message was proxied to a RADIUS Server which does + not support the EAP-Message extension. On receiving an Access-Reject, + the NAS MUST send an LCP Terminate Request to the authenticating + peer, and disconnect. + +2.3.2. Retransmission + + As noted in [3], the EAP authenticator (NAS) is responsible for + retransmission of packets between the authenticating peer and the + NAS. Thus if an EAP packet is lost in transit between the + authenticating peer and the NAS (or vice versa), the NAS will + retransmit. As in RADIUS [1], the RADIUS client is responsible for + retransmission of packets between the RADIUS client and the RADIUS + server. + + Note that it may be necessary to adjust retransmission strategies and + authentication timeouts in certain cases. For example, when a token + card is used additional time may be required to allow the user to + find the card and enter the token. Since the NAS will typically not + have knowledge of the required parameters, these need to be provided + by the RADIUS server. This can be accomplished by inclusion of + Session-Timeout and Password-Retry attributes within the Access- + Challenge packet. + + + + +Rigney, et al. Informational [Page 13] + +RFC 2869 RADIUS Extensions June 2000 + + + If Session-Timeout is present in an Access-Challenge packet that also + contains an EAP-Message, the value of the Session-Timeout provides + the NAS with the maximum number of seconds the NAS should wait for an + EAP-Response before retransmitting the EAP-Message to the dial-in + user. + +2.3.3. Fragmentation + + Using the EAP-Message attribute, it is possible for the RADIUS server + to encapsulate an EAP packet that is larger than the MTU on the link + between the NAS and the peer. Since it is not possible for the RADIUS + server to use MTU discovery to ascertain the link MTU, the Framed-MTU + attribute may be included in an Access-Request packet containing an + EAP-Message attribute so as to provide the RADIUS server with this + information. + +2.3.4. Examples + + The example below shows the conversation between the authenticating + peer, NAS, and RADIUS server, for the case of a One Time Password + (OTP) authentication. OTP is used only for illustrative purposes; + other authentication protocols could also have been used, although + they might show somewhat different behavior. + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + <- PPP EAP-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + + + +Rigney, et al. Informational [Page 14] + +RFC 2869 RADIUS Extensions June 2000 + + + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Accept/ + EAP-Message/EAP-Success + (other attributes) + <- PPP EAP-Success +PPP Authentication +Phase complete, +NCP Phase starts + +In the case where the NAS first sends an EAP-Start packet to the +RADIUS server, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EA-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + + + + +Rigney, et al. Informational [Page 15] + +RFC 2869 RADIUS Extensions June 2000 + + + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Accept/ + EAP-Message/EAP-Success + (other attributes) + <- PPP EAP-Success +PPP Authentication +Phase complete, +NCP Phase starts + +In the case where the client fails EAP authentication, the +conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EAP-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + RADIUS + Access-Request/ + + + +Rigney, et al. Informational [Page 16] + +RFC 2869 RADIUS Extensions June 2000 + + + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Reject/ + EAP-Message/EAP-Failure + + <- PPP EAP-Failure + (client disconnected) + +In the case that the RADIUS server or proxy does not support +EAP-Message, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +In the case where the local RADIUS Server does support EAP-Message, +but the remote RADIUS Server does not, the conversation would appear +as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EAP-Request/ + Identity + + + + +Rigney, et al. Informational [Page 17] + +RFC 2869 RADIUS Extensions June 2000 + + +PPP EAP-Response/ +Identity +(MyID) -> + RADIUS + Access-Request/ + EAP-Message/EAP-Response/ + (MyID) -> + <- RADIUS + Access-Reject + (proxied from remote + RADIUS Server) + <- PPP LCP Terminate + (User Disconnected) + +In the case where the authenticating peer does not support EAP, but +where EAP is required for that user, the conversation would appear as +follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP NAK-EAP +auth -> + <- PPP LCP Request-CHAP + auth +PPP LCP ACK-CHAP +auth -> + <- PPP CHAP Challenge +PPP CHAP Response -> + RADIUS + Access-Request/ + User-Name, + CHAP-Password -> + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +In the case where the NAS does not support EAP, but where EAP is +required for that user, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-CHAP + auth + + + +Rigney, et al. Informational [Page 18] + +RFC 2869 RADIUS Extensions June 2000 + + +PP LCP ACK-CHAP +auth -> + <- PPP CHAP Challenge +PPP CHAP Response -> + RADIUS + Access-Request/ + User-Name, + CHAP-Password -> + + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +2.3.5. Alternative uses + + Currently the conversation between the backend security server and + the RADIUS server is proprietary because of lack of standardization. + In order to increase standardization and provide interoperability + between Radius vendors and backend security vendors, it is + recommended that RADIUS-encapsulated EAP be used for this + conversation. + + This has the advantage of allowing the RADIUS server to support EAP + without the need for authentication-specific code within the RADIUS + server. Authentication-specific code can then reside on a backend + security server instead. + + In the case where RADIUS-encapsulated EAP is used in a conversation + between a RADIUS server and a backend security server, the security + server will typically return an Access-Accept/EAP-Success message + without inclusion of the expected attributes currently returned in an + Access-Accept. This means that the RADIUS server MUST add these + attributes prior to sending an Access-Accept/EAP-Success message to + the NAS. + +3. Packet Format + + Packet Format is identical to that defined in RFC 2865 [1] and 2866 + [2]. + +4. Packet Types + + Packet types are identical to those defined in RFC 2865 [1] and 2866 + [2]. + + See "Table of Attributes" below to determine which types of packets + can contain which attributes defined here. + + + +Rigney, et al. Informational [Page 19] + +RFC 2869 RADIUS Extensions June 2000 + + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization + and accounting details for the request and response. + + Some attributes MAY be included more than once. The effect of this + is attribute specific, and is specified in each attribute + description. The order of attributes of the same type SHOULD be + preserved. The order of attributes of different types is not + required to be preserved. + + The end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is the same as in RFC 2865 [1] but + is included here for ease of reference. The fields are transmitted + from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [5]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + 1-39 (refer to RFC 2865 [1], "RADIUS") + 40-51 (refer to RFC 2866 [2], "RADIUS Accounting") + 52 Acct-Input-Gigawords + 53 Acct-Output-Gigawords + 54 Unused + 55 Event-Timestamp + 56-59 Unused + 60-63 (refer to RFC 2865 [1], "RADIUS") + 64-67 (refer to [6]) + 68 (refer to [7]) + 69 (refer to [6]) + 70 ARAP-Password + 71 ARAP-Features + 72 ARAP-Zone-Access + + + +Rigney, et al. Informational [Page 20] + +RFC 2869 RADIUS Extensions June 2000 + + + 73 ARAP-Security + 74 ARAP-Security-Data + 75 Password-Retry + 76 Prompt + 77 Connect-Info + 78 Configuration-Token + 79 EAP-Message + 80 Message-Authenticator + 81-83 (refer to [6]) + 84 ARAP-Challenge-Response + 85 Acct-Interim-Interval + 86 (refer to [7]) + 87 NAS-Port-Id + 88 Framed-Pool + 89 Unused + 90-91 (refer to [6]) + 92-191 Unused + + Length + + The Length field is one octet, and indicates the length of this + attribute including the Type, Length and Value fields. If an + attribute is received in a packet with an invalid Length, the + entire request should be silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the attribute. The format and length of the Value + field is determined by the Type and Length fields. + + Note that none of the types in RADIUS terminate with a NUL (hex + 00). In particular, types "text" and "string" in RADIUS do not + terminate with a NUL (hex 00). The Attribute has a length field + and does not use a terminator. Text contains UTF-8 encoded 10646 + [8] characters and String contains 8-bit binary data. Servers and + servers and clients MUST be able to deal with embedded nulls. + RADIUS implementers using C are cautioned not to use strcpy() when + handling strings. + + The format of the value field is one of five data types. Note + that type "text" is a subset of type "string." + + text 1-253 octets containing UTF-8 encoded 10646 [8] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + + + + +Rigney, et al. Informational [Page 21] + +RFC 2869 RADIUS Extensions June 2000 + + + string 1-253 octets containing binary data (values 0 through + 255 decimal, inclusive). Strings of length zero (0) MUST + NOT be sent; omit the entire attribute instead. + + address 32 bit unsigned value, most significant octet first. + + integer 32 bit unsigned value, most significant octet first. + + time 32 bit unsigned value, most significant octet first -- + seconds since 00:00:00 UTC, January 1, 1970. + +5.1. Acct-Input-Gigawords + + Description + + This attribute indicates how many times the Acct-Input-Octets + counter has wrapped around 2^32 over the course of this service + being provided, and can only be present in Accounting-Request + records where the Acct-Status-Type is set to Stop or Interim- + Update. + + A summary of the Acct-Input-Gigawords attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 52 for Acct-Input-Gigawords. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + +Rigney, et al. Informational [Page 22] + +RFC 2869 RADIUS Extensions June 2000 + + +5.2. Acct-Output-Gigawords + + Description + + This attribute indicates how many times the Acct-Output-Octets + counter has wrapped around 2^32 in the course of delivering this + service, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop or Interim-Update. + + A summary of the Acct-Output-Gigawords attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 53 for Acct-Output-Gigawords. + + Length + + 6 + + Value + + The Value field is four octets. + +5.3. Event-Timestamp + + Description + + This attribute is included in an Accounting-Request packet to + record the time that this event occurred on the NAS, in seconds + since January 1, 1970 00:00 UTC. + + A summary of the Event-Timestamp attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + +Rigney, et al. Informational [Page 23] + +RFC 2869 RADIUS Extensions June 2000 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 55 for Event-Timestamp + + Length + + 6 + + Value + + The Value field is four octets encoding an unsigned integer with + the number of seconds since January 1, 1970 00:00 UTC. + +5.4. ARAP-Password + + Description + + This attribute is only present in an Access-Request packet + containing a Framed-Protocol of ARAP. + + Only one of User-Password, CHAP-Password, or ARAP-Password needs + to be present in an Access-Request, or one or more EAP-Messages. + + A summary of the ARAP-Password attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value4 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Rigney, et al. Informational [Page 24] + +RFC 2869 RADIUS Extensions June 2000 + + + Type + + 70 for ARAP-Password. + + Length + + 18 + + Value + + This attribute contains a 16 octet string, used to carry the + dial-in user's response to the NAS challenge and the client's own + challenge to the NAS. The high-order octets (Value1 and Value2) + contain the dial-in user's challenge to the NAS (2 32-bit numbers, + 8 octets) and the low-order octets (Value3 and Value4) contain the + dial-in user's response to the NAS challenge (2 32-bit numbers, 8 + octets). + +5.5. ARAP-Features + + Description + + This attribute is sent in an Access-Accept packet with Framed- + Protocol of ARAP, and includes password information that the NAS + should sent to the user in an ARAP "feature flags" packet. + + A summary of the ARAP-Features attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value1 | Value2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 71 for ARAP-Features. + + Length + + 16 + + + +Rigney, et al. Informational [Page 25] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is a compound string containing information the + NAS should send to the user in the ARAP "feature flags" packet. + + Value1: If zero, user cannot change their password. If non-zero + user can. (RADIUS does not handle the password changing, just + the attribute which indicates whether ARAP indicates they can.) + + Value2: Minimum acceptable password length, from 0 to 8. + + Value3: Password creation date in Macintosh format, defined as + 32 unsigned bits representing seconds since Midnight GMT + January 1, 1904. + + Value4: Password Expiration Delta from create date in seconds. + + Value5: Current RADIUS time in Macintosh format. + +5.6. ARAP-Zone-Access + + Description + + This attribute is included in an Access-Accept packet with + Framed-Protocol of ARAP to indicate how the ARAP zone list for the + user should be used. + + A summary of the ARAP-Zone-Access attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 72 for ARAP-Zone-Access. + + Length + + 6 + + + + + +Rigney, et al. Informational [Page 26] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is four octets encoding an integer with one of the + following values: + + 1 Only allow access to default zone + 2 Use zone filter inclusively + 4 Use zone filter exclusively + + + The value 3 is skipped, not because these are bit flags, but + because 3 in some ARAP implementations means "all zones" which is + the same as not specifying a list at all under RADIUS. + + If this attribute is present and the value is 2 or 4 then a + Filter-Id must also be present to name a zone list filter to apply + the access flag to. + +5.7. ARAP-Security + + Description + + This attribute identifies the ARAP Security Module to be used in + an Access-Challenge packet. + + A summary of the ARAP-Security attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 73 for ARAP-Security. + + Length + + 6 + + + + + + + + +Rigney, et al. Informational [Page 27] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is four octets, containing an integer specifying + the security module signature, which is a Macintosh OSType. + (Macintosh OSTypes are 4 ascii characters cast as a 32-bit + integer) + +5.8. ARAP-Security-Data + + Description + + This attribute contains the actual security module challenge or + response, and can be found in Access-Challenge and Access-Request + packets. + + A summary of the ARAP-Security-Data attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 74 for ARAP-Security-Data. + + Length + + >=3 + + String + + The String field contains the security module challenge or + response associated with the ARAP Security Module specified in + ARAP-Security. + +5.9. Password-Retry + + Description + + This attribute MAY be included in an Access-Reject to indicate how + many authentication attempts a user may be allowed to attempt + before being disconnected. + + It is primarily intended for use with ARAP authentication. + + + + +Rigney, et al. Informational [Page 28] + +RFC 2869 RADIUS Extensions June 2000 + + + A summary of the Password-Retry attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 75 for Password-Retry. + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the number of password retry attempts to permit the user. + +5.10. Prompt + + Description + + This attribute is used only in Access-Challenge packets, and + indicates to the NAS whether it should echo the user's response as + it is entered, or not echo it. + + + A summary of the Prompt attribute format is shown below. The fields + are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 76 for Prompt. + + + + +Rigney, et al. Informational [Page 29] + +RFC 2869 RADIUS Extensions June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 No Echo + 1 Echo + +5.11. Connect-Info + + Description + + This attribute is sent from the NAS to indicate the nature of the + user's connection. + + The NAS MAY send this attribute in an Access-Request or + Accounting-Request to indicate the nature of the user's + connection. + + A summary of the Connect-Info attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 77 for Connect-Info. + + Length + + >= 3 + + Text + + The Text field consists of UTF-8 encoded 10646 [8] characters. + The connection speed SHOULD be included at the beginning of the + first Connect-Info attribute in the packet. If the transmit and + receive connection speeds differ, they may both be included in the + first attribute with the transmit speed first (the speed the NAS + modem transmits at), a slash (/), the receive speed, then + optionally other information. + + + +Rigney, et al. Informational [Page 30] + +RFC 2869 RADIUS Extensions June 2000 + + + For example, "28800 V42BIS/LAPM" or "52000/31200 V90" + + More than one Connect-Info attribute may be present in an + Accounting-Request packet to accommodate expected efforts by ITU + to have modems report more connection information in a standard + format that might exceed 252 octets. + +5.12. Configuration-Token + + Description + + This attribute is for use in large distributed authentication + networks based on proxy. It is sent from a RADIUS Proxy Server to + a RADIUS Proxy Client in an Access-Accept to indicate a type of + user profile to be used. It should not be sent to a NAS. + + A summary of the Configuration-Token attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 78 for Configuration-Token. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + + + + + + + +Rigney, et al. Informational [Page 31] + +RFC 2869 RADIUS Extensions June 2000 + + +5.13. EAP-Message + + Description + + This attribute encapsulates Extended Access Protocol [3] packets + so as to allow the NAS to authenticate dial-in users via EAP + without having to understand the EAP protocol. + + The NAS places any EAP messages received from the user into one or + more EAP attributes and forwards them to the RADIUS Server as part + of the Access-Request, which can return EAP messages in Access- + Challenge, Access-Accept and Access-Reject packets. + + A RADIUS Server receiving EAP messages that it does not understand + SHOULD return an Access-Reject. + + The NAS places EAP messages received from the authenticating peer + into one or more EAP-Message attributes and forwards them to the + RADIUS Server within an Access-Request message. If multiple EAP- + Messages are contained within an Access-Request or Access- + Challenge packet, they MUST be in order and they MUST be + consecutive attributes in the Access-Request or Access-Challenge + packet. Access-Accept and Access-Reject packets SHOULD only have + ONE EAP-Message attribute in them, containing EAP-Success or EAP- + Failure. + + It is expected that EAP will be used to implement a variety of + authentication methods, including methods involving strong + cryptography. In order to prevent attackers from subverting EAP by + attacking RADIUS/EAP, (for example, by modifying the EAP-Success + or EAP-Failure packets) it is necessary that RADIUS/EAP provide + integrity protection at least as strong as those used in the EAP + methods themselves. + + Therefore the Message-Authenticator attribute MUST be used to + protect all Access-Request, Access-Challenge, Access-Accept, and + Access-Reject packets containing an EAP-Message attribute. + + Access-Request packets including an EAP-Message attribute without + a Message-Authenticator attribute SHOULD be silently discarded by + the RADIUS server. A RADIUS Server supporting EAP-Message MUST + calculate the correct value of the Message-Authenticator and + silently discard the packet if it does not match the value sent. + A RADIUS Server not supporting EAP-Message MUST return an Access- + Reject if it receives an Access-Request containing an EAP-Message + attribute. A RADIUS Server receiving an EAP-Message attribute that + it does not understand MUST return an Access-Reject. + + + + +Rigney, et al. Informational [Page 32] + +RFC 2869 RADIUS Extensions June 2000 + + + Access-Challenge, Access-Accept, or Access-Reject packets + including an EAP-Message attribute without a Message-Authenticator + attribute SHOULD be silently discarded by the NAS. A NAS + supporting EAP-Message MUST calculate the correct value of the + Message-Authenticator and silently discard the packet if it does + not match the value sent. + + A summary of the EAP-Message attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 79 for EAP-Message. + + Length + + >= 3 + + String + + The String field contains EAP packets, as defined in [3]. If + multiple EAP-Message attributes are present in a packet their + values should be concatenated; this allows EAP packets longer than + 253 octets to be passed by RADIUS. + +5.14. Message-Authenticator + + Description + + This attribute MAY be used to sign Access-Requests to prevent + spoofing Access-Requests using CHAP, ARAP or EAP authentication + methods. It MAY be used in any Access-Request. It MUST be used + in any Access-Request, Access-Accept, Access-Reject or Access- + Challenge that includes an EAP-Message attribute. + + A RADIUS Server receiving an Access-Request with a Message- + Authenticator Attribute present MUST calculate the correct value + of the Message-Authenticator and silently discard the packet if it + does not match the value sent. + + + + + + +Rigney, et al. Informational [Page 33] + +RFC 2869 RADIUS Extensions June 2000 + + + A RADIUS Client receiving an Access-Accept, Access-Reject or + Access-Challenge with a Message-Authenticator Attribute present + MUST calculate the correct value of the Message-Authenticator and + silently discard the packet if it does not match the value sent. + + Earlier drafts of this memo used "Signature" as the name of this + attribute, but Message-Authenticator is more precise. Its + operation has not changed, just the name. + + A summary of the Message-Authenticator attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 80 for Message-Authenticator + + Length + + 18 + + String + + When present in an Access-Request packet, Message-Authenticator is + an HMAC-MD5 [9] checksum of the entire Access-Request packet, + including Type, ID, Length and authenticator, using the shared + secret as the key, as follows. + + Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, + Request Authenticator, Attributes) + + When the checksum is calculated the signature string should be + considered to be sixteen octets of zero. + + For Access-Challenge, Access-Accept, and Access-Reject packets, + the Message-Authenticator is calculated as follows, using the + Request-Authenticator from the Access-Request this packet is in + reply to: + + Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, + Request Authenticator, Attributes) + + + + + +Rigney, et al. Informational [Page 34] + +RFC 2869 RADIUS Extensions June 2000 + + + When the checksum is calculated the signature string should be + considered to be sixteen octets of zero. The shared secret is + used as the key for the HMAC-MD5 hash. The is calculated and + inserted in the packet before the Response Authenticator is + calculated. + + This attribute is not needed if the User-Password attribute is + present, but is useful for preventing attacks on other types of + authentication. This attribute is intended to thwart attempts by + an attacker to setup a "rogue" NAS, and perform online dictionary + attacks against the RADIUS server. It does not afford protection + against "offline" attacks where the attacker intercepts packets + containing (for example) CHAP challenge and response, and performs + a dictionary attack against those packets offline. + + IP Security will eventually make this attribute unnecessary, so it + should be considered an interim measure. + +5.15. ARAP-Challenge-Response + + Description + + This attribute is sent in an Access-Accept packet with Framed- + Protocol of ARAP, and contains the response to the dial-in + client's challenge. + + A summary of the ARAP-Challenge-Response attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 84 for ARAP-Challenge-Response. + + Length + + 10 + + + + + +Rigney, et al. Informational [Page 35] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field contains an 8 octet response to the dial-in + client's challenge. The RADIUS server calculates this value by + taking the dial-in client's challenge from the high order 8 octets + of the ARAP-Password attribute and performing DES encryption on + this value with the authenticating user's password as the key. If + the user's password is less than 8 octets in length, the password + is padded at the end with NULL octets to a length of 8 before + using it as a key. + +5.16. Acct-Interim-Interval + + Description + + This attribute indicates the number of seconds between each + interim update in seconds for this specific session. This value + can only appear in the Access-Accept message. + + A summary of the Acct-Interim-Interval attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 85 for Acct-Interim-Interval. + + Length + + 6 + + Value + + The Value field contains the number of seconds between each + interim update to be sent from the NAS for this session. The value + MUST NOT be smaller than 60. The value SHOULD NOT be smaller than + 600, and careful consideration should be given to its impact on + network traffic. + + + + + + +Rigney, et al. Informational [Page 36] + +RFC 2869 RADIUS Extensions June 2000 + + +5.17. NAS-Port-Id + + Description + + This Attribute contains a text string which identifies the port of + the NAS which is authenticating the user. It is only used in + Access-Request and Accounting-Request packets. Note that this is + using "port" in its sense of a physical connection on the NAS, not + in the sense of a TCP or UDP port number. + + Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- + Request packet, if the NAS differentiates among its ports. NAS- + Port-Id is intended for use by NASes which cannot conveniently + number their ports. + + A summary of the NAS-Port-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 87 for NAS-Port-Id. + + Length + + >= 3 + + Text + + The Text field contains the name of the port using UTF-8 encoded + 10646 [8] characters. + +5.18. Framed-Pool + + Description + + This Attribute contains the name of an assigned address pool that + SHOULD be used to assign an address for the user. If a NAS does + not support multiple address pools, the NAS should ignore this + Attribute. Address pools are usually used for IP addresses, but + can be used for other protocols if the NAS supports pools for + those protocols. + + + +Rigney, et al. Informational [Page 37] + +RFC 2869 RADIUS Extensions June 2000 + + + A summary of the Framed-Pool Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 88 for Framed-Pool + + Length + + >= 3 + + String + + The string field contains the name of an assigned address pool + configured on the NAS. + +5.19. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kind of packets. Acct-Input-Gigawords, Acct-Output- + Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in + an Accounting-Request packet. Connect-Info may have 0+ instances in + an Accounting-Request packet. The other attributes added in this + document must not be present in an Accounting-Request. + +Request Accept Reject Challenge # Attribute +0-1 0 0 0 70 ARAP-Password [Note 1] +0 0-1 0 0-1 71 ARAP-Features +0 0-1 0 0 72 ARAP-Zone-Access +0-1 0 0 0-1 73 ARAP-Security +0+ 0 0 0+ 74 ARAP-Security-Data +0 0 0-1 0 75 Password-Retry +0 0 0 0-1 76 Prompt +0-1 0 0 0 77 Connect-Info +0 0+ 0 0 78 Configuration-Token +0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] +0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1] +0 0-1 0 0-1 84 ARAP-Challenge-Response +0 0-1 0 0 85 Acct-Interim-Interval +0-1 0 0 0 87 NAS-Port-Id +0 0-1 0 0 88 Framed-Pool +Request Accept Reject Challenge # Attribute + + + +Rigney, et al. Informational [Page 38] + +RFC 2869 RADIUS Extensions June 2000 + + + [Note 1] An Access-Request that contains either a User-Password or + CHAP-Password or ARAP-Password or one or more EAP-Message attributes + MUST NOT contain more than one type of those four attributes. If it + does not contain any of those four attributes, it SHOULD contain a + Message-Authenticator. If any packet type contains an EAP-Message + attribute it MUST also contain a Message-Authenticator. + + The following table defines the above table entries. + + 0 This attribute MUST NOT be present + 0+ Zero or more instances of this attribute MAY be present. + 0-1 Zero or one instance of this attribute MAY be present. + 1 Exactly one instance of this attribute MUST be present. + +6. IANA Considerations + + The Packet Type Codes, Attribute Types, and Attribute Values defined + in this document are registered by the Internet Assigned Numbers + Authority (IANA) from the RADIUS name spaces as described in the + "IANA Considerations" section of [1], in accordance with BCP 26 [10]. + +7. Security Considerations + + The attributes other than Message-Authenticator and EAP-Message in + this document have no additional security considerations beyond those + already identified in [1]. + +7.1. Message-Authenticator Security + + Access-Request packets with a User-Password establish the identity of + both the user and the NAS sending the Access-Request, because of the + way the shared secret between NAS and RADIUS server is used. + Access-Request packets with CHAP-Password or EAP-Message do not have + a User-Password attribute, so the Message-Authenticator attribute + should be used in access-request packets that do not have a User- + Password, in order to establish the identity of the NAS sending the + request. + +7.2. EAP Security + + Since the purpose of EAP is to provide enhanced security for PPP + authentication, it is critical that RADIUS support for EAP be secure. + In particular, the following issues must be addressed: + + Separation of EAP server and PPP authenticator + Connection hijacking + Man in the middle attacks + Multiple databases + + + +Rigney, et al. Informational [Page 39] + +RFC 2869 RADIUS Extensions June 2000 + + + Negotiation attacks + +7.2.1. Separation of EAP server and PPP authenticator + + It is possible for the EAP endpoints to mutually authenticate, + negotiate a ciphersuite, and derive a session key for subsequent use + in PPP encryption. + + This does not present an issue on the peer, since the peer and EAP + client reside on the same machine; all that is required is for the + EAP client module to pass the session key to the PPP encryption + module. + + The situation is more complex when EAP is used with RADIUS, since the + PPP authenticator will typically not reside on the same machine as + the EAP server. For example, the EAP server may be a backend security + server, or a module residing on the RADIUS server. + + In the case where the EAP server and PPP authenticator reside on + different machines, there are several implications for security. + Firstly, mutual authentication will occur between the peer and the + EAP server, not between the peer and the authenticator. This means + that it is not possible for the peer to validate the identity of the + NAS or tunnel server that it is speaking to. + + As described earlier, when EAP/RADIUS is used to encapsulate EAP + packets, the Message-Authenticator attribute is required in + EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the + RADIUS server. Since the Message-Authenticator attribute involves a + HMAC-MD5 hash, it is possible for the RADIUS server to verify the + integrity of the Access-Request as well as the NAS or tunnel server's + identity. Similarly, Access-Challenge packets sent from the RADIUS + server to the NAS are also authenticated and integrity protected + using an HMAC-MD5 hash, enabling the NAS or tunnel server to + determine the integrity of the packet and verify the identity of the + RADIUS server. Moreover, EAP packets sent via methods that contain + their own integrity protection cannot be successfully modified by a + rogue NAS or tunnel server. + + The second issue that arises in the case of an EAP server and PPP + authenticator residing on different machines is that the session key + negotiated between the peer and EAP server will need to be + transmitted to the authenticator. Therefore a mechanism needs to be + provided to transmit the session key from the EAP server to the + authenticator or tunnel server that needs to use the key. The + specification of this transit mechanism is outside the scope of this + document. + + + + +Rigney, et al. Informational [Page 40] + +RFC 2869 RADIUS Extensions June 2000 + + +7.2.2. Connection hijacking + + In this form of attack, the attacker attempts to inject packets into + the conversation between the NAS and the RADIUS server, or between + the RADIUS server and the backend security server. RADIUS does not + support encryption, and as described in [1], only Access-Reply and + Access-Challenge packets are integrity protected. Moreover, the + integrity protection mechanism described in [1] is weaker than that + likely to be used by some EAP methods, making it possible to subvert + those methods by attacking EAP/RADIUS. + + In order to provide for authentication of all packets in the EAP + exchange, all EAP/RADIUS packets MUST be authenticated using the + Message-Authenticator attribute, as described previously. + +7.2.3. Man in the middle attacks + + Since RADIUS security is based on shared secrets, end-to-end security + is not provided in the case where authentication or accounting + packets are forwarded along a proxy chain. As a result, attackers + gaining control of a RADIUS proxy will be able to modify EAP packets + in transit. + +7.2.4. Multiple databases + + In many cases a backend security server will be deployed along with a + RADIUS server in order to provide EAP services. Unless the backend + security server also functions as a RADIUS server, two separate user + databases will exist, each containing information about the security + requirements for the user. This represents a weakness, since security + may be compromised by a successful attack on either of the servers, + or their backend databases. With multiple user databases, adding a + new user may require multiple operations, increasing the chances for + error. The problems are further magnified in the case where user + information is also being kept in an LDAP server. In this case, three + stores of user information may exist. + + In order to address these threats, consolidation of databases is + recommended. This can be achieved by having both the RADIUS server + and backend security server store information in the same backend + database; by having the backend security server provide a full RADIUS + implementation; or by consolidating both the backend security server + and the RADIUS server onto the same machine. + + + + + + + + +Rigney, et al. Informational [Page 41] + +RFC 2869 RADIUS Extensions June 2000 + + +7.2.5. Negotiation attacks + + In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or + RADIUS server causes the authenticating peer to choose a less secure + authentication method so as to make it easier to obtain the user's + password. For example, a session that would normally be authenticated + with EAP would instead authenticated via CHAP or PAP; alternatively, + a connection that would normally be authenticated via one EAP type + occurs via a less secure EAP type, such as MD5. The threat posed by + rogue devices, once thought to be remote, has gained currency given + compromises of telephone company switching systems, such as those + described in [11]. + + Protection against negotiation attacks requires the elimination of + downward negotiations. This can be achieved via implementation of + per-connection policy on the part of the authenticating peer, and + per-user policy on the part of the RADIUS server. + + For the authenticating peer, authentication policy should be set on a + per-connection basis. Per-connection policy allows an authenticating + peer to negotiate EAP when calling one service, while negotiating + CHAP for another service, even if both services are accessible via + the same phone number. + + With per-connection policy, an authenticating peer will only attempt + to negotiate EAP for a session in which EAP support is expected. As a + result, there is a presumption that an authenticating peer selecting + EAP requires that level of security. If it cannot be provided, it is + likely that there is some kind of misconfiguration, or even that the + authenticating peer is contacting the wrong server. Should the NAS + not be able to negotiate EAP, or should the EAP-Request sent by the + NAS be of a different EAP type than what is expected, the + authenticating peer MUST disconnect. An authenticating peer expecting + EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. + + For a NAS, it may not be possible to determine whether a user is + required to authenticate with EAP until the user's identity is known. + For example, for shared-uses NASes it is possible for one reseller to + implement EAP while another does not. In such cases, if any users of + the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for + every call. This avoids forcing an EAP-capable client to do more than + one authentication, which weakens security. + + If CHAP is negotiated, the NAS will pass the User-Name and CHAP- + Password attributes to the RADIUS Server in an Access-Request packet. + If the user is not required to use EAP, then the RADIUS Server will + respond with an Access-Accept or Access-Reject packet as appropriate. + However, if CHAP has been negotiated but EAP is required, the RADIUS + + + +Rigney, et al. Informational [Page 42] + +RFC 2869 RADIUS Extensions June 2000 + + + server MUST respond with an Access-Reject, rather than an Access- + Challenge/EAP-Message/EAP-Request packet. The authenticating peer + MUST refuse to renegotiate authentication, even if the renegotiation + is from CHAP to EAP. + + If EAP is negotiated but is not supported by the RADIUS proxy or + server, then the server or proxy MUST respond with an Access-Reject. + In these cases, the NAS MUST send an LCP-Terminate and disconnect the + user. This is the correct behavior since the authenticating peer is + expecting EAP to be negotiated, and that expectation cannot be + fulfilled. An EAP-capable authenticating peer MUST refuse to + renegotiate the authentication protocol if EAP had initially been + negotiated. Note that problems with a non-EAP capable RADIUS proxy + could prove difficult to diagnose, since a user dialing in from one + location (with an EAP-capable proxy) might be able to successfully + authenticate via EAP, while the same user dialing into another + location (and encountering an EAP-incapable proxy) might be + consistently disconnected. + +8. References + + [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and + I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC + 2868, June 2000. + + [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, June 2000. + + [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + + + + + +Rigney, et al. Informational [Page 43] + +RFC 2869 RADIUS Extensions June 2000 + + + [9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [11] Slatalla, M., and Quittner, J., "Masters of Deception." + HarperCollins, New York, 1995. + +9. Acknowledgements + + RADIUS and RADIUS Accounting were originally developed by Livingston + Enterprises (now part of Lucent Technologies) for their PortMaster + series of Network Access Servers. + + The section on ARAP is adopted with permission from "Using RADIUS to + Authenticate Apple Remote Access Connections" by Ward Willats of Cyno + Technologies (ward@cyno.com). + + The section on Acct-Interim-Interval is adopted with permission from + an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark + Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. + + The section on EAP is adopted with permission from an earlier work in + progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit + Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson + and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of + Microsoft for useful discussions of this problem space. + +10. Chair's Address + + The RADIUS working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + + + + + + + + + +Rigney, et al. Informational [Page 44] + +RFC 2869 RADIUS Extensions June 2000 + + +11. Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@telemancy.com + + Questions on ARAP and RADIUS may be directed to: + + Ward Willats + Cyno Technologies + 1082 Glen Echo Ave + San Jose, CA 95125 + + Phone: +1 408 297 7766 + EMail: ward@cyno.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 45] + +RFC 2869 RADIUS Extensions June 2000 + + + Questions on EAP and RADIUS may be directed to any of the following: + + Pat R. Calhoun + Network and Security Research Center + Sun Microsystems, Inc. + 15 Network Circle + Menlo Park, CA 94025 + + Phone: +1 650 786 7733 + EMail: pcalhoun@eng.sun.com + + + Allan C. Rubens + Tut Systems, Inc. + 220 E. Huron, Suite 260 + Ann Arbor, MI 48104 + + Phone: +1 734 995 1697 + EMail: arubens@tutsys.com + + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 936 6605 + EMail: bernarda@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 46] + +RFC 2869 RADIUS Extensions June 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 47] + |