游戏

开发平台：

Visual C++

rfc2865.txt：源码内容

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
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]