diff options
Diffstat (limited to 'doc/rfc2865.txt')
| -rw-r--r-- | doc/rfc2865.txt | 4259 |
1 files changed, 0 insertions, 4259 deletions
diff --git a/doc/rfc2865.txt b/doc/rfc2865.txt deleted file mode 100644 index 10ec231..0000000 --- a/doc/rfc2865.txt +++ /dev/null @@ -1,4259 +0,0 @@ - - - - - - -Network Working Group C. Rigney -Request for Comments: 2865 S. Willens -Obsoletes: 2138 Livingston -Category: Standards Track A. Rubens - Merit - W. Simpson - Daydreamer - June 2000 - - - Remote Authentication Dial In User Service (RADIUS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -IESG Note: - - This protocol is widely implemented and used. Experience has shown - that it can suffer degraded performance and lost data when used in - large scale systems, in part because it does not include provisions - for congestion control. Readers of this document may find it - beneficial to track the progress of the IETF's AAA working group, - which may develop a successor protocol that better addresses the - scaling and congestion control issues. - -Abstract - - This document describes a protocol for carrying authentication, - authorization, and configuration information between a Network Access - Server which desires to authenticate its links and a shared - Authentication Server. - -Implementation Note - - This memo documents the RADIUS protocol. The early deployment of - RADIUS was done using UDP port number 1645, which conflicts with the - "datametrics" service. The officially assigned port number for - RADIUS is 1812. - - - - -Rigney, et al. Standards Track [Page 1] - -RFC 2865 RADIUS June 2000 - - -Table of Contents - - 1. Introduction .......................................... 3 - 1.1 Specification of Requirements ................... 4 - 1.2 Terminology ..................................... 5 - 2. Operation ............................................. 5 - 2.1 Challenge/Response .............................. 7 - 2.2 Interoperation with PAP and CHAP ................ 8 - 2.3 Proxy ........................................... 8 - 2.4 Why UDP? ........................................ 11 - 2.5 Retransmission Hints ............................ 12 - 2.6 Keep-Alives Considered Harmful .................. 13 - 3. Packet Format ......................................... 13 - 4. Packet Types .......................................... 17 - 4.1 Access-Request .................................. 17 - 4.2 Access-Accept ................................... 18 - 4.3 Access-Reject ................................... 20 - 4.4 Access-Challenge ................................ 21 - 5. Attributes ............................................ 22 - 5.1 User-Name ....................................... 26 - 5.2 User-Password ................................... 27 - 5.3 CHAP-Password ................................... 28 - 5.4 NAS-IP-Address .................................. 29 - 5.5 NAS-Port ........................................ 30 - 5.6 Service-Type .................................... 31 - 5.7 Framed-Protocol ................................. 33 - 5.8 Framed-IP-Address ............................... 34 - 5.9 Framed-IP-Netmask ............................... 34 - 5.10 Framed-Routing .................................. 35 - 5.11 Filter-Id ....................................... 36 - 5.12 Framed-MTU ...................................... 37 - 5.13 Framed-Compression .............................. 37 - 5.14 Login-IP-Host ................................... 38 - 5.15 Login-Service ................................... 39 - 5.16 Login-TCP-Port .................................. 40 - 5.17 (unassigned) .................................... 41 - 5.18 Reply-Message ................................... 41 - 5.19 Callback-Number ................................. 42 - 5.20 Callback-Id ..................................... 42 - 5.21 (unassigned) .................................... 43 - 5.22 Framed-Route .................................... 43 - 5.23 Framed-IPX-Network .............................. 44 - 5.24 State ........................................... 45 - 5.25 Class ........................................... 46 - 5.26 Vendor-Specific ................................. 47 - 5.27 Session-Timeout ................................. 48 - 5.28 Idle-Timeout .................................... 49 - 5.29 Termination-Action .............................. 49 - - - -Rigney, et al. Standards Track [Page 2] - -RFC 2865 RADIUS June 2000 - - - 5.30 Called-Station-Id ............................... 50 - 5.31 Calling-Station-Id .............................. 51 - 5.32 NAS-Identifier .................................. 52 - 5.33 Proxy-State ..................................... 53 - 5.34 Login-LAT-Service ............................... 54 - 5.35 Login-LAT-Node .................................. 55 - 5.36 Login-LAT-Group ................................. 56 - 5.37 Framed-AppleTalk-Link ........................... 57 - 5.38 Framed-AppleTalk-Network ........................ 58 - 5.39 Framed-AppleTalk-Zone ........................... 58 - 5.40 CHAP-Challenge .................................. 59 - 5.41 NAS-Port-Type ................................... 60 - 5.42 Port-Limit ...................................... 61 - 5.43 Login-LAT-Port .................................. 62 - 5.44 Table of Attributes ............................. 63 - 6. IANA Considerations ................................... 64 - 6.1 Definition of Terms ............................. 64 - 6.2 Recommended Registration Policies ............... 65 - 7. Examples .............................................. 66 - 7.1 User Telnet to Specified Host ................... 66 - 7.2 Framed User Authenticating with CHAP ............ 67 - 7.3 User with Challenge-Response card ............... 68 - 8. Security Considerations ............................... 71 - 9. Change Log ............................................ 71 - 10. References ............................................ 73 - 11. Acknowledgements ...................................... 74 - 12. Chair's Address ....................................... 74 - 13. Authors' Addresses .................................... 75 - 14. Full Copyright Statement .............................. 76 - -1. Introduction - - This document obsoletes RFC 2138 [1]. A summary of the changes - between this document and RFC 2138 is available in the "Change Log" - appendix. - - Managing dispersed serial line and modem pools for large numbers of - users can create the need for significant administrative support. - Since modem pools are by definition a link to the outside world, they - require careful attention to security, authorization and accounting. - This can be best achieved by managing a single "database" of users, - which allows for authentication (verifying user name and password) as - well as configuration information detailing the type of service to - deliver to the user (for example, SLIP, PPP, telnet, rlogin). - - - - - - - -Rigney, et al. Standards Track [Page 3] - -RFC 2865 RADIUS June 2000 - - - Key features of RADIUS are: - - Client/Server Model - - A Network Access Server (NAS) operates as a client of RADIUS. The - client is responsible for passing user information to designated - RADIUS servers, and then acting on the response which is returned. - - RADIUS servers are responsible for receiving user connection - requests, authenticating the user, and then returning all - configuration information necessary for the client to deliver - service to the user. - - A RADIUS server can act as a proxy client to other RADIUS servers - or other kinds of authentication servers. - - Network Security - - Transactions between the client and RADIUS server are - authenticated through the use of a shared secret, which is never - sent over the network. In addition, any user passwords are sent - encrypted between the client and RADIUS server, to eliminate the - possibility that someone snooping on an unsecure network could - determine a user's password. - - Flexible Authentication Mechanisms - - The RADIUS server can support a variety of methods to authenticate - a user. When it is provided with the user name and original - password given by the user, it can support PPP PAP or CHAP, UNIX - login, and other authentication mechanisms. - - Extensible Protocol - - All transactions are comprised of variable length Attribute- - Length-Value 3-tuples. New attribute values can be added without - disturbing existing implementations of the protocol. - -1.1. Specification of Requirements - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [2]. These key - words mean the same thing whether capitalized or not. - - An implementation is not compliant if it fails to satisfy one or more - of the must or must not requirements for the protocols it implements. - An implementation that satisfies all the must, must not, should and - - - -Rigney, et al. Standards Track [Page 4] - -RFC 2865 RADIUS June 2000 - - - should not requirements for its protocols is said to be - "unconditionally compliant"; one that satisfies all the must and must - not requirements but not all the should or should not requirements - for its protocols is said to be "conditionally compliant". - - A NAS that does not implement a given service MUST NOT implement the - RADIUS attributes for that service. For example, a NAS that is - unable to offer ARAP service MUST NOT implement the RADIUS attributes - for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an - unavailable service as an access-reject instead. - -1.2. Terminology - - This document frequently uses the following terms: - - service The NAS provides a service to the dial-in user, such as PPP - or Telnet. - - session Each service provided by the NAS to a dial-in user - constitutes a session, with the beginning of the session - defined as the point where service is first provided and - the end of the session defined as the point where service - is ended. A user may have multiple sessions in parallel or - series if the NAS supports that. - - silently discard - This means the implementation discards the packet without - further processing. The implementation SHOULD provide the - capability of logging the error, including the contents of - the silently discarded packet, and SHOULD record the event - in a statistics counter. - -2. Operation - - When a client is configured to use RADIUS, any user of the client - presents authentication information to the client. This might be - with a customizable login prompt, where the user is expected to enter - their username and password. Alternatively, the user might use a - link framing protocol such as the Point-to-Point Protocol (PPP), - which has authentication packets which carry this information. - - Once the client has obtained such information, it may choose to - authenticate using RADIUS. To do so, the client creates an "Access- - Request" containing such Attributes as the user's name, the user's - password, the ID of the client and the Port ID which the user is - accessing. When a password is present, it is hidden using a method - based on the RSA Message Digest Algorithm MD5 [3]. - - - - -Rigney, et al. Standards Track [Page 5] - -RFC 2865 RADIUS June 2000 - - - The Access-Request is submitted to the RADIUS server via the network. - If no response is returned within a length of time, the request is - re-sent a number of times. The client can also forward requests to - an alternate server or servers in the event that the primary server - is down or unreachable. An alternate server can be used either after - a number of tries to the primary server fail, or in a round-robin - fashion. Retry and fallback algorithms are the topic of current - research and are not specified in detail in this document. - - Once the RADIUS server receives the request, it validates the sending - client. A request from a client for which the RADIUS server does not - have a shared secret MUST be silently discarded. If the client is - valid, the RADIUS server consults a database of users to find the - user whose name matches the request. The user entry in the database - contains a list of requirements which must be met to allow access for - the user. This always includes verification of the password, but can - also specify the client(s) or port(s) to which the user is allowed - access. - - The RADIUS server MAY make requests of other servers in order to - satisfy the request, in which case it acts as a client. - - If any Proxy-State attributes were present in the Access-Request, - they MUST be copied unmodified and in order into the response packet. - Other Attributes can be placed before, after, or even between the - Proxy-State attributes. - - If any condition is not met, the RADIUS server sends an "Access- - Reject" response indicating that this user request is invalid. If - desired, the server MAY include a text message in the Access-Reject - which MAY be displayed by the client to the user. No other - Attributes (except Proxy-State) are permitted in an Access-Reject. - - If all conditions are met and the RADIUS server wishes to issue a - challenge to which the user must respond, the RADIUS server sends an - "Access-Challenge" response. It MAY include a text message to be - displayed by the client to the user prompting for a response to the - challenge, and MAY include a State attribute. - - If the client receives an Access-Challenge and supports - challenge/response it MAY display the text message, if any, to the - user, and then prompt the user for a response. The client then re- - submits its original Access-Request with a new request ID, with the - User-Password Attribute replaced by the response (encrypted), and - including the State Attribute from the Access-Challenge, if any. - Only 0 or 1 instances of the State Attribute SHOULD be - - - - - -Rigney, et al. Standards Track [Page 6] - -RFC 2865 RADIUS June 2000 - - - present in a request. The server can respond to this new Access- - Request with either an Access-Accept, an Access-Reject, or another - Access-Challenge. - - If all conditions are met, the list of configuration values for the - user are placed into an "Access-Accept" response. These values - include the type of service (for example: SLIP, PPP, Login User) and - all necessary values to deliver the desired service. For SLIP and - PPP, this may include values such as IP address, subnet mask, MTU, - desired compression, and desired packet filter identifiers. For - character mode users, this may include values such as desired - protocol and host. - -2.1. Challenge/Response - - In challenge/response authentication, the user is given an - unpredictable number and challenged to encrypt it and give back the - result. Authorized users are equipped with special devices such as - smart cards or software that facilitate calculation of the correct - response with ease. Unauthorized users, lacking the appropriate - device or software and lacking knowledge of the secret key necessary - to emulate such a device or software, can only guess at the response. - - The Access-Challenge packet typically contains a Reply-Message - including a challenge to be displayed to the user, such as a numeric - value unlikely ever to be repeated. Typically this is obtained from - an external server that knows what type of authenticator is in the - possession of the authorized user and can therefore choose a random - or non-repeating pseudorandom number of an appropriate radix and - length. - - The user then enters the challenge into his device (or software) and - it calculates a response, which the user enters into the client which - forwards it to the RADIUS server via a second Access-Request. If the - response matches the expected response the RADIUS server replies with - an Access-Accept, otherwise an Access-Reject. - - Example: The NAS sends an Access-Request packet to the RADIUS Server - with NAS-Identifier, NAS-Port, User-Name, User-Password (which may - just be a fixed string like "challenge" or ignored). The server - sends back an Access-Challenge packet with State and a Reply-Message - along the lines of "Challenge 12345678, enter your response at the - prompt" which the NAS displays. The NAS prompts for the response and - sends a NEW Access-Request to the server (with a new ID) with NAS- - Identifier, NAS-Port, User-Name, User-Password (the response just - entered by the user, encrypted), and the same State Attribute that - - - - - -Rigney, et al. Standards Track [Page 7] - -RFC 2865 RADIUS June 2000 - - - came with the Access-Challenge. The server then sends back either an - Access-Accept or Access-Reject based on whether the response matches - the required value, or it can even send another Access-Challenge. - -2.2. Interoperation with PAP and CHAP - - For PAP, the NAS takes the PAP ID and password and sends them in an - Access-Request packet as the User-Name and User-Password. The NAS MAY - include the Attributes Service-Type = Framed-User and Framed-Protocol - = PPP as a hint to the RADIUS server that PPP service is expected. - - For CHAP, the NAS generates a random challenge (preferably 16 octets) - and sends it to the user, who returns a CHAP response along with a - CHAP ID and CHAP username. The NAS then sends an Access-Request - packet to the RADIUS server with the CHAP username as the User-Name - and with the CHAP ID and CHAP response as the CHAP-Password - (Attribute 3). The random challenge can either be included in the - CHAP-Challenge attribute or, if it is 16 octets long, it can be - placed in the Request Authenticator field of the Access-Request - packet. The NAS MAY include the Attributes Service-Type = Framed- - User and Framed-Protocol = PPP as a hint to the RADIUS server that - PPP service is expected. - - The RADIUS server looks up a password based on the User-Name, - encrypts the challenge using MD5 on the CHAP ID octet, that password, - and the CHAP challenge (from the CHAP-Challenge attribute if present, - otherwise from the Request Authenticator), and compares that result - to the CHAP-Password. If they match, the server sends back an - Access-Accept, otherwise it sends back an Access-Reject. - - If the RADIUS server is unable to perform the requested - authentication it MUST return an Access-Reject. For example, CHAP - requires that the user's password be available in cleartext to the - server so that it can encrypt the CHAP challenge and compare that to - the CHAP response. If the password is not available in cleartext to - the RADIUS server then the server MUST send an Access-Reject to the - client. - -2.3. Proxy - - With proxy RADIUS, one RADIUS server receives an authentication (or - accounting) request from a RADIUS client (such as a NAS), forwards - the request to a remote RADIUS server, receives the reply from the - remote server, and sends that reply to the client, possibly with - changes to reflect local administrative policy. A common use for - proxy RADIUS is roaming. Roaming permits two or more administrative - entities to allow each other's users to dial in to either entity's - network for service. - - - -Rigney, et al. Standards Track [Page 8] - -RFC 2865 RADIUS June 2000 - - - The NAS sends its RADIUS access-request to the "forwarding server" - which forwards it to the "remote server". The remote server sends a - response (Access-Accept, Access-Reject, or Access-Challenge) back to - the forwarding server, which sends it back to the NAS. The User-Name - attribute MAY contain a Network Access Identifier [8] for RADIUS - Proxy operations. The choice of which server receives the forwarded - request SHOULD be based on the authentication "realm". The - authentication realm MAY be the realm part of a Network Access - Identifier (a "named realm"). Alternatively, the choice of which - server receives the forwarded request MAY be based on whatever other - criteria the forwarding server is configured to use, such as Called- - Station-Id (a "numbered realm"). - - A RADIUS server can function as both a forwarding server and a remote - server, serving as a forwarding server for some realms and a remote - server for other realms. One forwarding server can act as a - forwarder for any number of remote servers. A remote server can have - any number of servers forwarding to it and can provide authentication - for any number of realms. One forwarding server can forward to - another forwarding server to create a chain of proxies, although care - must be taken to avoid introducing loops. - - The following scenario illustrates a proxy RADIUS communication - between a NAS and the forwarding and remote RADIUS servers: - - 1. A NAS sends its access-request to the forwarding server. - - 2. The forwarding server forwards the access-request to the remote - server. - - 3. The remote server sends an access-accept, access-reject or - access-challenge back to the forwarding server. For this example, - an access-accept is sent. - - 4. The forwarding server sends the access-accept to the NAS. - - The forwarding server MUST treat any Proxy-State attributes already - in the packet as opaque data. Its operation MUST NOT depend on the - content of Proxy-State attributes added by previous servers. - - If there are any Proxy-State attributes in the request received from - the client, the forwarding server MUST include those Proxy-State - attributes in its reply to the client. The forwarding server MAY - include the Proxy-State attributes in the access-request when it - forwards the request, or MAY omit them in the forwarded request. If - the forwarding server omits the Proxy-State attributes in the - forwarded access-request, it MUST attach them to the response before - sending it to the client. - - - -Rigney, et al. Standards Track [Page 9] - -RFC 2865 RADIUS June 2000 - - - We now examine each step in more detail. - - 1. A NAS sends its access-request to the forwarding server. The - forwarding server decrypts the User-Password, if present, using - the shared secret it knows for the NAS. If a CHAP-Password - attribute is present in the packet and no CHAP-Challenge attribute - is present, the forwarding server MUST leave the Request- - Authenticator untouched or copy it to a CHAP-Challenge attribute. - - '' The forwarding server MAY add one Proxy-State attribute to the - packet. (It MUST NOT add more than one.) If it adds a Proxy- - State, the Proxy-State MUST appear after any other Proxy-States in - the packet. The forwarding server MUST NOT modify any other - Proxy-States that were in the packet (it may choose not to forward - them, but it MUST NOT change their contents). The forwarding - server MUST NOT change the order of any attributes of the same - type, including Proxy-State. - - 2. The forwarding server encrypts the User-Password, if present, - using the secret it shares with the remote server, sets the - Identifier as needed, and forwards the access-request to the - remote server. - - 3. The remote server (if the final destination) verifies the user - using User-Password, CHAP-Password, or such method as future - extensions may dictate, and returns an access-accept, access- - reject or access-challenge back to the forwarding server. For - this example, an access-accept is sent. The remote server MUST - copy all Proxy-State attributes (and only the Proxy-State - attributes) in order from the access-request to the response - packet, without modifying them. - - 4. The forwarding server verifies the Response Authenticator using - the secret it shares with the remote server, and silently discards - the packet if it fails verification. If the packet passes - verification, the forwarding server removes the last Proxy-State - (if it attached one), signs the Response Authenticator using the - secret it shares with the NAS, restores the Identifier to match - the one in the original request by the NAS, and sends the access- - accept to the NAS. - - A forwarding server MAY need to modify attributes to enforce local - policy. Such policy is outside the scope of this document, with the - following restrictions. A forwarding server MUST not modify existing - Proxy-State, State, or Class attributes present in the packet. - - - - - - -Rigney, et al. Standards Track [Page 10] - -RFC 2865 RADIUS June 2000 - - - Implementers of forwarding servers should consider carefully which - values it is willing to accept for Service-Type. Careful - consideration must be given to the effects of passing along Service- - Types of NAS-Prompt or Administrative in a proxied Access-Accept, and - implementers may wish to provide mechanisms to block those or other - service types, or other attributes. Such mechanisms are outside the - scope of this document. - -2.4. Why UDP? - - A frequently asked question is why RADIUS uses UDP instead of TCP as - a transport protocol. UDP was chosen for strictly technical reasons. - - There are a number of issues which must be understood. RADIUS is a - transaction based protocol which has several interesting - characteristics: - - 1. If the request to a primary Authentication server fails, a - secondary server must be queried. - - To meet this requirement, a copy of the request must be kept above - the transport layer to allow for alternate transmission. This - means that retransmission timers are still required. - - 2. The timing requirements of this particular protocol are - significantly different than TCP provides. - - At one extreme, RADIUS does not require a "responsive" detection - of lost data. The user is willing to wait several seconds for the - authentication to complete. The generally aggressive TCP - retransmission (based on average round trip time) is not required, - nor is the acknowledgement overhead of TCP. - - At the other extreme, the user is not willing to wait several - minutes for authentication. Therefore the reliable delivery of - TCP data two minutes later is not useful. The faster use of an - alternate server allows the user to gain access before giving up. - - 3. The stateless nature of this protocol simplifies the use of UDP. - - Clients and servers come and go. Systems are rebooted, or are - power cycled independently. Generally this does not cause a - problem and with creative timeouts and detection of lost TCP - connections, code can be written to handle anomalous events. UDP - however completely eliminates any of this special handling. Each - client and server can open their UDP transport just once and leave - it open through all types of failure events on the network. - - - - -Rigney, et al. Standards Track [Page 11] - -RFC 2865 RADIUS June 2000 - - - 4. UDP simplifies the server implementation. - - In the earliest implementations of RADIUS, the server was single - threaded. This means that a single request was received, - processed, and returned. This was found to be unmanageable in - environments where the back-end security mechanism took real time - (1 or more seconds). The server request queue would fill and in - environments where hundreds of people were being authenticated - every minute, the request turn-around time increased to longer - than users were willing to wait (this was especially severe when a - specific lookup in a database or over DNS took 30 or more - seconds). The obvious solution was to make the server multi- - threaded. Achieving this was simple with UDP. Separate processes - were spawned to serve each request and these processes could - respond directly to the client NAS with a simple UDP packet to the - original transport of the client. - - It's not all a panacea. As noted, using UDP requires one thing which - is built into TCP: with UDP we must artificially manage - retransmission timers to the same server, although they don't require - the same attention to timing provided by TCP. This one penalty is a - small price to pay for the advantages of UDP in this protocol. - - Without TCP we would still probably be using tin cans connected by - string. But for this particular protocol, UDP is a better choice. - -2.5. Retransmission Hints - - If the RADIUS server and alternate RADIUS server share the same - shared secret, it is OK to retransmit the packet to the alternate - RADIUS server with the same ID and Request Authenticator, because the - content of the attributes haven't changed. If you want to use a new - Request Authenticator when sending to the alternate server, you may. - - If you change the contents of the User-Password attribute (or any - other attribute), you need a new Request Authenticator and therefore - a new ID. - - If the NAS is retransmitting a RADIUS request to the same server as - before, and the attributes haven't changed, you MUST use the same - Request Authenticator, ID, and source port. If any attributes have - changed, you MUST use a new Request Authenticator and ID. - - A NAS MAY use the same ID across all servers, or MAY keep track of - IDs separately for each server, it is up to the implementer. If a - NAS needs more than 256 IDs for outstanding requests, it MAY use - - - - - -Rigney, et al. Standards Track [Page 12] - -RFC 2865 RADIUS June 2000 - - - additional source ports to send requests from, and keep track of IDs - for each source port. This allows up to 16 million or so outstanding - requests at one time to a single server. - -2.6. Keep-Alives Considered Harmful - - Some implementers have adopted the practice of sending test RADIUS - requests to see if a server is alive. This practice is strongly - discouraged, since it adds to load and harms scalability without - providing any additional useful information. Since a RADIUS request - is contained in a single datagram, in the time it would take you to - send a ping you could just send the RADIUS request, and getting a - reply tells you that the RADIUS server is up. If you do not have a - RADIUS request to send, it does not matter if the server is up or - not, because you are not using it. - - If you want to monitor your RADIUS server, use SNMP. That's what - SNMP is for. - -3. Packet Format - - Exactly one RADIUS packet is encapsulated in the UDP Data field [4], - where the UDP Destination Port field indicates 1812 (decimal). - - When a reply is generated, the source and destination ports are - reversed. - - This memo documents the RADIUS protocol. The early deployment of - RADIUS was done using UDP port number 1645, which conflicts with the - "datametrics" service. The officially assigned port number for - RADIUS is 1812. - - - - - - - - - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 13] - -RFC 2865 RADIUS June 2000 - - - A summary of the RADIUS data format is shown below. The fields are - transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Identifier | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Authenticator | - | | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attributes ... - +-+-+-+-+-+-+-+-+-+-+-+-+- - - Code - - The Code field is one octet, and identifies the type of RADIUS - packet. When a packet is received with an invalid Code field, it - is silently discarded. - - RADIUS Codes (decimal) are assigned as follows: - - 1 Access-Request - 2 Access-Accept - 3 Access-Reject - 4 Accounting-Request - 5 Accounting-Response - 11 Access-Challenge - 12 Status-Server (experimental) - 13 Status-Client (experimental) - 255 Reserved - - Codes 4 and 5 are covered in the RADIUS Accounting document [5]. - Codes 12 and 13 are reserved for possible use, but are not further - mentioned here. - - Identifier - - The Identifier field is one octet, and aids in matching requests - and replies. The RADIUS server can detect a duplicate request if - it has the same client source IP address and source UDP port and - Identifier within a short span of time. - - - - - - - -Rigney, et al. Standards Track [Page 14] - -RFC 2865 RADIUS June 2000 - - - Length - - The Length field is two octets. It indicates the length of the - packet including the Code, Identifier, Length, Authenticator and - Attribute fields. Octets outside the range of the Length field - MUST be treated as padding and ignored on reception. If the - packet is shorter than the Length field indicates, it MUST be - silently discarded. The minimum length is 20 and maximum length - is 4096. - - Authenticator - - The Authenticator field is sixteen (16) octets. The most - significant octet is transmitted first. This value is used to - authenticate the reply from the RADIUS server, and is used in the - password hiding algorithm. - - Request Authenticator - - In Access-Request Packets, the Authenticator value is a 16 - octet random number, called the Request Authenticator. The - value SHOULD be unpredictable and unique over the lifetime of a - secret (the password shared between the client and the RADIUS - server), since repetition of a request value in conjunction - with the same secret would permit an attacker to reply with a - previously intercepted response. Since it is expected that the - same secret MAY be used to authenticate with servers in - disparate geographic regions, the Request Authenticator field - SHOULD exhibit global and temporal uniqueness. - - The Request Authenticator value in an Access-Request packet - SHOULD also be unpredictable, lest an attacker trick a server - into responding to a predicted future request, and then use the - response to masquerade as that server to a future Access- - Request. - - Although protocols such as RADIUS are incapable of protecting - against theft of an authenticated session via realtime active - wiretapping attacks, generation of unique unpredictable - requests can protect against a wide range of active attacks - against authentication. - - The NAS and RADIUS server share a secret. That shared secret - followed by the Request Authenticator is put through a one-way - MD5 hash to create a 16 octet digest value which is xored with - the password entered by the user, and the xored result placed - - - - - -Rigney, et al. Standards Track [Page 15] - -RFC 2865 RADIUS June 2000 - - - in the User-Password attribute in the Access-Request packet. - See the entry for User-Password in the section on Attributes - for a more detailed description. - - Response Authenticator - - The value of the Authenticator field in Access-Accept, Access- - Reject, and Access-Challenge packets is called the Response - Authenticator, and contains a one-way MD5 hash calculated over - a stream of octets consisting of: the RADIUS packet, beginning - with the Code field, including the Identifier, the Length, the - Request Authenticator field from the Access-Request packet, and - the response Attributes, followed by the shared secret. That - is, ResponseAuth = - MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + - denotes concatenation. - - Administrative Note - - The secret (password shared between the client and the RADIUS - server) SHOULD be at least as large and unguessable as a well- - chosen password. It is preferred that the secret be at least 16 - octets. This is to ensure a sufficiently large range for the - secret to provide protection against exhaustive search attacks. - The secret MUST NOT be empty (length 0) since this would allow - packets to be trivially forged. - - A RADIUS server MUST use the source IP address of the RADIUS UDP - packet to decide which shared secret to use, so that RADIUS - requests can be proxied. - - When using a forwarding proxy, the proxy must be able to alter the - packet as it passes through in each direction - when the proxy - forwards the request, the proxy MAY add a Proxy-State Attribute, - and when the proxy forwards a response, it MUST remove its Proxy- - State Attribute if it added one. Proxy-State is always added or - removed after any other Proxy-States, but no other assumptions - regarding its location within the list of attributes can be made. - Since Access-Accept and Access-Reject replies are authenticated on - the entire packet contents, the stripping of the Proxy-State - attribute invalidates the signature in the packet - so the proxy - has to re-sign it. - - Further details of RADIUS proxy implementation are outside the - scope of this document. - - - - - - -Rigney, et al. Standards Track [Page 16] - -RFC 2865 RADIUS June 2000 - - -4. Packet Types - - The RADIUS Packet type is determined by the Code field in the first - octet of the Packet. - -4.1. Access-Request - - Description - - Access-Request packets are sent to a RADIUS server, and convey - information used to determine whether a user is allowed access to - a specific NAS, and any special services requested for that user. - An implementation wishing to authenticate a user MUST transmit a - RADIUS packet with the Code field set to 1 (Access-Request). - - Upon receipt of an Access-Request from a valid client, an - appropriate reply MUST be transmitted. - - An Access-Request SHOULD contain a User-Name attribute. It MUST - contain either a NAS-IP-Address attribute or a NAS-Identifier - attribute (or both). - - An Access-Request MUST contain either a User-Password or a CHAP- - Password or a State. An Access-Request MUST NOT contain both a - User-Password and a CHAP-Password. If future extensions allow - other kinds of authentication information to be conveyed, the - attribute for that can be used in an Access-Request instead of - User-Password or CHAP-Password. - - An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type - attribute or both unless the type of access being requested does - not involve a port or the NAS does not distinguish among its - ports. - - An Access-Request MAY contain additional attributes as a hint to - the server, but the server is not required to honor the hint. - - When a User-Password is present, it is hidden using a method based - on the RSA Message Digest Algorithm MD5 [3]. - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 17] - -RFC 2865 RADIUS June 2000 - - - A summary of the Access-Request packet format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Identifier | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Request Authenticator | - | | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attributes ... - +-+-+-+-+-+-+-+-+-+-+-+-+- - - Code - - 1 for Access-Request. - - Identifier - - The Identifier field MUST be changed whenever the content of the - Attributes field changes, and whenever a valid reply has been - received for a previous request. For retransmissions, the - Identifier MUST remain unchanged. - - Request Authenticator - - The Request Authenticator value MUST be changed each time a new - Identifier is used. - - Attributes - - The Attribute field is variable in length, and contains the list - of Attributes that are required for the type of service, as well - as any desired optional Attributes. - -4.2. Access-Accept - - Description - - Access-Accept packets are sent by the RADIUS server, and provide - specific configuration information necessary to begin delivery of - service to the user. If all Attribute values received in an - Access-Request are acceptable then the RADIUS implementation MUST - transmit a packet with the Code field set to 2 (Access-Accept). - - - - -Rigney, et al. Standards Track [Page 18] - -RFC 2865 RADIUS June 2000 - - - On reception of an Access-Accept, the Identifier field is matched - with a pending Access-Request. The Response Authenticator field - MUST contain the correct response for the pending Access-Request. - Invalid packets are silently discarded. - - A summary of the Access-Accept packet format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Identifier | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Response Authenticator | - | | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attributes ... - +-+-+-+-+-+-+-+-+-+-+-+-+- - - Code - - 2 for Access-Accept. - - Identifier - - The Identifier field is a copy of the Identifier field of the - Access-Request which caused this Access-Accept. - - Response Authenticator - - The Response Authenticator value is calculated from the Access- - Request value, as described earlier. - - Attributes - - The Attribute field is variable in length, and contains a list of - zero or more Attributes. - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 19] - -RFC 2865 RADIUS June 2000 - - -4.3. Access-Reject - - Description - - If any value of the received Attributes is not acceptable, then - the RADIUS server MUST transmit a packet with the Code field set - to 3 (Access-Reject). It MAY include one or more Reply-Message - Attributes with a text message which the NAS MAY display to the - user. - - A summary of the Access-Reject packet format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Identifier | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Response Authenticator | - | | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attributes ... - +-+-+-+-+-+-+-+-+-+-+-+-+- - - Code - - 3 for Access-Reject. - - Identifier - - The Identifier field is a copy of the Identifier field of the - Access-Request which caused this Access-Reject. - - Response Authenticator - - The Response Authenticator value is calculated from the Access- - Request value, as described earlier. - - Attributes - - The Attribute field is variable in length, and contains a list of - zero or more Attributes. - - - - - - - -Rigney, et al. Standards Track [Page 20] - -RFC 2865 RADIUS June 2000 - - -4.4. Access-Challenge - - Description - - If the RADIUS server desires to send the user a challenge - requiring a response, then the RADIUS server MUST respond to the - Access-Request by transmitting a packet with the Code field set to - 11 (Access-Challenge). - - The Attributes field MAY have one or more Reply-Message - Attributes, and MAY have a single State Attribute, or none. - Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State - attributes MAY also be included. No other Attributes defined in - this document are permitted in an Access-Challenge. - - On receipt of an Access-Challenge, the Identifier field is matched - with a pending Access-Request. Additionally, the Response - Authenticator field MUST contain the correct response for the - pending Access-Request. Invalid packets are silently discarded. - - If the NAS does not support challenge/response, it MUST treat an - Access-Challenge as though it had received an Access-Reject - instead. - - If the NAS supports challenge/response, receipt of a valid - Access-Challenge indicates that a new Access-Request SHOULD be - sent. The NAS MAY display the text message, if any, to the user, - and then prompt the user for a response. It then sends its - original Access-Request with a new request ID and Request - Authenticator, with the User-Password Attribute replaced by the - user's response (encrypted), and including the State Attribute - from the Access-Challenge, if any. Only 0 or 1 instances of the - State Attribute can be present in an Access-Request. - - A NAS which supports PAP MAY forward the Reply-Message to the - dialing client and accept a PAP response which it can use as - though the user had entered the response. If the NAS cannot do - so, it MUST treat the Access-Challenge as though it had received - an Access-Reject instead. - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 21] - -RFC 2865 RADIUS June 2000 - - - A summary of the Access-Challenge packet format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Identifier | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - | Response Authenticator | - | | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attributes ... - +-+-+-+-+-+-+-+-+-+-+-+-+- - - Code - - 11 for Access-Challenge. - - Identifier - - The Identifier field is a copy of the Identifier field of the - Access-Request which caused this Access-Challenge. - - Response Authenticator - - The Response Authenticator value is calculated from the Access- - Request value, as described earlier. - - Attributes - - The Attributes field is variable in length, and contains a list of - zero or more Attributes. - -5. Attributes - - RADIUS Attributes carry the specific authentication, authorization, - information and configuration details for the request and reply. - - The end of the list of Attributes is indicated by the Length of the - RADIUS packet. - - Some Attributes MAY be included more than once. The effect of this - is Attribute specific, and is specified in each Attribute - description. A summary table is provided at the end of the - "Attributes" section. - - - - -Rigney, et al. Standards Track [Page 22] - -RFC 2865 RADIUS June 2000 - - - If multiple Attributes with the same Type are present, the order of - Attributes with the same Type MUST be preserved by any proxies. The - order of Attributes of different Types is not required to be - preserved. A RADIUS server or client MUST NOT have any dependencies - on the order of attributes of different types. A RADIUS server or - client MUST NOT require attributes of the same type to be contiguous. - - Where an Attribute's description limits which kinds of packet it can - be contained in, this applies only to the packet types defined in - this document, namely Access-Request, Access-Accept, Access-Reject - and Access-Challenge (Codes 1, 2, 3, and 11). Other documents - defining other packet types may also use Attributes described here. - To determine which Attributes are allowed in Accounting-Request and - Accounting-Response packets (Codes 4 and 5) refer to the RADIUS - Accounting document [5]. - - Likewise where packet types defined here state that only certain - Attributes are permissible in them, future memos defining new - Attributes should indicate which packet types the new Attributes may - be present in. - - A summary of the Attribute format is shown below. The fields are - transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | Value ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - The Type field is one octet. Up-to-date values of the RADIUS Type - field are specified in the most recent "Assigned Numbers" RFC [6]. - Values 192-223 are reserved for experimental use, values 224-240 - are reserved for implementation-specific use, and values 241-255 - are reserved and should not be used. - - A RADIUS server MAY ignore Attributes with an unknown Type. - - A RADIUS client MAY ignore Attributes with an unknown Type. - - - - - - - - - - -Rigney, et al. Standards Track [Page 23] - -RFC 2865 RADIUS June 2000 - - - This specification concerns the following values: - - 1 User-Name - 2 User-Password - 3 CHAP-Password - 4 NAS-IP-Address - 5 NAS-Port - 6 Service-Type - 7 Framed-Protocol - 8 Framed-IP-Address - 9 Framed-IP-Netmask - 10 Framed-Routing - 11 Filter-Id - 12 Framed-MTU - 13 Framed-Compression - 14 Login-IP-Host - 15 Login-Service - 16 Login-TCP-Port - 17 (unassigned) - 18 Reply-Message - 19 Callback-Number - 20 Callback-Id - 21 (unassigned) - 22 Framed-Route - 23 Framed-IPX-Network - 24 State - 25 Class - 26 Vendor-Specific - 27 Session-Timeout - 28 Idle-Timeout - 29 Termination-Action - 30 Called-Station-Id - 31 Calling-Station-Id - 32 NAS-Identifier - 33 Proxy-State - 34 Login-LAT-Service - 35 Login-LAT-Node - 36 Login-LAT-Group - 37 Framed-AppleTalk-Link - 38 Framed-AppleTalk-Network - 39 Framed-AppleTalk-Zone - 40-59 (reserved for accounting) - 60 CHAP-Challenge - 61 NAS-Port-Type - 62 Port-Limit - 63 Login-LAT-Port - - - - - -Rigney, et al. Standards Track [Page 24] - -RFC 2865 RADIUS June 2000 - - - Length - - The Length field is one octet, and indicates the length of this - Attribute including the Type, Length and Value fields. If an - Attribute is received in an Access-Request but with an invalid - Length, an Access-Reject SHOULD be transmitted. If an Attribute - is received in an Access-Accept, Access-Reject or Access-Challenge - packet with an invalid length, the packet MUST either be treated - as an Access-Reject or else silently discarded. - - Value - - The Value field is zero or more octets and contains information - specific to the Attribute. The format and length of the Value - field is determined by the Type and Length fields. - - Note that none of the types in RADIUS terminate with a NUL (hex - 00). In particular, types "text" and "string" in RADIUS do not - terminate with a NUL (hex 00). The Attribute has a length field - and does not use a terminator. Text contains UTF-8 encoded 10646 - [7] characters and String contains 8-bit binary data. Servers and - servers and clients MUST be able to deal with embedded nulls. - RADIUS implementers using C are cautioned not to use strcpy() when - handling strings. - - The format of the value field is one of five data types. Note - that type "text" is a subset of type "string". - - text 1-253 octets containing UTF-8 encoded 10646 [7] - characters. Text of length zero (0) MUST NOT be sent; - omit the entire attribute instead. - - string 1-253 octets containing binary data (values 0 through - 255 decimal, inclusive). Strings of length zero (0) - MUST NOT be sent; omit the entire attribute instead. - - address 32 bit value, most significant octet first. - - integer 32 bit unsigned value, most significant octet first. - - time 32 bit unsigned value, most significant octet first -- - seconds since 00:00:00 UTC, January 1, 1970. The - standard Attributes do not use this data type but it is - presented here for possible use in future attributes. - - - - - - - -Rigney, et al. Standards Track [Page 25] - -RFC 2865 RADIUS June 2000 - - -5.1. User-Name - - Description - - This Attribute indicates the name of the user to be authenticated. - It MUST be sent in Access-Request packets if available. - - It MAY be sent in an Access-Accept packet, in which case the - client SHOULD use the name returned in the Access-Accept packet in - all Accounting-Request packets for this session. If the Access- - Accept includes Service-Type = Rlogin and the User-Name attribute, - a NAS MAY use the returned User-Name when performing the Rlogin - function. - - A summary of the User-Name Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 1 for User-Name. - - Length - - >= 3 - - String - - The String field is one or more octets. The NAS may limit the - maximum length of the User-Name but the ability to handle at least - 63 octets is recommended. - - The format of the username MAY be one of several forms: - - text Consisting only of UTF-8 encoded 10646 [7] characters. - - network access identifier - A Network Access Identifier as described in RFC 2486 - [8]. - - distinguished name - A name in ASN.1 form used in Public Key authentication - systems. - - - -Rigney, et al. Standards Track [Page 26] - -RFC 2865 RADIUS June 2000 - - -5.2. User-Password - - Description - - This Attribute indicates the password of the user to be - authenticated, or the user's input following an Access-Challenge. - It is only used in Access-Request packets. - - On transmission, the password is hidden. The password is first - padded at the end with nulls to a multiple of 16 octets. A one- - way MD5 hash is calculated over a stream of octets consisting of - the shared secret followed by the Request Authenticator. This - value is XORed with the first 16 octet segment of the password and - placed in the first 16 octets of the String field of the User- - Password Attribute. - - If the password is longer than 16 characters, a second one-way MD5 - hash is calculated over a stream of octets consisting of the - shared secret followed by the result of the first xor. That hash - is XORed with the second 16 octet segment of the password and - placed in the second 16 octets of the String field of the User- - Password Attribute. - - If necessary, this operation is repeated, with each xor result - being used along with the shared secret to generate the next hash - to xor the next segment of the password, to no more than 128 - characters. - - The method is taken from the book "Network Security" by Kaufman, - Perlman and Speciner [9] pages 109-110. A more precise - explanation of the method follows: - - Call the shared secret S and the pseudo-random 128-bit Request - Authenticator RA. Break the password into 16-octet chunks p1, p2, - etc. with the last one padded at the end with nulls to a 16-octet - boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need - intermediate values b1, b2, etc. - - b1 = MD5(S + RA) c(1) = p1 xor b1 - b2 = MD5(S + c(1)) c(2) = p2 xor b2 - . . - . . - . . - bi = MD5(S + c(i-1)) c(i) = pi xor bi - - The String will contain c(1)+c(2)+...+c(i) where + denotes - concatenation. - - - - -Rigney, et al. Standards Track [Page 27] - -RFC 2865 RADIUS June 2000 - - - On receipt, the process is reversed to yield the original - password. - - A summary of the User-Password Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 2 for User-Password. - - Length - - At least 18 and no larger than 130. - - String - - The String field is between 16 and 128 octets long, inclusive. - -5.3. CHAP-Password - - Description - - This Attribute indicates the response value provided by a PPP - Challenge-Handshake Authentication Protocol (CHAP) user in - response to the challenge. It is only used in Access-Request - packets. - - The CHAP challenge value is found in the CHAP-Challenge Attribute - (60) if present in the packet, otherwise in the Request - Authenticator field. - - A summary of the CHAP-Password Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | CHAP Ident | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -Rigney, et al. Standards Track [Page 28] - -RFC 2865 RADIUS June 2000 - - - Type - - 3 for CHAP-Password. - - Length - - 19 - - CHAP Ident - - This field is one octet, and contains the CHAP Identifier from the - user's CHAP Response. - - String - - The String field is 16 octets, and contains the CHAP Response from - the user. - -5.4. NAS-IP-Address - - Description - - This Attribute indicates the identifying IP Address of the NAS - which is requesting authentication of the user, and SHOULD be - unique to the NAS within the scope of the RADIUS server. NAS-IP- - Address is only used in Access-Request packets. Either NAS-IP- - Address or NAS-Identifier MUST be present in an Access-Request - packet. - - Note that NAS-IP-Address MUST NOT be used to select the shared - secret used to authenticate the request. The source IP address of - the Access-Request packet MUST be used to select the shared - secret. - - A summary of the NAS-IP-Address Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Address - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 4 for NAS-IP-Address. - - - -Rigney, et al. Standards Track [Page 29] - -RFC 2865 RADIUS June 2000 - - - Length - - 6 - - Address - - The Address field is four octets. - -5.5. NAS-Port - - Description - - This Attribute indicates the physical port number of the NAS which - is authenticating the user. It is only used in Access-Request - packets. Note that this is using "port" in its sense of a - physical connection on the NAS, not in the sense of a TCP or UDP - port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD - be present in an Access-Request packet, if the NAS differentiates - among its ports. - - A summary of the NAS-Port Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 5 for NAS-Port. - - Length - - 6 - - Value - - The Value field is four octets. - - - - - - - - - -Rigney, et al. Standards Track [Page 30] - -RFC 2865 RADIUS June 2000 - - -5.6. Service-Type - - Description - - This Attribute indicates the type of service the user has - requested, or the type of service to be provided. It MAY be used - in both Access-Request and Access-Accept packets. A NAS is not - required to implement all of these service types, and MUST treat - unknown or unsupported Service-Types as though an Access-Reject - had been received instead. - - A summary of the Service-Type Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 6 for Service-Type. - - Length - - 6 - - Value - - The Value field is four octets. - - 1 Login - 2 Framed - 3 Callback Login - 4 Callback Framed - 5 Outbound - 6 Administrative - 7 NAS Prompt - 8 Authenticate Only - 9 Callback NAS Prompt - 10 Call Check - 11 Callback Administrative - - - - - - -Rigney, et al. Standards Track [Page 31] - -RFC 2865 RADIUS June 2000 - - - The service types are defined as follows when used in an Access- - Accept. When used in an Access-Request, they MAY be considered to - be a hint to the RADIUS server that the NAS has reason to believe - the user would prefer the kind of service indicated, but the - server is not required to honor the hint. - - Login The user should be connected to a host. - - Framed A Framed Protocol should be started for the - User, such as PPP or SLIP. - - Callback Login The user should be disconnected and called - back, then connected to a host. - - Callback Framed The user should be disconnected and called - back, then a Framed Protocol should be started - for the User, such as PPP or SLIP. - - Outbound The user should be granted access to outgoing - devices. - - Administrative The user should be granted access to the - administrative interface to the NAS from which - privileged commands can be executed. - - NAS Prompt The user should be provided a command prompt - on the NAS from which non-privileged commands - can be executed. - - Authenticate Only Only Authentication is requested, and no - authorization information needs to be returned - in the Access-Accept (typically used by proxy - servers rather than the NAS itself). - - Callback NAS Prompt The user should be disconnected and called - back, then provided a command prompt on the - NAS from which non-privileged commands can be - executed. - - Call Check Used by the NAS in an Access-Request packet to - indicate that a call is being received and - that the RADIUS server should send back an - Access-Accept to answer the call, or an - Access-Reject to not accept the call, - typically based on the Called-Station-Id or - Calling-Station-Id attributes. It is - - - - - -Rigney, et al. Standards Track [Page 32] - -RFC 2865 RADIUS June 2000 - - - recommended that such Access-Requests use the - value of Calling-Station-Id as the value of - the User-Name. - - Callback Administrative - The user should be disconnected and called - back, then granted access to the - administrative interface to the NAS from which - privileged commands can be executed. - -5.7. Framed-Protocol - - Description - - This Attribute indicates the framing to be used for framed access. - It MAY be used in both Access-Request and Access-Accept packets. - - A summary of the Framed-Protocol Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 7 for Framed-Protocol. - - Length - - 6 - - Value - - The Value field is four octets. - - 1 PPP - 2 SLIP - 3 AppleTalk Remote Access Protocol (ARAP) - 4 Gandalf proprietary SingleLink/MultiLink protocol - 5 Xylogics proprietary IPX/SLIP - 6 X.75 Synchronous - - - - - -Rigney, et al. Standards Track [Page 33] - -RFC 2865 RADIUS June 2000 - - -5.8. Framed-IP-Address - - Description - - This Attribute indicates the address to be configured for the - user. It MAY be used in Access-Accept packets. It MAY be used in - an Access-Request packet as a hint by the NAS to the server that - it would prefer that address, but the server is not required to - honor the hint. - - A summary of the Framed-IP-Address Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Address - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 8 for Framed-IP-Address. - - Length - - 6 - - Address - - The Address field is four octets. The value 0xFFFFFFFF indicates - that the NAS Should allow the user to select an address (e.g. - Negotiated). The value 0xFFFFFFFE indicates that the NAS should - select an address for the user (e.g. Assigned from a pool of - addresses kept by the NAS). Other valid values indicate that the - NAS should use that value as the user's IP address. - -5.9. Framed-IP-Netmask - - Description - - This Attribute indicates the IP netmask to be configured for the - user when the user is a router to a network. It MAY be used in - Access-Accept packets. It MAY be used in an Access-Request packet - as a hint by the NAS to the server that it would prefer that - netmask, but the server is not required to honor the hint. - - - - -Rigney, et al. Standards Track [Page 34] - -RFC 2865 RADIUS June 2000 - - - A summary of the Framed-IP-Netmask Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Address - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 9 for Framed-IP-Netmask. - - Length - - 6 - - Address - - The Address field is four octets specifying the IP netmask of the - user. - -5.10. Framed-Routing - - Description - - This Attribute indicates the routing method for the user, when the - user is a router to a network. It is only used in Access-Accept - packets. - - A summary of the Framed-Routing Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 10 for Framed-Routing. - - - - - -Rigney, et al. Standards Track [Page 35] - -RFC 2865 RADIUS June 2000 - - - Length - - 6 - - Value - - The Value field is four octets. - - 0 None - 1 Send routing packets - 2 Listen for routing packets - 3 Send and Listen - -5.11. Filter-Id - - Description - - This Attribute indicates the name of the filter list for this - user. Zero or more Filter-Id attributes MAY be sent in an - Access-Accept packet. - - Identifying a filter list by name allows the filter to be used on - different NASes without regard to filter-list implementation - details. - - A summary of the Filter-Id Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | Text ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 11 for Filter-Id. - - Length - - >= 3 - - Text - - The Text field is one or more octets, and its contents are - implementation dependent. It is intended to be human readable and - MUST NOT affect operation of the protocol. It is recommended that - the message contain UTF-8 encoded 10646 [7] characters. - - - -Rigney, et al. Standards Track [Page 36] - -RFC 2865 RADIUS June 2000 - - -5.12. Framed-MTU - - Description - - This Attribute indicates the Maximum Transmission Unit to be - configured for the user, when it is not negotiated by some other - means (such as PPP). It MAY be used in Access-Accept packets. It - MAY be used in an Access-Request packet as a hint by the NAS to - the server that it would prefer that value, but the server is not - required to honor the hint. - - A summary of the Framed-MTU Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 12 for Framed-MTU. - - Length - - 6 - - Value - - The Value field is four octets. Despite the size of the field, - values range from 64 to 65535. - -5.13. Framed-Compression - - Description - - This Attribute indicates a compression protocol to be used for the - link. It MAY be used in Access-Accept packets. It MAY be used in - an Access-Request packet as a hint to the server that the NAS - would prefer to use that compression, but the server is not - required to honor the hint. - - More than one compression protocol Attribute MAY be sent. It is - the responsibility of the NAS to apply the proper compression - protocol to appropriate link traffic. - - - -Rigney, et al. Standards Track [Page 37] - -RFC 2865 RADIUS June 2000 - - - A summary of the Framed-Compression Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 13 for Framed-Compression. - - Length - - 6 - - Value - - The Value field is four octets. - - 0 None - 1 VJ TCP/IP header compression [10] - 2 IPX header compression - 3 Stac-LZS compression - -5.14. Login-IP-Host - - Description - - This Attribute indicates the system with which to connect the user, - when the Login-Service Attribute is included. It MAY be used in - Access-Accept packets. It MAY be used in an Access-Request packet as - a hint to the server that the NAS would prefer to use that host, but - the server is not required to honor the hint. - - A summary of the Login-IP-Host Attribute format is shown below. The - fields are transmitted from left to right. - - - - - - - - - - - -Rigney, et al. Standards Track [Page 38] - -RFC 2865 RADIUS June 2000 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Address - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 14 for Login-IP-Host. - - Length - - 6 - - Address - - The Address field is four octets. The value 0xFFFFFFFF indicates - that the NAS SHOULD allow the user to select an address. The - value 0 indicates that the NAS SHOULD select a host to connect the - user to. Other values indicate the address the NAS SHOULD connect - the user to. - -5.15. Login-Service - - Description - - This Attribute indicates the service to use to connect the user to - the login host. It is only used in Access-Accept packets. - - A summary of the Login-Service Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 15 for Login-Service. - - - - - - -Rigney, et al. Standards Track [Page 39] - -RFC 2865 RADIUS June 2000 - - - Length - - 6 - - Value - - The Value field is four octets. - - 0 Telnet - 1 Rlogin - 2 TCP Clear - 3 PortMaster (proprietary) - 4 LAT - 5 X25-PAD - 6 X25-T3POS - 8 TCP Clear Quiet (suppresses any NAS-generated connect string) - -5.16. Login-TCP-Port - - Description - - This Attribute indicates the TCP port with which the user is to be - connected, when the Login-Service Attribute is also present. It - is only used in Access-Accept packets. - - A summary of the Login-TCP-Port Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 16 for Login-TCP-Port. - - Length - - 6 - - Value - - The Value field is four octets. Despite the size of the field, - values range from 0 to 65535. - - - -Rigney, et al. Standards Track [Page 40] - -RFC 2865 RADIUS June 2000 - - -5.17. (unassigned) - - Description - - ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. - -5.18. Reply-Message - - Description - - This Attribute indicates text which MAY be displayed to the user. - - When used in an Access-Accept, it is the success message. - - When used in an Access-Reject, it is the failure message. It MAY - indicate a dialog message to prompt the user before another - Access-Request attempt. - - When used in an Access-Challenge, it MAY indicate a dialog message - to prompt the user for a response. - - Multiple Reply-Message's MAY be included and if any are displayed, - they MUST be displayed in the same order as they appear in the - packet. - - A summary of the Reply-Message Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | Text ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 18 for Reply-Message. - - Length - - >= 3 - - Text - - The Text field is one or more octets, and its contents are - implementation dependent. It is intended to be human readable, - and MUST NOT affect operation of the protocol. It is recommended - that the message contain UTF-8 encoded 10646 [7] characters. - - - -Rigney, et al. Standards Track [Page 41] - -RFC 2865 RADIUS June 2000 - - -5.19. Callback-Number - - Description - - This Attribute indicates a dialing string to be used for callback. - It MAY be used in Access-Accept packets. It MAY be used in an - Access-Request packet as a hint to the server that a Callback - service is desired, but the server is not required to honor the - hint. - - A summary of the Callback-Number Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 19 for Callback-Number. - - Length - - >= 3 - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.20. Callback-Id - - Description - - This Attribute indicates the name of a place to be called, to be - interpreted by the NAS. It MAY be used in Access-Accept packets. - - - - - - - - - -Rigney, et al. Standards Track [Page 42] - -RFC 2865 RADIUS June 2000 - - - A summary of the Callback-Id Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 20 for Callback-Id. - - Length - - >= 3 - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.21. (unassigned) - - Description - - ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. - -5.22. Framed-Route - - Description - - This Attribute provides routing information to be configured for - the user on the NAS. It is used in the Access-Accept packet and - can appear multiple times. - - A summary of the Framed-Route Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | Text ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -Rigney, et al. Standards Track [Page 43] - -RFC 2865 RADIUS June 2000 - - - Type - - 22 for Framed-Route. - - Length - - >= 3 - - Text - - The Text field is one or more octets, and its contents are - implementation dependent. It is intended to be human readable and - MUST NOT affect operation of the protocol. It is recommended that - the message contain UTF-8 encoded 10646 [7] characters. - - For IP routes, it SHOULD contain a destination prefix in dotted - quad form optionally followed by a slash and a decimal length - specifier stating how many high order bits of the prefix to use. - That is followed by a space, a gateway address in dotted quad - form, a space, and one or more metrics separated by spaces. For - example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length - specifier may be omitted, in which case it defaults to 8 bits for - class A prefixes, 16 bits for class B prefixes, and 24 bits for - class C prefixes. For example, "192.168.1.0 192.168.1.1 1". - - Whenever the gateway address is specified as "0.0.0.0" the IP - address of the user SHOULD be used as the gateway address. - -5.23. Framed-IPX-Network - - Description - - This Attribute indicates the IPX Network number to be configured - for the user. It is used in Access-Accept packets. - - A summary of the Framed-IPX-Network Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - -Rigney, et al. Standards Track [Page 44] - -RFC 2865 RADIUS June 2000 - - - Type - - 23 for Framed-IPX-Network. - - Length - - 6 - - Value - - The Value field is four octets. The value 0xFFFFFFFE indicates - that the NAS should select an IPX network for the user (e.g. - assigned from a pool of one or more IPX networks kept by the NAS). - Other values should be used as the IPX network for the link to the - user. - -5.24. State - - Description - - This Attribute is available to be sent by the server to the client - in an Access-Challenge and MUST be sent unmodified from the client - to the server in the new Access-Request reply to that challenge, - if any. - - This Attribute is available to be sent by the server to the client - in an Access-Accept that also includes a Termination-Action - Attribute with the value of RADIUS-Request. If the NAS performs - the Termination-Action by sending a new Access-Request upon - termination of the current session, it MUST include the State - attribute unchanged in that Access-Request. - - In either usage, the client MUST NOT interpret the attribute - locally. A packet must have only zero or one State Attribute. - Usage of the State Attribute is implementation dependent. - - A summary of the State Attribute format is shown below. The fields - are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 24 for State. - - - -Rigney, et al. Standards Track [Page 45] - -RFC 2865 RADIUS June 2000 - - - Length - - >= 3 - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.25. Class - - Description - - This Attribute is available to be sent by the server to the client - in an Access-Accept and SHOULD be sent unmodified by the client to - the accounting server as part of the Accounting-Request packet if - accounting is supported. The client MUST NOT interpret the - attribute locally. - - A summary of the Class Attribute format is shown below. The fields - are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 25 for Class. - - Length - - >= 3 - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - - - -Rigney, et al. Standards Track [Page 46] - -RFC 2865 RADIUS June 2000 - - -5.26. Vendor-Specific - - Description - - This Attribute is available to allow vendors to support their own - extended Attributes not suitable for general usage. It MUST not - affect the operation of the RADIUS protocol. - - Servers not equipped to interpret the vendor-specific information - sent by a client MUST ignore it (although it may be reported). - Clients which do not receive desired vendor-specific information - SHOULD make an attempt to operate without it, although they may do - so (and report they are doing so) in a degraded mode. - - A summary of the Vendor-Specific Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Vendor-Id - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Vendor-Id (cont) | String... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 26 for Vendor-Specific. - - Length - - >= 7 - - Vendor-Id - - The high-order octet is 0 and the low-order 3 octets are the SMI - Network Management Private Enterprise Code of the Vendor in - network byte order, as defined in the "Assigned Numbers" RFC [6]. - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - - - - -Rigney, et al. Standards Track [Page 47] - -RFC 2865 RADIUS June 2000 - - - It SHOULD be encoded as a sequence of vendor type / vendor length - / value fields, as follows. The Attribute-Specific field is - dependent on the vendor's definition of that attribute. An - example encoding of the Vendor-Specific attribute using this - method follows: - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Vendor-Id - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Vendor-Id (cont) | Vendor type | Vendor length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attribute-Specific... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Multiple subattributes MAY be encoded within a single Vendor- - Specific attribute, although they do not have to be. - -5.27. Session-Timeout - - Description - - This Attribute sets the maximum number of seconds of service to be - provided to the user before termination of the session or prompt. - This Attribute is available to be sent by the server to the client - in an Access-Accept or Access-Challenge. - - A summary of the Session-Timeout Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 27 for Session-Timeout. - - Length - - 6 - - - - - -Rigney, et al. Standards Track [Page 48] - -RFC 2865 RADIUS June 2000 - - - Value - - The field is 4 octets, containing a 32-bit unsigned integer with - the maximum number of seconds this user should be allowed to - remain connected by the NAS. - -5.28. Idle-Timeout - - Description - - This Attribute sets the maximum number of consecutive seconds of - idle connection allowed to the user before termination of the - session or prompt. This Attribute is available to be sent by the - server to the client in an Access-Accept or Access-Challenge. - - A summary of the Idle-Timeout Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 28 for Idle-Timeout. - - Length - - 6 - - Value - - The field is 4 octets, containing a 32-bit unsigned integer with - the maximum number of consecutive seconds of idle time this user - should be permitted before being disconnected by the NAS. - -5.29. Termination-Action - - Description - - This Attribute indicates what action the NAS should take when the - specified service is completed. It is only used in Access-Accept - packets. - - - - -Rigney, et al. Standards Track [Page 49] - -RFC 2865 RADIUS June 2000 - - - A summary of the Termination-Action Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 29 for Termination-Action. - - Length - - 6 - - Value - - The Value field is four octets. - - 0 Default - 1 RADIUS-Request - - If the Value is set to RADIUS-Request, upon termination of the - specified service the NAS MAY send a new Access-Request to the - RADIUS server, including the State attribute if any. - -5.30. Called-Station-Id - - Description - - This Attribute allows the NAS to send in the Access-Request packet - the phone number that the user called, using Dialed Number - Identification (DNIS) or similar technology. Note that this may - be different from the phone number the call comes in on. It is - only used in Access-Request packets. - - A summary of the Called-Station-Id Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -Rigney, et al. Standards Track [Page 50] - -RFC 2865 RADIUS June 2000 - - - Type - - 30 for Called-Station-Id. - - Length - - >= 3 - - String - - The String field is one or more octets, containing the phone - number that the user's call came in on. - - The actual format of the information is site or application - specific. UTF-8 encoded 10646 [7] characters are recommended, but - a robust implementation SHOULD support the field as - undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.31. Calling-Station-Id - - Description - - This Attribute allows the NAS to send in the Access-Request packet - the phone number that the call came from, using Automatic Number - Identification (ANI) or similar technology. It is only used in - Access-Request packets. - - A summary of the Calling-Station-Id Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 31 for Calling-Station-Id. - - Length - - >= 3 - - - - - -Rigney, et al. Standards Track [Page 51] - -RFC 2865 RADIUS June 2000 - - - String - - The String field is one or more octets, containing the phone - number that the user placed the call from. - - The actual format of the information is site or application - specific. UTF-8 encoded 10646 [7] characters are recommended, but - a robust implementation SHOULD support the field as - undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.32. NAS-Identifier - - Description - - This Attribute contains a string identifying the NAS originating - the Access-Request. It is only used in Access-Request packets. - Either NAS-IP-Address or NAS-Identifier MUST be present in an - Access-Request packet. - - Note that NAS-Identifier MUST NOT be used to select the shared - secret used to authenticate the request. The source IP address of - the Access-Request packet MUST be used to select the shared - secret. - - A summary of the NAS-Identifier Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 32 for NAS-Identifier. - - Length - - >= 3 - - - - - - - - -Rigney, et al. Standards Track [Page 52] - -RFC 2865 RADIUS June 2000 - - - String - - The String field is one or more octets, and should be unique to - the NAS within the scope of the RADIUS server. For example, a - fully qualified domain name would be suitable as a NAS-Identifier. - - The actual format of the information is site or application - specific, and a robust implementation SHOULD support the field as - undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.33. Proxy-State - - Description - - This Attribute is available to be sent by a proxy server to - another server when forwarding an Access-Request and MUST be - returned unmodified in the Access-Accept, Access-Reject or - Access-Challenge. When the proxy server receives the response to - its request, it MUST remove its own Proxy-State (the last Proxy- - State in the packet) before forwarding the response to the NAS. - - If a Proxy-State Attribute is added to a packet when forwarding - the packet, the Proxy-State Attribute MUST be added after any - existing Proxy-State attributes. - - The content of any Proxy-State other than the one added by the - current server should be treated as opaque octets and MUST NOT - affect operation of the protocol. - - Usage of the Proxy-State Attribute is implementation dependent. A - description of its function is outside the scope of this - specification. - - A summary of the Proxy-State Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 33 for Proxy-State. - - - -Rigney, et al. Standards Track [Page 53] - -RFC 2865 RADIUS June 2000 - - - Length - - >= 3 - - String - - The String field is one or more octets. The actual format of the - information is site or application specific, and a robust - implementation SHOULD support the field as undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.34. Login-LAT-Service - - Description - - This Attribute indicates the system with which the user is to be - connected by LAT. It MAY be used in Access-Accept packets, but - only when LAT is specified as the Login-Service. It MAY be used - in an Access-Request packet as a hint to the server, but the - server is not required to honor the hint. - - Administrators use the service attribute when dealing with - clustered systems, such as a VAX or Alpha cluster. In such an - environment several different time sharing hosts share the same - resources (disks, printers, etc.), and administrators often - configure each to offer access (service) to each of the shared - resources. In this case, each host in the cluster advertises its - services through LAT broadcasts. - - Sophisticated users often know which service providers (machines) - are faster and tend to use a node name when initiating a LAT - connection. Alternately, some administrators want particular - users to use certain machines as a primitive form of load - balancing (although LAT knows how to do load balancing itself). - - A summary of the Login-LAT-Service Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -Rigney, et al. Standards Track [Page 54] - -RFC 2865 RADIUS June 2000 - - - Type - - 34 for Login-LAT-Service. - - Length - - >= 3 - - String - - The String field is one or more octets, and contains the identity - of the LAT service to use. The LAT Architecture allows this - string to contain $ (dollar), - (hyphen), . (period), _ - (underscore), numerics, upper and lower case alphabetics, and the - ISO Latin-1 character set extension [11]. All LAT string - comparisons are case insensitive. - -5.35. Login-LAT-Node - - Description - - This Attribute indicates the Node with which the user is to be - automatically connected by LAT. It MAY be used in Access-Accept - packets, but only when LAT is specified as the Login-Service. It - MAY be used in an Access-Request packet as a hint to the server, - but the server is not required to honor the hint. - - A summary of the Login-LAT-Node Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 35 for Login-LAT-Node. - - Length - - >= 3 - - - - - - - - -Rigney, et al. Standards Track [Page 55] - -RFC 2865 RADIUS June 2000 - - - String - - The String field is one or more octets, and contains the identity - of the LAT Node to connect the user to. The LAT Architecture - allows this string to contain $ (dollar), - (hyphen), . (period), - _ (underscore), numerics, upper and lower case alphabetics, and - the ISO Latin-1 character set extension. All LAT string - comparisons are case insensitive. - -5.36. Login-LAT-Group - - Description - - This Attribute contains a string identifying the LAT group codes - which this user is authorized to use. It MAY be used in Access- - Accept packets, but only when LAT is specified as the Login- - Service. It MAY be used in an Access-Request packet as a hint to - the server, but the server is not required to honor the hint. - - LAT supports 256 different group codes, which LAT uses as a form - of access rights. LAT encodes the group codes as a 256 bit - bitmap. - - Administrators can assign one or more of the group code bits at - the LAT service provider; it will only accept LAT connections that - have these group codes set in the bit map. The administrators - assign a bitmap of authorized group codes to each user; LAT gets - these from the operating system, and uses these in its requests to - the service providers. - - A summary of the Login-LAT-Group Attribute format is shown below. - The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 36 for Login-LAT-Group. - - Length - - 34 - - - - - -Rigney, et al. Standards Track [Page 56] - -RFC 2865 RADIUS June 2000 - - - String - - The String field is a 32 octet bit map, most significant octet - first. A robust implementation SHOULD support the field as - undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.37. Framed-AppleTalk-Link - - Description - - This Attribute indicates the AppleTalk network number which should - be used for the serial link to the user, which is another - AppleTalk router. It is only used in Access-Accept packets. It - is never used when the user is not another router. - - A summary of the Framed-AppleTalk-Link Attribute format is shown - below. The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 37 for Framed-AppleTalk-Link. - - Length - - 6 - - Value - - The Value field is four octets. Despite the size of the field, - values range from 0 to 65535. The special value of 0 indicates - that this is an unnumbered serial link. A value of 1-65535 means - that the serial line between the NAS and the user should be - assigned that value as an AppleTalk network number. - - - - - - - -Rigney, et al. Standards Track [Page 57] - -RFC 2865 RADIUS June 2000 - - -5.38. Framed-AppleTalk-Network - - Description - - This Attribute indicates the AppleTalk Network number which the - NAS should probe to allocate an AppleTalk node for the user. It - is only used in Access-Accept packets. It is never used when the - user is another router. Multiple instances of this Attribute - indicate that the NAS may probe using any of the network numbers - specified. - - A summary of the Framed-AppleTalk-Network Attribute format is shown - below. The fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 38 for Framed-AppleTalk-Network. - - Length - - 6 - - Value - - The Value field is four octets. Despite the size of the field, - values range from 0 to 65535. The special value 0 indicates that - the NAS should assign a network for the user, using its default - cable range. A value between 1 and 65535 (inclusive) indicates - the AppleTalk Network the NAS should probe to find an address for - the user. - -5.39. Framed-AppleTalk-Zone - - Description - - This Attribute indicates the AppleTalk Default Zone to be used for - this user. It is only used in Access-Accept packets. Multiple - instances of this attribute in the same packet are not allowed. - - - - - -Rigney, et al. Standards Track [Page 58] - -RFC 2865 RADIUS June 2000 - - - A summary of the Framed-AppleTalk-Zone Attribute format is shown - below. The fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 39 for Framed-AppleTalk-Zone. - - Length - - >= 3 - - String - - The name of the Default AppleTalk Zone to be used for this user. - A robust implementation SHOULD support the field as - undistinguished octets. - - The codification of the range of allowed usage of this field is - outside the scope of this specification. - -5.40. CHAP-Challenge - - Description - - This Attribute contains the CHAP Challenge sent by the NAS to a - PPP Challenge-Handshake Authentication Protocol (CHAP) user. It - is only used in Access-Request packets. - - If the CHAP challenge value is 16 octets long it MAY be placed in - the Request Authenticator field instead of using this attribute. - - A summary of the CHAP-Challenge Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -Rigney, et al. Standards Track [Page 59] - -RFC 2865 RADIUS June 2000 - - - Type - - 60 for CHAP-Challenge. - - Length - - >= 7 - - String - - The String field contains the CHAP Challenge. - -5.41. NAS-Port-Type - - Description - - This Attribute indicates the type of the physical port of the NAS - which is authenticating the user. It can be used instead of or in - addition to the NAS-Port (5) attribute. It is only used in - Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or - both SHOULD be present in an Access-Request packet, if the NAS - differentiates among its ports. - - A summary of the NAS-Port-Type Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 61 for NAS-Port-Type. - - Length - - 6 - - Value - - The Value field is four octets. "Virtual" refers to a connection - to the NAS via some transport protocol, instead of through a - physical port. For example, if a user telnetted into a NAS to - - - - -Rigney, et al. Standards Track [Page 60] - -RFC 2865 RADIUS June 2000 - - - authenticate himself as an Outbound-User, the Access-Request might - include NAS-Port-Type = Virtual as a hint to the RADIUS server - that the user was not on a physical port. - - 0 Async - 1 Sync - 2 ISDN Sync - 3 ISDN Async V.120 - 4 ISDN Async V.110 - 5 Virtual - 6 PIAFS - 7 HDLC Clear Channel - 8 X.25 - 9 X.75 - 10 G.3 Fax - 11 SDSL - Symmetric DSL - 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase - Modulation - 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone - 14 IDSL - ISDN Digital Subscriber Line - 15 Ethernet - 16 xDSL - Digital Subscriber Line of unknown type - 17 Cable - 18 Wireless - Other - 19 Wireless - IEEE 802.11 - - PIAFS is a form of wireless ISDN commonly used in Japan, and - stands for PHS (Personal Handyphone System) Internet Access Forum - Standard (PIAFS). - -5.42. Port-Limit - - Description - - This Attribute sets the maximum number of ports to be provided to - the user by the NAS. This Attribute MAY be sent by the server to - the client in an Access-Accept packet. It is intended for use in - conjunction with Multilink PPP [12] or similar uses. It MAY also - be sent by the NAS to the server as a hint that that many ports - are desired for use, but the server is not required to honor the - hint. - - A summary of the Port-Limit Attribute format is shown below. The - fields are transmitted from left to right. - - - - - - - -Rigney, et al. Standards Track [Page 61] - -RFC 2865 RADIUS June 2000 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Value (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type - - 62 for Port-Limit. - - Length - - 6 - - Value - - The field is 4 octets, containing a 32-bit unsigned integer with - the maximum number of ports this user should be allowed to connect - to on the NAS. - -5.43. Login-LAT-Port - - Description - - This Attribute indicates the Port with which the user is to be - connected by LAT. It MAY be used in Access-Accept packets, but - only when LAT is specified as the Login-Service. It MAY be used - in an Access-Request packet as a hint to the server, but the - server is not required to honor the hint. - - A summary of the Login-LAT-Port Attribute format is shown below. The - fields are transmitted from left to right. - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - | Type | Length | String ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Type - - 63 for Login-LAT-Port. - - Length - - >= 3 - - - -Rigney, et al. Standards Track [Page 62] - -RFC 2865 RADIUS June 2000 - - - String - - The String field is one or more octets, and contains the identity - of the LAT port to use. The LAT Architecture allows this string - to contain $ (dollar), - (hyphen), . (period), _ (underscore), - numerics, upper and lower case alphabetics, and the ISO Latin-1 - character set extension. All LAT string comparisons are case - insensitive. - -5.44. Table of Attributes - - The following table provides a guide to which attributes may be found - in which kinds of packets, and in what quantity. - - Request Accept Reject Challenge # Attribute - 0-1 0-1 0 0 1 User-Name - 0-1 0 0 0 2 User-Password [Note 1] - 0-1 0 0 0 3 CHAP-Password [Note 1] - 0-1 0 0 0 4 NAS-IP-Address [Note 2] - 0-1 0 0 0 5 NAS-Port - 0-1 0-1 0 0 6 Service-Type - 0-1 0-1 0 0 7 Framed-Protocol - 0-1 0-1 0 0 8 Framed-IP-Address - 0-1 0-1 0 0 9 Framed-IP-Netmask - 0 0-1 0 0 10 Framed-Routing - 0 0+ 0 0 11 Filter-Id - 0-1 0-1 0 0 12 Framed-MTU - 0+ 0+ 0 0 13 Framed-Compression - 0+ 0+ 0 0 14 Login-IP-Host - 0 0-1 0 0 15 Login-Service - 0 0-1 0 0 16 Login-TCP-Port - 0 0+ 0+ 0+ 18 Reply-Message - 0-1 0-1 0 0 19 Callback-Number - 0 0-1 0 0 20 Callback-Id - 0 0+ 0 0 22 Framed-Route - 0 0-1 0 0 23 Framed-IPX-Network - 0-1 0-1 0 0-1 24 State [Note 1] - 0 0+ 0 0 25 Class - 0+ 0+ 0 0+ 26 Vendor-Specific - 0 0-1 0 0-1 27 Session-Timeout - 0 0-1 0 0-1 28 Idle-Timeout - 0 0-1 0 0 29 Termination-Action - 0-1 0 0 0 30 Called-Station-Id - 0-1 0 0 0 31 Calling-Station-Id - 0-1 0 0 0 32 NAS-Identifier [Note 2] - 0+ 0+ 0+ 0+ 33 Proxy-State - 0-1 0-1 0 0 34 Login-LAT-Service - 0-1 0-1 0 0 35 Login-LAT-Node - - - -Rigney, et al. Standards Track [Page 63] - -RFC 2865 RADIUS June 2000 - - - 0-1 0-1 0 0 36 Login-LAT-Group - 0 0-1 0 0 37 Framed-AppleTalk-Link - 0 0+ 0 0 38 Framed-AppleTalk-Network - 0 0-1 0 0 39 Framed-AppleTalk-Zone - 0-1 0 0 0 60 CHAP-Challenge - 0-1 0 0 0 61 NAS-Port-Type - 0-1 0-1 0 0 62 Port-Limit - 0-1 0-1 0 0 63 Login-LAT-Port - Request Accept Reject Challenge # Attribute - - [Note 1] An Access-Request MUST contain either a User-Password or a - CHAP-Password or State. An Access-Request MUST NOT contain both a - User-Password and a CHAP-Password. If future extensions allow other - kinds of authentication information to be conveyed, the attribute for - that can be used in an Access-Request instead of User-Password or - CHAP-Password. - - [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a - NAS-Identifier (or both). - - The following table defines the meaning of the above table entries. - -0 This attribute MUST NOT be present in packet. -0+ Zero or more instances of this attribute MAY be present in packet. -0-1 Zero or one instance of this attribute MAY be present in packet. -1 Exactly one instance of this attribute MUST be present in packet. - -6. IANA Considerations - - This section provides guidance to the Internet Assigned Numbers - Authority (IANA) regarding registration of values related to the - RADIUS protocol, in accordance with BCP 26 [13]. - - There are three name spaces in RADIUS that require registration: - Packet Type Codes, Attribute Types, and Attribute Values (for certain - Attributes). - - RADIUS is not intended as a general-purpose Network Access Server - (NAS) management protocol, and allocations should not be made for - purposes unrelated to Authentication, Authorization or Accounting. - -6.1. Definition of Terms - - The following terms are used here with the meanings defined in - BCP 26: "name space", "assigned value", "registration". - - - - - - -Rigney, et al. Standards Track [Page 64] - -RFC 2865 RADIUS June 2000 - - - The following policies are used here with the meanings defined in - BCP 26: "Private Use", "First Come First Served", "Expert Review", - "Specification Required", "IETF Consensus", "Standards Action". - -6.2. Recommended Registration Policies - - For registration requests where a Designated Expert should be - consulted, the IESG Area Director for Operations should appoint the - Designated Expert. - - For registration requests requiring Expert Review, the ietf-radius - mailing list should be consulted. - - Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have - been allocated. Because a new Packet Type has considerable impact on - interoperability, a new Packet Type Code requires Standards Action, - and should be allocated starting at 14. - - Attribute Types have a range from 1 to 255, and are the scarcest - resource in RADIUS, thus must be allocated with care. Attributes - 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for - re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated - following Expert Review, with Specification Required. Release of - blocks of Attribute Types (more than 3 at a time for a given purpose) - should require IETF Consensus. It is recommended that attributes 17 - and 21 be used only after all others are exhausted. - - Note that RADIUS defines a mechanism for Vendor-Specific extensions - (Attribute 26) and the use of that should be encouraged instead of - allocation of global attribute types, for functions specific only to - one vendor's implementation of RADIUS, where no interoperability is - deemed useful. - - As stated in the "Attributes" section above: - - "[Attribute Type] Values 192-223 are reserved for experimental - use, values 224-240 are reserved for implementation-specific use, - and values 241-255 are reserved and should not be used." - - Therefore Attribute values 192-240 are considered Private Use, and - values 241-255 require Standards Action. - - Certain attributes (for example, NAS-Port-Type) in RADIUS define a - list of values to correspond with various meanings. There can be 4 - billion (2^32) values for each attribute. Adding additional values to - the list can be done on a First Come, First Served basis by the IANA. - - - - - -Rigney, et al. Standards Track [Page 65] - -RFC 2865 RADIUS June 2000 - - -7. Examples - - A few examples are presented to illustrate the flow of packets and - use of typical attributes. These examples are not intended to be - exhaustive, many others are possible. Hexadecimal dumps of the - example packets are given in network byte order, using the shared - secret "xyzzy5461". - -7.1. User Telnet to Specified Host - - The NAS at 192.168.1.16 sends an Access-Request UDP packet to the - RADIUS Server for a user named nemo logging in on port 3 with - password "arctangent". - - The Request Authenticator is a 16 octet random number generated by - the NAS. - - The User-Password is 16 octets of password padded at end with nulls, - XORed with MD5(shared secret|Request Authenticator). - - 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb - 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d - 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 - 01 10 05 06 00 00 00 03 - - 1 Code = Access-Request (1) - 1 ID = 0 - 2 Length = 56 - 16 Request Authenticator - - Attributes: - 6 User-Name = "nemo" - 18 User-Password - 6 NAS-IP-Address = 192.168.1.16 - 6 NAS-Port = 3 - - The RADIUS server authenticates nemo, and sends an Access-Accept UDP - packet to the NAS telling it to telnet nemo to host 192.168.1.3. - - The Response Authenticator is a 16-octet MD5 checksum of the code - (2), id (0), Length (38), the Request Authenticator from above, the - attributes in this reply, and the shared secret. - - - - - - - - - -Rigney, et al. Standards Track [Page 66] - -RFC 2865 RADIUS June 2000 - - - 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf - 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 - 0e 06 c0 a8 01 03 - - 1 Code = Access-Accept (2) - 1 ID = 0 (same as in Access-Request) - 2 Length = 38 - 16 Response Authenticator - - Attributes: - 6 Service-Type (6) = Login (1) - 6 Login-Service (15) = Telnet (0) - 6 Login-IP-Host (14) = 192.168.1.3 - -7.2. Framed User Authenticating with CHAP - - The NAS at 192.168.1.16 sends an Access-Request UDP packet to the - RADIUS Server for a user named flopsy logging in on port 20 with PPP, - authenticating using CHAP. The NAS sends along the Service-Type and - Framed-Protocol attributes as a hint to the RADIUS server that this - user is looking for PPP, although the NAS is not required to do so. - - The Request Authenticator is a 16 octet random number generated by - the NAS, and is also used as the CHAP Challenge. - - The CHAP-Password consists of a 1 octet CHAP ID, in this case 22, - followed by the 16 octet CHAP response. - - 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e - 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 - 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 - 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 - 02 07 06 00 00 00 01 - - 1 Code = 1 (Access-Request) - 1 ID = 1 - 2 Length = 71 - 16 Request Authenticator - - Attributes: - 8 User-Name (1) = "flopsy" - 19 CHAP-Password (3) - 6 NAS-IP-Address (4) = 192.168.1.16 - 6 NAS-Port (5) = 20 - 6 Service-Type (6) = Framed (2) - 6 Framed-Protocol (7) = PPP (1) - - - - - -Rigney, et al. Standards Track [Page 67] - -RFC 2865 RADIUS June 2000 - - - The RADIUS server authenticates flopsy, and sends an Access-Accept - UDP packet to the NAS telling it to start PPP service and assign an - address for the user out of its dynamic address pool. - - The Response Authenticator is a 16-octet MD5 checksum of the code - (2), id (1), Length (56), the Request Authenticator from above, the - attributes in this reply, and the shared secret. - - 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 - 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01 - 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 - 00 01 0c 06 00 00 05 dc - - 1 Code = Access-Accept (2) - 1 ID = 1 (same as in Access-Request) - 2 Length = 56 - 16 Response Authenticator - - Attributes: - 6 Service-Type (6) = Framed (2) - 6 Framed-Protocol (7) = PPP (1) - 6 Framed-IP-Address (8) = 255.255.255.254 - 6 Framed-Routing (10) = None (0) - 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1) - 6 Framed-MTU (12) = 1500 - -7.3. User with Challenge-Response card - - The NAS at 192.168.1.16 sends an Access-Request UDP packet to the - RADIUS Server for a user named mopsy logging in on port 7. The user - enters the dummy password "challenge" in this example. The challenge - and response generated by the smart card for this example are - "32769430" and "99101462". - - The Request Authenticator is a 16 octet random number generated by - the NAS. - - The User-Password is 16 octets of password, in this case "challenge", - padded at the end with nulls, XORed with MD5(shared secret|Request - Authenticator). - - 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 - 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 - 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 - a8 01 10 05 06 00 00 00 07 - - - - - - -Rigney, et al. Standards Track [Page 68] - -RFC 2865 RADIUS June 2000 - - - 1 Code = Access-Request (1) - 1 ID = 2 - 2 Length = 57 - 16 Request Authenticator - - Attributes: - 7 User-Name (1) = "mopsy" - 18 User-Password (2) - 6 NAS-IP-Address (4) = 192.168.1.16 - 6 NAS-Port (5) = 7 - - The RADIUS server decides to challenge mopsy, sending back a - challenge string and looking for a response. The RADIUS server - therefore and sends an Access-Challenge UDP packet to the NAS. - - The Response Authenticator is a 16-octet MD5 checksum of the code - (11), id (2), length (78), the Request Authenticator from above, the - attributes in this reply, and the shared secret. - - The Reply-Message is "Challenge 32769430. Enter response at prompt." - - The State is a magic cookie to be returned along with user's - response; in this example 8 octets of data (33 32 37 36 39 34 33 30 - in hex). - - 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c - 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 - 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 - 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f - 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30 - - 1 Code = Access-Challenge (11) - 1 ID = 2 (same as in Access-Request) - 2 Length = 78 - 16 Response Authenticator - - Attributes: - 48 Reply-Message (18) - 10 State (24) - - The user enters his response, and the NAS send a new Access-Request - with that response, and includes the State Attribute. - - The Request Authenticator is a new 16 octet random number. - - The User-Password is 16 octets of the user's response, in this case - "99101462", padded at the end with nulls, XORed with MD5(shared - secret|Request Authenticator). - - - -Rigney, et al. Standards Track [Page 69] - -RFC 2865 RADIUS June 2000 - - - The state is the magic cookie from the Access-Challenge packet, - unchanged. - - 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 - c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f - 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 - a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 - 34 33 30 - - 1 Code = Access-Request (1) - 1 ID = 3 (Note that this changes.) - 2 Length = 67 - 16 Request Authenticator - - Attributes: - 7 User-Name = "mopsy" - 18 User-Password - 6 NAS-IP-Address (4) = 192.168.1.16 - 6 NAS-Port (5) = 7 - 10 State (24) - - The Response was incorrect (for the sake of example), so the RADIUS - server tells the NAS to reject the login attempt. - - The Response Authenticator is a 16 octet MD5 checksum of the code - (3), id (3), length(20), the Request Authenticator from above, the - attributes in this reply (in this case, none), and the shared secret. - - 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f - 9e 74 6a a0 - - 1 Code = Access-Reject (3) - 1 ID = 3 (same as in Access-Request) - 2 Length = 20 - 16 Response Authenticator - - Attributes: - (none, although a Reply-Message could be sent) - - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 70] - -RFC 2865 RADIUS June 2000 - - -8. Security Considerations - - Security issues are the primary topic of this document. - - In practice, within or associated with each RADIUS server, there is a - database which associates "user" names with authentication - information ("secrets"). It is not anticipated that a particular - named user would be authenticated by multiple methods. This would - make the user vulnerable to attacks which negotiate the least secure - method from among a set. Instead, for each named user there should - be an indication of exactly one method used to authenticate that user - name. If a user needs to make use of different authentication - methods under different circumstances, then distinct user names - SHOULD be employed, each of which identifies exactly one - authentication method. - - Passwords and other secrets should be stored at the respective ends - such that access to them is as limited as possible. Ideally, the - secrets should only be accessible to the process requiring access in - order to perform the authentication. - - The secrets should be distributed with a mechanism that limits the - number of entities that handle (and thus gain knowledge of) the - secret. Ideally, no unauthorized person should ever gain knowledge - of the secrets. It is possible to achieve this with SNMP Security - Protocols [14], but such a mechanism is outside the scope of this - specification. - - Other distribution methods are currently undergoing research and - experimentation. The SNMP Security document [14] also has an - excellent overview of threats to network protocols. - - The User-Password hiding mechanism described in Section 5.2 has not - been subjected to significant amounts of cryptanalysis in the - published literature. Some in the IETF community are concerned that - this method might not provide sufficient confidentiality protection - [15] to passwords transmitted using RADIUS. Users should evaluate - their threat environment and consider whether additional security - mechanisms should be employed. - -9. Change Log - - The following changes have been made from RFC 2138: - - Strings should use UTF-8 instead of US-ASCII and should be handled as - 8-bit data. - - Integers and dates are now defined as 32 bit unsigned values. - - - -Rigney, et al. Standards Track [Page 71] - -RFC 2865 RADIUS June 2000 - - - Updated list of attributes that can be included in Access-Challenge - to be consistent with the table of attributes. - - User-Name mentions Network Access Identifiers. - - User-Name may now be sent in Access-Accept for use with accounting - and Rlogin. - - Values added for Service-Type, Login-Service, Framed-Protocol, - Framed-Compression, and NAS-Port-Type. - - NAS-Port can now use all 32 bits. - - Examples now include hexadecimal displays of the packets. - - Source UDP port must be used in conjunction with the Request - Identifier when identifying duplicates. - - Multiple subattributes may be allowed in a Vendor-Specific attribute. - - An Access-Request is now required to contain either a NAS-IP-Address - or NAS-Identifier (or may contain both). - - Added notes under "Operations" with more information on proxy, - retransmissions, and keep-alives. - - If multiple Attributes with the same Type are present, the order of - Attributes with the same Type MUST be preserved by any proxies. - - Clarified Proxy-State. - - Clarified that Attributes must not depend on position within the - packet, as long as Attributes of the same type are kept in order. - - Added IANA Considerations section. - - Updated section on "Proxy" under "Operations". - - Framed-MTU can now be sent in Access-Request as a hint. - - Updated Security Considerations. - - Text strings identified as a subset of string, to clarify use of - UTF-8. - - - - - - - -Rigney, et al. Standards Track [Page 72] - -RFC 2865 RADIUS June 2000 - - -10. References - - [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2138, April - 1997. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March, 1997. - - [3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", - RFC 1321, April 1992. - - [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August - 1980. - - [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. - - [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC - 1700, October 1994. - - [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. - - [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC - 2486, January 1999. - - [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: - Private Communications in a Public World", Prentice Hall, March - 1995, ISBN 0-13-061466-1. - - [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial - links", RFC 1144, February 1990. - - [11] ISO 8859. International Standard -- Information Processing -- - 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin - Alphabet No. 1, ISO 8859-1:1987. - - [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. - Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August - 1996. - - [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - - [14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security - Protocols", RFC 1352, July 1992. - - - - -Rigney, et al. Standards Track [Page 73] - -RFC 2865 RADIUS June 2000 - - - [15] Dobbertin, H., "The Status of MD5 After a Recent Attack", - CryptoBytes Vol.2 No.2, Summer 1996. - -11. Acknowledgements - - RADIUS was originally developed by Steve Willens of Livingston - Enterprises for their PortMaster series of Network Access Servers. - -12. Chair's Address - - The working group can be contacted via the current chair: - - Carl Rigney - Livingston Enterprises - 4464 Willow Road - Pleasanton, California 94588 - - Phone: +1 925 737 2100 - EMail: cdr@telemancy.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 74] - -RFC 2865 RADIUS June 2000 - - -13. Authors' Addresses - - Questions about this memo can also be directed to: - - Carl Rigney - Livingston Enterprises - 4464 Willow Road - Pleasanton, California 94588 - - Phone: +1 925 737 2100 - EMail: cdr@telemancy.com - - - Allan C. Rubens - Merit Network, Inc. - 4251 Plymouth Road - Ann Arbor, Michigan 48105-2785 - - EMail: acr@merit.edu - - - William Allen Simpson - Daydreamer - Computer Systems Consulting Services - 1384 Fontaine - Madison Heights, Michigan 48071 - - EMail: wsimpson@greendragon.com - - - Steve Willens - Livingston Enterprises - 4464 Willow Road - Pleasanton, California 94588 - - EMail: steve@livingston.com - - - - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 75] - -RFC 2865 RADIUS June 2000 - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Rigney, et al. Standards Track [Page 76] - |