draft-ietf-radext-status-server-03.txt   draft-ietf-radext-status-server-04.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Proposed Standard Category: Informational
<draft-ietf-radext-status-server-03.txt> <draft-ietf-radext-status-server-04.txt>
Expires: June 16, 2009 Expires: September 1, 2009
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
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
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 June 16, 2009. This Internet-Draft will expire on September 1, 2009.
Copyright Notice Copyright Notice
This Internet-Draft is submitted to IETF in full conformance with the Copyright (c) 2009 IETF Trust and the persons identified as the
provisions of BCP 78 and BCP 79. document authors. All rights reserved.
Copyright (c) 2008 IETF Trust and the persons identified as the This document is subject to BCP 78 and the IETF Trust's Legal
document authors. All rights reserved. This document is subject to Provisions Relating to IETF Documents in effect on the date of
BCP 78 and the IETF Trust's Legal Provisions Relating to IETF publication of this document (http://trustee.ietf.org/license-info).
Documents (http://trustee.ietf.org/license-info) in effect on the Please review these documents carefully, as they describe your rights
date of 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.
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.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
2. Problem Statement ........................................ 6 2. Problem Statement ........................................ 6
2.1. Overloading Access-Request .......................... 6 2.1. Overloading Access-Request .......................... 6
2.1.1. Recommendation against Access-Request .......... 7 2.1.1. Recommendation against Access-Request .......... 7
2.2. Overloading Accounting-Request ...................... 7 2.2. Overloading Accounting-Request ...................... 7
2.2.1. Recommendation against Accounting-Request ...... 8 2.2.1. Recommendation against Accounting-Request ...... 8
2.3. Status-Server as a Solution ......................... 8 2.3. Status-Server as a Solution ......................... 8
2.3.1. Status-Server to the RADIUS Authentication port. 8 2.3.1. Status-Server to the RADIUS Authentication port 8
2.3.2. Status-Server to the RADIUS Accounting port .... 9 2.3.2. Status-Server to the RADIUS Accounting port .... 9
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 ................................. 14 4.2. Server Requirements ................................. 14
4.3. More Robust Fail-over with Status-Server ............ 15 4.3. More Robust Fail-over with Status-Server ............ 15
4.4. Proxy Server handling of Status-Server .............. 16 4.4. Proxy Server handling of Status-Server .............. 16
4.5. Realm Routing ....................................... 16 4.5. Realm Routing ....................................... 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 ..... 19 4.6.2. Interaction with RADIUS Client MIB modules ..... 19
5. Additional considerations ................................ 19 5. Table of Attributes ...................................... 19
5.1. Local site testing .................................. 19 6. Examples ................................................. 20
5.2. RADIUS over reliable transports ..................... 21 6.1. Minimal Query to Authentication Port ................ 20
5.3. Other uses for Status-Server ........................ 21 6.2. Minimal Query to Accounting Port .................... 21
6. Table of Attributes ...................................... 21 6.3. Verbose Query and Response .......................... 22
7. Examples ................................................. 22 7. IANA Considerations ...................................... 22
7.1. Minimal Query to Authentication Port ................ 22 8. Security Considerations .................................. 23
7.2. Minimal Query to Accounting Port .................... 23 9. References ............................................... 23
7.3. Verbose Query and Response .......................... 24 9.1. Normative references ................................ 23
8. IANA Considerations ...................................... 25 9.2. Informative references .............................. 23
9. Security Considerations .................................. 25
10. References .............................................. 25
10.1. Normative references ............................... 25
10.2. Informative references ............................. 25
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 12, line 9 skipping to change at page 12, line 9
implementing support for Status-Server. This section describes implementing support for Status-Server. This section describes
implementation details and requirements for RADIUS clients and implementation details and requirements for RADIUS clients and
servers that support Status-Server. servers that support Status-Server.
The following text applies to the authentication and accounting The following text applies to the authentication and accounting
ports. We use the generic terms below to simplify the discussion: ports. We use the generic terms below to simplify the discussion:
* Request packet * Request packet
An Access-Request packet sent to an authentication port, or An Access-Request packet sent to an authentication port, or
an Accounting-Request packet sent to an accounting port an Accounting-Request packet sent to an accounting port.
* Response packet * Response packet
An Access-Accept, Access-Challenge, or Access-Reject packet sent An Access-Accept, Access-Challenge, or Access-Reject packet sent
from an authentication port, or an Accounting-Response packet from an authentication port, or an Accounting-Response packet
sent from an accounting port. sent from an accounting port.
We also refer to "client" as the originator of the Status-Server We also refer to "client" as the originator of the Status-Server
packet, and "server" as the receiver of that packet, and the packet, and "server" as the receiver of that packet, and the
originator of the Response packet. originator of the Response packet.
Using generic terms to describe the Status-Server conversations is Using generic terms to describe the Status-Server conversations is
simpler than duplicating the text for authentication, and accounting simpler than duplicating the text for authentication and accounting
packets. packets.
4.1. Client Requirements 4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be that the generation of Status-Server packets. The default SHOULD be that
it is disabled. As it is undesirable to send queries to servers that it is disabled. As it is undesirable to send queries to servers that
do not support Status-Server, clients SHOULD also have a per-server do not support Status-Server, clients SHOULD also have a per-server
configuration indicating whether or not to enable Status-Server for a configuration indicating whether or not to enable Status-Server for a
particular destination. The default SHOULD be that it is disabled. particular destination. The default SHOULD be that it is disabled.
skipping to change at page 18, line 48 skipping to change at page 18, line 48
combination of these two practices will maximize network reliability combination of these two practices will maximize network reliability
and stability. and stability.
4.6. Management Information Base (MIB) Considerations 4.6. Management Information Base (MIB) Considerations
4.6.1. Interaction with RADIUS Server MIB modules 4.6.1. Interaction with RADIUS Server MIB modules
Since Status-Server packets are sent to the defined RADIUS ports, Since Status-Server packets are sent to the defined RADIUS ports,
they can affect the [RFC4669] and [RFC4671] RADIUS server MIB they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
modules. [RFC4669] defines a counter named modules. [RFC4669] defines a counter named
radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
packets of unknown type that were received". [RFC4671] defines a packets of unknown type that were received". [RFC4671] defines a
similar counter named radiusAcctServTotalUnknownTypes. similar counter named radiusAcctServTotalUnknownTypes.
Implementations not supporting Status-Server, or implementations that Implementations not supporting Status-Server, or implementations that
are configured to not respond to Status-Server packets MUST use these are configured to not respond to Status-Server packets MUST use these
counters to track received Status-Server packets. counters to track received Status-Server packets.
If, however, Status-Server is supported and the server is configured If, however, Status-Server is supported and the server is configured
to respond as described above, then the counters defined in [RFC4669] to respond as described above, then the counters defined in [RFC4669]
and [RFC4671] MUST NOT be used to track Status-Server requests or and [RFC4671] MUST NOT be used to track Status-Server requests or
responses to those requests. That is, when a server fully implements responses to those requests. That is, when a server fully implements
skipping to change at page 19, line 32 skipping to change at page 19, line 32
Clients implementing Status-Server MUST NOT increment [RFC4668] or Clients implementing Status-Server MUST NOT increment [RFC4668] or
[RFC4670] counters upon reception of Response packets to Status- [RFC4670] counters upon reception of Response packets to Status-
Server queries. That is, when a server fully implements Status- Server queries. That is, when a server fully implements Status-
Server, the counters defined in [RFC4668] and [RFC4670] MUST be Server, the counters defined in [RFC4668] and [RFC4670] MUST be
unaffected by the transmission or reception of packets relating to unaffected by the transmission or reception of packets relating to
Status-Server. Status-Server.
If an implementation supports Status-Server and the [RFC4668] or If an implementation supports Status-Server and the [RFC4668] or
[RFC4670] MIB modules, then it SHOULD also support vendor-specific [RFC4670] MIB modules, then it SHOULD also support vendor-specific
MIB extensions containing similar information as those MIB modules, MIB extensions dedicated solely to tracking Status-Server requests
but which are instead dedicated solely to tracking Status-Server and responses. Any definition of the client MIB module extensions
requests and responses. Any definition of the client MIB module for Status-Server is outside of the scope of this document.
extensions for Status-Server is outside of the scope of this
document.
5. Additional considerations
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
sections, they are covered herein.
5.1. Local site testing
There is at least one situation where using Access-Request or
Accounting-Request packets may be useful, despite the recommendations
above in Section 2.1.1 and Section 2.2.1. That situation is local
site testing, where the RADIUS client, server, and user store are
under the control of a single administrator or administrative entity.
In that situation, administrators MAY configure a well-known "test"
user to enable local site testing.
The advantage to creating such a local user is that it is now
possible for the administrator to send a RADIUS request that performs
end-to-end testing of the RADIUS server. As above with Status-
Server, this testing includes RADIUS server responsiveness. It may
also include querying databases of user authentication credentials,
or storing accounting data to a billing database. The information
obtained from performing those queries is that the entire RADIUS
server infrastructure, including all of its dependencies, is
functioning as expected. These queries are most useful in
deployments where an administrator has internal RADIUS servers that
proxy to other internal RADIUS servers, such as for load balancing or
fail over.
If used, the names utilized for these test users SHOULD be difficult
to guess by an attacker. An Access-Request packet for a test user
otherwise should be treated as follows, depending on its origin:
o Packets from localhost (127.0.0.1 or ::1): RADIUS servers
SHOULD treat the request according to local site policy.
o Packets from NASes that normally originate Access-Request
packets (i.e. not proxy servers): RADIUS servers SHOULD respond
with an Access-Reject packet, as the use of Status-Server is
preferred.
o Packets from other machines controlled by the administrator:
RADIUS servers SHOULD treat the request according to local site
policy.
o Packets originating from machines not controlled by the
administrator: RADIUS servers MUST respond with an Access-Reject
packet.
If a RADIUS server is configured to support test users for
Accounting-Request packets, it MAY respond with an Accounting-
Response packet, independent of the origin of the request. However,
any subsequent analysis of the accounting data such as billing or
usage MUST NOT include the data for the test user.
If these recommendations are implemented, then it may be possible in
some situations to safely query a RADIUS server for responsiveness
using Access-Request or Accounting-Request packets. However, this
behavior is still NOT RECOMMENDED.
5.2. RADIUS over reliable transports
Although RADIUS has been assigned two TCP ports (1812/tcp and
1813/tcp) in addition to the commonly used UDP ports, there has been
as yet no specification for using TCP as a reliable transport for
RADIUS. If such a specification were to be created, then the
transport issues discussed in [RFC3539] would apply.
Further, when RADIUS is run over reliable transports, the watchdog
algorithm described in [RFC3539] Section 3.4 MUST be used rather than
the algorithm described above. For the reasons outlined above in
Section 2, Status-Server packets SHOULD be used as the watchdog
request, in preference to Access-Request or Accounting-Request
packets.
Clients sending Status-Server over reliable transport MUST ensure
that the Identifier field is unique for all requests on a particular
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, the client MUST NOT simultaneously send an Access-Request or
Accounting-Request packet with that same Identifier value, on that
connection. Once the client has either received a response to the
Status-Server packet, or has determined that the Status-Server packet
has timed out, it may reuse that Identifier in another packet.
5.3. Other uses for Status-Server
While other uses of Status-Server are possible, uses beyond those
specified here are beyond the scope of this document. It may be
tempting to increase the utility of Status-Server by having the
responses carry additional information, but implementors are warned
that such uses have not been analyzed for potential security issues
or network problems.
Specifically, it may seem useful to leverage a combination of Status-
Server and CoA ports in order to send realm routing information
"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
been insufficient analysis and deployment experience to know if it is
useful, or even if it makes the network less reliable.
6. 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-1 0 0 4 NAS-IP-Address [Note 1]
skipping to change at page 22, line 26 skipping to change at page 20, line 15
NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one
of (NAS-IP-Address or NAS-IPv6-Address). 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 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".
7.1. Minimal Query to Authentication Port 6.1. Minimal Query to Authentication Port
The NAS sends a Status-Server UDP packet with minimal content to a The NAS sends a Status-Server UDP packet with minimal content to a
RADIUS server on port 1812. RADIUS server on port 1812.
The Request Authenticator is a 16 octet random number generated by The Request Authenticator is a 16 octet random number generated by
the NAS. Message-Authenticator is included in order to authenticate the NAS. Message-Authenticator is included in order to authenticate
that the request came from a known client. that the request came from a known client.
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
skipping to change at page 23, line 4 skipping to change at page 20, line 40
that the request came from a known client. that the request came from a known client.
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
82 20 97 c8 4f a3 82 20 97 c8 4f a3
1 Code = Status-Server (12) 1 Code = Status-Server (12)
1 ID = 218 1 ID = 218
2 Length = 38 2 Length = 38
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
The Response Authenticator is a 16 octet MD5 checksum of the code The Response Authenticator is a 16 octet MD5 checksum of the code
(2), id (218), Length (20), the Request Authenticator from above, and (2), id (218), Length (20), the Request Authenticator from above, and
the shared secret. the shared secret.
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
b5 41 1d 66 b5 41 1d 66
1 Code = Access-Accept (2) 1 Code = Access-Accept (2)
1 ID = 218 1 ID = 218
2 Length = 20 2 Length = 20
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
None. None.
7.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 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
skipping to change at page 24, line 10 skipping to change at page 22, line 5
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
Attributes: Attributes:
None. None.
7.3. Verbose Query and Response 6.3. Verbose Query and Response
The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS
server on port 1812. server on port 1812.
The Request Authenticator is a 16 octet random number generated by The Request Authenticator is a 16 octet random number generated by
the NAS. the NAS.
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
skipping to change at page 25, line 5 skipping to change at page 22, line 45
38 3a 34 30 38 3a 34 30
1 Code = Access-Accept (2) 1 Code = Access-Accept (2)
1 ID = 71 1 ID = 71
2 Length = 52 2 Length = 52
16 Request Authenticator 16 Request Authenticator
Attributes: Attributes:
32 Reply-Message (18) 32 Reply-Message (18)
8. IANA Considerations 7. IANA Considerations
This specification does not create any new registries, nor does it This specification does not create any new registries, nor does it
require assignment of any protocol parameters. require assignment of any protocol parameters.
9. Security Considerations 8. Security Considerations
This document defines the Status-Server packet as being similar in This document defines the Status-Server packet as being similar in
treatment to the Access-Request packet, and is therefore subject to treatment to the Access-Request packet, and is therefore subject to
the same security considerations as described in [RFC2865], Section the same security considerations as described in [RFC2865], 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 may have been vulnerable
to DoS attacks as a result. to DoS attacks as a result.
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.
10. References 9. References
10.1. Normative references 9.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.
[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 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.
[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
 End of changes. 23 change blocks. 
150 lines changed or deleted 52 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/