Network Working Group M. Chiba
Request for Comments: 3576 G. Dommety
Category: Informational M. Eklund
Cisco Systems, Inc.
D. Mitton
Circular Logic, UnLtd.
B. Aboba
Microsoft Corporation
July 2003
Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products. This includes support for disconnecting users and
changing authorizations applicable to a user session.
Chiba, et al. Informational [Page 1]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
Chiba, et al. Informational [Page 2]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1. Introduction
The RADIUS protocol, defined in [RFC2865], does not support
unsolicited messages sent from the RADIUS server to the Network
Access Server (NAS).
However, there are many instances in which it is desirable for
changes to be made to session characteristics, without requiring the
NAS to initiate the exchange. For example, it may be desirable for
administrators to be able to terminate a user session in progress.
Alternatively, if the user changes authorization level, this may
require that authorization attributes be added/deleted from a user
session.
To overcome these limitations, several vendors have implemented
additional RADIUS commands in order to be able to support unsolicited
messages sent from the RADIUS server to the NAS. These extended
commands provide support for Disconnect and Change-of-Authorization
(CoA) messages. Disconnect messages cause a user session to be
terminated immediately, whereas CoA messages modify session
authorization attributes such as data filters.
1.1. Applicability
This protocol is being recommended for publication as an
Informational RFC rather than as a standards-track RFC because of
problems that cannot be fixed without creating incompatibilities with
deployed implementations. This includes security vulnerabilities, as
well as semantic ambiguities resulting from the design of the
Change-of-Authorization (CoA) commands. While fixes are recommended,
they cannot be made mandatory since this would be incompatible with
existing implementations.
Existing implementations of this protocol do not support
authorization checks, so that an ISP sharing a NAS with another ISP
could disconnect or change authorizations for another ISP's users.
In order to remedy this problem, a "Reverse Path Forwarding" check is
recommended. See Section 5.1. for details.
Existing implementations utilize per-packet authentication and
integrity protection algorithms with known weaknesses [MD5Attack].
To provide stronger per-packet authentication and integrity
protection, the use of IPsec is recommended. See Section 5.3. for
details.
Chiba, et al. Informational [Page 3]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Existing implementations lack replay protection. In order to support
replay detection, it is recommended that the Event-Timestamp
Attribute be added to all messages in situations where IPsec replay
protection is not employed. Implementations should be configurable
to silently discard messages lacking the Event-Timestamp Attribute.
See Section 5.4. for details.
The approach taken with CoA commands in existing implementations
results in a semantic ambiguity. Existing implementations of the
CoA-Request identify the affected session, as well as supply the
authorization changes. Since RADIUS Attributes included within
existing implementations of the CoA-Request can be used for session
identification or authorization change, it may not be clear which
function a given attribute is serving.
The problem does not exist within [Diameter], in which authorization
change is requested by a command using Attribute Value Pairs (AVPs)
solely for identification, resulting in initiation of a standard
Request/Response sequence where authorization changes are supplied.
As a result, in no command can Diameter AVPs have multiple potential
meanings.
Due to differences in handling change-of-authorization requests in
RADIUS and Diameter, it may be difficult or impossible for a
Diameter/RADIUS gateway to successfully translate existing
implementations of this specification to equivalent messages in
Diameter. For example, a Diameter command changing any attribute
used for identification within existing CoA-Request implementations
cannot be translated, since such an authorization change is
impossible to carry out in existing implementations. Similarly,
translation between existing implementations of Disconnect-Request or
CoA-Request messages and Diameter is tricky because a Disconnect-
Request or CoA-Request message will need to be translated to multiple
Diameter commands.
To simplify translation between RADIUS and Diameter, a Service-Type
Attribute with value "Authorize Only" can (optionally) be included
within a Disconnect-Request or CoA-Request. Such a Request contains
only identification attributes. A NAS supporting the "Authorize
Only" Service-Type within a Disconnect-Request or CoA-Request
responds with a NAK containing a Service-Type Attribute with value
"Authorize Only" and an Error-Cause Attribute with value "Request
Initiated". The NAS will then send an Access-Request containing a
Service-Type Attribute with a value of "Authorize Only". This usage
sequence is akin to what occurs in Diameter and so is more easily
translated by a Diameter/RADIUS gateway.
Chiba, et al. Informational [Page 4]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1.2. Requirements Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
1.3. Terminology
This document frequently uses the following terms:
Network Access Server (NAS): The device providing access to the
network.
service: The NAS provides a service to the user,
such as IEEE 802 or PPP.
session: Each service provided by the NAS to a
user constitutes a session, with the
beginning of the session defined as the
point where service is first provided
and the end of the session defined as
the point where service is ended. A
user may have multiple sessions in
parallel or series if the NAS supports
that.
silently discard: This means the implementation discards
the packet without further 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.
2. Overview
This section describes the most commonly implemented features of
Disconnect and Change-of-Authorization messages.
2.1. Disconnect Messages (DM)
A Disconnect-Request packet is sent by the RADIUS server in order to
terminate a user session on a NAS and discard all associated session
context. The Disconnect-Request packet is sent to UDP port 3799, and
identifies the NAS as well as the user session to be terminated by
inclusion of the identification attributes described in Section 3.
Chiba, et al. Informational [Page 5]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+----------+ Disconnect-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a RADIUS
server with a Disconnect-ACK if all associated session context is
discarded and the user session is no longer connected, or a
Disconnect-NAK, if the NAS was unable to disconnect the session and
discard all associated session context. A NAS MUST respond to a
Disconnect-Request including a Service-Type Attribute with value
"Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be
sent. A NAS MUST respond to a Disconnect-Request including a
Service-Type Attribute with an unsupported value with a Disconnect-
NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be
included. A Disconnect-ACK MAY contain the Attribute
Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for
Admin-Reset.
2.2. Change-of-Authorization Messages (CoA)
CoA-Request packets contain information for dynamically changing
session authorizations. This is typically used to change data
filters. The data filters can be of either the ingress or egress
kind, and are sent in addition to the identification attributes as
described in section 3. The port used, and packet format (described
in Section 2.3.), are the same as that for Disconnect-Request
Messages.
The following attribute MAY be sent in a CoA-Request:
Filter-ID (11) - Indicates the name of a data filter list to be
applied for the session that the identification
attributes map to.
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a RADIUS server with a
CoA-ACK if the NAS is able to successfully change the authorizations
for the user session, or a CoA-NAK if the Request is unsuccessful. A
NAS MUST respond to a CoA-Request including a Service-Type Attribute
Chiba, et al. Informational [Page 6]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be
sent. A NAS MUST respond to a CoA-Request including a Service-Type
Attribute with an unsupported value with a CoA-NAK; an Error-Cause
Attribute with value "Unsupported Service" MAY be included.
2.3. Packet Format
For either Disconnect-Request or CoA-Request messages UDP port 3799
is used as the destination port. For responses, the source and
destination ports are reversed. Exactly one RADIUS packet is
encapsulated in the UDP Data field.
A summary of the data format is shown below. The fields are
transmitted from left to right.
The packet format consists of the fields: Code, Identifier, Length,
Authenticator, and Attributes in Type:Length:Value (TLV) format. All
fields hold the same meaning as those described in RADIUS [RFC2865].
The Authenticator field MUST be calculated in the same way as is
specified for an Accounting-Request in [RFC2866].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
The Code field is one octet, and identifies the type of RADIUS
packet. Packets received with an invalid Code field MUST be
silently discarded. RADIUS codes (decimal) for this extension are
assigned as follows:
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
Chiba, et al. Informational [Page 7]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Identifier
The Identifier field is one octet, and aids in matching requests
and replies. The RADIUS client can detect a duplicate request if
it has the same server source IP address and source UDP port and
Identifier within a short span of time.
Unlike RADIUS as defined in [RFC2865], the responsibility for
retransmission of Disconnect-Request and CoA-Request messages lies
with the RADIUS server. If after sending these messages, the
RADIUS server does not receive a response, it will retransmit.
The Identifier field MUST be changed whenever the content of the
Attributes field changes, or whenever a valid reply has been
received for a previous request. For retransmissions where the
contents are identical, the Identifier MUST remain unchanged.
If the RADIUS server is retransmitting a Disconnect-Request or
CoA-Request to the same client as before, and the Attributes have
not changed, the same Request Authenticator, Identifier and source
port MUST be used. If any Attributes have changed, a new
Authenticator and Identifier MUST be used.
Note that if the Event-Timestamp Attribute is included, it will be
updated when the packet is retransmitted, changing the content of
the Attributes field and requiring a new Identifier and Request
Authenticator.
If the Request to a primary proxy fails, a secondary proxy must be
queried, if available. Issues relating to failover algorithms are
described in [AAATransport]. Since this represents a new request,
a new Request Authenticator and Identifier MUST be used. However,
where the RADIUS server is sending directly to the client,
failover typically does not make sense, since Disconnect or CoA
messages need to be delivered to the NAS where the session
resides.
Length
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field
MUST be treated as padding and ignored on reception. If the
packet is shorter than the Length field indicates, it MUST be
silently discarded. The minimum length is 20 and the maximum
length is 4096.
Chiba, et al. Informational [Page 8]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Authenticator
The Authenticator field is sixteen (16) octets. The most
significant octet is transmitted first. This value is used to
authenticate the messages between the RADIUS server and client.
Request Authenticator
In Request packets, the Authenticator value is a 16 octet MD5
[RFC1321] checksum, called the Request Authenticator. The Request
Authenticator is calculated the same way as for an Accounting-
Request, specified in [RFC2866].
Note that the Request Authenticator of a Disconnect or CoA-Request
cannot be done the same way as the Request Authenticator of a
RADIUS Access-Request, because there is no User-Password Attribute
in a Disconnect-Request or CoA-Request.
Response Authenticator
The Authenticator field in a Response packet (e.g. Disconnect-ACK,
Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
Authenticator, and contains a one-way MD5 hash calculated over a
stream of octets consisting of the Code, Identifier, Length, the
Request Authenticator field from the packet being replied to, and
the response Attributes if any, followed by the shared secret.
The resulting 16 octet MD5 hash value is stored in the
Authenticator field of the Response packet.
Administrative note: As noted in [RFC2865] Section 3, the secret
(password shared between the client and the RADIUS server) SHOULD be
at least as large and unguessable as a well-chosen password. RADIUS
clients MUST use the source IP address of the RADIUS UDP packet to
decide which shared secret to use, so that requests can be proxied.
Attributes
In Disconnect and CoA-Request messages, all Attributes are treated
as mandatory. A NAS MUST respond to a CoA-Request containing one
or more unsupported Attributes or Attribute values with a CoA-NAK;
a Disconnect-Request containing one or more unsupported Attributes
or Attribute values MUST be answered with a Disconnect-NAK. State
changes resulting from a CoA-Request MUST be atomic: if the
Request is successful, a CoA-ACK is sent, and all requested
authorization changes MUST be made. If the CoA-Request is
unsuccessful, a CoA-NAK MUST be sent, and the requested
Chiba, et al. Informational [Page 9]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
authorization changes MUST NOT be made. Similarly, a state change
MUST NOT occur as a result of an unsuccessful Disconnect-Request;
here a Disconnect-NAK MUST be sent.
Since within this specification attributes may be used for
identification, authorization or other purposes, even if a NAS
implements an attribute for use with RADIUS authentication and
accounting, it may not support inclusion of that attribute within
Disconnect-Request or CoA-Request messages, given the difference
in attribute semantics. This is true even for attributes
specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
allowable within Access-Accept messages.
As a result, attributes beyond those specified in Section 3.2.
SHOULD NOT be included within Disconnect or CoA messages since
this could produce unpredictable results.
When using a forwarding proxy, the proxy must be able to alter the
packet as it passes through in each direction. When the proxy
forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
Attribute, and when the proxy forwards a response, it MUST remove
its Proxy-State Attribute if it added one. Proxy-State is always
added or removed after any other Proxy-States, but no other
assumptions regarding its location within the list of Attributes
can be made. Since Disconnect and CoA responses are authenticated
on the entire packet contents, the stripping of the Proxy-State
Attribute invalidates the integrity check - so the proxy needs to
recompute it. A forwarding proxy MUST NOT modify existing Proxy-
State, State, or Class Attributes present in the packet.
If there are any Proxy-State Attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy MUST
include those Proxy-State Attributes in its response to the
server. The forwarding proxy MAY include the Proxy-State
Attributes in the Disconnect-Request or CoA-Request when it
forwards the request, or it MAY omit them in the forwarded
request. If the forwarding proxy omits the Proxy-State Attributes
in the request, it MUST attach them to the response before sending
it to the server.
Chiba, et al. Informational [Page 10]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
3. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as a user session on the
NAS. All NAS identification attributes included in a Request message
MUST match in order for a Disconnect-Request or CoA-Request to be
successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
For session identification attributes, the User-Name and Acct-
Session-Id Attributes, if included, MUST match in order for a
Disconnect-Request or CoA-Request to be successful; other session
identification attributes SHOULD match. Where a mismatch of session
identification attributes is detected, a Disconnect-NAK or CoA-NAK
SHOULD be sent. The ability to use NAS or session identification
attributes to map to unique/multiple sessions is beyond the scope of
this document. Identification attributes include NAS and session
identification attributes, as described below.
NAS identification attributes
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Chiba, et al. Informational [Page 11]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.
To address security concerns described in Section 5.1., the User-Name
Attribute SHOULD be present in Disconnect-Request or CoA-Request
packets; one or more additional session identification attributes MAY
also be present. To address security concerns described in Section
5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address
Attributes SHOULD be present in Disconnect-Request or CoA-Request
packets; the NAS-Identifier Attribute MAY be present in addition.
If one or more authorization changes specified in a CoA-Request
cannot be carried out, or if one or more attributes or attribute-
values is unsupported, a CoA-NAK MUST be sent. Similarly, if there
are one or more unsupported attributes or attribute values in a
Disconnect-Request, a Disconnect-NAK MUST be sent.
Chiba, et al. Informational [Page 12]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Where a Service-Type Attribute with value "Authorize Only" is
included within a CoA-Request or Disconnect-Request, attributes
representing an authorization change MUST NOT be included; only
identification attributes are permitted. If attributes other than
NAS or session identification attributes are included in such a CoA-
Request, implementations MUST send a CoA-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included.
Similarly, if attributes other than NAS or session identification
attributes are included in such a Disconnect-Request, implementations
MUST send a Disconnect-NAK; an Error-Cause Attribute with value
"Unsupported Attribute" MAY be included.
3.1. Error-Cause
Description
It is possible that the NAS cannot honor Disconnect-Request or
CoA-Request messages for some reason. The Error-Cause Attribute
provides more detail on the cause of the problem. It MAY be
included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
messages.
A summary of the Error-Cause Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
101 for Error-Cause
Length
6
Value
The Value field is four octets, containing an integer specifying
the cause of the error. Values 0-199 and 300-399 are reserved.
Values 200-299 represent successful completion, so that these
values may only be sent within Disconnect-ACK or CoA-ACK message
and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
Chiba, et al. Informational [Page 13]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
400-499 represent fatal errors committed by the RADIUS server, so
that they MAY be sent within CoA-NAK or Disconnect-NAK messages,
and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages.
Values 500-599 represent fatal errors occurring on a NAS or RADIUS
proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK
messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK
messages. Error-Cause values SHOULD be logged by the RADIUS
server. Error-Code values (expressed in decimal) include:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
"Residual Session Context Removed" is sent in response to a
Disconnect-Request if the user session is no longer active, but
residual session context was found and successfully removed. This
value is only sent within a Disconnect-ACK and MUST NOT be sent
within a CoA-ACK, Disconnect-NAK or CoA-NAK.
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be
sent by implementations of this specification.
"Unsupported Attribute" is a fatal error sent if a Request contains
an attribute (such as a Vendor-Specific or EAP-Message Attribute)
that is not supported.
"Missing Attribute" is a fatal error sent if critical attributes
(such as NAS or session identification attributes) are missing from a
Request.
"NAS Identification Mismatch" is a fatal error sent if one or more
NAS identification attributes (see Section 3.) do not match the
identity of the NAS receiving the Request.
Chiba, et al. Informational [Page 14]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
"Invalid Request" is a fatal error sent if some other aspect of the
Request is invalid, such as if one or more attributes (such as EAP-
Message Attribute(s)) are not formatted properly.
"Unsupported Service" is a fatal error sent if a Service-Type
Attribute included with the Request is sent with an invalid or
unsupported value.
"Unsupported Extension" is a fatal error sent due to lack of support
for an extension such as Disconnect and/or CoA messages. This will
typically be sent by a proxy receiving an ICMP port unreachable
message after attempting to forward a Request to the NAS.
"Administratively Prohibited" is a fatal error sent if the NAS is
configured to prohibit honoring of Request messages for the specified
session.
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS
proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS
proxy was unable to determine how to route the Request to the NAS.
For example, this can occur if the required entries are not present
in the proxy's realm routing table.
"Session Context Not Found" is a fatal error sent if the session
context identified in the Request does not exist on the NAS.
"Session Context Not Removable" is a fatal error sent in response to
a Disconnect-Request if the NAS was able to locate the session
context, but could not remove it for some reason. It MUST NOT be
sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a
Disconnect-NAK.
"Other Proxy Processing Error" is a fatal error sent in response to a
Request that could not be processed by a proxy, for reasons other
than routing.
"Resources Unavailable" is a fatal error sent when a Request could
not be honored due to lack of available NAS resources (memory, non-
volatile storage, etc.).
"Request Initiated" is a fatal error sent in response to a Request
including a Service-Type Attribute with a value of "Authorize Only".
It indicates that the Disconnect-Request or CoA-Request has not been
honored, but that a RADIUS Access-Request including a Service-Type
Attribute with value "Authorize Only" is being sent to the RADIUS
server.
Chiba, et al. Informational [Page 15]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
3.2. Table of Attributes
The following table provides a guide to which attributes may be found
in which packets, and in what quantity.
Change-of-Authorization Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 7 Framed-Protocol [Note 3]
0-1 0 0 8 Framed-IP-Address [Note 1]
0-1 0 0 9 Framed-IP-Netmask [Note 3]
0-1 0 0 10 Framed-Routing [Note 3]
0+ 0 0 11 Filter-ID [Note 3]
0-1 0 0 12 Framed-MTU [Note 3]
0+ 0 0 13 Framed-Compression [Note 3]
0+ 0 0 14 Login-IP-Host [Note 3]
0-1 0 0 15 Login-Service [Note 3]
0-1 0 0 16 Login-TCP-Port [Note 3]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0 0 19 Callback-Number [Note 3]
0-1 0 0 20 Callback-Id [Note 3]
0+ 0 0 22 Framed-Route [Note 3]
0-1 0 0 23 Framed-IPX-Network [Note 3]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 3]
0+ 0 0 26 Vendor-Specific [Note 3]
0-1 0 0 27 Session-Timeout [Note 3]
0-1 0 0 28 Idle-Timeout [Note 3]
0-1 0 0 29 Termination-Action [Note 3]
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service [Note 3]
0-1 0 0 35 Login-LAT-Node [Note 3]
0-1 0 0 36 Login-LAT-Group [Note 3]
0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
Request ACK NAK # Attribute
Chiba, et al. Informational [Page 16]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Request ACK NAK # Attribute
0-1 0 0 62 Port-Limit [Note 3]
0-1 0 0 63 Login-LAT-Port [Note 3]
0+ 0 0 64 Tunnel-Type [Note 5]
0+ 0 0 65 Tunnel-Medium-Type [Note 5]
0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
0+ 0 0 69 Tunnel-Password [Note 5]
0-1 0 0 71 ARAP-Features [Note 3]
0-1 0 0 72 ARAP-Zone-Access [Note 3]
0+ 0 0 78 Configuration-Token [Note 3]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
0+ 0 0 83 Tunnel-Preference [Note 5]
0-1 0 0 85 Acct-Interim-Interval [Note 3]
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 88 Framed-Pool [Note 3]
0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0+ 0 0 98 Login-IPv6-Host [Note 3]
0+ 0 0 99 Framed-IPv6-Route [Note 3]
0-1 0 0 100 Framed-IPv6-Pool [Note 3]
0 0 0+ 101 Error-Cause
Request ACK NAK # Attribute
Disconnect Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 8 Framed-IP-Address [Note 1]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 4]
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
Request ACK NAK # Attribute
Chiba, et al. Informational [Page 17]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Request ACK NAK # Attribute
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0 0+ 0+ 101 Error-Cause
Request ACK NAK # Attribute
[Note 1] Where NAS or session identification attributes are included
in Disconnect-Request or CoA-Request messages, they are used for
identification purposes only. These attributes MUST NOT be used for
purposes other than identification (e.g. within CoA-Request messages
to request authorization changes).
[Note 2] The Reply-Message Attribute is used to present a displayable
message to the user. The message is only displayed as a result of a
successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
or CoA-ACK is subsequently sent). Where EAP is used for
authentication, an EAP-Message/Notification-Request Attribute is sent
instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-
Message/Notification-Response Attribute.
[Note 3] When included within a CoA-Request, these attributes
represent an authorization change request. When one of these
attributes is omitted from a CoA-Request, the NAS assumes that the
attribute value is to remain unchanged. Attributes included in a
CoA-Request replace all existing value(s) of the same attribute(s).
[Note 4] When included within a successful Disconnect-Request (where
a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
sent unmodified by the client to the accounting server in the
Accounting Stop packet. If the Disconnect-Request is unsuccessful,
then the Class Attribute is not processed.
[Note 5] When included within a CoA-Request, these attributes
represent an authorization change request. Where tunnel attribute(s)
are sent within a successful CoA-Request, all existing tunnel
attributes are removed and replaced by the new attribute(s).
Chiba, et al. Informational [Page 18]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
[Note 6] When included within a Disconnect-Request or CoA-Request, a
Service-Type Attribute with value "Authorize Only" indicates that the
Request only contains NAS and session identification attributes, and
that the NAS should attempt reauthorization by sending an Access-
Request with a Service-Type Attribute with value "Authorize Only".
This enables a usage model akin to that supported in Diameter, thus
easing translation between the two protocols. Support for the
Service-Type Attribute is optional within CoA-Request and
Disconnect-Request messages; where it is not included, the Request
message may contain both identification and authorization attributes.
A NAS that does not support the Service-Type Attribute with the value
"Authorize Only" within a Disconnect-Request MUST respond with a
Disconnect-NAK including no Service-Type Attribute; an Error-Cause
Attribute with value "Unsupported Service" MAY be included. A NAS
that does not support the Service-Type Attribute with the value
"Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
including no Service-Type Attribute; an Error-Cause Attribute with
value "Unsupported Service" MAY be included.
A NAS supporting the "Authorize Only" Service-Type value within
Disconnect-Request or CoA-Request messages MUST respond with a
Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
Attribute with value "Authorize Only", and an Error-Cause Attribute
with value "Request Initiated". The NAS then sends an Access-Request
to the RADIUS server with a Service-Type Attribute with value
"Authorize Only". This Access-Request SHOULD contain the NAS
attributes from the Disconnect or CoA-Request, as well as the session
attributes from the Request legal for inclusion in an Access-Request
as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As
noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
SHOULD be included in an Access-Request that does not contain a
User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.
The RADIUS server should send back an Access-Accept to (re-)authorize
the session or an Access-Reject to refuse to (re-)authorize it.
[Note 7] The State Attribute is available to be sent by the RADIUS
server to the NAS in a Disconnect-Request or CoA-Request message and
MUST be sent unmodified from the NAS to the RADIUS server in a
subsequent ACK or NAK message. If a Service-Type Attribute with
value "Authorize Only" is included in a Disconnect-Request or CoA-
Request along with a State Attribute, then the State Attribute MUST
be sent unmodified from the NAS to the RADIUS server in the resulting
Access-Request sent to the RADIUS server, if any. The State
Attribute is also available to be sent by the RADIUS server to the
NAS in a CoA-Request that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the client performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
Chiba, et al. Informational [Page 19]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Attribute unchanged in that Access-Request. In either usage, the
client MUST NOT interpret the Attribute locally. A Disconnect-
Request or CoA-Request packet must have only zero or one State
Attribute. Usage of the State Attribute is implementation dependent.
If the RADIUS server does not recognize the State Attribute in the
Access-Request, then it MUST send an Access-Reject.
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT 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.
1 Exactly one instance of this attribute MUST be present in packet.
4. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see
. There are six
updates for the section: RADIUS Packet Type Codes. These Packet
Types are allocated in [RADIANA]:
40 - Disconnect-Request
41 - Disconnect-ACK
42 - Disconnect-NAK
43 - CoA-Request
44 - CoA-ACK
45 - CoA-NAK
Allocation of a new Service-Type value for "Authorize Only" is
requested. This document also uses the UDP [RFC768] namespace, see
. The authors request
a port assignment from the Registered ports range. Finally, this
specification allocates the Error-Cause Attribute (101) with the
following decimal values:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
Chiba, et al. Informational [Page 20]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
5. Security Considerations
5.1. Authorization Issues
Where a NAS is shared by multiple providers, it is undesirable for
one provider to be able to send Disconnect-Request or CoA-Requests
affecting the sessions of another provider.
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or
CoA-Request messages from untrusted sources. By default, a RADIUS
proxy SHOULD perform a "reverse path forwarding" (RPF) check to
verify that a Disconnect-Request or CoA-Request originates from an
authorized RADIUS server. In addition, it SHOULD be possible to
explicitly authorize additional sources of Disconnect-Request or
CoA-Request packets relating to certain classes of sessions. For
example, a particular source can be explicitly authorized to send
CoA-Request messages relating to users within a set of realms.
To perform the RPF check, the proxy uses the session identification
attributes included in Disconnect-Request or CoA-Request messages, in
order to determine the RADIUS server(s) to which an equivalent
Access-Request could be routed. If the source address of the
Disconnect-Request or CoA-Request is within this set, then the
Request is forwarded; otherwise it MUST be silently discarded.
Typically the proxy will extract the realm from the Network Access
Identifier [RFC2486] included within the User-Name Attribute, and
determine the corresponding RADIUS servers in the proxy routing
tables. The RADIUS servers for that realm are then compared against
the source address of the packet. Where no RADIUS proxy is present,
the RPF check will need to be performed by the NAS itself.
Since authorization to send a Disconnect-Request or CoA-Request is
determined based on the source address and the corresponding shared
secret, the NASes or proxies SHOULD configure a different shared
secret for each RADIUS server.
Chiba, et al. Informational [Page 21]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
5.2. Impersonation
[RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS UDP
packet to decide which shared secret to use, so that RADIUS
requests can be proxied.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address Attributes will typically not match the source
address observed by the RADIUS server. Since the NAS-Identifier
Attribute need not contain an FQDN, this attribute may not be
resolvable to the source address observed by the RADIUS server, even
when no proxy is present.
As a result, the authenticity check performed by a RADIUS server or
proxy does not verify the correctness of NAS identification
attributes. This makes it possible for a rogue NAS to forge NAS-IP-
Address, NAS-IPv6-Address or NAS-Identifier Attributes within a
RADIUS Access-Request in order to impersonate another NAS. It is
also possible for a rogue NAS to forge session identification
attributes such as the Called-Station-Id, Calling-Station-Id, or
Originating-Line-Info [NASREQ]. This could fool the RADIUS server
into sending Disconnect-Request or CoA-Request messages containing
forged session identification attributes to a NAS targeted by an
attacker.
To address these vulnerabilities RADIUS proxies SHOULD check whether
NAS identification attributes (see Section 3.) match the source
address of packets originating from the NAS. Where one or more
attributes do not match, Disconnect-Request or CoA-Request messages
SHOULD be silently discarded.
Such a check may not always be possible. Since the NAS-Identifier
Attribute need not correspond to an FQDN, it may not be resolvable to
an IP address to be matched against the source address. Also, where
a NAT exists between the RADIUS client and proxy, checking the NAS-
IP-Address or NAS-IPv6-Address Attributes may not be feasible.
5.3. IPsec Usage Guidelines
In addition to security vulnerabilities unique to Disconnect or CoA
messages, the protocol exchanges described in this document are
susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is
RECOMMENDED that IPsec be employed to afford better security.
Chiba, et al. Informational [Page 22]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management. IPsec ESP [RFC2406]
with a non-null transform SHOULD be supported, and IPsec ESP with a
non-null encryption transform and authentication support SHOULD be
used to provide per-packet confidentiality, authentication, integrity
and replay protection. IKE SHOULD be used for key management.
Within RADIUS [RFC2865], a shared secret is used for hiding
Attributes such as User-Password, as well as used in computation of
the Response Authenticator. In RADIUS accounting [RFC2866], the
shared secret is used in computation of both the Request
Authenticator and the Response Authenticator.
Since in RADIUS a shared secret is used to provide confidentiality as
well as integrity protection and authentication, only use of IPsec
ESP with a non-null transform can provide security services
sufficient to substitute for RADIUS application-layer security.
Therefore, where IPsec AH or ESP null is used, it will typically
still be necessary to configure a RADIUS shared secret.
Where RADIUS is run over IPsec ESP with a non-null transform, the
secret shared between the NAS and the RADIUS server MAY NOT be
configured. In this case, a shared secret of zero length MUST be
assumed. However, a RADIUS server that cannot know whether incoming
traffic is IPsec-protected MUST be configured with a non-null RADIUS
shared secret.
When IPsec ESP is used with RADIUS, per-packet authentication,
integrity and replay protection MUST be used. 3DES-CBC MUST be
supported as an encryption transform and AES-CBC SHOULD be supported.
AES-CBC SHOULD be offered as a preferred encryption transform if
supported. HMAC-SHA1-96 MUST be supported as an authentication
transform. DES-CBC SHOULD NOT be used as the encryption transform.
A typical IPsec policy for an IPsec-capable RADIUS client is
"Initiate IPsec, from me to any destination port UDP 1812". This
IPsec policy causes an IPsec SA to be set up by the RADIUS client
prior to sending RADIUS traffic. If some RADIUS servers contacted by
the client do not support IPsec, then a more granular policy will be
required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server,
destination port UDP 1812."
For a client implementing this specification, the policy would be
"Accept IPsec, from any to me, destination port UDP 3799". This
causes the RADIUS client to accept (but not require) use of IPsec.
It may not be appropriate to require IPsec for all RADIUS servers
connecting to an IPsec-enabled RADIUS client, since some RADIUS
servers may not support IPsec.
Chiba, et al. Informational [Page 23]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
IPsec, from any to me, destination port 1812". This causes the
RADIUS server to accept (but not require) use of IPsec. It may not
be appropriate to require IPsec for all RADIUS clients connecting to
an IPsec-enabled RADIUS server, since some RADIUS clients may not
support IPsec.
For servers implementing this specification, the policy would be
"Initiate IPsec, from me to any, destination port UDP 3799". This
causes the RADIUS server to initiate IPsec when sending RADIUS
extension traffic to any RADIUS client. If some RADIUS clients
contacted by the server do not support IPsec, then a more granular
policy will be required, such as "Initiate IPsec, from me to IPsec-
capable-RADIUS-client, destination port UDP 3799".
Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that the RADIUS client and server perform
an authorization check. Before enabling a host to act as a RADIUS
client, the RADIUS server SHOULD check whether the host is authorized
to provide network access. Similarly, before enabling a host to act
as a RADIUS server, the RADIUS client SHOULD check whether the host
is authorized for that role.
RADIUS servers can be configured with the IP addresses (for IKE
Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS clients. Alternatively, if a separate
Certification Authority (CA) exists for RADIUS clients, then the
RADIUS server can configure this CA as a trust anchor [RFC3280] for
use with IPsec.
Similarly, RADIUS clients can be configured with the IP addresses
(for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
certificate authentication) of RADIUS servers. Alternatively, if a
separate CA exists for RADIUS servers, then the RADIUS client can
configure this CA as a trust anchor for use with IPsec.
Since unlike SSL/TLS, IKE does not permit certificate policies to be
set on a per-port basis, certificate policies need to apply to all
uses of IPsec on RADIUS clients and servers. In IPsec deployment
supporting only certificate authentication, a management station
initiating an IPsec-protected telnet session to the RADIUS server
would need to obtain a certificate chaining to the RADIUS client CA.
Issuing such a certificate might not be appropriate if the management
station was not authorized as a RADIUS client.
Where RADIUS clients may obtain their IP address dynamically (such as
an Access Point supporting DHCP), Main Mode with pre-shared keys
[RFC2409] SHOULD NOT be used, since this requires use of a group
Chiba, et al. Informational [Page 24]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
pre-shared key; instead, Aggressive Mode SHOULD be used. Where
RADIUS client addresses are statically assigned, either Aggressive
Mode or Main Mode MAY be used. With certificate authentication, Main
Mode SHOULD be used.
Care needs to be taken with IKE Phase 1 Identity Payload selection in
order to enable mapping of identities to pre-shared keys, even with
Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
Payloads are used and addresses are dynamically assigned, mapping of
identities to keys is not possible, so that group pre-shared keys are
still a practical necessity. As a result, the ID_FQDN identity
payload SHOULD be employed in situations where Aggressive mode is
utilized along with pre-shared keys and IP addresses are dynamically
assigned. This approach also has other advantages, since it allows
the RADIUS server and client to configure themselves based on the
fully qualified domain name of their peers.
Note that with IPsec, security services are negotiated at the
granularity of an IPsec SA, so that RADIUS exchanges requiring a set
of security services different from those negotiated with existing
IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs
are also advisable where quality of service considerations dictate
different handling RADIUS conversations. Attempting to apply
different quality of service to connections handled by the same IPsec
SA can result in reordering, and falling outside the replay window.
For a discussion of the issues, see [RFC2983].
5.4. Replay Protection
Where IPsec replay protection is not used, the Event-Timestamp (55)
Attribute [RFC2869] SHOULD be included within all messages. When
this attribute is present, both the NAS and the RADIUS server MUST
check that the Event-Timestamp Attribute is current within an
acceptable time window. If the Event-Timestamp Attribute is not
current, then the message MUST be silently discarded. This implies
the need for time synchronization within the network, which can be
achieved by a variety of means, including secure NTP, as described in
[NTPAUTH].
Both the NAS and the RADIUS server SHOULD be configurable to silently
discard messages lacking an Event-Timestamp Attribute. A default
time window of 300 seconds is recommended.
Chiba, et al. Informational [Page 25]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
6. Example Traces
Disconnect Request with User-Name:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
7. References
7.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Chiba, et al. Informational [Page 26]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July
2003.
7.2. Informative References
[RFC2882] Mitton, D., "Network Access Server Requirements:
Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
2983, October 2000.
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting (AAA) Transport Profile", RFC 3539,
June 2003.
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
Progress.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server
Application", Work in Progress.
Chiba, et al. Informational [Page 27]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network
Time Protocol", Work in Progress.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Acknowledgments
This protocol was first developed and distributed by Ascend
Communications. Example code was distributed in their free server
kit.
The authors would like to acknowledge the valuable suggestions and
feedback from the following people:
Avi Lior ,
Randy Bush ,
Steve Bellovin
Glen Zorn ,
Mark Jones ,
Claudio Lapidus ,
Anurag Batta ,
Kuntal Chowdhury , and
Tim Moore .
Russ Housley
Chiba, et al. Informational [Page 28]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
10. Authors' Addresses
Murtaza Chiba
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA, 95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845
EMail: david@mitton.com
Phone: +1 978 683 1814
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Chiba, et al. Informational [Page 29]
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chiba, et al. Informational [Page 30]
RFC, FYI, BCP