+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Rigney
-Request for Comments: 2058 Livingston
-Category: Standards Track A. Rubens
- Merit
- W. Simpson
- Daydreamer
- S. Willens
- Livingston
- January 1997
-
-
- Remote Authentication Dial In User Service (RADIUS)
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes a protocol for carrying authentication,
- authorization, and configuration information between a Network Access
- Server which desires to authenticate its links and a shared
- Authentication Server.
-
-Table of Contents
-
- 1. Introduction .......................................... 3
- 1.1 Specification of Requirements ................... 4
- 1.2 Terminology ..................................... 4
- 2. Operation ............................................. 5
- 2.1 Challenge/Response .............................. 6
- 2.2 Interoperation with PAP and CHAP ................ 7
- 2.3 Why UDP? ........................................ 8
- 3. Packet Format ......................................... 9
- 4. Packet Types .......................................... 12
- 4.1 Access-Request .................................. 12
- 4.2 Access-Accept ................................... 14
- 4.3 Access-Reject ................................... 15
- 4.4 Access-Challenge ................................ 16
- 5. Attributes ............................................ 17
- 5.1 User-Name ....................................... 20
- 5.2 User-Password ................................... 21
- 5.3 CHAP-Password ................................... 22
- 5.4 NAS-IP-Address .................................. 23
-
-
-
-Rigney, et. al. Informational [Page 1]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 5.5 NAS-Port ........................................ 24
- 5.6 Service-Type .................................... 25
- 5.7 Framed-Protocol ................................. 27
- 5.8 Framed-IP-Address ............................... 28
- 5.9 Framed-IP-Netmask ............................... 29
- 5.10 Framed-Routing .................................. 29
- 5.11 Filter-Id ....................................... 30
- 5.12 Framed-MTU ...................................... 31
- 5.13 Framed-Compression .............................. 32
- 5.14 Login-IP-Host ................................... 33
- 5.15 Login-Service ................................... 33
- 5.16 Login-TCP-Port .................................. 34
- 5.17 (unassigned) .................................... 35
- 5.18 Reply-Message ................................... 35
- 5.19 Callback-Number ................................. 36
- 5.20 Callback-Id ..................................... 37
- 5.21 (unassigned) .................................... 37
- 5.22 Framed-Route .................................... 38
- 5.23 Framed-IPX-Network .............................. 39
- 5.24 State ........................................... 39
- 5.25 Class ........................................... 40
- 5.26 Vendor-Specific ................................. 41
- 5.27 Session-Timeout ................................. 43
- 5.28 Idle-Timeout .................................... 44
- 5.29 Termination-Action .............................. 44
- 5.30 Called-Station-Id ............................... 45
- 5.31 Calling-Station-Id .............................. 46
- 5.32 NAS-Identifier .................................. 47
- 5.33 Proxy-State ..................................... 48
- 5.34 Login-LAT-Service ............................... 49
- 5.35 Login-LAT-Node .................................. 50
- 5.36 Login-LAT-Group ................................. 51
- 5.37 Framed-AppleTalk-Link ........................... 52
- 5.38 Framed-AppleTalk-Network ........................ 53
- 5.39 Framed-AppleTalk-Zone ........................... 53
- 5.40 CHAP-Challenge .................................. 54
- 5.41 NAS-Port-Type ................................... 55
- 5.42 Port-Limit ...................................... 56
- 5.43 Login-LAT-Port .................................. 57
- 5.44 Table of Attributes ............................. 58
- 6. Examples .............................................. 59
- 6.1 User Telnet to Specified Host ................... 59
- 6.2 Framed User Authenticating with CHAP ............ 60
- 6.3 User with Challenge-Response card ............... 61
- SECURITY CONSIDERATIONS ...................................... 62
- REFERENCES ................................................... 63
- ACKNOWLEDGEMENTS ............................................. 63
- CHAIR'S ADDRESS .............................................. 64
-
-
-
-Rigney, et. al. Informational [Page 2]
-\f
-RFC 2058 RADIUS January 1997
-
-
- AUTHORS' ADDRESSES ........................................... 64
-
-1. Introduction
-
- Managing dispersed serial line and modem pools for large numbers of
- users can create the need for significant administrative support.
- Since modem pools are by definition a link to the outside world, they
- require careful attention to security, authorization and accounting.
- This can be best achieved by managing a single "database" of users,
- which allows for authentication (verifying user name and password) as
- well as configuration information detailing the type of service to
- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
-
- Key features of RADIUS are:
-
- Client/Server Model
-
- A Network Access Server (NAS) operates as a client of RADIUS. The
- client is responsible for passing user information to designated
- RADIUS servers, and then acting on the response which is returned.
-
- RADIUS servers are responsible for receiving user connection
- requests, authenticating the user, and then returning all
- configuration information necessary for the client to deliver
- service to the user.
-
- A RADIUS server can act as a proxy client to other RADIUS servers
- or other kinds of authentication servers.
-
- Network Security
-
- Transactions between the client and RADIUS server are
- authenticated through the use of a shared secret, which is never
- sent over the network. In addition, any user passwords are sent
- encrypted between the client and RADIUS server, to eliminate the
- possibility that someone snooping on an unsecure network could
- determine a user's password.
-
- 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.
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 3]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Extensible Protocol
-
- All transactions are comprised of variable length Attribute-
- Length-Value 3-tuples. New attribute values can be added without
- disturbing existing implementations of the protocol.
-
-1.1. Specification of Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. These words are often capitalized.
-
- MUST This word, or the adjective "required", means that the
- definition is an absolute requirement of the specification.
-
- MUST NOT This phrase means that the definition is an absolute
- prohibition of the specification.
-
- SHOULD This word, or the adjective "recommended", means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications must be
- understood and carefully weighed before choosing a
- different course.
-
- MAY This word, or the adjective "optional", means that this
- item is one of an allowed set of alternatives. An
- implementation which does not include this option MUST be
- prepared to interoperate with another implementation which
- does include the option.
-
-1.2. Terminology
-
- This document 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
-
-
-
-Rigney, et. al. Informational [Page 4]
-\f
-RFC 2058 RADIUS January 1997
-
-
- in a statistics counter.
-
-2. Operation
-
- When a client is configured to use RADIUS, any user of the client
- presents authentication information to the client. This might be
- with a customizable login prompt, where the user is expected to enter
- their username and password. Alternatively, the user might use a
- link framing protocol such as the Point-to-Point Protocol (PPP),
- which has authentication packets which carry this information.
-
- Once the client has obtained such information, it may choose to
- authenticate using RADIUS. To do so, the client creates an "Access-
- Request" containing such Attributes as the user's name, the user's
- password, the ID of the client and the Port ID which the user is
- accessing. When a password is present, it is hidden using a method
- based on the RSA Message Digest Algorithm MD5 [1].
-
- The Access-Request is submitted to the RADIUS server via the network.
- If no response is returned within a length of time, the request is
- re-sent a number of times. The client can also forward requests to
- an alternate server or servers in the event that the primary server
- is down or unreachable. An alternate server can be used either after
- a number of tries to the primary server fail, or in a round-robin
- fashion. Retry and fallback algorithms are the topic of current
- research and are not specified in detail in this document.
-
- Once the RADIUS server receives the request, it validates the sending
- client. A request from a client for which the RADIUS server does not
- have a shared secret should be silently discarded. If the client is
- valid, the RADIUS server consults a database of users to find the
- user whose name matches the request. The user entry in the database
- contains a list of requirements which must be met to allow access for
- the user. This always includes verification of the password, but can
- also specify the client(s) or port(s) to which the user is allowed
- access.
-
- The RADIUS server MAY make requests of other servers in order to
- satisfy the request, in which case it acts as a client.
-
- If any condition is not met, the RADIUS server sends an "Access-
- Reject" response indicating that this user request is invalid. If
- desired, the server MAY include a text message in the Access-Reject
- which MAY be displayed by the client to the user. No other
- Attributes are permitted in an Access-Reject.
-
- If all conditions are met and the RADIUS server wishes to issue a
- challenge to which the user must respond, the RADIUS server sends an
-
-
-
-Rigney, et. al. Informational [Page 5]
-\f
-RFC 2058 RADIUS January 1997
-
-
- "Access-Challenge" response. It MAY include a text message to be
- displayed by the client to the user prompting for a response to the
- challenge, and MAY include a State attribute. If the client receives
- an Access-Challenge and supports challenge/response it MAY display
- the text message, if any, to the user, and then prompt the user for a
- response. The client then re-submits its original Access-Request
- with a new request ID, with the User-Password Attribute replaced by
- the response (encrypted), and including the State Attribute from the
- Access-Challenge, if any. Only 0 or 1 instances of the State
- Attributes should be present in a request. The server can respond to
- this new Access-Request with either an Access-Accept, an Access-
- Reject, or another Access-Challenge.
-
- If all conditions are met, the list of configuration values for the
- user are placed into an "Access-Accept" response. These values
- include the type of service (for example: SLIP, PPP, Login User) and
- all necessary values to deliver the desired service. For SLIP and
- PPP, this may include values such as IP address, subnet mask, MTU,
- desired compression, and desired packet filter identifiers. For
- character mode users, this may include values such as desired
- protocol and host.
-
-2.1. Challenge/Response
-
- In challenge/response authentication, the user is given an
- unpredictable number and challenged to encrypt it and give back the
- result. Authorized users are equipped with special devices such as
- smart cards or software that facilitate calculation of the correct
- response with ease. Unauthorized users, lacking the appropriate
- device or software and lacking knowledge of the secret key necessary
- to emulate such a device or software, can only guess at the response.
-
- The Access-Challenge packet typically contains a Reply-Message
- including a challenge to be displayed to the user, such as a numeric
- value unlikely ever to be repeated. Typically this is obtained from
- an external server that knows what type of authenticator should be in
- the possession of the authorized user and can therefore choose a
- random or non-repeating pseudorandom number of an appropriate radix
- and length.
-
- The user then enters the challenge into his device (or software) and
- it calculates a response, which the user enters into the client which
- forwards it to the RADIUS server via a second Access-Request. If the
- response matches the expected response the RADIUS server replies with
- an Access-Accept, otherwise an Access-Reject.
-
- Example: The NAS sends an Access-Request packet to the RADIUS Server
- with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
-
-
-
-Rigney, et. al. Informational [Page 6]
-\f
-RFC 2058 RADIUS January 1997
-
-
- just be a fixed string like "challenge" or ignored). The server
- sends back an Access-Challenge packet with State and a Reply-Message
- along the lines of "Challenge 12345678, enter your response at the
- prompt" which the NAS displays. The NAS prompts for the response and
- sends a NEW Access-Request to the server (with a new ID) with NAS-
- Identifier, NAS-Port, User-Name, User-Password (the response just
- entered by the user, encrypted), and the same State Attribute that
- came with the Access-Challenge. The server then sends back either an
- Access-Accept or Access-Reject based on whether the response matches
- what it should be, or it can even send another Access-Challenge.
-
-2.2. Interoperation with PAP and CHAP
-
- For PAP, the NAS takes the PAP ID and password and sends them in an
- Access-Request packet as the User-Name and User-Password. The NAS MAY
- include the Attributes Service-Type = Framed-User and Framed-Protocol
- = PPP as a hint to the RADIUS server that PPP service is expected.
-
- For CHAP, the NAS generates a random challenge (preferably 16 octets)
- and sends it to the user, who returns a CHAP response along with a
- CHAP ID and CHAP username. The NAS then sends an Access-Request
- packet to the RADIUS server with the CHAP username as the User-Name
- and with the CHAP ID and CHAP response as the CHAP-Password
- (Attribute 3). The random challenge can either be included in the
- CHAP-Challenge attribute or, if it is 16 octets long, it can be
- placed in the Request Authenticator field of the Access-Request
- packet. The NAS MAY include the Attributes Service-Type = Framed-
- User and Framed-Protocol = PPP as a hint to the RADIUS server that
- PPP service is expected.
-
- The RADIUS server looks up a password based on the User-Name,
- encrypts the challenge using MD5 on the CHAP ID octet, that password,
- and the CHAP challenge (from the CHAP-Challenge attribute if present,
- otherwise from the Request Authenticator), and compares that result
- to the CHAP-Password. If they match, the server sends back an
- Access-Accept, otherwise it sends back an Access-Reject.
-
- If the RADIUS server is unable to perform the requested
- authentication it should return an Access-Reject. For example, CHAP
- requires that the user's password be available in cleartext to the
- server so that it can encrypt the CHAP challenge and compare that to
- the CHAP response. If the password is not available in cleartext to
- the RADIUS server then the server MUST send an Access-Reject to the
- client.
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 7]
-\f
-RFC 2058 RADIUS January 1997
-
-
-2.3. Why UDP?
-
- A frequently asked question is why RADIUS uses UDP instead of TCP as
- a transport protocol. UDP was chosen for strictly technical reasons.
-
- There are a number of issues which must be understood. RADIUS is a
- transaction based protocol which has several interesting
- characteristics:
-
- 1. If the request to a primary Authentication server fails, a
- secondary server must be queried.
-
- To meet this requirement, a copy of the request must be kept
- above the transport layer to allow for alternate transmission.
- This means that retransmission timers are still required.
-
- 2. The timing requirements of this particular protocol are
- significantly different than TCP provides.
-
- At one extreme, RADIUS does not require a "responsive" detection
- of lost data. The user is willing to wait several seconds for
- the authentication to complete. The generally aggressive TCP
- retransmission (based on average round trip time) is not
- required, nor is the acknowledgement overhead of TCP.
-
- At the other extreme, the user is not willing to wait several
- minutes for authentication. Therefore the reliable delivery of
- TCP data two minutes later is not useful. The faster use of an
- alternate server allows the user to gain access before giving
- up.
-
- 3. The stateless nature of this protocol simplifies the use of UDP.
-
- Clients and servers come and go. Systems are rebooted, or are
- power cycled independently. Generally this does not cause a
- problem and with creative timeouts and detection of lost TCP
- connections, code can be written to handle anomalous events.
- UDP however completely eliminates any of this special handling.
- Each client and server can open their UDP transport just once
- and leave it open through all types of failure events on the
- network.
-
- 4. UDP simplifies the server implementation.
-
- In the earliest implementations of RADIUS, the server was single
- threaded. This means that a single request was received,
- processed, and returned. This was found to be unmanageable in
- environments where the back-end security mechanism took real
-
-
-
-Rigney, et. al. Informational [Page 8]
-\f
-RFC 2058 RADIUS January 1997
-
-
- time (1 or more seconds). The server request queue would fill
- and in environments where hundreds of people were being
- authenticated every minute, the request turn-around time
- increased to longer that users were willing to wait (this was
- especially severe when a specific lookup in a database or over
- DNS took 30 or more seconds). The obvious solution was to make
- the server multi-threaded. Achieving this was simple with UDP.
- Separate processes were spawned to serve each request and these
- processes could respond directly to the client NAS with a simple
- UDP packet to the original transport of the client.
-
- It's not all a panacea. As noted, using UDP requires one thing which
- is built into TCP: with UDP we must artificially manage
- retransmission timers to the same server, although they don't require
- the same attention to timing provided by TCP. This one penalty is a
- small price to pay for the advantages of UDP in this protocol.
-
- Without TCP we would still probably be using tin cans connected by
- string. But for this particular protocol, UDP is a better choice.
-
-3. Packet Format
-
- Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
- where the UDP Destination Port field indicates 1812 (decimal).
-
- When a reply is generated, the source and destination ports are
- reversed.
-
- 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 ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 9]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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 will be covered in the RADIUS Accounting document [9],
- and are not further mentioned here. Codes 12 and 13 are reserved for
- possible use, but are not further mentioned here.
-
-Identifier
-
- The Identifier field is one octet, and aids in matching requests and
- replies.
-
-Length
-
- The Length field is two octets. It indicates the length of the
- packet including the Code, Identifier, Length, Authenticator and
- Attribute fields. Octets outside the range of the Length field
- should be treated as padding and should be ignored on reception. If
- the packet is shorter than the Length field indicates, it should be
- silently discarded. The minimum length is 20 and maximum length is
- 4096.
-
-Authenticator
-
- The Authenticator field is sixteen (16) octets. The most significant
- octet is transmitted first. This value is used to authenticate the
- reply from the RADIUS server, and is used in the password hiding
- algorithm.
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 10]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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 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
-
-
-
-Rigney, et. al. Informational [Page 11]
-\f
-RFC 2058 RADIUS January 1997
-
-
- provide protection against exhaustive search attacks. A RADIUS
- server SHOULD use the source IP address of the RADIUS UDP packet to
- decide which shared secret to use, so that RADIUS requests can be
- proxied.
-
- When using a forwarding proxy, the proxy must be able to alter the
- packet as it passes through in each direction - when the proxy
- forwards the request, the proxy can add a Proxy-State Attribute, and
- when the proxy forwards a response, it removes the Proxy-State
- Attribute. Since Access-Accept and Access-Reject replies are
- authenticated on the entire packet contents, the stripping of the
- Proxy-State attribute would invalidate the signature in the packet -
- so the proxy has to re-sign it.
-
- Further details of RADIUS proxy implementation are outside the scope
- of this document.
-
-Attributes
-
- Many Attributes may have multiple instances, in such a case the order
- of Attributes of the same Type SHOULD be preserved. The order of
- Attributes of different Types is not required to be preserved.
-
- In the section below on "Attributes" where the text refers to which
- packets an attribute is allowed in, only packets with Codes 1, 2, 3
- and 11 and attributes defined in this document are covered in this
- document. A summary table is provided at the end of the "Attributes"
- section. To determine which Attributes are allowed in packets with
- codes 4 and 5 refer to the RADIUS Accounting document [9].
-
-4. Packet Types
-
- The RADIUS Packet type is determined by the Code field in the first
- octet of the Packet.
-
-4.1. Access-Request
-
- Description
-
- Access-Request packets are sent to a RADIUS server, and convey
- information used to determine whether a user is allowed access to a
- specific NAS, and any special services requested for that user. An
- implementation wishing to authenticate a user MUST transmit a
- RADIUS packet with the Code field set to 1 (Access-Request).
-
- Upon receipt of an Access-Request from a valid client, an
- appropriate reply MUST be transmitted.
-
-
-
-
-Rigney, et. al. Informational [Page 12]
-\f
-RFC 2058 RADIUS January 1997
-
-
- An Access-Request MUST contain a User-Name attribute. It SHOULD
- contain either a NAS-IP-Address attribute or NAS-Identifier
- attribute (or both, although that is not recommended). It MUST
- contain either a User-Password attribute or CHAP-Password
- attribute. It SHOULD contain a NAS-Port or NAS-Port-Type attribute
- or both unless the type of access being requested does not involve
- a port or the NAS does not distinguish among its ports.
-
- An Access-Request MAY contain additional attributes as a hint to
- the server, but the server is not required to honor the hint.
-
- When a User-Password is present, it is hidden using a method based
- on the RSA Message Digest Algorithm MD5 [1].
-
- A summary of the Access-Request packet format is shown below. The
- fields are transmitted from left to right.
-
- 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.
-
-
-
-
-
-Rigney, et. al. Informational [Page 13]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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). On
- reception of an Access-Accept, the Identifier field is matched with
- a pending Access-Request. Additionally, the Response Authenticator
- field MUST contain the correct response for the pending Access-
- Request. Invalid packets are silently discarded.
-
- A summary of the Access-Accept packet format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Code
-
- 2 for Access-Accept.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Accept.
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 14]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
-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.
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 15]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
-4.4. Access-Challenge
-
- Description
-
- If the RADIUS server desires to send the user a challenge requiring
- a response, then the RADIUS server MUST respond to the Access-
- Request by transmitting a packet with the Code field set to 11
- (Access-Challenge).
-
- The Attributes field MAY have one or more Reply-Message Attributes,
- and MAY have a single State Attribute, or none. No other
- Attributes are permitted in an Access-Challenge.
-
- On receipt of an Access-Challenge, the Identifier field is matched
- with a pending Access-Request. Additionally, the Response
- Authenticator field MUST contain the correct response for the
- pending Access-Request. Invalid packets are silently discarded.
-
- If the NAS does not support challenge/response, it MUST treat an
- Access-Challenge as though it had received an Access-Reject
- instead.
-
- If the NAS supports challenge/response, receipt of a valid Access-
- Challenge indicates that a new Access-Request SHOULD be sent. The
- NAS MAY display the text message, if any, to the user, and then
- prompt the user for a response. It then sends its original
- Access-Request with a new request ID and Request Authenticator,
- with the User-Password Attribute replaced by the user's response
- (encrypted), and including the State Attribute from the Access-
- Challenge, if any. Only 0 or 1 instances of the State Attribute
- can be present in an Access-Request.
-
- A NAS which supports PAP MAY forward the Reply-Message to the
- dialin client and accept a PAP response which it can use as though
- the user had entered the response. If the NAS cannot do so, it
- should treat the Access-Challenge as though it had received an
- Access-Reject instead.
-
-
-
-
-Rigney, et. al. Informational [Page 16]
-\f
-RFC 2058 RADIUS January 1997
-
-
- A summary of the Access-Challenge packet format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 11 for Access-Challenge.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Challenge.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- zero or more Attributes.
-
-5. Attributes
-
- RADIUS Attributes carry the specific authentication, authorization,
- information and configuration details for the request and reply.
-
- Some Attributes MAY be included more than once. The effect of this
- is Attribute specific, and is specified in each Attribute
- description.
-
- The end of the list of Attributes is indicated by the Length of the
- RADIUS packet.
-
-
-
-
-
-Rigney, et. al. Informational [Page 17]
-\f
-RFC 2058 RADIUS January 1997
-
-
- A summary of the Attribute format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- The Type field is one octet. Up-to-date values of the RADIUS Type
- field are specified in the most recent "Assigned Numbers" RFC [3].
- Values 192-223 are reserved for experimental use, values 224-240
- are reserved for implementation-specific use, and values 241-255
- are reserved and should not be used. This specification concerns
- the following values:
-
- A RADIUS server MAY ignore Attributes with an unknown Type.
-
- A RADIUS client MAY ignore Attributes with an unknown Type.
-
- 1 User-Name
- 2 User-Password
- 3 CHAP-Password
- 4 NAS-IP-Address
- 5 NAS-Port
- 6 Service-Type
- 7 Framed-Protocol
- 8 Framed-IP-Address
- 9 Framed-IP-Netmask
- 10 Framed-Routing
- 11 Filter-Id
- 12 Framed-MTU
- 13 Framed-Compression
- 14 Login-IP-Host
- 15 Login-Service
- 16 Login-TCP-Port
- 17 (unassigned)
- 18 Reply-Message
- 19 Callback-Number
- 20 Callback-Id
- 21 (unassigned)
- 22 Framed-Route
- 23 Framed-IPX-Network
- 24 State
- 25 Class
- 26 Vendor-Specific
-
-
-
-Rigney, et. al. Informational [Page 18]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 27 Session-Timeout
- 28 Idle-Timeout
- 29 Termination-Action
- 30 Called-Station-Id
- 31 Calling-Station-Id
- 32 NAS-Identifier
- 33 Proxy-State
- 34 Login-LAT-Service
- 35 Login-LAT-Node
- 36 Login-LAT-Group
- 37 Framed-AppleTalk-Link
- 38 Framed-AppleTalk-Network
- 39 Framed-AppleTalk-Zone
- 40-59 (reserved for accounting)
- 60 CHAP-Challenge
- 61 NAS-Port-Type
- 62 Port-Limit
- 63 Login-LAT-Port
-
- Length
-
- The Length field is one octet, and indicates the length of this
- Attribute including the Type, Length and Value fields. If an
- Attribute is received in an Access-Request but with an invalid
- Length, an Access-Reject SHOULD be transmitted. If an Attribute is
- received in an Access-Accept, Access-Reject or Access-Challenge
- packet with an invalid length, the packet MUST either be treated 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 a "string" in RADIUS does not require termination by an
- ASCII NUL because the Attribute already has a length field.
-
- The format of the value field is one of four data types.
-
- string 0-253 octets
-
- address 32 bit value, most significant octet first.
-
- integer 32 bit value, most significant octet first.
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 19]
-\f
-RFC 2058 RADIUS January 1997
-
-
- time 32 bit value, most significant octet first -- seconds
- since 00:00:00 GMT, January 1, 1970. The standard
- Attributes do not use this data type but it is presented
- here for possible use within Vendor-Specific attributes.
-
-5.1. User-Name
-
- Description
-
- This Attribute indicates the name of the user to be authenticated.
- It is only used in Access-Request packets.
-
- A summary of the User-Name Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 1 for User-Name.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The NAS may limit the
- maximum length of the User-Name but the ability to handle at least
- 63 octets is recommended.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 20]
-\f
-RFC 2058 RADIUS January 1997
-
-
- The format of the username MAY be one of several forms:
-
- monolithic Consisting only of alphanumeric characters. This
- simple form might be used to locally manage a NAS.
-
- simple Consisting only of printable ASCII characters.
-
- name@fqdn SMTP address. The Fully Qualified Domain Name (with or
- without trailing dot) indicates the realm in which the
- name part applies.
-
- distinguished name
- A name in ASN.1 form used in Public Key authentication
- systems.
-
-5.2. User-Password
-
- Description
-
- This Attribute indicates the password of the user to be
- authenticated, or the user's input following an Access-Challenge.
- It is only used in Access-Request packets.
-
- On transmission, the password is hidden. The password is first
- padded at the end with nulls to a multiple of 16 octets. A one-way
- MD5 hash is calculated over a stream of octets consisting of the
- shared secret followed by the Request Authenticator. This value is
- XORed with the first 16 octet segment of the password and placed in
- the first 16 octets of the String field of the User-Password
- Attribute.
-
- If the password is longer than 16 characters, a second one-way MD5
- hash is calculated over a stream of octets consisting of the shared
- secret followed by the result of the first xor. That hash is XORed
- with the second 16 octet segment of the password and placed in the
- second 16 octets of the String field of the User-Password
- Attribute.
-
- If necessary, this operation is repeated, with each xor result
- being used along with the shared secret to generate the next hash
- to xor the next segment of the password, to no more than 128
- characters.
-
- The method is taken from the book "Network Security" by Kaufman,
- Perlman and Speciner [4] pages 109-110. A more precise explanation
- of the method follows:
-
-
-
-
-
-Rigney, et. al. Informational [Page 21]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Call the shared secret S and the pseudo-random 128-bit Request
- Authenticator RA. Break the password into 16-octet chunks p1, p2,
- etc. with the last one padded at the end with nulls to a 16-octet
- boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
- intermediate values b1, b2, etc.
-
- b1 = MD5(S + RA) c(1) = p1 xor b1
- b2 = MD5(S + c(1)) c(2) = p2 xor b2
- . .
- . .
- . .
- bi = MD5(S + c(i-1)) c(i) = pi xor bi
-
-
- The String will contain c(1)+c(2)+...+c(i) where + denotes
- concatenation.
-
- On receipt, the process is reversed to yield the original password.
-
- A summary of the User-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 2 for User-Password.
-
- Length
-
- At least 18 and no larger than 130.
-
- String
-
- The String field is between 16 and 128 octets long, inclusive.
-
-5.3. CHAP-Password
-
- Description
-
- This Attribute indicates the response value provided by a PPP
- Challenge-Handshake Authentication Protocol (CHAP) user in response
- to the challenge. It is only used in Access-Request packets.
-
-
-
-
-Rigney, et. al. Informational [Page 22]
-\f
-RFC 2058 RADIUS January 1997
-
-
- The CHAP challenge value is found in the CHAP-Challenge Attribute
- (60) if present in the packet, otherwise in the Request
- Authenticator field.
-
- A summary of the CHAP-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | CHAP Ident | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 3 for CHAP-Password.
-
- Length
-
- 19
-
- CHAP Ident
-
- This field is one octet, and contains the CHAP Identifier from the
- user's CHAP Response.
-
- String
-
- The String field is 16 octets, and contains the CHAP Response from
- the user.
-
-
-5.4. NAS-IP-Address
-
- Description
-
- This Attribute indicates the identifying IP Address of the NAS
- which is requesting authentication of the user. It is only used in
- Access-Request packets. Either NAS-IP-Address or NAS-Identifier
- SHOULD be present in an Access-Request packet.
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 23]
-\f
-RFC 2058 RADIUS January 1997
-
-
- A summary of the NAS-IP-Address Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 4 for NAS-IP-Address.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets.
-
-5.5. NAS-Port
-
- Description
-
- This Attribute indicates the physical port number of the NAS which
- is authenticating the user. It is only used in Access-Request
- packets. Note that this is using "port" in its sense of a physical
- connection on the NAS, not in the sense of a TCP or UDP port
- number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be
- present in an Access-Request packet, if the NAS differentiates
- among its ports.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 24]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Despite the size of the field,
- values range from 0 to 65535.
-
-
-5.6. Service-Type
-
- Description
-
- This Attribute indicates the type of service the user has
- requested, or the type of service to be provided. It MAY be used
- in both Access-Request and Access-Accept packets. A NAS is not
- required to implement all of these service types, and MUST treat
- unknown or unsupported Service-Types as though an Access-Reject had
- been received instead.
-
- A summary of the Service-Type Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-Rigney, et. al. Informational [Page 25]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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
-
- The service types are defined as follows when used in an Access-
- Accept. When used in an Access-Request, they should be considered
- to be a hint to the RADIUS server that the NAS has reason to
- believe the user would prefer the kind of service indicated, but
- the server is not required to honor the hint.
-
- Login The user should be connected to a host.
-
- Framed A Framed Protocol should be started for the
- User, such as PPP or SLIP.
-
- Callback Login The user should be disconnected and called
- back, then connected to a host.
-
- Callback Framed The user should be disconnected and called
- back, then a Framed Protocol should be started
- for the User, such as PPP or SLIP.
-
- Outbound The user should be granted access to outgoing
- devices.
-
- Administrative The user should be granted access to the
- administrative interface to the NAS from which
- privileged commands can be executed.
-
-
-
-
-
-Rigney, et. al. Informational [Page 26]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
-
-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
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 27]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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
-
-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.
-
-
-
-Rigney, et. al. Informational [Page 28]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 29]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 Send routing packets
- 2 Listen for routing packets
- 3 Send and Listen
-
-5.11. Filter-Id
-
- Description
-
- This Attribute indicates the name of the filter list for this
- user. Zero or more Filter-Id attributes MAY be sent in an
- Access-Accept packet.
-
- Identifying a filter list by name allows the filter to be used on
- different NASes without regard to filter-list implementation
- details.
-
- A summary of the Filter-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-Rigney, et. al. Informational [Page 30]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Type
-
- 11 for Filter-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable and
- MUST NOT affect operation of the protocol. It is recommended that
- the message contain displayable ASCII characters from the range 32
- through 126 decimal.
-
-5.12. Framed-MTU
-
- Description
-
- This Attribute indicates the Maximum Transmission Unit to be
- configured for the user, when it is not negotiated by some other
- means (such as PPP). It is only used in Access-Accept packets.
-
- A summary of the Framed-MTU Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 12 for Framed-MTU.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 64 to 65535.
-
-
-
-Rigney, et. al. Informational [Page 31]
-\f
-RFC 2058 RADIUS January 1997
-
-
-5.13. Framed-Compression
-
- Description
-
- This Attribute indicates a compression protocol to be used for the
- link. It MAY be used in Access-Accept packets. It MAY be used in
- an Access-Request packet as a hint to the server that the NAS would
- prefer to use that compression, but the server is not required to
- honor the hint.
-
- More than one compression protocol Attribute MAY be sent. It is
- the responsibility of the NAS to apply the proper compression
- protocol to appropriate link traffic.
-
- A summary of the Framed-Compression Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 13 for Framed-Compression.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 VJ TCP/IP header compression [5]
- 2 IPX header compression
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 32]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 14 for Login-IP-Host.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets. The value 0xFFFFFFFF indicates
- that the NAS SHOULD allow the user to select an address. The
- value 0 indicates that the NAS SHOULD select a host to connect the
- user to. Other values indicate the address the NAS SHOULD connect
- the user to.
-
-5.15. Login-Service
-
- Description
-
- This Attribute indicates the service which should be used to
- connect the user to the login host. It is only used in Access-
- Accept packets.
-
-
-
-
-
-Rigney, et. al. Informational [Page 33]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 Telnet
- 1 Rlogin
- 2 TCP Clear
- 3 PortMaster (proprietary)
- 4 LAT
-
-5.16. Login-TCP-Port
-
- Description
-
- This Attribute indicates the TCP port with which the user is to be
- connected, when the Login-Service Attribute is also present. It
- is only used in Access-Accept packets.
-
- A summary of the Login-TCP-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-Rigney, et. al. Informational [Page 34]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
-5.17. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
-
-5.18. Reply-Message
-
- Description
-
- This Attribute indicates text which MAY be displayed to the user.
-
- When used in an Access-Accept, it is the success message.
-
- When used in an Access-Reject, it is the failure message. It MAY
- indicate a dialog message to prompt the user before another
- Access-Request attempt.
-
- When used in an Access-Challenge, it MAY indicate a dialog message
- to prompt the user for a response.
-
- Multiple Reply-Message's MAY be included and if any are displayed,
- they MUST be displayed in the same order as they appear in the
- packet.
-
- A summary of the Reply-Message Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-Rigney, et. al. Informational [Page 35]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Type
-
- 18 for Reply-Message.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable,
- and MUST NOT affect operation of the protocol. It is recommended
- that the message contain displayable ASCII characters from the
- range 10, 13, and 32 through 126 decimal. Mechanisms for
- extension to other character sets are beyond the scope of this
- specification.
-
-5.19. Callback-Number
-
- Description
-
- This Attribute indicates a dialing string to be used for callback.
- It MAY be used in Access-Accept packets. It MAY be used in an
- Access-Request packet as a hint to the server that a Callback
- service is desired, but the server is not required to honor the
- hint.
-
- A summary of the Callback-Number Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 19 for Callback-Number.
-
- Length
-
- >= 3
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 36]
-\f
-RFC 2058 RADIUS January 1997
-
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.20. Callback-Id
-
- Description
-
- This Attribute indicates the name of a place to be called, to be
- interpreted by the NAS. It MAY be used in Access-Accept packets.
-
- A summary of the Callback-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 20 for Callback-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.21. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
-
-
-
-Rigney, et. al. Informational [Page 37]
-\f
-RFC 2058 RADIUS January 1997
-
-
-5.22. Framed-Route
-
- Description
-
- This Attribute provides routing information to be configured for
- the user on the NAS. It is used in the Access-Accept packet and
- can appear multiple times.
-
- A summary of the Framed-Route Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 22 for Framed-Route.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable and
- MUST NOT affect operation of the protocol. It is recommended that
- the message contain displayable ASCII characters from the range 32
- through 126 decimal.
-
- For IP routes, it SHOULD contain a destination prefix in dotted
- quad form optionally followed by a slash and a decimal length
- specifier stating how many high order bits of the prefix should
- be used. That is followed by a space, a gateway address in
- dotted quad form, a space, and one or more metrics separated by
- spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400".
- The length specifier may be omitted in which case it should
- default to 8 bits for class A prefixes, 16 bits for class B
- prefixes, and 24 bits for class C prefixes. For example,
- "192.168.1.0 192.168.1.1 1".
-
- Whenever the gateway address is specified as "0.0.0.0" the IP
- address of the user SHOULD be used as the gateway address.
-
-
-
-
-Rigney, et. al. Informational [Page 38]
-\f
-RFC 2058 RADIUS January 1997
-
-
-5.23. Framed-IPX-Network
-
- Description
-
- This Attribute indicates the IPX Network number to be configured
- for the user. It is used in Access-Accept packets.
-
- A summary of the Framed-IPX-Network Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 23 for Framed-IPX-Network.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. The value 0xFFFFFFFE indicates
- that the NAS should select an IPX network for the user (e.g.
- assigned from a pool of one or more IPX networks kept by the NAS).
- Other values should be used as the IPX network for the link to the
- user.
-
-5.24. State
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Challenge and MUST be sent unmodified from the client
- to the server in the new Access-Request reply to that challenge,
- if any.
-
- 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
-
-
-
-Rigney, et. al. Informational [Page 39]
-\f
-RFC 2058 RADIUS January 1997
-
-
- termination of the current session, it MUST include the State
- attribute unchanged in that Access-Request.
-
- In either usage, no interpretation by the client should be made.
- A packet may have only one State Attribute. Usage of the State
- Attribute is implementation dependent.
-
- A summary of the State Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 24 for State.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.25. Class
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Accept and should be sent unmodified by the client to
- the accounting server as part of the Accounting-Request packet if
- accounting is supported. No interpretation by the client should
- be made.
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 40]
-\f
-RFC 2058 RADIUS January 1997
-
-
- A summary of the Class Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 25 for Class.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.26. Vendor-Specific
-
- Description
-
- This Attribute is available to allow vendors to support their own
- extended Attributes not suitable for general usage. It MUST not
- affect the operation of the RADIUS protocol.
-
- Servers not equipped to interpret the vendor-specific information
- sent by a client MUST ignore it (although it may be reported).
- Clients which do not receive desired vendor-specific information
- SHOULD make an attempt to operate without it, although they may do
- so (and report they are doing so) in a degraded mode.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 41]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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 [2].
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 42]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-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. Informational [Page 43]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Informational [Page 44]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 45]
-\f
-RFC 2058 RADIUS January 1997
-
-
- A summary of the Called-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 30 for Called-Station-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user's call came in on.
-
- The actual format of the information is site or application
- specific. Printable ASCII is recommended, but a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.31. Calling-Station-Id
-
- Description
-
- This Attribute allows the NAS to send in the Access-Request
- packet the phone number that the call came from, using Automatic
- Number Identification (ANI) or similar technology. It is only
- used in Access-Request packets.
-
- A summary of the Calling-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-Rigney, et. al. Informational [Page 46]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Type
-
- 31 for Calling-Station-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user placed the call from.
-
- The actual format of the information is site or application
- specific. Printable ASCII is recommended, but a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.32. NAS-Identifier
-
- Description
-
- This Attribute contains a string identifying the NAS originating
- the Access-Request. It is only used in Access-Request packets.
- Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
- Access-Request packet.
-
- A summary of the NAS-Identifier Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 32 for NAS-Identifier.
-
- Length
-
- >= 3
-
-
-
-
-
-Rigney, et. al. Informational [Page 47]
-\f
-RFC 2058 RADIUS January 1997
-
-
- String
-
- The String field is one or more octets, and should be unique to
- the NAS within the scope of the RADIUS server. For example, a
- fully qualified domain name would be suitable as a NAS-Identifier.
-
- The actual format of the information is site or application
- specific, and a robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.33. Proxy-State
-
- Description
-
- This Attribute is available to be sent by a proxy server to
- another server when forwarding an Access-Request and MUST be
- returned unmodified in the Access-Accept, Access-Reject or
- Access-Challenge. This attribute should be removed by the proxy
- server before the response is forwarded to the NAS.
-
- Usage of the Proxy-State Attribute is implementation dependent. A
- description of its function is outside the scope of this
- specification.
-
- A summary of the Proxy-State Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 33 for Proxy-State.
-
- Length
-
- >= 3
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 48]
-\f
-RFC 2058 RADIUS January 1997
-
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.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 ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 34 for Login-LAT-Service.
-
-
-
-
-
-Rigney, et. al. Informational [Page 49]
-\f
-RFC 2058 RADIUS January 1997
-
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT service to use. The LAT Architecture allows this
- string to contain $ (dollar), - (hyphen), . (period), _
- (underscore), numerics, upper and lower case alphabetics, and the
- ISO Latin-1 character set extension [6]. All LAT string
- comparisons are case insensitive.
-
-5.35. Login-LAT-Node
-
- Description
-
- This Attribute indicates the Node with which the user is to be
- automatically connected by LAT. It MAY be used in Access-Accept
- packets, but only when LAT is specified as the Login-Service. It
- MAY be used in an Access-Request packet as a hint to the server,
- but the server is not required to honor the hint.
-
- A summary of the Login-LAT-Node Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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. Informational [Page 50]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Informational [Page 51]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Informational [Page 52]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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. Informational [Page 53]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Informational [Page 54]
-\f
-RFC 2058 RADIUS January 1997
-
-
- 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. Informational [Page 55]
-\f
-RFC 2058 RADIUS January 1997
-
-
- authenticate himself as an Outbound-User, the Access-Request might
- include NAS-Port-Type = Virtual as a hint to the RADIUS server
- that the user was not on a physical port.
-
- 0 Async
- 1 Sync
- 2 ISDN Sync
- 3 ISDN Async V.120
- 4 ISDN Async V.110
- 5 Virtual
-
-5.42. Port-Limit
-
- Description
-
- This Attribute sets the maximum number of ports to be provided to
- the user by the NAS. This Attribute MAY be sent by the server to
- the client in an Access-Accept packet. It is intended for use in
- conjunction with Multilink PPP [7] or similar uses. It MAY also
- be sent by the NAS to the server as a hint that that many ports
- are desired for use, but the server is not required to honor the
- hint.
-
- A summary of the Port-Limit Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 62 for Port-Limit.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of ports this user should be allowed to connect
- to on the NAS.
-
-
-
-Rigney, et. al. Informational [Page 56]
-\f
-RFC 2058 RADIUS January 1997
-
-
-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
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 57]
-\f
-RFC 2058 RADIUS January 1997
-
-
-5.44. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in which kinds of packets, and in what quantity.
-
- Request Accept Reject Challenge # Attribute
- 1 0 0 0 1 User-Name
- 0-1 0 0 0 2 User-Password [Note 1]
- 0-1 0 0 0 3 CHAP-Password [Note 1]
- 0-1 0 0 0 4 NAS-IP-Address
- 0-1 0 0 0 5 NAS-Port
- 0-1 0-1 0 0 6 Service-Type
- 0-1 0-1 0 0 7 Framed-Protocol
- 0-1 0-1 0 0 8 Framed-IP-Address
- 0-1 0-1 0 0 9 Framed-IP-Netmask
- 0 0-1 0 0 10 Framed-Routing
- 0 0+ 0 0 11 Filter-Id
- 0 0-1 0 0 12 Framed-MTU
- 0+ 0+ 0 0 13 Framed-Compression
- 0+ 0+ 0 0 14 Login-IP-Host
- 0 0-1 0 0 15 Login-Service
- 0 0-1 0 0 16 Login-TCP-Port
- 0 0+ 0+ 0+ 18 Reply-Message
- 0-1 0-1 0 0 19 Callback-Number
- 0 0-1 0 0 20 Callback-Id
- 0 0+ 0 0 22 Framed-Route
- 0 0-1 0 0 23 Framed-IPX-Network
- 0-1 0-1 0 0-1 24 State
- 0 0+ 0 0 25 Class
- 0+ 0+ 0 0+ 26 Vendor-Specific
- 0 0-1 0 0-1 27 Session-Timeout
- 0 0-1 0 0-1 28 Idle-Timeout
- 0 0-1 0 0 29 Termination-Action
- 0-1 0 0 0 30 Called-Station-Id
- 0-1 0 0 0 31 Calling-Station-Id
- 0-1 0 0 0 32 NAS-Identifier
- 0+ 0+ 0+ 0+ 33 Proxy-State
- 0-1 0-1 0 0 34 Login-LAT-Service
- 0-1 0-1 0 0 35 Login-LAT-Node
- 0-1 0-1 0 0 36 Login-LAT-Group
- 0 0-1 0 0 37 Framed-AppleTalk-Link
- 0 0+ 0 0 38 Framed-AppleTalk-Network
- 0 0-1 0 0 39 Framed-AppleTalk-Zone
- 0-1 0 0 0 60 CHAP-Challenge
- 0-1 0 0 0 61 NAS-Port-Type
- 0-1 0-1 0 0 62 Port-Limit
- 0-1 0-1 0 0 63 Login-LAT-Port
- Request Accept Reject Challenge # Attribute
-
-
-
-Rigney, et. al. Informational [Page 58]
-\f
-RFC 2058 RADIUS January 1997
-
-
- [Note 1] An Access-Request MUST contain either a User-Password or a
- CHAP-Password, and MUST NOT contain both.
-
- The following table defines the meaning of the above table entries.
-
-0 This attribute MUST NOT be present in packet.
-0+ Zero or more instances of this attribute MAY be present in packet.
-0-1 Zero or one instance of this attribute MAY be present in packet.
-1 Exactly one instance of this attribute MUST be present in packet.
-
-6. Examples
-
- A few examples are presented to illustrate the flow of packets and
- use of typical attributes. These examples are not intended to be
- exhaustive, many others are possible.
-
-6.1. User Telnet to Specified Host
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named nemo logging in on port 3.
-
- Code = 1 (Access-Request)
- ID = 0
- Request Authenticator = {16 octet random number}
- Attributes:
- User-Name = "nemo"
- User-Password = {16 octets of Password padded at end with nulls,
- XORed with MD5(shared secret|Request Authenticator)}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 3
-
-
- The RADIUS server authenticates nemo, and sends an Access-Accept UDP
- packet to the NAS telling it to telnet nemo to host 192.168.1.3.
-
- Code = 2 (Access-Accept)
- ID = 0 (same as in Access-Request)
- Response Authenticator = {16-octet MD-5 checksum of the code (2),
- id (0), the Request Authenticator from above, the
- attributes in this reply, and the shared secret}
- Attributes:
- Service-Type = Login-User
- Login-Service = Telnet
- Login-Host = 192.168.1.3
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 59]
-\f
-RFC 2058 RADIUS January 1997
-
-
-6.2. Framed User Authenticating with CHAP
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named flopsy logging in on port 20 with PPP,
- authenticating using CHAP. The NAS sends along the Service-Type and
- Framed-Protocol attributes as a hint to the RADIUS server that this
- user is looking for PPP, although the NAS is not required to do so.
-
- Code = 1 (Access-Request)
- ID = 1
- Request Authenticator = {16 octet random number also used as
- CHAP challenge}
- Attributes:
- User-Name = "flopsy"
- CHAP-Password = {1 octet CHAP ID followed by 16 octet
- CHAP response}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 20
- Service-Type = Framed-User
- Framed-Protocol = PPP
-
- The RADIUS server authenticates flopsy, and sends an Access-Accept
- UDP packet to the NAS telling it to start PPP service and assign an
- address for the user out of its dynamic address pool.
-
- Code = 2 (Access-Accept)
- ID = 1 (same as in Access-Request)
- Response Authenticator = {16-octet MD-5 checksum of the code (2),
- id (1), the Request Authenticator from above, the
- attributes in this reply, and the shared secret}
- Attributes:
- Service-Type = Framed-User
- Framed-Protocol = PPP
- Framed-IP-Address = 255.255.255.254
- Framed-Routing = None
- Framed-Compression = 1 (VJ TCP/IP Header Compression)
- Framed-MTU = 1500
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 60]
-\f
-RFC 2058 RADIUS January 1997
-
-
-6.3. User with Challenge-Response card
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named mopsy logging in on port 7.
-
-Code = 1 (Access-Request)
-ID = 2
-Request Authenticator = {16 octet random number}
-Attributes:
- User-Name = "mopsy"
- User-Password = {16 octets of Password padded at end with nulls,
- XORed with MD5(shared secret|Request Authenticator)}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 7
-
- The RADIUS server decides to challenge mopsy, sending back a
- challenge string and looking for a response. The RADIUS server
- therefore and sends an Access-Challenge UDP packet to the NAS.
-
-Code = 11 (Access-Challenge}
-ID = 2 (same as in Access-Request)
-Response Authenticator = {16-octet MD-5 checksum of the code (11),
- id (2), the Request Authenticator from above, the
- attributes in this reply, and the shared secret}
-Attributes:
- Reply-Message = "Challenge 32769430. Enter response at prompt."
- State = {Magic Cookie to be returned along with user's response}
-
- The user enters his response, and the NAS send a new Access-Request
- with that response, and includes the State Attribute.
-
-Code = 1 (Access-Request)
-ID = 3 (Note that this changes)
-Request Authenticator = {NEW 16 octet random number}
-Attributes:
- User-Name = "mopsy"
- User-Password = {16 octets of Response padded at end with
- nulls, XORed with MD5 checksum of shared secret
- plus above Request Authenticator}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 7
- State = {Magic Cookie from Access-Challenge packet, unchanged}
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 61]
-\f
-RFC 2058 RADIUS January 1997
-
-
- The Response was incorrect, so the RADIUS server tells the NAS to
- reject the login attempt.
-
- Code = 3 (Access-Reject)
- ID = 3 (same as in Access-Request)
- Response Authenticator = {16-octet MD-5 checksum of the code (3),
- id (3), the Request Authenticator from above, the
- attributes in this reply if any, and the shared
- secret}
- Attributes:
- (none, although a Reply-Message could be sent)
-
-Security Considerations
-
- Security issues are the primary topic of this document.
-
- In practice, within or associated with each RADIUS server, there is a
- database which associates "user" names with authentication
- information ("secrets"). It is not anticipated that a particular
- named user would be authenticated by multiple methods. This would
- make the user vulnerable to attacks which negotiate the least secure
- method from among a set. Instead, for each named user there should
- be an indication of exactly one method used to authenticate that user
- name. If a user needs to make use of different authentication
- methods under different circumstances, then distinct user names
- SHOULD be employed, each of which identifies exactly one
- authentication method.
-
- Passwords and other secrets should be stored at the respective ends
- such that access to them is as limited as possible. Ideally, the
- secrets should only be accessible to the process requiring access in
- order to perform the authentication.
-
- The secrets should be distributed with a mechanism that limits the
- number of entities that handle (and thus gain knowledge of) the
- secret. Ideally, no unauthorized person should ever gain knowledge
- of the secrets. It is possible to achieve this with SNMP Security
- Protocols [8], but such a mechanism is outside the scope of this
- specification.
-
- Other distribution methods are currently undergoing research and
- experimentation. The SNMP Security document [8] also has an
- excellent overview of threats to network protocols.
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 62]
-\f
-RFC 2058 RADIUS January 1997
-
-
-References
-
- [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
- RFC 1321, MIT Laboratory for Computer Science, RSA Data
- Security Inc., April 1992.
-
- [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- USC/Information Sciences Institute, August 1980.
-
- [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, USC/Information Sciences Institute, October 1994.
-
- [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
- Private Communications in a Public World", Prentice Hall, March
- 1995, ISBN 0-13-061466-1.
-
- [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
- links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
-
- [6] ISO 8859. International Standard -- Information Processing --
- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
- Alphabet No. 1, ISO 8859-1:1987.
- <URL:http://www.iso.ch/cate/d16338.html>
-
- [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
- Multilink Protocol (MP)", RFC 1717, University of California
- Berkeley, Lloyd Internetworking, Newbridge Networks
- Corporation, November 1994.
-
- [8] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
- Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
- LAN Systems, Inc., MIT Laboratory for Computer Science, July
- 1992.
-
- [9] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.
-
-Acknowledgments
-
- RADIUS was originally developed by Livingston Enterprises for their
- PortMaster series of Network Access Servers.
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Informational [Page 63]
-\f
-RFC 2058 RADIUS January 1997
-
-
-Chair's Address
-
- The working group can be contacted via the current chair:
-
- Carl Rigney
- Livingston Enterprises
- 6920 Koll Center Parkway, Suite 220
- Pleasanton, California 94566
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
-Authors' Addresses
-
- Questions about this memo can also be directed to:
-
- Carl Rigney
- Livingston Enterprises
- 6920 Koll Center Parkway, Suite 220
- Pleasanton, California 94566
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
-
- Allan C. Rubens
- Merit Network, Inc.
- 4251 Plymouth Road
- Ann Arbor, Michigan 48105-2785
-
- EMail: acr@merit.edu
-
-
- William Allen Simpson
- Daydreamer
- Computer Systems Consulting Services
- 1384 Fontaine
- Madison Heights, Michigan 48071
-
- EMail: wsimpson@greendragon.com
-
-
- Steve Willens
- Livingston Enterprises
- 6920 Koll Center Parkway, Suite 220
- Pleasanton, California 94566
-
- EMail: steve@livingston.com
-
-
-
-Rigney, et. al. Informational [Page 64]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Rigney
-Request for Comments: 2059 Livingston
-Category: Informational January 1996
-
-
- RADIUS Accounting
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- This document describes a protocol for carrying accounting
- information between a Network Access Server and a shared Accounting
- Server.
-
-Table of Contents
-
- 1. Introduction .......................................... 2
- 1.1 Specification of Requirements ................... 3
- 1.2 Terminology ..................................... 3
- 2. Operation ............................................. 3
- 3. Packet Format ......................................... 4
- 4. Packet Types .......................................... 6
- 4.1 Accounting-Request .............................. 7
- 4.2 Accounting-Response ............................. 8
- 5. Attributes ............................................ 9
- 5.1 Acct-Status-Type ................................ 11
- 5.2 Acct-Delay-Time ................................. 12
- 5.3 Acct-Input-Octets ............................... 13
- 5.4 Acct-Output-Octets .............................. 13
- 5.5 Acct-Session-Id ................................. 14
- 5.6 Acct-Authentic .................................. 15
- 5.7 Acct-Session-Time ............................... 16
- 5.8 Acct-Input-Packets .............................. 17
- 5.9 Acct-Output-Packets ............................. 17
- 5.10 Acct-Terminate-Cause ............................ 18
- 5.11 Acct-Multi-Session-Id ........................... 20
- 5.12 Acct-Link-Count ................................. 21
- 5.13 Table of Attributes ............................. 22
- Security Considerations ...................................... 24
- References ................................................... 24
- Acknowledgements ............................................. 24
- Chair's Address .............................................. 25
- Author's Address ............................................. 25
-
-
-
-Rigney Informational [Page 1]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-1. Introduction
-
- Managing dispersed serial line and modem pools for large numbers of
- users can create the need for significant administrative support.
- Since modem pools are by definition a link to the outside world, they
- require careful attention to security, authorization and accounting.
- This can be best achieved by managing a single "database" of users,
- which allows for authentication (verifying user name and password) as
- well as configuration information detailing the type of service to
- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
-
- The RADIUS (Remote Authentication Dial In User Service) document [4]
- specifies the RADIUS protocol used for Authentication and
- Authorization. This memo extends the use of the RADIUS protocol to
- cover delivery of accounting information from the Network Access
- Server (NAS) to a RADIUS accounting server.
-
- Key features of RADIUS Accounting are:
-
- Client/Server Model
-
- A Network Access Server (NAS) operates as a client of the
- RADIUS accounting server. The client is responsible for
- passing user accounting information to a designated RADIUS
- accounting server.
-
- The RADIUS accounting server is responsible for receiving the
- accounting request and returning a response to the client
- indicating that it has successfully received the request.
-
- The RADIUS accounting server can act as a proxy client to other
- kinds of accounting servers.
-
- Network Security
-
- Transactions between the client and RADIUS accounting server
- are authenticated through the use of a shared secret, which is
- never sent over the network.
-
- Extensible Protocol
-
- All transactions are comprised of variable length Attribute-
- Length-Value 3-tuples. New attribute values can be added
- without disturbing existing implementations of the protocol.
-
- In this document, several words are used to signify the requirements
- of the specification. These words are often capitalized.
-
-
-
-
-Rigney Informational [Page 2]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-1.1 Specification of Requirements
-
- MUST This word, or the adjective "required", means that the
- definition is an absolute requirement of the specification.
-
- MUST NOT This phrase means that the definition is an absolute
- prohibition of the specification.
-
- SHOULD This word, or the adjective "recommended", means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications must be
- understood and carefully weighed before choosing a
- different course.
-
- MAY This word, or the adjective "optional", means that this
- item is one of an allowed set of alternatives. An
- implementation which does not include this option MUST be
- prepared to interoperate with another implementation which
- does include the option.
-
-1.2. Terminology
-
- This document uses the following terms:
-
- service The NAS provides a service to the dial-in user, such as PPP
- or Telnet.
-
- session Each service provided by the NAS to a dial-in user
- constitutes a session, with the beginning of the session
- defined as the point where service is first provided and
- the end of the session defined as the point where service
- is ended. A user may have multiple sessions in parallel or
- series if the NAS supports that, with each session
- generating a separate start and stop accounting record with
- its own Acct-Session-Id.
-
- silently discard
- This means the implementation discards the packet without
- further processing. The implementation SHOULD provide the
- capability of logging the error, including the contents of
- the silently discarded packet, and SHOULD record the event
- in a statistics counter.
-
-2. Operation
-
- When a client is configured to use RADIUS Accounting, at the start of
- service delivery it will generate an Accounting Start packet
- describing the type of service being delivered and the user it is
-
-
-
-Rigney Informational [Page 3]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- being delivered to, and will send that to the RADIUS Accounting
- server, which will send back an acknowledgement that the packet has
- been received. At the end of service delivery the client will
- generate an Accounting Stop packet describing the type of service
- that was delivered and optionally statistics such as elapsed time,
- input and output octets, or input and output packets. It will send
- that to the RADIUS Accounting server, which will send back an
- acknowledgement that the packet has been received.
-
- The Accounting-Request (whether for Start or Stop) is submitted to
- the RADIUS accounting server via the network. It is recommended that
- the client continue attempting to send the Accounting-Request packet
- until it receives an acknowledgement, using some form of backoff. If
- no response is returned within a length of time, the request is re-
- sent a number of times. The client can also forward requests to an
- alternate server or servers in the event that the primary server is
- down or unreachable. An alternate server can be used either after a
- number of tries to the primary server fail, or in a round-robin
- fashion. Retry and fallback algorithms are the topic of current
- research and are not specified in detail in this document.
-
- The RADIUS accounting server MAY make requests of other servers in
- order to satisfy the request, in which case it acts as a client.
-
- If the RADIUS accounting server is unable to successfully record the
- accounting packet it MUST NOT send an Accounting-Response
- acknowledgment to the client.
-
-3. Packet Format
-
- Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
- field [1], where the UDP Destination Port field indicates 1813
- (decimal).
-
- When a reply is generated, the source and destination ports are
- reversed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 4]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the RADIUS data format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-Code
-
- The Code field is one octet, and identifies the type of RADIUS
- packet. When a packet is received with an invalid Code field, it is
- silently discarded.
-
- RADIUS Accounting Codes (decimal) are assigned as follows:
-
- 4 Accounting-Request
- 5 Accounting-Response
-
-
-Identifier
-
- The Identifier field is one octet, and aids in matching requests and
- replies.
-
-Length
-
- The Length field is two octets. It indicates the length of the
- packet including the Code, Identifier, Length, Authenticator and
- Attribute fields. Octets outside the range of the Length field
- should be treated as padding and should be ignored on reception. If
- the packet is shorter than the Length field indicates, it should be
- silently discarded. The minimum length is 20 and maximum length is
- 4096.
-
-Authenticator
-
- The Authenticator field is sixteen (16) octets. The most significant
- octet is transmitted first. This value is used to authenticate the
- messages between the client and RADIUS accounting server.
-
-
-
-Rigney Informational [Page 5]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Request Authenticator
-
- In Accounting-Request Packets, the Authenticator value is a 16
- octet MD5 [3] checksum, called the Request Authenticator.
-
- The NAS and RADIUS accounting server share a secret. The Request
- Authenticator field in Accounting-Request packets contains a one-
- way MD5 hash calculated over a stream of octets consisting of the
- Code + Identifier + Length + 16 zero octets + request attributes +
- shared secret (where + indicates concatenation). The 16 octet MD5
- hash value is stored in the Authenticator field of the
- Accounting-Request packet.
-
- Note that the Request Authenticator of an Accounting-Request can
- not be done the same way as the Request Authenticator of a RADIUS
- Access-Request, because there is no User-Password attribute in an
- Accounting-Request.
-
-Response Authenticator
-
- The Authenticator field in an Accounting-Response packet is called
- the Response Authenticator, and contains a one-way MD5 hash
- calculated over a stream of octets consisting of the Accounting-
- Response Code, Identifier, Length, the Request Authenticator field
- from the Accounting-Request packet being replied to, and the response
- attributes if any, followed by the shared secret. The resulting 16
- octet MD5 hash value is stored in the Authenticator field of the
- Accounting-Response packet.
-
-Attributes
-
- Attributes may have multiple instances, in such a case the order of
- attributes of the same type SHOULD be preserved. The order of
- attributes of different types is not required to be preserved.
-
-4. Packet Types
-
- The RADIUS packet type is determined by the Code field in the first
- octet of the packet.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 6]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-4.1. Accounting-Request
-
- Description
-
- Accounting-Request packets are sent from a client (typically a
- Network Access Server or its proxy) to a RADIUS accounting server,
- and convey information used to provide accounting for a service
- provided to a user. The client transmits a RADIUS packet with the
- Code field set to 4 (Accounting-Request).
-
- Upon receipt of an Accounting-Request, the server MUST transmit an
- Accounting-Response reply if it successfully records the
- accounting packet, and MUST NOT transmit any reply if it fails to
- record the accounting packet.
-
- Any attribute valid in a RADIUS Access-Request or Access-Accept
- packet is valid in a RADIUS Accounting-Request packet, except that
- the following attributes MUST NOT be present in an Accounting-
- Request: User-Password, CHAP-Password, Reply-Message, State.
- Either NAS-IP-Address or NAS-Identifier MUST be present in a
- RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
- Port-Type attribute or both unless the service does not involve a
- port or the NAS does not distinguish among its ports.
-
- A summary of the Accounting-Request packet format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Request Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 4 for Accounting-Request.
-
- Identifier
-
- The Identifier field MUST be changed whenever the content of the
- Attributes field changes, and whenever a valid reply has been
-
-
-
-Rigney Informational [Page 7]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- received for a previous request. For retransmissions where the
- contents are identical, the Identifier MUST remain unchanged.
-
- Note that if Acct-Delay-Time is included in the attributes of an
- Accounting-Request then the Acct-Delay-Time value will be updated
- when the packet is retransmitted, changing the content of the
- Attributes field and requiring a new Identifier and Request
- Authenticator.
-
- Request Authenticator
-
- The Request Authenticator of an Accounting-Request contains a 16-
- octet MD5 hash value calculated according to the method described
- in "Request Authenticator" above.
-
-Attributes
-
- The Attributes field is variable in length, and contains a list of
- Attributes.
-
-4.2. Accounting-Response
-
- Description
-
- Accounting-Response packets are sent by the RADIUS accounting
- server to the client to acknowledge that the Accounting-Request
- has been received and recorded successfully. If the Accounting-
- Request was recorded successfully then the RADIUS accounting
- server MUST transmit a packet with the Code field set to 5
- (Accounting-Response). On reception of an Accounting-Response by
- the client, the Identifier field is matched with a pending
- Accounting-Request. Invalid packets are silently discarded.
-
- A RADIUS Accounting-Response is not required to have any
- attributes in it.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 8]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the Accounting-Response packet format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Code
-
- 5 for Accounting-Response.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Accounting-Request which caused this Accounting-Response.
-
- Response Authenticator
-
- The Response Authenticator of an Accounting-Response contains a
- 16-octet MD5 hash value calculated according to the method
- described in "Response Authenticator" above.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- zero or more Attributes.
-
-5. Attributes
-
- RADIUS Attributes carry the specific authentication, authorization
- and accounting details for the request and response.
-
- Some attributes MAY be included more than once. The effect of this
- is attribute specific, and is specified in each attribute
- description.
-
- The end of the list of attributes is indicated by the Length of the
- RADIUS packet.
-
-
-
-Rigney Informational [Page 9]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the attribute format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- The Type field is one octet. Up-to-date values of the RADIUS Type
- field are specified in the most recent "Assigned Numbers" RFC [2].
- Values 192-223 are reserved for experimental use, values 224-240
- are reserved for implementation-specific use, and values 241-255
- are reserved and should not be used. This specification concerns
- the following values:
-
- 1-39 (refer to RADIUS document [4])
- 40 Acct-Status-Type
- 41 Acct-Delay-Time
- 42 Acct-Input-Octets
- 43 Acct-Output-Octets
- 44 Acct-Session-Id
- 45 Acct-Authentic
- 46 Acct-Session-Time
- 47 Acct-Input-Packets
- 48 Acct-Output-Packets
- 49 Acct-Terminate-Cause
- 50 Acct-Multi-Session-Id
- 51 Acct-Link-Count
- 60+ (refer to RADIUS document [4])
-
- Length
-
- The Length field is one octet, and indicates the length of this
- attribute including the Type, Length and Value fields. If an
- attribute is received in an Accounting-Request with an invalid
- Length, the entire request should be silently discarded.
-
- Value
-
- The Value field is zero or more octets and contains information
- specific to the attribute. The format and length of the Value
- field is determined by the Type and Length fields.
-
- The format of the value field is one of four data types.
-
-
-
-Rigney Informational [Page 10]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- string 0-253 octets
-
- address 32 bit value, most significant octet first.
-
- integer 32 bit value, most significant octet first.
-
- time 32 bit value, most significant octet first -- seconds
- since 00:00:00 GMT, January 1, 1970. The standard
- Attributes do not use this data type but it is presented
- here for possible use within Vendor-Specific attributes.
-
-5.1. Acct-Status-Type
-
- Description
-
- This attribute indicates whether this Accounting-Request marks the
- beginning of the user service (Start) or the end (Stop).
-
- It MAY be used by the client to mark the start of accounting (for
- example, upon booting) by specifying Accounting-On and to mark the
- end of accounting (for example, just before a scheduled reboot) by
- specifying Accounting-Off.
-
- A summary of the Acct-Status-Type attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 40 for Acct-Status-Type.
-
- Length
-
- 6
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 11]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Value
-
- The Value field is four octets.
-
- 1 Start
- 2 Stop
- 7 Accounting-On
- 8 Accounting-Off
-
-
-5.2. Acct-Delay-Time
-
- Description
-
- This attribute indicates how many seconds the client has been
- trying to send this record for, and can be subtracted from the
- time of arrival on the server to find the approximate time of the
- event generating this Accounting-Request. (Network transit time
- is ignored.)
-
- Note that changing the Acct-Delay-Time causes the Identifier to
- change; see the discussion under Identifier above.
-
- A summary of the Acct-Delay-Time attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 41 for Acct-Delay-Time.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-
-
-
-
-Rigney Informational [Page 12]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-5.3. Acct-Input-Octets
-
- Description
-
- This attribute indicates how many octets have been received from
- the port over the course of this service being provided, and can
- only be present in Accounting-Request records where the Acct-
- Status-Type is set to Stop.
-
- A summary of the Acct-Input-Octets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 42 for Acct-Input-Octets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.4. Acct-Output-Octets
-
- Description
-
- This attribute indicates how many octets have been sent to the
- port in the course of delivering this service, and can only be
- present in Accounting-Request records where the Acct-Status-Type
- is set to Stop.
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 13]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the Acct-Output-Octets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 43 for Acct-Output-Octets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.5. Acct-Session-Id
-
- Description
-
- This attribute is a unique Accounting ID to make it easy to match
- start and stop records in a log file. The start and stop records
- for a given session MUST have the same Acct-Session-Id. It is
- strongly recommended that the Acct-Session-Id be a printable ASCII
- string.
-
- For example, one implementation uses a string with an 8-digit
- upper case hexadecimal number, the first two digits increment on
- each reboot (wrapping every 256 reboots) and the next 6 digits
- counting from 0 for the first person logging in after a reboot up
- to 2^24-1, about 16 million. Other encodings are possible.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 14]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the Acct-Session-Id attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 44 for Acct-Session-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field SHOULD be a string of printable ASCII characters.
-
-5.6. Acct-Authentic
-
- Description
-
- This attribute MAY be included in an Accounting-Request to
- indicate how the user was authenticated, whether by RADIUS, the
- NAS itself, or another remote authentication protocol. Users who
- are delivered service without being authenticated SHOULD NOT
- generate Accounting records.
-
- A summary of the Acct-Authentic attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 45 for Acct-Authentic.
-
-
-
-
-Rigney Informational [Page 15]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 RADIUS
- 2 Local
- 3 Remote
-
-5.7. Acct-Session-Time
-
- Description
-
- This attribute indicates how many seconds the user has received
- service for, and can only be present in Accounting-Request records
- where the Acct-Status-Type is set to Stop.
-
- A summary of the Acct-Session-Time attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 46 for Acct-Session-Time.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 16]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-5.8. Acct-Input-Packets
-
- Description
-
- This attribute indicates how many packets have been received from
- the port over the course of this service being provided to a
- Framed User, and can only be present in Accounting-Request records
- where the Acct-Status-Type is set to Stop.
-
- A summary of the Acct-Input-packets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 47 for Acct-Input-Packets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.9. Acct-Output-Packets
-
- Description
-
- This attribute indicates how many packets have been sent to the
- port in the course of delivering this service to a Framed User,
- and can only be present in Accounting-Request records where the
- Acct-Status-Type is set to Stop.
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 17]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the Acct-Output-Packets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 48 for Acct-Output-Packets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-
-5.10. Acct-Terminate-Cause
-
- Description
-
- This attribute indicates how the session was terminated, and can
- only be present in Accounting-Request records where the Acct-
- Status-Type is set to Stop.
-
- A summary of the Acct-Terminate-Cause attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 49 for Acct-Terminate-Cause
-
-
-
-Rigney Informational [Page 18]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets, containing an integer specifying
- the cause of session termination, as follows:
-
- 1 User Request
- 2 Lost Carrier
- 3 Lost Service
- 4 Idle Timeout
- 5 Session Timeout
- 6 Admin Reset
- 7 Admin Reboot
- 8 Port Error
- 9 NAS Error
- 10 NAS Request
- 11 NAS Reboot
- 12 Port Unneeded
- 13 Port Preempted
- 14 Port Suspended
- 15 Service Unavailable
- 16 Callback
- 17 User Error
- 18 Host Request
-
-
- The termination causes are as follows:
-
- User Request User requested termination of service, for
- example with LCP Terminate or by logging out.
-
- Lost Carrier DCD was dropped on the port.
-
- Lost Service Service can no longer be provided; for
- example, user's connection to a host was
- interrupted.
-
- Idle Timeout Idle timer expired.
-
- Session Timeout Maximum session length timer expired.
-
- Admin Reset Administrator reset the port or session.
-
- Admin Reboot Administrator is ending service on the NAS,
- for example prior to rebooting the NAS.
-
-
-
-Rigney Informational [Page 19]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Port Error NAS detected an error on the port which
- required ending the session.
-
- NAS Error NAS detected some error (other than on the
- port) which required ending the session.
-
- NAS Request NAS ended session for a non-error reason not
- otherwise listed here.
-
- NAS Reboot The NAS ended the session in order to reboot
- non-administratively ("crash").
-
- Port Unneeded NAS ended session because resource usage fell
- below low-water mark (for example, if a
- bandwidth-on-demand algorithm decided that
- the port was no longer needed).
-
- Port Preempted NAS ended session in order to allocate the
- port to a higher priority use.
-
- Port Suspended NAS ended session to suspend a virtual
- session.
-
- Service Unavailable NAS was unable to provide requested service.
-
- Callback NAS is terminating current session in order
- to perform callback for a new session.
-
- User Error Input from user is in error, causing
- termination of session.
-
- Host Request Login Host terminated session normally.
-
-5.11. Acct-Multi-Session-Id
-
- Description
-
- This attribute is a unique Accounting ID to make it easy to link
- together multiple related sessions in a log file. Each session
- linked together would have a unique Acct-Session-Id but the same
- Acct-Multi-Session-Id. It is strongly recommended that the Acct-
- Multi-Session-Id be a printable ASCII string.
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 20]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- A summary of the Acct-Session-Id attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 50 for Acct-Multi-Session-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field SHOULD be a string of printable ASCII characters.
-
-5.12. Acct-Link-Count
-
- Description
-
- This attribute gives the count of links which are known to have
- been in a given multilink session at the time the accounting
- record is generated. The NAS MAY include the Acct-Link-Count
- attribute in any Accounting-Request which might have multiple
- links.
-
- A summary of the Acct-Link-Count attribute format is show below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Type
-
- 51 for Acct-Link-Count.
-
-
-
-
-Rigney Informational [Page 21]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets, and contains the number of links
- seen so far in this Multilink Session.
-
- It may be used to make it easier for an accounting server to know
- when it has all the records for a given Multilink session. When
- the number of Accounting-Requests received with Acct-Status-Type =
- Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
- Id's equals the largest value of Acct-Link-Count seen in those
- Accounting-Requests, all Stop Accounting-Requests for that
- Multilink Session have been received.
-
- An example showing 8 Accounting-Requests should make things
- clearer. For clarity only the relevant attributes are shown, but
- additional attributes containing accounting information will also
- be present in the Accounting-Request.
-
- Multi-Session-Id Session-Id Status-Type Link-Count
- "10" "10" Start 1
- "10" "11" Start 2
- "10" "11" Stop 2
- "10" "12" Start 3
- "10" "13" Start 4
- "10" "12" Stop 4
- "10" "13" Stop 4
- "10" "10" Stop 4
-
-5.13. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in Accounting-Request packets. No attributes should be found in
- Accounting-Response packets except Proxy-State and possibly Vendor-
- Specific.
-
-
- # Attribute
- 0-1 User-Name
- 0 User-Password
- 0 CHAP-Password
- 0-1 NAS-IP-Address [4]
- 0-1 NAS-Port
- 0-1 Service-Type
- 0-1 Framed-Protocol
-
-
-
-Rigney Informational [Page 22]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- 0-1 Framed-IP-Address
- 0-1 Framed-IP-Netmask
- 0-1 Framed-Routing
- 0+ Filter-Id
- 0-1 Framed-MTU
- 0+ Framed-Compression
- 0+ Login-IP-Host
- 0-1 Login-Service
- 0-1 Login-TCP-Port
- 0 Reply-Message
- 0-1 Callback-Number
- 0-1 Callback-Id
- 0+ Framed-Route
- 0-1 Framed-IPX-Network
- 0 State
- 0+ Class
- 0+ Vendor-Specific
- 0-1 Session-Timeout
- 0-1 Idle-Timeout
- 0-1 Termination-Action
- 0-1 Called-Station-Id
- 0-1 Calling-Station-Id
- 0-1 NAS-Identifier [4]
- 0+ Proxy-State
- 0-1 Login-LAT-Service
- 0-1 Login-LAT-Node
- 0-1 Login-LAT-Group
- 0-1 Framed-AppleTalk-Link
- 0-1 Framed-AppleTalk-Network
- 0-1 Framed-AppleTalk-Zone
- 1 Acct-Status-Type
- 0-1 Acct-Delay-Time
- 0-1 Acct-Input-Octets
- 0-1 Acct-Output-Octets
- 1 Acct-Session-Id
- 0-1 Acct-Authentic
- 0-1 Acct-Session-Time
- 0-1 Acct-Input-Packets
- 0-1 Acct-Output-Packets
- 0-1 Acct-Terminate-Cause
- 0+ Acct-Multi-Session-Id
- 0+ Acct-Link-Count
- 0 CHAP-Challenge
- 0-1 NAS-Port-Type
- 0-1 Port-Limit
- 0-1 Login-LAT-Port
-
-
-
-
-
-Rigney Informational [Page 23]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
- [4] An Accounting-Request MUST contain either a NAS-IP-Address or a
- NAS-Identifier, and it is permitted (but not recommended) for it to
- contain both.
-
- The following table defines the above table entries.
-
- 0 This attribute MUST NOT be present
- 0+ Zero or more instances of this attribute MAY be present.
- 0-1 Zero or one instance of this attribute MAY be present.
- 1 Exactly one instance of this attribute MUST be present.
-
-Security Considerations
-
- Security issues are briefly discussed in sections concerning the
- authenticator included in accounting requests and responses, using a
- shared secret which is never sent over the network.
-
-References
-
- [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- USC/Information Sciences Institute, August 1980.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, USC/Information Sciences Institute, October 1994.
-
- [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
- RFC 1321, MIT Laboratory for Computer Science, RSA Data
- Security Inc., April 1992.
-
- [4] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
- Authentication Dial In User Service (RADIUS)", RFC 2058,
- January 1997.
-
-Acknowledgments
-
- RADIUS and RADIUS Accounting were originally developed by Livingston
- Enterprises for their PortMaster series of Network Access Servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 24]
-\f
-RFC 2059 RADIUS Accounting January 1997
-
-
-Chair's Address
-
- The RADIUS working group can be contacted via the current chair:
-
- Carl Rigney
- Livingston Enterprises
- 6920 Koll Center Parkway, Suite 220
- Pleasanton, California 94566
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
-
-Author's Address
-
- Questions about this memo can also be directed to:
-
- Carl Rigney
- Livingston Enterprises
- 6920 Koll Center Parkway, Suite 220
- Pleasanton, California 94566
-
- EMail: cdr@livingston.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 25]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Rigney
-Request for Comments: 2138 Livingston
-Obsoletes: 2058 A. Rubens
-Category: Standards Track Merit
- W. Simpson
- Daydreamer
- S. Willens
- Livingston
- April 1997
-
-
- Remote Authentication Dial In User Service (RADIUS)
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes a protocol for carrying authentication,
- authorization, and configuration information between a Network Access
- Server which desires to authenticate its links and a shared
- Authentication Server.
-
-Implementation Note
-
- This memo documents the RADIUS protocol. There has been some
- confusion in the assignment of port numbers for this protocol. The
- early deployment of RADIUS was done using the erroneously chosen port
- number 1645, which conflicts with the "datametrics" service. The
- officially assigned port number for RADIUS is 1812.
-
-Table of Contents
-
- 1. Introduction .......................................... 3
- 1.1 Specification of Requirements ................... 4
- 1.2 Terminology ..................................... 5
- 2. Operation ............................................. 5
- 2.1 Challenge/Response .............................. 7
- 2.2 Interoperation with PAP and CHAP ................ 7
- 2.3 Why UDP? ........................................ 8
- 3. Packet Format ......................................... 10
- 4. Packet Types .......................................... 13
- 4.1 Access-Request .................................. 13
-
-
-
-Rigney, et. al. Standards Track [Page 1]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 4.2 Access-Accept ................................... 14
- 4.3 Access-Reject ................................... 15
- 4.4 Access-Challenge ................................ 17
- 5. Attributes ............................................ 18
- 5.1 User-Name ....................................... 21
- 5.2 User-Password ................................... 22
- 5.3 CHAP-Password ................................... 23
- 5.4 NAS-IP-Address .................................. 24
- 5.5 NAS-Port ........................................ 25
- 5.6 Service-Type .................................... 26
- 5.7 Framed-Protocol ................................. 28
- 5.8 Framed-IP-Address ............................... 29
- 5.9 Framed-IP-Netmask ............................... 29
- 5.10 Framed-Routing .................................. 30
- 5.11 Filter-Id ....................................... 31
- 5.12 Framed-MTU ...................................... 32
- 5.13 Framed-Compression .............................. 33
- 5.14 Login-IP-Host ................................... 33
- 5.15 Login-Service ................................... 34
- 5.16 Login-TCP-Port .................................. 35
- 5.17 (unassigned) .................................... 36
- 5.18 Reply-Message ................................... 36
- 5.19 Callback-Number ................................. 37
- 5.20 Callback-Id ..................................... 38
- 5.21 (unassigned) .................................... 38
- 5.22 Framed-Route .................................... 39
- 5.23 Framed-IPX-Network .............................. 40
- 5.24 State ........................................... 40
- 5.25 Class ........................................... 41
- 5.26 Vendor-Specific ................................. 42
- 5.27 Session-Timeout ................................. 44
- 5.28 Idle-Timeout .................................... 44
- 5.29 Termination-Action .............................. 45
- 5.30 Called-Station-Id ............................... 46
- 5.31 Calling-Station-Id .............................. 47
- 5.32 NAS-Identifier .................................. 48
- 5.33 Proxy-State ..................................... 48
- 5.34 Login-LAT-Service ............................... 49
- 5.35 Login-LAT-Node .................................. 50
- 5.36 Login-LAT-Group ................................. 51
- 5.37 Framed-AppleTalk-Link ........................... 52
- 5.38 Framed-AppleTalk-Network ........................ 53
- 5.39 Framed-AppleTalk-Zone ........................... 54
- 5.40 CHAP-Challenge .................................. 55
- 5.41 NAS-Port-Type ................................... 55
- 5.42 Port-Limit ...................................... 56
- 5.43 Login-LAT-Port .................................. 57
- 5.44 Table of Attributes ............................. 58
-
-
-
-Rigney, et. al. Standards Track [Page 2]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 6. Examples .............................................. 59
- 6.1 User Telnet to Specified Host ................... 60
- 6.2 Framed User Authenticating with CHAP ............ 60
- 6.3 User with Challenge-Response card ............... 61
- Security Considerations ...................................... 63
- References ................................................... 64
- Acknowledgements ............................................. 64
- Chair's Address .............................................. 65
- Author's Addresses ........................................... 65
-
-1. Introduction
-
- Managing dispersed serial line and modem pools for large numbers of
- users can create the need for significant administrative support.
- Since modem pools are by definition a link to the outside world, they
- require careful attention to security, authorization and accounting.
- This can be best achieved by managing a single "database" of users,
- which allows for authentication (verifying user name and password) as
- well as configuration information detailing the type of service to
- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
-
- Key features of RADIUS are:
-
- Client/Server Model
-
- A Network Access Server (NAS) operates as a client of RADIUS. The
- client is responsible for passing user information to designated
- RADIUS servers, and then acting on the response which is returned.
-
- RADIUS servers are responsible for receiving user connection
- requests, authenticating the user, and then returning all
- configuration information necessary for the client to deliver
- service to the user.
-
- A RADIUS server can act as a proxy client to other RADIUS servers
- or other kinds of authentication servers.
-
- Network Security
-
- Transactions between the client and RADIUS server are
- authenticated through the use of a shared secret, which is never
- sent over the network. In addition, any user passwords are sent
- encrypted between the client and RADIUS server, to eliminate the
- possibility that someone snooping on an unsecure network could
- determine a user's password.
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 3]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Flexible Authentication Mechanisms
-
- The RADIUS server can support a variety of methods to authenticate
- a user. When it is provided with the user name and original
- password given by the user, it can support PPP PAP or CHAP, UNIX
- login, and other authentication mechanisms.
-
- Extensible Protocol
-
- All transactions are comprised of variable length Attribute-
- Length-Value 3-tuples. New attribute values can be added without
- disturbing existing implementations of the protocol.
-
-1.1. Specification of Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. These words are often capitalized.
-
- MUST This word, or the adjective "required", means that the
- definition is an absolute requirement of the specification.
-
- MUST NOT This phrase means that the definition is an absolute
- prohibition of the specification.
-
- SHOULD This word, or the adjective "recommended", means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications must be
- understood and carefully weighed before choosing a
- different course.
-
- MAY This word, or the adjective "optional", means that this
- item is one of an allowed set of alternatives. An
- implementation which does not include this option MUST be
- prepared to interoperate with another implementation which
- does include the option.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 4]
-\f
-RFC 2138 RADIUS April 1997
-
-
-1.2. Terminology
-
- This document frequently uses the following terms:
-
- service The NAS provides a service to the dial-in user, such as PPP
- or Telnet.
-
- session Each service provided by the NAS to a dial-in user
- constitutes a session, with the beginning of the session
- defined as the point where service is first provided and
- the end of the session defined as the point where service
- is ended. A user may have multiple sessions in parallel or
- series if the NAS supports that.
-
- silently discard
- This means the implementation discards the packet without
- further processing. The implementation SHOULD provide the
- capability of logging the error, including the contents of
- the silently discarded packet, and SHOULD record the event
- in a statistics counter.
-
-2. Operation
-
- When a client is configured to use RADIUS, any user of the client
- presents authentication information to the client. This might be
- with a customizable login prompt, where the user is expected to enter
- their username and password. Alternatively, the user might use a
- link framing protocol such as the Point-to-Point Protocol (PPP),
- which has authentication packets which carry this information.
-
- Once the client has obtained such information, it may choose to
- authenticate using RADIUS. To do so, the client creates an "Access-
- Request" containing such Attributes as the user's name, the user's
- password, the ID of the client and the Port ID which the user is
- accessing. When a password is present, it is hidden using a method
- based on the RSA Message Digest Algorithm MD5 [1].
-
- The Access-Request is submitted to the RADIUS server via the network.
- If no response is returned within a length of time, the request is
- re-sent a number of times. The client can also forward requests to
- an alternate server or servers in the event that the primary server
- is down or unreachable. An alternate server can be used either after
- a number of tries to the primary server fail, or in a round-robin
- fashion. Retry and fallback algorithms are the topic of current
- research and are not specified in detail in this document.
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 5]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Once the RADIUS server receives the request, it validates the sending
- client. A request from a client for which the RADIUS server does not
- have a shared secret should be silently discarded. If the client is
- valid, the RADIUS server consults a database of users to find the
- user whose name matches the request. The user entry in the database
- contains a list of requirements which must be met to allow access for
- the user. This always includes verification of the password, but can
- also specify the client(s) or port(s) to which the user is allowed
- access.
-
- The RADIUS server MAY make requests of other servers in order to
- satisfy the request, in which case it acts as a client.
-
- If any condition is not met, the RADIUS server sends an "Access-
- Reject" response indicating that this user request is invalid. If
- desired, the server MAY include a text message in the Access-Reject
- which MAY be displayed by the client to the user. No other
- Attributes are permitted in an Access-Reject.
-
- If all conditions are met and the RADIUS server wishes to issue a
- challenge to which the user must respond, the RADIUS server sends an
- "Access-Challenge" response. It MAY include a text message to be
- displayed by the client to the user prompting for a response to the
- challenge, and MAY include a State attribute. If the client receives
- an Access-Challenge and supports challenge/response it MAY display
- the text message, if any, to the user, and then prompt the user for a
- response. The client then re-submits its original Access-Request
- with a new request ID, with the User-Password Attribute replaced by
- the response (encrypted), and including the State Attribute from the
- Access-Challenge, if any. Only 0 or 1 instances of the State
- Attributes should be present in a request. The server can respond to
- this new Access-Request with either an Access-Accept, an Access-
- Reject, or another Access-Challenge.
-
- If all conditions are met, the list of configuration values for the
- user are placed into an "Access-Accept" response. These values
- include the type of service (for example: SLIP, PPP, Login User) and
- all necessary values to deliver the desired service. For SLIP and
- PPP, this may include values such as IP address, subnet mask, MTU,
- desired compression, and desired packet filter identifiers. For
- character mode users, this may include values such as desired
- protocol and host.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 6]
-\f
-RFC 2138 RADIUS April 1997
-
-
-2.1. Challenge/Response
-
- In challenge/response authentication, the user is given an
- unpredictable number and challenged to encrypt it and give back the
- result. Authorized users are equipped with special devices such as
- smart cards or software that facilitate calculation of the correct
- response with ease. Unauthorized users, lacking the appropriate
- device or software and lacking knowledge of the secret key necessary
- to emulate such a device or software, can only guess at the response.
-
- The Access-Challenge packet typically contains a Reply-Message
- including a challenge to be displayed to the user, such as a numeric
- value unlikely ever to be repeated. Typically this is obtained from
- an external server that knows what type of authenticator should be in
- the possession of the authorized user and can therefore choose a
- random or non-repeating pseudorandom number of an appropriate radix
- and length.
-
- The user then enters the challenge into his device (or software) and
- it calculates a response, which the user enters into the client which
- forwards it to the RADIUS server via a second Access-Request. If the
- response matches the expected response the RADIUS server replies with
- an Access-Accept, otherwise an Access-Reject.
-
- Example: The NAS sends an Access-Request packet to the RADIUS Server
- with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
- just be a fixed string like "challenge" or ignored). The server
- sends back an Access-Challenge packet with State and a Reply-Message
- along the lines of "Challenge 12345678, enter your response at the
- prompt" which the NAS displays. The NAS prompts for the response and
- sends a NEW Access-Request to the server (with a new ID) with NAS-
- Identifier, NAS-Port, User-Name, User-Password (the response just
- entered by the user, encrypted), and the same State Attribute that
- came with the Access-Challenge. The server then sends back either an
- Access-Accept or Access-Reject based on whether the response matches
- what it should be, or it can even send another Access-Challenge.
-
-2.2. Interoperation with PAP and CHAP
-
- For PAP, the NAS takes the PAP ID and password and sends them in an
- Access-Request packet as the User-Name and User-Password. The NAS MAY
- include the Attributes Service-Type = Framed-User and Framed-Protocol
- = PPP as a hint to the RADIUS server that PPP service is expected.
-
- For CHAP, the NAS generates a random challenge (preferably 16 octets)
- and sends it to the user, who returns a CHAP response along with a
- CHAP ID and CHAP username. The NAS then sends an Access-Request
- packet to the RADIUS server with the CHAP username as the User-Name
-
-
-
-Rigney, et. al. Standards Track [Page 7]
-\f
-RFC 2138 RADIUS April 1997
-
-
- and with the CHAP ID and CHAP response as the CHAP-Password
- (Attribute 3). The random challenge can either be included in the
- CHAP-Challenge attribute or, if it is 16 octets long, it can be
- placed in the Request Authenticator field of the Access-Request
- packet. The NAS MAY include the Attributes Service-Type = Framed-
- User and Framed-Protocol = PPP as a hint to the RADIUS server that
- PPP service is expected.
-
- The RADIUS server looks up a password based on the User-Name,
- encrypts the challenge using MD5 on the CHAP ID octet, that password,
- and the CHAP challenge (from the CHAP-Challenge attribute if present,
- otherwise from the Request Authenticator), and compares that result
- to the CHAP-Password. If they match, the server sends back an
- Access-Accept, otherwise it sends back an Access-Reject.
-
- If the RADIUS server is unable to perform the requested
- authentication it should return an Access-Reject. For example, CHAP
- requires that the user's password be available in cleartext to the
- server so that it can encrypt the CHAP challenge and compare that to
- the CHAP response. If the password is not available in cleartext to
- the RADIUS server then the server MUST send an Access-Reject to the
- client.
-
-2.3. Why UDP?
-
- A frequently asked question is why RADIUS uses UDP instead of TCP as
- a transport protocol. UDP was chosen for strictly technical reasons.
-
- There are a number of issues which must be understood. RADIUS is a
- transaction based protocol which has several interesting
- characteristics:
-
- 1. If the request to a primary Authentication server fails, a
- secondary server must be queried.
-
- To meet this requirement, a copy of the request must be kept
- above the transport layer to allow for alternate transmission.
- This means that retransmission timers are still required.
-
- 2. The timing requirements of this particular protocol are
- significantly different than TCP provides.
-
- At one extreme, RADIUS does not require a "responsive"
- detection of lost data. The user is willing to wait several
- seconds for the authentication to complete. The generally
- aggressive TCP retransmission (based on average round trip
- time) is not required, nor is the acknowledgement overhead of
- TCP.
-
-
-
-Rigney, et. al. Standards Track [Page 8]
-\f
-RFC 2138 RADIUS April 1997
-
-
- At the other extreme, the user is not willing to wait several
- minutes for authentication. Therefore the reliable delivery of
- TCP data two minutes later is not useful. The faster use of an
- alternate server allows the user to gain access before giving
- up.
-
- 3. The stateless nature of this protocol simplifies the use of UDP.
-
- Clients and servers come and go. Systems are rebooted, or are
- power cycled independently. Generally this does not cause a
- problem and with creative timeouts and detection of lost TCP
- connections, code can be written to handle anomalous events.
- UDP however completely eliminates any of this special handling.
- Each client and server can open their UDP transport just once
- and leave it open through all types of failure events on the
- network.
-
- 4. UDP simplifies the server implementation.
-
- In the earliest implementations of RADIUS, the server was
- single threaded. This means that a single request was
- received, processed, and returned. This was found to be
- unmanageable in environments where the back-end security
- mechanism took real time (1 or more seconds). The server
- request queue would fill and in environments where hundreds of
- people were being authenticated every minute, the request
- turn-around time increased to longer that users were willing to
- wait (this was especially severe when a specific lookup in a
- database or over DNS took 30 or more seconds). The obvious
- solution was to make the server multi-threaded. Achieving this
- was simple with UDP. Separate processes were spawned to serve
- each request and these processes could respond directly to the
- client NAS with a simple UDP packet to the original transport
- of the client.
-
- It's not all a panacea. As noted, using UDP requires one thing
- which is built into TCP: with UDP we must artificially manage
- retransmission timers to the same server, although they don't
- require the same attention to timing provided by TCP. This one
- penalty is a small price to pay for the advantages of UDP in
- this protocol.
-
- Without TCP we would still probably be using tin cans connected
- by string. But for this particular protocol, UDP is a better
- choice.
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 9]
-\f
-RFC 2138 RADIUS April 1997
-
-
-3. Packet Format
-
- Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
- where the UDP Destination Port field indicates 1812 (decimal).
-
- When a reply is generated, the source and destination ports are
- reversed.
-
- This memo documents the RADIUS protocol. There has been some
- confusion in the assignment of port numbers for this protocol. The
- early deployment of RADIUS was done using the erroneously chosen port
- number 1645, which conflicts with the "datametrics" service. The
- officially assigned port number for RADIUS is 1812.
-
- A summary of the RADIUS data format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-Code
-
- The Code field is one octet, and identifies the type of RADIUS
- packet. When a packet is received with an invalid Code field, it is
- silently discarded.
-
- RADIUS Codes (decimal) are assigned as follows:
-
- 1 Access-Request
- 2 Access-Accept
- 3 Access-Reject
- 4 Accounting-Request
- 5 Accounting-Response
- 11 Access-Challenge
- 12 Status-Server (experimental)
- 13 Status-Client (experimental)
- 255 Reserved
-
-
-
-
-Rigney, et. al. Standards Track [Page 10]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
- are not further mentioned here. Codes 12 and 13 are reserved for
- possible use, but are not further mentioned here.
-
-Identifier
-
- The Identifier field is one octet, and aids in matching requests and
- replies.
-
-Length
-
- The Length field is two octets. It indicates the length of the
- packet including the Code, Identifier, Length, Authenticator and
- Attribute fields. Octets outside the range of the Length field
- should be treated as padding and should be ignored on reception. If
- the packet is shorter than the Length field indicates, it should be
- silently discarded. The minimum length is 20 and maximum length is
- 4096.
-
-Authenticator
-
- The Authenticator field is sixteen (16) octets. The most significant
- octet is transmitted first. This value is used to authenticate the
- reply from the RADIUS server, and is used in the password hiding
- algorithm.
-
-Request Authenticator
-
- In Access-Request Packets, the Authenticator value is a 16 octet
- random number, called the Request Authenticator. The value SHOULD
- be unpredictable and unique over the lifetime of a secret (the
- password shared between the client and the RADIUS server), since
- repetition of a request value in conjunction with the same secret
- would permit an attacker to reply with a previously intercepted
- response. Since it is expected that the same secret MAY be used
- to authenticate with servers in disparate geographic regions, the
- Request Authenticator field SHOULD exhibit global and temporal
- uniqueness.
-
- The Request Authenticator value in an Access-Request packet SHOULD
- also be unpredictable, lest an attacker trick a server into
- responding to a predicted future request, and then use the
- response to masquerade as that server to a future Access-Request.
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 11]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Although protocols such as RADIUS are incapable of protecting
- against theft of an authenticated session via realtime active
- wiretapping attacks, generation of unique unpredictable requests
- can protect against a wide range of active attacks against
- authentication.
-
- The NAS and RADIUS server share a secret. That shared secret
- followed by the Request Authenticator is put through a one-way MD5
- hash to create a 16 octet digest value which is xored with the
- password entered by the user, and the xored result placed in the
- User-Password attribute in the Access-Request packet. See the
- entry for User-Password in the section on Attributes for a more
- detailed description.
-
- Response Authenticator
-
- The value of the Authenticator field in Access-Accept, Access-
- Reject, and Access-Challenge packets is called the Response
- Authenticator, and contains a one-way MD5 hash calculated over a
- stream of octets consisting of: the RADIUS packet, beginning with
- the Code field, including the Identifier, the Length, the Request
- Authenticator field from the Access-Request packet, and the
- response Attributes, followed by the shared secret. That is,
- ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
- where + denotes concatenation.
-
-Administrative Note
-
- The secret (password shared between the client and the RADIUS server)
- SHOULD be at least as large and unguessable as a well-chosen
- password. It is preferred that the secret be at least 16 octets.
- This is to ensure a sufficiently large range for the secret to
- provide protection against exhaustive search attacks. A RADIUS
- server SHOULD use the source IP address of the RADIUS UDP packet to
- decide which shared secret to use, so that RADIUS requests can be
- proxied.
-
- When using a forwarding proxy, the proxy must be able to alter the
- packet as it passes through in each direction - when the proxy
- forwards the request, the proxy can add a Proxy-State Attribute, and
- when the proxy forwards a response, it removes the Proxy-State
- Attribute. Since Access-Accept and Access-Reject replies are
- authenticated on the entire packet contents, the stripping of the
- Proxy-State attribute would invalidate the signature in the packet -
- so the proxy has to re-sign it.
-
- Further details of RADIUS proxy implementation are outside the scope
- of this document.
-
-
-
-Rigney, et. al. Standards Track [Page 12]
-\f
-RFC 2138 RADIUS April 1997
-
-
-Attributes
-
- Many Attributes may have multiple instances, in such a case the order
- of Attributes of the same Type SHOULD be preserved. The order of
- Attributes of different Types is not required to be preserved.
-
- In the section below on "Attributes" where the text refers to which
- packets an attribute is allowed in, only packets with Codes 1, 2, 3
- and 11 and attributes defined in this document are covered in this
- document. A summary table is provided at the end of the "Attributes"
- section. To determine which Attributes are allowed in packets with
- codes 4 and 5 refer to the RADIUS Accounting document [9].
-
-4. Packet Types
-
- The RADIUS Packet type is determined by the Code field in the first
- octet of the Packet.
-
-4.1. Access-Request
-
- Description
-
- Access-Request packets are sent to a RADIUS server, and convey
- information used to determine whether a user is allowed access to
- a specific NAS, and any special services requested for that user.
- An implementation wishing to authenticate a user MUST transmit a
- RADIUS packet with the Code field set to 1 (Access-Request).
-
- Upon receipt of an Access-Request from a valid client, an
- appropriate reply MUST be transmitted.
-
- An Access-Request MUST contain a User-Name attribute. It SHOULD
- contain either a NAS-IP-Address attribute or NAS-Identifier
- attribute (or both, although that is not recommended). It MUST
- contain either a User-Password attribute or CHAP-Password
- attribute. It SHOULD contain a NAS-Port or NAS-Port-Type
- attribute or both unless the type of access being requested does
- not involve a port or the NAS does not distinguish among its
- ports.
-
- An Access-Request MAY contain additional attributes as a hint to
- the server, but the server is not required to honor the hint.
-
- When a User-Password is present, it is hidden using a method based
- on the RSA Message Digest Algorithm MD5 [1].
-
- A summary of the Access-Request packet format is shown below. The
- fields are transmitted from left to right.
-
-
-
-Rigney, et. al. Standards Track [Page 13]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Request Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 1 for Access-Request.
-
- Identifier
-
- The Identifier field MUST be changed whenever the content of the
- Attributes field changes, and whenever a valid reply has been
- received for a previous request. For retransmissions, the
- Identifier MUST remain unchanged.
-
- Request Authenticator
-
- The Request Authenticator value MUST be changed each time a new
- Identifier is used.
-
- Attributes
-
- The Attribute field is variable in length, and contains the list
- of Attributes that are required for the type of service, as well
- as any desired optional Attributes.
-
-4.2. Access-Accept
-
- Description
-
- Access-Accept packets are sent by the RADIUS server, and provide
- specific configuration information necessary to begin delivery of
- service to the user. If all Attribute values received in an
- Access-Request are acceptable then the RADIUS implementation MUST
- transmit a packet with the Code field set to 2 (Access-Accept).
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 14]
-\f
-RFC 2138 RADIUS April 1997
-
-
- On reception of an Access-Accept, the Identifier field is matched
- with a pending Access-Request. Additionally, the Response
- Authenticator field MUST contain the correct response for the
- pending Access-Request. Invalid packets are silently discarded.
-
- A summary of the Access-Accept packet format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 2 for Access-Accept.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Accept.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attribute field is variable in length, and contains a list of
- zero or more Attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 15]
-\f
-RFC 2138 RADIUS April 1997
-
-
-4.3. Access-Reject
-
- Description
-
- If any value of the received Attributes is not acceptable, then
- the RADIUS server MUST transmit a packet with the Code field set
- to 3 (Access-Reject). It MAY include one or more Reply-Message
- Attributes with a text message which the NAS MAY display to the
- user.
-
- A summary of the Access-Reject packet format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 3 for Access-Reject.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Reject.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attribute field is variable in length, and contains a list of
- zero or more Attributes.
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 16]
-\f
-RFC 2138 RADIUS April 1997
-
-
-4.4. Access-Challenge
-
- Description
-
- If the RADIUS server desires to send the user a challenge
- requiring a response, then the RADIUS server MUST respond to the
- Access-Request by transmitting a packet with the Code field set to
- 11 (Access-Challenge).
-
- The Attributes field MAY have one or more Reply-Message
- Attributes, and MAY have a single State Attribute, or none. No
- other Attributes are permitted in an Access-Challenge.
-
- On receipt of an Access-Challenge, the Identifier field is matched
- with a pending Access-Request. Additionally, the Response
- Authenticator field MUST contain the correct response for the
- pending Access-Request. Invalid packets are silently discarded.
-
- If the NAS does not support challenge/response, it MUST treat an
- Access-Challenge as though it had received an Access-Reject
- instead.
-
- If the NAS supports challenge/response, receipt of a valid
- Access-Challenge indicates that a new Access-Request SHOULD be
- sent. The NAS MAY display the text message, if any, to the user,
- and then prompt the user for a response. It then sends its
- original Access-Request with a new request ID and Request
- Authenticator, with the User-Password Attribute replaced by the
- user's response (encrypted), and including the State Attribute
- from the Access-Challenge, if any. Only 0 or 1 instances of the
- State Attribute can be present in an Access-Request.
-
- A NAS which supports PAP MAY forward the Reply-Message to the
- dialin client and accept a PAP response which it can use as though
- the user had entered the response. If the NAS cannot do so, it
- should treat the Access-Challenge as though it had received an
- Access-Reject instead.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 17]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Access-Challenge packet format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 11 for Access-Challenge.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Challenge.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- zero or more Attributes.
-
-5. Attributes
-
- RADIUS Attributes carry the specific authentication, authorization,
- information and configuration details for the request and reply.
-
- Some Attributes MAY be included more than once. The effect of this
- is Attribute specific, and is specified in each Attribute
- description.
-
- The end of the list of Attributes is indicated by the Length of the
- RADIUS packet.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 18]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Attribute format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- The Type field is one octet. Up-to-date values of the RADIUS Type
- field are specified in the most recent "Assigned Numbers" RFC [3].
- Values 192-223 are reserved for experimental use, values 224-240
- are reserved for implementation-specific use, and values 241-255
- are reserved and should not be used. This specification concerns
- the following values:
-
- A RADIUS server MAY ignore Attributes with an unknown Type.
-
- A RADIUS client MAY ignore Attributes with an unknown Type.
-
- 1 User-Name
- 2 User-Password
- 3 CHAP-Password
- 4 NAS-IP-Address
- 5 NAS-Port
- 6 Service-Type
- 7 Framed-Protocol
- 8 Framed-IP-Address
- 9 Framed-IP-Netmask
- 10 Framed-Routing
- 11 Filter-Id
- 12 Framed-MTU
- 13 Framed-Compression
- 14 Login-IP-Host
- 15 Login-Service
- 16 Login-TCP-Port
- 17 (unassigned)
- 18 Reply-Message
- 19 Callback-Number
- 20 Callback-Id
- 21 (unassigned)
- 22 Framed-Route
- 23 Framed-IPX-Network
- 24 State
- 25 Class
- 26 Vendor-Specific
-
-
-
-Rigney, et. al. Standards Track [Page 19]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 27 Session-Timeout
- 28 Idle-Timeout
- 29 Termination-Action
- 30 Called-Station-Id
- 31 Calling-Station-Id
- 32 NAS-Identifier
- 33 Proxy-State
- 34 Login-LAT-Service
- 35 Login-LAT-Node
- 36 Login-LAT-Group
- 37 Framed-AppleTalk-Link
- 38 Framed-AppleTalk-Network
- 39 Framed-AppleTalk-Zone
- 40-59 (reserved for accounting)
- 60 CHAP-Challenge
- 61 NAS-Port-Type
- 62 Port-Limit
- 63 Login-LAT-Port
-
- Length
-
- The Length field is one octet, and indicates the length of this
- Attribute including the Type, Length and Value fields. If an
- Attribute is received in an Access-Request but with an invalid
- Length, an Access-Reject SHOULD be transmitted. If an Attribute
- is received in an Access-Accept, Access-Reject or Access-Challenge
- packet with an invalid length, the packet MUST either be treated
- an Access-Reject or else silently discarded.
-
- Value
-
- The Value field is zero or more octets and contains information
- specific to the Attribute. The format and length of the Value
- field is determined by the Type and Length fields.
-
- Note that a "string" in RADIUS does not require termination by an
- ASCII NUL because the Attribute already has a length field.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 20]
-\f
-RFC 2138 RADIUS April 1997
-
-
- The format of the value field is one of four data types.
-
- string 0-253 octets
-
- address 32 bit value, most significant octet first.
-
- integer 32 bit value, most significant octet first.
-
- time 32 bit value, most significant octet first -- seconds
- since 00:00:00 GMT, January 1, 1970. The standard
- Attributes do not use this data type but it is presented
- here for possible use within Vendor-Specific attributes.
-
-
-5.1. User-Name
-
- Description
-
- This Attribute indicates the name of the user to be authenticated.
- It is only used in Access-Request packets.
-
- A summary of the User-Name Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 1 for User-Name.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The NAS may limit the
- maximum length of the User-Name but the ability to handle at least
- 63 octets is recommended.
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 21]
-\f
-RFC 2138 RADIUS April 1997
-
-
- The format of the username MAY be one of several forms:
-
- monolithic Consisting only of alphanumeric characters. This
- simple form might be used to locally manage a NAS.
-
- simple Consisting only of printable ASCII characters.
-
- name@fqdn SMTP address. The Fully Qualified Domain Name (with or
- without trailing dot) indicates the realm in which the
- name part applies.
-
- distinguished name
- A name in ASN.1 form used in Public Key authentication
- systems.
-
-5.2. User-Password
-
- Description
-
- This Attribute indicates the password of the user to be
- authenticated, or the user's input following an Access-Challenge.
- It is only used in Access-Request packets.
-
- On transmission, the password is hidden. The password is first
- padded at the end with nulls to a multiple of 16 octets. A one-
- way MD5 hash is calculated over a stream of octets consisting of
- the shared secret followed by the Request Authenticator. This
- value is XORed with the first 16 octet segment of the password and
- placed in the first 16 octets of the String field of the User-
- Password Attribute.
-
- If the password is longer than 16 characters, a second one-way MD5
- hash is calculated over a stream of octets consisting of the
- shared secret followed by the result of the first xor. That hash
- is XORed with the second 16 octet segment of the password and
- placed in the second 16 octets of the String field of the User-
- Password Attribute.
-
- If necessary, this operation is repeated, with each xor result
- being used along with the shared secret to generate the next hash
- to xor the next segment of the password, to no more than 128
- characters.
-
- The method is taken from the book "Network Security" by Kaufman,
- Perlman and Speciner [4] pages 109-110. A more precise
- explanation of the method follows:
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 22]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Call the shared secret S and the pseudo-random 128-bit Request
- Authenticator RA. Break the password into 16-octet chunks p1, p2,
- etc. with the last one padded at the end with nulls to a 16-octet
- boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
- intermediate values b1, b2, etc.
-
- b1 = MD5(S + RA) c(1) = p1 xor b1
- b2 = MD5(S + c(1)) c(2) = p2 xor b2
- . .
- . .
- . .
- bi = MD5(S + c(i-1)) c(i) = pi xor bi
-
- The String will contain c(1)+c(2)+...+c(i) where + denotes
- concatenation.
-
- On receipt, the process is reversed to yield the original
- password.
-
- A summary of the User-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 2 for User-Password.
-
- Length
-
- At least 18 and no larger than 130.
-
- String
-
- The String field is between 16 and 128 octets long, inclusive.
-
-5.3. CHAP-Password
-
- Description
-
- This Attribute indicates the response value provided by a PPP
- Challenge-Handshake Authentication Protocol (CHAP) user in
- response to the challenge. It is only used in Access-Request
- packets.
-
-
-
-Rigney, et. al. Standards Track [Page 23]
-\f
-RFC 2138 RADIUS April 1997
-
-
- The CHAP challenge value is found in the CHAP-Challenge Attribute
- (60) if present in the packet, otherwise in the Request
- Authenticator field.
-
- A summary of the CHAP-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | CHAP Ident | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 3 for CHAP-Password.
-
- Length
-
- 19
-
- CHAP Ident
-
- This field is one octet, and contains the CHAP Identifier from the
- user's CHAP Response.
-
- String
-
- The String field is 16 octets, and contains the CHAP Response from
- the user.
-
-5.4. NAS-IP-Address
-
- Description
-
- This Attribute indicates the identifying IP Address of the NAS
- which is requesting authentication of the user. It is only used
- in Access-Request packets. Either NAS-IP-Address or NAS-
- Identifier SHOULD be present in an Access-Request packet.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 24]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the NAS-IP-Address Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 4 for NAS-IP-Address.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets.
-
-5.5. NAS-Port
-
- Description
-
- This Attribute indicates the physical port number of the NAS which
- is authenticating the user. It is only used in Access-Request
- packets. Note that this is using "port" in its sense of a
- physical connection on the NAS, not in the sense of a TCP or UDP
- port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
- be present in an Access-Request packet, if the NAS differentiates
- among its ports.
-
- A summary of the NAS-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 25]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 5 for NAS-Port.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535.
-
-5.6. Service-Type
-
- Description
-
- This Attribute indicates the type of service the user has
- requested, or the type of service to be provided. It MAY be used
- in both Access-Request and Access-Accept packets. A NAS is not
- required to implement all of these service types, and MUST treat
- unknown or unsupported Service-Types as though an Access-Reject
- had been received instead.
-
- A summary of the Service-Type Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 6 for Service-Type.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 26]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 Login
- 2 Framed
- 3 Callback Login
- 4 Callback Framed
- 5 Outbound
- 6 Administrative
- 7 NAS Prompt
- 8 Authenticate Only
- 9 Callback NAS Prompt
-
-
- The service types are defined as follows when used in an Access-
- Accept. When used in an Access-Request, they should be considered
- to be a hint to the RADIUS server that the NAS has reason to
- believe the user would prefer the kind of service indicated, but
- the server is not required to honor the hint.
-
- Login The user should be connected to a host.
-
- Framed A Framed Protocol should be started for the
- User, such as PPP or SLIP.
-
- Callback Login The user should be disconnected and called
- back, then connected to a host.
-
- Callback Framed The user should be disconnected and called
- back, then a Framed Protocol should be started
- for the User, such as PPP or SLIP.
-
- Outbound The user should be granted access to outgoing
- devices.
-
- Administrative The user should be granted access to the
- administrative interface to the NAS from which
- privileged commands can be executed.
-
- NAS Prompt The user should be provided a command prompt
- on the NAS from which non-privileged commands
- can be executed.
-
-
-
-
-Rigney, et. al. Standards Track [Page 27]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Authenticate Only Only Authentication is requested, and no
- authorization information needs to be returned
- in the Access-Accept (typically used by proxy
- servers rather than the NAS itself).
-
- Callback NAS Prompt The user should be disconnected and called
- back, then provided a command prompt on the
- NAS from which non-privileged commands can be
- executed.
-
-5.7. Framed-Protocol
-
- Description
-
- This Attribute indicates the framing to be used for framed access.
- It MAY be used in both Access-Request and Access-Accept packets.
-
- A summary of the Framed-Protocol Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 7 for Framed-Protocol.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 PPP
- 2 SLIP
- 3 AppleTalk Remote Access Protocol (ARAP)
- 4 Gandalf proprietary SingleLink/MultiLink protocol
- 5 Xylogics proprietary IPX/SLIP
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 28]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.8. Framed-IP-Address
-
- Description
-
- This Attribute indicates the address to be configured for the
- user. It MAY be used in Access-Accept packets. It MAY be used in
- an Access-Request packet as a hint by the NAS to the server that
- it would prefer that address, but the server is not required to
- honor the hint.
-
- A summary of the Framed-IP-Address Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 8 for Framed-IP-Address.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets. The value 0xFFFFFFFF indicates
- that the NAS should allow the user to select an address (e.g.
- Negotiated). The value 0xFFFFFFFE indicates that the NAS should
- select an address for the user (e.g. Assigned from a pool of
- addresses kept by the NAS). Other valid values indicate that the
- NAS should use that value as the user's IP address.
-
-5.9. Framed-IP-Netmask
-
- Description
-
- This Attribute indicates the IP netmask to be configured for the
- user when the user is a router to a network. It MAY be used in
- Access-Accept packets. It MAY be used in an Access-Request packet
- as a hint by the NAS to the server that it would prefer that
- netmask, but the server is not required to honor the hint.
-
-
-
-
-Rigney, et. al. Standards Track [Page 29]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Framed-IP-Netmask Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 9 for Framed-IP-Netmask.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets specifying the IP netmask of the
- user.
-
-5.10. Framed-Routing
-
- Description
-
- This Attribute indicates the routing method for the user, when the
- user is a router to a network. It is only used in Access-Accept
- packets.
-
- A summary of the Framed-Routing Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 10 for Framed-Routing.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 30]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 Send routing packets
- 2 Listen for routing packets
- 3 Send and Listen
-
-5.11. Filter-Id
-
- Description
-
- This Attribute indicates the name of the filter list for this
- user. Zero or more Filter-Id attributes MAY be sent in an
- Access-Accept packet.
-
- Identifying a filter list by name allows the filter to be used on
- different NASes without regard to filter-list implementation
- details.
-
- A summary of the Filter-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 11 for Filter-Id.
-
- Length
-
- >= 3
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 31]
-\f
-RFC 2138 RADIUS April 1997
-
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable and
- MUST NOT affect operation of the protocol. It is recommended that
- the message contain displayable ASCII characters from the range 32
- through 126 decimal.
-
-5.12. Framed-MTU
-
- Description
-
- This Attribute indicates the Maximum Transmission Unit to be
- configured for the user, when it is not negotiated by some other
- means (such as PPP). It is only used in Access-Accept packets.
-
- A summary of the Framed-MTU Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 12 for Framed-MTU.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 64 to 65535.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 32]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.13. Framed-Compression
-
- Description
-
- This Attribute indicates a compression protocol to be used for the
- link. It MAY be used in Access-Accept packets. It MAY be used in
- an Access-Request packet as a hint to the server that the NAS
- would prefer to use that compression, but the server is not
- required to honor the hint.
-
- More than one compression protocol Attribute MAY be sent. It is
- the responsibility of the NAS to apply the proper compression
- protocol to appropriate link traffic.
-
- A summary of the Framed-Compression Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 13 for Framed-Compression.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 VJ TCP/IP header compression [5]
- 2 IPX header compression
-
-5.14. Login-IP-Host
-
- Description
-
- This Attribute indicates the system with which to connect the
- user, when the Login-Service Attribute is included. It MAY be
- used in Access-Accept packets. It MAY be used in an Access-
-
-
-
-Rigney, et. al. Standards Track [Page 33]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Request packet as a hint to the server that the NAS would prefer
- to use that host, but the server is not required to honor the
- hint.
-
- A summary of the Login-IP-Host Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 14 for Login-IP-Host.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets. The value 0xFFFFFFFF indicates
- that the NAS SHOULD allow the user to select an address. The
- value 0 indicates that the NAS SHOULD select a host to connect the
- user to. Other values indicate the address the NAS SHOULD connect
- the user to.
-
-5.15. Login-Service
-
- Description
-
- This Attribute indicates the service which should be used to
- connect the user to the login host. It is only used in Access-
- Accept packets.
-
- A summary of the Login-Service Attribute format is shown below. The
- fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 34]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 15 for Login-Service.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 Telnet
- 1 Rlogin
- 2 TCP Clear
- 3 PortMaster (proprietary)
- 4 LAT
-
-5.16. Login-TCP-Port
-
- Description
-
- This Attribute indicates the TCP port with which the user is to be
- connected, when the Login-Service Attribute is also present. It
- is only used in Access-Accept packets.
-
- A summary of the Login-TCP-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 16 for Login-TCP-Port.
-
-
-
-Rigney, et. al. Standards Track [Page 35]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535.
-
-5.17. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
-
-5.18. Reply-Message
-
- Description
-
- This Attribute indicates text which MAY be displayed to the user.
-
- When used in an Access-Accept, it is the success message.
-
- When used in an Access-Reject, it is the failure message. It MAY
- indicate a dialog message to prompt the user before another
- Access-Request attempt.
-
- When used in an Access-Challenge, it MAY indicate a dialog message
- to prompt the user for a response.
-
- Multiple Reply-Message's MAY be included and if any are displayed,
- they MUST be displayed in the same order as they appear in the
- packet.
-
- A summary of the Reply-Message Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 18 for Reply-Message.
-
-
-
-
-Rigney, et. al. Standards Track [Page 36]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable,
- and MUST NOT affect operation of the protocol. It is recommended
- that the message contain displayable ASCII characters from the
- range 10, 13, and 32 through 126 decimal. Mechanisms for
- extension to other character sets are beyond the scope of this
- specification.
-
-5.19. Callback-Number
-
- Description
-
- This Attribute indicates a dialing string to be used for callback.
- It MAY be used in Access-Accept packets. It MAY be used in an
- Access-Request packet as a hint to the server that a Callback
- service is desired, but the server is not required to honor the
- hint.
-
- A summary of the Callback-Number Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 19 for Callback-Number.
-
- Length
-
- >= 3
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 37]
-\f
-RFC 2138 RADIUS April 1997
-
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.20. Callback-Id
-
- Description
-
- This Attribute indicates the name of a place to be called, to be
- interpreted by the NAS. It MAY be used in Access-Accept packets.
-
- A summary of the Callback-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 20 for Callback-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.21. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 38]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.22. Framed-Route
-
- Description
-
- This Attribute provides routing information to be configured for
- the user on the NAS. It is used in the Access-Accept packet and
- can appear multiple times.
-
- A summary of the Framed-Route Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 22 for Framed-Route.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and its contents are
- implementation dependent. It is intended to be human readable and
- MUST NOT affect operation of the protocol. It is recommended that
- the message contain displayable ASCII characters from the range 32
- through 126 decimal.
-
- For IP routes, it SHOULD contain a destination prefix in dotted
- quad form optionally followed by a slash and a decimal length
- specifier stating how many high order bits of the prefix should be
- used. That is followed by a space, a gateway address in dotted
- quad form, a space, and one or more metrics separated by spaces.
- For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
- specifier may be omitted in which case it should default to 8 bits
- for class A prefixes, 16 bits for class B prefixes, and 24 bits
- for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
-
- Whenever the gateway address is specified as "0.0.0.0" the IP
- address of the user SHOULD be used as the gateway address.
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 39]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.23. Framed-IPX-Network
-
- Description
-
- This Attribute indicates the IPX Network number to be configured
- for the user. It is used in Access-Accept packets.
-
- A summary of the Framed-IPX-Network Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 23 for Framed-IPX-Network.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. The value 0xFFFFFFFE indicates
- that the NAS should select an IPX network for the user (e.g.
- assigned from a pool of one or more IPX networks kept by the NAS).
- Other values should be used as the IPX network for the link to the
- user.
-
-5.24. State
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Challenge and MUST be sent unmodified from the client
- to the server in the new Access-Request reply to that challenge,
- if any.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 40]
-\f
-RFC 2138 RADIUS April 1997
-
-
- This Attribute is available to be sent by the server to the client
- in an Access-Accept that also includes a Termination-Action
- Attribute with the value of RADIUS-Request. If the NAS performs
- the Termination-Action by sending a new Access-Request upon
- termination of the current session, it MUST include the State
- attribute unchanged in that Access-Request.
-
- In either usage, no interpretation by the client should be made.
- A packet may have only one State Attribute. Usage of the State
- Attribute is implementation dependent.
-
- A summary of the State Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 24 for State.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.25. Class
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Accept and should be sent unmodified by the client to
- the accounting server as part of the Accounting-Request packet if
- accounting is supported. No interpretation by the client should
- be made.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 41]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Class Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 25 for Class.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.26. Vendor-Specific
-
- Description
-
- This Attribute is available to allow vendors to support their own
- extended Attributes not suitable for general usage. It MUST not
- affect the operation of the RADIUS protocol.
-
- Servers not equipped to interpret the vendor-specific information
- sent by a client MUST ignore it (although it may be reported).
- Clients which do not receive desired vendor-specific information
- SHOULD make an attempt to operate without it, although they may do
- so (and report they are doing so) in a degraded mode.
-
- A summary of the Vendor-Specific Attribute format is shown below.
- The fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 42]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Vendor-Id
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Vendor-Id (cont) | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 26 for Vendor-Specific.
-
- Length
-
- >= 7
-
- Vendor-Id
-
- The high-order octet is 0 and the low-order 3 octets are the SMI
- Network Management Private Enterprise Code of the Vendor in
- network byte order, as defined in the Assigned Numbers RFC [3].
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
- It SHOULD be encoded as a sequence of vendor type / vendor length
- / value fields, as follows. The Attribute-Specific field is
- dependent on the vendor's definition of that attribute. An
- example encoding of the Vendor-Specific attribute using this
- method follows:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Vendor-Id
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Vendor-Id (cont) | Vendor type | Vendor length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attribute-Specific...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 43]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.27. Session-Timeout
-
- Description
-
- This Attribute sets the maximum number of seconds of service to be
- provided to the user before termination of the session or prompt.
- This Attribute is available to be sent by the server to the client
- in an Access-Accept or Access-Challenge.
-
- A summary of the Session-Timeout Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 27 for Session-Timeout.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of seconds this user should be allowed to
- remain connected by the NAS.
-
-5.28. Idle-Timeout
-
- Description
-
- This Attribute sets the maximum number of consecutive seconds of
- idle connection allowed to the user before termination of the
- session or prompt. This Attribute is available to be sent by the
- server to the client in an Access-Accept or Access-Challenge.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 44]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Idle-Timeout Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 28 for Idle-Timeout.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of consecutive seconds of idle time this user
- should be permitted before being disconnected by the NAS.
-
-5.29. Termination-Action
-
- Description
-
- This Attribute indicates what action the NAS should take when the
- specified service is completed. It is only used in Access-Accept
- packets.
-
- A summary of the Termination-Action Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 29 for Termination-Action.
-
-
-
-
-Rigney, et. al. Standards Track [Page 45]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 Default
- 1 RADIUS-Request
-
- If the Value is set to RADIUS-Request, upon termination of the
- specified service the NAS MAY send a new Access-Request to the
- RADIUS server, including the State attribute if any.
-
-5.30. Called-Station-Id
-
- Description
-
- This Attribute allows the NAS to send in the Access-Request packet
- the phone number that the user called, using Dialed Number
- Identification (DNIS) or similar technology. Note that this may be
- different from the phone number the call comes in on. It is only
- used in Access-Request packets.
-
- A summary of the Called-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 30 for Called-Station-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user's call came in on.
-
-
-
-
-Rigney, et. al. Standards Track [Page 46]
-\f
-RFC 2138 RADIUS April 1997
-
-
- The actual format of the information is site or application
- specific. Printable ASCII is recommended, but a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.31. Calling-Station-Id
-
- Description
-
- This Attribute allows the NAS to send in the Access-Request packet
- the phone number that the call came from, using Automatic Number
- Identification (ANI) or similar technology. It is only used in
- Access-Request packets.
-
- A summary of the Calling-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 31 for Calling-Station-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user placed the call from.
-
- The actual format of the information is site or application
- specific. Printable ASCII is recommended, but a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 47]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.32. NAS-Identifier
-
- Description
-
- This Attribute contains a string identifying the NAS originating
- the Access-Request. It is only used in Access-Request packets.
- Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
- Access-Request packet.
-
- A summary of the NAS-Identifier Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 32 for NAS-Identifier.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and should be unique to
- the NAS within the scope of the RADIUS server. For example, a
- fully qualified domain name would be suitable as a NAS-Identifier.
-
- The actual format of the information is site or application
- specific, and a robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.33. Proxy-State
-
- Description
-
- This Attribute is available to be sent by a proxy server to
- another server when forwarding an Access-Request and MUST be
- returned unmodified in the Access-Accept, Access-Reject or
- Access-Challenge. This attribute should be removed by the proxy
- server before the response is forwarded to the NAS.
-
-
-
-Rigney, et. al. Standards Track [Page 48]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Usage of the Proxy-State Attribute is implementation dependent. A
- description of its function is outside the scope of this
- specification.
-
- A summary of the Proxy-State Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 33 for Proxy-State.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.34. Login-LAT-Service
-
- Description
-
- This Attribute indicates the system with which the user is to be
- connected by LAT. It MAY be used in Access-Accept packets, but
- only when LAT is specified as the Login-Service. It MAY be used
- in an Access-Request packet as a hint to the server, but the
- server is not required to honor the hint.
-
- Administrators use the service attribute when dealing with
- clustered systems, such as a VAX or Alpha cluster. In such an
- environment several different time sharing hosts share the same
- resources (disks, printers, etc.), and administrators often
- configure each to offer access (service) to each of the shared
- resources. In this case, each host in the cluster advertises its
- services through LAT broadcasts.
-
-
-
-
-Rigney, et. al. Standards Track [Page 49]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Sophisticated users often know which service providers (machines)
- are faster and tend to use a node name when initiating a LAT
- connection. Alternately, some administrators want particular
- users to use certain machines as a primitive form of load
- balancing (although LAT knows how to do load balancing itself).
-
- A summary of the Login-LAT-Service Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
- Type
-
- 34 for Login-LAT-Service.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT service to use. The LAT Architecture allows this
- string to contain $ (dollar), - (hyphen), . (period), _
- (underscore), numerics, upper and lower case alphabetics, and the
- ISO Latin-1 character set extension [6]. All LAT string
- comparisons are case insensitive.
-
-5.35. Login-LAT-Node
-
- Description
-
- This Attribute indicates the Node with which the user is to be
- automatically connected by LAT. It MAY be used in Access-Accept
- packets, but only when LAT is specified as the Login-Service. It
- MAY be used in an Access-Request packet as a hint to the server,
- but the server is not required to honor the hint.
-
- A summary of the Login-LAT-Node Attribute format is shown below. The
- fields are transmitted from left to right.
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 50]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 35 for Login-LAT-Node.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT Node to connect the user to. The LAT Architecture
- allows this string to contain $ (dollar), - (hyphen), . (period),
- _ (underscore), numerics, upper and lower case alphabetics, and
- the ISO Latin-1 character set extension. All LAT string
- comparisons are case insensitive.
-
-5.36. Login-LAT-Group
-
- Description
-
- This Attribute contains a string identifying the LAT group codes
- which this user is authorized to use. It MAY be used in Access-
- Accept packets, but only when LAT is specified as the Login-
- Service. It MAY be used in an Access-Request packet as a hint to
- the server, but the server is not required to honor the hint.
-
- LAT supports 256 different group codes, which LAT uses as a form
- of access rights. LAT encodes the group codes as a 256 bit
- bitmap.
-
- Administrators can assign one or more of the group code bits at
- the LAT service provider; it will only accept LAT connections that
- have these group codes set in the bit map. The administrators
- assign a bitmap of authorized group codes to each user; LAT gets
- these from the operating system, and uses these in its requests to
- the service providers.
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 51]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Login-LAT-Group Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 36 for Login-LAT-Group.
-
- Length
-
- 34
-
- String
-
- The String field is a 32 octet bit map, most significant octet
- first. A robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.37. Framed-AppleTalk-Link
-
- Description
-
- This Attribute indicates the AppleTalk network number which should
- be used for the serial link to the user, which is another
- AppleTalk router. It is only used in Access-Accept packets. It
- is never used when the user is not another router.
-
- A summary of the Framed-AppleTalk-Link Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 52]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Type
-
- 37 for Framed-AppleTalk-Link.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535. The special value of 0 indicates
- that this is an unnumbered serial link. A value of 1-65535 means
- that the serial line between the NAS and the user should be
- assigned that value as an AppleTalk network number.
-
-5.38. Framed-AppleTalk-Network
-
- Description
-
- This Attribute indicates the AppleTalk Network number which the
- NAS should probe to allocate an AppleTalk node for the user. It
- is only used in Access-Accept packets. It is never used when the
- user is another router. Multiple instances of this Attribute
- indicate that the NAS may probe using any of the network numbers
- specified.
-
- A summary of the Framed-AppleTalk-Network Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 38 for Framed-AppleTalk-Network.
-
- Length
-
- 6
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 53]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535. The special value 0 indicates that
- the NAS should assign a network for the user, using its default
- cable range. A value between 1 and 65535 (inclusive) indicates
- the AppleTalk Network the NAS should probe to find an address for
- the user.
-
-5.39. Framed-AppleTalk-Zone
-
- Description
-
- This Attribute indicates the AppleTalk Default Zone to be used for
- this user. It is only used in Access-Accept packets. Multiple
- instances of this attribute in the same packet are not allowed.
-
- A summary of the Framed-AppleTalk-Zone Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 39 for Framed-AppleTalk-Zone.
-
- Length
-
- >= 3
-
- String
-
- The name of the Default AppleTalk Zone to be used for this user.
- A robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 54]
-\f
-RFC 2138 RADIUS April 1997
-
-
-5.40. CHAP-Challenge
-
- Description
-
- This Attribute contains the CHAP Challenge sent by the NAS to a
- PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
- is only used in Access-Request packets.
-
- If the CHAP challenge value is 16 octets long it MAY be placed in
- the Request Authenticator field instead of using this attribute.
-
- A summary of the CHAP-Challenge Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 60 for CHAP-Challenge.
-
- Length
-
- >= 7
-
- String
-
- The String field contains the CHAP Challenge.
-
-5.41. NAS-Port-Type
-
- Description
-
- This Attribute indicates the type of the physical port of the NAS
- which is authenticating the user. It can be used instead of or in
- addition to the NAS-Port (5) attribute. It is only used in
- Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
- both SHOULD be present in an Access-Request packet, if the NAS
- differentiates among its ports.
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 55]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the NAS-Port-Type Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 61 for NAS-Port-Type.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. "Virtual" refers to a connection
- to the NAS via some transport protocol, instead of through a
- physical port. For example, if a user telnetted into a NAS to
- authenticate himself as an Outbound-User, the Access-Request might
- include NAS-Port-Type = Virtual as a hint to the RADIUS server
- that the user was not on a physical port.
-
- 0 Async
- 1 Sync
- 2 ISDN Sync
- 3 ISDN Async V.120
- 4 ISDN Async V.110
- 5 Virtual
-
-5.42. Port-Limit
-
- Description
-
- This Attribute sets the maximum number of ports to be provided to
- the user by the NAS. This Attribute MAY be sent by the server to
- the client in an Access-Accept packet. It is intended for use in
- conjunction with Multilink PPP [7] or similar uses. It MAY also
- be sent by the NAS to the server as a hint that that many ports
- are desired for use, but the server is not required to honor the
- hint.
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 56]
-\f
-RFC 2138 RADIUS April 1997
-
-
- A summary of the Port-Limit Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 62 for Port-Limit.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of ports this user should be allowed to connect
- to on the NAS.
-
-5.43. Login-LAT-Port
-
- Description
-
- This Attribute indicates the Port with which the user is to be
- connected by LAT. It MAY be used in Access-Accept packets, but
- only when LAT is specified as the Login-Service. It MAY be used
- in an Access-Request packet as a hint to the server, but the
- server is not required to honor the hint.
-
- A summary of the Login-LAT-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 63 for Login-LAT-Port.
-
-
-
-
-Rigney, et. al. Standards Track [Page 57]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT port to use. The LAT Architecture allows this string
- to contain $ (dollar), - (hyphen), . (period), _ (underscore),
- numerics, upper and lower case alphabetics, and the ISO Latin-1
- character set extension. All LAT string comparisons are case
- insensitive.
-
-5.44. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in which kinds of packets, and in what quantity.
-
- Request Accept Reject Challenge # Attribute
- 1 0 0 0 1 User-Name
- 0-1 0 0 0 2 User-Password [Note 1]
- 0-1 0 0 0 3 CHAP-Password [Note 1]
- 0-1 0 0 0 4 NAS-IP-Address
- 0-1 0 0 0 5 NAS-Port
- 0-1 0-1 0 0 6 Service-Type
- 0-1 0-1 0 0 7 Framed-Protocol
- 0-1 0-1 0 0 8 Framed-IP-Address
- 0-1 0-1 0 0 9 Framed-IP-Netmask
- 0 0-1 0 0 10 Framed-Routing
- 0 0+ 0 0 11 Filter-Id
- 0 0-1 0 0 12 Framed-MTU
- 0+ 0+ 0 0 13 Framed-Compression
- 0+ 0+ 0 0 14 Login-IP-Host
- 0 0-1 0 0 15 Login-Service
- 0 0-1 0 0 16 Login-TCP-Port
- 0 0+ 0+ 0+ 18 Reply-Message
- 0-1 0-1 0 0 19 Callback-Number
- 0 0-1 0 0 20 Callback-Id
- 0 0+ 0 0 22 Framed-Route
- 0 0-1 0 0 23 Framed-IPX-Network
- 0-1 0-1 0 0-1 24 State
- 0 0+ 0 0 25 Class
- 0+ 0+ 0 0+ 26 Vendor-Specific
- 0 0-1 0 0-1 27 Session-Timeout
- 0 0-1 0 0-1 28 Idle-Timeout
- 0 0-1 0 0 29 Termination-Action
- 0-1 0 0 0 30 Called-Station-Id
- 0-1 0 0 0 31 Calling-Station-Id
-
-
-
-Rigney, et. al. Standards Track [Page 58]
-\f
-RFC 2138 RADIUS April 1997
-
-
- 0-1 0 0 0 32 NAS-Identifier
- 0+ 0+ 0+ 0+ 33 Proxy-State
- 0-1 0-1 0 0 34 Login-LAT-Service
- 0-1 0-1 0 0 35 Login-LAT-Node
- 0-1 0-1 0 0 36 Login-LAT-Group
- 0 0-1 0 0 37 Framed-AppleTalk-Link
- 0 0+ 0 0 38 Framed-AppleTalk-Network
- 0 0-1 0 0 39 Framed-AppleTalk-Zone
- 0-1 0 0 0 60 CHAP-Challenge
- 0-1 0 0 0 61 NAS-Port-Type
- 0-1 0-1 0 0 62 Port-Limit
- 0-1 0-1 0 0 63 Login-LAT-Port
-
-
- Request Accept Reject Challenge # Attribute
-
-
- [Note 1] An Access-Request MUST contain either a User-Password or a
- CHAP-Password, and MUST NOT contain both.
-
- The following table defines the meaning of the above table entries.
-
- 0 This attribute MUST NOT be present in packet.
- 0+ Zero or more instances of this attribute MAY be present in packet.
- 0-1 Zero or one instance of this attribute MAY be present in packet.
- 1 Exactly one instance of this attribute MUST be present in packet.
-
-6. Examples
-
- A few examples are presented to illustrate the flow of packets and
- use of typical attributes. These examples are not intended to be
- exhaustive, many others are possible.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 59]
-\f
-RFC 2138 RADIUS April 1997
-
-
-6.1. User Telnet to Specified Host
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named nemo logging in on port 3.
-
- Code = 1 (Access-Request)
- ID = 0
- Length = 56
- Request Authenticator = {16 octet random number}
- Attributes:
- User-Name = "nemo"
- User-Password = {16 octets of Password padded at end with nulls,
- XORed with MD5(shared secret|Request Authenticator)}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 3
-
- The RADIUS server authenticates nemo, and sends an Access-Accept UDP
- packet to the NAS telling it to telnet nemo to host 192.168.1.3.
-
- Code = 2 (Access-Accept)
- ID = 0 (same as in Access-Request)
- Length = 38
- Response Authenticator = {16-octet MD-5 checksum of the code (2),
- id (0), Length (38), the Request Authenticator from
- above, the attributes in this reply, and the shared
- secret}
- Attributes:
- Service-Type = Login-User
- Login-Service = Telnet
- Login-Host = 192.168.1.3
-
-6.2. Framed User Authenticating with CHAP
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named flopsy logging in on port 20 with PPP,
- authenticating using CHAP. The NAS sends along the Service-Type and
- Framed-Protocol attributes as a hint to the RADIUS server that this
- user is looking for PPP, although the NAS is not required to do so.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 60]
-\f
-RFC 2138 RADIUS April 1997
-
-
- Code = 1 (Access-Request)
- ID = 1
- Length = 71
- Request Authenticator = {16 octet random number also used as
- CHAP challenge}
- Attributes:
- User-Name = "flopsy"
- CHAP-Password = {1 octet CHAP ID followed by 16 octet
- CHAP response}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 20
- Service-Type = Framed-User
- Framed-Protocol = PPP
-
- The RADIUS server authenticates flopsy, and sends an Access-Accept
- UDP packet to the NAS telling it to start PPP service and assign an
- address for the user out of its dynamic address pool.
-
- Code = 2 (Access-Accept)
- ID = 1 (same as in Access-Request)
- Length = 56
- Response Authenticator = {16-octet MD-5 checksum of the code (2),
- id (1), Length (56), the Request Authenticator from
- above, the attributes in this reply, and the shared
- secret}
- Attributes:
- Service-Type = Framed-User
- Framed-Protocol = PPP
- Framed-IP-Address = 255.255.255.254
- Framed-Routing = None
- Framed-Compression = 1 (VJ TCP/IP Header Compression)
- Framed-MTU = 1500
-
-6.3. User with Challenge-Response card
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named mopsy logging in on port 7.
-
- Code = 1 (Access-Request)
- ID = 2
- Length = 57
- Request Authenticator = {16 octet random number}
- Attributes:
- User-Name = "mopsy"
- User-Password = {16 octets of Password padded at end with nulls,
- XORed with MD5(shared secret|Request Authenticator)}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 7
-
-
-
-Rigney, et. al. Standards Track [Page 61]
-\f
-RFC 2138 RADIUS April 1997
-
-
- The RADIUS server decides to challenge mopsy, sending back a
- challenge string and looking for a response. The RADIUS server
- therefore and sends an Access-Challenge UDP packet to the NAS.
-
- Code = 11 (Access-Challenge}
- ID = 2 (same as in Access-Request)
- Length = 78
- Response Authenticator = {16-octet MD-5 checksum of the code (11),
- id (2), length (78), the Request Authenticator from
- above, the attributes in this reply, and the shared
- secret}
- Attributes:
- Reply-Message = "Challenge 32769430. Enter response at prompt."
- State = {Magic Cookie to be returned along with user's response;
- in this example 8 octets of data}
-
- The user enters his response, and the NAS send a new Access-Request
- with that response, and includes the State Attribute.
-
- Code = 1 (Access-Request)
- ID = 3 (Note that this changes)
- Length = 67
- Request Authenticator = {NEW 16 octet random number}
- Attributes:
- User-Name = "mopsy"
- User-Password = {16 octets of Response padded at end with
- nulls, XORed with MD5 checksum of shared secret
- plus above Request Authenticator}
- NAS-IP-Address = 192.168.1.16
- NAS-Port = 7
- State = {Magic Cookie from Access-Challenge packet, unchanged}
-
- The Response was incorrect, so the RADIUS server tells the NAS to
- reject the login attempt.
-
- Code = 3 (Access-Reject)
- ID = 3 (same as in Access-Request)
- Length = 20
- Response Authenticator = {16-octet MD-5 checksum of the code (3),
- id (3), length(20), the Request Authenticator from
- above, the attributes in this reply if any, and the
- shared secret}
- Attributes:
- (none, although a Reply-Message could be sent)
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 62]
-\f
-RFC 2138 RADIUS April 1997
-
-
-Security Considerations
-
- Security issues are the primary topic of this document.
-
- In practice, within or associated with each RADIUS server, there is a
- database which associates "user" names with authentication
- information ("secrets"). It is not anticipated that a particular
- named user would be authenticated by multiple methods. This would
- make the user vulnerable to attacks which negotiate the least secure
- method from among a set. Instead, for each named user there should
- be an indication of exactly one method used to authenticate that user
- name. If a user needs to make use of different authentication
- methods under different circumstances, then distinct user names
- SHOULD be employed, each of which identifies exactly one
- authentication method.
-
- Passwords and other secrets should be stored at the respective ends
- such that access to them is as limited as possible. Ideally, the
- secrets should only be accessible to the process requiring access in
- order to perform the authentication.
-
- The secrets should be distributed with a mechanism that limits the
- number of entities that handle (and thus gain knowledge of) the
- secret. Ideally, no unauthorized person should ever gain knowledge
- of the secrets. It is possible to achieve this with SNMP Security
- Protocols [8], but such a mechanism is outside the scope of this
- specification.
-
- Other distribution methods are currently undergoing research and
- experimentation. The SNMP Security document [8] also has an
- excellent overview of threats to network protocols.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 63]
-\f
-RFC 2138 RADIUS April 1997
-
-
-References
-
- [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
- RFC 1321, MIT Laboratory for Computer Science, RSA Data
- Security Inc., April 1992.
-
- [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- USC/Information Sciences Institute, August 1980.
-
- [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, USC/Information Sciences Institute, October 1994.
-
- [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
- Private Communications in a Public World", Prentice Hall, March
- 1995, ISBN 0-13-061466-1.
-
- [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
- links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
-
- [6] ISO 8859. International Standard -- Information Processing --
- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
- Alphabet No. 1, ISO 8859-1:1987.
- <URL:http://www.iso.ch/cate/d16338.html>
-
- [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
- Multilink Protocol (MP)", RFC 1717, University of California
- Berkeley, Lloyd Internetworking, Newbridge Networks
- Corporation, November 1994.
-
- [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
- Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
- LAN Systems, Inc., MIT Laboratory for Computer Science, July
- 1992.
-
- [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
-
-Acknowledgments
-
- RADIUS was originally developed by Livingston Enterprises for their
- PortMaster series of Network Access Servers.
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 64]
-\f
-RFC 2138 RADIUS April 1997
-
-
-Chair's Address
-
- The working group can be contacted via the current chair:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
-Authors' Addresses
-
- Questions about this memo can also be directed to:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
- Allan C. Rubens
- Merit Network, Inc.
- 4251 Plymouth Road
- Ann Arbor, Michigan 48105-2785
-
- EMail: acr@merit.edu
-
- William Allen Simpson
- Daydreamer
- Computer Systems Consulting Services
- 1384 Fontaine
- Madison Heights, Michigan 48071
-
- EMail: wsimpson@greendragon.com
-
- Steve Willens
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- EMail: steve@livingston.com
-
-
-
-
-
-
-Rigney, et. al. Standards Track [Page 65]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Rigney
-Request for Comments: 2139 Livingston
-Obsoletes: 2059 April 1997
-Category: Informational
-
-
- RADIUS Accounting
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- This document describes a protocol for carrying accounting
- information between a Network Access Server and a shared Accounting
- Server.
-
-Implementation Note
-
- This memo documents the RADIUS Accounting protocol. There has been
- some confusion in the assignment of port numbers for this protocol.
- The early deployment of RADIUS Accounting was done using the
- erroneously chosen port number 1646, which conflicts with the "sa-
- msg-port" service. The officially assigned port number for RADIUS
- Accounting is 1813.
-
-Table of Contents
-
- 1. Introduction .......................................... 2
- 1.1 Specification of Requirements ................... 3
- 1.2 Terminology ..................................... 3
- 2. Operation ............................................. 4
- 3. Packet Format ......................................... 5
- 4. Packet Types .......................................... 7
- 4.1 Accounting-Request .............................. 7
- 4.2 Accounting-Response ............................. 8
- 5. Attributes ............................................ 10
- 5.1 Acct-Status-Type ................................ 11
- 5.2 Acct-Delay-Time ................................. 12
- 5.3 Acct-Input-Octets ............................... 13
- 5.4 Acct-Output-Octets .............................. 14
- 5.5 Acct-Session-Id ................................. 14
- 5.6 Acct-Authentic .................................. 15
- 5.7 Acct-Session-Time ............................... 16
- 5.8 Acct-Input-Packets .............................. 16
-
-
-
-Rigney Informational [Page 1]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- 5.9 Acct-Output-Packets ............................. 17
- 5.10 Acct-Terminate-Cause ............................ 18
- 5.11 Acct-Multi-Session-Id ........................... 20
- 5.12 Acct-Link-Count ................................. 21
- 5.13 Table of Attributes ............................. 22
- Security Considerations ...................................... 24
- References ................................................... 24
- Acknowledgements ............................................. 24
- Chair's Address .............................................. 24
- Author's Address ............................................. 25
-
-1. Introduction
-
- Managing dispersed serial line and modem pools for large numbers of
- users can create the need for significant administrative support.
- Since modem pools are by definition a link to the outside world, they
- require careful attention to security, authorization and accounting.
- This can be best achieved by managing a single "database" of users,
- which allows for authentication (verifying user name and password) as
- well as configuration information detailing the type of service to
- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
-
- The RADIUS (Remote Authentication Dial In User Service) document [4]
- specifies the RADIUS protocol used for Authentication and
- Authorization. This memo extends the use of the RADIUS protocol to
- cover delivery of accounting information from the Network Access
- Server (NAS) to a RADIUS accounting server.
-
- Key features of RADIUS Accounting are:
-
- Client/Server Model
-
- A Network Access Server (NAS) operates as a client of the
- RADIUS accounting server. The client is responsible for
- passing user accounting information to a designated RADIUS
- accounting server.
-
- The RADIUS accounting server is responsible for receiving the
- accounting request and returning a response to the client
- indicating that it has successfully received the request.
-
- The RADIUS accounting server can act as a proxy client to other
- kinds of accounting servers.
-
-
-
-
-
-
-
-
-Rigney Informational [Page 2]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Network Security
-
- Transactions between the client and RADIUS accounting server
- are authenticated through the use of a shared secret, which is
- never sent over the network.
-
- Extensible Protocol
-
- All transactions are comprised of variable length Attribute-
- Length-Value 3-tuples. New attribute values can be added
- without disturbing existing implementations of the protocol.
-
-1.1. Specification of Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. These words are often capitalized.
-
- MUST This word, or the adjective "required", means that the
- definition is an absolute requirement of the specification.
-
- MUST NOT This phrase means that the definition is an absolute
- prohibition of the specification.
-
- SHOULD This word, or the adjective "recommended", means that there
- may exist valid reasons in particular circumstances to
- ignore this item, but the full implications must be
- understood and carefully weighed before choosing a
- different course.
-
- MAY This word, or the adjective "optional", means that this
- item is one of an allowed set of alternatives. An
- implementation which does not include this option MUST be
- prepared to interoperate with another implementation which
- does include the option.
-
-1.2. Terminology
-
- This document uses the following terms:
-
- service The NAS provides a service to the dial-in user, such as PPP
- or Telnet.
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 3]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- session Each service provided by the NAS to a dial-in user
- constitutes a session, with the beginning of the session
- defined as the point where service is first provided and
- the end of the session defined as the point where service
- is ended. A user may have multiple sessions in parallel or
- series if the NAS supports that, with each session
- generating a separate start and stop accounting record with
- its own Acct-Session-Id.
-
- silently discard
- This means the implementation discards the packet without
- further processing. The implementation SHOULD provide the
- capability of logging the error, including the contents of
- the silently discarded packet, and SHOULD record the event
- in a statistics counter.
-
-2. Operation
-
- When a client is configured to use RADIUS Accounting, at the start of
- service delivery it will generate an Accounting Start packet
- describing the type of service being delivered and the user it is
- being delivered to, and will send that to the RADIUS Accounting
- server, which will send back an acknowledgement that the packet has
- been received. At the end of service delivery the client will
- generate an Accounting Stop packet describing the type of service
- that was delivered and optionally statistics such as elapsed time,
- input and output octets, or input and output packets. It will send
- that to the RADIUS Accounting server, which will send back an
- acknowledgement that the packet has been received.
-
- The Accounting-Request (whether for Start or Stop) is submitted to
- the RADIUS accounting server via the network. It is recommended that
- the client continue attempting to send the Accounting-Request packet
- until it receives an acknowledgement, using some form of backoff. If
- no response is returned within a length of time, the request is re-
- sent a number of times. The client can also forward requests to an
- alternate server or servers in the event that the primary server is
- down or unreachable. An alternate server can be used either after a
- number of tries to the primary server fail, or in a round-robin
- fashion. Retry and fallback algorithms are the topic of current
- research and are not specified in detail in this document.
-
- The RADIUS accounting server MAY make requests of other servers in
- order to satisfy the request, in which case it acts as a client.
-
- If the RADIUS accounting server is unable to successfully record the
- accounting packet it MUST NOT send an Accounting-Response
- acknowledgment to the client.
-
-
-
-Rigney Informational [Page 4]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-3. Packet Format
-
- Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
- field [1], where the UDP Destination Port field indicates 1813
- (decimal).
-
- When a reply is generated, the source and destination ports are
- reversed.
-
- This memo documents the RADIUS Accounting protocol. There has been
- some confusion in the assignment of port numbers for this protocol.
- The early deployment of RADIUS Accounting was done using the
- erroneously chosen port number 1646, which conflicts with the "sa-
- msg-port" service. The officially assigned port number for RADIUS
- Accounting is 1813.
-
- A summary of the RADIUS data format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Code | Identifier | Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-| Authenticator |
-| |
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Attributes ...
-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-Code
-
- The Code field is one octet, and identifies the type of RADIUS
- packet. When a packet is received with an invalid Code field, it is
- silently discarded.
-
- RADIUS Accounting Codes (decimal) are assigned as follows:
-
- 4 Accounting-Request
- 5 Accounting-Response
-
-Identifier
-
- The Identifier field is one octet, and aids in matching requests and
- replies.
-
-
-
-Rigney Informational [Page 5]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-Length
-
- The Length field is two octets. It indicates the length of the
- packet including the Code, Identifier, Length, Authenticator and
- Attribute fields. Octets outside the range of the Length field
- should be treated as padding and should be ignored on reception. If
- the packet is shorter than the Length field indicates, it should be
- silently discarded. The minimum length is 20 and maximum length is
- 4096.
-
-Authenticator
-
- The Authenticator field is sixteen (16) octets. The most significant
- octet is transmitted first. This value is used to authenticate the
- messages between the client and RADIUS accounting server.
-
-Request Authenticator
-
- In Accounting-Request Packets, the Authenticator value is a 16 octet
- MD5 [3] checksum, called the Request Authenticator.
-
- The NAS and RADIUS accounting server share a secret. The Request
- Authenticator field in Accounting-Request packets contains a one- way
- MD5 hash calculated over a stream of octets consisting of the Code +
- Identifier + Length + 16 zero octets + request attributes + shared
- secret (where + indicates concatenation). The 16 octet MD5 hash
- value is stored in the Authenticator field of the Accounting-Request
- packet.
-
- Note that the Request Authenticator of an Accounting-Request can
- not be done the same way as the Request Authenticator of a RADIUS
- Access-Request, because there is no User-Password attribute in an
- Accounting-Request.
-
-Response Authenticator
-
- The Authenticator field in an Accounting-Response packet is called
- the Response Authenticator, and contains a one-way MD5 hash
- calculated over a stream of octets consisting of the Accounting-
- Response Code, Identifier, Length, the Request Authenticator field
- from the Accounting-Request packet being replied to, and the response
- attributes if any, followed by the shared secret. The resulting 16
- octet MD5 hash value is stored in the Authenticator field of the
- Accounting-Response packet.
-
-
-
-
-
-
-
-Rigney Informational [Page 6]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-Attributes
-
- Attributes may have multiple instances, in such a case the order of
- attributes of the same type SHOULD be preserved. The order of
- attributes of different types is not required to be preserved.
-
-4. Packet Types
-
- The RADIUS packet type is determined by the Code field in the first
- octet of the packet.
-
-4.1. Accounting-Request
-
- Description
-
- Accounting-Request packets are sent from a client (typically a
- Network Access Server or its proxy) to a RADIUS accounting server,
- and convey information used to provide accounting for a service
- provided to a user. The client transmits a RADIUS packet with the
- Code field set to 4 (Accounting-Request).
-
- Upon receipt of an Accounting-Request, the server MUST transmit an
- Accounting-Response reply if it successfully records the
- accounting packet, and MUST NOT transmit any reply if it fails to
- record the accounting packet.
-
- Any attribute valid in a RADIUS Access-Request or Access-Accept
- packet is valid in a RADIUS Accounting-Request packet, except that
- the following attributes MUST NOT be present in an Accounting-
- Request: User-Password, CHAP-Password, Reply-Message, State.
- Either NAS-IP-Address or NAS-Identifier MUST be present in a
- RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
- Port-Type attribute or both unless the service does not involve a
- port or the NAS does not distinguish among its ports.
-
- A summary of the Accounting-Request packet format is shown below.
- The fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 7]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Request Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 4 for Accounting-Request.
-
- Identifier
-
- The Identifier field MUST be changed whenever the content of the
- Attributes field changes, and whenever a valid reply has been
- received for a previous request. For retransmissions where the
- contents are identical, the Identifier MUST remain unchanged.
-
- Note that if Acct-Delay-Time is included in the attributes of an
- Accounting-Request then the Acct-Delay-Time value will be updated
- when the packet is retransmitted, changing the content of the
- Attributes field and requiring a new Identifier and Request
- Authenticator.
-
- Request Authenticator
-
- The Request Authenticator of an Accounting-Request contains a 16-
- octet MD5 hash value calculated according to the method described
- in "Request Authenticator" above.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- Attributes.
-
-4.2. Accounting-Response
-
- Description
-
- Accounting-Response packets are sent by the RADIUS accounting
- server to the client to acknowledge that the Accounting-Request
- has been received and recorded successfully. If the Accounting-
-
-
-
-Rigney Informational [Page 8]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Request was recorded successfully then the RADIUS accounting
- server MUST transmit a packet with the Code field set to 5
- (Accounting-Response). On reception of an Accounting-Response by
- the client, the Identifier field is matched with a pending
- Accounting-Request. Invalid packets are silently discarded.
-
- A RADIUS Accounting-Response is not required to have any
- attributes in it.
-
- A summary of the Accounting-Response packet format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 5 for Accounting-Response.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Accounting-Request which caused this Accounting-Response.
-
- Response Authenticator
-
- The Response Authenticator of an Accounting-Response contains a
- 16-octet MD5 hash value calculated according to the method
- described in "Response Authenticator" above.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- zero or more Attributes.
-
-
-
-
-
-
-
-Rigney Informational [Page 9]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-5. Attributes
-
- RADIUS Attributes carry the specific authentication, authorization
- and accounting details for the request and response.
-
- Some attributes MAY be included more than once. The effect of this
- is attribute specific, and is specified in each attribute
- description.
-
- The end of the list of attributes is indicated by the Length of the
- RADIUS packet.
-
- A summary of the attribute format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- The Type field is one octet. Up-to-date values of the RADIUS Type
- field are specified in the most recent "Assigned Numbers" RFC [2].
- Values 192-223 are reserved for experimental use, values 224-240
- are reserved for implementation-specific use, and values 241-255
- are reserved and should not be used. This specification concerns
- the following values:
-
- 1-39 (refer to RADIUS document [4])
- 40 Acct-Status-Type
- 41 Acct-Delay-Time
- 42 Acct-Input-Octets
- 43 Acct-Output-Octets
- 44 Acct-Session-Id
- 45 Acct-Authentic
- 46 Acct-Session-Time
- 47 Acct-Input-Packets
- 48 Acct-Output-Packets
- 49 Acct-Terminate-Cause
- 50 Acct-Multi-Session-Id
- 51 Acct-Link-Count
- 60+ (refer to RADIUS document [4])
-
-
-
-
-
-
-
-Rigney Informational [Page 10]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Length
-
- The Length field is one octet, and indicates the length of this
- attribute including the Type, Length and Value fields. If an
- attribute is received in an Accounting-Request with an invalid
- Length, the entire request should be silently discarded.
-
- Value
-
- The Value field is zero or more octets and contains information
- specific to the attribute. The format and length of the Value
- field is determined by the Type and Length fields.
-
- The format of the value field is one of four data types.
-
- string 0-253 octets
-
- address 32 bit value, most significant octet first.
-
- integer 32 bit value, most significant octet first.
-
- time 32 bit value, most significant octet first -- seconds
- since 00:00:00 GMT, January 1, 1970. The standard
- Attributes do not use this data type but it is presented
- here for possible use within Vendor-Specific attributes.
-
-5.1. Acct-Status-Type
-
- Description
-
- This attribute indicates whether this Accounting-Request marks the
- beginning of the user service (Start) or the end (Stop).
-
- It MAY be used by the client to mark the start of accounting (for
- example, upon booting) by specifying Accounting-On and to mark the
- end of accounting (for example, just before a scheduled reboot) by
- specifying Accounting-Off.
-
- A summary of the Acct-Status-Type attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-Rigney Informational [Page 11]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Type
-
- 40 for Acct-Status-Type.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 Start
- 2 Stop
- 7 Accounting-On
- 8 Accounting-Off
-
-5.2. Acct-Delay-Time
-
- Description
-
- This attribute indicates how many seconds the client has been
- trying to send this record for, and can be subtracted from the
- time of arrival on the server to find the approximate time of the
- event generating this Accounting-Request. (Network transit time
- is ignored.)
-
- Note that changing the Acct-Delay-Time causes the Identifier to
- change; see the discussion under Identifier above.
-
- A summary of the Acct-Delay-Time attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 41 for Acct-Delay-Time.
-
- Length
-
- 6
-
-
-
-Rigney Informational [Page 12]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Value
-
- The Value field is four octets.
-
-5.3. Acct-Input-Octets
-
- Description
-
- This attribute indicates how many octets have been received from
- the port over the course of this service being provided, and can
- only be present in Accounting-Request records where the Acct-
- Status-Type is set to Stop.
-
- A summary of the Acct-Input-Octets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 42 for Acct-Input-Octets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.4. Acct-Output-Octets
-
- Description
-
- This attribute indicates how many octets have been sent to the
- port in the course of delivering this service, and can only be
- present in Accounting-Request records where the Acct-Status-Type
- is set to Stop.
-
- A summary of the Acct-Output-Octets attribute format is shown below.
- The fields are transmitted from left to right.
-
-
-
-
-Rigney Informational [Page 13]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 43 for Acct-Output-Octets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.5. Acct-Session-Id
-
- Description
-
- This attribute is a unique Accounting ID to make it easy to match
- start and stop records in a log file. The start and stop records
- for a given session MUST have the same Acct-Session-Id. It is
- strongly recommended that the Acct-Session-Id be a printable ASCII
- string.
-
- For example, one implementation uses a string with an 8-digit
- upper case hexadecimal number, the first two digits increment on
- each reboot (wrapping every 256 reboots) and the next 6 digits
- counting from 0 for the first person logging in after a reboot up
- to 2^24-1, about 16 million. Other encodings are possible.
-
- A summary of the Acct-Session-Id attribute format is shown below.
- The fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 14]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 44 for Acct-Session-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field SHOULD be a string of printable ASCII characters.
-
-5.6. Acct-Authentic
-
- Description
-
- This attribute MAY be included in an Accounting-Request to
- indicate how the user was authenticated, whether by RADIUS, the
- NAS itself, or another remote authentication protocol. Users who
- are delivered service without being authenticated SHOULD NOT
- generate Accounting records.
-
- A summary of the Acct-Authentic attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 45 for Acct-Authentic.
-
- Length
-
- 6
-
-
-
-
-
-Rigney Informational [Page 15]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Value
-
- The Value field is four octets.
-
- 1 RADIUS
- 2 Local
- 3 Remote
-
-5.7. Acct-Session-Time
-
- Description
-
- This attribute indicates how many seconds the user has received
- service for, and can only be present in Accounting-Request records
- where the Acct-Status-Type is set to Stop.
-
- A summary of the Acct-Session-Time attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 46 for Acct-Session-Time.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.8. Acct-Input-Packets
-
- Description
-
- This attribute indicates how many packets have been received from
- the port over the course of this service being provided to a
- Framed User, and can only be present in Accounting-Request records
- where the Acct-Status-Type is set to Stop.
-
-
-
-
-Rigney Informational [Page 16]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- A summary of the Acct-Input-packets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 47 for Acct-Input-Packets.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.9. Acct-Output-Packets
-
- Description
-
- This attribute indicates how many packets have been sent to the
- port in the course of delivering this service to a Framed User,
- and can only be present in Accounting-Request records where the
- Acct-Status-Type is set to Stop.
-
- A summary of the Acct-Output-Packets attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 48 for Acct-Output-Packets.
-
-
-
-
-
-Rigney Informational [Page 17]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-5.10. Acct-Terminate-Cause
-
- Description
-
- This attribute indicates how the session was terminated, and can
- only be present in Accounting-Request records where the Acct-
- Status-Type is set to Stop.
-
- A summary of the Acct-Terminate-Cause attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 49 for Acct-Terminate-Cause
-
- Length
-
- 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 18]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Value
-
- The Value field is four octets, containing an integer specifying
- the cause of session termination, as follows:
-
- 1 User Request
- 2 Lost Carrier
- 3 Lost Service
- 4 Idle Timeout
- 5 Session Timeout
- 6 Admin Reset
- 7 Admin Reboot
- 8 Port Error
- 9 NAS Error
- 10 NAS Request
- 11 NAS Reboot
- 12 Port Unneeded
- 13 Port Preempted
- 14 Port Suspended
- 15 Service Unavailable
- 16 Callback
- 17 User Error
- 18 Host Request
-
-
-
- The termination causes are as follows:
-
- User Request User requested termination of service, for
- example with LCP Terminate or by logging out.
-
- Lost Carrier DCD was dropped on the port.
-
- Lost Service Service can no longer be provided; for
- example, user's connection to a host was
- interrupted.
-
- Idle Timeout Idle timer expired.
-
- Session Timeout Maximum session length timer expired.
-
- Admin Reset Administrator reset the port or session.
-
- Admin Reboot Administrator is ending service on the NAS,
- for example prior to rebooting the NAS.
-
- Port Error NAS detected an error on the port which
- required ending the session.
-
-
-
-Rigney Informational [Page 19]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- NAS Error NAS detected some error (other than on the
- port) which required ending the session.
-
- NAS Request NAS ended session for a non-error reason not
- otherwise listed here.
-
- NAS Reboot The NAS ended the session in order to reboot
- non-administratively ("crash").
-
- Port Unneeded NAS ended session because resource usage fell
- below low-water mark (for example, if a
- bandwidth-on-demand algorithm decided that
- the port was no longer needed).
-
- Port Preempted NAS ended session in order to allocate the
- port to a higher priority use.
-
- Port Suspended NAS ended session to suspend a virtual
- session.
-
- Service Unavailable NAS was unable to provide requested service.
-
- Callback NAS is terminating current session in order
- to perform callback for a new session.
-
- User Error Input from user is in error, causing
- termination of session.
-
- Host Request Login Host terminated session normally.
-
-5.11. Acct-Multi-Session-Id
-
- Description
-
- This attribute is a unique Accounting ID to make it easy to link
- together multiple related sessions in a log file. Each session
- linked together would have a unique Acct-Session-Id but the same
- Acct-Multi-Session-Id. It is strongly recommended that the Acct-
- Multi-Session-Id be a printable ASCII string.
-
- A summary of the Acct-Session-Id attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-Rigney Informational [Page 20]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- Type
-
- 50 for Acct-Multi-Session-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field SHOULD be a string of printable ASCII characters.
-
-5.12. Acct-Link-Count
-
- Description
-
- This attribute gives the count of links which are known to have
- been in a given multilink session at the time the accounting
- record is generated. The NAS MAY include the Acct-Link-Count
- attribute in any Accounting-Request which might have multiple
- links.
-
- A summary of the Acct-Link-Count attribute format is show below. The
- fields are transmitted from left to right.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 51 for Acct-Link-Count.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets, and contains the number of links
- seen so far in this Multilink Session.
-
-
-
-
-
-
-Rigney Informational [Page 21]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- It may be used to make it easier for an accounting server to know
- when it has all the records for a given Multilink session. When
- the number of Accounting-Requests received with Acct-Status-Type =
- Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
- Id's equals the largest value of Acct-Link-Count seen in those
- Accounting-Requests, all Stop Accounting-Requests for that
- Multilink Session have been received.
-
- An example showing 8 Accounting-Requests should make things
- clearer. For clarity only the relevant attributes are shown, but
- additional attributes containing accounting information will also
- be present in the Accounting-Request.
-
- Multi-Session-Id Session-Id Status-Type Link-Count
- "10" "10" Start 1
- "10" "11" Start 2
- "10" "11" Stop 2
- "10" "12" Start 3
- "10" "13" Start 4
- "10" "12" Stop 4
- "10" "13" Stop 4
- "10" "10" Stop 4
-
-5.13. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in Accounting-Request packets. No attributes should be found in
- Accounting-Response packets except Proxy-State and possibly Vendor-
- Specific.
-
- # Attribute
- 0-1 User-Name
- 0 User-Password
- 0 CHAP-Password
- 0-1 NAS-IP-Address [5]
- 0-1 NAS-Port
- 0-1 Service-Type
- 0-1 Framed-Protocol
- 0-1 Framed-IP-Address
- 0-1 Framed-IP-Netmask
- 0-1 Framed-Routing
- 0+ Filter-Id
- 0-1 Framed-MTU
- 0+ Framed-Compression
- 0+ Login-IP-Host
- 0-1 Login-Service
- 0-1 Login-TCP-Port
- 0 Reply-Message
-
-
-
-Rigney Informational [Page 22]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
- 0-1 Callback-Number
- 0-1 Callback-Id
- 0+ Framed-Route
- 0-1 Framed-IPX-Network
- 0 State
- 0+ Class
- 0+ Vendor-Specific
- 0-1 Session-Timeout
- 0-1 Idle-Timeout
- 0-1 Termination-Action
- 0-1 Called-Station-Id
- 0-1 Calling-Station-Id
- 0-1 NAS-Identifier [4]
- 0+ Proxy-State
- 0-1 Login-LAT-Service
- 0-1 Login-LAT-Node
- 0-1 Login-LAT-Group
- 0-1 Framed-AppleTalk-Link
- 0-1 Framed-AppleTalk-Network
- 0-1 Framed-AppleTalk-Zone
- 1 Acct-Status-Type
- 0-1 Acct-Delay-Time
- 0-1 Acct-Input-Octets
- 0-1 Acct-Output-Octets
- 1 Acct-Session-Id
- 0-1 Acct-Authentic
- 0-1 Acct-Session-Time
- 0-1 Acct-Input-Packets
- 0-1 Acct-Output-Packets
- 0-1 Acct-Terminate-Cause
- 0+ Acct-Multi-Session-Id
- 0+ Acct-Link-Count
- 0 CHAP-Challenge
- 0-1 NAS-Port-Type
- 0-1 Port-Limit
- 0-1 Login-LAT-Port
-
-
- [5] An Accounting-Request MUST contain either a NAS-IP-Address or a
- NAS-Identifier, and it is permitted (but not recommended) for it to
- contain both.
-
- The following table defines the above table entries.
-
- 0 This attribute MUST NOT be present
- 0+ Zero or more instances of this attribute MAY be present.
- 0-1 Zero or one instance of this attribute MAY be present.
- 1 Exactly one instance of this attribute MUST be present.
-
-
-
-Rigney Informational [Page 23]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-Security Considerations
-
- Security issues are briefly discussed in sections concerning the
- authenticator included in accounting requests and responses, using a
- shared secret which is never sent over the network.
-
-References
-
- [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- USC/Information Sciences Institute, August 1980.
-
- [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
- 1700, USC/Information Sciences Institute, October 1994.
-
- [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
- RFC 1321, MIT Laboratory for Computer Science, RSA Data
- Security Inc., April 1992.
-
- [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
- Authentication Dial In User Service (RADIUS)", RFC 2138,
- April 1997.
-
-Acknowledgments
-
- RADIUS and RADIUS Accounting were originally developed by Livingston
- Enterprises for their PortMaster series of Network Access Servers.
-
-Chair's Address
-
- The RADIUS working group can be contacted via the current chair:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- Phone: +1 510 426 0770
- EMail: cdr@livingston.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 24]
-\f
-RFC 2139 RADIUS Accounting April 1997
-
-
-Author's Address
-
- Questions about this memo can also be directed to:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- EMail: cdr@livingston.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney Informational [Page 25]
-\f
projects / freeradius.git / commitdiff