draft-ietf-radext-status-server-09.txt   rfc5997.txt 
Network Working Group Alan DeKok Internet Engineering Task Force (IETF) A. DeKok
INTERNET-DRAFT FreeRADIUS Request for Comments: 5997 FreeRADIUS
Updates: 2866 August 2010
Category: Informational Category: Informational
Updates: 2866 ISSN: 2070-1721
<draft-ietf-radext-status-server-09.txt>
Expires: November 18, 2010
18 May 2010
Use of Status-Server Packets in the Use of Status-Server Packets in the
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
draft-ietf-radext-status-server-09
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document describes a deployed extension to the Remote
Task Force (IETF), its areas, and its working groups. Note that Authentication Dial In User Service (RADIUS) protocol, enabling
other groups may also distribute working documents as Internet- clients to query the status of a RADIUS server. This extension
Drafts. utilizes the Status-Server (12) Code, which was reserved for
experimental use in RFC 2865.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 18, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5997.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract
This document describes a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. This extension
utilizes the Status-Server (12) Code, which was reserved for
experimental use in RFC 2865.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ....................................................3
1.1. Applicability ....................................... 4 1.1. Applicability ..............................................3
1.2. Terminology ......................................... 5 1.2. Terminology ................................................4
1.3. Requirements Language ............................... 5 1.3. Requirements Language ......................................4
2. Overview ................................................. 6 2. Overview ........................................................4
2.1. Why Access-Request is inappropriate ................. 7 2.1. Why Access-Request is Inappropriate ........................6
2.1.1. Recommendation against Access-Request .......... 8 2.1.1. Recommendation against Access-Request ...............7
2.2. Why Accounting-Request is inappropriate ............. 8 2.2. Why Accounting-Request is Inappropriate ....................7
2.2.1. Recommendation against Accounting-Request ...... 8 2.2.1. Recommendation against Accounting-Request ...........7
3. Packet Format ............................................ 9 3. Packet Format ...................................................8
3.1. Single definition for Status-Server ................. 11 3.1. Single Definition for Status-Server .......................10
4. Implementation notes ..................................... 11 4. Implementation Notes ...........................................10
4.1. Client Requirements ................................. 12 4.1. Client Requirements .......................................11
4.2. Server Requirements ................................. 13 4.2. Server Requirements .......................................12
4.3. Fail-over with Status-Server ........................ 15 4.3. Failover with Status-Server ...............................14
4.4. Proxy Server handling of Status-Server .............. 15 4.4. Proxy Server Handling of Status-Server ....................14
4.5. Limitations of Status-Server ........................ 16 4.5. Limitations of Status-Server ..............................15
4.6. Management Information Base (MIB) Considerations .... 18 4.6. Management Information Base (MIB) Considerations ..........17
4.6.1. Interaction with RADIUS Server MIB modules ..... 18 4.6.1. Interaction with RADIUS Server MIB Modules .........17
4.6.2. Interaction with RADIUS Client MIB modules ..... 18 4.6.2. Interaction with RADIUS Client MIB Modules .........17
5. Table of Attributes ...................................... 19 5. Table of Attributes ............................................18
6. Examples ................................................. 19 6. Examples .......................................................19
6.1. Minimal Query to Authentication Port ................ 20 6.1. Minimal Query to Authentication Port ......................19
6.2. Minimal Query to Accounting Port .................... 20 6.2. Minimal Query to Accounting Port ..........................20
6.3. Verbose Query and Response .......................... 21 6.3. Verbose Query and Response ................................21
7. IANA Considerations ...................................... 22 7. Security Considerations ........................................21
8. Security Considerations .................................. 22 8. References .....................................................23
9. References ............................................... 23 8.1. Normative References ......................................23
9.1. Normative references ................................ 23 8.2. Informative References ....................................23
9.2. Informative references .............................. 24 Acknowledgments ...................................................24
1. Introduction 1. Introduction
This document specifies a deployed extension to the Remote This document specifies a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. While the Status- clients to query the status of a RADIUS server. While the Status-
Server Code (12) was defined as experimental in [RFC2865] Section 3, Server (12) Code was defined as experimental in [RFC2865], Section 3,
details of the operation and potential uses of the Code were not details of the operation and potential uses of the Code were not
provided. provided.
As with the core RADIUS protocol, the Status-Server extension is As with the core RADIUS protocol, the Status-Server extension is
stateless, and queries do not otherwise affect the normal operation stateless, and queries do not otherwise affect the normal operation
of a server, nor do they result in any side effects, other than of a server, nor do they result in any side effects, other than
perhaps incrementing of an internal packet counter. Most of the perhaps incrementing an internal packet counter. Most of the
implementations of this extension have utilized it alongside implementations of this extension have utilized it alongside
implementations of RADIUS as defined in [RFC2865], so that this implementations of RADIUS as defined in [RFC2865], so that this
document focuses solely on the use of this extension with UDP document focuses solely on the use of this extension with UDP
transport. transport.
The rest of this document is laid out as follows. Section 2 contains The rest of this document is laid out as follows. Section 2 contains
the problem statement, and explanations as to why some possible the problem statement, and explanations as to why some possible
solutions can have unwanted side effects. Section 3 defines the solutions can have unwanted side effects. Section 3 defines the
Status-Server packet format. Section 4 contains client and server Status-Server packet format. Section 4 contains client and server
requirements, along with some implementation notes. Section 5 lists requirements, along with some implementation notes. Section 5
additional considerations not covered in the other sections. The contains a RADIUS table of attributes. The remaining text discusses
remaining text contains a RADIUS table of attributes, and discusses
security considerations not covered elsewhere in the document. security considerations not covered elsewhere in the document.
1.1. Applicability 1.1. Applicability
This protocol is being recommended for publication as an This protocol is being recommended for publication as an
Informational RFC rather than as a standards-track RFC because of Informational RFC rather than as a Standards-Track RFC because of
problems with deployed implementations. This includes security problems with deployed implementations. This includes security
vulnerabilities. The fixes recommended here are compatible with vulnerabilities. The fixes recommended here are compatible with
existing servers that receive Status-Server packets, but impose new existing servers that receive Status-Server packets, but impose new
security requirements on clients that send Status-Server packets. security requirements on clients that send Status-Server packets.
Some existing implementations of this protocol do not support the Some existing implementations of this protocol do not support the
Message-Authenticator attribute. This enables an unauthorized client Message-Authenticator attribute ([RFC3579]). This enables an
to spoofing Status-Server packets, potentially leading to incorrect unauthorized client to spoof Status-Server packets, potentially
Access-Accepts. In order to remedy this problem, this specification leading to incorrect Access-Accepts. In order to remedy this
requires the use of the Message-Authenticator attribute to provide problem, this specification requires the use of the Message-
per-packet authentication and integrity protection. Authenticator attribute to provide per-packet authentication and
integrity protection.
With existing implementations of this protocol, the potential exists With existing implementations of this protocol, the potential exists
for Status-Server requests to be in conflict with Access-Request or for Status-Server requests to be in conflict with Access-Request or
Accounting-Requests packets using the same Identifier. This Accounting-Request packets using the same Identifier. This
specification recommends techniques to avoid this problem. specification recommends techniques to avoid this problem.
These limitations are discussed in more detail below. These limitations are discussed in more detail below.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Network Access Server (NAS) "Network Access Server (NAS)"
The device providing access to the network. Also known as the
Authenticator (in IEEE 802.1X terminology) or RADIUS client.
RADIUS Proxy The device providing access to the network. Also known as the
In order to provide for the routing of RADIUS authentication and Authenticator (in IEEE 802.1X terminology) or RADIUS client.
accounting requests, a RADIUS proxy can be employed. To the NAS,
the RADIUS proxy appears to act as a RADIUS server, and to the
RADIUS server, the proxy appears to act as a RADIUS client.
silently discard "RADIUS Proxy"
This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of In order to provide for the routing of RADIUS authentication and
logging the error, including the contents of the silently discarded accounting requests, a RADIUS proxy can be employed. To the NAS,
packet, and SHOULD record the event in a statistics counter. the RADIUS proxy appears to act as a RADIUS server, and to the
RADIUS server, the proxy appears to act as a RADIUS client.
"silently discard"
This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
1.3. Requirements Language 1.3. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Overview 2. Overview
Status-Server packets are sent by a RADIUS client to a RADIUS server Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. The destination of a in order to test the status of that server. The destination of a
Status-Server packet is set to the IP address and port of the server Status-Server packet is set to the IP address and port of the server
that is being tested. A single Status-Server packet MUST be included that is being tested. A single Status-Server packet MUST be included
within a UDP datagram. A Message-Authenticator attribute MUST be within a UDP datagram. A Message-Authenticator attribute MUST be
included so as to provide per-packet authentication and integrity included so as to provide per-packet authentication and integrity
protection. protection.
RADIUS proxies or servers MUST NOT forward Status-Server packets. A RADIUS proxies or servers MUST NOT forward Status-Server packets. A
RADIUS server or proxy implementing this specification SHOULD respond RADIUS server or proxy implementing this specification SHOULD respond
to a Status-Server packet with an Access-Accept (authentication port) to a Status-Server packet with an Access-Accept (authentication port)
or Accounting-Response (accounting port). An Access-Challenge or Accounting-Response (accounting port). An Access-Challenge
response is NOT RECOMMENDED. An Access-Reject response MAY be used. response is NOT RECOMMENDED. An Access-Reject response MAY be used.
The list of attributes that are permitted in Status-Server and The list of attributes that are permitted in Status-Server packets,
Access-Accept packets responding to Status-Server packets are and in Access-Accept or Accounting-Response packets responding to
provided in the Section 6. Status-Server packets, is provided in Section 5. Section 6 provides
several examples.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
or server, the client is provided with an indication of the status of or server, the client is provided with an indication of the status of
that server only, since no RADIUS proxies are on the path between the that server only, since no RADIUS proxies are on the path between the
RADIUS client and server. As servers respond to a Status-Server RADIUS client and server. As servers respond to a Status-Server
packet without examining the User-Name attribute, the response to a packet without examining the User-Name attribute, the response to a
Status-Server packet cannot be used to infer any information about Status-Server packet cannot be used to infer any information about
the reachability of specific realms. the reachability of specific realms.
The "hop by hop" functionality of Status-Server packets is useful to The "hop-by-hop" functionality of Status-Server packets is useful to
RADIUS clients attempting to determine the status of the first RADIUS clients attempting to determine the status of the first
element on the path between the client and a server. Since the element on the path between the client and a server. Since the
Status-Server packet is non-forwardable, lack of a response may only Status-Server packet is non-forwardable, the lack of a response may
be due to packet loss or the failure of the server in the destination only be due to packet loss or the failure of the server at the
IP address, not due to faults in downstream links, proxies or destination IP address, and not due to faults in downstream links,
servers. It therefore provides an unambiguous indication of the proxies, or servers. It therefore provides an unambiguous indication
status of a server. of the status of a server.
This information may be useful in situations where the RADIUS client This information may be useful in situations in which the RADIUS
does not receive a response to an Access-Request. A client may have client does not receive a response to an Access-Request. A client
multiple proxies configured, with one proxy marked as primary and may have multiple proxies configured, with one proxy marked as
another marked as secondary. If the client does not receive a primary and another marked as secondary. If the client does not
response to a request sent to the primary proxy, it can "fail over" receive a response to a request sent to the primary proxy, it can
to the secondary, and send requests to the secondary instead of to "failover" to the secondary, and send requests to the secondary proxy
the primary proxy. instead.
However, it is possible that the lack of a response to requests sent However, it is possible that the lack of a response to requests sent
to the primary proxy was due not to a failure within the the primary, to the primary proxy was due not to a failure within the primary, but
but to alternative causes such as a failed link along the path to the to alternative causes such as a failed link along the path to the
destination server, or the failure of the destination server. destination server or the failure of the destination server itself.
In such a situation, it may be useful for the client to be able to In such a situation, it may be useful for the client to be able to
distinguish between failure causes so that it does not trigger distinguish between failure causes so that it does not trigger
failover inappropriately. For example, if the primary proxy is down, failover inappropriately. For example, if the primary proxy is down,
then a quick failover to the secondary proxy would be prudent. then a quick failover to the secondary proxy would be prudent;
Whereas if a downstream failure is the cause, then the value of whereas, if a downstream failure is the cause, then the value of
failover to a secondary proxy will depend on whether packets failover to a secondary proxy will depend on whether packets
forwarded by the secondary will utilize independent links, forwarded by the secondary will utilize independent links,
intermediaries or destination servers. intermediaries, or destination servers.
The Status-Server packet is not a "Keep-Alive" as discussed in The Status-Server packet is not a "Keep-Alive" as discussed in
[RFC2865] Section 2.6. "Keep-Alives" are Access-Request packets sent [RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets
to determine whether a downstream server is responsive. These sent to determine whether a downstream server is responsive. These
packets are typically sent only when a server is suspected to be packets are typically sent only when a server is suspected to be
down, and are no longer sent as soon as the server is available down, and they are no longer sent as soon as the server is available
again. again.
2.1. Why Access-Request is inappropriate 2.1. Why Access-Request is Inappropriate
One possible solution to the problem of querying server status is for One possible solution to the problem of querying server status is for
a NAS to send specially formed Access-Request packets to a RADIUS a NAS to send specially formed Access-Request packets to a RADIUS
server's authentication port. The NAS can then look for a response, server's authentication port. The NAS can then look for a response
and use this information to determine if the server is active or and use this information to determine if the server is active or
unresponsive. unresponsive.
However, the server may see the request as a normal login request for However, the server may see the request as a normal login request for
a user, and conclude that a real user has logged onto that NAS. The a user and conclude that a real user has logged onto that NAS. The
server may then perform actions that are undesirable for a simple server may then perform actions that are undesirable for a simple
status query. The server may alternatively respond with an Access- status query. The server may alternatively respond with an Access-
Challenge, indicating that it believes an extended authentication Challenge, indicating that it believes an extended authentication
conversation is necessary. conversation is necessary.
Another possibility is that the server responds with an Access- Another possibility is that the server responds with an Access-
Reject, indicating that the user is not authorized to gain access to Reject, indicating that the user is not authorized to gain access to
the network. As above, the server may also perform local site the network. As above, the server may also perform local-site
actions, such as warning an administrator of failed login attempts. actions, such as warning an administrator of failed login attempts.
The server may also delay the Access-Reject response, in the The server may also delay the Access-Reject response, in the
traditional manner of rate-limiting failed authentication attempts. traditional manner of rate-limiting failed authentication attempts.
This delay in response means that the querying administrator is This delay in response means that the querying administrator is
unsure as to whether or not the server is down, is slow to respond, unsure as to whether or not the server is down, slow to respond, or
or is intentionally delaying its response to the query. intentionally delaying its response to the query.
In addition, using Access-Request queries may mean that the server In addition, using Access-Request queries may mean that the server
may have local users configured whose sole reason for existence is to may have local users configured whose sole reason for existence is to
enable these query requests. Unless the server policy is designed enable these query requests. Unless the server policy is designed
carefully, it may be possible for an attacker to use those carefully, it may be possible for an attacker to use those
credentials to gain unauthorized network access. credentials to gain unauthorized network access.
We note that some NAS implementations currently use Access-Request We note that some NAS implementations currently use Access-Request
packets as described above, with a fixed (and non configurable) user packets as described above, with a fixed (and non-configurable) user
name and password. Implementation issues with that equipment means name and password. Implementation issues with that equipment mean
that if a RADIUS server does not respond to those queries, it may be that if a RADIUS server does not respond to those queries, it may be
marked as unresponsive by the NAS. This marking may happen even if marked as unresponsive by the NAS. This marking may happen even if
the server is actively responding to other Access-Requests from that the server is actively responding to other Access-Requests from that
same NAS. This behavior is confusing to administrators who then need same NAS. This behavior is confusing to administrators who then need
to determine why an active server has been marked as "unresponsive". to determine why an active server has been marked as "unresponsive".
2.1.1. Recommendation against Access-Request 2.1.1. Recommendation against Access-Request
For the reasons outlined above, NAS implementors SHOULD NOT generate For the reasons outlined above, NAS implementors SHOULD NOT generate
Access-Request packets solely to see if a server is alive. Access-Request packets solely to see if a server is alive.
Similarly, site administrators SHOULD NOT configure test users whose Similarly, site administrators SHOULD NOT configure test users whose
sole reason for existence is to enable such queries via Access- sole reason for existence is to enable such queries via Access-
Request packets. Request packets.
Note that it still may be useful to configure test users for the Note that it still may be useful to configure test users for the
purpose of performing end-to-end or in-depth testing of a server purpose of performing end-to-end or in-depth testing of a server
policy. While this practice is widespread, we caution administrators policy. While this practice is widespread, we caution administrators
to use it with care. to use it with care.
2.2. Why Accounting-Request is inappropriate 2.2. Why Accounting-Request is Inappropriate
A similar solution for the problem of querying server status may be A similar solution for the problem of querying server status may be
for a NAS to send specially formed Accounting-Request packets to a for a NAS to send specially formed Accounting-Request packets to a
RADIUS servers accounting port. The NAS can then look for a RADIUS server's accounting port. The NAS can then look for a
response, and use this information to determine if the server is response and use this information to determine if the server is
active or unresponsive. active or unresponsive.
As seen above with Access-Request, the server may then conclude that As seen above with Access-Request, the server may then conclude that
a real user has logged onto a NAS, and perform local site actions a real user has logged onto a NAS, and perform local-site actions
that are undesirable for a simple status query. that are undesirable for a simple status query.
Another consideration is that some attributes are mandatory to Another consideration is that some attributes are mandatory to
include in an Accounting-Request. This requirement forces the include in an Accounting-Request. This requirement forces the
administrator to query an accounting server with fake values for administrator to query an accounting server with fake values for
those attributes in a test packet. These fake values increase the those attributes in a test packet. These fake values increase the
work required to perform a simple query, and may pollute the server's work required to perform a simple query, and they may pollute the
accounting database with incorrect data. server's accounting database with incorrect data.
2.2.1. Recommendation against Accounting-Request 2.2.1. Recommendation against Accounting-Request
For the reasons outlined above, NAS implementors SHOULD NOT generate For the reasons outlined above, NAS implementors SHOULD NOT generate
Accounting-Request packets solely to see if a server is alive. Accounting-Request packets solely to see if a server is alive.
Similarly, site administrators SHOULD NOT configure accounting Similarly, site administrators SHOULD NOT configure accounting
policies whose sole reason for existence is to enable such queries policies whose sole reason for existence is to enable such queries
via Accounting-Request packets. via Accounting-Request packets.
Note that it still may be useful to configure test users for the Note that it still may be useful to configure test users for the
purpose of performing end-to-end or in-depth testing of a servers purpose of performing end-to-end or in-depth testing of a server's
policy. While this practice is widespread, we caution administrators policy. While this practice is widespread, we caution administrators
to use it with care. to use it with care.
3. Packet Format 3. Packet Format
Status-Server packets reuse the RADIUS packet format, with the fields Status-Server packets reuse the RADIUS packet format, with the fields
and values for those fields as defined [RFC2865] Section 3. We do and values for those fields as defined in [RFC2865], Section 3. We
not include all of the text or diagrams of that section here, but do not include all of the text or diagrams of that section here, but
instead explain the differences required to implement Status-Server. instead explain the differences required to implement Status-Server.
The Authenticator field of Status-Server packets MUST be generated The Authenticator field of Status-Server packets MUST be generated
using the same method as that used for the Request Authenticator using the same method as that used for the Request Authenticator
field of Access-Request packets, as given below. field of Access-Request packets, as given below.
The role of the Identifier field is the same for Status-Server as for The role of the Identifier field is the same for Status-Server as for
other packets. However, as Status-Server is taking the role of other packets. However, as Status-Server is taking the role of
Access-Request or Accounting-Request packets, there is the potential Access-Request or Accounting-Request packets, there is the potential
for Status-Server requests to be in conflict with Access-Request or for Status-Server requests to be in conflict with Access-Request or
Accounting-Request packets with the same Identifier. In Section 4.2, Accounting-Request packets with the same Identifier. In Section 4.2
below, we describe a method for avoiding these problems. This method below, we describe a method for avoiding these problems. This method
MUST be used to avoid conflicts between Status-Server and other MUST be used to avoid conflicts between Status-Server and other
packet types. packet types.
Request Authenticator Request Authenticator
In Status-Server Packets, the Authenticator value is a 16 octet In Status-Server packets, the Authenticator value is a 16-octet
random number, called the Request Authenticator. The value random number called the Request Authenticator. The value
SHOULD be unpredictable and unique over the lifetime of a SHOULD be unpredictable and unique over the lifetime of a
secret (the password shared between the client and the RADIUS secret (the password shared between the client and the RADIUS
server), since repetition of a request value in conjunction server), since repetition of a request value in conjunction
with the same secret would permit an attacker to reply with a with the same secret would permit an attacker to reply with a
previously intercepted response. Since it is expected that the previously intercepted response. Since it is expected that the
same secret MAY be used to authenticate with servers in same secret MAY be used to authenticate with servers in
disparate geographic regions, the Request Authenticator field disparate geographic regions, the Request Authenticator field
SHOULD exhibit global and temporal uniqueness. See [RFC4086] SHOULD exhibit global and temporal uniqueness. See [RFC4086]
for suggestions as to how random numbers may be generated. for suggestions as to how random numbers may be generated.
skipping to change at page 10, line 10 skipping to change at page 9, line 7
Similarly, the Response Authenticator field of an Access-Accept Similarly, the Response Authenticator field of an Access-Accept
packet sent in response to Status-Server queries MUST be generated packet sent in response to Status-Server queries MUST be generated
using the same method as used for calculating the Response using the same method as used for calculating the Response
Authenticator of the Access-Accept sent in response to an Access- Authenticator of the Access-Accept sent in response to an Access-
Request, with the Status-Server Request Authenticator taking the Request, with the Status-Server Request Authenticator taking the
place of the Access-Request Request Authenticator. place of the Access-Request Request Authenticator.
The Response Authenticator field of an Accounting-Response packet The Response Authenticator field of an Accounting-Response packet
sent in response to Status-Server queries MUST be generated using the sent in response to Status-Server queries MUST be generated using the
same method as used for for calculating the Response Authenticator of same method as used for calculating the Response Authenticator of the
the Accounting-Response sent in response to an Accounting-Request, Accounting-Response sent in response to an Accounting-Request, with
with the Status-Server Request Authenticator taking the place of the the Status-Server Request Authenticator taking the place of the
Accounting-Request Request Authenticator. Accounting-Request Request Authenticator.
Note that when a server responds to a Status-Server request, it MUST Note that when a server responds to a Status-Server request, it MUST
NOT send more than one response packet. NOT send more than one Response packet.
Response Authenticator Response Authenticator
The value of the Authenticator field in Access-Accept, or The value of the Authenticator field in Access-Accept or
Accounting-Response packets is called the Response Accounting-Response packets is called the Response
Authenticator, and contains a one-way MD5 hash calculated over Authenticator, and contains a one-way MD5 hash calculated over
a stream of octets consisting of: the RADIUS packet, beginning a stream of octets consisting of: the RADIUS packet, beginning
with the Code field, including the Identifier, the Length, the with the Code field, including the Identifier, the Length, the
Request Authenticator field from the Status-Server packet, and Request Authenticator field from the Status-Server packet, and
the response Attributes (if any), followed by the shared the response Attributes (if any), followed by the shared
secret. That is, ResponseAuth = secret. That is,
MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
denotes concatenation. ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
where + denotes concatenation.
In addition to the above requirements, all Status-Server packets MUST In addition to the above requirements, all Status-Server packets MUST
include a Message-Authenticator attribute. Failure to do so would include a Message-Authenticator attribute. Failure to do so would
mean that the packets could be trivially spoofed. mean that the packets could be trivially spoofed.
Status-Server packets MAY include NAS-Identifier, and one of NAS-IP- Status-Server packets MAY include NAS-Identifier, and one of
Address or NAS-IPv6-Address. These attributes are not necessary for NAS-IP-Address or NAS-IPv6-Address. These attributes are not
the operation of Status-Server, but may be useful information to a necessary for the operation of Status-Server, but may be useful
server that receives those packets. information to a server that receives those packets.
Other attributes SHOULD NOT be included in a Status-Server packet, Other attributes SHOULD NOT be included in a Status-Server packet,
and MUST be ignored if they are included. User authentication and MUST be ignored if they are included. User authentication
credentials such as User-Name, User-Password, CHAP-Password, EAP- credentials such as User-Name, User-Password, CHAP-Password,
Message, etc., MUST NOT appear in a Status-Server packet sent to a EAP-Message MUST NOT appear in a Status-Server packet sent to a
RADIUS authentication port. User or NAS accounting attributes such RADIUS authentication port. User or NAS accounting attributes such
as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc., MUST as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT
NOT appear in a Status-Server packet sent to a RADIUS accounting appear in a Status-Server packet sent to a RADIUS accounting port.
port.
The Access-Accept MAY contain a Reply-Message or Message- The Access-Accept MAY contain a Reply-Message or Message-
Authenticator attribute. It SHOULD NOT contain other attributes. Authenticator attribute. It SHOULD NOT contain other attributes.
The Accounting-Response packets sent in response to a Status-Server The Accounting-Response packets sent in response to a Status-Server
query SHOULD NOT contain any attributes. As the intent is to query SHOULD NOT contain any attributes. As the intent is to
implement a simple query instead of user authentication or implement a simple query instead of user authentication or
accounting, there is little reason to include other attributes in accounting, there is little reason to include other attributes in
either the query or the corresponding response. either the query or the corresponding response.
Examples of Status-Server packet flows are given below in Section 7. Examples of Status-Server packet flows are given below in Section 6.
3.1. Single definition for Status-Server 3.1. Single Definition for Status-Server
When sent to a RADIUS accounting port, contents of the Status-Server When sent to a RADIUS accounting port, the contents of the Status-
packets are calculated as described above. That is, even though the Server packets are calculated as described above. That is, even
packets are being sent to an accounting port, they are not created though the packets are being sent to an accounting port, they are not
using the same method as for Accounting-Requests. This difference created using the same method as is used for Accounting-Requests.
has a number of benefits. This difference has a number of benefits.
Having a single definition for Status-Server packets is simpler than Having a single definition for Status-Server packets is simpler than
having different definitions for different destination ports. In having different definitions for different destination ports. In
addition, if we were to define Status-Server as being similar to addition, if we were to define Status-Server as being similar to
Accounting-Request but containing no attributes, then those packets Accounting-Request but containing no attributes, then those packets
could be trivially forged. could be trivially forged.
We therefore define Status-Server consistently, and vary the response We therefore define Status-Server consistently, and vary the response
packets depending on the port to which the request is sent. When packets depending on the port to which the request is sent. When
sent to an authentication port, the response to a Status-Server query sent to an authentication port, the response to a Status-Server query
is an Access-Accept packet. When sent to an accounting port, the is an Access-Accept packet. When sent to an accounting port, the
response to a Status-Server query is an Accounting-Response packet. response to a Status-Server query is an Accounting-Response packet.
4. Implementation notes 4. Implementation Notes
There are a number of considerations to take into account when There are a number of considerations to take into account when
implementing support for Status-Server. This section describes implementing support for Status-Server. This section describes
implementation details and requirements for RADIUS clients and implementation details and requirements for RADIUS clients and
servers that support Status-Server. servers that support Status-Server.
The following text applies to the authentication and accounting The following text applies to the authentication and accounting
ports. We use the generic terms below to simplify the discussion: ports. We use the generic terms below to simplify the discussion:
* Request packet * Request packet
An Access-Request packet sent to an authentication port, or An Access-Request packet sent to an authentication port or an
an Accounting-Request packet sent to an accounting port. Accounting-Request packet sent to an accounting port.
* Response packet * Response packet
An Access-Accept, Access-Challenge, or Access-Reject packet sent An Access-Accept, Access-Challenge, or Access-Reject packet
from an authentication port, or an Accounting-Response packet sent from an authentication port or an Accounting-Response
sent from an accounting port. packet sent from an accounting port.
We also refer to "client" as the originator of the Status-Server We also refer to "client" as the originator of the Status-Server
packet, and "server" as the receiver of that packet, and the packet, and "server" as the receiver of that packet and the
originator of the Response packet. originator of the Response packet.
Using generic terms to describe the Status-Server conversations is Using generic terms to describe the Status-Server conversations is
simpler than duplicating the text for authentication and accounting simpler than duplicating the text for authentication and accounting
packets. packets.
4.1. Client Requirements 4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be that the generation of Status-Server packets. The default SHOULD be that
it is disabled. As it is undesirable to send queries to servers that it is disabled. As it is undesirable to send queries to servers that
do not support Status-Server, clients SHOULD also have a per-server do not support Status-Server, clients SHOULD also have a per-server
configuration indicating whether or not to enable Status-Server for a configuration indicating whether or not to enable Status-Server for a
particular destination. The default SHOULD be that it is disabled. particular destination. The default SHOULD be that it is disabled.
The client SHOULD use a watchdog timer such as defined in Section The client SHOULD use a watchdog timer, such as is defined in Section
2.2.1 of [RFC5080] to determine when to send Status-Server packets. 2.2.1 of [RFC5080], to determine when to send Status-Server packets.
When Status-Server packets are sent from a client, they MUST NOT be When Status-Server packets are sent from a client, they MUST NOT be
retransmitted. Instead, the Identity field MUST be changed every retransmitted. Instead, the Identity field MUST be changed every
time a packet is transmitted. The old packet should be discarded, time a packet is transmitted. The old packet should be discarded,
and a new Status-Server packet should be generated and sent, with new and a new Status-Server packet should be generated and sent, with new
Identity and Authenticator fields. Identity and Authenticator fields.
Clients MUST include the Message-Authenticator attribute in all Clients MUST include the Message-Authenticator attribute in all
Status-Server packets. Failure to do so would mean that the packets Status-Server packets. Failure to do so would mean that the packets
could be trivially spoofed, leading to potential denial of service could be trivially spoofed, leading to potential denial-of-service
(DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server
packet, except as outlined below in Section 6. As the intent of the packet, except as outlined below in Section 5. As the intent of the
packet is a simple status query, there is little reason for any packet is a simple status query, there is little reason for any
additional attributes to appear in Status-Server packets. additional attributes to appear in Status-Server packets.
The client MAY increment packet counters as a result of sending a The client MAY increment packet counters as a result of sending a
Status-Server request, or receiving a Response packet. The client Status-Server request or of receiving a Response packet. The client
MUST NOT perform any other action that is normally performed when it MUST NOT perform any other action that is normally performed when it
receives a Response packet, such as permitting a user to have login receives a Response packet, such as permitting a user to have login
access to a port. access to a port.
Clients MAY send Status-Server requests to the RADIUS destination Clients MAY send Status-Server requests to the RADIUS destination
ports from the same source port used to send normal Request packets. ports from the same source port used to send normal Request packets.
Other clients MAY choose to send Status-Server requests from a unique Other clients MAY choose to send Status-Server requests from a unique
source port, that is not used to send Request packets. source port that is not used to send Request packets.
The above suggestion for a unique source port for Status-Server The above suggestion for a unique source port for Status-Server
packets aids in matching responses to requests. Since the response packets aids in matching responses to requests. Since the response
to a Status-Server packet is an Access-Accept or Accounting-Response to a Status-Server packet is an Access-Accept or Accounting-Response
packet, those responses are indistinguishable from other packets sent packet, those responses are indistinguishable from other packets sent
in response to a Request packet. Therefore, the best way to in response to a Request packet. Therefore, the best way to
distinguish them from other traffic is to have a unique port. distinguish them from other traffic is to have a unique port.
A client MAY send a Status-Server packet from a source port also used A client MAY send a Status-Server packet from a source port also used
to send Request packets. In that case, the Identifier field MUST be to send Request packets. In that case, the Identifier field MUST be
unique across all outstanding Request packets for that source port, unique across all outstanding Request packets for that source port,
independent of the value of the RADIUS Code field for those independent of the value of the RADIUS Code field for those
outstanding requests. Once the client has either received a response outstanding requests. Once the client has either received a response
to the Status-Server packet, or has determined that the Status-Server to the Status-Server packet or determined that the Status-Server
packet has timed out, it may reuse that Identifier in another packet. packet has timed out, it may reuse that Identifier in another packet.
Robust implementations SHOULD accept any Response packet as a valid Robust implementations SHOULD accept any Response packet as a valid
response to a Status-Server packet, subject to the validation response to a Status-Server packet, subject to the validation
requirements defined above for the Response Authenticator. The code requirements defined above for the Response Authenticator. The Code
field of the packet matters less than the fact that a valid, signed, field of the packet matters less than the fact that a valid, signed
response has been received. response has been received.
That is, prior to accepting the response as valid, the client should That is, prior to accepting the response as valid, the client should
check that the Response packet Code field is either Access-Accept (2) check that the Response packet Code field is either Access-Accept (2)
or Accounting-Response (5). If the code does not match any of these or Accounting-Response (5). If the Code does not match any of these
values, the packet MUST be silently discarded. The client MUST then values, the packet MUST be silently discarded. The client MUST then
validate the Response Authenticator via the algorithm given above in validate the Response Authenticator via the algorithm given above in
Section 3. If the Response Authenticator is not valid, the packet Section 3. If the Response Authenticator is not valid, the packet
MUST be silently discarded. If the Response Authenticator is valid, MUST be silently discarded. If the Response Authenticator is valid,
then the packet MUST be deemed to be a valid response from the then the packet MUST be deemed to be a valid response from the
server. server.
If the client instead discarded the response because the packet code If the client instead discarded the response because the packet Code
did not match what it expected, then it could erroneously discard did not match what it expected, then it could erroneously discard
valid responses from a server, and mark that server as unresponsive. valid responses from a server, and mark that server as unresponsive.
This behavior would affect the stability of a RADIUS network, as This behavior would affect the stability of a RADIUS network, as
responsive servers would erroneously be marked as unresponsive. We responsive servers would erroneously be marked as unresponsive. We
therefore recommend that clients should be liberal in what they therefore recommend that clients should be liberal in what they
accept as responses to Status-Server queries. accept as responses to Status-Server queries.
4.2. Server Requirements 4.2. Server Requirements
Servers SHOULD permit administrators to globally enable or disable Servers SHOULD permit administrators to globally enable or disable
the acceptance of Status-Server packets. The default SHOULD be that the acceptance of Status-Server packets. The default SHOULD be that
it is enabled. Servers SHOULD also permit administrators to enable acceptance is enabled. Servers SHOULD also permit administrators to
or disable acceptance of Status-Server packets on a per-client basis. enable or disable acceptance of Status-Server packets on a per-client
The default SHOULD be that it is enabled. basis. The default SHOULD be that acceptance is enabled.
Status-Server packets originating from clients that are not permitted Status-Server packets originating from clients that are not permitted
to send the server Request packets MUST be silently discarded. If a to send the server Request packets MUST be silently discarded. If a
server does not support Status-Server packets, or is configured to server does not support Status-Server packets, or is configured not
not respond to them, then it MUST silently discard the packet. to respond to them, then it MUST silently discard the packet.
We note that [RFC2865] Section 3 defines a number of RADIUS Codes, We note that [RFC2865], Section 3, defines a number of RADIUS Codes,
but does not make statements about which Codes are valid for port but does not make statements about which Codes are valid for
1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS port 1812. In contrast, [RFC2866], Section 3, specifies that only
Accounting packets are to be sent to port 1813. This specification RADIUS Accounting packets are to be sent to port 1813. This
is compatible with [RFC2865], as it uses a known Code for packets to specification is compatible with [RFC2865], as it uses a known Code
port 1812. This specification is not compatible with [RFC2866], as for packets to port 1812. This specification is not compatible with
it adds a new code (Status-Server) that is valid for port 1812. [RFC2866], as it adds a new Code (Status-Server) that is valid for
However, as the category of [RFC2866] is Informational, this conflict port 1812. However, as the category of [RFC2866] is Informational,
is acceptable. this conflict is acceptable.
Servers SHOULD silently discard Status-Server packets if they Servers SHOULD silently discard Status-Server packets if they
determine that a client is sending too many Status-Server requests in determine that a client is sending too many Status-Server requests in
a particular time period. The method used by a server to make this a particular time period. The method used by a server to make this
determination is implementation-specific, and out of scope for this determination is implementation specific and out of scope for this
specification. specification.
If a server supports Status-Server packets, and is configured to If a server supports Status-Server packets, and is configured to
respond to them, and receives a packet from a known client, it MUST respond to them, and receives a packet from a known client, it MUST
validate the Message-Authenticator attribute as defined in [RFC3579] validate the Message-Authenticator attribute as defined in [RFC3579],
Section 3.2. Packets failing that validation MUST be silently Section 3.2. Packets failing that validation MUST be silently
discarded. discarded.
Servers SHOULD NOT otherwise discard Status-Server packets if they Servers SHOULD NOT otherwise discard Status-Server packets if they
have recently sent the client a Response packet. The query may have have recently sent the client a Response packet. The query may have
originated from an administrator who does not have access to the originated from an administrator who does not have access to the
Response packet stream, or who is interested in obtaining additional Response packet stream or one who is interested in obtaining
information about the server. additional information about the server.
The server MAY prioritize the handling of Status-Server packets over The server MAY prioritize the handling of Status-Server packets over
the handling of other requests, subject to the rate limiting the handling of other requests, subject to the rate limiting
described above. described above.
The server MAY decide to not respond to a Status-Server, depending on The server MAY decide not to respond to a Status-Server, depending on
local site policy. For example, a server that is running but is local-site policy. For example, a server that is running but is
unable to perform its normal activities MAY silently discard Status- unable to perform its normal activities MAY silently discard Status-
Server packets. This situation can happen, for example, when a Server packets. This situation can happen, for example, when a
server requires access to a database for normal operation, but the server requires access to a database for normal operation, but the
connection to that database is down. Or, it may happen when the connection to that database is down. Or, it may happen when the
accepted load on the server is lower than the offered load. accepted load on the server is lower than the offered load.
Some server implementations require that Access-Request packets are Some server implementations require that Access-Request packets be
accepted only on "authentication" ports, (e.g., 1812/udp), and that accepted only on "authentication" ports (e.g., 1812/udp), and that
Accounting-Request packets are accepted only on "accounting" ports Accounting-Request packets be accepted only on "accounting" ports
(e.g., 1813/udp). Those implementations SHOULD reply to Status- (e.g., 1813/udp). Those implementations SHOULD reply to Status-
Server packets sent to an "authentication" port with an Access-Accept Server packets sent to an "authentication" port with an Access-Accept
packet. Those implementations SHOULD reply to Status-Server packets packet and SHOULD reply to Status-Server packets sent to an
sent to an "accounting" port with an Accounting-Response packet. "accounting" port with an Accounting-Response packet.
Some server implementations accept both Access-Request and Some server implementations accept both Access-Request and
Accounting-Request packets on the same port, and do not distinguish Accounting-Request packets on the same port, and they do not
between "authentication only" ports, and "accounting only" ports. distinguish between "authentication only" ports and "accounting only"
Those implementations SHOULD reply to Status-Server packets with an ports. Those implementations SHOULD reply to Status-Server packets
Access-Accept packet. with an Access-Accept packet.
The server MAY increment packet counters as a result of receiving a The server MAY increment packet counters as a result of receiving a
Status-Server, or sending a Response packet. The server SHOULD NOT Status-Server packet or sending a Response packet. The server SHOULD
perform any other action that is normally performed when it receives NOT perform any other action that is normally performed when it
a Request packet, other than sending a Response packet. receives a Request packet, other than sending a Response packet.
4.3. Fail-over with Status-Server 4.3. Failover with Status-Server
A client may wish to failover from one proxy to another in the event A client may wish to "failover" from one proxy to another in the
that it does not receive a response to an Access-Request or event that it does not receive a response to an Access-Request or
Accounting-Request. In order to determine whether the lack of Accounting-Request. In order to determine whether the lack of
response is due to a problem with the proxy or a downstream server, response is due to a problem with the proxy or a downstream server,
the client can send periodic Status-Server packets to a proxy after the client can send periodic Status-Server packets to a proxy after
lack of a response. the lack of a response.
These packets will help the client determine if the failure was due These packets will help the client determine if the failure was due
to an issue on the path between the client and proxy or the proxy to an issue on the path between the client and proxy or the proxy
itself, or whether the issue is occurring downstream. itself, or whether the issue is occurring downstream.
If no response is received to Status-Server packets, the RADIUS If no response is received to Status-Server packets, the RADIUS
client can initiate failover to another proxy. By continuing to send client can initiate failover to another proxy. By continuing to send
Status-Server packets to the original proxy, the RADIUS client can Status-Server packets to the original proxy, the RADIUS client can
determine when it becomes responsive again. determine when it becomes responsive again.
Once the server has been deemed responsive, normal RADIUS requests Once the server has been deemed responsive, normal RADIUS requests
may sent to it again. This determination should be made separately may be sent to it again. This determination should be made
for each server that the client has a relationship with. The same separately for each server with which the client has a relationship.
algorithm SHOULD be used for both authentication and accounting The same algorithm SHOULD be used for both authentication and
ports. The client MUST treat each destination (IP, port) combination accounting ports. The client MUST treat each destination (IP, port)
as a unique server for the purposes of this determination. combination as a unique server for the purposes of this
determination.
Clients SHOULD use a retransmission mechanism similar to that given Clients SHOULD use a retransmission mechanism similar to that given
in Section 2.2.1 of [RFC5080]. If a reliable transport is used for in Section 2.2.1 of [RFC5080]. If a reliable transport is used for
RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST
be used. be used.
4.4. Proxy Server handling of Status-Server 4.4. Proxy Server Handling of Status-Server
Many RADIUS servers can act as proxy servers, and can forward Many RADIUS servers can act as proxy servers, and can forward
requests to another RADIUS server. Such servers MUST NOT proxy requests to another RADIUS server. Such servers MUST NOT proxy
Status-Server packets. The purpose of Status-Server as specified Status-Server packets. The purpose of Status-Server as specified
here is to permit the client to query the responsiveness of a server here is to permit the client to query the responsiveness of a server
that it has a direct relationship with. Proxying Status-Server with which it has a direct relationship. Proxying Status-Server
queries would negate any usefulness that may be gained by queries would negate any usefulness that may be gained by
implementing support for them. implementing support for them.
Proxy servers MAY be configured to respond to Status-Server queries Proxy servers MAY be configured to respond to Status-Server queries
from clients, and MAY act as clients sending Status-Server queries to from clients, and they MAY act as clients sending Status-Server
other servers. However, those activities MUST be independent of one queries to other servers. However, those activities MUST be
another. independent of one another.
4.5. Limitations of Status-Server 4.5. Limitations of Status-Server
RADIUS servers are commonly used in an environment where Network RADIUS servers are commonly used in an environment where Network
Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. Access Identifiers (NAIs) are used as routing identifiers [RFC4282].
In this practice, the User-Name attribute is decorated with realm In this practice, the User-Name attribute is decorated with realm-
routing information, commonly in the format of "user@realm". Since a routing information, commonly in the format of "user@realm". Since a
particular RADIUS server may act as a proxy for more than one realm, particular RADIUS server may act as a proxy for more than one realm,
we need to explain how the behavior defined above in Section 4.3, we need to explain how the behavior defined above in Section 4.3
above, affects realm routing. affects realm routing.
The schematic below demonstrates this scenario. The schematic below demonstrates this scenario.
/-> RADIUS Proxy P -----> RADIUS Server for Realm A /-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ / / \ /
NAS X NAS X
\ / \ \ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B \-> RADIUS Proxy S -----> RADIUS Server for Realm B
That is, the NAS has relationships with two RADIUS Proxies, P and S. That is, the NAS has relationships with two RADIUS Proxies, P and S.
Each RADIUS Proxy has relationships with RADIUS Servers for both Each RADIUS proxy has relationships with RADIUS servers for both
Realm A and Realm B. Realm A and Realm B.
In this scenario, the RADIUS Proxies can determine if one or both of In this scenario, the RADIUS proxies can determine if one or both of
the RADIUS Servers are dead or unreachable. The NAS can determine if the RADIUS servers are dead or unreachable. The NAS can determine if
one or both of the RADIUS Proxies are dead or unreachable. There is one or both of the RADIUS proxies are dead or unreachable. There is
an additional case to consider, however. an additional case to consider, however.
If RADIUS Proxy P cannot reach the RADIUS Server for Realm A, but the If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but
RADIUS Proxy S can reach that RADIUS Server, then the NAS cannot RADIUS Proxy S can reach that RADIUS server, then the NAS cannot
discover this information using the Status-Server queries as outlined discover this information using the Status-Server queries as outlined
above. It would therefore be useful for the NAS to know that Realm A above. It would therefore be useful for the NAS to know that Realm A
is reachable from RADIUS Proxy S, as it can then route all requests is reachable from RADIUS Proxy S, as it can then route all requests
for Realm A to that RADIUS Proxy. Without this knowledge, the client for Realm A to that RADIUS proxy. Without this knowledge, the client
may route requests to RADIUS Proxy P, where they may be discarded or may route requests to RADIUS Proxy P, where they may be discarded or
rejected. rejected.
To complicate matters, the behavior of RADIUS Proxies P and S in this To complicate matters, the behavior of RADIUS Proxies P and S in this
situation is not well defined. Some implementations simply fail to situation is not well defined. Some implementations simply fail to
respond to the request, and other implementations respond with an respond to the request, and other implementations respond with an
Access-Reject. If the implementation fails to respond, then the NAS Access-Reject. If the implementation fails to respond, then the NAS
cannot distinguish between the RADIUS Proxy being down, or the next cannot distinguish between the RADIUS proxy being down and the next
server along the proxy chain being unreachable. server along the proxy chain being unreachable.
In the worst case, failures in routing for Realm A may affect users In the worst case, failures in routing for Realm A may affect users
of Realm B. For example, if RADIUS Proxy P can reach Realm B but not of Realm B. For example, if RADIUS Proxy P can reach Realm B but not
Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then
active paths exist to handle all RADIUS requests. However, depending active paths exist to handle all RADIUS requests. However, depending
on the NAS and RADIUS Proxy implementation choices, the NAS may not on the NAS and RADIUS proxy implementation choices, the NAS may not
be able to determine which server requests may be sent to in order to be able to determine to which server requests may be sent in order to
maintain network stability. maintain network stability.
This problem cannot unfortunately be solved by using Status-Server Unfortunately, this problem cannot be solved by using Status-Server
requests. A robust solution would involve either a RADIUS routing requests. A robust solution would involve either a RADIUS routing
table for the NAI realms, or a RADIUS "destination unreachable" table for the NAI realms or a RADIUS "destination unreachable"
response to authentication requests. Either solution would not fit response to authentication requests. Either solution would not fit
into the traditional RADIUS model, and both are therefore outside of into the traditional RADIUS model, and both are therefore outside of
the scope of this specification. the scope of this specification.
The problem is discussed here in order to define how best to use The problem is discussed here in order to define how best to use
Status-Server in this situation, rather than to define a new Status-Server in this situation, rather than to define a new
solution. solution.
When a server has responded recently to a request from a client, that When a server has responded recently to a request from a client, that
client MUST mark the server as "responsive". In the above case, a client MUST mark the server as "responsive". In the above case, a
RADIUS Proxy may be responding to requests destined for Realm A, but RADIUS proxy may be responding to requests destined for Realm A, but
not responding to requests destined for Realm B. The client not responding to requests destined for Realm B. The client
therefore considers the server to be responsive, as it is receiving therefore considers the server to be responsive, as it is receiving
responses from the server. responses from the server.
The client will then continue to send requests to the RADIUS Proxy The client will then continue to send requests to the RADIUS proxy
for destination Realm B, even though the RADIUS Proxy cannot route for destination Realm B, even though the RADIUS proxy cannot route
the requests to that destination. This failure is a known limitation the requests to that destination. This failure is a known limitation
of RADIUS, and can be partially addressed through the use of failover of RADIUS, and can be partially addressed through the use of failover
in the RADIUS Proxies. in the RADIUS proxies.
A more realistic situation than the one outlined above is where each A more realistic situation than the one outlined above is one in
RADIUS Proxy also has multiple choices of RADIUS Servers for a realm, which each RADIUS proxy also has multiple choices of RADIUS servers
as outlined below. for a realm, as outlined below.
/-> RADIUS Proxy P -----> RADIUS Server P /-> RADIUS Proxy P -----> RADIUS Server P
/ \ / / \ /
NAS X NAS X
\ / \ \ / \
\-> RADIUS Proxy S -----> RADIUS Server S \-> RADIUS Proxy S -----> RADIUS Server S
In this situation, if all participants implement Status-Server as In this situation, if all participants implement Status-Server as
defined herein, any one link may be broken, and all requests from the defined herein, any one link may be broken, and all requests from the
NAS will still reach a RADIUS Server. If two links are broken at NAS will still reach a RADIUS server. If two links are broken at
different places, (i.e., not both links from the NAS), then all different places (i.e., not both links from the NAS), then all
requests from the NAS will still reach a RADIUS Server. In many requests from the NAS will still reach a RADIUS server. In many
situations where three or more links are broken, then requests from situations where three or more links are broken, requests from the
the NAS may still reach a RADIUS Server. NAS may still reach a RADIUS server.
It is RECOMMENDED, therefore, that implementations desiring the most It is RECOMMENDED, therefore, that implementations desiring the most
benefit from Status-Server also implement server failover. The benefit from Status-Server also implement server failover. The
combination of these two practices will maximize network reliability combination of these two practices will maximize network reliability
and stability. and stability.
4.6. Management Information Base (MIB) Considerations 4.6. Management Information Base (MIB) Considerations
4.6.1. Interaction with RADIUS Server MIB modules 4.6.1. Interaction with RADIUS Server MIB Modules
Since Status-Server packets are sent to the defined RADIUS ports, Since Status-Server packets are sent to the defined RADIUS ports,
they can affect the [RFC4669] and [RFC4671] RADIUS server MIB they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
modules. [RFC4669] defines a counter named modules. [RFC4669] defines a counter named
radiusAuthServTotalUnknownTypes that counts "The number of RADIUS radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
packets of unknown type that were received". [RFC4671] defines a packets of unknown type that were received". [RFC4671] defines a
similar counter named radiusAcctServTotalUnknownTypes. similar counter named radiusAccServTotalUnknownTypes.
Implementations not supporting Status-Server, or implementations that Implementations not supporting Status-Server or implementations that
are configured to not respond to Status-Server packets MUST use these are configured not to respond to Status-Server packets MUST use these
counters to track received Status-Server packets. counters to track received Status-Server packets.
If, however, Status-Server is supported and the server is configured If, however, Status-Server is supported and the server is configured
to respond as described above, then the counters defined in [RFC4669] to respond as described above, then the counters defined in [RFC4669]
and [RFC4671] MUST NOT be used to track Status-Server requests or and [RFC4671] MUST NOT be used to track Status-Server requests or
responses to those requests. That is, when a server fully implements responses to those requests. That is, when a server fully implements
Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
be unaffected by the transmission or reception of packets relating to be unaffected by the transmission or reception of packets relating to
Status-Server. Status-Server.
If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
Modules, then it SHOULD also support vendor-specific MIB extensions modules, then it SHOULD also support vendor-specific MIB extensions
dedicated solely to tracking Status-Server requests and responses. dedicated solely to tracking Status-Server requests and responses.
Any definition of the server MIB modules for Status-Server is outside Any definition of the server MIB modules for Status-Server is outside
of the scope of this document. of the scope of this document.
4.6.2. Interaction with RADIUS Client MIB modules 4.6.2. Interaction with RADIUS Client MIB Modules
Clients implementing Status-Server MUST NOT increment [RFC4668] or Clients implementing Status-Server MUST NOT increment [RFC4668] or
[RFC4670] counters upon reception of Response packets to Status- [RFC4670] counters upon reception of Response packets to Status-
Server queries. That is, when a server fully implements Status- Server queries. That is, when a server fully implements Status-
Server, the counters defined in [RFC4668] and [RFC4670] MUST be Server, the counters defined in [RFC4668] and [RFC4670] MUST be
unaffected by the transmission or reception of packets relating to unaffected by the transmission or reception of packets relating to
Status-Server. Status-Server.
If an implementation supports Status-Server and the [RFC4668] or If an implementation supports Status-Server and the [RFC4668] or
[RFC4670] MIB modules, then it SHOULD also support vendor-specific [RFC4670] MIB modules, then it SHOULD also support vendor-specific
MIB extensions dedicated solely to tracking Status-Server requests MIB extensions dedicated solely to tracking Status-Server requests
and responses. Any definition of the client MIB module extensions and responses. Any definition of the client MIB modules for Status-
for Status-Server is outside of the scope of this document. Server is outside of the scope of this document.
5. Table of Attributes 5. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in Status-Server packets, and in what quantity. Attributes other in Status-Server packets, and in what quantity. Attributes other
than the ones listed below SHOULD NOT be found in a Status-Server than the ones listed below SHOULD NOT be found in a Status-Server
packet. packet.
Status- Access- Accounting- Status- Access- Accounting-
Server Accept Response # Attribute Server Accept Response # Attribute
0 0 0 1 User-Name, 0 0 0 1 User-Name
0 0 0 2 User-Password 0 0 0 2 User-Password
0 0 0 3 CHAP-Password 0 0 0 3 CHAP-Password
0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1)
0 0+ 0 18 Reply-Message 0 0+ 0 18 Reply-Message
0+ 0+ 0+ 26 Vendor-Specific 0+ 0+ 0+ 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier (Note 1) 0-1 0 0 32 NAS-Identifier (Note 1)
0 0 0 70 EAP-Message 0 0 0 79 EAP-Message
1 0-1 0-1 80 Message-Authenticator 1 0-1 0-1 80 Message-Authenticator
0-1 0 0 95 NAS-IPv6-Address (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1)
0 0 0 103-121 Digest-* 0 0 0 103-121 Digest-*
Note 1: A Status-Server SHOULD contain one of (NAS-IP-Address or NAS- Note 1: A Status-Server packet SHOULD contain one of
IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both
(NAS-IP-Address or NAS-IPv6-Address). NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet. 0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet. 0+ Zero or more instances of this attribute MAY be present in
0-1 Zero or one instance of this attribute MAY be present in packet. packet.
1 Exactly one instance of this attribute MUST be present in packet. 0-1 Zero or one instance of this attribute MAY be present in
packet.
1 Exactly one instance of this attribute MUST be present in
packet.
6. Examples 6. Examples
A few examples are presented to illustrate the flow of packets to A few examples are presented to illustrate the flow of packets to
both the authentication and accounting ports. These examples are not both the authentication and accounting ports. These examples are not
intended to be exhaustive, many others are possible. Hexadecimal intended to be exhaustive; many others are possible. Hexadecimal
dumps of the example packets are given in network byte order, using dumps of the example packets are given in network byte order, using
the shared secret "xyzzy5461". the shared secret "xyzzy5461".
6.1. Minimal Query to Authentication Port 6.1. Minimal Query to Authentication Port
The NAS sends a Status-Server UDP packet with minimal content to a The NAS sends a Status-Server UDP packet with minimal content to a
RADIUS server on port 1812. RADIUS server on port 1812.
The Request Authenticator is a 16 octet random number generated by The Request Authenticator is a 16-octet random number generated by
the NAS. Message-Authenticator is included in order to authenticate the NAS. Message-Authenticator is included in order to authenticate
that the request came from a known client. that the request came from a known client.
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
82 20 97 c8 4f a3 82 20 97 c8 4f a3
1 Code = Status-Server (12) 1 Code = Status-Server (12)
1 ID = 218 1 ID = 218
2 Length = 38 2 Length = 38
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
The Response Authenticator is a 16 octet MD5 checksum of the code The Response Authenticator is a 16-octet MD5 checksum of the Code
(2), id (218), Length (20), the Request Authenticator from above, and (2), ID (218), Length (20), the Request Authenticator from above, and
the shared secret. the shared secret.
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
b5 41 1d 66 b5 41 1d 66
1 Code = Access-Accept (2) 1 Code = Access-Accept (2)
1 ID = 218 1 ID = 218
2 Length = 20 2 Length = 20
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
None. None.
6.2. Minimal Query to Accounting Port 6.2. Minimal Query to Accounting Port
The NAS sends a Status-Server UDP packet with minimal content to a The NAS sends a Status-Server UDP packet with minimal content to a
RADIUS server on port 1813. RADIUS server on port 1813.
The Request Authenticator is a 16 octet random number generated by The Request Authenticator is a 16-octet random number generated by
the NAS. Message-Authenticator is included in order to authenticate the NAS. Message-Authenticator is included in order to authenticate
that the request came from a known client. that the request came from a known client.
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
da de 26 36 78 58 da de 26 36 78 58
1 Code = Status-Server (12) 1 Code = Status-Server (12)
1 ID = 179 1 ID = 179
2 Length = 38 2 Length = 38
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
The Response Authenticator is a 16 octet MD5 checksum of the code The Response Authenticator is a 16-octet MD5 checksum of the Code
(5), id (179), Length (20), the Request Authenticator from above, and (5), ID (179), Length (20), the Request Authenticator from above, and
the shared secret. the shared secret.
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
48 60 66 9c 48 60 66 9c
1 Code = Accounting-Response (5) 1 Code = Accounting-Response (5)
1 ID = 179 1 ID = 179
2 Length = 20 2 Length = 20
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
None. None.
6.3. Verbose Query and Response 6.3. Verbose Query and Response
The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS
server on port 1812. server on port 1812.
The Request Authenticator is a 16 octet random number generated by The Request Authenticator is a 16-octet random number generated by
the NAS. the NAS.
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
1 Code = Status-Server (12) 1 Code = Status-Server (12)
1 ID = 71 1 ID = 71
2 Length = 44 2 Length = 44
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
6 NAS-IP-Address (4) = 192.0.2.16 6 NAS-IP-Address (4) = 192.0.2.16
18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
The Response Authenticator is a 16-octet MD5 checksum of the code The Response Authenticator is a 16-octet MD5 checksum of the Code
(2), id (71), Length (52), the Request Authenticator from above, the (2), ID (71), Length (52), the Request Authenticator from above, the
attributes in this reply, and the shared secret. attributes in this reply, and the shared secret.
The Reply-Message is "RADIUS Server up 2 days, 18:40" The Reply-Message is "RADIUS Server up 2 days, 18:40"
02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd
6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72
76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31
38 3a 34 30 38 3a 34 30
1 Code = Access-Accept (2) 1 Code = Access-Accept (2)
1 ID = 71 1 ID = 71
2 Length = 52 2 Length = 52
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
32 Reply-Message (18) 32 Reply-Message (18)
7. IANA Considerations 7. Security Considerations
This specification does not create any new registries, nor does it
require assignment of any protocol parameters.
8. Security Considerations
This document defines the Status-Server packet as being similar in This document defines the Status-Server packet as being similar in
treatment to the Access-Request packet, and is therefore subject to treatment to the Access-Request packet, and is therefore subject to
the same security considerations as described in [RFC2865], Section the same security considerations as described in [RFC2865],
8. Status-Server packets also use the Message-Authenticator Section 8. Status-Server packets also use the Message-Authenticator
attribute, and are therefore subject to the same security attribute, and are therefore subject to the same security
considerations as [RFC3579], Section 4. considerations as [RFC3579], Section 4.
We reiterate that Status-Server packets MUST contain a Message- We reiterate that Status-Server packets MUST contain a Message-
Authenticator attribute. Early implementations supporting Status- Authenticator attribute. Early implementations supporting Status-
Server did not enforce this requirement, and were vulnerable to the Server did not enforce this requirement, and were vulnerable to the
following attacks: following attacks:
* Servers not checking Message-Authenticator could respond to * Servers not checking the Message-Authenticator attribute could
Status-Server packets from an attacker, potentially enabling respond to Status-Server packets from an attacker, potentially
a reflected DoS attack onto a real client. enabling a reflected DoS attack onto a real client.
* Servers not checking Message-Authenticator could be subject to a * Servers not checking the Message-Authenticator attribute could
race condition, where an attacker could see an Access-Request be subject to a race condition, where an attacker could see an
packet from a valid client, and synthesize a Status-Server packet Access-Request packet from a valid client and synthesize a
containing the same Request Authenticator. If the attacker won the Status-Server packet containing the same Request Authenticator.
race against the valid client, the server could respond with an If the attacker won the race against the valid client, the
Access-Accept, and potentially authorize unwanted service. server could respond with an Access-Accept and potentially
authorize unwanted service.
The last attack is similar to a related attack when Access-Request The last attack is similar to a related attack when Access-Request
packets contain a CHAP-Password but no Message-Authenticator. We re- packets contain a CHAP-Password but no Message-Authenticator. We
iterate the suggestion of [RFC5080] Section 2.2.2, which proposes re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes
that all clients send a Message-Authenticator in every Access-Request that all clients send a Message-Authenticator in every Access-Request
packet, and that all servers have a configuration setting to require packet, and that all servers have a configuration setting to require
(or not) that a Message-Authenticator attribute be used in every (or not) that a Message-Authenticator attribute be used in every
Access-Request packet. Access-Request packet.
Failure to include a Message-Authenticator attribute in a Status- Failure to include a Message-Authenticator attribute in a Status-
Server packet means that any RADIUS client or server may be Server packet means that any RADIUS client or server may be
vulnerable to the attacks outlined above. For this reason, vulnerable to the attacks outlined above. For this reason,
implementations of this specification which fail to require use of implementations of this specification that fail to require use of the
the Message-Authenticator attribute are NOT RECOMMENDED. Message-Authenticator attribute are NOT RECOMMENDED.
Where this document differs from [RFC2865] is that it defines a new Where this document differs from [RFC2865] is that it defines a new
request/response method in RADIUS; the Status-Server request. As request/response method in RADIUS: the Status-Server request. As
this use is based on previously described and implemented standards, this use is based on previously described and implemented standards,
we know of no additional security considerations that arise from the we know of no additional security considerations that arise from the
use of Status-Server as defined herein. use of Status-Server as defined herein.
Attacks on cryptographic hashes are well known [RFC4270], and getting Attacks on cryptographic hashes are well known [RFC4270] and getting
better with time. RADIUS uses the MD5 hash [RFC1321] for packet better with time. RADIUS uses the MD5 hash [RFC1321] for packet
authentication and attribute obfuscation. There are ongoing efforts authentication and attribute obfuscation. There are ongoing efforts
in the IETF to analyze and address these issues for the RADIUS in the IETF to analyze and address these issues for the RADIUS
protocol. protocol.
9. References 8. References
9.1. Normative references 8.1. Normative References
[RFC1321] [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, April 1992.
1992
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Authentication Dial In User Service (RADIUS)", RFC 2865, June "Remote Authentication Dial In User Service (RADIUS)",
2000. RFC 2865, June 2000.
[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC4086] Eastlake, D., et al, "Randomness Requirements for Security", [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
User Service (RADIUS) Implementation Issues and Suggested Dial In User Service (RADIUS) Implementation Issues and
Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
9.2. Informative references 8.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
User Service) Support For Extensible Authentication Protocol Dial In User Service) Support For Extensible
(EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
in Internet Protocols", RFC 4270, November 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6",
4668, August 2006. RFC 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
4669, August 2006. RFC 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6",
August 2006. RFC 4670, August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6",
August 2006. RFC 4671, August 2006.
Acknowledgments Acknowledgments
Parts of the text in Section 3 defining the Request and Response Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3. Authenticators were taken, with minor edits, from [RFC2865],
Section 3.
The author would like to thank Mike McCauley of Open Systems The author would like to thank Mike McCauley of Open Systems
Consultants for making a Radiator server available for Consultants for making a Radiator server available for
interoperability testing. interoperability testing.
Ignacio Goyret provided valuable feedback on the history and security Ignacio Goyret provided valuable feedback on the history and security
of the Status-Server packet. of the Status-Server packet.
Author's Address Author's Address
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org http://freeradius.org
Email: aland@freeradius.org
EMail: aland@freeradius.org
 End of changes. 149 change blocks. 
358 lines changed or deleted 356 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/