draft-ietf-radext-status-server-02.txt   draft-ietf-radext-status-server-03.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Informational Category: Proposed Standard
<draft-ietf-radext-status-server-02.txt> <draft-ietf-radext-status-server-03.txt>
Expires: May 2, 2009 Expires: June 16, 2009
2 November 2008 16 December 2008
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
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2009. This Internet-Draft will expire on June 16, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject to
BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info) in effect on the
date of publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
RFC 2865 defines a Status-Server code for use in RADIUS, but labels RFC 2865 defines a Status-Server code for use in RADIUS, but labels
it as "Experimental" without further discussion. This document it as "Experimental" without further discussion. This document
describes a practical use for the Status-Server packet code, which is describes a practical use for the Status-Server packet code, which is
to let clients query the status of a RADIUS server. These queries, to let clients query the status of a RADIUS server. These queries,
and responses (if any) enable the client to make more informed and responses (if any) enable the client to make more informed
decisions. The result is a more stable, and more robust RADIUS decisions. The result is a more stable, and more robust RADIUS
architecture. architecture.
Table of Contents Table of Contents
1. Introduction ............................................. 3 1. Introduction ............................................. 4
1.1. Terminology ......................................... 3 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 4 1.2. Requirements Language ............................... 5
2. Problem Statement ........................................ 5 2. Problem Statement ........................................ 6
2.1. Overloading Access-Request .......................... 5 2.1. Overloading Access-Request .......................... 6
2.1.1. Recommendation against Access-Request .......... 6 2.1.1. Recommendation against Access-Request .......... 7
2.2. Overloading Accounting-Request ...................... 6 2.2. Overloading Accounting-Request ...................... 7
2.2.1. Recommendation against Accounting-Request ...... 7 2.2.1. Recommendation against Accounting-Request ...... 8
2.3. Status-Server as a Solution ......................... 7 2.3. Status-Server as a Solution ......................... 8
2.3.1. Status-Server to the RADIUS Authentication port 7 2.3.1. Status-Server to the RADIUS Authentication port. 8
2.3.2. ....................................................... 8 2.3.2. Status-Server to the RADIUS Accounting port .... 9
2.3.3. Status-Server to the RADIUS Change-of-Authorizat 8 3. Packet Format ............................................ 9
3. Packet Format ............................................ 8 3.1. Single definition for Status-Server ................. 11
3.1. Consistent definition for Status-Server ............. 10
4. Implementation notes ..................................... 11 4. Implementation notes ..................................... 11
4.1. Client Requirements ................................. 12 4.1. Client Requirements ................................. 12
4.2. Server Requirements ................................. 13 4.2. Server Requirements ................................. 14
4.3. Change of Authorization and Status-Server ........... 15 4.3. More Robust Fail-over with Status-Server ............ 15
4.4. More Robust Fail-over with Status-Server ............ 16 4.4. Proxy Server handling of Status-Server .............. 16
4.5. Proxy Server handling of Status-Server .............. 16 4.5. Realm Routing ....................................... 16
4.6. Realm Routing ....................................... 17 4.6. Management Information Base (MIB) Considerations .... 18
4.7. Management Information Base (MIB) Considerations .... 19 4.6.1. Interaction with RADIUS Server MIB modules ..... 18
4.7.1. Interaction with RADIUS Server MIBs ............ 19 4.6.2. Interaction with RADIUS Client MIB modules ..... 19
4.7.2. Interaction with RADIUS Client MIBs ............ 19 5. Additional considerations ................................ 19
5. Additional considerations ................................ 20 5.1. Local site testing .................................. 19
5.1. Local site testing .................................. 20
5.2. RADIUS over reliable transports ..................... 21 5.2. RADIUS over reliable transports ..................... 21
5.3. Other uses for Status-Server ........................ 22 5.3. Other uses for Status-Server ........................ 21
6. Table of Attributes ...................................... 22 6. Table of Attributes ...................................... 21
7. Examples ................................................. 22 7. Examples ................................................. 22
7.1. Minimal Query to Authentication Port ................ 23 7.1. Minimal Query to Authentication Port ................ 22
7.2. Minimal Query to Accounting Port .................... 23 7.2. Minimal Query to Accounting Port .................... 23
7.3. Verbose Query and Response .......................... 24 7.3. Verbose Query and Response .......................... 24
8. IANA Considerations ...................................... 25 8. IANA Considerations ...................................... 25
9. Security Considerations .................................. 25 9. Security Considerations .................................. 25
10. References .............................................. 25 10. References .............................................. 25
10.1. Normative references ............................... 26 10.1. Normative references ............................... 25
10.2. Informative references ............................. 26 10.2. Informative references ............................. 25
Intellectual Property Statement .............................. 27
Disclaimer of Validity ....................................... 28
Full Copyright Statement ..................................... 28
1. Introduction 1. Introduction
The RADIUS Working Group was formed in 1995 to document the protocol The RADIUS Working Group was formed in 1995 to document the protocol
of the same name, and created a number of standards surrounding the of the same name, and created a number of standards surrounding the
protocol. It also defined experimental commands within the protocol, protocol. It also defined experimental commands within the protocol,
without elaborating further on the potential uses of those commands. without elaborating further on the potential uses of those commands.
One of the commands so defined was Status-Server ([RFC2865] Section One of the commands so defined was Status-Server ([RFC2865] Section
3.). 3.).
skipping to change at page 3, line 34 skipping to change at page 4, line 34
retransmissions internally. Since RADIUS runs over the User Datagram retransmissions internally. Since RADIUS runs over the User Datagram
Protocol (UDP) rather than Transport Control Protocol (TCP), the full Protocol (UDP) rather than Transport Control Protocol (TCP), the full
watchdog mechanism is not applicable here. watchdog mechanism is not applicable here.
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 lists
additional considerations not covered in the other sections. The additional considerations not covered in the other sections. The
remaining text contains a RADIUS table of attributes, and discussed 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. Terminology 1.1. 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 The device providing access to the network. Also known as the
Authenticator (in IEEE 802.1x terminology) or RADIUS client. Authenticator (in IEEE 802.1x terminology) or RADIUS client.
skipping to change at page 5, line 51 skipping to change at page 6, line 51
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, is slow to respond,
or is intentionally delaying it's response to the query. or is 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's policy is designed enable these query requests. Unless the server's 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 means
that if a RADIUS server does not respond to those qeuries, 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 servers purpose of performing end-to-end or in-depth testing of a servers
policy. While this practice is wide-spread, we caution policy. While this practice is widespread, we caution administrators
administrators to use it with care. to use it with care.
2.2. Overloading Accounting-Request 2.2. Overloading Accounting-Request
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 authentication port. The NAS can then look for a RADIUS servers 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
skipping to change at page 7, line 15 skipping to change at page 8, line 15
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 servers
policy. While this practice is wide-spread, we caution policy. While this practice is widespread, we caution administrators
administrators to use it with care. to use it with care.
2.3. Status-Server as a Solution 2.3. Status-Server as a Solution
A better solution to the above problems is to use the Status-Server A better solution to the above problems is to use the Status-Server
packet code. The name of the code leads us to conclude that it was packet code. The name of the code leads us to conclude that it was
intended for packets that query the status of a server. Since the intended for packets that query the status of a server. Since the
packet is otherwise undefined, it does not cause interoperability packet is otherwise undefined, it does not cause interoperability
issues to create implementation-specific definitions for it. The issues to create implementation-specific definitions for it. The
difficulty until now has been defining an inter-operable method of difficulty until now has been defining an interoperable method of
performing these queries. performing these queries.
This document addresses that need. This document addresses that need.
2.3.1. Status-Server to the RADIUS Authentication port 2.3.1. Status-Server to the RADIUS Authentication port
Status-Server SHOULD be used instead of Access-Request to query the Status-Server SHOULD be used instead of Access-Request to query the
responsiveness of a server. In this use-case, the protocol exchange responsiveness of a server. In this use case, the protocol exchange
between client and server is similar to the usual exchange of Access- between client and server is similar to the usual exchange of Access-
Request and Access-Accept, as shown below. Request and Access-Accept, as shown below.
NAS RADIUS server NAS RADIUS server
--- ------------- --- -------------
Status-Server/ Status-Server/
Message-Authenticator -> Message-Authenticator ->
<- Access-Accept/ <- Access-Accept/
Reply-Message Reply-Message
The Status-Server packet MUST contain a Message-Authenticator The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The response (if any) to a Status-Server attribute for security. The response (if any) to a Status-Server
packet sent to an authentication port MUST be an Access-Accept packet sent to an authentication port SHOULD be an Access-Accept
packet. The list of attributes that are permitted in the Access- packet. Other response packet codes are NOT RECOMMENDED. The list
Accept packet is given in the Table of Attributes in Section 6, of attributes that are permitted in the Access-Accept packet is given
below. in the Table of Attributes in Section 6, below.
2.3.2. 2.3.2. Status-Server to the RADIUS Accounting port
Status-Server may be used instead of Accounting-Request to query the Status-Server MAY be used instead of Accounting-Request to query the
responsiveness of a server. In this use-case, the protocol exchange responsiveness of a server. In this use case, the protocol exchange
between client and server is similar to the usual exchange of between client and server is similar to the usual exchange of
Accounting-Request and Accounting-Response, as shown below. Accounting-Request and Accounting-Response, as shown below.
NAS RADIUS server NAS RADIUS server
--- ------------- --- -------------
Status-Server/ Status-Server/
Message-Authenticator -> Message-Authenticator ->
<- Accounting-Response <- Accounting-Response
The Status-Server packet MUST contain a Message-Authenticator The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The response (if any) to a Status-Server attribute for security. The response (if any) to a Status-Server
packet sent to an accounting port MUST be an Accounting-Response packet sent to an accounting port SHOULD be an Accounting-Response
packet. The list of attributes that are permitted in the Accounting- packet. Other response packet codes are NOT RECOMMENDED. The list
Response packet is given in the Table of Attributes in Section 6, of attributes that are permitted in the Accounting-Response packet is
below. given in the Table of Attributes in Section 6, below.
2.3.3. Status-Server to the RADIUS Change-of-Authorization port
Status-Server may be pro-actively sent by a server to a NAS when the
server first boots. This use mirrors the Accounting-Request use of
the Acct-Status-Type attribute with value "Accounting On". This
packet can serve as an indication to the NAS that the server is
available for authentication and accounting requests.
In this use-case, the protocol exchange between client and server is
similar to the usual exchange of CoA-Request and CoA-ACK, as shown
below.
RADIUS Server NAS
------------- ---
Status-Server/
Message-Authenticator ->
<- CoA-ACK
The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The response (if any) to a Status-Server
packet sent to a Change-of-Authorization port MUST be a CoA-ACK
packet. The list of attributes that are permitted in the CoA-ACK
packet is given in the Table of Attributes in Section 6, below.
3. Packet Format 3. Packet Format
Status-Server packets re-use the RADIUS packet format, with the Status-Server packets reuse the RADIUS packet format, with the fields
fields and values for those fields as defined [RFC2865] Section 3. and values for those fields as defined [RFC2865] Section 3. We do
not include all of the text or diagrams of that section here, but
We do not include all of the text or diagrams of that section here, instead explain the differences required to implement Status-Server.
but 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,
skipping to change at page 9, line 44 skipping to change at page 10, line 18
The Request Authenticator value in a Status-Server packet The Request Authenticator value in a Status-Server packet
SHOULD also be unpredictable, lest an attacker trick a server SHOULD also be unpredictable, lest an attacker trick a server
into responding to a predicted future request, and then use the into responding to a predicted future request, and then use the
response to masquerade as that server to a future Status-Server response to masquerade as that server to a future Status-Server
request from a client. request from a client.
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 for calculating the Response using the same method as used for for calculating the Response
Authenticator of the Access-Accept, with the Status-Server Request Authenticator of the Access-Accept sent in response to an Access-
Authenticator taking the place of the Access-Request Request Request, with the Status-Server Request Authenticator taking the
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 for calculating the Response Authenticator of
the Accounting-Response, with the Status-Server Request Authenticator the Accounting-Response sent in response to an Accounting-Request,
taking the place of the Accounting-Request Request Authenticator. with the Status-Server Request Authenticator taking the place of the
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
NOTE 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, ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
denotes concatenation. 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, one of NAS-IP- Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-
Address or NAS-IPv6-Address, and Reply-Message. These attributes are Address or NAS-IPv6-Address. These attributes are not necessary for
not necessary for the operation of Status-Server, but may be useful the operation of Status-Server, but may be useful information to a
information to a server that receives those packets. 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.
User authentication credentials such as User-Password, CHAP-Password, User authentication credentials such as User-Password, CHAP-Password,
EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a EAP-Message, etc. 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, etc. MUST
NOT appear in a Status-Server packet sent to a RADIUS accounting NOT 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 7.
3.1. Consistent 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, contents of the Status-Server
packets are calculated as described above. That is, even though the packets are calculated as described above. That is, even though the
packets are being sent to an accounting port, they are not created packets are being sent to an accounting port, they are not created
using the same method as for Accounting-Requests. This difference using the same method as for Accounting-Requests. This difference
has a number of benefits. has a number of benefits.
Having one 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 or CoA-Request, but containing no attributes, then Accounting-Request but containing no attributes, then those packets
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.
When sent to a change of authorization (CoA) port, the response to a
Status-Server query is an CoA-ACK 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, accounting, and coa 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 Accounting-Request packet sent to an accounting port, or an Accounting-Request packet sent to an accounting port
a Change-Of-Authorization packet sent to a CoA port.
* Response packet * Response packet
An Access-Accept, Access-Challenge, or Access-Reject packet sent An Access-Accept, Access-Challenge, or Access-Reject packet sent
from an authentication port, or an Accounting-Response packet from an authentication port, or an Accounting-Response packet
sent from an accounting port, or a CoA-ACK packet sent from a sent from an accounting port.
CoA 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, accounting, and simpler than duplicating the text for authentication, and accounting
coa 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.
skipping to change at page 12, line 52 skipping to change at page 13, line 24
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, Accounting-Response, to a Status-Server packet is an Access-Accept or Accounting-Response
or CoA-ACK packet, those responses are indistinguishable from other packet, those responses are indistinguishable from other packets sent
packets sent in response to a Request packet. Therefore, the best in response to a Request packet. Therefore, the best way to
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 Identifer field MUST be to send Request packets. In that case, the Identifer 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 has determined that the Status-Server
packet has timed out, it may re-use that Identifier in another packet has timed out, it may reuse that Identifier in another packet.
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 check that the Response packet Code field is either Access-Accept (2)
(2), Accounting-Response (5), or CoA-ACK (44). If the code does not or Accounting-Response (5). If the code does not match any of these
match any of these values, the packet MUST be silently discarded. values, the packet MUST be silently discarded. The client MUST then
The client MUST then validate the Response Authenticator via the validate the Response Authenticator via the algorithm given above in
algorithm given above in Section 3. If the Response Authenticator is Section 3. If the Response Authenticator is not valid, the packet
not valid, the packet MUST be silently discarded. If the Response MUST be silently discarded. If the Response Authenticator is valid,
Authenticator is valid, then the packet MUST be deemed to be a valid then the packet MUST be deemed to be a valid response from the
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
skipping to change at page 14, line 34 skipping to change at page 15, line 5
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 who is interested in obtaining additional
information about the server. information about the server.
The server MAY prioritize the handling Status-Server queries over the The server MAY prioritize the handling of Status-Server packets over
handling of other requests, subject to the rate limiting described the handling of other requests, subject to the rate limiting
above. described above.
The server MAY decide to not respond to a Status-Server, depending on The server MAY decide to not 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 it's 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 are
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 are accepted only on "accounting" ports
(e.g. 1813/udp). Those implementations SHOULD reply to Status-Server (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server
packets sent to an "authentication" port with an Access-Accept packets sent to an "authentication" port with an Access-Accept
skipping to change at page 15, line 17 skipping to change at page 15, line 36
Accounting-Request packets on the same port, and do not distinguish Accounting-Request packets on the same port, and do not distinguish
between "authentication only" ports, and "accounting only" ports. between "authentication only" ports, and "accounting only" ports.
Those implementations SHOULD reply to Status-Server packets with an Those implementations SHOULD reply to Status-Server packets with an
Access-Accept packet. 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, or sending a Response packet. The server SHOULD NOT
perform any other action that is normally performed when it receives perform any other action that is normally performed when it receives
a Request packet, other than sending a Response packet. a Request packet, other than sending a Response packet.
4.3. Change of Authorization and Status-Server 4.3. More Robust Fail-over with Status-Server
The use of Status-Server with respect to Change of Authorization
requires some additional discussion.
When a Dynamic Authorization Client ([RFC5176] Section 1.3) reboots,
it SHOULD send a Status-Server packet to a CoA port to IP addresses
that are configured as both Dynamic Authorization Servers and RADIUS
clients. Jitter SHOULD be used to avoid synchronization issues. If
there is no response to a packet, the periodic timer above SHOULD be
used to continue sending packets to that destination until a response
has been received. When a response is received, the Dynamic
Authorization Client MUST NOT send further Status-Server packets to
the CoA port of any Dynamic Authorization until it next reboots.
When a Dynamic Authorization Server receives a Status-Server packet
to it's CoA port, it SHOULD respond with a CoA-ACK packet, as
described above. It MAY use this information to modify it's
authentication and/or accounting behavior, as described below.
If the Status-Server packet came to a NAS CoA port from an IP address
which is also configured as an authentication and/or accounting
server. the NAS MAY decide to mark the RADIUS server as being
responsive. If the RADIUS server had previously been marked as
unresponsive, this change would enable the NAS to start packets to
start sending packets to that RADIUS server again. The NAS MAY
otherwise decide to receive multiple packets to it's CoA port before
marking the RADIUS server as responsive. This behavior is
implementation-defined, and SHOULD be configurable.
Where possible, the Dynamic Authorization Client (usually a RADIUS
server) SHOULD originate the Status-Server packet from the port to
which the NAS would normally send Request packets. For example, a
packet sent from from a RADIUS server with source port 1812 to a NAS
with destination port 3799, would indicate to the NAS that the RADIUS
authentication server at that address is alive.
4.4. More Robust Fail-over with Status-Server
A common problem in RADIUS client implementations is the A common problem in RADIUS client implementations is the
implementation of a robust fail-over mechanism between servers. A implementation of a robust fail-over mechanism between servers. A
client may have multiple servers configured, with one server marked client may have multiple servers configured, with one server marked
as primary and another marked as secondary. If the client determines as primary and another marked as secondary. If the client determines
that the primary is unresponsive, it can "fail over" to the that the primary is unresponsive, it can "fail over" to the
secondary, and send requests to the secondary instead of to the secondary, and send requests to the secondary instead of to the
primary. primary.
However, it is difficult in standard RADIUS for a client to know when However, it is difficult in standard RADIUS for a client to know when
it should start sending requests to the primary again. Sending test it should start sending requests to the primary again. Sending test
Access-Requests or Accounting-Requests to see if the server is alive Access-Requests or Accounting-Requests to see if the server is alive
has the issues outlined above in Section 2. Clients could has the issues outlined above in Section 2. Clients could
alternately send real traffic to the primary, on the hope that it is alternately send real traffic to the primary, on the hope that it is
responsive. If the server is still unresponsive, however, the result responsive. If the server is still unresponsive, however, the result
may be user login failures. The Status-Server solution is an ideal may be user login failures. The Status-Server solution is an ideal
one to solve this problem. way to solve this problem.
When a client fails over from one server to another because of a lack When a client fails over from one server to another because of a lack
of responsiveness, it SHOULD send periodic Status-Server packets to of responsiveness, it SHOULD send periodic Status-Server packets to
the unresponsive server, using the timer (Tw) defined above. the unresponsive server, using the timer (Tw) defined above.
Once three time periods have passed where Status-Server messages have Once three time periods have passed where Status-Server packets have
been sent and responded to, the server should be deemed responsive been sent and responded to, the server should be deemed responsive
and RADIUS requests may sent to it again. This determination should and RADIUS requests may sent to it again. This determination should
be made separately for each server that the client has a relationship be made separately for each server that the client has a relationship
with. The same algorithm should be used for both authentication and with. The same algorithm should be used for both authentication and
accounting ports. The client MUST treat each destination (ip, port) accounting ports. The client MUST treat each destination (ip, port)
combination as a unique server for the purposes of this combination as a unique server for the purposes of this
determination. determination.
The practice of sending Status-Server packets to CoA ports (where
applicable) can increase the information available in the network,
and further help to stabilize the network, and to lower response
times in the event of network changes.
The above behavior is modelled after [RFC3539] Section 3.4.1. We The above behavior is modelled after [RFC3539] Section 3.4.1. We
note that if a reliable transport is used for RADIUS, then the note that if a reliable transport is used for RADIUS, then the
algorithms specified in [RFC3539] MUST be used in preference to the algorithms specified in [RFC3539] MUST be used in preference to the
ones given here. ones given here.
4.5. 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 home servers. Such servers MUST NOT proxy Status-Server requests to home servers. Such servers MUST NOT proxy Status-Server
packets. The purpose of Status-Server as specified here is to permit packets. The purpose of Status-Server as specified here is to permit
the client to query the responsiveness of a server that it has a the client to query the responsiveness of a server that it has a
direct relationship with. Proxying Status-Server queries would direct relationship with. Proxying Status-Server queries would
negate any usefulness that may be gained by implementing support for negate any usefulness that may be gained by implementing support for
them. 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 MAY act as clients sending Status-Server queries to
other servers. However, those activities MUST be independent of one other servers. However, those activities MUST be independent of one
another. another.
4.6. Realm Routing 4.5. Realm Routing
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,
the mechanism outlined above may be inadequate. the mechanism outlined above may be inadequate.
The schematic below demonstrates this scenario. The schematic below demonstrates this scenario.
skipping to change at page 18, line 7 skipping to change at page 17, line 31
is reachable from Proxy Server S, as it can then route all requests is reachable from Proxy Server S, as it can then route all requests
for Realm A to that Proxy Server. Without this knowledge, the client for Realm A to that Proxy Server. Without this knowledge, the client
may route requests to Proxy Server P, where they may be discarded or may route requests to Proxy Server P, where they may be discarded or
rejected. rejected.
To complicate matters, the behavior of Proxy Servers P and S in this To complicate matters, the behavior of Proxy Servers 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 Proxy Server being down, or the next cannot distinguish between the Proxy Server being down, or the next
server along along the proxy chain is 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
Realm B. For example, if Proxy Server P can reach Realm B but not of Realm B. For example, if Proxy Server P can reach Realm B but not
Realm A, and Proxy Server S can reach Realm A but not Realm B, then Realm A, and Proxy Server 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 Proxy Server implementation choices, the NAS may not on the NAS and Proxy Server implementation choices, the NAS may not
be able to determine which server requests may be sent to in order to be able to determine which server requests may be sent to in order to
maintain network stability. maintain network stability.
This problem cannot, unfortunately be solved by using Status-Server This problem cannot, unfortunately 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
skipping to change at page 18, line 51 skipping to change at page 18, line 28
A more realistic situation than the one outlined above is where each A more realistic situation than the one outlined above is where each
Proxy Server also has multiple choices of Home Servers for a realm, Proxy Server also has multiple choices of Home Servers for a realm,
as outlined below. as outlined below.
/-> Proxy Server P -----> Home Server P /-> Proxy Server P -----> Home Server P
/ \ / / \ /
NAS X NAS X
\ / \ \ / \
\-> Proxy Server S -----> Home Server S \-> Proxy Server S -----> Home Server S
In this situation, if all participants impement 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 home server. If two links are broken at NAS will still reach a home 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 home server. In many requests from the NAS will still reach a home server. In many
situations where three or more links are broken, then requests from situations where three or more links are broken, then requests from
the NAS may still reach a home server. the NAS may still reach a home 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.7. Management Information Base (MIB) Considerations 4.6. Management Information Base (MIB) Considerations
4.7.1. Interaction with RADIUS Server MIBs 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 MIBs. they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
[RFC4669] defines a counter named radiusAuthServTotalUnknownTypes, modules. [RFC4669] defines a counter named
that counts "The number of RADIUS packets of unknown type that were radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS
received". [RFC4671] defines a similar counter named packets of unknown type that were received". [RFC4671] defines a
radiusAcctServTotalUnknownTypes. Implementations not supporting similar counter named radiusAcctServTotalUnknownTypes.
Status-Server, or implementations that are configured to not respond Implementations not supporting Status-Server, or implementations that
to Status-Server packets MUST use these counters to track received are configured to not respond to Status-Server packets MUST use these
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] If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
MIBs, then it SHOULD also support vendor-specific MIBs containing Modules, then it SHOULD also support vendor-specific MIB extensions
similar information as the standard MIBs, but which are instead
dedicated solely to tracking Status-Server requests and responses. dedicated solely to tracking Status-Server requests and responses.
Any definition of the server MIBs for Status-Server is outside of the Any definition of the server MIB modules for Status-Server is outside
scope of this document. of the scope of this document.
4.7.2. Interaction with RADIUS Client MIBs 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] MIBs, then it SHOULD also support vendor-specific MIBs [RFC4670] MIB modules, then it SHOULD also support vendor-specific
containing similar information as those MIBs, but which are instead MIB extensions containing similar information as those MIB modules,
dedicated solely to tracking Status-Server requests and responses. but which are instead dedicated solely to tracking Status-Server
Any definition of the client MIBs for Status-Server is outside of the requests and responses. Any definition of the client MIB module
scope of this document. extensions for Status-Server is outside of the scope of this
document.
5. Additional considerations 5. Additional considerations
There are additional topics related to the use of Status-Server that There are additional topics related to the use of Status-Server that
may be covered. As those topics do not fit well into the preceding may be covered. As those topics do not fit well into the preceding
sections, they are covered herein. sections, they are covered herein.
5.1. Local site testing 5.1. Local site testing
There is at least one situation where using Access-Request or There is at least one situation where using Access-Request or
skipping to change at page 20, line 37 skipping to change at page 20, line 13
In that situation, administrators MAY configure a well-known "test" In that situation, administrators MAY configure a well-known "test"
user to enable local site testing. user to enable local site testing.
The advantage to creating such a local user is that it is now The advantage to creating such a local user is that it is now
possible for the administrator to send a RADIUS request that performs possible for the administrator to send a RADIUS request that performs
end-to-end testing of the RADIUS server. As above with Status- end-to-end testing of the RADIUS server. As above with Status-
Server, this testing includes RADIUS server responsiveness. It may Server, this testing includes RADIUS server responsiveness. It may
also include querying databases of user authentication credentials, also include querying databases of user authentication credentials,
or storing accounting data to a billing database. The information or storing accounting data to a billing database. The information
obtained from performing those queries is that the entire RADIUS obtained from performing those queries is that the entire RADIUS
server infrastructure, including all of it's dependencies, is server infrastructure, including all of its dependencies, is
functioning as expected. These queries are most useful in functioning as expected. These queries are most useful in
deployments where an administrator has internal RADIUS server that deployments where an administrator has internal RADIUS servers that
proxy to other internal RADIUS servers, such as for load balancing or proxy to other internal RADIUS servers, such as for load balancing or
fail over. fail over.
If used, the names used for these test users SHOULD be difficult to If used, the names utilized for these test users SHOULD be difficult
guess by an attacker. An Access-Request packet for a test user to guess by an attacker. An Access-Request packet for a test user
otherwise should be treated as follows, depending on its origin: otherwise should be treated as follows, depending on its origin:
o Packets from localhost (127.0.0.1 or ::1): RADIUS servers o Packets from localhost (127.0.0.1 or ::1): RADIUS servers
SHOULD treat the request according to local site policy. SHOULD treat the request according to local site policy.
o Packets from NASes that normally originate Access-Request o Packets from NASes that normally originate Access-Request
packets (i.e. not proxy servers): RADIUS servers SHOULD respond packets (i.e. not proxy servers): RADIUS servers SHOULD respond
with an Access-Reject packet, as the use of Status-Server is with an Access-Reject packet, as the use of Status-Server is
preferred. preferred.
skipping to change at page 21, line 49 skipping to change at page 21, line 28
packets. packets.
Clients sending Status-Server over reliable transport MUST ensure Clients sending Status-Server over reliable transport MUST ensure
that the Identifier field is unique for all requests on a particular that the Identifier field is unique for all requests on a particular
connection, independent of the packet code. That is, if a Status- connection, independent of the packet code. That is, if a Status-
Server with a particular value in the Identifier field is sent to a Server with a particular value in the Identifier field is sent to a
server, the client MUST NOT simultaneously send an Access-Request or server, the client MUST NOT simultaneously send an Access-Request or
Accounting-Request packet with that same Identifier value, on that Accounting-Request packet with that same Identifier value, on that
connection. Once the client has either received a response to the connection. Once the client has either received a response to the
Status-Server packet, or has determined that the Status-Server packet Status-Server packet, or has determined that the Status-Server packet
has timed out, it may re-use that Identifier in another packet. has timed out, it may reuse that Identifier in another packet.
5.3. Other uses for Status-Server 5.3. Other uses for Status-Server
While other uses of Status-Server are possible, uses beyond those While other uses of Status-Server are possible, uses beyond those
specified here are beyond the scope of this document. It may be specified here are beyond the scope of this document. It may be
tempting to increase the utility of Status-Server by having the tempting to increase the utility of Status-Server by having the
responses carry additional information, implementors are warned that responses carry additional information, but implementors are warned
such uses have not been analyzed for potential security issues or that such uses have not been analyzed for potential security issues
network problems. or network problems.
Specifically, it may seem useful to leverage a combination of Status- Specifically, it may seem useful to leverage a combination of Status-
Server and CoA ports in order to send realm routing information Server and CoA ports in order to send realm routing information
"upstream" from the home servers to the proxy servers, and finally to "upstream" from the home servers to the proxy servers, and finally to
the NAS. This use of Status-Server is NOT RECOMMENDED, as there has the NAS. This use of Status-Server is NOT RECOMMENDED, as there has
been insufficient analysis and deployment experience to know if it is been insufficient analysis and deployment experience to know if it is
useful, or even if it makes the network less reliable. useful, or even if it makes the network less reliable.
6. Table of Attributes 6. Table of Attributes
The following table provide 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. No attributes other in Status-Server packets, and in what quantity. Attributes other
than the ones listed below should be found in a Status-Server packet. than the ones listed below SHOULD NOT be found in a Status-Server
packet.
Status- Access- Accounting- CoA- Status- Access- Accounting-
Server Accept Response ACK # Attribute Server Accept Response # Attribute
0-1 0 0 0 4 NAS-IP-Address 0-1 0 0 4 NAS-IP-Address [Note 1]
0 0+ 0 0 18 Reply-Message 0 0+ 0 18 Reply-Message
0+ 0+ 0+ 0 26 Vendor-Specific 0+ 0+ 0+ 26 Vendor-Specific
0+ 0+ 0 0 31 Calling-Station-Id 0-1 0 0 32 NAS-Identifier [Note 1]
0-1 0 0 0 32 NAS-Identifier 1 0-1 0-1 80 Message-Authenticator
1 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 0 95 NAS-IPv6-Address
[Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or
NAS-IPv6-Address), or NAS-Identifier, or both 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 packet.
0-1 Zero or one instance of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet.
1 Exactly one instance of this attribute MUST be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
7. Examples 7. Examples
skipping to change at page 23, line 22 skipping to change at page 23, line 4
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
skipping to change at page 24, line 14 skipping to change at page 23, line 43
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 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 02 b3 00 1a 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 16 Request Authenticator 2 Length = 20 16 Request Authenticator
skipping to change at page 26, line 11 skipping to change at page 25, line 38
use of Status-Server as defined herein. use of Status-Server as defined herein.
10. References 10. References
10.1. Normative references 10.1. Normative references
[RFC2865] [RFC2865]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579]
Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In User
Service) Support For Extensible Authentication Protocol (EAP)", RFC
3579, September 2003.
[RFC4282] [RFC4282]
Aboba, B., and Beadles, M. at al, "The Network Access Identifier", Aboba, B., and Beadles, M. at al, "The Network Access Identifier",
RFC 4282, December 2005. RFC 4282, December 2005.
10.2. Informative references 10.2. Informative references
[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", RFC 2119, March, 1997.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006. 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006. 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670,
August 2006. August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671,
August 2006. August 2006.
[RFC5176] Chiba, M., Eklund, M., et al, "Dynamic Authorization
Extensions to Remote Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008.
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 inter- Consultants for making a Radiator server available for
operability testing. interoperability testing.
Authors' Addresses Authors' Addresses
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 72 change blocks. 
243 lines changed or deleted 167 lines changed or added

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