diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2138.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2138.txt')
| -rw-r--r-- | doc/rfc/rfc2138.txt | 3643 |
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc2138.txt b/doc/rfc/rfc2138.txt new file mode 100644 index 0000000..9f4a86d --- /dev/null +++ b/doc/rfc/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. + <URL:http://www.iso.ch/cate/d16338.html> + + [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] + |