From 50c6611fb2d9fdcfd820dd13579bb229508166a4 Mon Sep 17 00:00:00 2001 From: Dmitry Kozlov Date: Tue, 24 Aug 2010 12:57:08 +0400 Subject: additional documentation --- doc/rfc2138.txt | 3643 +++++++++++++++++++++++++++++++++++++++++++++++ doc/rfc2139.txt | 1403 ++++++++++++++++++ doc/rfc2548.txt | 2299 ++++++++++++++++++++++++++++++ doc/rfc2865.txt | 4259 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ doc/rfc2866.txt | 1571 ++++++++++++++++++++ doc/rfc2869.txt | 2635 ++++++++++++++++++++++++++++++++++ doc/rfc3580.txt | 1683 ++++++++++++++++++++++ 7 files changed, 17493 insertions(+) create mode 100644 doc/rfc2138.txt create mode 100644 doc/rfc2139.txt create mode 100644 doc/rfc2548.txt create mode 100644 doc/rfc2865.txt create mode 100644 doc/rfc2866.txt create mode 100644 doc/rfc2869.txt create mode 100644 doc/rfc3580.txt diff --git a/doc/rfc2138.txt b/doc/rfc2138.txt new file mode 100644 index 0000000..9f4a86d --- /dev/null +++ b/doc/rfc2138.txt @@ -0,0 +1,3643 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2138 Livingston +Obsoletes: 2058 A. Rubens +Category: Standards Track Merit + W. Simpson + Daydreamer + S. Willens + Livingston + April 1997 + + + Remote Authentication Dial In User Service (RADIUS) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a protocol for carrying authentication, + authorization, and configuration information between a Network Access + Server which desires to authenticate its links and a shared + Authentication Server. + +Implementation Note + + This memo documents the RADIUS protocol. There has been some + confusion in the assignment of port numbers for this protocol. The + early deployment of RADIUS was done using the erroneously chosen port + number 1645, which conflicts with the "datametrics" service. The + officially assigned port number for RADIUS is 1812. + +Table of Contents + + 1. Introduction .......................................... 3 + 1.1 Specification of Requirements ................... 4 + 1.2 Terminology ..................................... 5 + 2. Operation ............................................. 5 + 2.1 Challenge/Response .............................. 7 + 2.2 Interoperation with PAP and CHAP ................ 7 + 2.3 Why UDP? ........................................ 8 + 3. Packet Format ......................................... 10 + 4. Packet Types .......................................... 13 + 4.1 Access-Request .................................. 13 + + + +Rigney, et. al. Standards Track [Page 1] + +RFC 2138 RADIUS April 1997 + + + 4.2 Access-Accept ................................... 14 + 4.3 Access-Reject ................................... 15 + 4.4 Access-Challenge ................................ 17 + 5. Attributes ............................................ 18 + 5.1 User-Name ....................................... 21 + 5.2 User-Password ................................... 22 + 5.3 CHAP-Password ................................... 23 + 5.4 NAS-IP-Address .................................. 24 + 5.5 NAS-Port ........................................ 25 + 5.6 Service-Type .................................... 26 + 5.7 Framed-Protocol ................................. 28 + 5.8 Framed-IP-Address ............................... 29 + 5.9 Framed-IP-Netmask ............................... 29 + 5.10 Framed-Routing .................................. 30 + 5.11 Filter-Id ....................................... 31 + 5.12 Framed-MTU ...................................... 32 + 5.13 Framed-Compression .............................. 33 + 5.14 Login-IP-Host ................................... 33 + 5.15 Login-Service ................................... 34 + 5.16 Login-TCP-Port .................................. 35 + 5.17 (unassigned) .................................... 36 + 5.18 Reply-Message ................................... 36 + 5.19 Callback-Number ................................. 37 + 5.20 Callback-Id ..................................... 38 + 5.21 (unassigned) .................................... 38 + 5.22 Framed-Route .................................... 39 + 5.23 Framed-IPX-Network .............................. 40 + 5.24 State ........................................... 40 + 5.25 Class ........................................... 41 + 5.26 Vendor-Specific ................................. 42 + 5.27 Session-Timeout ................................. 44 + 5.28 Idle-Timeout .................................... 44 + 5.29 Termination-Action .............................. 45 + 5.30 Called-Station-Id ............................... 46 + 5.31 Calling-Station-Id .............................. 47 + 5.32 NAS-Identifier .................................. 48 + 5.33 Proxy-State ..................................... 48 + 5.34 Login-LAT-Service ............................... 49 + 5.35 Login-LAT-Node .................................. 50 + 5.36 Login-LAT-Group ................................. 51 + 5.37 Framed-AppleTalk-Link ........................... 52 + 5.38 Framed-AppleTalk-Network ........................ 53 + 5.39 Framed-AppleTalk-Zone ........................... 54 + 5.40 CHAP-Challenge .................................. 55 + 5.41 NAS-Port-Type ................................... 55 + 5.42 Port-Limit ...................................... 56 + 5.43 Login-LAT-Port .................................. 57 + 5.44 Table of Attributes ............................. 58 + + + +Rigney, et. al. Standards Track [Page 2] + +RFC 2138 RADIUS April 1997 + + + 6. Examples .............................................. 59 + 6.1 User Telnet to Specified Host ................... 60 + 6.2 Framed User Authenticating with CHAP ............ 60 + 6.3 User with Challenge-Response card ............... 61 + Security Considerations ...................................... 63 + References ................................................... 64 + Acknowledgements ............................................. 64 + Chair's Address .............................................. 65 + Author's Addresses ........................................... 65 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + Key features of RADIUS are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of RADIUS. The + client is responsible for passing user information to designated + RADIUS servers, and then acting on the response which is returned. + + RADIUS servers are responsible for receiving user connection + requests, authenticating the user, and then returning all + configuration information necessary for the client to deliver + service to the user. + + A RADIUS server can act as a proxy client to other RADIUS servers + or other kinds of authentication servers. + + Network Security + + Transactions between the client and RADIUS server are + authenticated through the use of a shared secret, which is never + sent over the network. In addition, any user passwords are sent + encrypted between the client and RADIUS server, to eliminate the + possibility that someone snooping on an unsecure network could + determine a user's password. + + + + + + +Rigney, et. al. Standards Track [Page 3] + +RFC 2138 RADIUS April 1997 + + + Flexible Authentication Mechanisms + + The RADIUS server can support a variety of methods to authenticate + a user. When it is provided with the user name and original + password given by the user, it can support PPP PAP or CHAP, UNIX + login, and other authentication mechanisms. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added without + disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 4] + +RFC 2138 RADIUS April 1997 + + +1.2. Terminology + + This document frequently 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 + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that. + + 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 + + When a client is configured to use RADIUS, any user of the client + presents authentication information to the client. This might be + with a customizable login prompt, where the user is expected to enter + their username and password. Alternatively, the user might use a + link framing protocol such as the Point-to-Point Protocol (PPP), + which has authentication packets which carry this information. + + Once the client has obtained such information, it may choose to + authenticate using RADIUS. To do so, the client creates an "Access- + Request" containing such Attributes as the user's name, the user's + password, the ID of the client and the Port ID which the user is + accessing. When a password is present, it is hidden using a method + based on the RSA Message Digest Algorithm MD5 [1]. + + The Access-Request is submitted to the RADIUS server via the network. + If no response is returned within a length of time, the request is + re-sent a number of times. The client can also forward requests to + an alternate server or servers in the event that the primary server + is down or unreachable. An alternate server can be used either after + a number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + + + + + +Rigney, et. al. Standards Track [Page 5] + +RFC 2138 RADIUS April 1997 + + + Once the RADIUS server receives the request, it validates the sending + client. A request from a client for which the RADIUS server does not + have a shared secret should be silently discarded. If the client is + valid, the RADIUS server consults a database of users to find the + user whose name matches the request. The user entry in the database + contains a list of requirements which must be met to allow access for + the user. This always includes verification of the password, but can + also specify the client(s) or port(s) to which the user is allowed + access. + + The RADIUS server MAY make requests of other servers in order to + satisfy the request, in which case it acts as a client. + + If any condition is not met, the RADIUS server sends an "Access- + Reject" response indicating that this user request is invalid. If + desired, the server MAY include a text message in the Access-Reject + which MAY be displayed by the client to the user. No other + Attributes are permitted in an Access-Reject. + + If all conditions are met and the RADIUS server wishes to issue a + challenge to which the user must respond, the RADIUS server sends an + "Access-Challenge" response. It MAY include a text message to be + displayed by the client to the user prompting for a response to the + challenge, and MAY include a State attribute. If the client receives + an Access-Challenge and supports challenge/response it MAY display + the text message, if any, to the user, and then prompt the user for a + response. The client then re-submits its original Access-Request + with a new request ID, with the User-Password Attribute replaced by + the response (encrypted), and including the State Attribute from the + Access-Challenge, if any. Only 0 or 1 instances of the State + Attributes should be present in a request. The server can respond to + this new Access-Request with either an Access-Accept, an Access- + Reject, or another Access-Challenge. + + If all conditions are met, the list of configuration values for the + user are placed into an "Access-Accept" response. These values + include the type of service (for example: SLIP, PPP, Login User) and + all necessary values to deliver the desired service. For SLIP and + PPP, this may include values such as IP address, subnet mask, MTU, + desired compression, and desired packet filter identifiers. For + character mode users, this may include values such as desired + protocol and host. + + + + + + + + + +Rigney, et. al. Standards Track [Page 6] + +RFC 2138 RADIUS April 1997 + + +2.1. Challenge/Response + + In challenge/response authentication, the user is given an + unpredictable number and challenged to encrypt it and give back the + result. Authorized users are equipped with special devices such as + smart cards or software that facilitate calculation of the correct + response with ease. Unauthorized users, lacking the appropriate + device or software and lacking knowledge of the secret key necessary + to emulate such a device or software, can only guess at the response. + + The Access-Challenge packet typically contains a Reply-Message + including a challenge to be displayed to the user, such as a numeric + value unlikely ever to be repeated. Typically this is obtained from + an external server that knows what type of authenticator should be in + the possession of the authorized user and can therefore choose a + random or non-repeating pseudorandom number of an appropriate radix + and length. + + The user then enters the challenge into his device (or software) and + it calculates a response, which the user enters into the client which + forwards it to the RADIUS server via a second Access-Request. If the + response matches the expected response the RADIUS server replies with + an Access-Accept, otherwise an Access-Reject. + + Example: The NAS sends an Access-Request packet to the RADIUS Server + with NAS-Identifier, NAS-Port, User-Name, User-Password (which may + just be a fixed string like "challenge" or ignored). The server + sends back an Access-Challenge packet with State and a Reply-Message + along the lines of "Challenge 12345678, enter your response at the + prompt" which the NAS displays. The NAS prompts for the response and + sends a NEW Access-Request to the server (with a new ID) with NAS- + Identifier, NAS-Port, User-Name, User-Password (the response just + entered by the user, encrypted), and the same State Attribute that + came with the Access-Challenge. The server then sends back either an + Access-Accept or Access-Reject based on whether the response matches + what it should be, or it can even send another Access-Challenge. + +2.2. Interoperation with PAP and CHAP + + For PAP, the NAS takes the PAP ID and password and sends them in an + Access-Request packet as the User-Name and User-Password. The NAS MAY + include the Attributes Service-Type = Framed-User and Framed-Protocol + = PPP as a hint to the RADIUS server that PPP service is expected. + + For CHAP, the NAS generates a random challenge (preferably 16 octets) + and sends it to the user, who returns a CHAP response along with a + CHAP ID and CHAP username. The NAS then sends an Access-Request + packet to the RADIUS server with the CHAP username as the User-Name + + + +Rigney, et. al. Standards Track [Page 7] + +RFC 2138 RADIUS April 1997 + + + and with the CHAP ID and CHAP response as the CHAP-Password + (Attribute 3). The random challenge can either be included in the + CHAP-Challenge attribute or, if it is 16 octets long, it can be + placed in the Request Authenticator field of the Access-Request + packet. The NAS MAY include the Attributes Service-Type = Framed- + User and Framed-Protocol = PPP as a hint to the RADIUS server that + PPP service is expected. + + The RADIUS server looks up a password based on the User-Name, + encrypts the challenge using MD5 on the CHAP ID octet, that password, + and the CHAP challenge (from the CHAP-Challenge attribute if present, + otherwise from the Request Authenticator), and compares that result + to the CHAP-Password. If they match, the server sends back an + Access-Accept, otherwise it sends back an Access-Reject. + + If the RADIUS server is unable to perform the requested + authentication it should return an Access-Reject. For example, CHAP + requires that the user's password be available in cleartext to the + server so that it can encrypt the CHAP challenge and compare that to + the CHAP response. If the password is not available in cleartext to + the RADIUS server then the server MUST send an Access-Reject to the + client. + +2.3. Why UDP? + + A frequently asked question is why RADIUS uses UDP instead of TCP as + a transport protocol. UDP was chosen for strictly technical reasons. + + There are a number of issues which must be understood. RADIUS is a + transaction based protocol which has several interesting + characteristics: + + 1. If the request to a primary Authentication server fails, a + secondary server must be queried. + + To meet this requirement, a copy of the request must be kept + above the transport layer to allow for alternate transmission. + This means that retransmission timers are still required. + + 2. The timing requirements of this particular protocol are + significantly different than TCP provides. + + At one extreme, RADIUS does not require a "responsive" + detection of lost data. The user is willing to wait several + seconds for the authentication to complete. The generally + aggressive TCP retransmission (based on average round trip + time) is not required, nor is the acknowledgement overhead of + TCP. + + + +Rigney, et. al. Standards Track [Page 8] + +RFC 2138 RADIUS April 1997 + + + At the other extreme, the user is not willing to wait several + minutes for authentication. Therefore the reliable delivery of + TCP data two minutes later is not useful. The faster use of an + alternate server allows the user to gain access before giving + up. + + 3. The stateless nature of this protocol simplifies the use of UDP. + + Clients and servers come and go. Systems are rebooted, or are + power cycled independently. Generally this does not cause a + problem and with creative timeouts and detection of lost TCP + connections, code can be written to handle anomalous events. + UDP however completely eliminates any of this special handling. + Each client and server can open their UDP transport just once + and leave it open through all types of failure events on the + network. + + 4. UDP simplifies the server implementation. + + In the earliest implementations of RADIUS, the server was + single threaded. This means that a single request was + received, processed, and returned. This was found to be + unmanageable in environments where the back-end security + mechanism took real time (1 or more seconds). The server + request queue would fill and in environments where hundreds of + people were being authenticated every minute, the request + turn-around time increased to longer that users were willing to + wait (this was especially severe when a specific lookup in a + database or over DNS took 30 or more seconds). The obvious + solution was to make the server multi-threaded. Achieving this + was simple with UDP. Separate processes were spawned to serve + each request and these processes could respond directly to the + client NAS with a simple UDP packet to the original transport + of the client. + + It's not all a panacea. As noted, using UDP requires one thing + which is built into TCP: with UDP we must artificially manage + retransmission timers to the same server, although they don't + require the same attention to timing provided by TCP. This one + penalty is a small price to pay for the advantages of UDP in + this protocol. + + Without TCP we would still probably be using tin cans connected + by string. But for this particular protocol, UDP is a better + choice. + + + + + + +Rigney, et. al. Standards Track [Page 9] + +RFC 2138 RADIUS April 1997 + + +3. Packet Format + + Exactly one RADIUS packet is encapsulated in the UDP Data field [2], + where the UDP Destination Port field indicates 1812 (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS protocol. There has been some + confusion in the assignment of port numbers for this protocol. The + early deployment of RADIUS was done using the erroneously chosen port + number 1645, which conflicts with the "datametrics" service. The + officially assigned port number for RADIUS is 1812. + + A summary of the RADIUS data 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + +Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it is + silently discarded. + + RADIUS Codes (decimal) are assigned as follows: + + 1 Access-Request + 2 Access-Accept + 3 Access-Reject + 4 Accounting-Request + 5 Accounting-Response + 11 Access-Challenge + 12 Status-Server (experimental) + 13 Status-Client (experimental) + 255 Reserved + + + + +Rigney, et. al. Standards Track [Page 10] + +RFC 2138 RADIUS April 1997 + + + Codes 4 and 5 are covered in the RADIUS Accounting document [9], and + are not further mentioned here. Codes 12 and 13 are reserved for + possible use, but are not further mentioned here. + +Identifier + + The Identifier field is one octet, and aids in matching requests and + replies. + +Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + should be treated as padding and should be ignored on reception. If + the packet is shorter than the Length field indicates, it should be + silently discarded. The minimum length is 20 and maximum length is + 4096. + +Authenticator + + The Authenticator field is sixteen (16) octets. The most significant + octet is transmitted first. This value is used to authenticate the + reply from the RADIUS server, and is used in the password hiding + algorithm. + +Request Authenticator + + In Access-Request Packets, the Authenticator value is a 16 octet + random number, called the Request Authenticator. The value SHOULD + be unpredictable and unique over the lifetime of a secret (the + password shared between the client and the RADIUS server), since + repetition of a request value in conjunction with the same secret + would permit an attacker to reply with a previously intercepted + response. Since it is expected that the same secret MAY be used + to authenticate with servers in disparate geographic regions, the + Request Authenticator field SHOULD exhibit global and temporal + uniqueness. + + The Request Authenticator value in an Access-Request packet SHOULD + also be unpredictable, lest an attacker trick a server into + responding to a predicted future request, and then use the + response to masquerade as that server to a future Access-Request. + + + + + + + + +Rigney, et. al. Standards Track [Page 11] + +RFC 2138 RADIUS April 1997 + + + Although protocols such as RADIUS are incapable of protecting + against theft of an authenticated session via realtime active + wiretapping attacks, generation of unique unpredictable requests + can protect against a wide range of active attacks against + authentication. + + The NAS and RADIUS server share a secret. That shared secret + followed by the Request Authenticator is put through a one-way MD5 + hash to create a 16 octet digest value which is xored with the + password entered by the user, and the xored result placed in the + User-Password attribute in the Access-Request packet. See the + entry for User-Password in the section on Attributes for a more + detailed description. + + Response Authenticator + + The value of the Authenticator field in Access-Accept, Access- + Reject, and Access-Challenge packets is called the Response + Authenticator, and contains a one-way MD5 hash calculated over a + stream of octets consisting of: the RADIUS packet, beginning with + the Code field, including the Identifier, the Length, the Request + Authenticator field from the Access-Request packet, and the + response Attributes, followed by the shared secret. That is, + ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) + where + denotes concatenation. + +Administrative Note + + The secret (password shared between the client and the RADIUS server) + SHOULD be at least as large and unguessable as a well-chosen + password. It is preferred that the secret be at least 16 octets. + This is to ensure a sufficiently large range for the secret to + provide protection against exhaustive search attacks. A RADIUS + server SHOULD use the source IP address of the RADIUS UDP packet to + decide which shared secret to use, so that RADIUS requests can be + proxied. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction - when the proxy + forwards the request, the proxy can add a Proxy-State Attribute, and + when the proxy forwards a response, it removes the Proxy-State + Attribute. Since Access-Accept and Access-Reject replies are + authenticated on the entire packet contents, the stripping of the + Proxy-State attribute would invalidate the signature in the packet - + so the proxy has to re-sign it. + + Further details of RADIUS proxy implementation are outside the scope + of this document. + + + +Rigney, et. al. Standards Track [Page 12] + +RFC 2138 RADIUS April 1997 + + +Attributes + + Many Attributes may have multiple instances, in such a case the order + of Attributes of the same Type SHOULD be preserved. The order of + Attributes of different Types is not required to be preserved. + + In the section below on "Attributes" where the text refers to which + packets an attribute is allowed in, only packets with Codes 1, 2, 3 + and 11 and attributes defined in this document are covered in this + document. A summary table is provided at the end of the "Attributes" + section. To determine which Attributes are allowed in packets with + codes 4 and 5 refer to the RADIUS Accounting document [9]. + +4. Packet Types + + The RADIUS Packet type is determined by the Code field in the first + octet of the Packet. + +4.1. Access-Request + + Description + + Access-Request packets are sent to a RADIUS server, and convey + information used to determine whether a user is allowed access to + a specific NAS, and any special services requested for that user. + An implementation wishing to authenticate a user MUST transmit a + RADIUS packet with the Code field set to 1 (Access-Request). + + Upon receipt of an Access-Request from a valid client, an + appropriate reply MUST be transmitted. + + An Access-Request MUST contain a User-Name attribute. It SHOULD + contain either a NAS-IP-Address attribute or NAS-Identifier + attribute (or both, although that is not recommended). It MUST + contain either a User-Password attribute or CHAP-Password + attribute. It SHOULD contain a NAS-Port or NAS-Port-Type + attribute or both unless the type of access being requested does + not involve a port or the NAS does not distinguish among its + ports. + + An Access-Request MAY contain additional attributes as a hint to + the server, but the server is not required to honor the hint. + + When a User-Password is present, it is hidden using a method based + on the RSA Message Digest Algorithm MD5 [1]. + + A summary of the Access-Request packet format is shown below. The + fields are transmitted from left to right. + + + +Rigney, et. al. Standards Track [Page 13] + +RFC 2138 RADIUS April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 1 for Access-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MUST remain unchanged. + + Request Authenticator + + The Request Authenticator value MUST be changed each time a new + Identifier is used. + + Attributes + + The Attribute field is variable in length, and contains the list + of Attributes that are required for the type of service, as well + as any desired optional Attributes. + +4.2. Access-Accept + + Description + + Access-Accept packets are sent by the RADIUS server, and provide + specific configuration information necessary to begin delivery of + service to the user. If all Attribute values received in an + Access-Request are acceptable then the RADIUS implementation MUST + transmit a packet with the Code field set to 2 (Access-Accept). + + + + + + + +Rigney, et. al. Standards Track [Page 14] + +RFC 2138 RADIUS April 1997 + + + On reception of an Access-Accept, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + A summary of the Access-Accept packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Access-Accept. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Accept. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 15] + +RFC 2138 RADIUS April 1997 + + +4.3. Access-Reject + + Description + + If any value of the received Attributes is not acceptable, then + the RADIUS server MUST transmit a packet with the Code field set + to 3 (Access-Reject). It MAY include one or more Reply-Message + Attributes with a text message which the NAS MAY display to the + user. + + A summary of the Access-Reject packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Access-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Reject. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney, et. al. Standards Track [Page 16] + +RFC 2138 RADIUS April 1997 + + +4.4. Access-Challenge + + Description + + If the RADIUS server desires to send the user a challenge + requiring a response, then the RADIUS server MUST respond to the + Access-Request by transmitting a packet with the Code field set to + 11 (Access-Challenge). + + The Attributes field MAY have one or more Reply-Message + Attributes, and MAY have a single State Attribute, or none. No + other Attributes are permitted in an Access-Challenge. + + On receipt of an Access-Challenge, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + If the NAS does not support challenge/response, it MUST treat an + Access-Challenge as though it had received an Access-Reject + instead. + + If the NAS supports challenge/response, receipt of a valid + Access-Challenge indicates that a new Access-Request SHOULD be + sent. The NAS MAY display the text message, if any, to the user, + and then prompt the user for a response. It then sends its + original Access-Request with a new request ID and Request + Authenticator, with the User-Password Attribute replaced by the + user's response (encrypted), and including the State Attribute + from the Access-Challenge, if any. Only 0 or 1 instances of the + State Attribute can be present in an Access-Request. + + A NAS which supports PAP MAY forward the Reply-Message to the + dialin client and accept a PAP response which it can use as though + the user had entered the response. If the NAS cannot do so, it + should treat the Access-Challenge as though it had received an + Access-Reject instead. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 17] + +RFC 2138 RADIUS April 1997 + + + A summary of the Access-Challenge packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 11 for Access-Challenge. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Challenge. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization, + information and configuration details for the request and reply. + + Some Attributes MAY be included more than once. The effect of this + is Attribute specific, and is specified in each Attribute + description. + + The end of the list of Attributes is indicated by the Length of the + RADIUS packet. + + + + + +Rigney, et. al. Standards Track [Page 18] + +RFC 2138 RADIUS April 1997 + + + A summary of the 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | 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 [3]. + 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: + + A RADIUS server MAY ignore Attributes with an unknown Type. + + A RADIUS client MAY ignore Attributes with an unknown Type. + + 1 User-Name + 2 User-Password + 3 CHAP-Password + 4 NAS-IP-Address + 5 NAS-Port + 6 Service-Type + 7 Framed-Protocol + 8 Framed-IP-Address + 9 Framed-IP-Netmask + 10 Framed-Routing + 11 Filter-Id + 12 Framed-MTU + 13 Framed-Compression + 14 Login-IP-Host + 15 Login-Service + 16 Login-TCP-Port + 17 (unassigned) + 18 Reply-Message + 19 Callback-Number + 20 Callback-Id + 21 (unassigned) + 22 Framed-Route + 23 Framed-IPX-Network + 24 State + 25 Class + 26 Vendor-Specific + + + +Rigney, et. al. Standards Track [Page 19] + +RFC 2138 RADIUS April 1997 + + + 27 Session-Timeout + 28 Idle-Timeout + 29 Termination-Action + 30 Called-Station-Id + 31 Calling-Station-Id + 32 NAS-Identifier + 33 Proxy-State + 34 Login-LAT-Service + 35 Login-LAT-Node + 36 Login-LAT-Group + 37 Framed-AppleTalk-Link + 38 Framed-AppleTalk-Network + 39 Framed-AppleTalk-Zone + 40-59 (reserved for accounting) + 60 CHAP-Challenge + 61 NAS-Port-Type + 62 Port-Limit + 63 Login-LAT-Port + + 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 an Access-Request but with an invalid + Length, an Access-Reject SHOULD be transmitted. If an Attribute + is received in an Access-Accept, Access-Reject or Access-Challenge + packet with an invalid length, the packet MUST either be treated + an Access-Reject or else 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 a "string" in RADIUS does not require termination by an + ASCII NUL because the Attribute already has a length field. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 20] + +RFC 2138 RADIUS April 1997 + + + The format of the value field is one of four data types. + + string 0-253 octets + + address 32 bit value, most significant octet first. + + integer 32 bit value, most significant octet first. + + time 32 bit value, most significant octet first -- seconds + since 00:00:00 GMT, January 1, 1970. The standard + Attributes do not use this data type but it is presented + here for possible use within Vendor-Specific attributes. + + +5.1. User-Name + + Description + + This Attribute indicates the name of the user to be authenticated. + It is only used in Access-Request packets. + + A summary of the User-Name 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 1 for User-Name. + + Length + + >= 3 + + String + + The String field is one or more octets. The NAS may limit the + maximum length of the User-Name but the ability to handle at least + 63 octets is recommended. + + + + + + + + +Rigney, et. al. Standards Track [Page 21] + +RFC 2138 RADIUS April 1997 + + + The format of the username MAY be one of several forms: + + monolithic Consisting only of alphanumeric characters. This + simple form might be used to locally manage a NAS. + + simple Consisting only of printable ASCII characters. + + name@fqdn SMTP address. The Fully Qualified Domain Name (with or + without trailing dot) indicates the realm in which the + name part applies. + + distinguished name + A name in ASN.1 form used in Public Key authentication + systems. + +5.2. User-Password + + Description + + This Attribute indicates the password of the user to be + authenticated, or the user's input following an Access-Challenge. + It is only used in Access-Request packets. + + On transmission, the password is hidden. The password is first + padded at the end with nulls to a multiple of 16 octets. A one- + way MD5 hash is calculated over a stream of octets consisting of + the shared secret followed by the Request Authenticator. This + value is XORed with the first 16 octet segment of the password and + placed in the first 16 octets of the String field of the User- + Password Attribute. + + If the password is longer than 16 characters, a second one-way MD5 + hash is calculated over a stream of octets consisting of the + shared secret followed by the result of the first xor. That hash + is XORed with the second 16 octet segment of the password and + placed in the second 16 octets of the String field of the User- + Password Attribute. + + If necessary, this operation is repeated, with each xor result + being used along with the shared secret to generate the next hash + to xor the next segment of the password, to no more than 128 + characters. + + The method is taken from the book "Network Security" by Kaufman, + Perlman and Speciner [4] pages 109-110. A more precise + explanation of the method follows: + + + + + +Rigney, et. al. Standards Track [Page 22] + +RFC 2138 RADIUS April 1997 + + + Call the shared secret S and the pseudo-random 128-bit Request + Authenticator RA. Break the password into 16-octet chunks p1, p2, + etc. with the last one padded at the end with nulls to a 16-octet + boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need + intermediate values b1, b2, etc. + + b1 = MD5(S + RA) c(1) = p1 xor b1 + b2 = MD5(S + c(1)) c(2) = p2 xor b2 + . . + . . + . . + bi = MD5(S + c(i-1)) c(i) = pi xor bi + + The String will contain c(1)+c(2)+...+c(i) where + denotes + concatenation. + + On receipt, the process is reversed to yield the original + password. + + A summary of the User-Password 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 2 for User-Password. + + Length + + At least 18 and no larger than 130. + + String + + The String field is between 16 and 128 octets long, inclusive. + +5.3. CHAP-Password + + Description + + This Attribute indicates the response value provided by a PPP + Challenge-Handshake Authentication Protocol (CHAP) user in + response to the challenge. It is only used in Access-Request + packets. + + + +Rigney, et. al. Standards Track [Page 23] + +RFC 2138 RADIUS April 1997 + + + The CHAP challenge value is found in the CHAP-Challenge Attribute + (60) if present in the packet, otherwise in the Request + Authenticator field. + + A summary of the CHAP-Password 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 4 5 6 7 8 9 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | CHAP Ident | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 3 for CHAP-Password. + + Length + + 19 + + CHAP Ident + + This field is one octet, and contains the CHAP Identifier from the + user's CHAP Response. + + String + + The String field is 16 octets, and contains the CHAP Response from + the user. + +5.4. NAS-IP-Address + + Description + + This Attribute indicates the identifying IP Address of the NAS + which is requesting authentication of the user. It is only used + in Access-Request packets. Either NAS-IP-Address or NAS- + Identifier SHOULD be present in an Access-Request packet. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 24] + +RFC 2138 RADIUS April 1997 + + + A summary of the NAS-IP-Address 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 4 for NAS-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. + +5.5. NAS-Port + + Description + + This Attribute indicates the physical port number of the NAS which + is authenticating the user. It is only used in Access-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-Type (61) or both SHOULD + be present in an Access-Request packet, if the NAS differentiates + among its ports. + + A summary of the NAS-Port Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 25] + +RFC 2138 RADIUS April 1997 + + + 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 + + 5 for NAS-Port. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + +5.6. Service-Type + + Description + + This Attribute indicates the type of service the user has + requested, or the type of service to be provided. It MAY be used + in both Access-Request and Access-Accept packets. A NAS is not + required to implement all of these service types, and MUST treat + unknown or unsupported Service-Types as though an Access-Reject + had been received instead. + + A summary of the Service-Type 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 + + 6 for Service-Type. + + + + + +Rigney, et. al. Standards Track [Page 26] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Login + 2 Framed + 3 Callback Login + 4 Callback Framed + 5 Outbound + 6 Administrative + 7 NAS Prompt + 8 Authenticate Only + 9 Callback NAS Prompt + + + The service types are defined as follows when used in an Access- + Accept. When used in an Access-Request, they should be considered + to be a hint to the RADIUS server that the NAS has reason to + believe the user would prefer the kind of service indicated, but + the server is not required to honor the hint. + + Login The user should be connected to a host. + + Framed A Framed Protocol should be started for the + User, such as PPP or SLIP. + + Callback Login The user should be disconnected and called + back, then connected to a host. + + Callback Framed The user should be disconnected and called + back, then a Framed Protocol should be started + for the User, such as PPP or SLIP. + + Outbound The user should be granted access to outgoing + devices. + + Administrative The user should be granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + + NAS Prompt The user should be provided a command prompt + on the NAS from which non-privileged commands + can be executed. + + + + +Rigney, et. al. Standards Track [Page 27] + +RFC 2138 RADIUS April 1997 + + + Authenticate Only Only Authentication is requested, and no + authorization information needs to be returned + in the Access-Accept (typically used by proxy + servers rather than the NAS itself). + + Callback NAS Prompt The user should be disconnected and called + back, then provided a command prompt on the + NAS from which non-privileged commands can be + executed. + +5.7. Framed-Protocol + + Description + + This Attribute indicates the framing to be used for framed access. + It MAY be used in both Access-Request and Access-Accept packets. + + A summary of the Framed-Protocol 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 + + 7 for Framed-Protocol. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 PPP + 2 SLIP + 3 AppleTalk Remote Access Protocol (ARAP) + 4 Gandalf proprietary SingleLink/MultiLink protocol + 5 Xylogics proprietary IPX/SLIP + + + + + + +Rigney, et. al. Standards Track [Page 28] + +RFC 2138 RADIUS April 1997 + + +5.8. Framed-IP-Address + + Description + + This Attribute indicates the address to be configured for the + user. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint by the NAS to the server that + it would prefer that address, but the server is not required to + honor the hint. + + A summary of the Framed-IP-Address 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 for Framed-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS should allow the user to select an address (e.g. + Negotiated). The value 0xFFFFFFFE indicates that the NAS should + select an address for the user (e.g. Assigned from a pool of + addresses kept by the NAS). Other valid values indicate that the + NAS should use that value as the user's IP address. + +5.9. Framed-IP-Netmask + + Description + + This Attribute indicates the IP netmask to be configured for the + user when the user is a router to a network. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet + as a hint by the NAS to the server that it would prefer that + netmask, but the server is not required to honor the hint. + + + + +Rigney, et. al. Standards Track [Page 29] + +RFC 2138 RADIUS April 1997 + + + A summary of the Framed-IP-Netmask 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 9 for Framed-IP-Netmask. + + Length + + 6 + + Address + + The Address field is four octets specifying the IP netmask of the + user. + +5.10. Framed-Routing + + Description + + This Attribute indicates the routing method for the user, when the + user is a router to a network. It is only used in Access-Accept + packets. + + A summary of the Framed-Routing 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 + + 10 for Framed-Routing. + + + + + +Rigney, et. al. Standards Track [Page 30] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 Send routing packets + 2 Listen for routing packets + 3 Send and Listen + +5.11. Filter-Id + + Description + + This Attribute indicates the name of the filter list for this + user. Zero or more Filter-Id attributes MAY be sent in an + Access-Accept packet. + + Identifying a filter list by name allows the filter to be used on + different NASes without regard to filter-list implementation + details. + + A summary of the Filter-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 11 for Filter-Id. + + Length + + >= 3 + + + + + + + + + + +Rigney, et. al. Standards Track [Page 31] + +RFC 2138 RADIUS April 1997 + + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain displayable ASCII characters from the range 32 + through 126 decimal. + +5.12. Framed-MTU + + Description + + This Attribute indicates the Maximum Transmission Unit to be + configured for the user, when it is not negotiated by some other + means (such as PPP). It is only used in Access-Accept packets. + + A summary of the Framed-MTU 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 + + 12 for Framed-MTU. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 64 to 65535. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 32] + +RFC 2138 RADIUS April 1997 + + +5.13. Framed-Compression + + Description + + This Attribute indicates a compression protocol to be used for the + link. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint to the server that the NAS + would prefer to use that compression, but the server is not + required to honor the hint. + + More than one compression protocol Attribute MAY be sent. It is + the responsibility of the NAS to apply the proper compression + protocol to appropriate link traffic. + + A summary of the Framed-Compression 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 + + 13 for Framed-Compression. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 VJ TCP/IP header compression [5] + 2 IPX header compression + +5.14. Login-IP-Host + + Description + + This Attribute indicates the system with which to connect the + user, when the Login-Service Attribute is included. It MAY be + used in Access-Accept packets. It MAY be used in an Access- + + + +Rigney, et. al. Standards Track [Page 33] + +RFC 2138 RADIUS April 1997 + + + Request packet as a hint to the server that the NAS would prefer + to use that host, but the server is not required to honor the + hint. + + A summary of the Login-IP-Host 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 14 for Login-IP-Host. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS SHOULD allow the user to select an address. The + value 0 indicates that the NAS SHOULD select a host to connect the + user to. Other values indicate the address the NAS SHOULD connect + the user to. + +5.15. Login-Service + + Description + + This Attribute indicates the service which should be used to + connect the user to the login host. It is only used in Access- + Accept packets. + + A summary of the Login-Service Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + +Rigney, et. al. Standards Track [Page 34] + +RFC 2138 RADIUS April 1997 + + + 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 + + 15 for Login-Service. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Telnet + 1 Rlogin + 2 TCP Clear + 3 PortMaster (proprietary) + 4 LAT + +5.16. Login-TCP-Port + + Description + + This Attribute indicates the TCP port with which the user is to be + connected, when the Login-Service Attribute is also present. It + is only used in Access-Accept packets. + + A summary of the Login-TCP-Port 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 + + 16 for Login-TCP-Port. + + + +Rigney, et. al. Standards Track [Page 35] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + +5.17. (unassigned) + + Description + + ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. + +5.18. Reply-Message + + Description + + This Attribute indicates text which MAY be displayed to the user. + + When used in an Access-Accept, it is the success message. + + When used in an Access-Reject, it is the failure message. It MAY + indicate a dialog message to prompt the user before another + Access-Request attempt. + + When used in an Access-Challenge, it MAY indicate a dialog message + to prompt the user for a response. + + Multiple Reply-Message's MAY be included and if any are displayed, + they MUST be displayed in the same order as they appear in the + packet. + + A summary of the Reply-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 18 for Reply-Message. + + + + +Rigney, et. al. Standards Track [Page 36] + +RFC 2138 RADIUS April 1997 + + + Length + + >= 3 + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters from the + range 10, 13, and 32 through 126 decimal. Mechanisms for + extension to other character sets are beyond the scope of this + specification. + +5.19. Callback-Number + + Description + + This Attribute indicates a dialing string to be used for callback. + It MAY be used in Access-Accept packets. It MAY be used in an + Access-Request packet as a hint to the server that a Callback + service is desired, but the server is not required to honor the + hint. + + A summary of the Callback-Number 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 19 for Callback-Number. + + Length + + >= 3 + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 37] + +RFC 2138 RADIUS April 1997 + + + 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. + +5.20. Callback-Id + + Description + + This Attribute indicates the name of a place to be called, to be + interpreted by the NAS. It MAY be used in Access-Accept packets. + + A summary of the Callback-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 20 for Callback-Id. + + 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. + +5.21. (unassigned) + + Description + + ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. + + + + + +Rigney, et. al. Standards Track [Page 38] + +RFC 2138 RADIUS April 1997 + + +5.22. Framed-Route + + Description + + This Attribute provides routing information to be configured for + the user on the NAS. It is used in the Access-Accept packet and + can appear multiple times. + + A summary of the Framed-Route 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 + + 22 for Framed-Route. + + Length + + >= 3 + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain displayable ASCII characters from the range 32 + through 126 decimal. + + For IP routes, it SHOULD contain a destination prefix in dotted + quad form optionally followed by a slash and a decimal length + specifier stating how many high order bits of the prefix should be + used. That is followed by a space, a gateway address in dotted + quad form, a space, and one or more metrics separated by spaces. + For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length + specifier may be omitted in which case it should default to 8 bits + for class A prefixes, 16 bits for class B prefixes, and 24 bits + for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". + + Whenever the gateway address is specified as "0.0.0.0" the IP + address of the user SHOULD be used as the gateway address. + + + + + + +Rigney, et. al. Standards Track [Page 39] + +RFC 2138 RADIUS April 1997 + + +5.23. Framed-IPX-Network + + Description + + This Attribute indicates the IPX Network number to be configured + for the user. It is used in Access-Accept packets. + + A summary of the Framed-IPX-Network 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 + + 23 for Framed-IPX-Network. + + Length + + 6 + + Value + + The Value field is four octets. The value 0xFFFFFFFE indicates + that the NAS should select an IPX network for the user (e.g. + assigned from a pool of one or more IPX networks kept by the NAS). + Other values should be used as the IPX network for the link to the + user. + +5.24. State + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Challenge and MUST be sent unmodified from the client + to the server in the new Access-Request reply to that challenge, + if any. + + + + + + + + + +Rigney, et. al. Standards Track [Page 40] + +RFC 2138 RADIUS April 1997 + + + This Attribute is available to be sent by the server to the client + in an Access-Accept that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the NAS performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + attribute unchanged in that Access-Request. + + In either usage, no interpretation by the client should be made. + A packet may have only one State Attribute. Usage of the State + Attribute is implementation dependent. + + A summary of the State 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 24 for State. + + 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. + +5.25. Class + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Accept and should be sent unmodified by the client to + the accounting server as part of the Accounting-Request packet if + accounting is supported. No interpretation by the client should + be made. + + + + + +Rigney, et. al. Standards Track [Page 41] + +RFC 2138 RADIUS April 1997 + + + A summary of the Class 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 25 for Class. + + 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. + +5.26. Vendor-Specific + + Description + + This Attribute is available to allow vendors to support their own + extended Attributes not suitable for general usage. It MUST not + affect the operation of the RADIUS protocol. + + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do + so (and report they are doing so) in a degraded mode. + + A summary of the Vendor-Specific Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + +Rigney, et. al. Standards Track [Page 42] + +RFC 2138 RADIUS April 1997 + + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 26 for Vendor-Specific. + + Length + + >= 7 + + Vendor-Id + + The high-order octet is 0 and the low-order 3 octets are the SMI + Network Management Private Enterprise Code of the Vendor in + network byte order, as defined in the Assigned Numbers RFC [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. + + It SHOULD be encoded as a sequence of vendor type / vendor length + / value fields, as follows. The Attribute-Specific field is + dependent on the vendor's definition of that attribute. An + example encoding of the Vendor-Specific attribute using this + method follows: + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | Vendor type | Vendor length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Specific... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + +Rigney, et. al. Standards Track [Page 43] + +RFC 2138 RADIUS April 1997 + + +5.27. Session-Timeout + + Description + + This Attribute sets the maximum number of seconds of service to be + provided to the user before termination of the session or prompt. + This Attribute is available to be sent by the server to the client + in an Access-Accept or Access-Challenge. + + A summary of the Session-Timeout 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 + + 27 for Session-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of seconds this user should be allowed to + remain connected by the NAS. + +5.28. Idle-Timeout + + Description + + This Attribute sets the maximum number of consecutive seconds of + idle connection allowed to the user before termination of the + session or prompt. This Attribute is available to be sent by the + server to the client in an Access-Accept or Access-Challenge. + + + + + + + + + +Rigney, et. al. Standards Track [Page 44] + +RFC 2138 RADIUS April 1997 + + + A summary of the Idle-Timeout 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 + + 28 for Idle-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of consecutive seconds of idle time this user + should be permitted before being disconnected by the NAS. + +5.29. Termination-Action + + Description + + This Attribute indicates what action the NAS should take when the + specified service is completed. It is only used in Access-Accept + packets. + + A summary of the Termination-Action 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 + + 29 for Termination-Action. + + + + +Rigney, et. al. Standards Track [Page 45] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Default + 1 RADIUS-Request + + If the Value is set to RADIUS-Request, upon termination of the + specified service the NAS MAY send a new Access-Request to the + RADIUS server, including the State attribute if any. + +5.30. Called-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the user called, using Dialed Number + Identification (DNIS) or similar technology. Note that this may be + different from the phone number the call comes in on. It is only + used in Access-Request packets. + + A summary of the Called-Station-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 30 for Called-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user's call came in on. + + + + +Rigney, et. al. Standards Track [Page 46] + +RFC 2138 RADIUS April 1997 + + + The actual format of the information is site or application + specific. Printable ASCII is recommended, but 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. + +5.31. Calling-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the call came from, using Automatic Number + Identification (ANI) or similar technology. It is only used in + Access-Request packets. + + A summary of the Calling-Station-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 31 for Calling-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user placed the call from. + + The actual format of the information is site or application + specific. Printable ASCII is recommended, but 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. Standards Track [Page 47] + +RFC 2138 RADIUS April 1997 + + +5.32. NAS-Identifier + + Description + + This Attribute contains a string identifying the NAS originating + the Access-Request. It is only used in Access-Request packets. + Either NAS-IP-Address or NAS-Identifier SHOULD be present in an + Access-Request packet. + + A summary of the NAS-Identifier 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 32 for NAS-Identifier. + + Length + + >= 3 + + String + + The String field is one or more octets, and should be unique to + the NAS within the scope of the RADIUS server. For example, a + fully qualified domain name would be suitable as a NAS-Identifier. + + 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. + +5.33. Proxy-State + + Description + + This Attribute is available to be sent by a proxy server to + another server when forwarding an Access-Request and MUST be + returned unmodified in the Access-Accept, Access-Reject or + Access-Challenge. This attribute should be removed by the proxy + server before the response is forwarded to the NAS. + + + +Rigney, et. al. Standards Track [Page 48] + +RFC 2138 RADIUS April 1997 + + + Usage of the Proxy-State Attribute is implementation dependent. A + description of its function is outside the scope of this + specification. + + A summary of the Proxy-State 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 33 for Proxy-State. + + 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. + +5.34. Login-LAT-Service + + Description + + This Attribute indicates the system with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + Administrators use the service attribute when dealing with + clustered systems, such as a VAX or Alpha cluster. In such an + environment several different time sharing hosts share the same + resources (disks, printers, etc.), and administrators often + configure each to offer access (service) to each of the shared + resources. In this case, each host in the cluster advertises its + services through LAT broadcasts. + + + + +Rigney, et. al. Standards Track [Page 49] + +RFC 2138 RADIUS April 1997 + + + Sophisticated users often know which service providers (machines) + are faster and tend to use a node name when initiating a LAT + connection. Alternately, some administrators want particular + users to use certain machines as a primitive form of load + balancing (although LAT knows how to do load balancing itself). + + A summary of the Login-LAT-Service 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 34 for Login-LAT-Service. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT service to use. The LAT Architecture allows this + string to contain $ (dollar), - (hyphen), . (period), _ + (underscore), numerics, upper and lower case alphabetics, and the + ISO Latin-1 character set extension [6]. All LAT string + comparisons are case insensitive. + +5.35. Login-LAT-Node + + Description + + This Attribute indicates the Node with which the user is to be + automatically connected by LAT. It MAY be used in Access-Accept + packets, but only when LAT is specified as the Login-Service. It + MAY be used in an Access-Request packet as a hint to the server, + but the server is not required to honor the hint. + + A summary of the Login-LAT-Node Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Rigney, et. al. Standards Track [Page 50] + +RFC 2138 RADIUS April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 35 for Login-LAT-Node. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT Node to connect the user to. The LAT Architecture + allows this string to contain $ (dollar), - (hyphen), . (period), + _ (underscore), numerics, upper and lower case alphabetics, and + the ISO Latin-1 character set extension. All LAT string + comparisons are case insensitive. + +5.36. Login-LAT-Group + + Description + + This Attribute contains a string identifying the LAT group codes + which this user is authorized to use. It MAY be used in Access- + Accept packets, but only when LAT is specified as the Login- + Service. It MAY be used in an Access-Request packet as a hint to + the server, but the server is not required to honor the hint. + + LAT supports 256 different group codes, which LAT uses as a form + of access rights. LAT encodes the group codes as a 256 bit + bitmap. + + Administrators can assign one or more of the group code bits at + the LAT service provider; it will only accept LAT connections that + have these group codes set in the bit map. The administrators + assign a bitmap of authorized group codes to each user; LAT gets + these from the operating system, and uses these in its requests to + the service providers. + + + + + + + + +Rigney, et. al. Standards Track [Page 51] + +RFC 2138 RADIUS April 1997 + + + A summary of the Login-LAT-Group 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 36 for Login-LAT-Group. + + Length + + 34 + + String + + The String field is a 32 octet bit map, most significant octet + first. 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. + +5.37. Framed-AppleTalk-Link + + Description + + This Attribute indicates the AppleTalk network number which should + be used for the serial link to the user, which is another + AppleTalk router. It is only used in Access-Accept packets. It + is never used when the user is not another router. + + A summary of the Framed-AppleTalk-Link 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Rigney, et. al. Standards Track [Page 52] + +RFC 2138 RADIUS April 1997 + + + Type + + 37 for Framed-AppleTalk-Link. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value of 0 indicates + that this is an unnumbered serial link. A value of 1-65535 means + that the serial line between the NAS and the user should be + assigned that value as an AppleTalk network number. + +5.38. Framed-AppleTalk-Network + + Description + + This Attribute indicates the AppleTalk Network number which the + NAS should probe to allocate an AppleTalk node for the user. It + is only used in Access-Accept packets. It is never used when the + user is another router. Multiple instances of this Attribute + indicate that the NAS may probe using any of the network numbers + specified. + + A summary of the Framed-AppleTalk-Network 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 + + 38 for Framed-AppleTalk-Network. + + Length + + 6 + + + + + + +Rigney, et. al. Standards Track [Page 53] + +RFC 2138 RADIUS April 1997 + + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value 0 indicates that + the NAS should assign a network for the user, using its default + cable range. A value between 1 and 65535 (inclusive) indicates + the AppleTalk Network the NAS should probe to find an address for + the user. + +5.39. Framed-AppleTalk-Zone + + Description + + This Attribute indicates the AppleTalk Default Zone to be used for + this user. It is only used in Access-Accept packets. Multiple + instances of this attribute in the same packet are not allowed. + + A summary of the Framed-AppleTalk-Zone 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 4 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 39 for Framed-AppleTalk-Zone. + + Length + + >= 3 + + String + + The name of the Default AppleTalk Zone to be used for this user. + 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. Standards Track [Page 54] + +RFC 2138 RADIUS April 1997 + + +5.40. CHAP-Challenge + + Description + + This Attribute contains the CHAP Challenge sent by the NAS to a + PPP Challenge-Handshake Authentication Protocol (CHAP) user. It + is only used in Access-Request packets. + + If the CHAP challenge value is 16 octets long it MAY be placed in + the Request Authenticator field instead of using this attribute. + + A summary of the CHAP-Challenge 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 + + 60 for CHAP-Challenge. + + Length + + >= 7 + + String + + The String field contains the CHAP Challenge. + +5.41. NAS-Port-Type + + Description + + This Attribute indicates the type of the physical port of the NAS + which is authenticating the user. It can be used instead of or in + addition to the NAS-Port (5) attribute. It is only used in + Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or + both SHOULD be present in an Access-Request packet, if the NAS + differentiates among its ports. + + + + + + + + + +Rigney, et. al. Standards Track [Page 55] + +RFC 2138 RADIUS April 1997 + + + A summary of the NAS-Port-Type 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 + + 61 for NAS-Port-Type. + + Length + + 6 + + Value + + The Value field is four octets. "Virtual" refers to a connection + to the NAS via some transport protocol, instead of through a + physical port. For example, if a user telnetted into a NAS to + authenticate himself as an Outbound-User, the Access-Request might + include NAS-Port-Type = Virtual as a hint to the RADIUS server + that the user was not on a physical port. + + 0 Async + 1 Sync + 2 ISDN Sync + 3 ISDN Async V.120 + 4 ISDN Async V.110 + 5 Virtual + +5.42. Port-Limit + + Description + + This Attribute sets the maximum number of ports to be provided to + the user by the NAS. This Attribute MAY be sent by the server to + the client in an Access-Accept packet. It is intended for use in + conjunction with Multilink PPP [7] or similar uses. It MAY also + be sent by the NAS to the server as a hint that that many ports + are desired for use, but the server is not required to honor the + hint. + + + + + +Rigney, et. al. Standards Track [Page 56] + +RFC 2138 RADIUS April 1997 + + + A summary of the Port-Limit 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 + + 62 for Port-Limit. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of ports this user should be allowed to connect + to on the NAS. + +5.43. Login-LAT-Port + + Description + + This Attribute indicates the Port with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + A summary of the Login-LAT-Port 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 63 for Login-LAT-Port. + + + + +Rigney, et. al. Standards Track [Page 57] + +RFC 2138 RADIUS April 1997 + + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT port to use. The LAT Architecture allows this string + to contain $ (dollar), - (hyphen), . (period), _ (underscore), + numerics, upper and lower case alphabetics, and the ISO Latin-1 + character set extension. All LAT string comparisons are case + insensitive. + +5.44. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge # Attribute + 1 0 0 0 1 User-Name + 0-1 0 0 0 2 User-Password [Note 1] + 0-1 0 0 0 3 CHAP-Password [Note 1] + 0-1 0 0 0 4 NAS-IP-Address + 0-1 0 0 0 5 NAS-Port + 0-1 0-1 0 0 6 Service-Type + 0-1 0-1 0 0 7 Framed-Protocol + 0-1 0-1 0 0 8 Framed-IP-Address + 0-1 0-1 0 0 9 Framed-IP-Netmask + 0 0-1 0 0 10 Framed-Routing + 0 0+ 0 0 11 Filter-Id + 0 0-1 0 0 12 Framed-MTU + 0+ 0+ 0 0 13 Framed-Compression + 0+ 0+ 0 0 14 Login-IP-Host + 0 0-1 0 0 15 Login-Service + 0 0-1 0 0 16 Login-TCP-Port + 0 0+ 0+ 0+ 18 Reply-Message + 0-1 0-1 0 0 19 Callback-Number + 0 0-1 0 0 20 Callback-Id + 0 0+ 0 0 22 Framed-Route + 0 0-1 0 0 23 Framed-IPX-Network + 0-1 0-1 0 0-1 24 State + 0 0+ 0 0 25 Class + 0+ 0+ 0 0+ 26 Vendor-Specific + 0 0-1 0 0-1 27 Session-Timeout + 0 0-1 0 0-1 28 Idle-Timeout + 0 0-1 0 0 29 Termination-Action + 0-1 0 0 0 30 Called-Station-Id + 0-1 0 0 0 31 Calling-Station-Id + + + +Rigney, et. al. Standards Track [Page 58] + +RFC 2138 RADIUS April 1997 + + + 0-1 0 0 0 32 NAS-Identifier + 0+ 0+ 0+ 0+ 33 Proxy-State + 0-1 0-1 0 0 34 Login-LAT-Service + 0-1 0-1 0 0 35 Login-LAT-Node + 0-1 0-1 0 0 36 Login-LAT-Group + 0 0-1 0 0 37 Framed-AppleTalk-Link + 0 0+ 0 0 38 Framed-AppleTalk-Network + 0 0-1 0 0 39 Framed-AppleTalk-Zone + 0-1 0 0 0 60 CHAP-Challenge + 0-1 0 0 0 61 NAS-Port-Type + 0-1 0-1 0 0 62 Port-Limit + 0-1 0-1 0 0 63 Login-LAT-Port + + + Request Accept Reject Challenge # Attribute + + + [Note 1] An Access-Request MUST contain either a User-Password or a + CHAP-Password, and MUST NOT contain both. + + The following table defines the meaning of the above table entries. + + 0 This attribute MUST NOT be present in packet. + 0+ Zero or more instances of this attribute MAY be present in packet. + 0-1 Zero or one instance of this attribute MAY be present in packet. + 1 Exactly one instance of this attribute MUST be present in packet. + +6. Examples + + A few examples are presented to illustrate the flow of packets and + use of typical attributes. These examples are not intended to be + exhaustive, many others are possible. + + + + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 59] + +RFC 2138 RADIUS April 1997 + + +6.1. User Telnet to Specified Host + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named nemo logging in on port 3. + + Code = 1 (Access-Request) + ID = 0 + Length = 56 + Request Authenticator = {16 octet random number} + Attributes: + User-Name = "nemo" + User-Password = {16 octets of Password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator)} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 3 + + The RADIUS server authenticates nemo, and sends an Access-Accept UDP + packet to the NAS telling it to telnet nemo to host 192.168.1.3. + + Code = 2 (Access-Accept) + ID = 0 (same as in Access-Request) + Length = 38 + Response Authenticator = {16-octet MD-5 checksum of the code (2), + id (0), Length (38), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Service-Type = Login-User + Login-Service = Telnet + Login-Host = 192.168.1.3 + +6.2. Framed User Authenticating with CHAP + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named flopsy logging in on port 20 with PPP, + authenticating using CHAP. The NAS sends along the Service-Type and + Framed-Protocol attributes as a hint to the RADIUS server that this + user is looking for PPP, although the NAS is not required to do so. + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 60] + +RFC 2138 RADIUS April 1997 + + + Code = 1 (Access-Request) + ID = 1 + Length = 71 + Request Authenticator = {16 octet random number also used as + CHAP challenge} + Attributes: + User-Name = "flopsy" + CHAP-Password = {1 octet CHAP ID followed by 16 octet + CHAP response} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 20 + Service-Type = Framed-User + Framed-Protocol = PPP + + The RADIUS server authenticates flopsy, and sends an Access-Accept + UDP packet to the NAS telling it to start PPP service and assign an + address for the user out of its dynamic address pool. + + Code = 2 (Access-Accept) + ID = 1 (same as in Access-Request) + Length = 56 + Response Authenticator = {16-octet MD-5 checksum of the code (2), + id (1), Length (56), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Service-Type = Framed-User + Framed-Protocol = PPP + Framed-IP-Address = 255.255.255.254 + Framed-Routing = None + Framed-Compression = 1 (VJ TCP/IP Header Compression) + Framed-MTU = 1500 + +6.3. User with Challenge-Response card + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named mopsy logging in on port 7. + + Code = 1 (Access-Request) + ID = 2 + Length = 57 + Request Authenticator = {16 octet random number} + Attributes: + User-Name = "mopsy" + User-Password = {16 octets of Password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator)} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 7 + + + +Rigney, et. al. Standards Track [Page 61] + +RFC 2138 RADIUS April 1997 + + + The RADIUS server decides to challenge mopsy, sending back a + challenge string and looking for a response. The RADIUS server + therefore and sends an Access-Challenge UDP packet to the NAS. + + Code = 11 (Access-Challenge} + ID = 2 (same as in Access-Request) + Length = 78 + Response Authenticator = {16-octet MD-5 checksum of the code (11), + id (2), length (78), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Reply-Message = "Challenge 32769430. Enter response at prompt." + State = {Magic Cookie to be returned along with user's response; + in this example 8 octets of data} + + The user enters his response, and the NAS send a new Access-Request + with that response, and includes the State Attribute. + + Code = 1 (Access-Request) + ID = 3 (Note that this changes) + Length = 67 + Request Authenticator = {NEW 16 octet random number} + Attributes: + User-Name = "mopsy" + User-Password = {16 octets of Response padded at end with + nulls, XORed with MD5 checksum of shared secret + plus above Request Authenticator} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 7 + State = {Magic Cookie from Access-Challenge packet, unchanged} + + The Response was incorrect, so the RADIUS server tells the NAS to + reject the login attempt. + + Code = 3 (Access-Reject) + ID = 3 (same as in Access-Request) + Length = 20 + Response Authenticator = {16-octet MD-5 checksum of the code (3), + id (3), length(20), the Request Authenticator from + above, the attributes in this reply if any, and the + shared secret} + Attributes: + (none, although a Reply-Message could be sent) + + + + + + + +Rigney, et. al. Standards Track [Page 62] + +RFC 2138 RADIUS April 1997 + + +Security Considerations + + Security issues are the primary topic of this document. + + In practice, within or associated with each RADIUS server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set. Instead, for each named user there should + be an indication of exactly one method used to authenticate that user + name. If a user needs to make use of different authentication + methods under different circumstances, then distinct user names + SHOULD be employed, each of which identifies exactly one + authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. It is possible to achieve this with SNMP Security + Protocols [8], but such a mechanism is outside the scope of this + specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document [8] also has an + excellent overview of threats to network protocols. + + + + + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 63] + +RFC 2138 RADIUS April 1997 + + +References + + [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, RSA Data + Security Inc., April 1992. + + [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: + Private Communications in a Public World", Prentice Hall, March + 1995, ISBN 0-13-061466-1. + + [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial + links", RFC 1144, Lawrence Berkeley Laboratory, February 1990. + + [6] ISO 8859. International Standard -- Information Processing -- + 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin + Alphabet No. 1, ISO 8859-1:1987. + + + [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP + Multilink Protocol (MP)", RFC 1717, University of California + Berkeley, Lloyd Internetworking, Newbridge Networks + Corporation, November 1994. + + [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security + Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes + LAN Systems, Inc., MIT Laboratory for Computer Science, July + 1992. + + [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. + +Acknowledgments + + RADIUS was originally developed by Livingston Enterprises for their + PortMaster series of Network Access Servers. + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 64] + +RFC 2138 RADIUS April 1997 + + +Chair's Address + + The working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + +Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + + Allan C. Rubens + Merit Network, Inc. + 4251 Plymouth Road + Ann Arbor, Michigan 48105-2785 + + EMail: acr@merit.edu + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: wsimpson@greendragon.com + + Steve Willens + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: steve@livingston.com + + + + + + +Rigney, et. al. Standards Track [Page 65] + diff --git a/doc/rfc2139.txt b/doc/rfc2139.txt new file mode 100644 index 0000000..88c5af8 --- /dev/null +++ b/doc/rfc2139.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2139 Livingston +Obsoletes: 2059 April 1997 +Category: Informational + + + RADIUS Accounting + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes a protocol for carrying accounting + information between a Network Access Server and a shared Accounting + Server. + +Implementation Note + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 3 + 1.2 Terminology ..................................... 3 + 2. Operation ............................................. 4 + 3. Packet Format ......................................... 5 + 4. Packet Types .......................................... 7 + 4.1 Accounting-Request .............................. 7 + 4.2 Accounting-Response ............................. 8 + 5. Attributes ............................................ 10 + 5.1 Acct-Status-Type ................................ 11 + 5.2 Acct-Delay-Time ................................. 12 + 5.3 Acct-Input-Octets ............................... 13 + 5.4 Acct-Output-Octets .............................. 14 + 5.5 Acct-Session-Id ................................. 14 + 5.6 Acct-Authentic .................................. 15 + 5.7 Acct-Session-Time ............................... 16 + 5.8 Acct-Input-Packets .............................. 16 + + + +Rigney Informational [Page 1] + +RFC 2139 RADIUS Accounting April 1997 + + + 5.9 Acct-Output-Packets ............................. 17 + 5.10 Acct-Terminate-Cause ............................ 18 + 5.11 Acct-Multi-Session-Id ........................... 20 + 5.12 Acct-Link-Count ................................. 21 + 5.13 Table of Attributes ............................. 22 + Security Considerations ...................................... 24 + References ................................................... 24 + Acknowledgements ............................................. 24 + Chair's Address .............................................. 24 + Author's Address ............................................. 25 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + The RADIUS (Remote Authentication Dial In User Service) document [4] + specifies the RADIUS protocol used for Authentication and + Authorization. This memo extends the use of the RADIUS protocol to + cover delivery of accounting information from the Network Access + Server (NAS) to a RADIUS accounting server. + + Key features of RADIUS Accounting are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of the + RADIUS accounting server. The client is responsible for + passing user accounting information to a designated RADIUS + accounting server. + + The RADIUS accounting server is responsible for receiving the + accounting request and returning a response to the client + indicating that it has successfully received the request. + + The RADIUS accounting server can act as a proxy client to other + kinds of accounting servers. + + + + + + + + +Rigney Informational [Page 2] + +RFC 2139 RADIUS Accounting April 1997 + + + Network Security + + Transactions between the client and RADIUS accounting server + are authenticated through the use of a shared secret, which is + never sent over the network. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added + without disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + +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. + + + + + + + + + + +Rigney Informational [Page 3] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + 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 with + its own Acct-Session-Id. + + 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 + + When a client is configured to use RADIUS Accounting, at the start of + service delivery it will generate an Accounting Start packet + describing the type of service being delivered and the user it is + being delivered to, and will send that to the RADIUS Accounting + server, which will send back an acknowledgement that the packet has + been received. At the end of service delivery the client will + generate an Accounting Stop packet describing the type of service + that was delivered and optionally statistics such as elapsed time, + input and output octets, or input and output packets. It will send + that to the RADIUS Accounting server, which will send back an + acknowledgement that the packet has been received. + + The Accounting-Request (whether for Start or Stop) is submitted to + the RADIUS accounting server via the network. It is recommended that + the client continue attempting to send the Accounting-Request packet + until it receives an acknowledgement, using some form of backoff. If + no response is returned within a length of time, the request is re- + sent a number of times. The client can also forward requests to an + alternate server or servers in the event that the primary server is + down or unreachable. An alternate server can be used either after a + number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + The RADIUS accounting server MAY make requests of other servers in + order to satisfy the request, in which case it acts as a client. + + If the RADIUS accounting server is unable to successfully record the + accounting packet it MUST NOT send an Accounting-Response + acknowledgment to the client. + + + +Rigney Informational [Page 4] + +RFC 2139 RADIUS Accounting April 1997 + + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [1], where the UDP Destination Port field indicates 1813 + (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + + A summary of the RADIUS data 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Code | Identifier | Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +| Authenticator | +| | +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attributes ... ++-+-+-+-+-+-+-+-+-+-+-+-+- + + +Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it is + silently discarded. + + RADIUS Accounting Codes (decimal) are assigned as follows: + + 4 Accounting-Request + 5 Accounting-Response + +Identifier + + The Identifier field is one octet, and aids in matching requests and + replies. + + + +Rigney Informational [Page 5] + +RFC 2139 RADIUS Accounting April 1997 + + +Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + should be treated as padding and should be ignored on reception. If + the packet is shorter than the Length field indicates, it should be + silently discarded. The minimum length is 20 and maximum length is + 4096. + +Authenticator + + The Authenticator field is sixteen (16) octets. The most significant + octet is transmitted first. This value is used to authenticate the + messages between the client and RADIUS accounting server. + +Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 octet + MD5 [3] checksum, called the Request Authenticator. + + The NAS and RADIUS accounting server share a secret. The Request + Authenticator field in Accounting-Request packets contains a one- way + MD5 hash calculated over a stream of octets consisting of the Code + + Identifier + Length + 16 zero octets + request attributes + shared + secret (where + indicates concatenation). The 16 octet MD5 hash + value is stored in the Authenticator field of the Accounting-Request + packet. + + Note that the Request Authenticator of an Accounting-Request can + not be done the same way as the Request Authenticator of a RADIUS + Access-Request, because there is no User-Password attribute in an + Accounting-Request. + +Response Authenticator + + The Authenticator field in an Accounting-Response packet is called + the Response Authenticator, and contains a one-way MD5 hash + calculated over a stream of octets consisting of the Accounting- + Response Code, Identifier, Length, the Request Authenticator field + from the Accounting-Request packet being replied to, and the response + attributes if any, followed by the shared secret. The resulting 16 + octet MD5 hash value is stored in the Authenticator field of the + Accounting-Response packet. + + + + + + + +Rigney Informational [Page 6] + +RFC 2139 RADIUS Accounting April 1997 + + +Attributes + + Attributes may have multiple instances, in such a case the order of + attributes of the same type SHOULD be preserved. The order of + attributes of different types is not required to be preserved. + +4. Packet Types + + The RADIUS packet type is determined by the Code field in the first + octet of the packet. + +4.1. Accounting-Request + + Description + + Accounting-Request packets are sent from a client (typically a + Network Access Server or its proxy) to a RADIUS accounting server, + and convey information used to provide accounting for a service + provided to a user. The client transmits a RADIUS packet with the + Code field set to 4 (Accounting-Request). + + Upon receipt of an Accounting-Request, the server MUST transmit an + Accounting-Response reply if it successfully records the + accounting packet, and MUST NOT transmit any reply if it fails to + record the accounting packet. + + Any attribute valid in a RADIUS Access-Request or Access-Accept + packet is valid in a RADIUS Accounting-Request packet, except that + the following attributes MUST NOT be present in an Accounting- + Request: User-Password, CHAP-Password, Reply-Message, State. + Either NAS-IP-Address or NAS-Identifier MUST be present in a + RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- + Port-Type attribute or both unless the service does not involve a + port or the NAS does not distinguish among its ports. + + A summary of the Accounting-Request packet format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 4 for Accounting-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + Note that if Acct-Delay-Time is included in the attributes of an + Accounting-Request then the Acct-Delay-Time value will be updated + when the packet is retransmitted, changing the content of the + Attributes field and requiring a new Identifier and Request + Authenticator. + + Request Authenticator + + The Request Authenticator of an Accounting-Request contains a 16- + octet MD5 hash value calculated according to the method described + in "Request Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + Attributes. + +4.2. Accounting-Response + + Description + + Accounting-Response packets are sent by the RADIUS accounting + server to the client to acknowledge that the Accounting-Request + has been received and recorded successfully. If the Accounting- + + + +Rigney Informational [Page 8] + +RFC 2139 RADIUS Accounting April 1997 + + + Request was recorded successfully then the RADIUS accounting + server MUST transmit a packet with the Code field set to 5 + (Accounting-Response). On reception of an Accounting-Response by + the client, the Identifier field is matched with a pending + Accounting-Request. Invalid packets are silently discarded. + + A RADIUS Accounting-Response is not required to have any + attributes in it. + + A summary of the Accounting-Response packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 5 for Accounting-Response. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Accounting-Request which caused this Accounting-Response. + + Response Authenticator + + The Response Authenticator of an Accounting-Response contains a + 16-octet MD5 hash value calculated according to the method + described in "Response Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney Informational [Page 9] + +RFC 2139 RADIUS Accounting April 1997 + + +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 end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the 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 | 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 [2]. + 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 RADIUS document [4]) + 40 Acct-Status-Type + 41 Acct-Delay-Time + 42 Acct-Input-Octets + 43 Acct-Output-Octets + 44 Acct-Session-Id + 45 Acct-Authentic + 46 Acct-Session-Time + 47 Acct-Input-Packets + 48 Acct-Output-Packets + 49 Acct-Terminate-Cause + 50 Acct-Multi-Session-Id + 51 Acct-Link-Count + 60+ (refer to RADIUS document [4]) + + + + + + + +Rigney Informational [Page 10] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 an Accounting-Request 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. + + The format of the value field is one of four data types. + + string 0-253 octets + + address 32 bit value, most significant octet first. + + integer 32 bit value, most significant octet first. + + time 32 bit value, most significant octet first -- seconds + since 00:00:00 GMT, January 1, 1970. The standard + Attributes do not use this data type but it is presented + here for possible use within Vendor-Specific attributes. + +5.1. Acct-Status-Type + + Description + + This attribute indicates whether this Accounting-Request marks the + beginning of the user service (Start) or the end (Stop). + + It MAY be used by the client to mark the start of accounting (for + example, upon booting) by specifying Accounting-On and to mark the + end of accounting (for example, just before a scheduled reboot) by + specifying Accounting-Off. + + A summary of the Acct-Status-Type 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 11] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 7 Accounting-On + 8 Accounting-Off + +5.2. Acct-Delay-Time + + Description + + This attribute indicates how many seconds the client has been + trying to send this record for, and can be subtracted from the + time of arrival on the server to find the approximate time of the + event generating this Accounting-Request. (Network transit time + is ignored.) + + Note that changing the Acct-Delay-Time causes the Identifier to + change; see the discussion under Identifier above. + + A summary of the Acct-Delay-Time 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 + + 41 for Acct-Delay-Time. + + Length + + 6 + + + +Rigney Informational [Page 12] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + +5.3. Acct-Input-Octets + + Description + + This attribute indicates how many octets have been received from + the port 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. + + A summary of the Acct-Input-Octets 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 + + 42 for Acct-Input-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.4. Acct-Output-Octets + + Description + + This attribute indicates how many octets have been sent to the + port 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. + + A summary of the Acct-Output-Octets attribute format is shown below. + The fields are transmitted from left to right. + + + + +Rigney Informational [Page 13] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + + 43 for Acct-Output-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.5. Acct-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to match + start and stop records in a log file. The start and stop records + for a given session MUST have the same Acct-Session-Id. It is + strongly recommended that the Acct-Session-Id be a printable ASCII + string. + + For example, one implementation uses a string with an 8-digit + upper case hexadecimal number, the first two digits increment on + each reboot (wrapping every 256 reboots) and the next 6 digits + counting from 0 for the first person logging in after a reboot up + to 2^24-1, about 16 million. Other encodings are possible. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + +Rigney Informational [Page 14] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.6. Acct-Authentic + + Description + + This attribute MAY be included in an Accounting-Request to + indicate how the user was authenticated, whether by RADIUS, the + NAS itself, or another remote authentication protocol. Users who + are delivered service without being authenticated SHOULD NOT + generate Accounting records. + + A summary of the Acct-Authentic 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 + + 45 for Acct-Authentic. + + Length + + 6 + + + + + +Rigney Informational [Page 15] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + + 1 RADIUS + 2 Local + 3 Remote + +5.7. Acct-Session-Time + + Description + + This attribute indicates how many seconds the user has received + service for, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Session-Time 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 + + 46 for Acct-Session-Time. + + Length + + 6 + + Value + + The Value field is four octets. + +5.8. Acct-Input-Packets + + Description + + This attribute indicates how many packets have been received from + the port over the course of this service being provided to a + Framed User, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + + + +Rigney Informational [Page 16] + +RFC 2139 RADIUS Accounting April 1997 + + + A summary of the Acct-Input-packets 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 + + 47 for Acct-Input-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.9. Acct-Output-Packets + + Description + + This attribute indicates how many packets have been sent to the + port in the course of delivering this service to a Framed User, + and can only be present in Accounting-Request records where the + Acct-Status-Type is set to Stop. + + A summary of the Acct-Output-Packets 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 + + 48 for Acct-Output-Packets. + + + + + +Rigney Informational [Page 17] + +RFC 2139 RADIUS Accounting April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + +5.10. Acct-Terminate-Cause + + Description + + This attribute indicates how the session was terminated, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Terminate-Cause 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 + + 49 for Acct-Terminate-Cause + + Length + + 6 + + + + + + + + + + + + + + + + + +Rigney Informational [Page 18] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets, containing an integer specifying + the cause of session termination, as follows: + + 1 User Request + 2 Lost Carrier + 3 Lost Service + 4 Idle Timeout + 5 Session Timeout + 6 Admin Reset + 7 Admin Reboot + 8 Port Error + 9 NAS Error + 10 NAS Request + 11 NAS Reboot + 12 Port Unneeded + 13 Port Preempted + 14 Port Suspended + 15 Service Unavailable + 16 Callback + 17 User Error + 18 Host Request + + + + The termination causes are as follows: + + User Request User requested termination of service, for + example with LCP Terminate or by logging out. + + Lost Carrier DCD was dropped on the port. + + Lost Service Service can no longer be provided; for + example, user's connection to a host was + interrupted. + + Idle Timeout Idle timer expired. + + Session Timeout Maximum session length timer expired. + + Admin Reset Administrator reset the port or session. + + Admin Reboot Administrator is ending service on the NAS, + for example prior to rebooting the NAS. + + Port Error NAS detected an error on the port which + required ending the session. + + + +Rigney Informational [Page 19] + +RFC 2139 RADIUS Accounting April 1997 + + + NAS Error NAS detected some error (other than on the + port) which required ending the session. + + NAS Request NAS ended session for a non-error reason not + otherwise listed here. + + NAS Reboot The NAS ended the session in order to reboot + non-administratively ("crash"). + + Port Unneeded NAS ended session because resource usage fell + below low-water mark (for example, if a + bandwidth-on-demand algorithm decided that + the port was no longer needed). + + Port Preempted NAS ended session in order to allocate the + port to a higher priority use. + + Port Suspended NAS ended session to suspend a virtual + session. + + Service Unavailable NAS was unable to provide requested service. + + Callback NAS is terminating current session in order + to perform callback for a new session. + + User Error Input from user is in error, causing + termination of session. + + Host Request Login Host terminated session normally. + +5.11. Acct-Multi-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to link + together multiple related sessions in a log file. Each session + linked together would have a unique Acct-Session-Id but the same + Acct-Multi-Session-Id. It is strongly recommended that the Acct- + Multi-Session-Id be a printable ASCII string. + + A summary of the Acct-Session-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 | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 20] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.12. Acct-Link-Count + + Description + + This attribute gives the count of links which are known to have + been in a given multilink session at the time the accounting + record is generated. The NAS MAY include the Acct-Link-Count + attribute in any Accounting-Request which might have multiple + links. + + A summary of the Acct-Link-Count attribute format is show 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 + + 51 for Acct-Link-Count. + + Length + + 6 + + Value + + The Value field is four octets, and contains the number of links + seen so far in this Multilink Session. + + + + + + +Rigney Informational [Page 21] + +RFC 2139 RADIUS Accounting April 1997 + + + It may be used to make it easier for an accounting server to know + when it has all the records for a given Multilink session. When + the number of Accounting-Requests received with Acct-Status-Type = + Stop and the same Acct-Multi-Session-Id and unique Acct-Session- + Id's equals the largest value of Acct-Link-Count seen in those + Accounting-Requests, all Stop Accounting-Requests for that + Multilink Session have been received. + + An example showing 8 Accounting-Requests should make things + clearer. For clarity only the relevant attributes are shown, but + additional attributes containing accounting information will also + be present in the Accounting-Request. + + Multi-Session-Id Session-Id Status-Type Link-Count + "10" "10" Start 1 + "10" "11" Start 2 + "10" "11" Stop 2 + "10" "12" Start 3 + "10" "13" Start 4 + "10" "12" Stop 4 + "10" "13" Stop 4 + "10" "10" Stop 4 + +5.13. Table of Attributes + + The following table provides a guide to which attributes may be found + in Accounting-Request packets. No attributes should be found in + Accounting-Response packets except Proxy-State and possibly Vendor- + Specific. + + # Attribute + 0-1 User-Name + 0 User-Password + 0 CHAP-Password + 0-1 NAS-IP-Address [5] + 0-1 NAS-Port + 0-1 Service-Type + 0-1 Framed-Protocol + 0-1 Framed-IP-Address + 0-1 Framed-IP-Netmask + 0-1 Framed-Routing + 0+ Filter-Id + 0-1 Framed-MTU + 0+ Framed-Compression + 0+ Login-IP-Host + 0-1 Login-Service + 0-1 Login-TCP-Port + 0 Reply-Message + + + +Rigney Informational [Page 22] + +RFC 2139 RADIUS Accounting April 1997 + + + 0-1 Callback-Number + 0-1 Callback-Id + 0+ Framed-Route + 0-1 Framed-IPX-Network + 0 State + 0+ Class + 0+ Vendor-Specific + 0-1 Session-Timeout + 0-1 Idle-Timeout + 0-1 Termination-Action + 0-1 Called-Station-Id + 0-1 Calling-Station-Id + 0-1 NAS-Identifier [4] + 0+ Proxy-State + 0-1 Login-LAT-Service + 0-1 Login-LAT-Node + 0-1 Login-LAT-Group + 0-1 Framed-AppleTalk-Link + 0-1 Framed-AppleTalk-Network + 0-1 Framed-AppleTalk-Zone + 1 Acct-Status-Type + 0-1 Acct-Delay-Time + 0-1 Acct-Input-Octets + 0-1 Acct-Output-Octets + 1 Acct-Session-Id + 0-1 Acct-Authentic + 0-1 Acct-Session-Time + 0-1 Acct-Input-Packets + 0-1 Acct-Output-Packets + 0-1 Acct-Terminate-Cause + 0+ Acct-Multi-Session-Id + 0+ Acct-Link-Count + 0 CHAP-Challenge + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + + [5] An Accounting-Request MUST contain either a NAS-IP-Address or a + NAS-Identifier, and it is permitted (but not recommended) for it to + contain both. + + 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. + + + +Rigney Informational [Page 23] + +RFC 2139 RADIUS Accounting April 1997 + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +References + + [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, RSA Data + Security Inc., April 1992. + + [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, + April 1997. + +Acknowledgments + + RADIUS and RADIUS Accounting were originally developed by Livingston + Enterprises for their PortMaster series of Network Access Servers. + +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 510 426 0770 + EMail: cdr@livingston.com + + + + + + + + + + + + + +Rigney Informational [Page 24] + +RFC 2139 RADIUS Accounting April 1997 + + +Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@livingston.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 25] + diff --git a/doc/rfc2548.txt b/doc/rfc2548.txt new file mode 100644 index 0000000..35c83c3 --- /dev/null +++ b/doc/rfc2548.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2548 Microsoft Corporation +Category: Informational March 1999 + + + Microsoft Vendor-specific RADIUS Attributes + +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 (1999). All Rights Reserved. + +Abstract + + This document describes the set of Microsoft vendor-specific RADIUS + attributes. These attributes are designed to support Microsoft + proprietary dial-up protocols and/or provide support for features + which is not provided by the standard RADIUS attribute set [3]. It + is expected that this memo will be updated whenever Microsoft defines + a new vendor-specific attribute, since its primary purpose is to + provide an open, easily accessible reference for third-parties + wishing to interoperate with Microsoft products. + +1. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [2]. + +2. Attributes + + The following sections describe sub-attributes which may be + transmitted in one or more RADIUS attributes of type Vendor-Specific + [3]. More than one sub-attribute MAY be transmitted in a single + Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD + be packed as a sequence of Vendor-Type/Vendor-Length/Value triples + following the inital Type, Length and Vendor-ID fields. The Length + field of the Vendor-Specific Attribute MUST be set equal to the sum + of the Vendor-Length fields of the sub-attributes contained in the + Vendor-Specific Attribute, plus six. The Vendor-ID field of the + Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft). + + + + + +Zorn Informational [Page 1] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1. Attributes for Support of MS-CHAP Version 1 + +2.1.1. Introduction + + Microsoft created Microsoft Challenge-Handshake Authentication + Protocol (MS-CHAP) [4] to authenticate remote Windows workstations, + providing the functionality to which LAN-based users are accustomed. + Where possible, MS-CHAP is consistent with standard CHAP [5], and the + differences are easily modularized. Briefly, the differences between + MS-CHAP and standard CHAP are: + + * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP + option 3, Authentication Protocol. + + * The MS-CHAP Response packet is in a format designed for + compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, + Microsoft Windows95, and Microsoft LAN Manager 2.x networking + products. The MS-CHAP format does not require the authenticator + to store a clear-text or reversibly encrypted password. + + * MS-CHAP provides an authenticator-controlled authentication + retry mechanism. + + * MS-CHAP provides an authenticator-controlled password changing + mechanism. + + * MS-CHAP defines an extended set of reason-for-failure codes, + returned in the Failure packet Message field. + + The attributes defined in this section reflect these differences. + +2.1.2. MS-CHAP-Challenge + + Description + + This Attribute contains the challenge sent by a NAS to a Microsoft + Challenge-Handshake Authentication Protocol (MS-CHAP) user. It + MAY be used in both Access-Request and Access-Challenge packets. + + A summary of the MS-CHAP-Challenge Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + +Zorn Informational [Page 2] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 11 for MS-CHAP-Challenge. + + Vendor-Length + > 2 + + String + The String field contains the MS-CHAP challenge. + +2.1.3. MS-CHAP-Response + + Description + + This Attribute contains the response value provided by a PPP + Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) + user in response to the challenge. It is only used in Access- + Request packets. + + A summary of the MS-CHAP-Response Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 3] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response(cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 1 for MS-CHAP-Response. + + Vendor-Length + 52 + + Ident + Identical to the PPP CHAP Identifier. + + Flags + The Flags field is one octet in length. If the Flags field is one + (0x01), the NT-Response field is to be used in preference to the + LM-Response field for authentication. The LM-Response field MAY + still be used (if non-empty), but the NT-Response SHOULD be tried + first. If it is zero, the NT-Response field MUST be ignored and + the LM-Response field used. + + + + + +Zorn Informational [Page 4] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + + The NT-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + +2.1.4. MS-CHAP-Domain + + Description + + The MS-CHAP-Domain Attribute indicates the Windows NT domain in + which the user was authenticated. It MAY be included in both + Access-Accept and Accounting-Request packets. + + A summary of the MS-CHAP-Domain Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 10 for MS-CHAP-Domain. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains the name in ASCII of the Windows NT domain in + which the user was authenticated. + + + + + + + + + + +Zorn Informational [Page 5] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.5. MS-CHAP-Error + + Description + + The MS-CHAP-Error Attribute contains error data related to the + preceding MS-CHAP exchange. This Attribute may be used in both + MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used + in Access-Reject packets. + + A summary of the MS-CHAP-Error Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 2 for MS-CHAP-Error. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains specially formatted ASCII text, which is + interpreted by the authenticating peer. + +2.1.6. MS-CHAP-CPW-1 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in Access-Request packets, and + should only be included if an MS-CHAP-Error attribute was included in + the immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is less than 2. + + A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 6] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Old-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-New-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Old-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-New-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New-LM-Password-Length | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 3 for MS-CHAP-PW-1 + + Vendor-Length + 72 + + Code + The Code field is one octet in length. Its value is always 5. + + + +Zorn Informational [Page 7] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + LM-Old-Password + The LM-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + LM-New-Password + The LM-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + NT-Old-Password + The NT-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + NT-New-Password + The NT-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + New-LM-Password-Length + The New-LM-Password-Length field is two octets in length and + contains the length in octets of the new LAN Manager-compatible + password. + + Flags + The Flags field is two octets in length. If the least significant + bit of the Flags field is one, this indicates that the NT-New- + Password and NT-Old-Password fields are valid and SHOULD be used. + Otherwise, the LM-New-Password and LM-Old-Password fields MUST be + used. + +2.1.7. MS-CHAP-CPW-2 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in Access-Request packets, + and should only be included if an MS-CHAP-Error attribute was + included in the immediately preceding Access-Reject packet, the + String field of the MS-CHAP-Error attribute indicated that the + user password had expired, and the MS-CHAP version is equal to 2. + + A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 8] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old-NT-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old-LM-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Zorn Informational [Page 9] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Type + 4 for MS-CHAP-PW-2 + + Vendor-Length + 86 + + Code + 6 + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical to that in the + Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- + Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- + Request packet. + + Old-NT-Hash + The Old-NT-Hash field is 16 octets in length. It contains the old + Windows NT password hash encrypted with the new Windows NT + password hash. + + Old-LM-Hash + The Old-LM-Hash field is 16 octets in length. It contains the old + Lan Manager password hash encrypted with the new Windows NT + password hash. + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + The NT-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + Flags + The Flags field is two octets in length. If the least significant + bit (bit 0) of this field is one, the NT-Response field is to be + used in preference to the LM-Response field for authentication. + The LM-Response field MAY still be used (if present), but the NT- + Response SHOULD be tried first. If least significant bit of the + field is zero, the NT-Response field MUST be ignored and the LM- + Response field used instead. If bit 1 of the Flags field is one, + the Old-LM-Hash field is valid and SHOULD be used. If this bit is + set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST + be included in the packet. + + + + +Zorn Informational [Page 10] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.8. MS-CHAP-LM-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old LAN Manager password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in + conjunction with the MS-CHAP-CPW-2 attribute. It should only be + included if an MS-CHAP-Error attribute was included in the + immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is 2 or greater. + + A summary of the MS-CHAP-LM-Enc-PW 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence-Number | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 5 for MS-CHAP-LM-Enc-PW + + Vendor-Length + > 6 + + Code 6. Code is the same as for the MS-CHAP-PW-2 attribute. + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical in all + instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS- + CHAP-PW-2 attributes which are present in the same Access-Request + packet. + + + + + + + +Zorn Informational [Page 11] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Sequence-Number + The Sequence-Number field is two octets in length and indicates + which "chunk" of the encrypted password is contained in the + following String field. + + String The String field contains a portion of the encrypted password. + +2.2. MS-CHAP-NT-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old Windows NT password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in conjunc- + tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It + should only be included if an MS-CHAP-Error attribute was included + in the immediately preceding Access-Reject packet, the String + field of the MS-CHAP-Error attribute indicated that the user + password had expired, and the MS-CHAP version is 2 or greater. + + A summary of the MS-CHAP-NT-Enc-PW 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence-Number | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 6 for MS-CHAP-NT-Enc-PW + + Vendor-Length + > 6 + + Code + 6. Code is the same as for the MS-CHAP-PW-2 attribute. + + + + + + +Zorn Informational [Page 12] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical in all + instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS- + CHAP-PW-2 attributes which are present in the same Access-Request + packet. + + Sequence-Number + The Sequence-Number field is two octets in length and indicates + which "chunk" of the encrypted password is contained in the + following String field. + + String + The String field contains a portion of the encrypted password. + +2.3. Attributes for Support of MS-CHAP Version 2 + +2.3.1. Introduction + + This section describes RADIUS attributes supporting version two of + Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is + similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1) + [4]. Certain protocol fields have been deleted or reused but with + different semantics. Where possible, MS-CHAP-V2 is consistent with + both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences + between MS-CHAP-V2 and MS-CHAP-V1 are: + + * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP + option 3, Authentication Protocol. + + * MS-CHAP-V2 provides mutual authentication between peers by + piggybacking a peer challenge on the Response packet and an + authenticator response on the Success packet. + + * The calculation of the "Windows NT compatible challenge + response" sub-field in the Response packet has been changed to + include the peer challenge and the user name. + + * In MS-CHAP-V1, the "LAN Manager compatible challenge response" + sub-field was always sent in the Response packet. This field + has been replaced in MS-CHAP-V2 by the Peer-Challenge field. + + * The format of the Message field in the Failure packet has been + changed. + + * The Change Password (version 1) and Change Password (version 2) + packets are no longer supported. They have been replaced with a + single Change-Password packet. + + + +Zorn Informational [Page 13] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + The attributes defined in this section reflect these differences. + +2.3.2. MS-CHAP2-Response + + Description + + This Attribute contains the response value provided by an MS- + CHAP-V2 peer in response to the challenge. It is only used in + Access-Request packets. + + A summary of the MS-CHAP2-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reserved (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 25 for MS-CHAP2-Response. + + Vendor-Length + 52 + + + +Zorn Informational [Page 14] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + Identical to the PPP MS-CHAP v2 Identifier. + + Flags + The Flags field is one octet in length. It is reserved for future + use and MUST be zero. + + Peer-Challenge + The Peer-Challenge field is a 16-octet random number. + + Reserved + This field is reserved for future use and MUST be zero. + + Response + The Response field is 24 octets in length and holds an encoded + function of the password, the Peer-Challenge field and the + received challenge. + +2.3.3. MS-CHAP2-Success + + Description + + This Attribute contains a 42-octet authenticator response string. + This string MUST be included in the Message field of the MS-CHAP- + V2 Success packet sent from the NAS to the peer. This Attribute + is only used in Access-Accept packets. + + A summary of the MS-CHAP2-Success 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 26 for MS-CHAP2-Success. + + Vendor-Length + 45 + + Ident + Identical to the PPP MS-CHAP v2 Identifier. + + String + The 42-octet authenticator string (see above). + + + + +Zorn Informational [Page 15] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.3.4. MS-CHAP2-CPW + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in conjunction with the MS- + CHAP-NT-Enc-PW attribute in Access-Request packets, and should + only be included if an MS-CHAP-Error attribute was included in the + immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is equal to 3. + + A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 16] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 27 for MS-CHAP2-PW + + Vendor-Length + 70 + + Code + 7 + + + +Zorn Informational [Page 17] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical to that in the + Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in + the Access-Request packet. + + Encrypted-Hash + The Encrypted-Hash field is 16 octets in length. It contains the + old Windows NT password hash encrypted with the new Windows NT + password hash. + + NT-Response + The NT-Response field is 24 octets in length and holds an encoded + function of the new password, the Peer-Challenge field and the + received challenge. + + Flags + The Flags field is two octets in length. This field is reserved + for future use and MUST be zero. + +2.4. Attributes for MPPE Support + + This section describes a set of Attributes designed to support the + use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up + networks. MPPE is a means of representing Point to Point Protocol + (PPP) [7] packets in a encrypted form. MPPE uses the RSA RC4 [8] + algorithm for encryption. The length of the session key to be used + for initializing encryption tables can be negotiated; MPPE currently + supports 40 bit and 128 bit session keys. MPPE is negotiated within + option 18 in the PPP Compression Control Protocol (CCP)[9], [10]. + +2.4.1. MS-CHAP-MPPE-Keys + + Description + + The MS-CHAP-MPPE-Keys Attribute contains two session keys for use + by the Microsoft Point-to-Point Encryption Protocol (MPPE). This + Attribute is only included in Access-Accept packets. + + A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 18] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Keys + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 12 for MS-CHAP-MPPE-Keys. + + Vendor-Length + 34 + + Keys + The Keys field consists of two logical sub-fields: the LM-Key and + the NT-Key. The LM-Key is eight octets in length and contains the + first eight bytes of the output of the function LmPasswordHash(P, + This hash is constructed as follows: let the plain-text password + be represented by P. + + The NT-Key sub-field is sixteen octets in length and contains the + first sixteen octets of the hashed Windows NT password. The + format of the plaintext Keys field is illustrated in the following + diagram: + + + + + + + + + + + + +Zorn Informational [Page 19] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Key + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Key (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Key + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Padding (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Keys field MUST be encrypted by the RADIUS server using the + same method defined for the User-Password Attribute [3]. Padding + is required because the method referenced above requires the field + to be encrypted to be a multiple of sixteen octets in length. + + Implementation Note + This attribute should only be returned in response to an + Access-Request packet containing MS-CHAP attributes. + +2.4.2. MS-MPPE-Send-Key + + Description + + The MS-MPPE-Send-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets sent + from the NAS to the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Send-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 20] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Salt + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 16 for MS-MPPE-Send-Key. + + Vendor-Length + > 4 + + Salt + The Salt field is two octets in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. The most + significant bit (leftmost) of the Salt field MUST be set (1). The + contents of each Salt field in a given Access-Accept packet MUST + be unique. + + String + The plaintext String field consists of three logical sub-fields: + the Key-Length and Key sub-fields (both of which are required), + and the optional Padding sub-field. The Key-Length sub-field is + one octet in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains the actual encryption key. + If the combined length (in octets) of the unencrypted Key-Length + and Key sub-fields is not an even multiple of 16, then the Padding + sub-field MUST be present. If it is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + Construct a plaintext version of the String field by concate- + nating the Key-Length and Key sub-fields. If necessary, pad + the resulting string until its length (in octets) is an even + multiple of 16. It is recommended that zero octets (0x00) be + used for padding. Call this plaintext P. + + Call the shared secret S, the pseudo-random 128-bit Request + Authenticator (from the corresponding Access-Request packet) R, + and the contents of the Salt field A. Break P into 16 octet + chunks p(1), p(2)...p(i), where i = len(P)/16. Call the + ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. + Intermediate values b(1), b(2)...c(i) are required. Encryption + is performed in the following manner ('+' indicates + concatenation): + + + +Zorn Informational [Page 21] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) + b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) + . . + . . + . . + b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) + + The resulting encrypted String field will contain + c(1)+c(2)+...+c(i). + + On receipt, the process is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might be unavailable. The external + server SHOULD, however, return the attribute as defined above; the + Salt field SHOULD be zero-filled and padding of the String field + SHOULD be done. When the RADIUS server receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting it to the RADIUS + client. If the channel used to communicate the MS-MPPE-Send-Key + attribute is not secure from eavesdropping, the attribute MUST be + cryptographically protected. + +2.4.3. MS-MPPE-Recv-Key + + Description + + The MS-MPPE-Recv-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets received + by the NAS from the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Recv-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + +Zorn Informational [Page 22] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Salt + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 17 for MS-MPPE-Recv-Key. + + Vendor-Length + > 4 + + Salt + The Salt field is two octets in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. The most + significant bit (leftmost) of the Salt field MUST be set (1). The + contents of each Salt field in a given Access-Accept packet MUST + be unique. + + String + The plaintext String field consists of three logical sub-fields: + the Key-Length and Key sub-fields (both of which are required), + and the optional Padding sub-field. The Key-Length sub-field is + one octet in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains the actual encryption key. + If the combined length (in octets) of the unencrypted Key-Length + and Key sub-fields is not an even multiple of 16, then the Padding + sub-field MUST be present. If it is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + Construct a plaintext version of the String field by + concatenating the Key-Length and Key sub-fields. If necessary, + pad the resulting string until its length (in octets) is an + even multiple of 16. It is recommended that zero octets (0x00) + be used for padding. Call this plaintext P. + + Call the shared secret S, the pseudo-random 128-bit Request + Authenticator (from the corresponding Access-Request packet) R, + and the contents of the Salt field A. Break P into 16 octet + chunks p(1), p(2)...p(i), where i = len(P)/16. Call the + ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. + Intermediate values b(1), b(2)...c(i) are required. Encryption + is performed in the following manner ('+' indicates + concatenation): + + + +Zorn Informational [Page 23] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) + b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) + . . + . . + . . + b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) + + The resulting encrypted String field will contain + c(1)+c(2)+...+c(i). + + On receipt, the process is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might be unavailable. The external + server SHOULD, however, return the attribute as defined above; the + Salt field SHOULD be zero-filled and padding of the String field + SHOULD be done. When the RADIUS server receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting it to the RADIUS + client. If the channel used to communicate the MS-MPPE-Recv-Key + attribute is not secure from eavesdropping, the attribute MUST be + cryptographically protected. + +2.4.4. MS-MPPE-Encryption-Policy + + Description + + The MS-MPPE-Encryption-Policy Attribute may be used to signify + whether the use of encryption is allowed or required. If the + Policy field is equal to 1 (Encryption-Allowed), any or none of + the encryption types specified in the MS-MPPE-Encryption-Types + Attribute MAY be used. If the Policy field is equal to 2 + (Encryption-Required), any of the encryption types specified in + the MS-MPPE-Encryption-Types Attribute MAY be used, but at least + one MUST be used. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted left to right. + + + + + +Zorn Informational [Page 24] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Policy + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Policy (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 7 for MS-MPPE-Encryption-Policy. + + Vendor-Length + 6 + + Policy + The Policy field is 4 octets in length. Defined values are: + + 1 Encryption-Allowed 2 Encryption-Required + +2.4.5. MS-MPPE-Encryption-Types + + Description + + The MS-MPPE-Encryption-Types Attribute is used to signify the + types of encryption available for use with MPPE. It is a four + octet integer that is interpreted as a string of bits. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Types + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Types (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 8 for MS-MPPE-Encryption-Types. + + Vendor-Length + 6 + + Policy + The Types field is 4 octets in length. The following diagram + illustrates the Types field. + + + + +Zorn Informational [Page 25] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 3 2 1 + 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |S|L| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + If the L bit is set, RC4[5] encryption using a 40-bit key is + allowed. If the S bit is set, RC4 encryption using a 128-bit key + is allowed. If both the L and S bits are set, then either 40- or + 128-bit keys may be used with the RC4 algorithm. + +2.5. Attributes for BAP Support + + This section describes a set of vendor-specific RADIUS attributes + designed to support the dynamic control of bandwidth allocation in + multilink PPP [11]. Attributes are defined that specify whether use + of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or + required on incoming calls, the level of line capacity (expressed as + a percentage) below which utilization must fall before a link is + eligible to be dropped, and the length of time (in seconds) that a + link must be under-utilized before it is dropped. + +2.5.1. MS-BAP-Usage + + Description + + This Attribute describes whether the use of BAP is allowed, + disallowed or required on new multilink calls. It MAY be used in + Access-Accept packets. + + A summary of the MS-BAP-Usage 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 13 for MS-BAP-Usage. + + Vendor-Length + 6 + + + + + +Zorn Informational [Page 26] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Value field is four octets. + + 0 BAP usage not allowed + 1 BAP usage allowed + 2 BAP usage required + +2.5.2. MS-Link-Utilization-Threshold + + Description + + This Attribute represents the percentage of available bandwidth + utilization below which the link must fall before the link is + eligible for termination. Permissible values for the MS-Link- + Utilization-Threshold Attribute are in the range 1-100, inclusive. + It is only used in Access-Accept packets. + + A summary of the MS-Link-Utilization-Threshold 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 14 for MS-Link-Utilization-Threshold + + Vendor-Length 6 + + Value The Value field is four octets in length and represents the + percentage of available bandwidth utilization below which the link + must fall before the link is eligible for termination. + Permissible values are in the range 1-100, inclusive. + +2.5.3. MS-Link-Drop-Time-Limit + + Description + + The MS-Link-Drop-Time-Limit Attribute indicates the length of time + (in seconds) that a link must be underutilized before it is + dropped. It MAY only be included in Access-Accept packets. + + A summary of the MS-Link-Drop-Time-Limit Attribute format is given + below. The fields are transmitted left to right. + + + +Zorn Informational [Page 27] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 15 for MS-Link-Drop-Time-Limit + + Vendor-Length + 6 + + Value + The Value field represents the number of seconds that a link must + be underutilized (i.e., display bandwidth utilization below the + threshold specified in the MS-Link-Utilization-Threshold + Attribute) before the link is dropped. + +2.6. Attributes for ARAP Support + + This section describes a set of Attributes designed to support the + Apple Remote Access Protocol (ARAP). + +2.6.1. MS-Old-ARAP-Password + + Description + + The MS-Old-ARAP-Password Attribute is used to transmit the old + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-Old-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 19 for MS-Old-ARAP-Password Attribute + + Vendor-Length + > 3 + + + + +Zorn Informational [Page 28] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + String + The String field is one or more octets. It contains the old ARAP + password DES-encrypted using itself as the key. + +2.6.2. MS-New-ARAP-Password + + Description + + The MS-New-ARAP-Password Attribute is used to transmit the new + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-New-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 20 for MS-New-ARAP-Password Attribute + + Vendor-Length + > 3 + + String + The String field is one or more octets. It contains the new ARAP + password DES-encrypted using the old ARAP password as the key. + +2.6.3. MS-ARAP-Password-Change-Reason + + Description + + The MS-ARAP-Password-Change-Reason Attribute is used to indicate + reason for a server-initiated password change. It MAY be included + in Access-Challenge packets. + + A summary of the MS-ARAP-Password-Change-Reason Attribute format is + given below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 29] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Why + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Why (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 21 for MS-ARAP-Password-Change-Reason + + Vendor-Length + 6 + + Why + The Why field is 4 octets in length. The following values are + defined: + Just-Change-Password 1 + Expired-Password 2 + Admin-Requires-Password-Change 3 + Password-Too-Short 4 + +2.6.4. MS-ARAP-Challenge + + Description + + This attribute is only present in an Access-Request packet + containing a Framed-Protocol Attribute with the value 3 (ARAP). + + A summary of the MS-ARAP-Challenge Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 33 for MS-ARAP-Challenge + + Vendor-Length + 10 + + + + +Zorn Informational [Page 30] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Challenge Field is 8 octets in length. It contains the + challenge (as two 4-octet quantities) sent by the NAS to the peer. + +2.7. Miscellaneous Attributes + + This section describes attributes which do not fall into any + particular category, but are used in the identification and operation + of Microsoft remote access products. + +2.7.1. MS-RAS-Vendor + + Description + + The MS-RAS-Vendor Attribute is used to indicate the manufacturer + of the RADIUS client machine. It MAY be included in both Access- + Request and Accounting-Request packets. + + A summary of the MS-RAS-Vendor Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Vendor-ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-ID (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 9 for MS-RAS-Vendor + + Vendor-Length + 6 + + Vendor-ID + The Vendor-ID field is 4 octets in length. The high-order octet + is 0 and the low-order 3 octets are the SMI Network Management + Private Enterprise Code of the Vendor in network byte order, as + defined in the Assigned Numbers RFC [13]. + +2.7.2. MS-RAS-Version + + Description + + The MS-RAS-Version Attribute is used to indicate the version of + the RADIUS client software. This attribute SHOULD be included in + packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be + + + +Zorn Informational [Page 31] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + sent in packets which do not contain an MS-RAS-Vendor Attribute. + It MAY be included in both Access-Request and Accounting-Request + packets. + + A summary of the MS-RAS-Version Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 18 for MS-RAS-Version + + Vendor-Length + > 3 + + String + The String field is one or more octets. The actual format of the + information is vendor specific, and a robust implementation SHOULD + support the field as undistinguished octets. + +2.7.3. MS-Filter + + Description + + The MS-Filter Attribute is used to transmit traffic filters. It + MAY be included in both Access-Accept and Accounting-Request + packets. + + If multiple MS-Filter Attributes are contained within a packet, + they MUST be in order and they MUST be consecutive attributes in + the packet. + + A summary of the MS-Filter Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Filter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 22 for MS-Filter Attribute + + + + +Zorn Informational [Page 32] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Length + > 3 + + Filter + The Filter field is one or more octets. It contains a sequence of + undifferentiated octets. + + If multiple MS-Filter Attributes occur in a single Access-Accept + packet, the Filter field from each MUST be concatenated in the + order received to form the actual filter. + +2.7.4. MS-Acct-Auth-Type + + Description + + The MS-Acct-Auth-Type Attribute is used to represent the method + used to authenticate the dial-up user. It MAY be included in + Accounting-Request packets. + + A summary of the MS-Acct-Auth-Type Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Auth-Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Auth-Type (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 23 for MS-Acct-Auth-Type + + Vendor-Length + 6 + + Auth-Type + The Auth-Type field is 4 octets in length. The following values + are defined for this field: + + PAP 1 + CHAP 2 + MS-CHAP-1 3 + MS-CHAP-2 4 + EAP 5 + + + + + + +Zorn Informational [Page 33] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.5. MS-Acct-EAP-Type + + Description + + The MS-Acct-EAP-Type Attribute is used to represent the Extensible + Authentication Protocol (EAP) [15] type used to authenticate the + dial-up user. It MAY be included in Accounting-Request packets. + + A summary of the MS-Acct-EAP-Type Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | EAP-Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + EAP-Type (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 24 for MS-Acct-EAP-Type + + Vendor-Length + 6 + + Auth-Type + The EAP-Type field is 4 octets in length. The following values + are currently defined for this field: + + MD5 4 + OTP 5 + Generic Token Card 6 + TLS 13 + +2.7.6. MS-Primary-DNS-Server + + Description + + The MS-Primary-DNS-Server Attribute is used to indicate the + address of the primary Domain Name Server (DNS) [16, 17] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-DNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + +Zorn Informational [Page 34] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 28 for MS-Primary-DNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the primary DNS server. + +2.7.7. MS-Secondary-DNS-Server + + Description + + The MS-Secondary-DNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-DNS-Server Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 29 for MS-Secondary-DNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the secondary DNS server. + + + + +Zorn Informational [Page 35] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.8. MS-Primary-NBNS-Server + + Description + + The MS-Primary-NBNS-Server Attribute is used to indicate the + address of the primary NetBIOS Name Server (NBNS) [18] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-MBNS-Server Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 30 for MS-Primary-NBNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the primary NBNS server. + +2.7.9. MS-Secondary-NBNS-Server + + Description + + The MS-Secondary-NBNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-NBNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 36] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 31 for MS-Secondary-NBNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the secondary NBNS server. + +3. Table of Attributes + + The following table provides a guide to which of the above attributes + may be found in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge Acct-Request # Attribute + 0-1 0 0 0 0 1 MS-CHAP-Response + 0 0 0-1 0 0 2 MS-CHAP-Error + 0-1 0 0 0 0 3 MS-CHAP-CPW-1 + 0-1 0 0 0 0 4 MS-CHAP-CPW-2 + 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW + 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW + 0 0-1 0 0 0 7 MS-MPPE-Encryption- + Policy + 0 0-1 0 0 0 8 MS-MPPE-Encryption-Type + 0-1 0 0 0 0-1 9 MS-RAS-Vendor + 0 0-1 0 0 0-1 10 MS-CHAP-Domain + 0-1 0 0 0-1 0 11 MS-CHAP-Challenge + 0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys + 0 0-1 0 0 0 13 MS-BAP-Usage + 0 0-1 0 0 0 14 MS-Link-Utilization- + Threshold + 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit + 0 0-1 0 0 0 16 MS-MPPE-Send-Key + 0 0-1 0 0 0 17 MS-MPPE-Recv-Key + 0-1 0 0 0 0-1 18 MS-RAS-Version + 0-1 0 0 0 0 19 MS-Old-ARAP-Password + 0-1 0 0 0 0 20 MS-New-ARAP-Password + 0 0 0 0-1 0 21 MS-ARAP-PW-Change- + Reason + + + +Zorn Informational [Page 37] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 0 0+ 0 0 0+ 22 MS-Filter + 0 0 0 0 0-1 23 MS-Acct-Auth-Type + 0 0 0 0 0-1 24 MS-Acct-EAP-Type + 0-1 0 0 0 0 25 MS-CHAP2-Response + 0 0-1 0 0 0 26 MS-CHAP2-Success + 0-1 0 0 0 0 27 MS-CHAP2-CPW + 0 0-1 0 0 0-1 28 MS-Primary-DNS-Server + 0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server + 0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server + 0 0-1 0 0 0-1 31 MS-Secondary-NBNS- + Server + 0-1 0 0 0 0 33 MS-ARAP-Challenge + +The following table defines the meaning of the above table entries. + +0 This attribute MUST NOT be present in packet. +0+ Zero or more instances of this attribute MAY be present in packet. +0-1 Zero or one instance of this attribute MAY be present in packet. + +4. Security Considerations + + MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User + passwords should be chosen with care, and be of sufficient length to + deter easy guessing. + + Although the scheme used to protect the Keys field of the MS-CHAP- + MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is + believed to be relatively secure on the wire, RADIUS proxies will + decrypt and re-encrypt the field for forwarding. Therefore, these + attributes SHOULD NOT be used on networks where untrusted RADIUS + proxies reside. + +5. Acknowledgements + + Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash- + winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra + Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), + Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton + (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh + Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com), + and Don Rule (don-aldr@microsoft.com) for useful suggestions and + editorial feedback. + + + + + + + + + +Zorn Informational [Page 38] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +6. Editor's Address + + Questions about this memo can be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: glennz@microsoft.com + +7. References + + [1] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Access Dial In User Service", RFC 2138, April 1997. + + [4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, + October 1998. + + [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption + (MPPE) Protocol", Work in Progress. + + [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [8] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [9] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC + 1962, June 1996. + + + +Zorn Informational [Page 39] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, + "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. + + [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation + Protocol (BAP) The PPP Bandwidth Allocation Control Protocol + (BACP)", RFC 2125, March 1997. + + [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in + Progress. + + [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/ISI, November 1987. + + [17] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, + March 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 40] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 41] + diff --git a/doc/rfc2865.txt b/doc/rfc2865.txt new file mode 100644 index 0000000..10ec231 --- /dev/null +++ b/doc/rfc2865.txt @@ -0,0 +1,4259 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2865 S. Willens +Obsoletes: 2138 Livingston +Category: Standards Track A. Rubens + Merit + W. Simpson + Daydreamer + June 2000 + + + Remote Authentication Dial In User Service (RADIUS) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +IESG Note: + + This protocol is widely implemented and used. Experience has shown + that it can suffer degraded performance and lost data when used in + large scale systems, in part because it does not include provisions + for congestion control. Readers of this document may find it + beneficial to track the progress of the IETF's AAA working group, + which may develop a successor protocol that better addresses the + scaling and congestion control issues. + +Abstract + + This document describes a protocol for carrying authentication, + authorization, and configuration information between a Network Access + Server which desires to authenticate its links and a shared + Authentication Server. + +Implementation Note + + This memo documents the RADIUS protocol. The early deployment of + RADIUS was done using UDP port number 1645, which conflicts with the + "datametrics" service. The officially assigned port number for + RADIUS is 1812. + + + + +Rigney, et al. Standards Track [Page 1] + +RFC 2865 RADIUS June 2000 + + +Table of Contents + + 1. Introduction .......................................... 3 + 1.1 Specification of Requirements ................... 4 + 1.2 Terminology ..................................... 5 + 2. Operation ............................................. 5 + 2.1 Challenge/Response .............................. 7 + 2.2 Interoperation with PAP and CHAP ................ 8 + 2.3 Proxy ........................................... 8 + 2.4 Why UDP? ........................................ 11 + 2.5 Retransmission Hints ............................ 12 + 2.6 Keep-Alives Considered Harmful .................. 13 + 3. Packet Format ......................................... 13 + 4. Packet Types .......................................... 17 + 4.1 Access-Request .................................. 17 + 4.2 Access-Accept ................................... 18 + 4.3 Access-Reject ................................... 20 + 4.4 Access-Challenge ................................ 21 + 5. Attributes ............................................ 22 + 5.1 User-Name ....................................... 26 + 5.2 User-Password ................................... 27 + 5.3 CHAP-Password ................................... 28 + 5.4 NAS-IP-Address .................................. 29 + 5.5 NAS-Port ........................................ 30 + 5.6 Service-Type .................................... 31 + 5.7 Framed-Protocol ................................. 33 + 5.8 Framed-IP-Address ............................... 34 + 5.9 Framed-IP-Netmask ............................... 34 + 5.10 Framed-Routing .................................. 35 + 5.11 Filter-Id ....................................... 36 + 5.12 Framed-MTU ...................................... 37 + 5.13 Framed-Compression .............................. 37 + 5.14 Login-IP-Host ................................... 38 + 5.15 Login-Service ................................... 39 + 5.16 Login-TCP-Port .................................. 40 + 5.17 (unassigned) .................................... 41 + 5.18 Reply-Message ................................... 41 + 5.19 Callback-Number ................................. 42 + 5.20 Callback-Id ..................................... 42 + 5.21 (unassigned) .................................... 43 + 5.22 Framed-Route .................................... 43 + 5.23 Framed-IPX-Network .............................. 44 + 5.24 State ........................................... 45 + 5.25 Class ........................................... 46 + 5.26 Vendor-Specific ................................. 47 + 5.27 Session-Timeout ................................. 48 + 5.28 Idle-Timeout .................................... 49 + 5.29 Termination-Action .............................. 49 + + + +Rigney, et al. Standards Track [Page 2] + +RFC 2865 RADIUS June 2000 + + + 5.30 Called-Station-Id ............................... 50 + 5.31 Calling-Station-Id .............................. 51 + 5.32 NAS-Identifier .................................. 52 + 5.33 Proxy-State ..................................... 53 + 5.34 Login-LAT-Service ............................... 54 + 5.35 Login-LAT-Node .................................. 55 + 5.36 Login-LAT-Group ................................. 56 + 5.37 Framed-AppleTalk-Link ........................... 57 + 5.38 Framed-AppleTalk-Network ........................ 58 + 5.39 Framed-AppleTalk-Zone ........................... 58 + 5.40 CHAP-Challenge .................................. 59 + 5.41 NAS-Port-Type ................................... 60 + 5.42 Port-Limit ...................................... 61 + 5.43 Login-LAT-Port .................................. 62 + 5.44 Table of Attributes ............................. 63 + 6. IANA Considerations ................................... 64 + 6.1 Definition of Terms ............................. 64 + 6.2 Recommended Registration Policies ............... 65 + 7. Examples .............................................. 66 + 7.1 User Telnet to Specified Host ................... 66 + 7.2 Framed User Authenticating with CHAP ............ 67 + 7.3 User with Challenge-Response card ............... 68 + 8. Security Considerations ............................... 71 + 9. Change Log ............................................ 71 + 10. References ............................................ 73 + 11. Acknowledgements ...................................... 74 + 12. Chair's Address ....................................... 74 + 13. Authors' Addresses .................................... 75 + 14. Full Copyright Statement .............................. 76 + +1. Introduction + + This document obsoletes RFC 2138 [1]. A summary of the changes + between this document and RFC 2138 is available in the "Change Log" + appendix. + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + + + + + + +Rigney, et al. Standards Track [Page 3] + +RFC 2865 RADIUS June 2000 + + + Key features of RADIUS are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of RADIUS. The + client is responsible for passing user information to designated + RADIUS servers, and then acting on the response which is returned. + + RADIUS servers are responsible for receiving user connection + requests, authenticating the user, and then returning all + configuration information necessary for the client to deliver + service to the user. + + A RADIUS server can act as a proxy client to other RADIUS servers + or other kinds of authentication servers. + + Network Security + + Transactions between the client and RADIUS server are + authenticated through the use of a shared secret, which is never + sent over the network. In addition, any user passwords are sent + encrypted between the client and RADIUS server, to eliminate the + possibility that someone snooping on an unsecure network could + determine a user's password. + + Flexible Authentication Mechanisms + + The RADIUS server can support a variety of methods to authenticate + a user. When it is provided with the user name and original + password given by the user, it can support PPP PAP or CHAP, UNIX + login, and other authentication mechanisms. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + 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 BCP 14 [2]. These key + words mean the same thing whether capitalized or not. + + 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 + + + +Rigney, et al. Standards Track [Page 4] + +RFC 2865 RADIUS June 2000 + + + 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-accept authorizing an + unavailable service as an access-reject instead. + +1.2. Terminology + + This document frequently 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 + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that. + + 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 + + When a client is configured to use RADIUS, any user of the client + presents authentication information to the client. This might be + with a customizable login prompt, where the user is expected to enter + their username and password. Alternatively, the user might use a + link framing protocol such as the Point-to-Point Protocol (PPP), + which has authentication packets which carry this information. + + Once the client has obtained such information, it may choose to + authenticate using RADIUS. To do so, the client creates an "Access- + Request" containing such Attributes as the user's name, the user's + password, the ID of the client and the Port ID which the user is + accessing. When a password is present, it is hidden using a method + based on the RSA Message Digest Algorithm MD5 [3]. + + + + +Rigney, et al. Standards Track [Page 5] + +RFC 2865 RADIUS June 2000 + + + The Access-Request is submitted to the RADIUS server via the network. + If no response is returned within a length of time, the request is + re-sent a number of times. The client can also forward requests to + an alternate server or servers in the event that the primary server + is down or unreachable. An alternate server can be used either after + a number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + Once the RADIUS server receives the request, it validates the sending + client. A request from a client for which the RADIUS server does not + have a shared secret MUST be silently discarded. If the client is + valid, the RADIUS server consults a database of users to find the + user whose name matches the request. The user entry in the database + contains a list of requirements which must be met to allow access for + the user. This always includes verification of the password, but can + also specify the client(s) or port(s) to which the user is allowed + access. + + The RADIUS server MAY make requests of other servers in order to + satisfy the request, in which case it acts as a client. + + If any Proxy-State attributes were present in the Access-Request, + they MUST be copied unmodified and in order into the response packet. + Other Attributes can be placed before, after, or even between the + Proxy-State attributes. + + If any condition is not met, the RADIUS server sends an "Access- + Reject" response indicating that this user request is invalid. If + desired, the server MAY include a text message in the Access-Reject + which MAY be displayed by the client to the user. No other + Attributes (except Proxy-State) are permitted in an Access-Reject. + + If all conditions are met and the RADIUS server wishes to issue a + challenge to which the user must respond, the RADIUS server sends an + "Access-Challenge" response. It MAY include a text message to be + displayed by the client to the user prompting for a response to the + challenge, and MAY include a State attribute. + + If the client receives an Access-Challenge and supports + challenge/response it MAY display the text message, if any, to the + user, and then prompt the user for a response. The client then re- + submits its original Access-Request with a new request ID, with the + User-Password Attribute replaced by the response (encrypted), and + including the State Attribute from the Access-Challenge, if any. + Only 0 or 1 instances of the State Attribute SHOULD be + + + + + +Rigney, et al. Standards Track [Page 6] + +RFC 2865 RADIUS June 2000 + + + present in a request. The server can respond to this new Access- + Request with either an Access-Accept, an Access-Reject, or another + Access-Challenge. + + If all conditions are met, the list of configuration values for the + user are placed into an "Access-Accept" response. These values + include the type of service (for example: SLIP, PPP, Login User) and + all necessary values to deliver the desired service. For SLIP and + PPP, this may include values such as IP address, subnet mask, MTU, + desired compression, and desired packet filter identifiers. For + character mode users, this may include values such as desired + protocol and host. + +2.1. Challenge/Response + + In challenge/response authentication, the user is given an + unpredictable number and challenged to encrypt it and give back the + result. Authorized users are equipped with special devices such as + smart cards or software that facilitate calculation of the correct + response with ease. Unauthorized users, lacking the appropriate + device or software and lacking knowledge of the secret key necessary + to emulate such a device or software, can only guess at the response. + + The Access-Challenge packet typically contains a Reply-Message + including a challenge to be displayed to the user, such as a numeric + value unlikely ever to be repeated. Typically this is obtained from + an external server that knows what type of authenticator is in the + possession of the authorized user and can therefore choose a random + or non-repeating pseudorandom number of an appropriate radix and + length. + + The user then enters the challenge into his device (or software) and + it calculates a response, which the user enters into the client which + forwards it to the RADIUS server via a second Access-Request. If the + response matches the expected response the RADIUS server replies with + an Access-Accept, otherwise an Access-Reject. + + Example: The NAS sends an Access-Request packet to the RADIUS Server + with NAS-Identifier, NAS-Port, User-Name, User-Password (which may + just be a fixed string like "challenge" or ignored). The server + sends back an Access-Challenge packet with State and a Reply-Message + along the lines of "Challenge 12345678, enter your response at the + prompt" which the NAS displays. The NAS prompts for the response and + sends a NEW Access-Request to the server (with a new ID) with NAS- + Identifier, NAS-Port, User-Name, User-Password (the response just + entered by the user, encrypted), and the same State Attribute that + + + + + +Rigney, et al. Standards Track [Page 7] + +RFC 2865 RADIUS June 2000 + + + came with the Access-Challenge. The server then sends back either an + Access-Accept or Access-Reject based on whether the response matches + the required value, or it can even send another Access-Challenge. + +2.2. Interoperation with PAP and CHAP + + For PAP, the NAS takes the PAP ID and password and sends them in an + Access-Request packet as the User-Name and User-Password. The NAS MAY + include the Attributes Service-Type = Framed-User and Framed-Protocol + = PPP as a hint to the RADIUS server that PPP service is expected. + + For CHAP, the NAS generates a random challenge (preferably 16 octets) + and sends it to the user, who returns a CHAP response along with a + CHAP ID and CHAP username. The NAS then sends an Access-Request + packet to the RADIUS server with the CHAP username as the User-Name + and with the CHAP ID and CHAP response as the CHAP-Password + (Attribute 3). The random challenge can either be included in the + CHAP-Challenge attribute or, if it is 16 octets long, it can be + placed in the Request Authenticator field of the Access-Request + packet. The NAS MAY include the Attributes Service-Type = Framed- + User and Framed-Protocol = PPP as a hint to the RADIUS server that + PPP service is expected. + + The RADIUS server looks up a password based on the User-Name, + encrypts the challenge using MD5 on the CHAP ID octet, that password, + and the CHAP challenge (from the CHAP-Challenge attribute if present, + otherwise from the Request Authenticator), and compares that result + to the CHAP-Password. If they match, the server sends back an + Access-Accept, otherwise it sends back an Access-Reject. + + If the RADIUS server is unable to perform the requested + authentication it MUST return an Access-Reject. For example, CHAP + requires that the user's password be available in cleartext to the + server so that it can encrypt the CHAP challenge and compare that to + the CHAP response. If the password is not available in cleartext to + the RADIUS server then the server MUST send an Access-Reject to the + client. + +2.3. Proxy + + With proxy RADIUS, one RADIUS server receives an authentication (or + accounting) request from a RADIUS client (such as a NAS), forwards + the request to a remote RADIUS server, receives the reply from the + remote server, and sends that reply to the client, possibly with + changes to reflect local administrative policy. A common use for + proxy RADIUS is roaming. Roaming permits two or more administrative + entities to allow each other's users to dial in to either entity's + network for service. + + + +Rigney, et al. Standards Track [Page 8] + +RFC 2865 RADIUS June 2000 + + + The NAS sends its RADIUS access-request to the "forwarding server" + which forwards it to the "remote server". The remote server sends a + response (Access-Accept, Access-Reject, or Access-Challenge) back to + the forwarding server, which sends it back to the NAS. The User-Name + attribute MAY contain a Network Access Identifier [8] for RADIUS + Proxy operations. The choice of which server receives the forwarded + request SHOULD be based on the authentication "realm". The + authentication realm MAY be the realm part of a Network Access + Identifier (a "named realm"). Alternatively, the choice of which + server receives the forwarded request MAY be based on whatever other + criteria the forwarding server is configured to use, such as Called- + Station-Id (a "numbered realm"). + + A RADIUS server can function as both a forwarding server and a remote + server, serving as a forwarding server for some realms and a remote + server for other realms. One forwarding server can act as a + forwarder for any number of remote servers. A remote server can have + any number of servers forwarding to it and can provide authentication + for any number of realms. One forwarding server can forward to + another forwarding server to create a chain of proxies, although care + must be taken to avoid introducing loops. + + The following scenario illustrates a proxy RADIUS communication + between a NAS and the forwarding and remote RADIUS servers: + + 1. A NAS sends its access-request to the forwarding server. + + 2. The forwarding server forwards the access-request to the remote + server. + + 3. The remote server sends an access-accept, access-reject or + access-challenge back to the forwarding server. For this example, + an access-accept is sent. + + 4. The forwarding server sends the access-accept to the NAS. + + The forwarding server MUST treat any Proxy-State attributes already + in the packet as opaque data. Its operation MUST NOT depend on the + content of Proxy-State attributes added by previous servers. + + If there are any Proxy-State attributes in the request received from + the client, the forwarding server MUST include those Proxy-State + attributes in its reply to the client. The forwarding server MAY + include the Proxy-State attributes in the access-request when it + forwards the request, or MAY omit them in the forwarded request. If + the forwarding server omits the Proxy-State attributes in the + forwarded access-request, it MUST attach them to the response before + sending it to the client. + + + +Rigney, et al. Standards Track [Page 9] + +RFC 2865 RADIUS June 2000 + + + We now examine each step in more detail. + + 1. A NAS sends its access-request to the forwarding server. The + forwarding server decrypts the User-Password, if present, using + the shared secret it knows for the NAS. If a CHAP-Password + attribute is present in the packet and no CHAP-Challenge attribute + is present, the forwarding server MUST leave the Request- + Authenticator untouched or copy it to a CHAP-Challenge attribute. + + '' The forwarding server MAY add one Proxy-State attribute to the + packet. (It MUST NOT add more than one.) If it adds a Proxy- + State, the Proxy-State MUST appear after any other Proxy-States in + the packet. The forwarding server MUST NOT modify any other + Proxy-States that were in the packet (it may choose not to forward + them, but it MUST NOT change their contents). The forwarding + server MUST NOT change the order of any attributes of the same + type, including Proxy-State. + + 2. The forwarding server encrypts the User-Password, if present, + using the secret it shares with the remote server, sets the + Identifier as needed, and forwards the access-request to the + remote server. + + 3. The remote server (if the final destination) verifies the user + using User-Password, CHAP-Password, or such method as future + extensions may dictate, and returns an access-accept, access- + reject or access-challenge back to the forwarding server. For + this example, an access-accept is sent. The remote server MUST + copy all Proxy-State attributes (and only the Proxy-State + attributes) in order from the access-request to the response + packet, without modifying them. + + 4. The forwarding server verifies the Response Authenticator using + the secret it shares with the remote server, and silently discards + the packet if it fails verification. If the packet passes + verification, the forwarding server removes the last Proxy-State + (if it attached one), signs the Response Authenticator using the + secret it shares with the NAS, restores the Identifier to match + the one in the original request by the NAS, and sends the access- + accept to the NAS. + + A forwarding server MAY need to modify attributes to enforce local + policy. Such policy is outside the scope of this document, with the + following restrictions. A forwarding server MUST not modify existing + Proxy-State, State, or Class attributes present in the packet. + + + + + + +Rigney, et al. Standards Track [Page 10] + +RFC 2865 RADIUS June 2000 + + + Implementers of forwarding servers should consider carefully which + values it is willing to accept for Service-Type. Careful + consideration must be given to the effects of passing along Service- + Types of NAS-Prompt or Administrative in a proxied Access-Accept, and + implementers may wish to provide mechanisms to block those or other + service types, or other attributes. Such mechanisms are outside the + scope of this document. + +2.4. Why UDP? + + A frequently asked question is why RADIUS uses UDP instead of TCP as + a transport protocol. UDP was chosen for strictly technical reasons. + + There are a number of issues which must be understood. RADIUS is a + transaction based protocol which has several interesting + characteristics: + + 1. If the request to a primary Authentication server fails, a + secondary server must be queried. + + To meet this requirement, a copy of the request must be kept above + the transport layer to allow for alternate transmission. This + means that retransmission timers are still required. + + 2. The timing requirements of this particular protocol are + significantly different than TCP provides. + + At one extreme, RADIUS does not require a "responsive" detection + of lost data. The user is willing to wait several seconds for the + authentication to complete. The generally aggressive TCP + retransmission (based on average round trip time) is not required, + nor is the acknowledgement overhead of TCP. + + At the other extreme, the user is not willing to wait several + minutes for authentication. Therefore the reliable delivery of + TCP data two minutes later is not useful. The faster use of an + alternate server allows the user to gain access before giving up. + + 3. The stateless nature of this protocol simplifies the use of UDP. + + Clients and servers come and go. Systems are rebooted, or are + power cycled independently. Generally this does not cause a + problem and with creative timeouts and detection of lost TCP + connections, code can be written to handle anomalous events. UDP + however completely eliminates any of this special handling. Each + client and server can open their UDP transport just once and leave + it open through all types of failure events on the network. + + + + +Rigney, et al. Standards Track [Page 11] + +RFC 2865 RADIUS June 2000 + + + 4. UDP simplifies the server implementation. + + In the earliest implementations of RADIUS, the server was single + threaded. This means that a single request was received, + processed, and returned. This was found to be unmanageable in + environments where the back-end security mechanism took real time + (1 or more seconds). The server request queue would fill and in + environments where hundreds of people were being authenticated + every minute, the request turn-around time increased to longer + than users were willing to wait (this was especially severe when a + specific lookup in a database or over DNS took 30 or more + seconds). The obvious solution was to make the server multi- + threaded. Achieving this was simple with UDP. Separate processes + were spawned to serve each request and these processes could + respond directly to the client NAS with a simple UDP packet to the + original transport of the client. + + It's not all a panacea. As noted, using UDP requires one thing which + is built into TCP: with UDP we must artificially manage + retransmission timers to the same server, although they don't require + the same attention to timing provided by TCP. This one penalty is a + small price to pay for the advantages of UDP in this protocol. + + Without TCP we would still probably be using tin cans connected by + string. But for this particular protocol, UDP is a better choice. + +2.5. Retransmission Hints + + If the RADIUS server and alternate RADIUS server share the same + shared secret, it is OK to retransmit the packet to the alternate + RADIUS server with the same ID and Request Authenticator, because the + content of the attributes haven't changed. If you want to use a new + Request Authenticator when sending to the alternate server, you may. + + If you change the contents of the User-Password attribute (or any + other attribute), you need a new Request Authenticator and therefore + a new ID. + + If the NAS is retransmitting a RADIUS request to the same server as + before, and the attributes haven't changed, you MUST use the same + Request Authenticator, ID, and source port. If any attributes have + changed, you MUST use a new Request Authenticator and ID. + + A NAS MAY use the same ID across all servers, or MAY keep track of + IDs separately for each server, it is up to the implementer. If a + NAS needs more than 256 IDs for outstanding requests, it MAY use + + + + + +Rigney, et al. Standards Track [Page 12] + +RFC 2865 RADIUS June 2000 + + + additional source ports to send requests from, and keep track of IDs + for each source port. This allows up to 16 million or so outstanding + requests at one time to a single server. + +2.6. Keep-Alives Considered Harmful + + Some implementers have adopted the practice of sending test RADIUS + requests to see if a server is alive. This practice is strongly + discouraged, since it adds to load and harms scalability without + providing any additional useful information. Since a RADIUS request + is contained in a single datagram, in the time it would take you to + send a ping you could just send the RADIUS request, and getting a + reply tells you that the RADIUS server is up. If you do not have a + RADIUS request to send, it does not matter if the server is up or + not, because you are not using it. + + If you want to monitor your RADIUS server, use SNMP. That's what + SNMP is for. + +3. Packet Format + + Exactly one RADIUS packet is encapsulated in the UDP Data field [4], + where the UDP Destination Port field indicates 1812 (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS protocol. The early deployment of + RADIUS was done using UDP port number 1645, which conflicts with the + "datametrics" service. The officially assigned port number for + RADIUS is 1812. + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 13] + +RFC 2865 RADIUS June 2000 + + + A summary of the RADIUS data 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it + is silently discarded. + + RADIUS Codes (decimal) are assigned as follows: + + 1 Access-Request + 2 Access-Accept + 3 Access-Reject + 4 Accounting-Request + 5 Accounting-Response + 11 Access-Challenge + 12 Status-Server (experimental) + 13 Status-Client (experimental) + 255 Reserved + + Codes 4 and 5 are covered in the RADIUS Accounting document [5]. + Codes 12 and 13 are reserved for possible use, but are not further + mentioned here. + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS server can detect a duplicate request if + it has the same client source IP address and source UDP port and + Identifier within a short span of time. + + + + + + + +Rigney, et al. Standards Track [Page 14] + +RFC 2865 RADIUS June 2000 + + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and maximum length + is 4096. + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the reply from the RADIUS server, and is used in the + password hiding algorithm. + + Request Authenticator + + In Access-Request Packets, the Authenticator value is a 16 + octet random number, called the Request Authenticator. The + value SHOULD be unpredictable and unique over the lifetime of a + secret (the password shared between the client and the RADIUS + server), since repetition of a request value in conjunction + with the same secret would permit an attacker to reply with a + previously intercepted response. Since it is expected that the + same secret MAY be used to authenticate with servers in + disparate geographic regions, the Request Authenticator field + SHOULD exhibit global and temporal uniqueness. + + The Request Authenticator value in an Access-Request packet + SHOULD also be unpredictable, lest an attacker trick a server + into responding to a predicted future request, and then use the + response to masquerade as that server to a future Access- + Request. + + Although protocols such as RADIUS are incapable of protecting + against theft of an authenticated session via realtime active + wiretapping attacks, generation of unique unpredictable + requests can protect against a wide range of active attacks + against authentication. + + The NAS and RADIUS server share a secret. That shared secret + followed by the Request Authenticator is put through a one-way + MD5 hash to create a 16 octet digest value which is xored with + the password entered by the user, and the xored result placed + + + + + +Rigney, et al. Standards Track [Page 15] + +RFC 2865 RADIUS June 2000 + + + in the User-Password attribute in the Access-Request packet. + See the entry for User-Password in the section on Attributes + for a more detailed description. + + Response Authenticator + + The value of the Authenticator field in Access-Accept, Access- + Reject, and Access-Challenge packets is called the Response + Authenticator, and contains a one-way MD5 hash calculated over + a stream of octets consisting of: the RADIUS packet, beginning + with the Code field, including the Identifier, the Length, the + Request Authenticator field from the Access-Request packet, and + the response Attributes, followed by the shared secret. That + is, ResponseAuth = + MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + + denotes concatenation. + + Administrative Note + + The secret (password shared between the client and the RADIUS + server) SHOULD be at least as large and unguessable as a well- + chosen password. It is preferred that the secret be at least 16 + octets. This is to ensure a sufficiently large range for the + secret to provide protection against exhaustive search attacks. + The secret MUST NOT be empty (length 0) since this would allow + packets to be trivially forged. + + A RADIUS server MUST use the source IP address of the RADIUS UDP + packet to decide which shared secret to use, so that RADIUS + requests can be proxied. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction - when the proxy + forwards the request, the proxy MAY add a Proxy-State Attribute, + and when the proxy forwards a response, it MUST remove its Proxy- + State Attribute if it added one. Proxy-State is always added or + removed after any other Proxy-States, but no other assumptions + regarding its location within the list of attributes can be made. + Since Access-Accept and Access-Reject replies are authenticated on + the entire packet contents, the stripping of the Proxy-State + attribute invalidates the signature in the packet - so the proxy + has to re-sign it. + + Further details of RADIUS proxy implementation are outside the + scope of this document. + + + + + + +Rigney, et al. Standards Track [Page 16] + +RFC 2865 RADIUS June 2000 + + +4. Packet Types + + The RADIUS Packet type is determined by the Code field in the first + octet of the Packet. + +4.1. Access-Request + + Description + + Access-Request packets are sent to a RADIUS server, and convey + information used to determine whether a user is allowed access to + a specific NAS, and any special services requested for that user. + An implementation wishing to authenticate a user MUST transmit a + RADIUS packet with the Code field set to 1 (Access-Request). + + Upon receipt of an Access-Request from a valid client, an + appropriate reply MUST be transmitted. + + An Access-Request SHOULD contain a User-Name attribute. It MUST + contain either a NAS-IP-Address attribute or a NAS-Identifier + attribute (or both). + + An Access-Request MUST contain either a User-Password or a CHAP- + Password or a State. An Access-Request MUST NOT contain both a + User-Password and a CHAP-Password. If future extensions allow + other kinds of authentication information to be conveyed, the + attribute for that can be used in an Access-Request instead of + User-Password or CHAP-Password. + + An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type + attribute or both unless the type of access being requested does + not involve a port or the NAS does not distinguish among its + ports. + + An Access-Request MAY contain additional attributes as a hint to + the server, but the server is not required to honor the hint. + + When a User-Password is present, it is hidden using a method based + on the RSA Message Digest Algorithm MD5 [3]. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 17] + +RFC 2865 RADIUS June 2000 + + + A summary of the Access-Request packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 1 for Access-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MUST remain unchanged. + + Request Authenticator + + The Request Authenticator value MUST be changed each time a new + Identifier is used. + + Attributes + + The Attribute field is variable in length, and contains the list + of Attributes that are required for the type of service, as well + as any desired optional Attributes. + +4.2. Access-Accept + + Description + + Access-Accept packets are sent by the RADIUS server, and provide + specific configuration information necessary to begin delivery of + service to the user. If all Attribute values received in an + Access-Request are acceptable then the RADIUS implementation MUST + transmit a packet with the Code field set to 2 (Access-Accept). + + + + +Rigney, et al. Standards Track [Page 18] + +RFC 2865 RADIUS June 2000 + + + On reception of an Access-Accept, the Identifier field is matched + with a pending Access-Request. The Response Authenticator field + MUST contain the correct response for the pending Access-Request. + Invalid packets are silently discarded. + + A summary of the Access-Accept packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Access-Accept. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Accept. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 19] + +RFC 2865 RADIUS June 2000 + + +4.3. Access-Reject + + Description + + If any value of the received Attributes is not acceptable, then + the RADIUS server MUST transmit a packet with the Code field set + to 3 (Access-Reject). It MAY include one or more Reply-Message + Attributes with a text message which the NAS MAY display to the + user. + + A summary of the Access-Reject packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Access-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Reject. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney, et al. Standards Track [Page 20] + +RFC 2865 RADIUS June 2000 + + +4.4. Access-Challenge + + Description + + If the RADIUS server desires to send the user a challenge + requiring a response, then the RADIUS server MUST respond to the + Access-Request by transmitting a packet with the Code field set to + 11 (Access-Challenge). + + The Attributes field MAY have one or more Reply-Message + Attributes, and MAY have a single State Attribute, or none. + Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State + attributes MAY also be included. No other Attributes defined in + this document are permitted in an Access-Challenge. + + On receipt of an Access-Challenge, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + If the NAS does not support challenge/response, it MUST treat an + Access-Challenge as though it had received an Access-Reject + instead. + + If the NAS supports challenge/response, receipt of a valid + Access-Challenge indicates that a new Access-Request SHOULD be + sent. The NAS MAY display the text message, if any, to the user, + and then prompt the user for a response. It then sends its + original Access-Request with a new request ID and Request + Authenticator, with the User-Password Attribute replaced by the + user's response (encrypted), and including the State Attribute + from the Access-Challenge, if any. Only 0 or 1 instances of the + State Attribute can be present in an Access-Request. + + A NAS which supports PAP MAY forward the Reply-Message to the + dialing client and accept a PAP response which it can use as + though the user had entered the response. If the NAS cannot do + so, it MUST treat the Access-Challenge as though it had received + an Access-Reject instead. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 21] + +RFC 2865 RADIUS June 2000 + + + A summary of the Access-Challenge packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 11 for Access-Challenge. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Challenge. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization, + information and configuration details for the request and reply. + + The end of the list of Attributes is indicated by the Length of the + RADIUS packet. + + Some Attributes MAY be included more than once. The effect of this + is Attribute specific, and is specified in each Attribute + description. A summary table is provided at the end of the + "Attributes" section. + + + + +Rigney, et al. Standards Track [Page 22] + +RFC 2865 RADIUS June 2000 + + + If multiple Attributes with the same Type are present, the order of + Attributes with the same Type MUST be preserved by any proxies. The + order of Attributes of different Types is not required to be + preserved. A RADIUS server or client MUST NOT have any dependencies + on the order of attributes of different types. A RADIUS server or + client MUST NOT require attributes of the same type to be contiguous. + + Where an Attribute's description limits which kinds of packet it can + be contained in, this applies only to the packet types defined in + this document, namely Access-Request, Access-Accept, Access-Reject + and Access-Challenge (Codes 1, 2, 3, and 11). Other documents + defining other packet types may also use Attributes described here. + To determine which Attributes are allowed in Accounting-Request and + Accounting-Response packets (Codes 4 and 5) refer to the RADIUS + Accounting document [5]. + + Likewise where packet types defined here state that only certain + Attributes are permissible in them, future memos defining new + Attributes should indicate which packet types the new Attributes may + be present in. + + A summary of the 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | 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 [6]. + 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. + + A RADIUS server MAY ignore Attributes with an unknown Type. + + A RADIUS client MAY ignore Attributes with an unknown Type. + + + + + + + + + + +Rigney, et al. Standards Track [Page 23] + +RFC 2865 RADIUS June 2000 + + + This specification concerns the following values: + + 1 User-Name + 2 User-Password + 3 CHAP-Password + 4 NAS-IP-Address + 5 NAS-Port + 6 Service-Type + 7 Framed-Protocol + 8 Framed-IP-Address + 9 Framed-IP-Netmask + 10 Framed-Routing + 11 Filter-Id + 12 Framed-MTU + 13 Framed-Compression + 14 Login-IP-Host + 15 Login-Service + 16 Login-TCP-Port + 17 (unassigned) + 18 Reply-Message + 19 Callback-Number + 20 Callback-Id + 21 (unassigned) + 22 Framed-Route + 23 Framed-IPX-Network + 24 State + 25 Class + 26 Vendor-Specific + 27 Session-Timeout + 28 Idle-Timeout + 29 Termination-Action + 30 Called-Station-Id + 31 Calling-Station-Id + 32 NAS-Identifier + 33 Proxy-State + 34 Login-LAT-Service + 35 Login-LAT-Node + 36 Login-LAT-Group + 37 Framed-AppleTalk-Link + 38 Framed-AppleTalk-Network + 39 Framed-AppleTalk-Zone + 40-59 (reserved for accounting) + 60 CHAP-Challenge + 61 NAS-Port-Type + 62 Port-Limit + 63 Login-LAT-Port + + + + + +Rigney, et al. Standards Track [Page 24] + +RFC 2865 RADIUS June 2000 + + + 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 an Access-Request but with an invalid + Length, an Access-Reject SHOULD be transmitted. If an Attribute + is received in an Access-Accept, Access-Reject or Access-Challenge + packet with an invalid length, the packet MUST either be treated + as an Access-Reject or else 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 + [7] 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 [7] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + 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 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. The + standard Attributes do not use this data type but it is + presented here for possible use in future attributes. + + + + + + + +Rigney, et al. Standards Track [Page 25] + +RFC 2865 RADIUS June 2000 + + +5.1. User-Name + + Description + + This Attribute indicates the name of the user to be authenticated. + It MUST be sent in Access-Request packets if available. + + It MAY be sent in an Access-Accept packet, in which case the + client SHOULD use the name returned in the Access-Accept packet in + all Accounting-Request packets for this session. If the Access- + Accept includes Service-Type = Rlogin and the User-Name attribute, + a NAS MAY use the returned User-Name when performing the Rlogin + function. + + A summary of the User-Name 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 1 for User-Name. + + Length + + >= 3 + + String + + The String field is one or more octets. The NAS may limit the + maximum length of the User-Name but the ability to handle at least + 63 octets is recommended. + + The format of the username MAY be one of several forms: + + text Consisting only of UTF-8 encoded 10646 [7] characters. + + network access identifier + A Network Access Identifier as described in RFC 2486 + [8]. + + distinguished name + A name in ASN.1 form used in Public Key authentication + systems. + + + +Rigney, et al. Standards Track [Page 26] + +RFC 2865 RADIUS June 2000 + + +5.2. User-Password + + Description + + This Attribute indicates the password of the user to be + authenticated, or the user's input following an Access-Challenge. + It is only used in Access-Request packets. + + On transmission, the password is hidden. The password is first + padded at the end with nulls to a multiple of 16 octets. A one- + way MD5 hash is calculated over a stream of octets consisting of + the shared secret followed by the Request Authenticator. This + value is XORed with the first 16 octet segment of the password and + placed in the first 16 octets of the String field of the User- + Password Attribute. + + If the password is longer than 16 characters, a second one-way MD5 + hash is calculated over a stream of octets consisting of the + shared secret followed by the result of the first xor. That hash + is XORed with the second 16 octet segment of the password and + placed in the second 16 octets of the String field of the User- + Password Attribute. + + If necessary, this operation is repeated, with each xor result + being used along with the shared secret to generate the next hash + to xor the next segment of the password, to no more than 128 + characters. + + The method is taken from the book "Network Security" by Kaufman, + Perlman and Speciner [9] pages 109-110. A more precise + explanation of the method follows: + + Call the shared secret S and the pseudo-random 128-bit Request + Authenticator RA. Break the password into 16-octet chunks p1, p2, + etc. with the last one padded at the end with nulls to a 16-octet + boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need + intermediate values b1, b2, etc. + + b1 = MD5(S + RA) c(1) = p1 xor b1 + b2 = MD5(S + c(1)) c(2) = p2 xor b2 + . . + . . + . . + bi = MD5(S + c(i-1)) c(i) = pi xor bi + + The String will contain c(1)+c(2)+...+c(i) where + denotes + concatenation. + + + + +Rigney, et al. Standards Track [Page 27] + +RFC 2865 RADIUS June 2000 + + + On receipt, the process is reversed to yield the original + password. + + A summary of the User-Password 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 2 for User-Password. + + Length + + At least 18 and no larger than 130. + + String + + The String field is between 16 and 128 octets long, inclusive. + +5.3. CHAP-Password + + Description + + This Attribute indicates the response value provided by a PPP + Challenge-Handshake Authentication Protocol (CHAP) user in + response to the challenge. It is only used in Access-Request + packets. + + The CHAP challenge value is found in the CHAP-Challenge Attribute + (60) if present in the packet, otherwise in the Request + Authenticator field. + + A summary of the CHAP-Password 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 4 5 6 7 8 9 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | CHAP Ident | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 28] + +RFC 2865 RADIUS June 2000 + + + Type + + 3 for CHAP-Password. + + Length + + 19 + + CHAP Ident + + This field is one octet, and contains the CHAP Identifier from the + user's CHAP Response. + + String + + The String field is 16 octets, and contains the CHAP Response from + the user. + +5.4. NAS-IP-Address + + Description + + This Attribute indicates the identifying IP Address of the NAS + which is requesting authentication of the user, and SHOULD be + unique to the NAS within the scope of the RADIUS server. NAS-IP- + Address is only used in Access-Request packets. Either NAS-IP- + Address or NAS-Identifier MUST be present in an Access-Request + packet. + + Note that NAS-IP-Address MUST NOT be used to select the shared + secret used to authenticate the request. The source IP address of + the Access-Request packet MUST be used to select the shared + secret. + + A summary of the NAS-IP-Address 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 4 for NAS-IP-Address. + + + +Rigney, et al. Standards Track [Page 29] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Address + + The Address field is four octets. + +5.5. NAS-Port + + Description + + This Attribute indicates the physical port number of the NAS which + is authenticating the user. It is only used in Access-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-Type (61) or both SHOULD + be present in an Access-Request packet, if the NAS differentiates + among its ports. + + A summary of the NAS-Port 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 + + 5 for NAS-Port. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + + +Rigney, et al. Standards Track [Page 30] + +RFC 2865 RADIUS June 2000 + + +5.6. Service-Type + + Description + + This Attribute indicates the type of service the user has + requested, or the type of service to be provided. It MAY be used + in both Access-Request and Access-Accept packets. A NAS is not + required to implement all of these service types, and MUST treat + unknown or unsupported Service-Types as though an Access-Reject + had been received instead. + + A summary of the Service-Type 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 + + 6 for Service-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Login + 2 Framed + 3 Callback Login + 4 Callback Framed + 5 Outbound + 6 Administrative + 7 NAS Prompt + 8 Authenticate Only + 9 Callback NAS Prompt + 10 Call Check + 11 Callback Administrative + + + + + + +Rigney, et al. Standards Track [Page 31] + +RFC 2865 RADIUS June 2000 + + + The service types are defined as follows when used in an Access- + Accept. When used in an Access-Request, they MAY be considered to + be a hint to the RADIUS server that the NAS has reason to believe + the user would prefer the kind of service indicated, but the + server is not required to honor the hint. + + Login The user should be connected to a host. + + Framed A Framed Protocol should be started for the + User, such as PPP or SLIP. + + Callback Login The user should be disconnected and called + back, then connected to a host. + + Callback Framed The user should be disconnected and called + back, then a Framed Protocol should be started + for the User, such as PPP or SLIP. + + Outbound The user should be granted access to outgoing + devices. + + Administrative The user should be granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + + NAS Prompt The user should be provided a command prompt + on the NAS from which non-privileged commands + can be executed. + + Authenticate Only Only Authentication is requested, and no + authorization information needs to be returned + in the Access-Accept (typically used by proxy + servers rather than the NAS itself). + + Callback NAS Prompt The user should be disconnected and called + back, then provided a command prompt on the + NAS from which non-privileged commands can be + executed. + + Call Check Used by the NAS in an Access-Request packet to + indicate that a call is being received and + that the RADIUS server should send back an + Access-Accept to answer the call, or an + Access-Reject to not accept the call, + typically based on the Called-Station-Id or + Calling-Station-Id attributes. It is + + + + + +Rigney, et al. Standards Track [Page 32] + +RFC 2865 RADIUS June 2000 + + + recommended that such Access-Requests use the + value of Calling-Station-Id as the value of + the User-Name. + + Callback Administrative + The user should be disconnected and called + back, then granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + +5.7. Framed-Protocol + + Description + + This Attribute indicates the framing to be used for framed access. + It MAY be used in both Access-Request and Access-Accept packets. + + A summary of the Framed-Protocol 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 + + 7 for Framed-Protocol. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 PPP + 2 SLIP + 3 AppleTalk Remote Access Protocol (ARAP) + 4 Gandalf proprietary SingleLink/MultiLink protocol + 5 Xylogics proprietary IPX/SLIP + 6 X.75 Synchronous + + + + + +Rigney, et al. Standards Track [Page 33] + +RFC 2865 RADIUS June 2000 + + +5.8. Framed-IP-Address + + Description + + This Attribute indicates the address to be configured for the + user. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint by the NAS to the server that + it would prefer that address, but the server is not required to + honor the hint. + + A summary of the Framed-IP-Address 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 for Framed-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS Should allow the user to select an address (e.g. + Negotiated). The value 0xFFFFFFFE indicates that the NAS should + select an address for the user (e.g. Assigned from a pool of + addresses kept by the NAS). Other valid values indicate that the + NAS should use that value as the user's IP address. + +5.9. Framed-IP-Netmask + + Description + + This Attribute indicates the IP netmask to be configured for the + user when the user is a router to a network. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet + as a hint by the NAS to the server that it would prefer that + netmask, but the server is not required to honor the hint. + + + + +Rigney, et al. Standards Track [Page 34] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-IP-Netmask 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 9 for Framed-IP-Netmask. + + Length + + 6 + + Address + + The Address field is four octets specifying the IP netmask of the + user. + +5.10. Framed-Routing + + Description + + This Attribute indicates the routing method for the user, when the + user is a router to a network. It is only used in Access-Accept + packets. + + A summary of the Framed-Routing 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 + + 10 for Framed-Routing. + + + + + +Rigney, et al. Standards Track [Page 35] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 Send routing packets + 2 Listen for routing packets + 3 Send and Listen + +5.11. Filter-Id + + Description + + This Attribute indicates the name of the filter list for this + user. Zero or more Filter-Id attributes MAY be sent in an + Access-Accept packet. + + Identifying a filter list by name allows the filter to be used on + different NASes without regard to filter-list implementation + details. + + A summary of the Filter-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 11 for Filter-Id. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain UTF-8 encoded 10646 [7] characters. + + + +Rigney, et al. Standards Track [Page 36] + +RFC 2865 RADIUS June 2000 + + +5.12. Framed-MTU + + Description + + This Attribute indicates the Maximum Transmission Unit to be + configured for the user, when it is not negotiated by some other + means (such as PPP). It MAY be used in Access-Accept packets. It + MAY be used in an Access-Request packet as a hint by the NAS to + the server that it would prefer that value, but the server is not + required to honor the hint. + + A summary of the Framed-MTU 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 + + 12 for Framed-MTU. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 64 to 65535. + +5.13. Framed-Compression + + Description + + This Attribute indicates a compression protocol to be used for the + link. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint to the server that the NAS + would prefer to use that compression, but the server is not + required to honor the hint. + + More than one compression protocol Attribute MAY be sent. It is + the responsibility of the NAS to apply the proper compression + protocol to appropriate link traffic. + + + +Rigney, et al. Standards Track [Page 37] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-Compression 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 + + 13 for Framed-Compression. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 VJ TCP/IP header compression [10] + 2 IPX header compression + 3 Stac-LZS compression + +5.14. Login-IP-Host + + Description + + This Attribute indicates the system with which to connect the user, + when the Login-Service Attribute is included. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet as + a hint to the server that the NAS would prefer to use that host, but + the server is not required to honor the hint. + + A summary of the Login-IP-Host Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + +Rigney, et al. Standards Track [Page 38] + +RFC 2865 RADIUS 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 14 for Login-IP-Host. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS SHOULD allow the user to select an address. The + value 0 indicates that the NAS SHOULD select a host to connect the + user to. Other values indicate the address the NAS SHOULD connect + the user to. + +5.15. Login-Service + + Description + + This Attribute indicates the service to use to connect the user to + the login host. It is only used in Access-Accept packets. + + A summary of the Login-Service 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 + + 15 for Login-Service. + + + + + + +Rigney, et al. Standards Track [Page 39] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Telnet + 1 Rlogin + 2 TCP Clear + 3 PortMaster (proprietary) + 4 LAT + 5 X25-PAD + 6 X25-T3POS + 8 TCP Clear Quiet (suppresses any NAS-generated connect string) + +5.16. Login-TCP-Port + + Description + + This Attribute indicates the TCP port with which the user is to be + connected, when the Login-Service Attribute is also present. It + is only used in Access-Accept packets. + + A summary of the Login-TCP-Port 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 + + 16 for Login-TCP-Port. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + + + +Rigney, et al. Standards Track [Page 40] + +RFC 2865 RADIUS June 2000 + + +5.17. (unassigned) + + Description + + ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. + +5.18. Reply-Message + + Description + + This Attribute indicates text which MAY be displayed to the user. + + When used in an Access-Accept, it is the success message. + + When used in an Access-Reject, it is the failure message. It MAY + indicate a dialog message to prompt the user before another + Access-Request attempt. + + When used in an Access-Challenge, it MAY indicate a dialog message + to prompt the user for a response. + + Multiple Reply-Message's MAY be included and if any are displayed, + they MUST be displayed in the same order as they appear in the + packet. + + A summary of the Reply-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 18 for Reply-Message. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain UTF-8 encoded 10646 [7] characters. + + + +Rigney, et al. Standards Track [Page 41] + +RFC 2865 RADIUS June 2000 + + +5.19. Callback-Number + + Description + + This Attribute indicates a dialing string to be used for callback. + It MAY be used in Access-Accept packets. It MAY be used in an + Access-Request packet as a hint to the server that a Callback + service is desired, but the server is not required to honor the + hint. + + A summary of the Callback-Number 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 19 for Callback-Number. + + 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. + +5.20. Callback-Id + + Description + + This Attribute indicates the name of a place to be called, to be + interpreted by the NAS. It MAY be used in Access-Accept packets. + + + + + + + + + +Rigney, et al. Standards Track [Page 42] + +RFC 2865 RADIUS June 2000 + + + A summary of the Callback-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 20 for Callback-Id. + + 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. + +5.21. (unassigned) + + Description + + ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. + +5.22. Framed-Route + + Description + + This Attribute provides routing information to be configured for + the user on the NAS. It is used in the Access-Accept packet and + can appear multiple times. + + A summary of the Framed-Route 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + +Rigney, et al. Standards Track [Page 43] + +RFC 2865 RADIUS June 2000 + + + Type + + 22 for Framed-Route. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain UTF-8 encoded 10646 [7] characters. + + For IP routes, it SHOULD contain a destination prefix in dotted + quad form optionally followed by a slash and a decimal length + specifier stating how many high order bits of the prefix to use. + That is followed by a space, a gateway address in dotted quad + form, a space, and one or more metrics separated by spaces. For + example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length + specifier may be omitted, in which case it defaults to 8 bits for + class A prefixes, 16 bits for class B prefixes, and 24 bits for + class C prefixes. For example, "192.168.1.0 192.168.1.1 1". + + Whenever the gateway address is specified as "0.0.0.0" the IP + address of the user SHOULD be used as the gateway address. + +5.23. Framed-IPX-Network + + Description + + This Attribute indicates the IPX Network number to be configured + for the user. It is used in Access-Accept packets. + + A summary of the Framed-IPX-Network 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Rigney, et al. Standards Track [Page 44] + +RFC 2865 RADIUS June 2000 + + + Type + + 23 for Framed-IPX-Network. + + Length + + 6 + + Value + + The Value field is four octets. The value 0xFFFFFFFE indicates + that the NAS should select an IPX network for the user (e.g. + assigned from a pool of one or more IPX networks kept by the NAS). + Other values should be used as the IPX network for the link to the + user. + +5.24. State + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Challenge and MUST be sent unmodified from the client + to the server in the new Access-Request reply to that challenge, + if any. + + This Attribute is available to be sent by the server to the client + in an Access-Accept that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the NAS performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + attribute unchanged in that Access-Request. + + In either usage, the client MUST NOT interpret the attribute + locally. A packet must have only zero or one State Attribute. + Usage of the State Attribute is implementation dependent. + + A summary of the State 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 24 for State. + + + +Rigney, et al. Standards Track [Page 45] + +RFC 2865 RADIUS June 2000 + + + 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. + +5.25. Class + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Accept and SHOULD be sent unmodified by the client to + the accounting server as part of the Accounting-Request packet if + accounting is supported. The client MUST NOT interpret the + attribute locally. + + A summary of the Class 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 25 for Class. + + 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. Standards Track [Page 46] + +RFC 2865 RADIUS June 2000 + + +5.26. Vendor-Specific + + Description + + This Attribute is available to allow vendors to support their own + extended Attributes not suitable for general usage. It MUST not + affect the operation of the RADIUS protocol. + + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do + so (and report they are doing so) in a degraded mode. + + A summary of the Vendor-Specific 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 26 for Vendor-Specific. + + Length + + >= 7 + + Vendor-Id + + The high-order octet is 0 and the low-order 3 octets are the SMI + Network Management Private Enterprise Code of the Vendor in + network byte order, as defined in the "Assigned Numbers" RFC [6]. + + 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. Standards Track [Page 47] + +RFC 2865 RADIUS June 2000 + + + It SHOULD be encoded as a sequence of vendor type / vendor length + / value fields, as follows. The Attribute-Specific field is + dependent on the vendor's definition of that attribute. An + example encoding of the Vendor-Specific attribute using this + method follows: + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | Vendor type | Vendor length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Specific... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Multiple subattributes MAY be encoded within a single Vendor- + Specific attribute, although they do not have to be. + +5.27. Session-Timeout + + Description + + This Attribute sets the maximum number of seconds of service to be + provided to the user before termination of the session or prompt. + This Attribute is available to be sent by the server to the client + in an Access-Accept or Access-Challenge. + + A summary of the Session-Timeout 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 + + 27 for Session-Timeout. + + Length + + 6 + + + + + +Rigney, et al. Standards Track [Page 48] + +RFC 2865 RADIUS June 2000 + + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of seconds this user should be allowed to + remain connected by the NAS. + +5.28. Idle-Timeout + + Description + + This Attribute sets the maximum number of consecutive seconds of + idle connection allowed to the user before termination of the + session or prompt. This Attribute is available to be sent by the + server to the client in an Access-Accept or Access-Challenge. + + A summary of the Idle-Timeout 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 + + 28 for Idle-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of consecutive seconds of idle time this user + should be permitted before being disconnected by the NAS. + +5.29. Termination-Action + + Description + + This Attribute indicates what action the NAS should take when the + specified service is completed. It is only used in Access-Accept + packets. + + + + +Rigney, et al. Standards Track [Page 49] + +RFC 2865 RADIUS June 2000 + + + A summary of the Termination-Action 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 + + 29 for Termination-Action. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Default + 1 RADIUS-Request + + If the Value is set to RADIUS-Request, upon termination of the + specified service the NAS MAY send a new Access-Request to the + RADIUS server, including the State attribute if any. + +5.30. Called-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the user called, using Dialed Number + Identification (DNIS) or similar technology. Note that this may + be different from the phone number the call comes in on. It is + only used in Access-Request packets. + + A summary of the Called-Station-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + +Rigney, et al. Standards Track [Page 50] + +RFC 2865 RADIUS June 2000 + + + Type + + 30 for Called-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user's call came in on. + + The actual format of the information is site or application + specific. UTF-8 encoded 10646 [7] characters are recommended, but + 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. + +5.31. Calling-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the call came from, using Automatic Number + Identification (ANI) or similar technology. It is only used in + Access-Request packets. + + A summary of the Calling-Station-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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 31 for Calling-Station-Id. + + Length + + >= 3 + + + + + +Rigney, et al. Standards Track [Page 51] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, containing the phone + number that the user placed the call from. + + The actual format of the information is site or application + specific. UTF-8 encoded 10646 [7] characters are recommended, but + 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. + +5.32. NAS-Identifier + + Description + + This Attribute contains a string identifying the NAS originating + the Access-Request. It is only used in Access-Request packets. + Either NAS-IP-Address or NAS-Identifier MUST be present in an + Access-Request packet. + + Note that NAS-Identifier MUST NOT be used to select the shared + secret used to authenticate the request. The source IP address of + the Access-Request packet MUST be used to select the shared + secret. + + A summary of the NAS-Identifier 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 32 for NAS-Identifier. + + Length + + >= 3 + + + + + + + + +Rigney, et al. Standards Track [Page 52] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and should be unique to + the NAS within the scope of the RADIUS server. For example, a + fully qualified domain name would be suitable as a NAS-Identifier. + + 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. + +5.33. Proxy-State + + Description + + This Attribute is available to be sent by a proxy server to + another server when forwarding an Access-Request and MUST be + returned unmodified in the Access-Accept, Access-Reject or + Access-Challenge. When the proxy server receives the response to + its request, it MUST remove its own Proxy-State (the last Proxy- + State in the packet) before forwarding the response to the NAS. + + If a Proxy-State Attribute is added to a packet when forwarding + the packet, the Proxy-State Attribute MUST be added after any + existing Proxy-State attributes. + + The content of any Proxy-State other than the one added by the + current server should be treated as opaque octets and MUST NOT + affect operation of the protocol. + + Usage of the Proxy-State Attribute is implementation dependent. A + description of its function is outside the scope of this + specification. + + A summary of the Proxy-State 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 33 for Proxy-State. + + + +Rigney, et al. Standards Track [Page 53] + +RFC 2865 RADIUS June 2000 + + + 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. + +5.34. Login-LAT-Service + + Description + + This Attribute indicates the system with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + Administrators use the service attribute when dealing with + clustered systems, such as a VAX or Alpha cluster. In such an + environment several different time sharing hosts share the same + resources (disks, printers, etc.), and administrators often + configure each to offer access (service) to each of the shared + resources. In this case, each host in the cluster advertises its + services through LAT broadcasts. + + Sophisticated users often know which service providers (machines) + are faster and tend to use a node name when initiating a LAT + connection. Alternately, some administrators want particular + users to use certain machines as a primitive form of load + balancing (although LAT knows how to do load balancing itself). + + A summary of the Login-LAT-Service 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 54] + +RFC 2865 RADIUS June 2000 + + + Type + + 34 for Login-LAT-Service. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT service to use. The LAT Architecture allows this + string to contain $ (dollar), - (hyphen), . (period), _ + (underscore), numerics, upper and lower case alphabetics, and the + ISO Latin-1 character set extension [11]. All LAT string + comparisons are case insensitive. + +5.35. Login-LAT-Node + + Description + + This Attribute indicates the Node with which the user is to be + automatically connected by LAT. It MAY be used in Access-Accept + packets, but only when LAT is specified as the Login-Service. It + MAY be used in an Access-Request packet as a hint to the server, + but the server is not required to honor the hint. + + A summary of the Login-LAT-Node 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 35 for Login-LAT-Node. + + Length + + >= 3 + + + + + + + + +Rigney, et al. Standards Track [Page 55] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and contains the identity + of the LAT Node to connect the user to. The LAT Architecture + allows this string to contain $ (dollar), - (hyphen), . (period), + _ (underscore), numerics, upper and lower case alphabetics, and + the ISO Latin-1 character set extension. All LAT string + comparisons are case insensitive. + +5.36. Login-LAT-Group + + Description + + This Attribute contains a string identifying the LAT group codes + which this user is authorized to use. It MAY be used in Access- + Accept packets, but only when LAT is specified as the Login- + Service. It MAY be used in an Access-Request packet as a hint to + the server, but the server is not required to honor the hint. + + LAT supports 256 different group codes, which LAT uses as a form + of access rights. LAT encodes the group codes as a 256 bit + bitmap. + + Administrators can assign one or more of the group code bits at + the LAT service provider; it will only accept LAT connections that + have these group codes set in the bit map. The administrators + assign a bitmap of authorized group codes to each user; LAT gets + these from the operating system, and uses these in its requests to + the service providers. + + A summary of the Login-LAT-Group 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 36 for Login-LAT-Group. + + Length + + 34 + + + + + +Rigney, et al. Standards Track [Page 56] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is a 32 octet bit map, most significant octet + first. 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. + +5.37. Framed-AppleTalk-Link + + Description + + This Attribute indicates the AppleTalk network number which should + be used for the serial link to the user, which is another + AppleTalk router. It is only used in Access-Accept packets. It + is never used when the user is not another router. + + A summary of the Framed-AppleTalk-Link 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 + + 37 for Framed-AppleTalk-Link. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value of 0 indicates + that this is an unnumbered serial link. A value of 1-65535 means + that the serial line between the NAS and the user should be + assigned that value as an AppleTalk network number. + + + + + + + +Rigney, et al. Standards Track [Page 57] + +RFC 2865 RADIUS June 2000 + + +5.38. Framed-AppleTalk-Network + + Description + + This Attribute indicates the AppleTalk Network number which the + NAS should probe to allocate an AppleTalk node for the user. It + is only used in Access-Accept packets. It is never used when the + user is another router. Multiple instances of this Attribute + indicate that the NAS may probe using any of the network numbers + specified. + + A summary of the Framed-AppleTalk-Network 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 + + 38 for Framed-AppleTalk-Network. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value 0 indicates that + the NAS should assign a network for the user, using its default + cable range. A value between 1 and 65535 (inclusive) indicates + the AppleTalk Network the NAS should probe to find an address for + the user. + +5.39. Framed-AppleTalk-Zone + + Description + + This Attribute indicates the AppleTalk Default Zone to be used for + this user. It is only used in Access-Accept packets. Multiple + instances of this attribute in the same packet are not allowed. + + + + + +Rigney, et al. Standards Track [Page 58] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-AppleTalk-Zone 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 4 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 39 for Framed-AppleTalk-Zone. + + Length + + >= 3 + + String + + The name of the Default AppleTalk Zone to be used for this user. + 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. + +5.40. CHAP-Challenge + + Description + + This Attribute contains the CHAP Challenge sent by the NAS to a + PPP Challenge-Handshake Authentication Protocol (CHAP) user. It + is only used in Access-Request packets. + + If the CHAP challenge value is 16 octets long it MAY be placed in + the Request Authenticator field instead of using this attribute. + + A summary of the CHAP-Challenge 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... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 59] + +RFC 2865 RADIUS June 2000 + + + Type + + 60 for CHAP-Challenge. + + Length + + >= 7 + + String + + The String field contains the CHAP Challenge. + +5.41. NAS-Port-Type + + Description + + This Attribute indicates the type of the physical port of the NAS + which is authenticating the user. It can be used instead of or in + addition to the NAS-Port (5) attribute. It is only used in + Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or + both SHOULD be present in an Access-Request packet, if the NAS + differentiates among its ports. + + A summary of the NAS-Port-Type 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 + + 61 for NAS-Port-Type. + + Length + + 6 + + Value + + The Value field is four octets. "Virtual" refers to a connection + to the NAS via some transport protocol, instead of through a + physical port. For example, if a user telnetted into a NAS to + + + + +Rigney, et al. Standards Track [Page 60] + +RFC 2865 RADIUS June 2000 + + + authenticate himself as an Outbound-User, the Access-Request might + include NAS-Port-Type = Virtual as a hint to the RADIUS server + that the user was not on a physical port. + + 0 Async + 1 Sync + 2 ISDN Sync + 3 ISDN Async V.120 + 4 ISDN Async V.110 + 5 Virtual + 6 PIAFS + 7 HDLC Clear Channel + 8 X.25 + 9 X.75 + 10 G.3 Fax + 11 SDSL - Symmetric DSL + 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase + Modulation + 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone + 14 IDSL - ISDN Digital Subscriber Line + 15 Ethernet + 16 xDSL - Digital Subscriber Line of unknown type + 17 Cable + 18 Wireless - Other + 19 Wireless - IEEE 802.11 + + PIAFS is a form of wireless ISDN commonly used in Japan, and + stands for PHS (Personal Handyphone System) Internet Access Forum + Standard (PIAFS). + +5.42. Port-Limit + + Description + + This Attribute sets the maximum number of ports to be provided to + the user by the NAS. This Attribute MAY be sent by the server to + the client in an Access-Accept packet. It is intended for use in + conjunction with Multilink PPP [12] or similar uses. It MAY also + be sent by the NAS to the server as a hint that that many ports + are desired for use, but the server is not required to honor the + hint. + + A summary of the Port-Limit Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + +Rigney, et al. Standards Track [Page 61] + +RFC 2865 RADIUS 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 + + 62 for Port-Limit. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of ports this user should be allowed to connect + to on the NAS. + +5.43. Login-LAT-Port + + Description + + This Attribute indicates the Port with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + A summary of the Login-LAT-Port 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 63 for Login-LAT-Port. + + Length + + >= 3 + + + +Rigney, et al. Standards Track [Page 62] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and contains the identity + of the LAT port to use. The LAT Architecture allows this string + to contain $ (dollar), - (hyphen), . (period), _ (underscore), + numerics, upper and lower case alphabetics, and the ISO Latin-1 + character set extension. All LAT string comparisons are case + insensitive. + +5.44. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge # Attribute + 0-1 0-1 0 0 1 User-Name + 0-1 0 0 0 2 User-Password [Note 1] + 0-1 0 0 0 3 CHAP-Password [Note 1] + 0-1 0 0 0 4 NAS-IP-Address [Note 2] + 0-1 0 0 0 5 NAS-Port + 0-1 0-1 0 0 6 Service-Type + 0-1 0-1 0 0 7 Framed-Protocol + 0-1 0-1 0 0 8 Framed-IP-Address + 0-1 0-1 0 0 9 Framed-IP-Netmask + 0 0-1 0 0 10 Framed-Routing + 0 0+ 0 0 11 Filter-Id + 0-1 0-1 0 0 12 Framed-MTU + 0+ 0+ 0 0 13 Framed-Compression + 0+ 0+ 0 0 14 Login-IP-Host + 0 0-1 0 0 15 Login-Service + 0 0-1 0 0 16 Login-TCP-Port + 0 0+ 0+ 0+ 18 Reply-Message + 0-1 0-1 0 0 19 Callback-Number + 0 0-1 0 0 20 Callback-Id + 0 0+ 0 0 22 Framed-Route + 0 0-1 0 0 23 Framed-IPX-Network + 0-1 0-1 0 0-1 24 State [Note 1] + 0 0+ 0 0 25 Class + 0+ 0+ 0 0+ 26 Vendor-Specific + 0 0-1 0 0-1 27 Session-Timeout + 0 0-1 0 0-1 28 Idle-Timeout + 0 0-1 0 0 29 Termination-Action + 0-1 0 0 0 30 Called-Station-Id + 0-1 0 0 0 31 Calling-Station-Id + 0-1 0 0 0 32 NAS-Identifier [Note 2] + 0+ 0+ 0+ 0+ 33 Proxy-State + 0-1 0-1 0 0 34 Login-LAT-Service + 0-1 0-1 0 0 35 Login-LAT-Node + + + +Rigney, et al. Standards Track [Page 63] + +RFC 2865 RADIUS June 2000 + + + 0-1 0-1 0 0 36 Login-LAT-Group + 0 0-1 0 0 37 Framed-AppleTalk-Link + 0 0+ 0 0 38 Framed-AppleTalk-Network + 0 0-1 0 0 39 Framed-AppleTalk-Zone + 0-1 0 0 0 60 CHAP-Challenge + 0-1 0 0 0 61 NAS-Port-Type + 0-1 0-1 0 0 62 Port-Limit + 0-1 0-1 0 0 63 Login-LAT-Port + Request Accept Reject Challenge # Attribute + + [Note 1] An Access-Request MUST contain either a User-Password or a + CHAP-Password or State. An Access-Request MUST NOT contain both a + User-Password and a CHAP-Password. If future extensions allow other + kinds of authentication information to be conveyed, the attribute for + that can be used in an Access-Request instead of User-Password or + CHAP-Password. + + [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a + NAS-Identifier (or both). + + The following table defines the meaning of the above table entries. + +0 This attribute MUST NOT be present in packet. +0+ Zero or more instances of this attribute MAY be present in packet. +0-1 Zero or one instance of this attribute MAY be present in packet. +1 Exactly one instance of this attribute MUST be present in packet. + +6. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding registration of values related to the + RADIUS protocol, in accordance with BCP 26 [13]. + + There are three name spaces in RADIUS that require registration: + Packet Type Codes, Attribute Types, and Attribute Values (for certain + Attributes). + + RADIUS is not intended as a general-purpose Network Access Server + (NAS) management protocol, and allocations should not be made for + purposes unrelated to Authentication, Authorization or Accounting. + +6.1. Definition of Terms + + The following terms are used here with the meanings defined in + BCP 26: "name space", "assigned value", "registration". + + + + + + +Rigney, et al. Standards Track [Page 64] + +RFC 2865 RADIUS June 2000 + + + The following policies are used here with the meanings defined in + BCP 26: "Private Use", "First Come First Served", "Expert Review", + "Specification Required", "IETF Consensus", "Standards Action". + +6.2. Recommended Registration Policies + + For registration requests where a Designated Expert should be + consulted, the IESG Area Director for Operations should appoint the + Designated Expert. + + For registration requests requiring Expert Review, the ietf-radius + mailing list should be consulted. + + Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have + been allocated. Because a new Packet Type has considerable impact on + interoperability, a new Packet Type Code requires Standards Action, + and should be allocated starting at 14. + + Attribute Types have a range from 1 to 255, and are the scarcest + resource in RADIUS, thus must be allocated with care. Attributes + 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for + re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated + following Expert Review, with Specification Required. Release of + blocks of Attribute Types (more than 3 at a time for a given purpose) + should require IETF Consensus. It is recommended that attributes 17 + and 21 be used only after all others are exhausted. + + Note that RADIUS defines a mechanism for Vendor-Specific extensions + (Attribute 26) and the use of that should be encouraged instead of + allocation of global attribute types, for functions specific only to + one vendor's implementation of RADIUS, where no interoperability is + deemed useful. + + As stated in the "Attributes" section above: + + "[Attribute Type] 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." + + Therefore Attribute values 192-240 are considered Private Use, and + values 241-255 require Standards Action. + + Certain attributes (for example, NAS-Port-Type) in RADIUS define a + list of values to correspond with various meanings. There can be 4 + billion (2^32) values for each attribute. Adding additional values to + the list can be done on a First Come, First Served basis by the IANA. + + + + + +Rigney, et al. Standards Track [Page 65] + +RFC 2865 RADIUS June 2000 + + +7. Examples + + A few examples are presented to illustrate the flow of packets and + use of typical attributes. These examples are not intended to be + exhaustive, many others are possible. Hexadecimal dumps of the + example packets are given in network byte order, using the shared + secret "xyzzy5461". + +7.1. User Telnet to Specified Host + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named nemo logging in on port 3 with + password "arctangent". + + The Request Authenticator is a 16 octet random number generated by + the NAS. + + The User-Password is 16 octets of password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator). + + 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb + 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d + 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 + 01 10 05 06 00 00 00 03 + + 1 Code = Access-Request (1) + 1 ID = 0 + 2 Length = 56 + 16 Request Authenticator + + Attributes: + 6 User-Name = "nemo" + 18 User-Password + 6 NAS-IP-Address = 192.168.1.16 + 6 NAS-Port = 3 + + The RADIUS server authenticates nemo, and sends an Access-Accept UDP + packet to the NAS telling it to telnet nemo to host 192.168.1.3. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (2), id (0), Length (38), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + + + + + + + + +Rigney, et al. Standards Track [Page 66] + +RFC 2865 RADIUS June 2000 + + + 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf + 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 + 0e 06 c0 a8 01 03 + + 1 Code = Access-Accept (2) + 1 ID = 0 (same as in Access-Request) + 2 Length = 38 + 16 Response Authenticator + + Attributes: + 6 Service-Type (6) = Login (1) + 6 Login-Service (15) = Telnet (0) + 6 Login-IP-Host (14) = 192.168.1.3 + +7.2. Framed User Authenticating with CHAP + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named flopsy logging in on port 20 with PPP, + authenticating using CHAP. The NAS sends along the Service-Type and + Framed-Protocol attributes as a hint to the RADIUS server that this + user is looking for PPP, although the NAS is not required to do so. + + The Request Authenticator is a 16 octet random number generated by + the NAS, and is also used as the CHAP Challenge. + + The CHAP-Password consists of a 1 octet CHAP ID, in this case 22, + followed by the 16 octet CHAP response. + + 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e + 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 + 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 + 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 + 02 07 06 00 00 00 01 + + 1 Code = 1 (Access-Request) + 1 ID = 1 + 2 Length = 71 + 16 Request Authenticator + + Attributes: + 8 User-Name (1) = "flopsy" + 19 CHAP-Password (3) + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 20 + 6 Service-Type (6) = Framed (2) + 6 Framed-Protocol (7) = PPP (1) + + + + + +Rigney, et al. Standards Track [Page 67] + +RFC 2865 RADIUS June 2000 + + + The RADIUS server authenticates flopsy, and sends an Access-Accept + UDP packet to the NAS telling it to start PPP service and assign an + address for the user out of its dynamic address pool. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (2), id (1), Length (56), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 + 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01 + 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 + 00 01 0c 06 00 00 05 dc + + 1 Code = Access-Accept (2) + 1 ID = 1 (same as in Access-Request) + 2 Length = 56 + 16 Response Authenticator + + Attributes: + 6 Service-Type (6) = Framed (2) + 6 Framed-Protocol (7) = PPP (1) + 6 Framed-IP-Address (8) = 255.255.255.254 + 6 Framed-Routing (10) = None (0) + 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1) + 6 Framed-MTU (12) = 1500 + +7.3. User with Challenge-Response card + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named mopsy logging in on port 7. The user + enters the dummy password "challenge" in this example. The challenge + and response generated by the smart card for this example are + "32769430" and "99101462". + + The Request Authenticator is a 16 octet random number generated by + the NAS. + + The User-Password is 16 octets of password, in this case "challenge", + padded at the end with nulls, XORed with MD5(shared secret|Request + Authenticator). + + 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 + 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 + 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 + a8 01 10 05 06 00 00 00 07 + + + + + + +Rigney, et al. Standards Track [Page 68] + +RFC 2865 RADIUS June 2000 + + + 1 Code = Access-Request (1) + 1 ID = 2 + 2 Length = 57 + 16 Request Authenticator + + Attributes: + 7 User-Name (1) = "mopsy" + 18 User-Password (2) + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 7 + + The RADIUS server decides to challenge mopsy, sending back a + challenge string and looking for a response. The RADIUS server + therefore and sends an Access-Challenge UDP packet to the NAS. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (11), id (2), length (78), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + The Reply-Message is "Challenge 32769430. Enter response at prompt." + + The State is a magic cookie to be returned along with user's + response; in this example 8 octets of data (33 32 37 36 39 34 33 30 + in hex). + + 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c + 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 + 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 + 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f + 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30 + + 1 Code = Access-Challenge (11) + 1 ID = 2 (same as in Access-Request) + 2 Length = 78 + 16 Response Authenticator + + Attributes: + 48 Reply-Message (18) + 10 State (24) + + The user enters his response, and the NAS send a new Access-Request + with that response, and includes the State Attribute. + + The Request Authenticator is a new 16 octet random number. + + The User-Password is 16 octets of the user's response, in this case + "99101462", padded at the end with nulls, XORed with MD5(shared + secret|Request Authenticator). + + + +Rigney, et al. Standards Track [Page 69] + +RFC 2865 RADIUS June 2000 + + + The state is the magic cookie from the Access-Challenge packet, + unchanged. + + 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 + c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f + 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 + a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 + 34 33 30 + + 1 Code = Access-Request (1) + 1 ID = 3 (Note that this changes.) + 2 Length = 67 + 16 Request Authenticator + + Attributes: + 7 User-Name = "mopsy" + 18 User-Password + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 7 + 10 State (24) + + The Response was incorrect (for the sake of example), so the RADIUS + server tells the NAS to reject the login attempt. + + The Response Authenticator is a 16 octet MD5 checksum of the code + (3), id (3), length(20), the Request Authenticator from above, the + attributes in this reply (in this case, none), and the shared secret. + + 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f + 9e 74 6a a0 + + 1 Code = Access-Reject (3) + 1 ID = 3 (same as in Access-Request) + 2 Length = 20 + 16 Response Authenticator + + Attributes: + (none, although a Reply-Message could be sent) + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 70] + +RFC 2865 RADIUS June 2000 + + +8. Security Considerations + + Security issues are the primary topic of this document. + + In practice, within or associated with each RADIUS server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set. Instead, for each named user there should + be an indication of exactly one method used to authenticate that user + name. If a user needs to make use of different authentication + methods under different circumstances, then distinct user names + SHOULD be employed, each of which identifies exactly one + authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. It is possible to achieve this with SNMP Security + Protocols [14], but such a mechanism is outside the scope of this + specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document [14] also has an + excellent overview of threats to network protocols. + + The User-Password hiding mechanism described in Section 5.2 has not + been subjected to significant amounts of cryptanalysis in the + published literature. Some in the IETF community are concerned that + this method might not provide sufficient confidentiality protection + [15] to passwords transmitted using RADIUS. Users should evaluate + their threat environment and consider whether additional security + mechanisms should be employed. + +9. Change Log + + The following changes have been made from RFC 2138: + + Strings should use UTF-8 instead of US-ASCII and should be handled as + 8-bit data. + + Integers and dates are now defined as 32 bit unsigned values. + + + +Rigney, et al. Standards Track [Page 71] + +RFC 2865 RADIUS June 2000 + + + Updated list of attributes that can be included in Access-Challenge + to be consistent with the table of attributes. + + User-Name mentions Network Access Identifiers. + + User-Name may now be sent in Access-Accept for use with accounting + and Rlogin. + + Values added for Service-Type, Login-Service, Framed-Protocol, + Framed-Compression, and NAS-Port-Type. + + NAS-Port can now use all 32 bits. + + Examples now include hexadecimal displays of the packets. + + Source UDP port must be used in conjunction with the Request + Identifier when identifying duplicates. + + Multiple subattributes may be allowed in a Vendor-Specific attribute. + + An Access-Request is now required to contain either a NAS-IP-Address + or NAS-Identifier (or may contain both). + + Added notes under "Operations" with more information on proxy, + retransmissions, and keep-alives. + + If multiple Attributes with the same Type are present, the order of + Attributes with the same Type MUST be preserved by any proxies. + + Clarified Proxy-State. + + Clarified that Attributes must not depend on position within the + packet, as long as Attributes of the same type are kept in order. + + Added IANA Considerations section. + + Updated section on "Proxy" under "Operations". + + Framed-MTU can now be sent in Access-Request as a hint. + + Updated Security Considerations. + + Text strings identified as a subset of string, to clarify use of + UTF-8. + + + + + + + +Rigney, et al. Standards Track [Page 72] + +RFC 2865 RADIUS June 2000 + + +10. References + + [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, April + 1997. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", + RFC 1321, April 1992. + + [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC + 2486, January 1999. + + [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: + Private Communications in a Public World", Prentice Hall, March + 1995, ISBN 0-13-061466-1. + + [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial + links", RFC 1144, February 1990. + + [11] ISO 8859. International Standard -- Information Processing -- + 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin + Alphabet No. 1, ISO 8859-1:1987. + + [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. + Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August + 1996. + + [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + [14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security + Protocols", RFC 1352, July 1992. + + + + +Rigney, et al. Standards Track [Page 73] + +RFC 2865 RADIUS June 2000 + + + [15] Dobbertin, H., "The Status of MD5 After a Recent Attack", + CryptoBytes Vol.2 No.2, Summer 1996. + +11. Acknowledgements + + RADIUS was originally developed by Steve Willens of Livingston + Enterprises for their PortMaster series of Network Access Servers. + +12. Chair's Address + + The 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. Standards Track [Page 74] + +RFC 2865 RADIUS June 2000 + + +13. Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + Allan C. Rubens + Merit Network, Inc. + 4251 Plymouth Road + Ann Arbor, Michigan 48105-2785 + + EMail: acr@merit.edu + + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: wsimpson@greendragon.com + + + Steve Willens + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: steve@livingston.com + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 75] + +RFC 2865 RADIUS June 2000 + + +14. 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. Standards Track [Page 76] + diff --git a/doc/rfc2866.txt b/doc/rfc2866.txt new file mode 100644 index 0000000..82da1dc --- /dev/null +++ b/doc/rfc2866.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2866 Livingston +Category: Informational June 2000 +Obsoletes: 2139 + + + RADIUS Accounting + +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 a protocol for carrying accounting + information between a Network Access Server and a shared Accounting + Server. + +Implementation Note + + This memo documents the RADIUS Accounting protocol. The early + deployment of RADIUS Accounting was done using UDP port number 1646, + which conflicts with the "sa-msg-port" service. The officially + assigned port number for RADIUS Accounting is 1813. + +Table of Contents + + 1. Introduction .................................... 2 + 1.1 Specification of Requirements ................. 3 + 1.2 Terminology ................................... 3 + 2. Operation ....................................... 4 + 2.1 Proxy ......................................... 4 + 3. Packet Format ................................... 5 + 4. Packet Types ................................... 7 + 4.1 Accounting-Request ............................ 8 + 4.2 Accounting-Response ........................... 9 + 5. Attributes ...................................... 10 + 5.1 Acct-Status-Type .............................. 12 + 5.2 Acct-Delay-Time ............................... 13 + 5.3 Acct-Input-Octets ............................. 14 + 5.4 Acct-Output-Octets ............................ 15 + 5.5 Acct-Session-Id ............................... 15 + + + +Rigney Informational [Page 1] + +RFC 2866 RADIUS Accounting June 2000 + + + 5.6 Acct-Authentic ................................ 16 + 5.7 Acct-Session-Time ............................. 17 + 5.8 Acct-Input-Packets ............................ 18 + 5.9 Acct-Output-Packets ........................... 18 + 5.10 Acct-Terminate-Cause .......................... 19 + 5.11 Acct-Multi-Session-Id ......................... 21 + 5.12 Acct-Link-Count ............................... 22 + 5.13 Table of Attributes ........................... 23 + 6. IANA Considerations ............................. 25 + 7. Security Considerations ......................... 25 + 8. Change Log ...................................... 25 + 9. References ...................................... 26 + 10. Acknowledgements ................................ 26 + 11. Chair's Address ................................. 26 + 12. Author's Address ................................ 27 + 13. Full Copyright Statement ........................ 28 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + The RADIUS (Remote Authentication Dial In User Service) document [2] + specifies the RADIUS protocol used for Authentication and + Authorization. This memo extends the use of the RADIUS protocol to + cover delivery of accounting information from the Network Access + Server (NAS) to a RADIUS accounting server. + + This document obsoletes RFC 2139 [1]. A summary of the changes + between this document and RFC 2139 is available in the "Change Log" + appendix. + + Key features of RADIUS Accounting are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of the + RADIUS accounting server. The client is responsible for + passing user accounting information to a designated RADIUS + accounting server. + + + + + +Rigney Informational [Page 2] + +RFC 2866 RADIUS Accounting June 2000 + + + The RADIUS accounting server is responsible for receiving the + accounting request and returning a response to the client + indicating that it has successfully received the request. + + The RADIUS accounting server can act as a proxy client to + other kinds of accounting servers. + + Network Security + + Transactions between the client and RADIUS accounting server + are authenticated through the use of a shared secret, which is + never sent over the network. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + 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 [3]. These + key words mean the same thing whether capitalized or not. + +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 + 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 with + its own Acct-Session-Id. + + 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. + + + +Rigney Informational [Page 3] + +RFC 2866 RADIUS Accounting June 2000 + + +2. Operation + + When a client is configured to use RADIUS Accounting, at the start of + service delivery it will generate an Accounting Start packet + describing the type of service being delivered and the user it is + being delivered to, and will send that to the RADIUS Accounting + server, which will send back an acknowledgement that the packet has + been received. At the end of service delivery the client will + generate an Accounting Stop packet describing the type of service + that was delivered and optionally statistics such as elapsed time, + input and output octets, or input and output packets. It will send + that to the RADIUS Accounting server, which will send back an + acknowledgement that the packet has been received. + + The Accounting-Request (whether for Start or Stop) is submitted to + the RADIUS accounting server via the network. It is recommended that + the client continue attempting to send the Accounting-Request packet + until it receives an acknowledgement, using some form of backoff. If + no response is returned within a length of time, the request is re- + sent a number of times. The client can also forward requests to an + alternate server or servers in the event that the primary server is + down or unreachable. An alternate server can be used either after a + number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + The RADIUS accounting server MAY make requests of other servers in + order to satisfy the request, in which case it acts as a client. + + If the RADIUS accounting server is unable to successfully record the + accounting packet it MUST NOT send an Accounting-Response + acknowledgment to the client. + +2.1. Proxy + + See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy + Accounting RADIUS works the same way, as illustrated by the following + example. + + 1. The NAS sends an accounting-request to the forwarding server. + + 2. The forwarding server logs the accounting-request (if desired), + adds its Proxy-State (if desired) after any other Proxy-State + attributes, updates the Request Authenticator, and forwards the + request to the remote server. + + + + + + +Rigney Informational [Page 4] + +RFC 2866 RADIUS Accounting June 2000 + + + 3. The remote server logs the accounting-request (if desired), + copies all Proxy-State attributes in order and unmodified from + the request to the response packet, and sends the accounting- + response to the forwarding server. + + 4. The forwarding server strips the last Proxy-State (if it added + one in step 2), updates the Response Authenticator and sends + the accounting-response to the NAS. + + A forwarding server MUST not modify existing Proxy-State or Class + attributes present in the packet. + + A forwarding server may either perform its forwarding function in a + pass through manner, where it sends retransmissions on as soon as it + gets them, or it may take responsibility for retransmissions, for + example in cases where the network link between forwarding and remote + server has very different characteristics than the link between NAS + and forwarding server. + + Extreme care should be used when implementing a proxy server that + takes responsibility for retransmissions so that its retransmission + policy is robust and scalable. + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [4], where the UDP Destination Port field indicates 1813 + (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS Accounting protocol. The early + deployment of RADIUS Accounting was done using UDP port number 1646, + which conflicts with the "sa-msg-port" service. The officially + assigned port number for RADIUS Accounting is 1813. + + A summary of the RADIUS data format is shown below. The fields are + transmitted from left to right. + + + + + + + + + + + + +Rigney Informational [Page 5] + +RFC 2866 RADIUS Accounting 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it + is silently discarded. + + RADIUS Accounting Codes (decimal) are assigned as follows: + + 4 Accounting-Request + 5 Accounting-Response + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS server can detect a duplicate request if + it has the same client source IP address and source UDP port and + Identifier within a short span of time. + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and maximum length + is 4095. + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the messages between the client and RADIUS accounting + server. + + + +Rigney Informational [Page 6] + +RFC 2866 RADIUS Accounting June 2000 + + + Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 + octet MD5 [5] checksum, called the Request Authenticator. + + The NAS and RADIUS accounting server share a secret. The Request + Authenticator field in Accounting-Request packets contains a one- + way MD5 hash calculated over a stream of octets consisting of the + Code + Identifier + Length + 16 zero octets + request attributes + + shared secret (where + indicates concatenation). The 16 octet MD5 + hash value is stored in the Authenticator field of the + Accounting-Request packet. + + Note that the Request Authenticator of an Accounting-Request can + not be done the same way as the Request Authenticator of a RADIUS + Access-Request, because there is no User-Password attribute in an + Accounting-Request. + + Response Authenticator + + The Authenticator field in an Accounting-Response packet is called + the Response Authenticator, and contains a one-way MD5 hash + calculated over a stream of octets consisting of the Accounting- + Response Code, Identifier, Length, the Request Authenticator field + from the Accounting-Request packet being replied to, and the + response attributes if any, followed by the shared secret. The + resulting 16 octet MD5 hash value is stored in the Authenticator + field of the Accounting-Response packet. + + Attributes + + Attributes may have multiple instances, in such a case the order + of attributes of the same type SHOULD be preserved. The order of + attributes of different types is not required to be preserved. + +4. Packet Types + + The RADIUS packet type is determined by the Code field in the first + octet of the packet. + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2866 RADIUS Accounting June 2000 + + +4.1. Accounting-Request + + Description + + Accounting-Request packets are sent from a client (typically a + Network Access Server or its proxy) to a RADIUS accounting server, + and convey information used to provide accounting for a service + provided to a user. The client transmits a RADIUS packet with the + Code field set to 4 (Accounting-Request). + + Upon receipt of an Accounting-Request, the server MUST transmit an + Accounting-Response reply if it successfully records the + accounting packet, and MUST NOT transmit any reply if it fails to + record the accounting packet. + + Any attribute valid in a RADIUS Access-Request or Access-Accept + packet is valid in a RADIUS Accounting-Request packet, except that + the following attributes MUST NOT be present in an Accounting- + Request: User-Password, CHAP-Password, Reply-Message, State. + Either NAS-IP-Address or NAS-Identifier MUST be present in a + RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- + Port-Type attribute or both unless the service does not involve a + port or the NAS does not distinguish among its ports. + + If the Accounting-Request packet includes a Framed-IP-Address, + that attribute MUST contain the IP address of the user. If the + Access-Accept used the special values for Framed-IP-Address + telling the NAS to assign or negotiate an IP address for the user, + the Framed-IP-Address (if any) in the Accounting-Request MUST + contain the actual IP address assigned or negotiated. + + A summary of the Accounting-Request packet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + + + +Rigney Informational [Page 8] + +RFC 2866 RADIUS Accounting June 2000 + + + Code + + 4 for Accounting-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + Note that if Acct-Delay-Time is included in the attributes of an + Accounting-Request then the Acct-Delay-Time value will be updated + when the packet is retransmitted, changing the content of the + Attributes field and requiring a new Identifier and Request + Authenticator. + + Request Authenticator + + The Request Authenticator of an Accounting-Request contains a 16-octet + MD5 hash value calculated according to the method described in + "Request Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + Attributes. + +4.2. Accounting-Response + + Description + + Accounting-Response packets are sent by the RADIUS accounting + server to the client to acknowledge that the Accounting-Request + has been received and recorded successfully. If the Accounting- + Request was recorded successfully then the RADIUS accounting + server MUST transmit a packet with the Code field set to 5 + (Accounting-Response). On reception of an Accounting-Response by + the client, the Identifier field is matched with a pending + Accounting-Request. The Response Authenticator field MUST contain + the correct response for the pending Accounting-Request. Invalid + packets are silently discarded. + + A RADIUS Accounting-Response is not required to have any + attributes in it. + + A summary of the Accounting-Response packet format is shown below. + The fields are transmitted from left to right. + + + +Rigney Informational [Page 9] + +RFC 2866 RADIUS Accounting 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 5 for Accounting-Response. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Accounting-Request which caused this Accounting-Response. + + Response Authenticator + + The Response Authenticator of an Accounting-Response contains a + 16-octet MD5 hash value calculated according to the method + described in "Response Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +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 end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is shown below. The fields are + transmitted from left to right. + + + + +Rigney Informational [Page 10] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 [6]. + 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 RADIUS document [2]) + 40 Acct-Status-Type + 41 Acct-Delay-Time + 42 Acct-Input-Octets + 43 Acct-Output-Octets + 44 Acct-Session-Id + 45 Acct-Authentic + 46 Acct-Session-Time + 47 Acct-Input-Packets + 48 Acct-Output-Packets + 49 Acct-Terminate-Cause + 50 Acct-Multi-Session-Id + 51 Acct-Link-Count + 60+ (refer to RADIUS document [2]) + + 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 an Accounting-Request with an invalid + Length, the entire request MUST 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 + + + +Rigney Informational [Page 11] + +RFC 2866 RADIUS Accounting June 2000 + + + [7] 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 [7] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + 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 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. The + standard Attributes do not use this data type but it is + presented here for possible use in future attributes. + +5.1. Acct-Status-Type + + Description + + This attribute indicates whether this Accounting-Request marks the + beginning of the user service (Start) or the end (Stop). + + It MAY be used by the client to mark the start of accounting (for + example, upon booting) by specifying Accounting-On and to mark the + end of accounting (for example, just before a scheduled reboot) by + specifying Accounting-Off. + + A summary of the Acct-Status-Type 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Rigney Informational [Page 12] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 3 Interim-Update + 7 Accounting-On + 8 Accounting-Off + 9-14 Reserved for Tunnel Accounting + 15 Reserved for Failed + +5.2. Acct-Delay-Time + + Description + + This attribute indicates how many seconds the client has been + trying to send this record for, and can be subtracted from the + time of arrival on the server to find the approximate time of the + event generating this Accounting-Request. (Network transit time + is ignored.) + + Note that changing the Acct-Delay-Time causes the Identifier to + change; see the discussion under Identifier above. + + A summary of the Acct-Delay-Time 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Rigney Informational [Page 13] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 41 for Acct-Delay-Time. + + Length + + 6 + + Value + + The Value field is four octets. + +5.3. Acct-Input-Octets + + Description + + This attribute indicates how many octets have been received from + the port 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. + + A summary of the Acct-Input-Octets 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 + + 42 for Acct-Input-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + +Rigney Informational [Page 14] + +RFC 2866 RADIUS Accounting June 2000 + + +5.4. Acct-Output-Octets + + Description + + This attribute indicates how many octets have been sent to the + port 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. + + A summary of the Acct-Output-Octets 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 + + 43 for Acct-Output-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.5. Acct-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to match + start and stop records in a log file. The start and stop records + for a given session MUST have the same Acct-Session-Id. An + Accounting-Request packet MUST have an Acct-Session-Id. An + Access-Request packet MAY have an Acct-Session-Id; if it does, + then the NAS MUST use the same Acct-Session-Id in the Accounting- + Request packets for that session. + + The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] + characters. + + + + + +Rigney Informational [Page 15] + +RFC 2866 RADIUS Accounting June 2000 + + + For example, one implementation uses a string with an 8-digit + upper case hexadecimal number, the first two digits increment on + each reboot (wrapping every 256 reboots) and the next 6 digits + counting from 0 for the first person logging in after a reboot up + to 2^24-1, about 16 million. Other encodings are possible. + + A summary of the Acct-Session-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 + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of UTF-8 encoded 10646 [7] + characters. + +5.6. Acct-Authentic + + Description + + This attribute MAY be included in an Accounting-Request to + indicate how the user was authenticated, whether by RADIUS, the + NAS itself, or another remote authentication protocol. Users who + are delivered service without being authenticated SHOULD NOT + generate Accounting records. + + A summary of the Acct-Authentic 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 16] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 45 for Acct-Authentic. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 RADIUS + 2 Local + 3 Remote + +5.7. Acct-Session-Time + + Description + + This attribute indicates how many seconds the user has received + service for, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Session-Time 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 + + 46 for Acct-Session-Time. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + +Rigney Informational [Page 17] + +RFC 2866 RADIUS Accounting June 2000 + + +5.8. Acct-Input-Packets + + Description + + This attribute indicates how many packets have been received from + the port over the course of this service being provided to a + Framed User, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Input-packets 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 + + 47 for Acct-Input-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.9. Acct-Output-Packets + + Description + + This attribute indicates how many packets have been sent to the + port in the course of delivering this service to a Framed User, + and can only be present in Accounting-Request records where the + Acct-Status-Type is set to Stop. + + A summary of the Acct-Output-Packets attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + +Rigney Informational [Page 18] + +RFC 2866 RADIUS Accounting 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 + + 48 for Acct-Output-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.10. Acct-Terminate-Cause + + Description + + This attribute indicates how the session was terminated, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Terminate-Cause 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + +Rigney Informational [Page 19] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 49 for Acct-Terminate-Cause + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the cause of session termination, as follows: + + 1 User Request + 2 Lost Carrier + 3 Lost Service + 4 Idle Timeout + 5 Session Timeout + 6 Admin Reset + 7 Admin Reboot + 8 Port Error + 9 NAS Error + 10 NAS Request + 11 NAS Reboot + 12 Port Unneeded + 13 Port Preempted + 14 Port Suspended + 15 Service Unavailable + 16 Callback + 17 User Error + 18 Host Request + + The termination causes are as follows: + + User Request User requested termination of service, for + example with LCP Terminate or by logging out. + + Lost Carrier DCD was dropped on the port. + + Lost Service Service can no longer be provided; for + example, user's connection to a host was + interrupted. + + Idle Timeout Idle timer expired. + + Session Timeout Maximum session length timer expired. + + Admin Reset Administrator reset the port or session. + + + +Rigney Informational [Page 20] + +RFC 2866 RADIUS Accounting June 2000 + + + Admin Reboot Administrator is ending service on the NAS, + for example prior to rebooting the NAS. + + Port Error NAS detected an error on the port which + required ending the session. + + NAS Error NAS detected some error (other than on the + port) which required ending the session. + + NAS Request NAS ended session for a non-error reason not + otherwise listed here. + + NAS Reboot The NAS ended the session in order to reboot + non-administratively ("crash"). + + Port Unneeded NAS ended session because resource usage fell + below low-water mark (for example, if a + bandwidth-on-demand algorithm decided that + the port was no longer needed). + + Port Preempted NAS ended session in order to allocate the + port to a higher priority use. + + Port Suspended NAS ended session to suspend a virtual + session. + + Service Unavailable NAS was unable to provide requested service. + + Callback NAS is terminating current session in order + to perform callback for a new session. + + User Error Input from user is in error, causing + termination of session. + + Host Request Login Host terminated session normally. + +5.11. Acct-Multi-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to link + together multiple related sessions in a log file. Each session + linked together would have a unique Acct-Session-Id but the same + Acct-Multi-Session-Id. It is strongly recommended that the Acct- + Multi-Session-Id contain UTF-8 encoded 10646 [7] characters. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + +Rigney Informational [Page 21] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD contain UTF-8 encoded 10646 [7] characters. + +5.12. Acct-Link-Count + + Description + + This attribute gives the count of links which are known to have been + in a given multilink session at the time the accounting record is + generated. The NAS MAY include the Acct-Link-Count attribute in any + Accounting-Request which might have multiple links. + + A summary of the Acct-Link-Count attribute format is show 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + +Rigney Informational [Page 22] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 51 for Acct-Link-Count. + + Length + + 6 + + Value + + The Value field is four octets, and contains the number of links + seen so far in this Multilink Session. + + It may be used to make it easier for an accounting server to know + when it has all the records for a given Multilink session. When + the number of Accounting-Requests received with Acct-Status-Type = + Stop and the same Acct-Multi-Session-Id and unique Acct-Session- + Id's equals the largest value of Acct-Link-Count seen in those + Accounting-Requests, all Stop Accounting-Requests for that + Multilink Session have been received. + + An example showing 8 Accounting-Requests should make things + clearer. For clarity only the relevant attributes are shown, but + additional attributes containing accounting information will also + be present in the Accounting-Request. + + Multi-Session-Id Session-Id Status-Type Link-Count + "10" "10" Start 1 + "10" "11" Start 2 + "10" "11" Stop 2 + "10" "12" Start 3 + "10" "13" Start 4 + "10" "12" Stop 4 + "10" "13" Stop 4 + "10" "10" Stop 4 + +5.13. Table of Attributes + + The following table provides a guide to which attributes may be found + in Accounting-Request packets. No attributes should be found in + Accounting-Response packets except Proxy-State and possibly Vendor- + Specific. + + + # Attribute + 0-1 User-Name + 0 User-Password + 0 CHAP-Password + + + +Rigney Informational [Page 23] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-IP-Address [Note 1] + 0-1 NAS-Port + 0-1 Service-Type + 0-1 Framed-Protocol + 0-1 Framed-IP-Address + 0-1 Framed-IP-Netmask + 0-1 Framed-Routing + 0+ Filter-Id + 0-1 Framed-MTU + 0+ Framed-Compression + 0+ Login-IP-Host + 0-1 Login-Service + 0-1 Login-TCP-Port + 0 Reply-Message + 0-1 Callback-Number + 0-1 Callback-Id + 0+ Framed-Route + 0-1 Framed-IPX-Network + 0 State + 0+ Class + 0+ Vendor-Specific + 0-1 Session-Timeout + 0-1 Idle-Timeout + 0-1 Termination-Action + 0-1 Called-Station-Id + 0-1 Calling-Station-Id + 0-1 NAS-Identifier [Note 1] + 0+ Proxy-State + 0-1 Login-LAT-Service + 0-1 Login-LAT-Node + 0-1 Login-LAT-Group + 0-1 Framed-AppleTalk-Link + 0-1 Framed-AppleTalk-Network + 0-1 Framed-AppleTalk-Zone + 1 Acct-Status-Type + 0-1 Acct-Delay-Time + 0-1 Acct-Input-Octets + 0-1 Acct-Output-Octets + 1 Acct-Session-Id + 0-1 Acct-Authentic + 0-1 Acct-Session-Time + 0-1 Acct-Input-Packets + 0-1 Acct-Output-Packets + 0-1 Acct-Terminate-Cause + 0+ Acct-Multi-Session-Id + 0+ Acct-Link-Count + 0 CHAP-Challenge + + + + +Rigney Informational [Page 24] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address + or a NAS-Identifier (or both). + + 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 RFC 2865 [2], in accordance with BCP + 26 [8]. + +7. Security Considerations + + Security issues are discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +8. Change Log + + US-ASCII replaced by UTF-8. + + Added notes on Proxy. + + Framed-IP-Address should contain the actual IP address of the user. + + If Acct-Session-ID was sent in an access-request, it must be used in + the accounting-request for that session. + + New values added to Acct-Status-Type. + + Added an IANA Considerations section. + + Updated references. + + Text strings identified as a subset of string, to clarify use of + UTF-8. + + + + +Rigney Informational [Page 25] + +RFC 2866 RADIUS Accounting June 2000 + + +9. References + + [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. + + [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +10. Acknowledgements + + RADIUS and RADIUS Accounting were originally developed by Steve + Willens of Livingston Enterprises for their PortMaster series of + Network Access Servers. + +11. 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 Informational [Page 26] + +RFC 2866 RADIUS Accounting June 2000 + + +12. Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@telemancy.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 27] + +RFC 2866 RADIUS Accounting June 2000 + + +13. 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 Informational [Page 28] + diff --git a/doc/rfc2869.txt b/doc/rfc2869.txt new file mode 100644 index 0000000..74ed7f6 --- /dev/null +++ b/doc/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] + diff --git a/doc/rfc3580.txt b/doc/rfc3580.txt new file mode 100644 index 0000000..b87235c --- /dev/null +++ b/doc/rfc3580.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group P. Congdon +Request for Comments: 3580 Hewlett Packard Company +Category: Informational B. Aboba + Microsoft + A. Smith + Trapeze Networks + G. Zorn + Cisco Systems + J. Roese + Enterasys + September 2003 + + + IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) + Usage Guidelines + +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 (2003). All Rights Reserved. + +Abstract + + This document provides suggestions on Remote Authentication Dial In + User Service (RADIUS) usage by IEEE 802.1X Authenticators. The + material in this document is also included within a non-normative + Appendix within the IEEE 802.1X specification, and is being presented + as an IETF RFC for informational purposes. + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 1] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4 + 2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5 + 2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5 + 2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6 + 2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7 + 3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7 + 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8 + 3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8 + 3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9 + 3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9 + 3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9 + 3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10 + 3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10 + 3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10 + 3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11 + 3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11 + 3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11 + 3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11 + 3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12 + 3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12 + 3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12 + 3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12 + 3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12 + 3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12 + 3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13 + 3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13 + 3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13 + 3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14 + 3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14 + 4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18 + 5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19 + 5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19 + 5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20 + + + +Congdon, et al. Informational [Page 2] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20 + 5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 7.2. Informative References . . . . . . . . . . . . . . . . . 23 + 8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25 + 9. Intellectual Property Statement . . . . . . . . . . . . . . . 28 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + +1. Introduction + + IEEE 802.1X enables authenticated access to IEEE 802 media, including + Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote + Authentication Dial In User Service (RADIUS) support is optional + within IEEE 802.1X, it is expected that many IEEE 802.1X + Authenticators will function as RADIUS clients. + + IEEE 802.1X [IEEE8021X] provides "network port authentication" for + IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring + and 802.11 [IEEE80211] wireless LANS. + + IEEE 802.1X does not require use of a backend Authentication Server, + and thus can be deployed with stand-alone bridges or Access Points, + as well as in centrally managed scenarios. + + In situations where it is desirable to centrally manage + authentication, authorization and accounting (AAA) for IEEE 802 + networks, deployment of a backend authentication and accounting + server is desirable. In such situations, it is expected that IEEE + 802.1X Authenticators will function as AAA clients. + + This document provides suggestions on RADIUS usage by IEEE 802.1X + Authenticators. Support for any AAA protocol is optional for IEEE + 802.1X Authenticators, and therefore this specification has been + incorporated into a non-normative Appendix within the IEEE 802.1X + specification. + +1.1. Terminology + + This document uses the following terms: + + Access Point (AP) + A Station that provides access to the distribution services via + the wireless medium for associated Stations. + + + + +Congdon, et al. Informational [Page 3] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Association + The service used to establish Access Point/Station mapping and + enable Station invocation of the distribution system services. + + Authenticator + An Authenticator is an entity that requires authentication from + the Supplicant. The Authenticator may be connected to the + Supplicant at the other end of a point-to-point LAN segment or + 802.11 wireless link. + + Authentication Server + An Authentication Server is an entity that provides an + Authentication Service to an Authenticator. This service + verifies, from the credentials provided by the Supplicant, the + claim of identity made by the Supplicant. + + Port Access Entity (PAE) + The protocol entity associated with a physical or virtual + (802.11) Port. A given PAE may support the protocol + functionality associated with the Authenticator, Supplicant or + both. + + Station (STA) + Any device that contains an IEEE 802.11 conformant medium + access control (MAC) and physical layer (PHY) interface to the + wireless medium (WM). + + Supplicant + A Supplicant is an entity that is being authenticated by an + Authenticator. The Supplicant may be connected to the + Authenticator at one end of a point-to-point LAN segment or + 802.11 wireless link. + +1.2. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. 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 [RFC2119]. + + + + + + + + + + + +Congdon, et al. Informational [Page 4] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +2. RADIUS Accounting Attributes + + With a few exceptions, the RADIUS accounting attributes defined in + [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE + 802.1X sessions as they do in dialup sessions and therefore no + additional commentary is needed. + + Attributes requiring more discussion include: + + Acct-Terminate-Cause + Acct-Multi-Session-Id + Acct-Link-Count + +2.1. Acct-Terminate-Cause + + This attribute indicates how the session was terminated, as described + in [RFC2866]. [IEEE8021X] defines the following termination cause + values, which are shown with their RADIUS equivalents in the table on + the next page. + + IEEE 802.1X RADIUS + dot1xAuthSessionTerminateCause Acct-Terminate-Cause + Value Value + ------------- -------------------- + SupplicantLogoff(1) User Request (1) + portFailure(2) Lost Carrier (2) + SupplicantRestart(3) Supplicant Restart (19) + reauthFailed(4) Reauthentication Failure (20) + authControlForceUnauth(5) Admin Reset (6) + portReInit(6) Port Reinitialized (21) + portAdminDisabled(7) Port Administratively Disabled (22) + notTerminatedYet(999) N/A + + When using this attribute, the User Request (1) termination cause + corresponds to the situation in which the session terminated due to + an EAPOL-Logoff received from the Supplicant. When a session is + moved due to roaming, the EAPOL state machines will treat this as a + Supplicant Logoff. + + A Lost Carrier (2) termination cause indicates session termination + due to loss of physical connectivity for reasons other than roaming + between Access Points. For example, if the Supplicant disconnects a + point-to-point LAN connection, or moves out of range of an Access + Point, this termination cause is used. Lost Carrier (2) therefore + equates to a Port Disabled condition in the EAPOL state machines. + + A Supplicant Restart (19) termination cause indicates + re-initialization of the Supplicant state machines. + + + +Congdon, et al. Informational [Page 5] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + A Reauthentication Failure (20) termination cause indicates that a + previously authenticated Supplicant has failed to re-authenticate + successfully following expiry of the re-authentication timer or + explicit re-authentication request by management action. + + Within [IEEE80211], periodic re-authentication may be useful in + preventing reuse of an initialization vector with a given key. Since + successful re-authentication does not result in termination of the + session, accounting packets are not sent as a result of + re-authentication unless the status of the session changes. For + example: + + a. The session is terminated due to re-authentication failure. In + this case the Reauthentication Failure (20) termination cause is + used. + + b. The authorizations are changed as a result of a successful + re-authentication. In this case, the Service Unavailable (15) + termination cause is used. For accounting purposes, the portion + of the session after the authorization change is treated as a + separate session. + + Where IEEE 802.1X authentication occurs prior to association, + accounting packets are not sent until an association occurs. + + An Admin Reset (6) termination cause indicates that the Port has been + administratively forced into the unauthorized state. + + A Port Reinitialized (21) termination cause indicates that the Port's + MAC has been reinitialized. + + A Port Administratively Disabled (22) termination cause indicates + that the Port has been administratively disabled. + +2.2. Acct-Multi-Session-Id + + The purpose of this attribute is to make it possible to link together + multiple related sessions. While [IEEE8021X] does not act on + aggregated ports, it is possible for a Supplicant roaming between + Access Points to cause multiple RADIUS accounting packets to be sent + by different Access Points. + + Where supported by the Access Points, the Acct-Multi-Session-Id + attribute can be used to link together the multiple related sessions + of a roaming Supplicant. In such a situation, if the session context + is transferred between Access Points, accounting packets MAY be sent + without a corresponding authentication and authorization exchange, + + + + +Congdon, et al. Informational [Page 6] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + provided that Association has occurred. However, in such a situation + it is assumed that the Acct-Multi-Session-Id is transferred between + the Access Points as part of the Inter-Access Point Protocol (IAPP). + + If the Acct-Multi-Session-Id were not unique between Access Points, + then it is possible that the chosen Acct-Multi-Session-Id will + overlap with an existing value allocated on that Access Point, and + the Accounting Server would therefore be unable to distinguish a + roaming session from a multi-link session. + + As a result, the Acct-Multi-Session-Id attribute is unique among all + the bridges or Access Points, Supplicants and sessions. In order to + provide this uniqueness, it is suggested that the Acct-Multi- + Session-Id be of the form: + + Original AP MAC Address | Supplicant MAC Address | NTP Timestamp + + Here "|" represents concatenation, the original AP MAC Address is the + MAC address of the bridge or Access Point at which the session + started, and the 64-bit NTP timestamp indicates the beginning of the + original session. In order to provide for consistency of the Acct- + Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id + may be moved between Access Points as part of IAPP or another handoff + scheme. + + The use of an Acct-Multi-Session-Id of this form guarantees + uniqueness among all Access Points, Supplicants and sessions. Since + the NTP timestamp does not wrap on reboot, there is no possibility + that a rebooted Access Point could choose an Acct-Multi-Session-Id + that could be confused with that of a previous session. + + Since the Acct-Multi-Session-Id is of type String as defined in + [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string + of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- + 14-23-DE-AF-23-83-C0-76-B8-44-E8" + +2.3. Acct-Link-Count + + The Acct-Link-Count attribute may be used to account for the number + of ports that have been aggregated. + +3. RADIUS Authentication + + This section describes how attributes defined in [RFC2865], + [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in + IEEE 802.1X authentication. + + + + + +Congdon, et al. Informational [Page 7] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.1. User-Name + + In IEEE 802.1X, the Supplicant typically provides its identity via an + EAP-Response/Identity message. Where available, the Supplicant + identity is included in the User-Name attribute, and included in the + RADIUS Access-Request and Access-Reply messages as specified in + [RFC2865] and [RFC3579]. + + Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name + attribute may contain the Calling-Station-ID value, which is set to + the Supplicant MAC address. + +3.2. User-Password, CHAP-Password, CHAP-Challenge + + Since IEEE 802.1X does not support PAP or CHAP authentication, the + User-Password, CHAP-Password or CHAP-Challenge attributes are not + used by IEEE 802.1X Authenticators acting as RADIUS clients. + +3.3. NAS-IP-Address, NAS-IPv6-Address + + For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 + address of the bridge or Access Point acting as an Authenticator, and + the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X + Authenticator has more than one interface, it may be desirable to use + a loopback address for this purpose so that the Authenticator will + still be reachable even if one of the interfaces were to fail. + +3.4. NAS-Port + + For use with IEEE 802.1X the NAS-Port will contain the port number of + the bridge, if this is available. While an Access Point does not + have physical ports, a unique "association ID" is assigned to every + mobile Station upon a successful association exchange. As a result, + for an Access Point, if the association exchange has been completed + prior to authentication, the NAS-Port attribute will contain the + association ID, which is a 16-bit unsigned integer. Where IEEE + 802.1X authentication occurs prior to association, a unique NAS-Port + value may not be available. + +3.5. Service-Type + + For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and + Call Check (10) values are most commonly used. + + A Service-Type of Framed indicates that appropriate 802 framing + should be used for the connection. A Service-Type of Authenticate + Only (8) indicates that no authorization information needs to be + returned in the Access-Accept. As described in [RFC2865], a + + + +Congdon, et al. Informational [Page 8] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Service-Type of Call Check is included in an Access-Request packet to + request that the RADIUS server accept or reject the connection + attempt, typically based on the Called-Station-ID (set to the bridge + or Access Point MAC address) or Calling-Station-ID attributes (set to + the Supplicant MAC address). As noted in [RFC2865], it is + recommended that in this case, the User-Name attribute be given the + value of Calling-Station-Id. + +3.6. Framed-Protocol + + Since there is no value for IEEE 802 media, the Framed-Protocol + attribute is not used by IEEE 802.1X Authenticators. + +3.7. Framed-IP-Address, Framed-IP-Netmask + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can + only be used by IEEE 802.1X Authenticators that support IP address + assignment mechanisms. Typically this capability is supported by + layer 3 devices. + +3.8. Framed-Routing + + The Framed-Routing attribute indicates the routing method for the + Supplicant. It is therefore only relevant for IEEE 802.1X + Authenticators that act as layer 3 devices, and cannot be used by a + bridge or Access Point. + +3.9. Filter-ID + + This attribute indicates the name of the filter list to be applied to + the Supplicant's session. For use with an IEEE 802.1X Authenticator, + it may be used to indicate either layer 2 or layer 3 filters. Layer + 3 filters are typically only supported on IEEE 802.1X Authenticators + that act as layer 3 devices. + +3.10. Framed-MTU + + This attribute indicates the maximum size of an IP packet that may be + transmitted over the wire between the Supplicant and the + Authenticator. IEEE 802.1X Authenticators set this to the value + corresponding to the relevant 802 medium, and include it in the + RADIUS Access-Request. The RADIUS server may send an EAP packet as + large as Framed-MTU minus four (4) octets, taking into account the + additional overhead for the IEEE 802.1X Version (1), Type (1) and + Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU + values (which do not include LLC/SNAP overhead) and maximum frame + length values (not including the preamble) are as follows: + + + +Congdon, et al. Informational [Page 9] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Maximum Frame + Media Framed-MTU Length + ========= =============== ============== + Ethernet 1500 1522 + 802.3 1500 1522 + 802.4 8174 8193 + 802.5 (4 Mbps) 4528 4550 + 802.5 (16 Mbps) 18173 18200 + 802.5 (100 Mb/s) 18173 18200 + 802.6 9191 9240 + 802.9a 1500 1518 + 802.11 2304 2346 + 802.12 (Ethernet) 1500 1518 + 802.12 (Token Ring) 4502 4528 + FDDI 4479 4500 + + NOTE - the Framed-MTU size for IEEE 802.11 media may change as a + result of ongoing work being undertaken in the IEEE 802.11 Working + Group. Since some 802.11 stations cannot handle an MTU larger than + 1500 octets, it is recommended that RADIUS servers encountering a + NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 + octets. + +3.11. Framed-Compression + + [IEEE8021X] does not include compression support. Therefore this + attribute is not understood by [IEEE8021X] Authenticators. + +3.12. Displayable Messages + + The Reply-Message attribute, defined in section 5.18 of [RFC2865], + indicates text which may be displayed to the user. This is similar + in concept to the EAP Notification Type, defined in [RFC2284]. As + noted in [RFC3579], Section 2.6.5, when sending a displayable message + to an [IEEE8021X] Authenticator, displayable messages are best sent + within EAP-Message/EAP-Request/Notification attribute(s), and not + within Reply-Message attribute(s). + +3.13. Callback-Number, Callback-ID + + These attributes are not understood by IEEE 802.1X Authenticators. + + + + + + + + + + +Congdon, et al. Informational [Page 10] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.14. Framed-Route, Framed-IPv6-Route + + The Framed-Route and Framed-IPv6-Route attributes provide routes that + are to be configured for the Supplicant. These attributes are + therefore only relevant for IEEE 802.1X Authenticators that act as + layer 3 devices, and cannot be understood by a bridge or Access + Point. + +3.15. State, Class, Proxy-State + + These attributes are used for the same purposes as described in + [RFC2865]. + +3.16. Vendor-Specific + + Vendor-specific attributes are used for the same purposes as + described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key + attributes, described in section 2.4 of [RFC2548], MAY be used to + encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, + Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and + MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP + method are given in [RFC2716]. Details of the EAPOL-Key descriptor + are provided in Section 4. + +3.17. Session-Timeout + + When sent along in an Access-Accept without a Termination-Action + attribute or with a Termination-Action attribute set to Default, the + Session-Timeout attribute specifies the maximum number of seconds of + service provided prior to session termination. + + When sent in an Access-Accept along with a Termination-Action value + of RADIUS-Request, the Session-Timeout attribute specifies the + maximum number of seconds of service provided prior to re- + authentication. In this case, the Session-Timeout attribute is used + to load the reAuthPeriod constant within the Reauthentication Timer + state machine of 802.1X. When sent with a Termination-Action value + of RADIUS-Request, a Session-Timeout value of zero indicates the + desire to perform another authentication (possibly of a different + type) immediately after the first authentication has successfully + completed. + + When sent in an Access-Challenge, this attribute represents the + maximum number of seconds that an IEEE 802.1X Authenticator should + wait for an EAP-Response before retransmitting. In this case, the + Session-Timeout attribute is used to load the suppTimeout constant + within the backend state machine of IEEE 802.1X. + + + + +Congdon, et al. Informational [Page 11] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.18. Idle-Timeout + + The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 + media other than 802.11 the media are always on. As a result the + Idle-Timeout attribute is typically only used with wireless media + such as IEEE 802.11. It is possible for a wireless device to wander + out of range of all Access Points. In this case, the Idle-Timeout + attribute indicates the maximum time that a wireless device may + remain idle. + +3.19. Termination-Action + + This attribute indicates what action should be taken when the service + is completed. The value RADIUS-Request (1) indicates that re- + authentication should occur on expiration of the Session-Time. The + value Default (0) indicates that the session should terminate. + +3.20. Called-Station-Id + + For IEEE 802.1X Authenticators, this attribute is used to store the + bridge or Access Point MAC address in ASCII format (upper case only), + with octet values separated by a "-". Example: "00-10-A4-23-19-C0". + In IEEE 802.11, where the SSID is known, it SHOULD be appended to the + Access Point MAC address, separated from the MAC address with a ":". + Example "00-10-A4-23-19-C0:AP1". + +3.21. Calling-Station-Id + + For IEEE 802.1X Authenticators, this attribute is used to store the + Supplicant MAC address in ASCII format (upper case only), with octet + values separated by a "-". Example: "00-10-A4-23-19-C0". + +3.22. NAS-Identifier + + This attribute contains a string identifying the IEEE 802.1X + Authenticator originating the Access-Request. + +3.23. NAS-Port-Type + + For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) + Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be + used. + + + + + + + + + +Congdon, et al. Informational [Page 12] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.24. Port-Limit + + This attribute has no meaning when sent to an [IEEE8021X] + Authenticator. + +3.25. Password-Retry + + In IEEE 802.1X, the Authenticator always transitions to the HELD + state after an authentication failure. Thus this attribute does not + make sense for IEEE 802.1X. + +3.26. Connect-Info + + This attribute is sent by a bridge or Access Point to indicate the + nature of the Supplicant's connection. When sent in the Access- + Request it is recommended that this attribute contain information on + the speed of the Supplicant's connection. For 802.11, the following + format is recommended: "CONNECT 11Mbps 802.11b". If sent in the + Accounting STOP, this attribute may be used to summarize statistics + relating to session quality. For example, in IEEE 802.11, the + Connect-Info attribute may contain information on the number of link + layer retransmissions. The exact format of this attribute is + implementation specific. + +3.27. EAP-Message + + Since IEEE 802.1X provides for encapsulation of EAP as described in + [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in + [RFC3579] is used to encapsulate EAP packets for transmission from + the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] + Section 2.2. describes how the Authentication Server handles invalid + EAP packets passed to it by the Authenticator. + +3.28. Message-Authenticator + + As noted in [RFC3579] Section 3.1., the Message-Authenticator + attribute MUST be used to protect packets within a RADIUS/EAP + conversation. + +3.29. NAS-Port-Id + + This attribute is used to identify the IEEE 802.1X Authenticator port + which authenticates the Supplicant. The NAS-Port-Id differs from the + NAS-Port in that it is a string of variable length whereas the NAS- + Port is a 4 octet value. + + + + + + +Congdon, et al. Informational [Page 13] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.30. Framed-Pool, Framed-IPv6-Pool + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be + used by IEEE 802.1X Authenticators that support IP address assignment + mechanisms. Typically this capability is supported by layer 3 + devices. + +3.31. Tunnel Attributes + + Reference [RFC2868] defines RADIUS tunnel attributes used for + authentication and authorization, and [RFC2867] defines tunnel + attributes used for accounting. Where the IEEE 802.1X Authenticator + supports tunneling, a compulsory tunnel may be set up for the + Supplicant as a result of the authentication. + + In particular, it may be desirable to allow a port to be placed into + a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the + result of the authentication. This can be used, for example, to + allow a wireless host to remain on the same VLAN as it moves within a + campus network. + + The RADIUS server typically indicates the desired VLAN by including + tunnel attributes within the Access-Accept. However, the IEEE 802.1X + Authenticator may also provide a hint as to the VLAN to be assigned + to the Supplicant by including Tunnel attributes within the Access- + Request. + + For use in VLAN assignment, the following tunnel attributes are used: + + Tunnel-Type=VLAN (13) + Tunnel-Medium-Type=802 + Tunnel-Private-Group-ID=VLANID + + Note that the VLANID is 12-bits, taking a value between 1 and 4094, + inclusive. Since the Tunnel-Private-Group-ID is of type String as + defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer + value is encoded as a string. + + When Tunnel attributes are sent, it is necessary to fill in the Tag + field. As noted in [RFC2868], section 3.1: + + The Tag field is one octet in length and is intended to provide a + means of grouping attributes in the same packet which refer to the + same tunnel. Valid values for this field are 0x01 through 0x1F, + inclusive. If the Tag field is unused, it MUST be zero (0x00). + + + + + +Congdon, et al. Informational [Page 14] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel- + Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or + Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel- + Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of + greater than 0x1F is interpreted as the first octet of the following + field. + + Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X + Authenticators that may support tunneling but not VLANs), it is only + necessary for tunnel attributes to specify a single tunnel. As a + result, where it is only desired to specify the VLANID, the tag field + SHOULD be set to zero (0x00) in all tunnel attributes. Where + alternative tunnel types are to be provided, tag values between 0x01 + and 0x1F SHOULD be chosen. + +4. RC4 EAPOL-Key Frame + + The RC4 EAPOL-Key frame is created and transmitted by the + Authenticator in order to provide media specific key information. + For example, within 802.11 the RC4 EAPOL-Key frame can be used to + distribute multicast/broadcast ("default") keys, or unicast ("key + mapping") keys. The "default" key is the same for all Stations + within a broadcast domain. + + The RC4 EAPOL-Key frame is not acknowledged and therefore the + Authenticator does not know whether the Supplicant has received it. + If it is lost, then the Supplicant and Authenticator will not have + the same keying material, and communication will fail. If this + occurs, the problem is typically addressed by re-running the + authentication. + + The RC4 EAPOL-Key frame is sent from the Authenticator to the + Supplicant in order to provision the "default" key, and subsequently + in order to refresh the "default" key. It may also be used to + refresh the key-mapping key. Rekey is typically only required with + weak ciphersuites such as WEP, defined in [IEEE80211]. + + Where keys are required, an EAP method that derives keys is typically + selected. Therefore the initial "key mapping" keys can be derived + from EAP keying material, without requiring the Authenticator to send + an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP + keying material can be derived and used is presented in [RFC2716]. + + + + + + + + + +Congdon, et al. Informational [Page 15] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more + complete description is provided on the next page. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Packet Type | Packet Body Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Key Length |Replay Counter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay Counter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay Counter | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... |F| Key Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version + The Version field is one octet. For IEEE 802.1X, it contains the + value 0x01. + + Packet Type + The Packet Type field is one octet, and determines the type of + packet being transmitted. For an EAPOL-Key Descriptor, the Packet + Type field contains 0x03. + + Packet Body Length + The Packet Body Length is two octets, and contains the length of + the EAPOL-Key descriptor in octets, not including the Version, + Packet Type and Packet Body Length fields. + + + + + +Congdon, et al. Informational [Page 16] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Type + The Type field is a single octet. The Key descriptor is defined + differently for each Type; this specification documents only the + RC4 Key Descriptor (Type = 0x01). + + Key Length + The Key Length field is two octets. If Packet Body Length = 44 + + Key Length, then the Key Field contains the key in encrypted form, + of length Key Length. This is 5 octets (40 bits) for WEP, and 13 + octets (104 bits) for WEP-128. If Packet Body Length = 44, then + the Key field is absent, and Key Length represents the number of + least significant octets from the MS-MPPE-Send-Key attribute + [RFC2548] to be used as the keying material. Note that the MS- + MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the + point of view of the Authenticator. From the Supplicant point of + reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on + the Supplicant corresponds to the MS-MPPE-Send-Key on the + Authenticator, and the MS-MPPE-Send-Key on the Supplicant + corresponds to the MS-MPPE-Recv-Key on the Authenticator. + + Replay Counter + The Replay Counter field is 8 octets. It does not repeat within + the life of the keying material used to encrypt the Key field and + compute the Key Signature field. A 64-bit NTP timestamp MAY be + used as the Replay Counter. + + Key IV + The Key IV field is 16 octets and includes a 128-bit + cryptographically random number. + + F + The Key flag (F) is a single bit, describing the type of key that + is included in the Key field. Values are: + + 0 = for broadcast (default key) + 1 = for unicast (key mapping key) + + Key Index + The Key Index is 7 bits. + + Key Signature + The Key Signature field is 16 octets. It contains an HMAC-MD5 + message integrity check computed over the EAPOL-Key descriptor, + starting from the Version field, with the Key field filled in if + present, but with the Key Signature field set to zero. For the + computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is + used as the HMAC-MD5 key. + + + + +Congdon, et al. Informational [Page 17] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Key + If Packet Body Length = 44 + Key Length, then the Key Field + contains the key in encrypted form, of length Key Length. If + Packet Body Length = 44, then the Key field is absent, and the + least significant Key Length octets from the MS-MPPE-Send-Key + attribute is used as the keying material. Where the Key field is + encrypted using RC4, the RC4 encryption key used to encrypt this + field is formed by concatenating the 16 octet (128 bit) Key-IV + field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a + 48 octet RC4 key (384 bits). + +5. Security Considerations + + Since this document describes the use of RADIUS for purposes of + authentication, authorization, and accounting in IEEE 802.1X-enabled + networks, it is vulnerable to all of the threats that are present in + other RADIUS applications. For a discussion of these threats, see + [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576]. + + Vulnerabilities include: + + Packet modification or forgery + Dictionary attacks + Known plaintext attacks + Replay + Outcome mismatches + 802.11 integration + Key management issues + +5.1. Packet Modification or Forgery + + RADIUS, defined in [RFC2865], does not require all Access-Requests to + be authenticated or integrity protected. However, IEEE 802.1X is + based on EAP. As described in [3579], Section 3.1.: + + 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. + + As a result, when used with IEEE 802.1X, all RADIUS packets MUST be + authenticated and integrity protected. In addition, as described in + [3579], Section 4.2.: + + To address the security vulnerabilities of RADIUS/EAP, + implementations of this specification SHOULD support IPsec + [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP + [RFC2406] with non-null transform SHOULD be supported, and IPsec + ESP with a non-null encryption transform and authentication + + + +Congdon, et al. Informational [Page 18] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + support SHOULD be used to provide per-packet confidentiality, + authentication, integrity and replay protection. IKE SHOULD be + used for key management. + +5.2. Dictionary Attacks + + As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is + vulnerable to offline dictionary attack, based on capture of the + Response Authenticator or Message-Authenticator attribute. In order + to decrease the level of vulnerability, [RFC2865], Section 3 + recommends: + + The secret (password shared between the client and the RADIUS + server) SHOULD be at least as large and unguessable as a well- + chosen password. It is preferred that the secret be at least 16 + octets. + + In addition, the risk of an offline dictionary attack can be further + mitigated by employing IPsec ESP with a non-null transform in order + to encrypt the RADIUS conversation, as described in [RFC3579], + Section 4.2. + +5.3. Known Plaintext Attacks + + Since IEEE 802.1X is based on EAP, which does not support PAP, the + RADIUS User-Password attribute is not used to carry hidden user + passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], + in order to generate a key stream based on the RADIUS shared secret + and the Request Authenticator. Where PAP is in use, it is possible + to collect key streams corresponding to a given Request Authenticator + value, by capturing RADIUS conversations corresponding to a PAP + authentication attempt using a known password. Since the User- + Password is known, the key stream corresponding to a given Request + Authenticator can be determined and stored. + + The vulnerability is described in detail in [RFC3579], Section 4.3.4. + Even though IEEE 802.1X Authenticators do not support PAP + authentication, a security vulnerability can still exist where the + same RADIUS shared secret is used for hiding User-Password as well as + other attributes. This can occur, for example, if the same RADIUS + proxy handles authentication requests for both IEEE 802.1X (which may + hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key + attributes) and GPRS (which may hide the User-Password attribute). + + The threat can be mitigated by protecting RADIUS with IPsec ESP with + a non-null transform, as described in [RFC3579], Section 4.2. In + addition, the same RADIUS shared secret MUST NOT be used for both + IEEE 802.1X authentication and PAP authentication. + + + +Congdon, et al. Informational [Page 19] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +5.4. Replay + + As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides + only limited support for replay protection. Replay protection for + RADIUS authentication and accounting can be provided by enabling + IPsec replay protection with RADIUS, as described in [RFC3579], + Section 4.2. + + As with the Request Authenticator, for use with IEEE 802.1X + Authenticators, the Acct-Session-Id SHOULD be globally and temporally + unique. + +5.5. Outcome Mismatches + + [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP + packet encapsulated in an EAP-Message attribute does not agree with + the RADIUS Packet Type. For example, an EAP Success packet might be + encapsulated within an Access-Reject; an EAP Failure might be sent + within an Access-Accept; or an EAP Success or Failure might be sent + within an Access-Challenge. + + As described in [RFC3579] Section 2.6.3., these conflicting messages + are likely to cause confusion. To ensure that access decisions made + by IEEE 802.1X Authenticators conform to the wishes of the RADIUS + server, it is necessary for the Authenticator to make the decision + solely based on the authentication result (Access-Accept/Reject) and + not based on the contents of EAP-Message attributes, if present. + +5.6. 802.11 Integration + + [IEEE8021X] was developed for use on wired IEEE 802 networks such as + Ethernet, and therefore does not describe how to securely adapt IEEE + 802.1X for use with 802.11. This is left to an enhanced security + specification under development within IEEE 802.11. + + For example, [IEEE8021X] does not specify whether authentication + occurs prior to, or after association, nor how the derived keys are + used within various ciphersuites. It also does not specify + ciphersuites addressing the vulnerabilities discovered in WEP, + described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. + [IEEE8021X] only defines an authentication framework, leaving the + definition of the authentication methods to other documents, such as + [RFC2716]. + + Since [IEEE8021X] does not address 802.11 integration issues, + implementors are strongly advised to consult additional IEEE 802.11 + security specifications for guidance on how to adapt IEEE 802.1X for + use with 802.11. For example, it is likely that the IEEE 802.11 + + + +Congdon, et al. Informational [Page 20] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + enhanced security specification will define its own IEEE 802.11 key + hierarchy as well as new EAPOL-Key descriptors. + +5.7. Key Management Issues + + The EAPOL-Key descriptor described in Section 4. is likely to be + deprecated in the future, when the IEEE 802.11 enhanced security + group completes its work. Known security issues include: + + [1] Default key-only support. IEEE 802.1X enables the derivation of + per-Station unicast keys, known in [IEEE80211] as "key mapping + keys." Keys used to encrypt multicast/broadcast traffic are + known as "default keys". However, in some 802.11 + implementations, the unicast keys, derived as part of the EAP + authentication process, are used solely in order to encrypt, + authenticate and integrity protect the EAPOL-Key descriptor, as + described in Section 4. These implementations only support use + of default keys (ordinarily only used with multicast/broadcast + traffic) to secure all traffic, unicast or multicast/broadcast, + resulting in inherent security weaknesses. + + Where per-Station key-mapping keys (e.g. unicast keys) are + unsupported, any Station possessing the default key can decrypt + traffic from other Stations or impersonate them. When used + along with a weak cipher (e.g. WEP), implementations supporting + only default keys provide more material for attacks such as + those described in [Fluhrer] and [Stubbl]. If in addition, the + default key is not refreshed periodically, IEEE 802.1X dynamic + key derivation provides little or no security benefit. For an + understanding of the issues with WEP, see [Berkeley], [Arbaugh], + [Fluhrer], and [Stubbl]. + + [2] Reuse of keying material. The EAPOL-Key descriptor specified in + section 4 uses the same keying material (MS-MPPE-Recv-Key) both + to encrypt the Key field within the EAPOL-Key descriptor, and to + encrypt data passed between the Station and Access Point. + Multi-purpose keying material is frowned upon, since multiple + uses can leak information helpful to an attacker. + + [3] Weak algorithms. The algorithm used to encrypt the Key field + within the EAPOL-Key descriptor is similar to the algorithm used + in WEP, and as a result, shares some of the same weaknesses. As + with WEP, the RC4 stream cipher is used to encrypt the key. As + input to the RC4 engine, the IV and key are concatenated rather + than being combined within a mixing function. As with WEP, the + IV is not a counter, and therefore there is little protection + against reuse. + + + + +Congdon, et al. Informational [Page 21] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + As a result of these vulnerabilities, implementors intending to use + the EAPOL-Key descriptor described in this document are urged to + consult the 802.11 enhanced security specification for a more secure + alternative. It is also advisable to consult the evolving literature + on WEP vulnerabilities, in order to better understand the risks, as + well as to obtain guidance on setting an appropriate re-keying + interval. + +6. IANA Considerations + + This specification does not create any RADIUS attributes nor any new + number spaces for IANA administration. However, it does require + assignment of new values to existing RADIUS attributes. These + include: + + Attribute Values Required + ========= =============== + NAS-Port-Type Token-Ring (20), FDDI (21) + Tunnel-Type VLAN (13) + Acct-Terminate-Cause Supplicant Restart (19) + Reauthentication Failure (20) + Port Reinitialized (21) + Port Administratively Disabled (22) + +7. References + +7.1. Normative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 1998. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, + June 2000. + + + + + +Congdon, et al. Informational [Page 22] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., + Holdrege, M. and I. Goyret, "RADIUS Attributes for + Tunnel Protocol Support", RFC 2868, June 2000. + + [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC + 3576, July 2003. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + [IEEE8021X] IEEE Standards for Local and Metropolitan Area + Networks: Port based Network Access Control, IEEE Std + 802.1X-2001, June 2001. + +7.2. Informative References + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS + Attributes", RFC 2548, March 1999. + + [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and + Policy Implementation in Roaming", RFC 2607, June + 1999. + + [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication + Protocol", RFC 2716, October 1999. + + + +Congdon, et al. Informational [Page 23] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent + Attack." CryptoBytes Vol.2 No.2, Summer 1996. + + [IEEE802] IEEE Standards for Local and Metropolitan Area + Networks: Overview and Architecture, ANSI/IEEE Std + 802, 1990. + + [IEEE8021Q] IEEE Standards for Local and Metropolitan Area + Networks: Draft Standard for Virtual Bridged Local + Area Networks, P802.1Q, January 1998. + + [IEEE8023] ISO/IEC 8802-3 Information technology - + Telecommunications and information exchange between + systems - Local and metropolitan area networks - + Common specifications - Part 3: Carrier Sense + Multiple Access with Collision Detection (CSMA/CD) + Access Method and Physical Layer Specifications, (also + ANSI/IEEE Std 802.3- 1996), 1996. + + [IEEE80211] Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific Requirements + Part 11: Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications, IEEE Std. + 802.11-1999, 1999. + + [Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting + Mobile Communications: The Insecurity of 802.11", ACM + SIGMOBILE, Seventh Annual International Conference on + Mobile Computing and Networking, July 2001, Rome, + Italy. + + [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 + Wireless Network has No Clothes", Department of + Computer Science, University of Maryland, College + Park, March 2001. + + [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in + the Key Scheduling Algorithm of RC4", Eighth Annual + Workshop on Selected Areas in Cryptography, Toronto, + Canada, August 2001. + + [Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using + the Fluhrer, Mantin and Shamir Attack to Break WEP", + 2002 NDSS Conference. + + + + + + +Congdon, et al. Informational [Page 24] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +8. Table of Attributes + + The following table provides a guide to which attributes MAY be sent + and received as part of IEEE 802.1X authentication. L3 denotes + attributes that require layer 3 capabilities, and thus may not be + supported by all Authenticators. For each attribute, the reference + provides the definitive information on usage. + + 802.1X # Attribute + X 1 User-Name [RFC2865] + 2 User-Password [RFC2865] + 3 CHAP-Password [RFC2865] + X 4 NAS-IP-Address [RFC2865] + X 5 NAS-Port [RFC2865] + X 6 Service-Type [RFC2865] + 7 Framed-Protocol [RFC2865] + L3 8 Framed-IP-Address [RFC2865] + L3 9 Framed-IP-Netmask [RFC2865] + L3 10 Framed-Routing [RFC2865] + X 11 Filter-Id [RFC2865] + X 12 Framed-MTU [RFC2865] + 13 Framed-Compression [RFC2865] + L3 14 Login-IP-Host [RFC2865] + L3 15 Login-Service [RFC2865] + L3 16 Login-TCP-Port [RFC2865] + 18 Reply-Message [RFC2865] + 19 Callback-Number [RFC2865] + 20 Callback-Id [RFC2865] + L3 22 Framed-Route [RFC2865] + L3 23 Framed-IPX-Network [RFC2865] + X 24 State [RFC2865] + X 25 Class [RFC2865] + X 26 Vendor-Specific [RFC2865] + X 27 Session-Timeout [RFC2865] + X 28 Idle-Timeout [RFC2865] + X 29 Termination-Action [RFC2865] + X 30 Called-Station-Id [RFC2865] + X 31 Calling-Station-Id [RFC2865] + X 32 NAS-Identifier [RFC2865] + X 33 Proxy-State [RFC2865] + 34 Login-LAT-Service [RFC2865] + 35 Login-LAT-Node [RFC2865] + 36 Login-LAT-Group [RFC2865] + 802.1X # Attribute + + + + + + + +Congdon, et al. Informational [Page 25] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 802.1X # Attribute + L3 37 Framed-AppleTalk-Link [RFC2865] + L3 38 Framed-AppleTalk-Network [RFC2865] + L3 39 Framed-AppleTalk-Zone [RFC2865] + X 40 Acct-Status-Type [RFC2866] + X 41 Acct-Delay-Time [RFC2866] + X 42 Acct-Input-Octets [RFC2866] + X 43 Acct-Output-Octets [RFC2866] + X 44 Acct-Session-Id [RFC2866] + X 45 Acct-Authentic [RFC2866] + X 46 Acct-Session-Time [RFC2866] + X 47 Acct-Input-Packets [RFC2866] + X 48 Acct-Output-Packets [RFC2866] + X 49 Acct-Terminate-Cause [RFC2866] + X 50 Acct-Multi-Session-Id [RFC2866] + X 51 Acct-Link-Count [RFC2866] + X 52 Acct-Input-Gigawords [RFC2869] + X 53 Acct-Output-Gigawords [RFC2869] + X 55 Event-Timestamp [RFC2869] + 60 CHAP-Challenge [RFC2865] + X 61 NAS-Port-Type [RFC2865] + 62 Port-Limit [RFC2865] + 63 Login-LAT-Port [RFC2865] + X 64 Tunnel-Type [RFC2868] + X 65 Tunnel-Medium-Type [RFC2868] + L3 66 Tunnel-Client-Endpoint [RFC2868] + L3 67 Tunnel-Server-Endpoint [RFC2868] + L3 68 Acct-Tunnel-Connection [RFC2867] + L3 69 Tunnel-Password [RFC2868] + 70 ARAP-Password [RFC2869] + 71 ARAP-Features [RFC2869] + 72 ARAP-Zone-Access [RFC2869] + 73 ARAP-Security [RFC2869] + 74 ARAP-Security-Data [RFC2869] + 75 Password-Retry [RFC2869] + 76 Prompt [RFC2869] + X 77 Connect-Info [RFC2869] + X 78 Configuration-Token [RFC2869] + X 79 EAP-Message [RFC3579] + X 80 Message-Authenticator [RFC3579] + X 81 Tunnel-Private-Group-ID [RFC2868] + L3 82 Tunnel-Assignment-ID [RFC2868] + X 83 Tunnel-Preference [RFC2868] + 84 ARAP-Challenge-Response [RFC2869] + 802.1X # Attribute + + + + + + +Congdon, et al. Informational [Page 26] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 802.1X # Attribute + X 85 Acct-Interim-Interval [RFC2869] + X 86 Acct-Tunnel-Packets-Lost [RFC2867] + X 87 NAS-Port-Id [RFC2869] + L3 88 Framed-Pool [RFC2869] + L3 90 Tunnel-Client-Auth-ID [RFC2868] + L3 91 Tunnel-Server-Auth-ID [RFC2868] + X 95 NAS-IPv6-Address [RFC3162] + 96 Framed-Interface-Id [RFC3162] + L3 97 Framed-IPv6-Prefix [RFC3162] + L3 98 Login-IPv6-Host [RFC3162] + L3 99 Framed-IPv6-Route [RFC3162] + L3 100 Framed-IPv6-Pool [RFC3162] + X 101 Error-Cause [RFC3576] + 802.1X # Attribute + + Key + === + X = May be used with IEEE 802.1X authentication + L3 = Implemented only by Authenticators with Layer 3 + capabilities + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 27] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +9. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards- related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +10. Acknowledgments + + The authors would like to acknowledge Bob O'Hara of Airespace, David + Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of + Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for + contributions to this document. + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 28] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +11. Authors' Addresses + + Paul Congdon + Hewlett Packard Company + HP ProCurve Networking + 8000 Foothills Blvd, M/S 5662 + Roseville, CA 95747 + + Phone: +1 916 785 5753 + Fax: +1 916 785 8478 + EMail: paul_congdon@hp.com + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + Fax: +1 425 936 7329 + EMail: bernarda@microsoft.com + + Andrew Smith + Trapeze Networks + 5753 W. Las Positas Blvd. + Pleasanton, CA 94588-4084 + + Fax: +1 415 345 1827 + EMail: ah_smith@acm.org + + John Roese + Enterasys + + Phone: +1 603 337 1506 + EMail: jjr@enterasys.com + + Glen Zorn + Cisco Systems, Inc. + 500 108th Avenue N.E., Suite 500 + Bellevue, WA 98004 + + Phone: +1 425 438 8218 + Fax: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + +Congdon, et al. Informational [Page 29] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 30] + -- cgit v1.2.3