Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS
Category: Informational
<draft-dekok-radius-status-server-00.txt>
6 February 2007
Use of Status-Server Packets in RADIUS
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
[RFC2865] defines a Status-Server code for use in RADIUS, but labels
it as "Experimental" without further discussion. This document
describes practical uses for Status-Server that have been implemented
as a method of querying the status of a RADIUS server.
DeKok, Alan Informational [Page 1]
INTERNET-DRAFT Status-Server Practices 6 February 2007
Table of Contents
1. Introduction ............................................. 2
1.1. Terminology ......................................... 2
1.2. Requirements Language ............................... 3
2. Problem Statement ........................................ 4
2.1. Sending Access-Request "pings" ...................... 4
2.1.1. Recommendation against Access-Request .......... 5
2.2. Sending Accounting-Request "pings" .................. 5
2.2.1. Recommendation against Accounting-Request ...... 6
2.3. Status-Server as a Solution ......................... 6
2.3.1. Status-Server instead of Access-Request ........ 6
2.3.2. Status-Server instead of Accounting-Request .... 6
3. Packet Format ............................................ 7
3.1. Consistent definition for Status-Server ............. 9
4. Implementation notes ..................................... 9
4.1. Client Requirements ................................. 10
4.2. Server Requirements ................................. 11
4.3. More Robust Fail-over with Status-Server ............ 11
4.4. Proxy Server handling of Status-Server .............. 12
4.5. MIB Considerations .................................. 12
4.5.1. Interaction with RADIUS Server MIBs ............ 13
4.5.2. Interaction with RADIUS Client MIBs ............ 13
5. Additional considerations ................................ 13
5.1. RADIUS over reliable transports ..................... 13
5.2. Other uses for Status-Server ........................ 14
5.3. Potential Uses for Status-Client .................... 14
6. Table of Attributes ...................................... 14
7. IANA Considerations ...................................... 15
8. Security Considerations .................................. 15
9. References ............................................... 15
9.1. Informative references .............................. 15
9.2. Normative references ................................ 16
Intellectual Property Statement .............................. 16
Disclaimer of Validity ....................................... 18
Full Copyright Statement ..................................... 18
DeKok, Alan Informational [Page 2]
INTERNET-DRAFT Status-Server Practices 6 February 2007
1. Introduction
The RADIUS Working Group was formed in 1995 to document the protocol
of the same name, and created a number of standards surrounding the
protocol. It also defined experimental commands within the protocol,
without elaborating further on the potential uses of those commands.
This document describes how some of the current implementations on
the market are using Status-Server packets as an application-layer
method of "pinging" a RADIUS server to see if it is responding to
requests. These queries do not affect the normal operation of the
server, and do not result in any side effects other than incrementing
internal packet counters.
These "pings" are not intended to be the application-layer watchdog
messages described in [RFC3539] Section 3.4. That document describes
AAA protocols that run over reliable transports, which handle
retransmissions internally. Since RADIUS runs over UDP rather than
TCP, the full watchdog mechanism is not applicable here.
The rest of this document is laid out as follows. Section 2 contains
the problem statement, and explanations as to why some possible
solutions have unwanted side effects. Section 3 defines the Status-
Server packet format. Section 4 contains implementation notes with
detailed client and server requirements. Section 5 lists additional
considerations not covered in the other sections. The remaining text
lists the typical RADIUS table of attributes, and covers some
additional security considerations not covered in the rest of the
document.
1.1. Terminology
This document uses the following terms:
Network Access Server (NAS)
The device providing access to the network. Also known as the
Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.
Home Server
A RADIUS server that is authoritative for user authorization and
authentication.
Proxy Server
A RADIUS server that acts as a Home Server to the NAS, but in turn
proxies the request to another Proxy Server, or to a Home Server.
silently discard
This means the implementation discards the packet without further
DeKok, Alan Informational [Page 3]
INTERNET-DRAFT Status-Server Practices 6 February 2007
processing. The implementation SHOULD provide the capability of
logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter.
1.2. Requirements Language
In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
DeKok, Alan Informational [Page 4]
INTERNET-DRAFT Status-Server Practices 6 February 2007
2. Problem Statement
It is often useful know if a RADIUS server is alive and responding to
requests. The most accurate way to obtain this information is to
query the server via via normal protocol traffic, as other methods
are either less accurate, or cannot be performed remotely.
The reasons for wanting to know the status of a server are many. The
administrator may simply by curious of the server is responding, and
may not have access to NAS or traffic data that would give him that
information. The queries may also be performed automatically by a
NAS or proxy server, which is configured to send packets to a RADIUS
server, and where that server may not be responding. That is, while
[RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful,
it is useful to send "Are you Alive" queries to a server once it has
been marked "dead" due to unresponsiveness.
The occasional query to a "dead" server has little impact on the
network or server load, and permits clients to more quickly discover
when the server returns to a responsive state. In all, status
queries are a useful part of a network server deployment.
2.1. Sending Access-Request "pings"
One possible solution to the problem of querying server status is to
send Access-Request packets as a kind of application-level "ping" to
the RADIUS port (1812), and then to look for an Access-Accept
response. However, the server may then conclude that a real user has
logged onto a NAS, and perform local site actions that are
undesirable for a simple status qeury.
The server may otherwise respond with an Access-Challenge, indicating
that it believes that it is engaging in an extended RADIUS
authentication conversation with a user via the NAS. This side
effect is also unwanted, as the request was intended as a simple
status query, rather than a desire to start a longer protocol
conversation.
Or, the server may respond with an Access-Reject, indicating that the
user is not authorized to gain access to network. As above, the
server may also perform local site actions, such as warning an
administrator of failed login attempts. The server may also delay
the Access-Reject response, in the traditional manner of of rate-
limiting failed authentication attempts. This delay in response to
the "ping" means that for a period of time, the querying
administrator is unsure as to whether or not the server is down, is
slow to respond, or is intentionally delaying its response to the
query.
DeKok, Alan Informational [Page 5]
INTERNET-DRAFT Status-Server Practices 6 February 2007
In addition, using Access-Request packets as "pings" may mean that
the server has to have local users configured whose sole reason for
existence is to enable the "ping" requests. Unless the server policy
is carefully designed for those users, it may be possible for an
attacker to use that users credentials to gain unauthorized network
access.
We note that some NAS implementations currently use Access-Request
packets as described above, with fixed (and non configurable)
username and password. Issues with those implementations sometimes
mean that if a RADIUS server does not respond to those "ping"
request, the server may be marked as unresponsive, even though it is
actively responding to other Access-Requests. This behavior is
confusing to administrators who have to understand why a live server
is marked "unresponsive".
2.1.1. Recommendation against Access-Request
For the reasons outlined above, NAS implementors SHOULD NOT use
Access-Request packets as "pings" to see if a server is alive.
Similarly, site administrators SHOULD NOT configure test users whose
sole reason for existence is to enable "pings" via Access-Request
packets.
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
policy. We do not recommend against this practice, though we do warn
administrators to use it with caution.
2.2. Sending Accounting-Request "pings"
A similar solution for problem of querying server status may be to
send Accounting-Request packets as a kind of application-level "ping"
to the RADIUS accounting port (1813), and then to look for an
Accounting-Response packet. As above, the server may then conclude
that a real user has logged onto a NAS, and perform local site
actions that are an undesirable for a simple status qeury.
In addition, some attributes are mandatory to include in an
Accounting-Request. This requirement forces the administrator who
desires to query the server to create "fake" values for those
attributes in a test packet. These "fake" values increase the work
required to perform a simple query, and may pollute the servers
accounting database with invalid data.
DeKok, Alan Informational [Page 6]
INTERNET-DRAFT Status-Server Practices 6 February 2007
2.2.1. Recommendation against Accounting-Request
For the reasons outlined above, NAS implementors SHOULD NOT use
Accounting-Request packets as "pings" to see if a server is alive.
Similarly, site administrators SHOULD NOT configure accounting
policies whose sole reason for existence is to enable "pings" via
Accounting-Request packets.
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
policy. We do not recommend against this practice, though we do warn
administrators to use it with caution.
2.3. Status-Server as a Solution
A better solution to the problem is to use Status-Server. The name
appears to be intended for packets that query the status of a server,
the packets are previously undefined, and the problem statement
outlined in Section 3 indicates that administrators need the ability
to qury the a servers status. The difficulty before now has been an
interoperable method of performing these queries.
2.3.1. Status-Server instead of Access-Request
Status-Server SHOULD be used instead of Access-Request to query the
responsiveness of a server. In this use-case, the protocol exchange
between client and server is similar to the normal exchange of
Access-Request and Access-Accept, as diagrammed below.
NAS RADIUS server
--- -------------
Status-Server/
Message-Authenticator ->
<- Access-Accept/
Reply-Message
With this design, the Status-Server packet replaces an Access-Request
packet, without the previously mentioned side effects.
2.3.2. Status-Server instead of Accounting-Request
Status-Server may be used instead of Accounting-Request to query the
responsiveness of a server. In this use-case, the protocol exchange
between client and server is similar to the normal exchange of
Accounting-Request and Accounting-Response, as diagrammed below.
NAS RADIUS server
--- -------------
Status-Server/
DeKok, Alan Informational [Page 7]
INTERNET-DRAFT Status-Server Practices 6 February 2007
Message-Authenticator ->
<- Accounting-Response
With this design, the Status-Server packet replaces an
Accounting-Request packet, without the previously mentioned side
effects.
3. Packet Format
Status-Server packets have the normal RADIUS packet form, with the
fields 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 instead document the details specific to implementing Status-
Server.
The Authenticator field of Status-Server packets MUST be generated
using the same method as that used for the Request Authenticator
field of Access-Request packets. In more detail, the definition of
Request Authenticator for Status-Server packets is given below.
The role of the Identifier field is the same for Status-Server as for
other packets. However, as Status-Server is taking the role of
Access-Request or Accounting-Request packets, there is the potential
for Status-Server requests to be in conflict with Access-Request or
Accounting-Request packets with the same Identifier. In Section 4.2,
below, we describe how these problems can be avoided.
Request Authenticator
In Status-Server Packets, the Authenticator value is a 16 octet
random number, called the Request Authenticator. The value
SHOULD be unpredictable and unique over the lifetime of a
secret (the password shared between the client and the RADIUS
server), since repetition of a request value in conjunction
with the same secret would permit an attacker to reply with a
previously intercepted response. Since it is expected that the
same secret MAY be used to authenticate with servers in
disparate geographic regions, the Request Authenticator field
SHOULD exhibit global and temporal uniqueness.
The Request Authenticator value in a Status-Server packet
SHOULD also be unpredictable, lest an attacker trick a server
into responding to a predicted future request, and then use the
response to masquerade as that server to a future Status-
Server.
Although protocols such as RADIUS are incapable of protecting
against theft of an authenticated session via realtime active
DeKok, Alan Informational [Page 8]
INTERNET-DRAFT Status-Server Practices 6 February 2007
wiretapping attacks, generation of unique unpredictable
requests can protect against a wide range of active attacks
against authentication.
Similarly, the Response Authenticator field of Access-Accept packets
sent in response to Status-Server queries MUST be generated using the
normal method for calculating the Response Authenticator of the
Access-Accept, with the Status-Server Request Authenticator taking
the place of the Access-Request Request Authenticator.
The Response Authenticator field of Accounting-Response packets sent
in response to Status-Server queries MUST be generated using the
normal method for calculating the Response Authenticator of the
Accounting-Response, with the Status-Server Request Authenticator
taking the place of the Accounting-Request Request Authenticator.
In more detail, the definition of Response Authenticator is given
below.
Response Authenticator
The value of the Authenticator field in Access-Accept, or
Accounting-Response packets is called the Response
Authenticator, and contains a one-way MD5 hash calculated over
a stream of octets consisting of: the RADIUS packet, beginning
with the Code field, including the Identifier, the Length, the
Request Authenticator field from the Status-Server packet, and
the response Attributes (if any), followed by the shared
secret. That is, ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
denotes concatenation.
In addition to the above requiremets, all Status-Server packets MUST
include a Message-Authenticator attribute. Failure to do so would
mean that the packets could be trivially spoofed.
Status-Server packets MAY include NAS-Identifier, and/or NAS-IP-
Address or NAS-IPv6-Address. These attributes are not necessary for
the operation of Status-Server, but may be useful information to a
server that receives those packets.
Other attributes SHOULD NOT be included in a Status-Server packet.
User authentication or authorization credentials such as User-Name,
User-Password, CHAP-Password, etc. MUST NOT appear in a Status-Server
packet sent to a server authentication port. User or NAS accounting
attributes such as User-Name, Acct-Session-Id, or Acct-Status-Type
MUST NOT appear in a Status-Server packet sent to a server accounting
port.
DeKok, Alan Informational [Page 9]
INTERNET-DRAFT Status-Server Practices 6 February 2007
Similarly, the Access-Accept MAY include a Reply-Message attribute.
The Access-Accept or Accounting-Response packets sent in response to
a Status-Server query SHOULD NOT contain any attributes. As the
intent is to implement a simple "ping" instead of user authentication
or accounting, there is no reason to include other attributes in
either the query or the corresponding response.
Detailed examples are given in Section XX, below.
3.1. Consistent definition for Status-Server
When sent to a RADIUS accounting port, Status-Server packets are
calculated as described above. That is, even though the packets are
being sent to an accounting port, they are not created via the same
method as Accounting-Request packets. This difference from the
normal Accounting-Request handling has a number of benefits.
Having one definition for Status-Server is simpler than defining the
packet differently when it is sent to different ports. In addition,
if we were to define Status-Server as a similar to Accounting-
Request, but containing no attributes, then the packets could be
trivially spoofed.
We therefore define Status-Server consistently, and vary the response
packets depending on the port to which the request is sent. When
sent to an authentication port, the response to a Status-Server query
is an Access-Accept packet. When sent to an accounting port, the
response to a Status-Server query is an Accounting-Response packet.
4. Implementation notes
There are a number of considerations to take into account when
implementing support for Status-Server. This section describes
implementation details and requirements for RADIUS clients and
servers that support Status-Server.
The following text applies to both authentication and accounting
ports. We use the generic term "request packets" to mean "Access-
Request packets sent to an authentication port, or Accounting-Request
packets sent to an accounting port." We also use the generic term
"response packets" to mean "Access-Accept, Access-Challenge, or
Access-Reject packets sent from an authentication port, or
Accounting-Response packets sent from an accounting port."
Using generic terms to describe the Status-Server conversations is
simpler than duplicating the text for both authentication and
accounting ports.
DeKok, Alan Informational [Page 10]
INTERNET-DRAFT Status-Server Practices 6 February 2007
4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be to
globally disable it. As it is undesirable to send queries to servers
that do not support Status-Server, clients SHOULD also have a per-
server configuration indicating whether or not the server support
Status-Server. The default SHOULD be that the server does not
support Status-Server.
The client SHOULD also have a configurable global timer (Tw) that is
used when sending periodic Status-Server queries during server fail-
over. The default value SHOULD be 30 seconds, and the value MUST NOT
be permitted to be set below 6 seconds. If a response has not been
received within the timeout period, the request is deemed to have no
response, and MUST be discarded.
When Status-Server packets are sent from a client, they MUST NOT be
retransmitted. Instead, the Identity field MUST be changed for every
Status-Server packet. The old request should be discarded, and a new
Status-Server packet should be generated and sent, with new Identity
and Authenticator fields.
Clients MUST include the Message-Authenticator attribute in all
Status-Server packets. Failure to do so would mean that the packets
could be trivially spoofed, leading to potential denial of service
(DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server
packet. As the intent of the packet is a simple status query, there
is no reason for any additional attributes to appear in Status-Server
packets.
The client MAY increment packet counters as a result of sending a
Status-Server, or receiving a response packet. The client MUST NOT
perform any other action that is normally performed when it receives
a response packet, such as permitting a user login access to a port.
When a client sends Status-Server packets, those requests MUST NOT be
sent from a source port that is used to send Access-Request or
Accounting-Request packets. Clients SHOULD dedicate a source port
solely for sending Status-Server requests. Clients MAY send Status-
Server requests to both authentication and accounting destination
ports from the same source port.
The above requirement for a unique source port aids in matching
responses to requests. Since the response to a Status-Server packet
is an Access-Accept or Accounting-Response packet, those responses
are indistinguishable from normal packets sent in response to an
Access-Request or Accounting-Request. Therefore, the best way to
DeKok, Alan Informational [Page 11]
INTERNET-DRAFT Status-Server Practices 6 February 2007
distinguish them from normal traffic is to have a unique port.
4.2. Server Requirements
Servers SHOULD permit administrators to globally enable or disable
the acceptance of Status-Server packets. The default SHOULD be to
globally enable it.
Status-Server packets originating from clients that are not permitted
to send the server request packets MUST be silently discarded. If a
server does not support Status-Server packets, or is configured to
not respond to them, then it MUST silently discard the packet.
Servers SHOULD silently discard Status-Server packets if they
determine that a client is sending too many Status-Server requests in
a particular time period. Note that the server MAY discard the
packet without first validating the Message-Authenticator attribute.
The method used by a server to make this determination is
implementation-specific, and out of scope of this document.
If a server supports Status-Server packets, and is configured to
respond to them, and receives a packet from a known client, it MUST
validate the Message-Authenticator attribute as defined in [RFC3579]
Section 3.2. Packets failing validation MUST be silently discarded.
Servers SHOULD NOT otherwise discard Status-Server packets if they
have recently sent the client a response packet. The query may have
originated from an administrator who does not have access to the
response packet stream, or who is interested in obtaining additional
information about the server.
The server SHOULD prioritize the handling Status-Server queries over
normal request handling, subject to the rate limiting described
above. As the intent of Status-Server is to qeury the responsiveness
of the server, it is unhelpful for the server to queue Status-Server
packets for later handling. Such queuing may lead a client to
believe that a server is unresponsive.
The server MAY increment packet counters as a result of receiving a
Status-Server, or sending a response packet. The server MUST NOT
perform any other action that is normally performed when it receives
a request, other than sending a response packet.
4.3. More Robust Fail-over with Status-Server
A common problem in RADIUS client implementations is the
implementation of a robust fail-over mechanism. A client may have
multiple servers configured for examplem with one server marked as
DeKok, Alan Informational [Page 12]
INTERNET-DRAFT Status-Server Practices 6 February 2007
primary and another marked as secondary. If the client determines
that the primary is unresponsive, it "fails over" to the secondary,
and begins to send requests to the secondary instead of the primary.
However, it is difficult to know when the client should start sending
requests to the primary again. Sending test Access-Requests or
Accounting-Requests to see if the server is alive has all of the
issues outlined above. Clients could alternately send real traffic
to the primary, on the hope that it is responsive. If the server is
still unresponsive, however, the result may be lost accounting data
or user login failures. This problem is one that the Status-Server
solution can address.
When a client fails over from one server to another because of a lack
of responsiveness, it SHOULD send periodic Status-Server packets to
the unresponsive server, using the timer (Tw) defined above.
Once three time periods have passed where Status-Server messages have
been sent and responded to, the server should be deemed responsive
and RADIUS requests may sent to it again. This determination should
be made separately for each server that the client has a relationship
with, though the same algorithm applies to both authentiction and
accounting servers.
The above behavior is modelled after [RFC3539] Section 3.4.1. We
note that if a reliable transport is used for RADIUS, then the
algorithms specified in [RFC3539] MUST be used in preference to the
ones given here.
4.4. Proxy Server handling of Status-Server
Many RADIUS servers can act as proxy servers. Such servers MUST NOT
proxy Status-Server packets. The purpose of Status-Server as
specified here is to permit the client to query the responsiveness of
a server. Proxying Status-Server queries negates any usefulness that
may be gained by implementing support for them.
Proxy servers MAY be configured to respond to Status-Server queries
from clients, and MAY act as clients sending Status-Server queries to
other servers. However, those operations MUST be independent of one
another.
4.5. MIB Considerations
DeKok, Alan Informational [Page 13]
INTERNET-DRAFT Status-Server Practices 6 February 2007
4.5.1. Interaction with RADIUS Server MIBs
Since Status-Server packets are sent to the normal RADIUS ports, the
question arises of how these packets affect the [RFC4669] and
[RFC4671] RADIUS server MIBs. [RFC4669] defines a counter named
radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS
packets of unknown type that were received". [RFC4671] defines a
similar counter named radiusAcctServTotalUnknownTypes.
Implementations not supporting Status-Server, or implementations that
are configured to not respond to Status-Server packets MUST use these
counters to track received Status-Server packets.
If, however, Status-Server is supported and the server is configured
to respond as described above, then the counters defined in [RFC4669]
and [RFC4671] MUST NOT be used to track Status-Server requests or
responses to those requests. That is, the [RFC4669] and [RFC4671]
counters MUST be unaffected by the transmission or reception of
packets relating to Status-Server.
If an implementation supports Status-Server and the [RFC4669] or
[RFC4671] MIBs, then it SHOULD also support vendor-specific MIBs
containing similar information as those MIBs, but which are instead
dedicated solely to tracking Status-Server requests and responses.
The exact definition of the server MIBs for Status-Server is outside
of the scope of this document.
4.5.2. Interaction with RADIUS Client MIBs
Clients implementing Status-Server MUST NOT increment [RFC4668] or
[RFC4670] counters upon reception of response packets to Status-
Server queries. That is, the [RFC4668] and [RFC4670] counters MUST
be unaffected by the transmission or reception of packets relating to
Status-Server.
If an implementation supports Status-Server and the [RFC4668] or
[RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs
containing similar information as those MIBs, but which are instead
dedicated solely to tracking Status-Server requests and responses.
The exact definition of the clients MIBs for Status-Server is outside
of the scope of this document.
5. Additional considerations
5.1. RADIUS over reliable transports
Although RADIUS has been assigned two TCP ports (1812/tcp and
1812/tcp) in addition to the normally used UDP ports, there has been
DeKok, Alan Informational [Page 14]
INTERNET-DRAFT Status-Server Practices 6 February 2007
as yet no implementations using TCP as a reliable transport for
RADIUS. If an implementation 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. Status-Server SHOULD be the packet
used as the watchdog request, in prefence to Access-Request or
Accounting-Request.
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 re-use that Identifier in an Access-Request or
Accounting-Request.
5.2. 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, implementors are warned that
such used have not been analysed for potential security issues or
network problems.
5.3. Potential Uses for Status-Client
RADIUS currently defines an experimental Status-Client packet type,
in addition to Status-Server. It could be possible to define Status-
Client similar to Status-Server, except that it would be applicable
to Change of Authorization, and Disconnect Request packets, currently
sent to a NAS on port 3799 [RFC3576].
We do no more than mention the possibility here. Any definition of
Status-Client is outside of the scope of this document.
6. Table of Attributes
The following tables provide a guide to which attributes may be found
in which kinds of packets, and in what quantity.
Status-Server # Attribute
0-1 4 NAS-IP-Address
DeKok, Alan Informational [Page 15]
INTERNET-DRAFT Status-Server Practices 6 February 2007
0 18 Reply-Message
0-1 32 NAS-Identifier
1 80 Message-Authenticator
0-1 95 NAS-IPv6-Address
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT 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.
7. IANA Considerations
This specification does not create any new registries, nor does it
require assignment of any protocol parameters.
8. Security Considerations
This document defines the Status-Server packet as being similar in
treatment to the Access-Request packet, and is therefore subject to
the same security considerations as described in [RFC2865], Section
8. Status-Server packets also use the Message-Authenticator
attribute, and are therefore subject to the same security
considerations as [RFC3579], Section 4.
Where this document differs from the above specifications is that it
defines a new request/response method in RADIUS; the Status-Server
"ping". As this use is based on previously described and implemented
standards, we know of no additional security considerations that
arise from the use of Status-Server as described herein.
9. References
9.1. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., Aboba, B.,
"Dynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)", RFC 3576, July 2003.
DeKok, Alan Informational [Page 16]
INTERNET-DRAFT Status-Server Practices 6 February 2007
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670,
August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671,
August 2006.
9.2. Normative references
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[RFC3579] Abova, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
Acknowledgments
Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3.
Authors' Addresses
Alan DeKok
The FreeRADIUS Server Project
http://freeradius.org
Email: aland@freeradius.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
DeKok, Alan Informational [Page 17]
INTERNET-DRAFT Status-Server Practices 6 February 2007
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
DeKok, Alan Informational [Page 18]
INTERNET-DRAFT Status-Server Practices 6 February 2007
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
DeKok, Alan Informational [Page 19]