📄 rfc2058.txt
字号:
Network Working Group C. Rigney
Request for Comments: 2058 Livingston
Category: Standards Track A. Rubens
Merit
W. Simpson
Daydreamer
S. Willens
Livingston
January 1997
Remote Authentication Dial In User Service (RADIUS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server which desires to authenticate its links and a shared
Authentication Server.
Table of Contents
1. Introduction .......................................... 3
1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 4
2. Operation ............................................. 5
2.1 Challenge/Response .............................. 6
2.2 Interoperation with PAP and CHAP ................ 7
2.3 Why UDP? ........................................ 8
3. Packet Format ......................................... 9
4. Packet Types .......................................... 12
4.1 Access-Request .................................. 12
4.2 Access-Accept ................................... 14
4.3 Access-Reject ................................... 15
4.4 Access-Challenge ................................ 16
5. Attributes ............................................ 17
5.1 User-Name ....................................... 20
5.2 User-Password ................................... 21
5.3 CHAP-Password ................................... 22
5.4 NAS-IP-Address .................................. 23
Rigney, et. al. Informational [Page 1]
RFC 2058 RADIUS January 1997
5.5 NAS-Port ........................................ 24
5.6 Service-Type .................................... 25
5.7 Framed-Protocol ................................. 27
5.8 Framed-IP-Address ............................... 28
5.9 Framed-IP-Netmask ............................... 29
5.10 Framed-Routing .................................. 29
5.11 Filter-Id ....................................... 30
5.12 Framed-MTU ...................................... 31
5.13 Framed-Compression .............................. 32
5.14 Login-IP-Host ................................... 33
5.15 Login-Service ................................... 33
5.16 Login-TCP-Port .................................. 34
5.17 (unassigned) .................................... 35
5.18 Reply-Message ................................... 35
5.19 Callback-Number ................................. 36
5.20 Callback-Id ..................................... 37
5.21 (unassigned) .................................... 37
5.22 Framed-Route .................................... 38
5.23 Framed-IPX-Network .............................. 39
5.24 State ........................................... 39
5.25 Class ........................................... 40
5.26 Vendor-Specific ................................. 41
5.27 Session-Timeout ................................. 43
5.28 Idle-Timeout .................................... 44
5.29 Termination-Action .............................. 44
5.30 Called-Station-Id ............................... 45
5.31 Calling-Station-Id .............................. 46
5.32 NAS-Identifier .................................. 47
5.33 Proxy-State ..................................... 48
5.34 Login-LAT-Service ............................... 49
5.35 Login-LAT-Node .................................. 50
5.36 Login-LAT-Group ................................. 51
5.37 Framed-AppleTalk-Link ........................... 52
5.38 Framed-AppleTalk-Network ........................ 53
5.39 Framed-AppleTalk-Zone ........................... 53
5.40 CHAP-Challenge .................................. 54
5.41 NAS-Port-Type ................................... 55
5.42 Port-Limit ...................................... 56
5.43 Login-LAT-Port .................................. 57
5.44 Table of Attributes ............................. 58
6. Examples .............................................. 59
6.1 User Telnet to Specified Host ................... 59
6.2 Framed User Authenticating with CHAP ............ 60
6.3 User with Challenge-Response card ............... 61
SECURITY CONSIDERATIONS ...................................... 62
REFERENCES ................................................... 63
ACKNOWLEDGEMENTS ............................................. 63
CHAIR'S ADDRESS .............................................. 64
Rigney, et. al. Informational [Page 2]
RFC 2058 RADIUS January 1997
AUTHORS' ADDRESSES ........................................... 64
1. Introduction
Managing dispersed serial line and modem pools for large numbers of
users can create the need for significant administrative support.
Since modem pools are by definition a link to the outside world, they
require careful attention to security, authorization and accounting.
This can be best achieved by managing a single "database" of users,
which allows for authentication (verifying user name and password) as
well as configuration information detailing the type of service to
deliver to the user (for example, SLIP, PPP, telnet, rlogin).
Key features of RADIUS are:
Client/Server Model
A Network Access Server (NAS) operates as a client of RADIUS. The
client is responsible for passing user information to designated
RADIUS servers, and then acting on the response which is returned.
RADIUS servers are responsible for receiving user connection
requests, authenticating the user, and then returning all
configuration information necessary for the client to deliver
service to the user.
A RADIUS server can act as a proxy client to other RADIUS servers
or other kinds of authentication servers.
Network Security
Transactions between the client and RADIUS server are
authenticated through the use of a shared secret, which is never
sent over the network. In addition, any user passwords are sent
encrypted between the client and RADIUS server, to eliminate the
possibility that someone snooping on an unsecure network could
determine a user's password.
Flexible Authentication Mechanisms
The RADIUS server can support a variety of methods to authenticate
a user. When it is provided with the user name and original
password given by the user, it can support PPP PAP or CHAP, UNIX
login, and other authentication mechanisms.
Rigney, et. al. Informational [Page 3]
RFC 2058 RADIUS January 1997
Extensible Protocol
All transactions are comprised of variable length Attribute-
Length-Value 3-tuples. New attribute values can be added without
disturbing existing implementations of the protocol.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
1.2. Terminology
This document frequently uses the following terms:
service The NAS provides a service to the dial-in user, such as PPP
or Telnet.
session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or
series if the NAS supports that.
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
Rigney, et. al. Informational [Page 4]
RFC 2058 RADIUS January 1997
in a statistics counter.
2. Operation
When a client is configured to use RADIUS, any user of the client
presents authentication information to the client. This might be
with a customizable login prompt, where the user is expected to enter
their username and password. Alternatively, the user might use a
link framing protocol such as the Point-to-Point Protocol (PPP),
which has authentication packets which carry this information.
Once the client has obtained such information, it may choose to
authenticate using RADIUS. To do so, the client creates an "Access-
Request" containing such Attributes as the user's name, the user's
password, the ID of the client and the Port ID which the user is
accessing. When a password is present, it is hidden using a method
based on the RSA Message Digest Algorithm MD5 [1].
The Access-Request is submitted to the RADIUS server via the network.
If no response is returned within a length of time, the request is
re-sent a number of times. The client can also forward requests to
an alternate server or servers in the event that the primary server
is down or unreachable. An alternate server can be used either after
a number of tries to the primary server fail, or in a round-robin
fashion. Retry and fallback algorithms are the topic of current
research and are not specified in detail in this document.
Once the RADIUS server receives the request, it validates the sending
client. A request from a client for which the RADIUS server does not
have a shared secret should be silently discarded. If the client is
valid, the RADIUS server consults a database of users to find the
user whose name matches the request. The user entry in the database
contains a list of requirements which must be met to allow access for
the user. This always includes verification of the password, but can
also specify the client(s) or port(s) to which the user is allowed
access.
The RADIUS server MAY make requests of other servers in order to
satisfy the request, in which case it acts as a client.
If any condition is not met, the RADIUS server sends an "Access-
Reject" response indicating that this user request is invalid. If
desired, the server MAY include a text message in the Access-Reject
which MAY be displayed by the client to the user. No other
Attributes are permitted in an Access-Reject.
If all conditions are met and the RADIUS server wishes to issue a
challenge to which the user must respond, the RADIUS server sends an
Rigney, et. al. Informational [Page 5]
RFC 2058 RADIUS January 1997
"Access-Challenge" response. It MAY include a text message to be
displayed by the client to the user prompting for a response to the
challenge, and MAY include a State attribute. If the client receives
an Access-Challenge and supports challenge/response it MAY display
the text message, if any, to the user, and then prompt the user for a
response. The client then re-submits its original Access-Request
with a new request ID, with the User-Password Attribute replaced by
the response (encrypted), and including the State Attribute from the
Access-Challenge, if any. Only 0 or 1 instances of the State
Attributes should be present in a request. The server can respond to
this new Access-Request with either an Access-Accept, an Access-
Reject, or another Access-Challenge.
If all conditions are met, the list of configuration values for the
user are placed into an "Access-Accept" response. These values
include the type of service (for example: SLIP, PPP, Login User) and
all necessary values to deliver the desired service. For SLIP and
PPP, this may include values such as IP address, subnet mask, MTU,
desired compression, and desired packet filter identifiers. For
character mode users, this may include values such as desired
protocol and host.
2.1. Challenge/Response
In challenge/response authentication, the user is given an
unpredictable number and challenged to encrypt it and give back the
result. Authorized users are equipped with special devices such as
smart cards or software that facilitate calculation of the correct
response with ease. Unauthorized users, lacking the appropriate
device or software and lacking knowledge of the secret key necessary
to emulate such a device or software, can only guess at the response.
The Access-Challenge packet typically contains a Reply-Message
including a challenge to be displayed to the user, such as a numeric
value unlikely ever to be repeated. Typically this is obtained from
an external server that knows what type of authenticator should be in
the possession of the authorized user and can therefore choose a
random or non-repeating pseudorandom number of an appropriate radix
and length.
The user then enters the challenge into his device (or software) and
it calculates a response, which the user enters into the client which
forwards it to the RADIUS server via a second Access-Request. If the
response matches the expected response the RADIUS server replies with
an Access-Accept, otherwise an Access-Reject.
Example: The NAS sends an Access-Request packet to the RADIUS Server
with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
Rigney, et. al. Informational [Page 6]
RFC 2058 RADIUS January 1997
just be a fixed string like "challenge" or ignored). The server
sends back an Access-Challenge packet with State and a Reply-Message
along the lines of "Challenge 12345678, enter your response at the
prompt" which the NAS displays. The NAS prompts for the response and
sends a NEW Access-Request to the server (with a new ID) with NAS-
Identifier, NAS-Port, User-Name, User-Password (the response just
entered by the user, encrypted), and the same State Attribute that
came with the Access-Challenge. The server then sends back either an
Access-Accept or Access-Reject based on whether the response matches
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -