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