draft-ietf-radext-status-server-05.txt   draft-ietf-radext-status-server-06.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Informational Category: Informational
<draft-ietf-radext-status-server-05.txt> <draft-ietf-radext-status-server-06.txt>
Expires: April 12, 2009 Expires: August 16, 2010
12 October 2009 16 February 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-05 draft-ietf-radext-status-server-06
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 April 12, 2009. This Internet-Draft will expire on August 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info/) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document describes a deployed extension to the Remote This document describes 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. This extension clients to query the status of a RADIUS server. This extension
utilizes the Status-Server (12) Code, which was reserved for utilizes the Status-Server (12) Code, which was reserved for
experimental use in RFC 2865. experimental use in RFC 2865.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Applicability ....................................... 4 1.1. Applicability ....................................... 4
1.2. Terminology ......................................... 5 1.2. Terminology ......................................... 5
1.3. Requirements Language ............................... 5 1.3. Requirements Language ............................... 5
2. Problem Statement ........................................ 6 2. Overview ................................................. 6
2.1. Why Access-Request cannot be used ................... 6 2.1. Why Access-Request is inappropriate ................. 7
2.1.1. Recommendation against Access-Request .......... 7 2.1.1. Recommendation against Access-Request .......... 8
2.2. Why Accounting-Request cannot be used ............... 7 2.2. Why Accounting-Request is inappropriate ............. 8
2.2.1. Recommendation against Accounting-Request ...... 8 2.2.1. Recommendation against Accounting-Request ...... 8
2.3. Why Status-Server is appropriate .................... 8
2.3.1. Status-Server Exchange ......................... 8
3. Packet Format ............................................ 9 3. Packet Format ............................................ 9
3.1. Single definition for Status-Server ................. 11 3.1. Single definition for Status-Server ................. 11
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 ................................. 13
4.3. More Robust Fail-over with Status-Server ............ 15 4.3. Fail-over with Status-Server ........................ 15
4.4. Proxy Server handling of Status-Server .............. 15 4.4. Proxy Server handling of Status-Server .............. 16
4.5. Limitations of Status-Server ........................ 16 4.5. Limitations of Status-Server ........................ 16
4.6. Management Information Base (MIB) Considerations .... 18 4.6. Management Information Base (MIB) Considerations .... 18
4.6.1. Interaction with RADIUS Server MIB modules ..... 18 4.6.1. Interaction with RADIUS Server MIB modules ..... 18
4.6.2. Interaction with RADIUS Client MIB modules ..... 18 4.6.2. Interaction with RADIUS Client MIB modules ..... 19
5. Table of Attributes ...................................... 19 5. Table of Attributes ...................................... 19
6. Examples ................................................. 19 6. Examples ................................................. 20
6.1. Minimal Query to Authentication Port ................ 19 6.1. Minimal Query to Authentication Port ................ 20
6.2. Minimal Query to Accounting Port .................... 20 6.2. Minimal Query to Accounting Port .................... 21
6.3. Verbose Query and Response .......................... 21 6.3. Verbose Query and Response .......................... 21
7. IANA Considerations ...................................... 22 7. IANA Considerations ...................................... 22
8. Security Considerations .................................. 22 8. Security Considerations .................................. 22
9. References ............................................... 22 9. References ............................................... 23
9.1. Normative references ................................ 22 9.1. Normative references ................................ 23
9.2. Informative references .............................. 23 9.2. Informative references .............................. 23
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 Code (12) 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.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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 spoofing of Status- Message-Authenticator attribute. This enables an unauthorized client
Server packets. In order to remedy this problem, this specification to spoofing Status-Server packets, potentially leading to incorrect
recommends the use of the Message-Authenticator attribute to provide Access-Accepts. In order to remedy this problem, this specification
requires the use of the Message-Authenticator attribute to provide
per-packet authentication and integrity protection. 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-Requests packets using the same Identifier. This
specification recommends techniques to avoid this problem. specification recommends techniques to avoid this problem.
This specification is also limited to being a "hop by hop" query.
When RADIUS packets transition one or more RADIUS Proxies, any
information about the status of downstreamservers is unavailable to
the client. In addition, it queries only the status of a RADIUS
server, cannot carry information about specific realms.
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 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 6, line 5 skipping to change at page 6, line 5
packet, and SHOULD record the event in a statistics counter. 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. Problem Statement 2. Overview
A common problem in RADIUS client implementations is the Status-Server packets are sent by a RADIUS client to a RADIUS server
implementation of a robust fail-over mechanism between servers. A in order to test the status of that server. A Message-Authenticator
client may have multiple servers configured, with one server marked attribute MUST be included so as to provide per-packet authentication
as primary and another marked as secondary. If the client does not and integrity protection. A single Status-Server packet MUST be
receive a response to a request sent to the primary server, it can included within a UDP datagram. RADIUS proxies MUST NOT forward
"fail over" to the secondary, and send requests to the secondary Status-Server packets.
instead of to the primary server.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
or server, the destination of a Status-Server packet is set to the IP
address of the server which is being tested. As a result, the client
is provided with an indication of the status of that server only,
since no RADIUS proxies are on the path between the RADIUS client and
server. Since servers respond to a Status-Server packet without
examining the User-Name attribute, the response to a Status-Server
packet cannot be used to infer any information about the reachability
of specific realms.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Message (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
The "hop by hop" functionality of Status-Server packets is useful to
RADIUS clients attempting to determine the status of elements on the
path between the client and a server. Since the Status-Server packet
is non-forwardable, lack of a response may only be due to packet loss
or the failure of the server in the destination IP address, not due
to faults in downstream links, proxies or servers. It therefore
provides an unambiguous indication of the status of a server.
This information may be useful in situations where the RADIUS client
does not receive a response to an Access-Request. A client may have
multiple proxies configured, with one proxy marked as primary and
another marked as secondary. If the client does not receive a
response to a request sent to the primary proxy, it can "fail over"
to the secondary, and send requests to the secondary instead of to
the primary proxy.
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 server was due not to a failure within the the to the primary proxy was due not to a failure within the the primary,
primary, but to alternative causes such as a failed link along the but to alternative causes such as a failed link along the path to the
path to the destination server, or the failure of a downstream proxy destination server, or the failure of the destination server.
or server. In such a situation, it may be useful for the client to
be able to distinguish between failure causes. For example, if the
primary server is down, then quick failover to the secondary server
would be prudent, whereas if a downstream failure is the cause, then
the value of failing over to a secondary server will depend on
whether packets forwarded by the secondary will utilize independent
links, intermediaries or destination servers.
Since the Status-Server packet is non-forwardable, lack of a response In such a situation, it may be useful for the client to be able to
may only be due to packet loss or the failure of the server in the distinguish between failure causes so that it does not trigger
destination IP address, not due to faults in downstream links, failover inappropriately. For example, if the primary proxy is down,
proxies or servers. It therefore provides an unambiguous indication then a quick failover to the secondary proxy would be prudent.
of the status of a server. Whereas if a downstream failure is the cause, then the value of
failover to a secondary proxy will depend on whether packets
forwarded by the secondary will utilize independent links,
intermediaries or destination servers.
We note that this 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 sent when an downstream [RFC2865] Section 2.6. "Keep-Alives" are Access-Request packets sent
server is known to be responsive. These packets are sent only when a to determine whether a downstream server is responsive. These
server is suspected to be down, and stop being sent as soon as the packets are typically sent only when a server is suspected to be
server returns to availability. down, and are no longer sent as soon as the server is available
again.
2.1. Why Access-Request cannot be used 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
skipping to change at page 7, line 43 skipping to change at page 8, line 25
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 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 cannot be used 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 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.
skipping to change at page 8, line 26 skipping to change at page 9, line 10
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 widespread, we caution administrators policy. While this practice is widespread, we caution administrators
to use it with care. to use it with care.
2.3. Why Status-Server is appropriate
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
intended for packets that query the status of a server. Since the
packet is officially undefined, but widely used as specified here,
this document does not create inter-operability issues.
2.3.1. Status-Server Exchange
Status-Server packets are typically sent to the destination address
and port of a RADIUS server or proxy. A Message-Authenticator
attribute MUST be included so as to provide per-packet authentication
and integrity protection. A single Status-Server packet MUST be
included within a UDP datagram. RADIUS proxies MUST NOT forward
Status-Server packets.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Message (accounting port). Other
response packet codes (such as Access-Challenge or Access-Reject) are
NOT RECOMMENDED. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
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 [RFC2865] Section 3. We do
not include all of the text or diagrams of that section here, but 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.
skipping to change at page 9, line 46 skipping to change at page 9, line 51
SHOULD exhibit global and temporal uniqueness. SHOULD exhibit global and temporal uniqueness.
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 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 for calculating the Response Authenticator of
the Accounting-Response sent in response to an Accounting-Request, the Accounting-Response sent in response to an Accounting-Request,
with the Status-Server Request Authenticator taking the place of the with the Status-Server Request Authenticator taking the place of the
Accounting-Request Request Authenticator. Accounting-Request Request Authenticator.
skipping to change at page 10, line 34 skipping to change at page 10, line 39
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 NAS-IP-
Address or NAS-IPv6-Address. These attributes are not necessary for Address or NAS-IPv6-Address. These attributes are not necessary for
the operation of Status-Server, but may be useful information to a the operation of Status-Server, but may be useful 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, and MUST be ignored if they are included. User authentication
EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a credentials such as User-Name, User-Password, CHAP-Password, 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.
skipping to change at page 15, line 16 skipping to change at page 15, line 24
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. More Robust Fail-over with Status-Server 4.3. Fail-over with Status-Server
A client will typically fail over from one server to another because A client may wish to failover from one proxy to another in the event
of a lack of responsiveness to normal RADIUS traffic. However, the that it does not receive a response to an Access-Request or
client has few reasons to mark the server as responsive, as it is not Accounting-Request. In order to determine whether the lack of
being sent any packets. 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
lack of a response. The inter-packet period is Tw, as described in
Section 4.1.
The solution is that the client SHOULD begin to send periodic Status-
Server packets as soon as a server is determined to be unresponsive.
The inter-packet period is Tw, as defined above in Section 4.1.
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 the server being unresponsive, or if the problem is due to an to an issue on the path between the client and proxy or the proxy
downstream server being unresponsive. itself, or whether the issue is occurring downstream.
If no response is received to Status-Server packets, the RADIUS
client can initiate failover to another proxy. By continuing to send
Status-Server packets to the original proxy at an interval of Tw, the
RADIUS client can determine when the original proxy becomes
responsive again.
Once three time periods have passed where Status-Server packets 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.
skipping to change at page 19, line 17 skipping to change at page 19, line 33
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-1 0 0 4 NAS-IP-Address [Note 1] 0 0 0 1 User-Name,
0 0 0 2 User-Password
0 0 0 3 CHAP-Password
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
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-*
[Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or Note 1: A Status-Server SHOULD contain one of (NAS-IP-Address or NAS-
NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of
of (NAS-IP-Address or NAS-IPv6-Address). (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.
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".
skipping to change at page 20, line 42 skipping to change at page 21, line 15
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 80 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 1a 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 16 Request Authenticator 2 Length = 20
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
skipping to change at page 22, line 27 skipping to change at page 22, line 48
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], Section
8. Status-Server packets also use the Message-Authenticator 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 may have been vulnerable Server did not enforce this requirement, and were vulnerable to the
to DoS attacks as a result. following attacks:
* Servers not checking Message-Authenticator could respond to
Status-Server packets from an attacker, potentially enabling
a reflected DoS attack onto a real client.
* Servers not checking Message-Authenticator could be subject to a
race condition, where an attacker could see an Access-Request
packet from a valid client, and synthesise a Status-Server packet
containing the same Request Authenticator. If the attacker won the
race against the valid client, the server could respond with an
Access-Accept, and potentially authorize unwanted service.
The last attack is similar to a related attack when Access-Request
packets contain a CHAP-Password but no Message-Authenticator. We re-
iterate the suggestion of [RFC5080] Section 2.2.2, which suggests
that all clients send a Message-Authenticator in every Access-Request
packet, and that all servers configurably require that a Message-
Authenticator attribute be used in every Access-Request packet.
Failure to include a Message-Authenticator attribute in a Status-
Server packet means that any RADIUS client or server may be
vulnerable to the attacks outlined above. For this reason,
implementations of this specification which fail to require use of
the 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.
9. References 9. References
9.1. Normative references 9.1. Normative references
skipping to change at page 23, line 31 skipping to change at page 24, line 26
[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.
[RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In
User Service (RADIUS) Implementation Issues and Suggested
Fixes", RFC 5080, December 2007.
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
of the Status-Server packet.
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
 End of changes. 40 change blocks. 
126 lines changed or deleted 176 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/