7 Network Working Group M. Chiba
8 Request for Comments: 3576 G. Dommety
9 Category: Informational M. Eklund
12 Circular Logic, UnLtd.
18 Dynamic Authorization Extensions to Remote
19 Authentication Dial In User Service (RADIUS)
23 This memo provides information for the Internet community. It does
24 not specify an Internet standard of any kind. Distribution of this
29 Copyright (C) The Internet Society (2003). All Rights Reserved.
33 This document describes a currently deployed extension to the Remote
34 Authentication Dial In User Service (RADIUS) protocol, allowing
35 dynamic changes to a user session, as implemented by network access
36 server products. This includes support for disconnecting users and
37 changing authorizations applicable to a user session.
58 Chiba, et al. Informational [Page 1]
60 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
67 1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
68 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
70 2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
71 2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
72 2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
73 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
74 3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
75 3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
76 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
77 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
78 5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
79 5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
80 5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
81 5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
82 6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
84 7.1. Normative References . . . . . . . . . . . . . . . . . . 26
85 7.2. Informative References . . . . . . . . . . . . . . . . . 27
86 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
87 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
88 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
89 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
114 Chiba, et al. Informational [Page 2]
116 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
121 The RADIUS protocol, defined in [RFC2865], does not support
122 unsolicited messages sent from the RADIUS server to the Network
125 However, there are many instances in which it is desirable for
126 changes to be made to session characteristics, without requiring the
127 NAS to initiate the exchange. For example, it may be desirable for
128 administrators to be able to terminate a user session in progress.
129 Alternatively, if the user changes authorization level, this may
130 require that authorization attributes be added/deleted from a user
133 To overcome these limitations, several vendors have implemented
134 additional RADIUS commands in order to be able to support unsolicited
135 messages sent from the RADIUS server to the NAS. These extended
136 commands provide support for Disconnect and Change-of-Authorization
137 (CoA) messages. Disconnect messages cause a user session to be
138 terminated immediately, whereas CoA messages modify session
139 authorization attributes such as data filters.
143 This protocol is being recommended for publication as an
144 Informational RFC rather than as a standards-track RFC because of
145 problems that cannot be fixed without creating incompatibilities with
146 deployed implementations. This includes security vulnerabilities, as
147 well as semantic ambiguities resulting from the design of the
148 Change-of-Authorization (CoA) commands. While fixes are recommended,
149 they cannot be made mandatory since this would be incompatible with
150 existing implementations.
152 Existing implementations of this protocol do not support
153 authorization checks, so that an ISP sharing a NAS with another ISP
154 could disconnect or change authorizations for another ISP's users.
155 In order to remedy this problem, a "Reverse Path Forwarding" check is
156 recommended. See Section 5.1. for details.
158 Existing implementations utilize per-packet authentication and
159 integrity protection algorithms with known weaknesses [MD5Attack].
160 To provide stronger per-packet authentication and integrity
161 protection, the use of IPsec is recommended. See Section 5.3. for
170 Chiba, et al. Informational [Page 3]
172 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
175 Existing implementations lack replay protection. In order to support
176 replay detection, it is recommended that the Event-Timestamp
177 Attribute be added to all messages in situations where IPsec replay
178 protection is not employed. Implementations should be configurable
179 to silently discard messages lacking the Event-Timestamp Attribute.
180 See Section 5.4. for details.
182 The approach taken with CoA commands in existing implementations
183 results in a semantic ambiguity. Existing implementations of the
184 CoA-Request identify the affected session, as well as supply the
185 authorization changes. Since RADIUS Attributes included within
186 existing implementations of the CoA-Request can be used for session
187 identification or authorization change, it may not be clear which
188 function a given attribute is serving.
190 The problem does not exist within [Diameter], in which authorization
191 change is requested by a command using Attribute Value Pairs (AVPs)
192 solely for identification, resulting in initiation of a standard
193 Request/Response sequence where authorization changes are supplied.
194 As a result, in no command can Diameter AVPs have multiple potential
197 Due to differences in handling change-of-authorization requests in
198 RADIUS and Diameter, it may be difficult or impossible for a
199 Diameter/RADIUS gateway to successfully translate existing
200 implementations of this specification to equivalent messages in
201 Diameter. For example, a Diameter command changing any attribute
202 used for identification within existing CoA-Request implementations
203 cannot be translated, since such an authorization change is
204 impossible to carry out in existing implementations. Similarly,
205 translation between existing implementations of Disconnect-Request or
206 CoA-Request messages and Diameter is tricky because a Disconnect-
207 Request or CoA-Request message will need to be translated to multiple
210 To simplify translation between RADIUS and Diameter, a Service-Type
211 Attribute with value "Authorize Only" can (optionally) be included
212 within a Disconnect-Request or CoA-Request. Such a Request contains
213 only identification attributes. A NAS supporting the "Authorize
214 Only" Service-Type within a Disconnect-Request or CoA-Request
215 responds with a NAK containing a Service-Type Attribute with value
216 "Authorize Only" and an Error-Cause Attribute with value "Request
217 Initiated". The NAS will then send an Access-Request containing a
218 Service-Type Attribute with a value of "Authorize Only". This usage
219 sequence is akin to what occurs in Diameter and so is more easily
220 translated by a Diameter/RADIUS gateway.
226 Chiba, et al. Informational [Page 4]
228 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
231 1.2. Requirements Language
233 In this document, several words are used to signify the requirements
234 of the specification. These words are often capitalized. The key
235 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
236 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
237 are to be interpreted as described in [RFC2119].
241 This document frequently uses the following terms:
243 Network Access Server (NAS): The device providing access to the
246 service: The NAS provides a service to the user,
247 such as IEEE 802 or PPP.
249 session: Each service provided by the NAS to a
250 user constitutes a session, with the
251 beginning of the session defined as the
252 point where service is first provided
253 and the end of the session defined as
254 the point where service is ended. A
255 user may have multiple sessions in
256 parallel or series if the NAS supports
259 silently discard: This means the implementation discards
260 the packet without further processing.
261 The implementation SHOULD provide the
262 capability of logging the error,
263 including the contents of the silently
264 discarded packet, and SHOULD record the
265 event in a statistics counter.
269 This section describes the most commonly implemented features of
270 Disconnect and Change-of-Authorization messages.
272 2.1. Disconnect Messages (DM)
274 A Disconnect-Request packet is sent by the RADIUS server in order to
275 terminate a user session on a NAS and discard all associated session
276 context. The Disconnect-Request packet is sent to UDP port 3799, and
277 identifies the NAS as well as the user session to be terminated by
278 inclusion of the identification attributes described in Section 3.
282 Chiba, et al. Informational [Page 5]
284 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
287 +----------+ Disconnect-Request +----------+
288 | | <-------------------- | |
290 | | Disconnect-Response | Server |
291 | | ---------------------> | |
292 +----------+ +----------+
294 The NAS responds to a Disconnect-Request packet sent by a RADIUS
295 server with a Disconnect-ACK if all associated session context is
296 discarded and the user session is no longer connected, or a
297 Disconnect-NAK, if the NAS was unable to disconnect the session and
298 discard all associated session context. A NAS MUST respond to a
299 Disconnect-Request including a Service-Type Attribute with value
300 "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be
301 sent. A NAS MUST respond to a Disconnect-Request including a
302 Service-Type Attribute with an unsupported value with a Disconnect-
303 NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be
304 included. A Disconnect-ACK MAY contain the Attribute
305 Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for
308 2.2. Change-of-Authorization Messages (CoA)
310 CoA-Request packets contain information for dynamically changing
311 session authorizations. This is typically used to change data
312 filters. The data filters can be of either the ingress or egress
313 kind, and are sent in addition to the identification attributes as
314 described in section 3. The port used, and packet format (described
315 in Section 2.3.), are the same as that for Disconnect-Request
318 The following attribute MAY be sent in a CoA-Request:
320 Filter-ID (11) - Indicates the name of a data filter list to be
321 applied for the session that the identification
324 +----------+ CoA-Request +----------+
325 | | <-------------------- | |
327 | | CoA-Response | Server |
328 | | ---------------------> | |
329 +----------+ +----------+
331 The NAS responds to a CoA-Request sent by a RADIUS server with a
332 CoA-ACK if the NAS is able to successfully change the authorizations
333 for the user session, or a CoA-NAK if the Request is unsuccessful. A
334 NAS MUST respond to a CoA-Request including a Service-Type Attribute
338 Chiba, et al. Informational [Page 6]
340 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
343 with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be
344 sent. A NAS MUST respond to a CoA-Request including a Service-Type
345 Attribute with an unsupported value with a CoA-NAK; an Error-Cause
346 Attribute with value "Unsupported Service" MAY be included.
350 For either Disconnect-Request or CoA-Request messages UDP port 3799
351 is used as the destination port. For responses, the source and
352 destination ports are reversed. Exactly one RADIUS packet is
353 encapsulated in the UDP Data field.
355 A summary of the data format is shown below. The fields are
356 transmitted from left to right.
358 The packet format consists of the fields: Code, Identifier, Length,
359 Authenticator, and Attributes in Type:Length:Value (TLV) format. All
360 fields hold the same meaning as those described in RADIUS [RFC2865].
361 The Authenticator field MUST be calculated in the same way as is
362 specified for an Accounting-Request in [RFC2866].
365 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
366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
367 | Code | Identifier | Length |
368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 +-+-+-+-+-+-+-+-+-+-+-+-+-
379 The Code field is one octet, and identifies the type of RADIUS
380 packet. Packets received with an invalid Code field MUST be
381 silently discarded. RADIUS codes (decimal) for this extension are
384 40 - Disconnect-Request [RFC2882]
385 41 - Disconnect-ACK [RFC2882]
386 42 - Disconnect-NAK [RFC2882]
387 43 - CoA-Request [RFC2882]
388 44 - CoA-ACK [RFC2882]
389 45 - CoA-NAK [RFC2882]
394 Chiba, et al. Informational [Page 7]
396 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
401 The Identifier field is one octet, and aids in matching requests
402 and replies. The RADIUS client can detect a duplicate request if
403 it has the same server source IP address and source UDP port and
404 Identifier within a short span of time.
406 Unlike RADIUS as defined in [RFC2865], the responsibility for
407 retransmission of Disconnect-Request and CoA-Request messages lies
408 with the RADIUS server. If after sending these messages, the
409 RADIUS server does not receive a response, it will retransmit.
411 The Identifier field MUST be changed whenever the content of the
412 Attributes field changes, or whenever a valid reply has been
413 received for a previous request. For retransmissions where the
414 contents are identical, the Identifier MUST remain unchanged.
416 If the RADIUS server is retransmitting a Disconnect-Request or
417 CoA-Request to the same client as before, and the Attributes have
418 not changed, the same Request Authenticator, Identifier and source
419 port MUST be used. If any Attributes have changed, a new
420 Authenticator and Identifier MUST be used.
422 Note that if the Event-Timestamp Attribute is included, it will be
423 updated when the packet is retransmitted, changing the content of
424 the Attributes field and requiring a new Identifier and Request
427 If the Request to a primary proxy fails, a secondary proxy must be
428 queried, if available. Issues relating to failover algorithms are
429 described in [AAATransport]. Since this represents a new request,
430 a new Request Authenticator and Identifier MUST be used. However,
431 where the RADIUS server is sending directly to the client,
432 failover typically does not make sense, since Disconnect or CoA
433 messages need to be delivered to the NAS where the session
438 The Length field is two octets. It indicates the length of the
439 packet including the Code, Identifier, Length, Authenticator and
440 Attribute fields. Octets outside the range of the Length field
441 MUST be treated as padding and ignored on reception. If the
442 packet is shorter than the Length field indicates, it MUST be
443 silently discarded. The minimum length is 20 and the maximum
450 Chiba, et al. Informational [Page 8]
452 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
457 The Authenticator field is sixteen (16) octets. The most
458 significant octet is transmitted first. This value is used to
459 authenticate the messages between the RADIUS server and client.
461 Request Authenticator
463 In Request packets, the Authenticator value is a 16 octet MD5
464 [RFC1321] checksum, called the Request Authenticator. The Request
465 Authenticator is calculated the same way as for an Accounting-
466 Request, specified in [RFC2866].
468 Note that the Request Authenticator of a Disconnect or CoA-Request
469 cannot be done the same way as the Request Authenticator of a
470 RADIUS Access-Request, because there is no User-Password Attribute
471 in a Disconnect-Request or CoA-Request.
473 Response Authenticator
475 The Authenticator field in a Response packet (e.g. Disconnect-ACK,
476 Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
477 Authenticator, and contains a one-way MD5 hash calculated over a
478 stream of octets consisting of the Code, Identifier, Length, the
479 Request Authenticator field from the packet being replied to, and
480 the response Attributes if any, followed by the shared secret.
481 The resulting 16 octet MD5 hash value is stored in the
482 Authenticator field of the Response packet.
484 Administrative note: As noted in [RFC2865] Section 3, the secret
485 (password shared between the client and the RADIUS server) SHOULD be
486 at least as large and unguessable as a well-chosen password. RADIUS
487 clients MUST use the source IP address of the RADIUS UDP packet to
488 decide which shared secret to use, so that requests can be proxied.
492 In Disconnect and CoA-Request messages, all Attributes are treated
493 as mandatory. A NAS MUST respond to a CoA-Request containing one
494 or more unsupported Attributes or Attribute values with a CoA-NAK;
495 a Disconnect-Request containing one or more unsupported Attributes
496 or Attribute values MUST be answered with a Disconnect-NAK. State
497 changes resulting from a CoA-Request MUST be atomic: if the
498 Request is successful, a CoA-ACK is sent, and all requested
499 authorization changes MUST be made. If the CoA-Request is
500 unsuccessful, a CoA-NAK MUST be sent, and the requested
506 Chiba, et al. Informational [Page 9]
508 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
511 authorization changes MUST NOT be made. Similarly, a state change
512 MUST NOT occur as a result of an unsuccessful Disconnect-Request;
513 here a Disconnect-NAK MUST be sent.
515 Since within this specification attributes may be used for
516 identification, authorization or other purposes, even if a NAS
517 implements an attribute for use with RADIUS authentication and
518 accounting, it may not support inclusion of that attribute within
519 Disconnect-Request or CoA-Request messages, given the difference
520 in attribute semantics. This is true even for attributes
521 specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
522 allowable within Access-Accept messages.
524 As a result, attributes beyond those specified in Section 3.2.
525 SHOULD NOT be included within Disconnect or CoA messages since
526 this could produce unpredictable results.
528 When using a forwarding proxy, the proxy must be able to alter the
529 packet as it passes through in each direction. When the proxy
530 forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
531 Attribute, and when the proxy forwards a response, it MUST remove
532 its Proxy-State Attribute if it added one. Proxy-State is always
533 added or removed after any other Proxy-States, but no other
534 assumptions regarding its location within the list of Attributes
535 can be made. Since Disconnect and CoA responses are authenticated
536 on the entire packet contents, the stripping of the Proxy-State
537 Attribute invalidates the integrity check - so the proxy needs to
538 recompute it. A forwarding proxy MUST NOT modify existing Proxy-
539 State, State, or Class Attributes present in the packet.
541 If there are any Proxy-State Attributes in a Disconnect-Request or
542 CoA-Request received from the server, the forwarding proxy MUST
543 include those Proxy-State Attributes in its response to the
544 server. The forwarding proxy MAY include the Proxy-State
545 Attributes in the Disconnect-Request or CoA-Request when it
546 forwards the request, or it MAY omit them in the forwarded
547 request. If the forwarding proxy omits the Proxy-State Attributes
548 in the request, it MUST attach them to the response before sending
562 Chiba, et al. Informational [Page 10]
564 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
569 In Disconnect-Request and CoA-Request packets, certain attributes are
570 used to uniquely identify the NAS as well as a user session on the
571 NAS. All NAS identification attributes included in a Request message
572 MUST match in order for a Disconnect-Request or CoA-Request to be
573 successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
574 For session identification attributes, the User-Name and Acct-
575 Session-Id Attributes, if included, MUST match in order for a
576 Disconnect-Request or CoA-Request to be successful; other session
577 identification attributes SHOULD match. Where a mismatch of session
578 identification attributes is detected, a Disconnect-NAK or CoA-NAK
579 SHOULD be sent. The ability to use NAS or session identification
580 attributes to map to unique/multiple sessions is beyond the scope of
581 this document. Identification attributes include NAS and session
582 identification attributes, as described below.
584 NAS identification attributes
586 Attribute # Reference Description
587 --------- --- --------- -----------
588 NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
589 NAS-Identifier 32 [RFC2865] String identifying the NAS.
590 NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
618 Chiba, et al. Informational [Page 11]
620 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
623 Session identification attributes
625 Attribute # Reference Description
626 --------- --- --------- -----------
627 User-Name 1 [RFC2865] The name of the user
628 associated with the session.
629 NAS-Port 5 [RFC2865] The port on which the
630 session is terminated.
631 Framed-IP-Address 8 [RFC2865] The IPv4 address associated
633 Called-Station-Id 30 [RFC2865] The link address to which
634 the session is connected.
635 Calling-Station-Id 31 [RFC2865] The link address from which
636 the session is connected.
637 Acct-Session-Id 44 [RFC2866] The identifier uniquely
638 identifying the session
640 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
641 identifying related sessions.
642 NAS-Port-Type 61 [RFC2865] The type of port used.
643 NAS-Port-Id 87 [RFC2869] String identifying the port
644 where the session is.
645 Originating-Line-Info 94 [NASREQ] Provides information on the
646 characteristics of the line
649 Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
650 associated with the session;
653 Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
654 with the session, always sent
655 with Framed-Interface-Id.
657 To address security concerns described in Section 5.1., the User-Name
658 Attribute SHOULD be present in Disconnect-Request or CoA-Request
659 packets; one or more additional session identification attributes MAY
660 also be present. To address security concerns described in Section
661 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address
662 Attributes SHOULD be present in Disconnect-Request or CoA-Request
663 packets; the NAS-Identifier Attribute MAY be present in addition.
665 If one or more authorization changes specified in a CoA-Request
666 cannot be carried out, or if one or more attributes or attribute-
667 values is unsupported, a CoA-NAK MUST be sent. Similarly, if there
668 are one or more unsupported attributes or attribute values in a
669 Disconnect-Request, a Disconnect-NAK MUST be sent.
674 Chiba, et al. Informational [Page 12]
676 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
679 Where a Service-Type Attribute with value "Authorize Only" is
680 included within a CoA-Request or Disconnect-Request, attributes
681 representing an authorization change MUST NOT be included; only
682 identification attributes are permitted. If attributes other than
683 NAS or session identification attributes are included in such a CoA-
684 Request, implementations MUST send a CoA-NAK; an Error-Cause
685 Attribute with value "Unsupported Attribute" MAY be included.
686 Similarly, if attributes other than NAS or session identification
687 attributes are included in such a Disconnect-Request, implementations
688 MUST send a Disconnect-NAK; an Error-Cause Attribute with value
689 "Unsupported Attribute" MAY be included.
695 It is possible that the NAS cannot honor Disconnect-Request or
696 CoA-Request messages for some reason. The Error-Cause Attribute
697 provides more detail on the cause of the problem. It MAY be
698 included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
701 A summary of the Error-Cause Attribute format is shown below. The
702 fields are transmitted from left to right.
705 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
706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
707 | Type | Length | Value
708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
722 The Value field is four octets, containing an integer specifying
723 the cause of the error. Values 0-199 and 300-399 are reserved.
724 Values 200-299 represent successful completion, so that these
725 values may only be sent within Disconnect-ACK or CoA-ACK message
726 and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
730 Chiba, et al. Informational [Page 13]
732 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
735 400-499 represent fatal errors committed by the RADIUS server, so
736 that they MAY be sent within CoA-NAK or Disconnect-NAK messages,
737 and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages.
738 Values 500-599 represent fatal errors occurring on a NAS or RADIUS
739 proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK
740 messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK
741 messages. Error-Cause values SHOULD be logged by the RADIUS
742 server. Error-Code values (expressed in decimal) include:
746 201 Residual Session Context Removed
747 202 Invalid EAP Packet (Ignored)
748 401 Unsupported Attribute
749 402 Missing Attribute
750 403 NAS Identification Mismatch
752 405 Unsupported Service
753 406 Unsupported Extension
754 501 Administratively Prohibited
755 502 Request Not Routable (Proxy)
756 503 Session Context Not Found
757 504 Session Context Not Removable
758 505 Other Proxy Processing Error
759 506 Resources Unavailable
760 507 Request Initiated
762 "Residual Session Context Removed" is sent in response to a
763 Disconnect-Request if the user session is no longer active, but
764 residual session context was found and successfully removed. This
765 value is only sent within a Disconnect-ACK and MUST NOT be sent
766 within a CoA-ACK, Disconnect-NAK or CoA-NAK.
768 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be
769 sent by implementations of this specification.
771 "Unsupported Attribute" is a fatal error sent if a Request contains
772 an attribute (such as a Vendor-Specific or EAP-Message Attribute)
773 that is not supported.
775 "Missing Attribute" is a fatal error sent if critical attributes
776 (such as NAS or session identification attributes) are missing from a
779 "NAS Identification Mismatch" is a fatal error sent if one or more
780 NAS identification attributes (see Section 3.) do not match the
781 identity of the NAS receiving the Request.
786 Chiba, et al. Informational [Page 14]
788 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
791 "Invalid Request" is a fatal error sent if some other aspect of the
792 Request is invalid, such as if one or more attributes (such as EAP-
793 Message Attribute(s)) are not formatted properly.
795 "Unsupported Service" is a fatal error sent if a Service-Type
796 Attribute included with the Request is sent with an invalid or
799 "Unsupported Extension" is a fatal error sent due to lack of support
800 for an extension such as Disconnect and/or CoA messages. This will
801 typically be sent by a proxy receiving an ICMP port unreachable
802 message after attempting to forward a Request to the NAS.
804 "Administratively Prohibited" is a fatal error sent if the NAS is
805 configured to prohibit honoring of Request messages for the specified
808 "Request Not Routable" is a fatal error which MAY be sent by a RADIUS
809 proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS
810 proxy was unable to determine how to route the Request to the NAS.
811 For example, this can occur if the required entries are not present
812 in the proxy's realm routing table.
814 "Session Context Not Found" is a fatal error sent if the session
815 context identified in the Request does not exist on the NAS.
817 "Session Context Not Removable" is a fatal error sent in response to
818 a Disconnect-Request if the NAS was able to locate the session
819 context, but could not remove it for some reason. It MUST NOT be
820 sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a
823 "Other Proxy Processing Error" is a fatal error sent in response to a
824 Request that could not be processed by a proxy, for reasons other
827 "Resources Unavailable" is a fatal error sent when a Request could
828 not be honored due to lack of available NAS resources (memory, non-
829 volatile storage, etc.).
831 "Request Initiated" is a fatal error sent in response to a Request
832 including a Service-Type Attribute with a value of "Authorize Only".
833 It indicates that the Disconnect-Request or CoA-Request has not been
834 honored, but that a RADIUS Access-Request including a Service-Type
835 Attribute with value "Authorize Only" is being sent to the RADIUS
842 Chiba, et al. Informational [Page 15]
844 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
847 3.2. Table of Attributes
849 The following table provides a guide to which attributes may be found
850 in which packets, and in what quantity.
852 Change-of-Authorization Messages
854 Request ACK NAK # Attribute
855 0-1 0 0 1 User-Name [Note 1]
856 0-1 0 0 4 NAS-IP-Address [Note 1]
857 0-1 0 0 5 NAS-Port [Note 1]
858 0-1 0 0-1 6 Service-Type [Note 6]
859 0-1 0 0 7 Framed-Protocol [Note 3]
860 0-1 0 0 8 Framed-IP-Address [Note 1]
861 0-1 0 0 9 Framed-IP-Netmask [Note 3]
862 0-1 0 0 10 Framed-Routing [Note 3]
863 0+ 0 0 11 Filter-ID [Note 3]
864 0-1 0 0 12 Framed-MTU [Note 3]
865 0+ 0 0 13 Framed-Compression [Note 3]
866 0+ 0 0 14 Login-IP-Host [Note 3]
867 0-1 0 0 15 Login-Service [Note 3]
868 0-1 0 0 16 Login-TCP-Port [Note 3]
869 0+ 0 0 18 Reply-Message [Note 2]
870 0-1 0 0 19 Callback-Number [Note 3]
871 0-1 0 0 20 Callback-Id [Note 3]
872 0+ 0 0 22 Framed-Route [Note 3]
873 0-1 0 0 23 Framed-IPX-Network [Note 3]
874 0-1 0-1 0-1 24 State [Note 7]
875 0+ 0 0 25 Class [Note 3]
876 0+ 0 0 26 Vendor-Specific [Note 3]
877 0-1 0 0 27 Session-Timeout [Note 3]
878 0-1 0 0 28 Idle-Timeout [Note 3]
879 0-1 0 0 29 Termination-Action [Note 3]
880 0-1 0 0 30 Called-Station-Id [Note 1]
881 0-1 0 0 31 Calling-Station-Id [Note 1]
882 0-1 0 0 32 NAS-Identifier [Note 1]
883 0+ 0+ 0+ 33 Proxy-State
884 0-1 0 0 34 Login-LAT-Service [Note 3]
885 0-1 0 0 35 Login-LAT-Node [Note 3]
886 0-1 0 0 36 Login-LAT-Group [Note 3]
887 0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
888 0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
889 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
890 0-1 0 0 44 Acct-Session-Id [Note 1]
891 0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
892 0-1 0-1 0-1 55 Event-Timestamp
893 0-1 0 0 61 NAS-Port-Type [Note 1]
894 Request ACK NAK # Attribute
898 Chiba, et al. Informational [Page 16]
900 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
903 Request ACK NAK # Attribute
904 0-1 0 0 62 Port-Limit [Note 3]
905 0-1 0 0 63 Login-LAT-Port [Note 3]
906 0+ 0 0 64 Tunnel-Type [Note 5]
907 0+ 0 0 65 Tunnel-Medium-Type [Note 5]
908 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
909 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
910 0+ 0 0 69 Tunnel-Password [Note 5]
911 0-1 0 0 71 ARAP-Features [Note 3]
912 0-1 0 0 72 ARAP-Zone-Access [Note 3]
913 0+ 0 0 78 Configuration-Token [Note 3]
914 0+ 0-1 0 79 EAP-Message [Note 2]
915 0-1 0-1 0-1 80 Message-Authenticator
916 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
917 0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
918 0+ 0 0 83 Tunnel-Preference [Note 5]
919 0-1 0 0 85 Acct-Interim-Interval [Note 3]
920 0-1 0 0 87 NAS-Port-Id [Note 1]
921 0-1 0 0 88 Framed-Pool [Note 3]
922 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
923 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
924 0-1 0 0 94 Originating-Line-Info [Note 1]
925 0-1 0 0 95 NAS-IPv6-Address [Note 1]
926 0-1 0 0 96 Framed-Interface-Id [Note 1]
927 0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
928 0+ 0 0 98 Login-IPv6-Host [Note 3]
929 0+ 0 0 99 Framed-IPv6-Route [Note 3]
930 0-1 0 0 100 Framed-IPv6-Pool [Note 3]
931 0 0 0+ 101 Error-Cause
932 Request ACK NAK # Attribute
936 Request ACK NAK # Attribute
937 0-1 0 0 1 User-Name [Note 1]
938 0-1 0 0 4 NAS-IP-Address [Note 1]
939 0-1 0 0 5 NAS-Port [Note 1]
940 0-1 0 0-1 6 Service-Type [Note 6]
941 0-1 0 0 8 Framed-IP-Address [Note 1]
942 0+ 0 0 18 Reply-Message [Note 2]
943 0-1 0-1 0-1 24 State [Note 7]
944 0+ 0 0 25 Class [Note 4]
945 0+ 0 0 26 Vendor-Specific
946 0-1 0 0 30 Called-Station-Id [Note 1]
947 0-1 0 0 31 Calling-Station-Id [Note 1]
948 0-1 0 0 32 NAS-Identifier [Note 1]
949 0+ 0+ 0+ 33 Proxy-State
950 Request ACK NAK # Attribute
954 Chiba, et al. Informational [Page 17]
956 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
959 Request ACK NAK # Attribute
960 0-1 0 0 44 Acct-Session-Id [Note 1]
961 0-1 0-1 0 49 Acct-Terminate-Cause
962 0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
963 0-1 0-1 0-1 55 Event-Timestamp
964 0-1 0 0 61 NAS-Port-Type [Note 1]
965 0+ 0-1 0 79 EAP-Message [Note 2]
966 0-1 0-1 0-1 80 Message-Authenticator
967 0-1 0 0 87 NAS-Port-Id [Note 1]
968 0-1 0 0 94 Originating-Line-Info [Note 1]
969 0-1 0 0 95 NAS-IPv6-Address [Note 1]
970 0-1 0 0 96 Framed-Interface-Id [Note 1]
971 0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
972 0 0+ 0+ 101 Error-Cause
973 Request ACK NAK # Attribute
975 [Note 1] Where NAS or session identification attributes are included
976 in Disconnect-Request or CoA-Request messages, they are used for
977 identification purposes only. These attributes MUST NOT be used for
978 purposes other than identification (e.g. within CoA-Request messages
979 to request authorization changes).
981 [Note 2] The Reply-Message Attribute is used to present a displayable
982 message to the user. The message is only displayed as a result of a
983 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
984 or CoA-ACK is subsequently sent). Where EAP is used for
985 authentication, an EAP-Message/Notification-Request Attribute is sent
986 instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-
987 Message/Notification-Response Attribute.
989 [Note 3] When included within a CoA-Request, these attributes
990 represent an authorization change request. When one of these
991 attributes is omitted from a CoA-Request, the NAS assumes that the
992 attribute value is to remain unchanged. Attributes included in a
993 CoA-Request replace all existing value(s) of the same attribute(s).
995 [Note 4] When included within a successful Disconnect-Request (where
996 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
997 sent unmodified by the client to the accounting server in the
998 Accounting Stop packet. If the Disconnect-Request is unsuccessful,
999 then the Class Attribute is not processed.
1001 [Note 5] When included within a CoA-Request, these attributes
1002 represent an authorization change request. Where tunnel attribute(s)
1003 are sent within a successful CoA-Request, all existing tunnel
1004 attributes are removed and replaced by the new attribute(s).
1010 Chiba, et al. Informational [Page 18]
1012 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1015 [Note 6] When included within a Disconnect-Request or CoA-Request, a
1016 Service-Type Attribute with value "Authorize Only" indicates that the
1017 Request only contains NAS and session identification attributes, and
1018 that the NAS should attempt reauthorization by sending an Access-
1019 Request with a Service-Type Attribute with value "Authorize Only".
1020 This enables a usage model akin to that supported in Diameter, thus
1021 easing translation between the two protocols. Support for the
1022 Service-Type Attribute is optional within CoA-Request and
1023 Disconnect-Request messages; where it is not included, the Request
1024 message may contain both identification and authorization attributes.
1025 A NAS that does not support the Service-Type Attribute with the value
1026 "Authorize Only" within a Disconnect-Request MUST respond with a
1027 Disconnect-NAK including no Service-Type Attribute; an Error-Cause
1028 Attribute with value "Unsupported Service" MAY be included. A NAS
1029 that does not support the Service-Type Attribute with the value
1030 "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
1031 including no Service-Type Attribute; an Error-Cause Attribute with
1032 value "Unsupported Service" MAY be included.
1034 A NAS supporting the "Authorize Only" Service-Type value within
1035 Disconnect-Request or CoA-Request messages MUST respond with a
1036 Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
1037 Attribute with value "Authorize Only", and an Error-Cause Attribute
1038 with value "Request Initiated". The NAS then sends an Access-Request
1039 to the RADIUS server with a Service-Type Attribute with value
1040 "Authorize Only". This Access-Request SHOULD contain the NAS
1041 attributes from the Disconnect or CoA-Request, as well as the session
1042 attributes from the Request legal for inclusion in an Access-Request
1043 as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As
1044 noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
1045 SHOULD be included in an Access-Request that does not contain a
1046 User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.
1047 The RADIUS server should send back an Access-Accept to (re-)authorize
1048 the session or an Access-Reject to refuse to (re-)authorize it.
1050 [Note 7] The State Attribute is available to be sent by the RADIUS
1051 server to the NAS in a Disconnect-Request or CoA-Request message and
1052 MUST be sent unmodified from the NAS to the RADIUS server in a
1053 subsequent ACK or NAK message. If a Service-Type Attribute with
1054 value "Authorize Only" is included in a Disconnect-Request or CoA-
1055 Request along with a State Attribute, then the State Attribute MUST
1056 be sent unmodified from the NAS to the RADIUS server in the resulting
1057 Access-Request sent to the RADIUS server, if any. The State
1058 Attribute is also available to be sent by the RADIUS server to the
1059 NAS in a CoA-Request that also includes a Termination-Action
1060 Attribute with the value of RADIUS-Request. If the client performs
1061 the Termination-Action by sending a new Access-Request upon
1062 termination of the current session, it MUST include the State
1066 Chiba, et al. Informational [Page 19]
1068 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1071 Attribute unchanged in that Access-Request. In either usage, the
1072 client MUST NOT interpret the Attribute locally. A Disconnect-
1073 Request or CoA-Request packet must have only zero or one State
1074 Attribute. Usage of the State Attribute is implementation dependent.
1075 If the RADIUS server does not recognize the State Attribute in the
1076 Access-Request, then it MUST send an Access-Reject.
1078 The following table defines the meaning of the above table entries.
1080 0 This attribute MUST NOT be present in packet.
1081 0+ Zero or more instances of this attribute MAY be present in
1083 0-1 Zero or one instance of this attribute MAY be present in packet.
1084 1 Exactly one instance of this attribute MUST be present in packet.
1086 4. IANA Considerations
1088 This document uses the RADIUS [RFC2865] namespace, see
1089 <http://www.iana.org/assignments/radius-types>. There are six
1090 updates for the section: RADIUS Packet Type Codes. These Packet
1091 Types are allocated in [RADIANA]:
1093 40 - Disconnect-Request
1100 Allocation of a new Service-Type value for "Authorize Only" is
1101 requested. This document also uses the UDP [RFC768] namespace, see
1102 <http://www.iana.org/assignments/port-numbers>. The authors request
1103 a port assignment from the Registered ports range. Finally, this
1104 specification allocates the Error-Cause Attribute (101) with the
1105 following decimal values:
1109 201 Residual Session Context Removed
1110 202 Invalid EAP Packet (Ignored)
1111 401 Unsupported Attribute
1112 402 Missing Attribute
1113 403 NAS Identification Mismatch
1115 405 Unsupported Service
1116 406 Unsupported Extension
1117 501 Administratively Prohibited
1118 502 Request Not Routable (Proxy)
1122 Chiba, et al. Informational [Page 20]
1124 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1127 503 Session Context Not Found
1128 504 Session Context Not Removable
1129 505 Other Proxy Processing Error
1130 506 Resources Unavailable
1131 507 Request Initiated
1133 5. Security Considerations
1135 5.1. Authorization Issues
1137 Where a NAS is shared by multiple providers, it is undesirable for
1138 one provider to be able to send Disconnect-Request or CoA-Requests
1139 affecting the sessions of another provider.
1141 A NAS or RADIUS proxy MUST silently discard Disconnect-Request or
1142 CoA-Request messages from untrusted sources. By default, a RADIUS
1143 proxy SHOULD perform a "reverse path forwarding" (RPF) check to
1144 verify that a Disconnect-Request or CoA-Request originates from an
1145 authorized RADIUS server. In addition, it SHOULD be possible to
1146 explicitly authorize additional sources of Disconnect-Request or
1147 CoA-Request packets relating to certain classes of sessions. For
1148 example, a particular source can be explicitly authorized to send
1149 CoA-Request messages relating to users within a set of realms.
1151 To perform the RPF check, the proxy uses the session identification
1152 attributes included in Disconnect-Request or CoA-Request messages, in
1153 order to determine the RADIUS server(s) to which an equivalent
1154 Access-Request could be routed. If the source address of the
1155 Disconnect-Request or CoA-Request is within this set, then the
1156 Request is forwarded; otherwise it MUST be silently discarded.
1158 Typically the proxy will extract the realm from the Network Access
1159 Identifier [RFC2486] included within the User-Name Attribute, and
1160 determine the corresponding RADIUS servers in the proxy routing
1161 tables. The RADIUS servers for that realm are then compared against
1162 the source address of the packet. Where no RADIUS proxy is present,
1163 the RPF check will need to be performed by the NAS itself.
1165 Since authorization to send a Disconnect-Request or CoA-Request is
1166 determined based on the source address and the corresponding shared
1167 secret, the NASes or proxies SHOULD configure a different shared
1168 secret for each RADIUS server.
1178 Chiba, et al. Informational [Page 21]
1180 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1185 [RFC2865] Section 3 states:
1187 A RADIUS server MUST use the source IP address of the RADIUS UDP
1188 packet to decide which shared secret to use, so that RADIUS
1189 requests can be proxied.
1191 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
1192 NAS-IPv6-Address Attributes will typically not match the source
1193 address observed by the RADIUS server. Since the NAS-Identifier
1194 Attribute need not contain an FQDN, this attribute may not be
1195 resolvable to the source address observed by the RADIUS server, even
1196 when no proxy is present.
1198 As a result, the authenticity check performed by a RADIUS server or
1199 proxy does not verify the correctness of NAS identification
1200 attributes. This makes it possible for a rogue NAS to forge NAS-IP-
1201 Address, NAS-IPv6-Address or NAS-Identifier Attributes within a
1202 RADIUS Access-Request in order to impersonate another NAS. It is
1203 also possible for a rogue NAS to forge session identification
1204 attributes such as the Called-Station-Id, Calling-Station-Id, or
1205 Originating-Line-Info [NASREQ]. This could fool the RADIUS server
1206 into sending Disconnect-Request or CoA-Request messages containing
1207 forged session identification attributes to a NAS targeted by an
1210 To address these vulnerabilities RADIUS proxies SHOULD check whether
1211 NAS identification attributes (see Section 3.) match the source
1212 address of packets originating from the NAS. Where one or more
1213 attributes do not match, Disconnect-Request or CoA-Request messages
1214 SHOULD be silently discarded.
1216 Such a check may not always be possible. Since the NAS-Identifier
1217 Attribute need not correspond to an FQDN, it may not be resolvable to
1218 an IP address to be matched against the source address. Also, where
1219 a NAT exists between the RADIUS client and proxy, checking the NAS-
1220 IP-Address or NAS-IPv6-Address Attributes may not be feasible.
1222 5.3. IPsec Usage Guidelines
1224 In addition to security vulnerabilities unique to Disconnect or CoA
1225 messages, the protocol exchanges described in this document are
1226 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is
1227 RECOMMENDED that IPsec be employed to afford better security.
1234 Chiba, et al. Informational [Page 22]
1236 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1239 Implementations of this specification SHOULD support IPsec [RFC2401]
1240 along with IKE [RFC2409] for key management. IPsec ESP [RFC2406]
1241 with a non-null transform SHOULD be supported, and IPsec ESP with a
1242 non-null encryption transform and authentication support SHOULD be
1243 used to provide per-packet confidentiality, authentication, integrity
1244 and replay protection. IKE SHOULD be used for key management.
1246 Within RADIUS [RFC2865], a shared secret is used for hiding
1247 Attributes such as User-Password, as well as used in computation of
1248 the Response Authenticator. In RADIUS accounting [RFC2866], the
1249 shared secret is used in computation of both the Request
1250 Authenticator and the Response Authenticator.
1252 Since in RADIUS a shared secret is used to provide confidentiality as
1253 well as integrity protection and authentication, only use of IPsec
1254 ESP with a non-null transform can provide security services
1255 sufficient to substitute for RADIUS application-layer security.
1256 Therefore, where IPsec AH or ESP null is used, it will typically
1257 still be necessary to configure a RADIUS shared secret.
1259 Where RADIUS is run over IPsec ESP with a non-null transform, the
1260 secret shared between the NAS and the RADIUS server MAY NOT be
1261 configured. In this case, a shared secret of zero length MUST be
1262 assumed. However, a RADIUS server that cannot know whether incoming
1263 traffic is IPsec-protected MUST be configured with a non-null RADIUS
1266 When IPsec ESP is used with RADIUS, per-packet authentication,
1267 integrity and replay protection MUST be used. 3DES-CBC MUST be
1268 supported as an encryption transform and AES-CBC SHOULD be supported.
1269 AES-CBC SHOULD be offered as a preferred encryption transform if
1270 supported. HMAC-SHA1-96 MUST be supported as an authentication
1271 transform. DES-CBC SHOULD NOT be used as the encryption transform.
1273 A typical IPsec policy for an IPsec-capable RADIUS client is
1274 "Initiate IPsec, from me to any destination port UDP 1812". This
1275 IPsec policy causes an IPsec SA to be set up by the RADIUS client
1276 prior to sending RADIUS traffic. If some RADIUS servers contacted by
1277 the client do not support IPsec, then a more granular policy will be
1278 required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server,
1279 destination port UDP 1812."
1281 For a client implementing this specification, the policy would be
1282 "Accept IPsec, from any to me, destination port UDP 3799". This
1283 causes the RADIUS client to accept (but not require) use of IPsec.
1284 It may not be appropriate to require IPsec for all RADIUS servers
1285 connecting to an IPsec-enabled RADIUS client, since some RADIUS
1286 servers may not support IPsec.
1290 Chiba, et al. Informational [Page 23]
1292 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1295 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
1296 IPsec, from any to me, destination port 1812". This causes the
1297 RADIUS server to accept (but not require) use of IPsec. It may not
1298 be appropriate to require IPsec for all RADIUS clients connecting to
1299 an IPsec-enabled RADIUS server, since some RADIUS clients may not
1302 For servers implementing this specification, the policy would be
1303 "Initiate IPsec, from me to any, destination port UDP 3799". This
1304 causes the RADIUS server to initiate IPsec when sending RADIUS
1305 extension traffic to any RADIUS client. If some RADIUS clients
1306 contacted by the server do not support IPsec, then a more granular
1307 policy will be required, such as "Initiate IPsec, from me to IPsec-
1308 capable-RADIUS-client, destination port UDP 3799".
1310 Where IPsec is used for security, and no RADIUS shared secret is
1311 configured, it is important that the RADIUS client and server perform
1312 an authorization check. Before enabling a host to act as a RADIUS
1313 client, the RADIUS server SHOULD check whether the host is authorized
1314 to provide network access. Similarly, before enabling a host to act
1315 as a RADIUS server, the RADIUS client SHOULD check whether the host
1316 is authorized for that role.
1318 RADIUS servers can be configured with the IP addresses (for IKE
1319 Aggressive Mode with pre-shared keys) or FQDNs (for certificate
1320 authentication) of RADIUS clients. Alternatively, if a separate
1321 Certification Authority (CA) exists for RADIUS clients, then the
1322 RADIUS server can configure this CA as a trust anchor [RFC3280] for
1325 Similarly, RADIUS clients can be configured with the IP addresses
1326 (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
1327 certificate authentication) of RADIUS servers. Alternatively, if a
1328 separate CA exists for RADIUS servers, then the RADIUS client can
1329 configure this CA as a trust anchor for use with IPsec.
1331 Since unlike SSL/TLS, IKE does not permit certificate policies to be
1332 set on a per-port basis, certificate policies need to apply to all
1333 uses of IPsec on RADIUS clients and servers. In IPsec deployment
1334 supporting only certificate authentication, a management station
1335 initiating an IPsec-protected telnet session to the RADIUS server
1336 would need to obtain a certificate chaining to the RADIUS client CA.
1337 Issuing such a certificate might not be appropriate if the management
1338 station was not authorized as a RADIUS client.
1340 Where RADIUS clients may obtain their IP address dynamically (such as
1341 an Access Point supporting DHCP), Main Mode with pre-shared keys
1342 [RFC2409] SHOULD NOT be used, since this requires use of a group
1346 Chiba, et al. Informational [Page 24]
1348 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1351 pre-shared key; instead, Aggressive Mode SHOULD be used. Where
1352 RADIUS client addresses are statically assigned, either Aggressive
1353 Mode or Main Mode MAY be used. With certificate authentication, Main
1354 Mode SHOULD be used.
1356 Care needs to be taken with IKE Phase 1 Identity Payload selection in
1357 order to enable mapping of identities to pre-shared keys, even with
1358 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
1359 Payloads are used and addresses are dynamically assigned, mapping of
1360 identities to keys is not possible, so that group pre-shared keys are
1361 still a practical necessity. As a result, the ID_FQDN identity
1362 payload SHOULD be employed in situations where Aggressive mode is
1363 utilized along with pre-shared keys and IP addresses are dynamically
1364 assigned. This approach also has other advantages, since it allows
1365 the RADIUS server and client to configure themselves based on the
1366 fully qualified domain name of their peers.
1368 Note that with IPsec, security services are negotiated at the
1369 granularity of an IPsec SA, so that RADIUS exchanges requiring a set
1370 of security services different from those negotiated with existing
1371 IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs
1372 are also advisable where quality of service considerations dictate
1373 different handling RADIUS conversations. Attempting to apply
1374 different quality of service to connections handled by the same IPsec
1375 SA can result in reordering, and falling outside the replay window.
1376 For a discussion of the issues, see [RFC2983].
1378 5.4. Replay Protection
1380 Where IPsec replay protection is not used, the Event-Timestamp (55)
1381 Attribute [RFC2869] SHOULD be included within all messages. When
1382 this attribute is present, both the NAS and the RADIUS server MUST
1383 check that the Event-Timestamp Attribute is current within an
1384 acceptable time window. If the Event-Timestamp Attribute is not
1385 current, then the message MUST be silently discarded. This implies
1386 the need for time synchronization within the network, which can be
1387 achieved by a variety of means, including secure NTP, as described in
1390 Both the NAS and the RADIUS server SHOULD be configurable to silently
1391 discard messages lacking an Event-Timestamp Attribute. A default
1392 time window of 300 seconds is recommended.
1402 Chiba, et al. Informational [Page 25]
1404 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1409 Disconnect Request with User-Name:
1411 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
1412 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
1415 Disconnect Request with Acct-Session-ID:
1417 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
1418 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
1419 32: 3930 3233 3435 3637 90234567
1421 Disconnect Request with Framed-IP-Address:
1423 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
1424 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
1429 7.1. Normative References
1431 [RFC1305] Mills, D., "Network Time Protocol (version 3)
1432 Specification, Implementation and Analysis", RFC 1305,
1435 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1438 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
1439 Keyed-Hashing for Message Authentication", RFC 2104,
1442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1443 Requirement Levels", BCP 14, RFC 2119, March 1997.
1445 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
1446 the Internet Protocol", RFC 2401, November 1998.
1448 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
1449 Payload (ESP)", RFC 2406, November 1998.
1451 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
1452 (IKE)", RFC 2409, November 1998.
1458 Chiba, et al. Informational [Page 26]
1460 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1463 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
1464 an IANA Considerations Section in RFCs", BCP 26, RFC
1467 [RFC2486] Aboba, B. and M. Beadles, "The Network Access
1468 Identifier", RFC 2486, January 1999.
1470 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
1471 "Remote Authentication Dial In User Service (RADIUS)",
1472 RFC 2865, June 2000.
1474 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1476 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
1477 Extensions", RFC 2869, June 2000.
1479 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
1480 RFC 3162, August 2001.
1482 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1483 X.509 Public Key Infrastructure Certificate and
1484 Certificate Revocation List (CRL) Profile", RFC 3280,
1487 [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote
1488 Authentication Dial In User Service)", RFC 3575, July
1491 7.2. Informative References
1493 [RFC2882] Mitton, D., "Network Access Server Requirements:
1494 Extended RADIUS Practices", RFC 2882, July 2000.
1496 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
1499 [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
1500 and Accounting (AAA) Transport Profile", RFC 3539,
1503 [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
1506 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
1507 Attack", CryptoBytes Vol.2 No.2, Summer 1996.
1509 [NASREQ] Calhoun, P., et al., "Diameter Network Access Server
1510 Application", Work in Progress.
1514 Chiba, et al. Informational [Page 27]
1516 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1519 [NTPAUTH] Mills, D., "Public Key Cryptography for the Network
1520 Time Protocol", Work in Progress.
1522 8. Intellectual Property Statement
1524 The IETF takes no position regarding the validity or scope of any
1525 intellectual property or other rights that might be claimed to
1526 pertain to the implementation or use of the technology described in
1527 this document or the extent to which any license under such rights
1528 might or might not be available; neither does it represent that it
1529 has made any effort to identify any such rights. Information on the
1530 IETF's procedures with respect to rights in standards-track and
1531 standards- related documentation can be found in BCP-11. Copies of
1532 claims of rights made available for publication and any assurances of
1533 licenses to be made available, or the result of an attempt made to
1534 obtain a general license or permission for the use of such
1535 proprietary rights by implementers or users of this specification can
1536 be obtained from the IETF Secretariat.
1538 The IETF invites any interested party to bring to its attention any
1539 copyrights, patents or patent applications, or other proprietary
1540 rights which may cover technology that may be required to practice
1541 this standard. Please address the information to the IETF Executive
1546 This protocol was first developed and distributed by Ascend
1547 Communications. Example code was distributed in their free server
1550 The authors would like to acknowledge the valuable suggestions and
1551 feedback from the following people:
1553 Avi Lior <avi@bridgewatersystems.com>,
1554 Randy Bush <randy@psg.net>,
1555 Steve Bellovin <smb@research.att.com>
1556 Glen Zorn <gwz@cisco.com>,
1557 Mark Jones <mjones@bridgewatersystems.com>,
1558 Claudio Lapidus <clapidus@hotmail.com>,
1559 Anurag Batta <Anurag_Batta@3com.com>,
1560 Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
1561 Tim Moore <timmoore@microsoft.com>.
1562 Russ Housley <housley@vigilsec.com>
1570 Chiba, et al. Informational [Page 28]
1572 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1575 10. Authors' Addresses
1582 EMail: mchiba@cisco.com
1583 Phone: +1 408 525 7198
1590 EMail: gdommety@cisco.com
1591 Phone: +1 408 525 1404
1598 EMail: meklund@cisco.com
1599 Phone: +1 865 671 6255
1602 Circular Logic UnLtd.
1603 733 Turnpike Street #154
1604 North Andover, MA 01845
1606 EMail: david@mitton.com
1607 Phone: +1 978 683 1814
1610 Microsoft Corporation
1614 EMail: bernarda@microsoft.com
1615 Phone: +1 425 706 6605
1616 Fax: +1 425 936 7329
1626 Chiba, et al. Informational [Page 29]
1628 RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
1631 11. Full Copyright Statement
1633 Copyright (C) The Internet Society (2003). All Rights Reserved.
1635 This document and translations of it may be copied and furnished to
1636 others, and derivative works that comment on or otherwise explain it
1637 or assist in its implementation may be prepared, copied, published
1638 and distributed, in whole or in part, without restriction of any
1639 kind, provided that the above copyright notice and this paragraph are
1640 included on all such copies and derivative works. However, this
1641 document itself may not be modified in any way, such as by removing
1642 the copyright notice or references to the Internet Society or other
1643 Internet organizations, except as needed for the purpose of
1644 developing Internet standards in which case the procedures for
1645 copyrights defined in the Internet Standards process must be
1646 followed, or as required to translate it into languages other than
1649 The limited permissions granted above are perpetual and will not be
1650 revoked by the Internet Society or its successors or assignees.
1652 This document and the information contained herein is provided on an
1653 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1654 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1656 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1657 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1661 Funding for the RFC Editor function is currently provided by the
1682 Chiba, et al. Informational [Page 30]
projects / freeradius.git / blob