summaryrefslogtreecommitdiff
path: root/rfc/rfc2869.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc2869.txt')
-rw-r--r--rfc/rfc2869.txt2635
1 files changed, 2635 insertions, 0 deletions
diff --git a/rfc/rfc2869.txt b/rfc/rfc2869.txt
new file mode 100644
index 0000000..74ed7f6
--- /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]
+