draft-ietf-radext-status-server-06.txt   draft-ietf-radext-status-server-07.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-06.txt> <draft-ietf-radext-status-server-07.txt>
Expires: August 16, 2010 Expires: November 27, 2010
16 February 2010 26 April 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-06 draft-ietf-radext-status-server-07
Status of this Memo 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. provisions of BCP 78 and 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 August 16, 2010. This Internet-Draft will expire on November 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4.6.2. Interaction with RADIUS Client MIB modules ..... 19 4.6.2. Interaction with RADIUS Client MIB modules ..... 19
5. Table of Attributes ...................................... 19 5. Table of Attributes ...................................... 19
6. Examples ................................................. 20 6. Examples ................................................. 20
6.1. Minimal Query to Authentication Port ................ 20 6.1. Minimal Query to Authentication Port ................ 20
6.2. Minimal Query to Accounting Port .................... 21 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 ............................................... 23 9. References ............................................... 23
9.1. Normative references ................................ 23 9.1. Normative references ................................ 23
9.2. Informative references .............................. 23 9.2. Informative references .............................. 24
1. Introduction 1. Introduction
This document specifies a deployed extension to the Remote This document specifies a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. While the Status- clients to query the status of a RADIUS server. While the Status-
Server Code (12) was defined as experimental in [RFC2865] Section 3, Server 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 6, line 33 skipping to change at page 6, line 33
A RADIUS server or proxy implementing this specification SHOULD A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Message (accounting port). An (authentication port) or Accounting-Message (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6. packets are provided in the Section 6.
The "hop by hop" functionality of Status-Server packets is useful to The "hop by hop" functionality of Status-Server packets is useful to
RADIUS clients attempting to determine the status of elements on the RADIUS clients attempting to determine the status of the first
path between the client and a server. Since the Status-Server packet element on the path between the client and a server. Since the
is non-forwardable, lack of a response may only be due to packet loss Status-Server packet is non-forwardable, lack of a response may only
or the failure of the server in the destination IP address, not due be due to packet loss or the failure of the server in the destination
to faults in downstream links, proxies or servers. It therefore IP address, not due to faults in downstream links, proxies or
provides an unambiguous indication of the status of a server. servers. It therefore provides an unambiguous indication of the
status of a server.
This information may be useful in situations where the RADIUS client This information may be useful in situations where the RADIUS client
does not receive a response to an Access-Request. A client may have does not receive a response to an Access-Request. A client may have
multiple proxies configured, with one proxy marked as primary and multiple proxies configured, with one proxy marked as primary and
another marked as secondary. If the client does not receive a another marked as secondary. If the client does not receive a
response to a request sent to the primary proxy, it can "fail over" 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 to the secondary, and send requests to the secondary instead of to
the primary proxy. 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
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 its 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 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 queries, it may be that if a RADIUS server does not respond to those queries, it may be
marked as unresponsive by the NAS. This marking may happen even if marked as unresponsive by the NAS. This marking may happen even if
the server is actively responding to other Access-Requests from that the server is actively responding to other Access-Requests from that
same NAS. This behavior is confusing to administrators who then need same NAS. This behavior is confusing to administrators who then need
skipping to change at page 8, line 21 skipping to change at page 8, line 21
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 server
policy. While this practice is widespread, we caution administrators policy. While this practice is widespread, we caution administrators
to use it with care. to use it with care.
2.2. Why Accounting-Request is inappropriate 2.2. Why Accounting-Request is inappropriate
A similar solution for the problem of querying server status may be A similar solution for the problem of querying server status may be
for a NAS to send specially formed Accounting-Request packets to a for a NAS to send specially formed Accounting-Request packets to a
RADIUS servers accounting port. The NAS can then look for a RADIUS 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.
skipping to change at page 9, line 41 skipping to change at page 9, line 41
In Status-Server Packets, the Authenticator value is a 16 octet In Status-Server Packets, the Authenticator value is a 16 octet
random number, called the Request Authenticator. The value random number, called the Request Authenticator. The value
SHOULD be unpredictable and unique over the lifetime of a SHOULD be unpredictable and unique over the lifetime of a
secret (the password shared between the client and the RADIUS secret (the password shared between the client and the RADIUS
server), since repetition of a request value in conjunction server), since repetition of a request value in conjunction
with the same secret would permit an attacker to reply with a with the same secret would permit an attacker to reply with a
previously intercepted response. Since it is expected that the previously intercepted response. Since it is expected that the
same secret MAY be used to authenticate with servers in same secret MAY be used to authenticate with servers in
disparate geographic regions, the Request Authenticator field disparate geographic regions, the Request Authenticator field
SHOULD exhibit global and temporal uniqueness. SHOULD exhibit global and temporal uniqueness. See [RFC4086]
for suggestions as to how random numbers may be generated.
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 calculating the Response using the same method as used for calculating the Response
skipping to change at page 10, line 42 skipping to change at page 10, line 43
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,
and MUST be ignored if they are included. User authentication and MUST be ignored if they are included. User authentication
credentials such as User-Name, User-Password, CHAP-Password, EAP- credentials such as User-Name, User-Password, CHAP-Password, EAP-
Message, etc. MUST NOT appear in a Status-Server packet sent to a 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 13, line 16 skipping to change at page 13, line 18
source port, that is not used to send Request packets. source port, that is not used to send Request packets.
The above suggestion for a unique source port for Status-Server The above suggestion for a unique source port for Status-Server
packets aids in matching responses to requests. Since the response packets aids in matching responses to requests. Since the response
to a Status-Server packet is an Access-Accept or Accounting-Response to a Status-Server packet is an Access-Accept or Accounting-Response
packet, those responses are indistinguishable from other packets sent packet, those responses are indistinguishable from other packets sent
in response to a Request packet. Therefore, the best way to in response to a Request packet. Therefore, the best way to
distinguish them from other traffic is to have a unique port. distinguish them from other traffic is to have a unique port.
A client MAY send a Status-Server packet from a source port also used A client MAY send a Status-Server packet from a source port also used
to send Request packets. In that case, the Identifer field MUST be to send Request packets. In that case, the Identifier field MUST be
unique across all outstanding Request packets for that source port, unique across all outstanding Request packets for that source port,
independent of the value of the RADIUS Code field for those independent of the value of the RADIUS Code field for those
outstanding requests. Once the client has either received a response outstanding requests. Once the client has either received a response
to the Status-Server packet, or has determined that the Status-Server to the Status-Server packet, or has determined that the Status-Server
packet has timed out, it may reuse that Identifier in another packet. packet has timed out, it may reuse that Identifier in another packet.
Robust implementations SHOULD accept any Response packet as a valid Robust implementations SHOULD accept any Response packet as a valid
response to a Status-Server packet, subject to the validation response to a Status-Server packet, subject to the validation
requirements defined above for the Response Authenticator. The code requirements defined above for the Response Authenticator. The code
field of the packet matters less than the fact that a valid, signed, field of the packet matters less than the fact that a valid, signed,
skipping to change at page 13, line 51 skipping to change at page 14, line 4
valid responses from a server, and mark that server as unresponsive. valid responses from a server, and mark that server as unresponsive.
This behavior would affect the stability of a RADIUS network, as This behavior would affect the stability of a RADIUS network, as
responsive servers would erroneously be marked as unresponsive. We responsive servers would erroneously be marked as unresponsive. We
therefore recommend that clients should be liberal in what they therefore recommend that clients should be liberal in what they
accept as responses to Status-Server queries. accept as responses to Status-Server queries.
4.2. Server Requirements 4.2. Server Requirements
Servers SHOULD permit administrators to globally enable or disable Servers SHOULD permit administrators to globally enable or disable
the acceptance of Status-Server packets. The default SHOULD be that the acceptance of Status-Server packets. The default SHOULD be that
it is enabled. Servers SHOULD also permit adminstrators to enable or it is enabled. Servers SHOULD also permit administrators to enable
disable acceptance of Status-Server packets on a per-client basis. or disable acceptance of Status-Server packets on a per-client basis.
The default SHOULD be that it is enabled. The default SHOULD be that it is enabled.
Status-Server packets originating from clients that are not permitted Status-Server packets originating from clients that are not permitted
to send the server Request packets MUST be silently discarded. If a to send the server Request packets MUST be silently discarded. If a
server does not support Status-Server packets, or is configured to server does not support Status-Server packets, or is configured to
not respond to them, then it MUST silently discard the packet. not respond to them, then it MUST silently discard the packet.
We note that [RFC2865] Section 3 defines a number of RADIUS Codes, We note that [RFC2865] Section 3 defines a number of RADIUS Codes,
but does not make statements about which Codes are valid for port but does not make statements about which Codes are valid for port
1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS
skipping to change at page 15, line 6 skipping to change at page 15, line 6
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 its normal activities MAY silently discard Status- unable to perform its normal activities MAY silently discard Status-
Server packets. This situation can happen, for example, when a Server packets. This situation can happen, for example, when a
server requires access to a database for normal operation, but the server requires access to a database for normal operation, but the
connection to that database is down. Or, it may happen when the connection to that database is down. Or, it may happen when the
accepted load on the server is lower than the offered load. accepted load on the server is lower than the offered load.
Some server implementations require that Access-Request packets are Some server implementations require that Access-Request packets 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-
packets sent to an "authentication" port with an Access-Accept Server packets sent to an "authentication" port with an Access-Accept
packet. Those implementations SHOULD reply to Status-Server packets packet. Those implementations SHOULD reply to Status-Server packets
sent to an "accounting" port with an Accounting-Response packet. sent to an "accounting" port with an Accounting-Response packet.
Some server implementations accept both Access-Request and Some server implementations accept both Access-Request and
Accounting-Request packets on the same port, and do not distinguish Accounting-Request packets on the same port, and 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
skipping to change at page 15, line 49 skipping to change at page 15, line 49
client can initiate failover to another proxy. By continuing to send client can initiate failover to another proxy. By continuing to send
Status-Server packets to the original proxy at an interval of Tw, the Status-Server packets to the original proxy at an interval of Tw, the
RADIUS client can determine when the original proxy becomes RADIUS client can determine when the original proxy becomes
responsive again. 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.
The above behavior is modelled after [RFC3539] Section 3.4.1. We The above behavior is modeled after [RFC3539] Section 3.4.1. We note
note that if a reliable transport is used for RADIUS, then the that if a reliable transport is used for RADIUS, then the algorithms
algorithms specified in [RFC3539] MUST be used in preference to the specified in [RFC3539] MUST be used in preference to the ones given
ones given here. here.
4.4. Proxy Server handling of Status-Server 4.4. Proxy Server handling of Status-Server
Many RADIUS servers can act as proxy servers, and can forward Many RADIUS servers can act as proxy servers, and can forward
requests to another RADIUS server. Such servers MUST NOT proxy requests to another RADIUS server. Such servers MUST NOT proxy
Status-Server packets. The purpose of Status-Server as specified Status-Server packets. The purpose of Status-Server as specified
here is to permit the client to query the responsiveness of a server here is to permit the client to query the responsiveness of a server
that it has a direct relationship with. Proxying Status-Server that it has a direct relationship with. Proxying Status-Server
queries would negate any usefulness that may be gained by queries would negate any usefulness that may be gained by
implementing support for them. implementing support for them.
skipping to change at page 16, line 44 skipping to change at page 16, line 44
The schematic below demonstrates this scenario. The schematic below demonstrates this scenario.
/-> RADIUS Proxy P -----> RADIUS Server for Realm A /-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ / / \ /
NAS X NAS X
\ / \ \ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B \-> RADIUS Proxy S -----> RADIUS Server for Realm B
That is, the NAS has relationships with two RADIUS Proxies, P and S. That is, the NAS has relationships with two RADIUS Proxies, P and S.
Each RADIUS Proxyhas relationships with RADIUS Servers for both Realm Each RADIUS Proxy has relationships with RADIUS Servers for both
A and Realm B. Realm A and Realm B.
In this scenario, the RADIUS Proxies can determine if one or both of In this scenario, the RADIUS Proxies can determine if one or both of
the RADIUS Servers are dead or unreachable. The NAS can determine if the RADIUS Servers are dead or unreachable. The NAS can determine if
one or both of the RADIUS Proxies are dead or unreachable. There is one or both of the RADIUS Proxies are dead or unreachable. There is
an additional case to consider, however. an additional case to consider, however.
If RADIUS Proxy P cannot reach the RADIUS Server for Realm A, but the If RADIUS Proxy P cannot reach the RADIUS Server for Realm A, but the
RADIUS Proxy S can reach that RADIUS Server, then the NAS cannot RADIUS Proxy S can reach that RADIUS Server, then the NAS cannot
discover this information using the Status-Server queries as outlined discover this information using the Status-Server queries as outlined
above. It would therefore be useful for the NAS to know that Realm A above. It would therefore be useful for the NAS to know that Realm A
skipping to change at page 17, line 27 skipping to change at page 17, line 27
server along the proxy chain being unreachable. server along the proxy chain being unreachable.
In the worst case, failures in routing for Realm A may affect users In the worst case, failures in routing for Realm A may affect users
of Realm B. For example, if RADIUS Proxy P can reach Realm B but not of Realm B. For example, if RADIUS Proxy P can reach Realm B but not
Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then
active paths exist to handle all RADIUS requests. However, depending active paths exist to handle all RADIUS requests. However, depending
on the NAS and RADIUS Proxy implementation choices, the NAS may not on the NAS and RADIUS Proxy implementation choices, the NAS may not
be able to determine which server requests may be sent to in order to be able to determine 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
into the traditional RADIUS model, and both are therefore outside of into the traditional RADIUS model, and both are therefore outside of
the scope of this specification. the scope of this specification.
The problem is discussed here in order to define how best to use The problem is discussed here in order to define how best to use
Status-Server in this situation, rather than to define a new Status-Server in this situation, rather than to define a new
solution. solution.
skipping to change at page 18, line 16 skipping to change at page 18, line 16
/-> RADIUS Proxy P -----> RADIUS Server P /-> RADIUS Proxy P -----> RADIUS Server P
/ \ / / \ /
NAS X NAS X
\ / \ \ / \
\-> RADIUS Proxy S -----> RADIUS Server S \-> RADIUS Proxy S -----> RADIUS Server S
In this situation, if all participants implement Status-Server as In this situation, if all participants implement Status-Server as
defined herein, any one link may be broken, and all requests from the defined herein, any one link may be broken, and all requests from the
NAS will still reach a RADIUS Server. If two links are broken at NAS will still reach a RADIUS Server. If two links are broken at
different places, (i.e. not both links from the NAS), then all different places, (i.e., not both links from the NAS), then all
requests from the NAS will still reach a RADIUS Server. In many requests from the NAS will still reach a RADIUS Server. In many
situations where three or more links are broken, then requests from situations where three or more links are broken, then requests from
the NAS may still reach a RADIUS Server. the NAS may still reach a RADIUS Server.
It is RECOMMENDED, therefore, that implementations desiring the most It is RECOMMENDED, therefore, that implementations desiring the most
benefit from Status-Server also implement server failover. The benefit from Status-Server also implement server failover. The
combination of these two practices will maximize network reliability combination of these two practices will maximize network reliability
and stability. and stability.
4.6. Management Information Base (MIB) Considerations 4.6. Management Information Base (MIB) Considerations
skipping to change at page 19, line 40 skipping to change at page 19, line 40
Status- Access- Accounting- Status- Access- Accounting-
Server Accept Response # Attribute Server Accept Response # Attribute
0 0 0 1 User-Name, 0 0 0 1 User-Name,
0 0 0 2 User-Password 0 0 0 2 User-Password
0 0 0 3 CHAP-Password 0 0 0 3 CHAP-Password
0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1)
0 0+ 0 18 Reply-Message 0 0+ 0 18 Reply-Message
0+ 0+ 0+ 26 Vendor-Specific 0+ 0+ 0+ 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier (Note 1) 0-1 0 0 32 NAS-Identifier (Note 1)
0 0 0 70 EAP-MEssage 0 0 0 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-* 0 0 0 103-121 Digest-*
Note 1: A Status-Server SHOULD contain one of (NAS-IP-Address or NAS- Note 1: A Status-Server SHOULD contain one of (NAS-IP-Address or NAS-
IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one 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.
skipping to change at page 23, line 11 skipping to change at page 23, line 11
Authenticator attribute. Early implementations supporting Status- Authenticator attribute. Early implementations supporting Status-
Server did not enforce this requirement, and were vulnerable to the Server did not enforce this requirement, and were vulnerable to the
following attacks: following attacks:
* Servers not checking Message-Authenticator could respond to * Servers not checking Message-Authenticator could respond to
Status-Server packets from an attacker, potentially enabling Status-Server packets from an attacker, potentially enabling
a reflected DoS attack onto a real client. a reflected DoS attack onto a real client.
* Servers not checking Message-Authenticator could be subject to a * Servers not checking Message-Authenticator could be subject to a
race condition, where an attacker could see an Access-Request race condition, where an attacker could see an Access-Request
packet from a valid client, and synthesise a Status-Server packet packet from a valid client, and synthesize a Status-Server packet
containing the same Request Authenticator. If the attacker won the containing the same Request Authenticator. If the attacker won the
race against the valid client, the server could respond with an race against the valid client, the server could respond with an
Access-Accept, and potentially authorize unwanted service. Access-Accept, and potentially authorize unwanted service.
The last attack is similar to a related attack when Access-Request The last attack is similar to a related attack when Access-Request
packets contain a CHAP-Password but no Message-Authenticator. We re- packets contain a CHAP-Password but no Message-Authenticator. We re-
iterate the suggestion of [RFC5080] Section 2.2.2, which suggests iterate the suggestion of [RFC5080] Section 2.2.2, which proposes
that all clients send a Message-Authenticator in every Access-Request that all clients send a Message-Authenticator in every Access-Request
packet, and that all servers configurably require that a Message- packet, and that all servers have a configuration setting to require
Authenticator attribute be used in every Access-Request packet. (or not) that a Message-Authenticator attribute be used in every
Access-Request packet.
Failure to include a Message-Authenticator attribute in a Status- Failure to include a Message-Authenticator attribute in a Status-
Server packet means that any RADIUS client or server may be Server packet means that any RADIUS client or server may be
vulnerable to the attacks outlined above. For this reason, vulnerable to the attacks outlined above. For this reason,
implementations of this specification which fail to require use of implementations of this specification which fail to require use of
the Message-Authenticator attribute are NOT RECOMMENDED. 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
[RFC2865] [RFC1321]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April,
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1992
[RFC4282]
Aboba, B., and Beadles, M. at al, "The Network Access Identifier",
RFC 4282, December 2005.
9.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.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[RFC4086] Eastlake, D., et al, "Randomness Requirements for Security",
RFC 4086, June 2005.
[RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access
Identifier", RFC 4282, December 2005.
9.2. Informative references
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [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 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (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
skipping to change at page 24, line 42 skipping to change at page 24, line 47
Parts of the text in Section 3 defining the Request and Response Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3. Authenticators were taken with minor edits from [RFC2865] Section 3.
The author would like to thank Mike McCauley of Open Systems The author would like to thank Mike McCauley of Open Systems
Consultants for making a Radiator server available for Consultants for making a Radiator server available for
interoperability testing. interoperability testing.
Ignacio Goyret provided valuable feedback on the history and security Ignacio Goyret provided valuable feedback on the history and security
of the Status-Server packet. of the Status-Server packet.
Authors' Addresses Author's Address
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org http://freeradius.org
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 27 change blocks. 
48 lines changed or deleted 56 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/