7 Network Working Group M. Chiba
8 Request for Comments: 5176 G. Dommety
9 Obsoletes: 3576 M. Eklund
10 Category: Informational Cisco Systems, Inc.
12 RSA, Security Division of EMC
18 Dynamic Authorization Extensions to
19 Remote 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 This document describes a currently deployed extension to the Remote
30 Authentication Dial In User Service (RADIUS) protocol, allowing
31 dynamic changes to a user session, as implemented by network access
32 server products. This includes support for disconnecting users and
33 changing authorizations applicable to a user session.
58 Chiba, et al. Informational [Page 1]
60 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
65 1. Introduction ....................................................2
66 1.1. Applicability ..............................................3
67 1.2. Requirements Language ......................................4
68 1.3. Terminology ................................................4
69 2. Overview ........................................................4
70 2.1. Disconnect Messages (DMs) ..................................5
71 2.2. Change-of-Authorization (CoA) Messages .....................5
72 2.3. Packet Format ..............................................6
73 3. Attributes .....................................................10
74 3.1. Proxy State ...............................................12
75 3.2. Authorize Only ............................................13
76 3.3. State .....................................................14
77 3.4. Message-Authenticator .....................................15
78 3.5. Error-Cause ...............................................16
79 3.6. Table of Attributes .......................................20
80 4. Diameter Considerations ........................................24
81 5. IANA Considerations ............................................26
82 6. Security Considerations ........................................26
83 6.1. Authorization Issues ......................................26
84 6.2. IPsec Usage Guidelines ....................................27
85 6.3. Replay Protection .........................................28
86 7. Example Traces .................................................28
87 8. References .....................................................29
88 8.1. Normative References ......................................29
89 8.2. Informative References ....................................30
90 9. Acknowledgments ................................................30
91 Appendix A ........................................................31
95 The RADIUS protocol, defined in [RFC2865], does not support
96 unsolicited messages sent from the RADIUS server to the Network
99 However, there are many instances in which it is desirable for
100 changes to be made to session characteristics, without requiring the
101 NAS to initiate the exchange. For example, it may be desirable for
102 administrators to be able to terminate user session(s) in progress.
103 Alternatively, if the user changes authorization level, this may
104 require that authorization attributes be added/deleted from user
107 To overcome these limitations, several vendors have implemented
108 additional RADIUS commands in order to enable unsolicited messages to
109 be sent to the NAS. These extended commands provide support for
110 Disconnect and Change-of-Authorization (CoA) packets. Disconnect
114 Chiba, et al. Informational [Page 2]
116 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
119 packets cause user session(s) to be terminated immediately, whereas
120 CoA packets modify session authorization attributes such as data
125 This protocol is being recommended for publication as an
126 Informational RFC rather than as a standards-track RFC because of
127 problems that cannot be fixed without creating incompatibilities with
128 deployed implementations. This includes security vulnerabilities, as
129 well as semantic ambiguities resulting from the design of the
130 Change-of-Authorization (CoA) commands. While fixes are recommended,
131 they cannot be made mandatory since this would be incompatible with
132 existing implementations.
134 Existing implementations of this protocol do not support
135 authorization checks, so that an ISP sharing a NAS with another ISP
136 could disconnect or change authorizations for another ISP's users.
137 In order to remedy this problem, a "Reverse Path Forwarding" check is
138 described; see Section 6.1 for details.
140 Existing implementations utilize per-packet authentication and
141 integrity protection algorithms with known weaknesses [MD5Attack].
142 To provide stronger per-packet authentication and integrity
143 protection, the use of IPsec is recommended. See Section 6.2 for
146 Existing implementations lack replay protection. In order to support
147 replay detection, it is recommended that an Event-Timestamp Attribute
148 be added to all packets in situations where IPsec replay protection
149 is not employed. See Section 6.3 for details.
151 The approach taken with CoA commands in existing implementations
152 results in a semantic ambiguity. Existing implementations of the
153 CoA-Request identify the affected session, as well as supply the
154 authorization changes. Since RADIUS Attributes included within
155 existing implementations of the CoA-Request can be used for session
156 identification or authorization change, it may not be clear which
157 function a given attribute is serving.
159 The problem does not exist within the Diameter protocol [RFC3588], in
160 which server-initiated authorization change is initiated using a
161 Re-Auth-Request (RAR) command identifying the session via User-Name
162 and Session-Id Attribute Value Pairs (AVPs) and containing a
163 Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY". This results
164 in initiation of a standard Request/Response sequence where
165 authorization changes are supplied. As a result, in no command can
166 Diameter AVPs have multiple potential meanings.
170 Chiba, et al. Informational [Page 3]
172 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
175 1.2. Requirements Language
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119].
183 This document frequently uses the following terms:
185 Dynamic Authorization Client (DAC)
186 The entity originating Change of Authorization (CoA) Requests or
187 Disconnect-Requests. While it is possible that the DAC is
188 co-resident with a RADIUS authentication or accounting server,
189 this need not necessarily be the case.
191 Dynamic Authorization Server (DAS)
192 The entity receiving CoA-Request or Disconnect-Request packets.
193 The DAS may be a NAS or a RADIUS proxy.
195 Network Access Server (NAS)
196 The device providing access to the network.
199 The NAS provides a service to the user, such as IEEE 802 or
200 Point-to-Point Protocol (PPP).
203 Each service provided by the NAS to a user constitutes a
204 session, with the beginning of the session defined as the point
205 where service is first provided and the end of the session
206 defined as the point where service is ended. A user may have
207 multiple sessions in parallel or series if the NAS supports
211 This means the implementation discards the packet without
212 further processing. The implementation SHOULD provide the
213 capability of logging the error, including the contents of the
214 silently discarded packet, and SHOULD record the event in a
219 This section describes the most commonly implemented features of
220 Disconnect and Change-of-Authorization (CoA) packets.
226 Chiba, et al. Informational [Page 4]
228 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
231 2.1. Disconnect Messages (DMs)
233 A Disconnect-Request packet is sent by the Dynamic Authorization
234 Client in order to terminate user session(s) on a NAS and discard all
235 associated session context. The Disconnect-Request packet is sent to
236 UDP port 3799, and identifies the NAS as well as the user session(s)
237 to be terminated by inclusion of the identification attributes
238 described in Section 3.
240 +----------+ +----------+
241 | | Disconnect-Request | |
242 | | <-------------------- | |
244 | | Disconnect-ACK/NAK | |
245 | | ---------------------> | |
246 +----------+ +----------+
248 The NAS responds to a Disconnect-Request packet sent by a Dynamic
249 Authorization Client with a Disconnect-ACK if all associated session
250 context is discarded and the user session(s) are no longer connected,
251 or a Disconnect-NAK, if the NAS was unable to disconnect one or more
252 sessions and discard all associated session context. A Disconnect-
253 ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866]
254 with the value set to 6 for Admin-Reset.
256 2.2. Change-of-Authorization (CoA) Messages
258 CoA-Request packets contain information for dynamically changing
259 session authorizations. Typically, this is used to change data
260 filters. The data filters can be of either the ingress or egress
261 kind, and are sent in addition to the identification attributes as
262 described in Section 3. The port used and packet format (described
263 in Section 2.3) are the same as those for Disconnect-Request packets.
265 The following attributes MAY be sent in a CoA-Request:
267 Filter-ID (11) - Indicates the name of a data filter list
268 to be applied for the session(s) that the
269 identification attributes map to.
271 NAS-Filter-Rule (92) - Provides a filter list to be applied for
272 the session(s) that the identification
273 attributes map to [RFC4849].
282 Chiba, et al. Informational [Page 5]
284 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
287 +----------+ +----------+
289 | | <-------------------- | |
292 | | ---------------------> | |
293 +----------+ +----------+
295 The NAS responds to a CoA-Request sent by a Dynamic Authorization
296 Client with a CoA-ACK if the NAS is able to successfully change the
297 authorizations for the user session(s), or a CoA-NAK if the CoA-
298 Request is unsuccessful. A NAS MUST respond to a CoA-Request
299 including a Service-Type Attribute with an unsupported value with a
300 CoA-NAK; an Error-Cause Attribute with value "Unsupported Service"
305 For either Disconnect-Request or CoA-Request packets UDP port 3799 is
306 used as the destination port. For responses, the source and
307 destination ports are reversed. Exactly one RADIUS packet is
308 encapsulated in the UDP Data field.
310 A summary of the data format is shown below. The fields are
311 transmitted from left to right.
313 The packet format consists of the following fields: Code, Identifier,
314 Length, Authenticator, and Attributes in Type-Length-Value (TLV)
315 format. All fields hold the same meaning as those described in
316 RADIUS [RFC2865]. The Authenticator field MUST be calculated in the
317 same way as is specified for an Accounting-Request in [RFC2866].
320 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
321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322 | Code | Identifier | Length |
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
330 +-+-+-+-+-+-+-+-+-+-+-+-+-
338 Chiba, et al. Informational [Page 6]
340 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
345 The Code field is one octet, and identifies the type of RADIUS
346 packet. Packets received with an invalid Code field MUST be
347 silently discarded. RADIUS codes (decimal) for this extension are
350 40 - Disconnect-Request [RFC3575]
351 41 - Disconnect-ACK [RFC3575]
352 42 - Disconnect-NAK [RFC3575]
353 43 - CoA-Request [RFC3575]
354 44 - CoA-ACK [RFC3575]
355 45 - CoA-NAK [RFC3575]
359 The Identifier field is one octet, and aids in matching requests
360 and replies. A Dynamic Authorization Server implementing this
361 specification MUST be capable of detecting a duplicate request if
362 it has the same source IP address, source UDP port, and Identifier
363 within a short span of time.
365 The responsibility for retransmission of Disconnect-Request and
366 CoA-Request packets lies with the Dynamic Authorization Client.
367 If after sending these packets, the Dynamic Authorization Client
368 does not receive a response, it will retransmit.
370 The Identifier field MUST be changed whenever the content of the
371 Attributes field changes, or whenever a valid reply has been
372 received for a previous request. For retransmissions where the
373 contents are identical, the Identifier MUST remain unchanged.
375 If the Dynamic Authorization Client is retransmitting a
376 Disconnect-Request or CoA-Request to the same Dynamic
377 Authorization Server as before, and the attributes haven't
378 changed, the same Request Authenticator, Identifier, and source
379 port MUST be used. If any attributes have changed, a new
380 Authenticator and Identifier MUST be used.
382 If the Request to a primary Dynamic Authorization Server fails, a
383 secondary Dynamic Authorization Server must be queried, if
384 available; issues relating to failover algorithms are described in
385 [RFC3539]. Since this represents a new request, a new Request
386 Authenticator and Identifier MUST be used. However, where the
387 Dynamic Authorization Client is sending directly to the NAS,
388 failover typically does not make sense, since CoA-Request or
389 Disconnect-Request packets need to be delivered to the NAS where
394 Chiba, et al. Informational [Page 7]
396 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
401 The Length field is two octets. It indicates the length of the
402 packet including the Code, Identifier, Length, Authenticator, and
403 Attribute fields. Octets outside the range of the Length field
404 MUST be treated as padding and ignored on reception. If the
405 packet is shorter than the Length field indicates, it MUST be
406 silently discarded. The minimum length is 20 and maximum length
411 The Authenticator field is sixteen (16) octets. The most
412 significant octet is transmitted first. This value is used to
413 authenticate packets between the Dynamic Authorization Client and
414 the Dynamic Authorization Server.
416 Request Authenticator
418 In Request packets, the Authenticator value is a 16-octet MD5
419 [RFC1321] checksum, called the Request Authenticator. The
420 Request Authenticator is calculated the same way as for an
421 Accounting-Request, specified in [RFC2866].
423 Note that the Request Authenticator of a CoA-Request or
424 Disconnect-Request cannot be computed the same way as the
425 Request Authenticator of a RADIUS Access-Request, because there
426 is no User-Password Attribute in a CoA-Request or Disconnect-
429 Response Authenticator
431 The Authenticator field in a Response packet (e.g.,
432 Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called
433 the Response Authenticator, and contains a one-way MD5 hash
434 calculated over a stream of octets consisting of the Code,
435 Identifier, Length, the Request Authenticator field from the
436 packet being replied to, and the response attributes if any,
437 followed by the shared secret. The resulting 16-octet MD5 hash
438 value is stored in the Authenticator field of the Response
441 Administrative note: As noted in [RFC2865], Section 3, the secret
442 (password shared between the Dynamic Authorization Client and the
443 Dynamic Authorization Server) SHOULD be at least as large and
444 unguessable as a well-chosen password. The Dynamic Authorization
450 Chiba, et al. Informational [Page 8]
452 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
455 Server MUST use the source IP address of the RADIUS UDP packet to
456 decide which shared secret to use, so that requests can be
461 In CoA-Request and Disconnect-Request packets, all attributes MUST
462 be treated as mandatory. If one or more authorization changes
463 specified in a CoA-Request cannot be carried out, the NAS MUST
464 send a CoA-NAK. A NAS MUST respond to a CoA-Request containing
465 one or more unsupported attributes or Attribute values with a
466 CoA-NAK; an Error-Cause Attribute with value 401 (Unsupported
467 Attribute) or 407 (Invalid Attribute Value) MAY be included. A
468 NAS MUST respond to a Disconnect-Request containing one or more
469 unsupported attributes or Attribute values with a Disconnect-NAK;
470 an Error-Cause Attribute with value 401 (Unsupported Attribute) or
471 407 (Invalid Attribute Value) MAY be included.
473 State changes resulting from a CoA-Request MUST be atomic: if the
474 CoA-Request is successful for all matching sessions, the NAS MUST
475 send a CoA-ACK in reply, and all requested authorization changes
476 MUST be made. If the CoA-Request is unsuccessful for any matching
477 sessions, the NAS MUST send a CoA-NAK in reply, and the requested
478 authorization changes MUST NOT be made for any of the matching
479 sessions. Similarly, a state change MUST NOT occur as a result of
480 a Disconnect-Request that is unsuccessful with respect to any of
481 the matching sessions; a NAS MUST send a Disconnect-NAK in reply
482 if any of the matching sessions cannot be successfully terminated.
483 A NAS that does not support dynamic authorization changes applying
484 to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in
485 reply; an Error-Cause Attribute with value 508 (Multiple Session
486 Selection Unsupported) SHOULD be included.
488 Within this specification, attributes can be used for
489 identification, authorization, or other purposes. RADIUS
490 Attribute specifications created after publication of this
491 document SHOULD state whether an attribute can be included in CoA
492 or Disconnect messages, and if so, which messages it can be
493 included in and whether it serves as an identification or
494 authorization attribute.
496 Even if a NAS implements an attribute for use with RADIUS
497 authentication and accounting, it is possible that it will not
498 support inclusion of that attribute within CoA-Request and
499 Disconnect-Request packets, given the difference in attribute
500 semantics. This is true even for attributes specified as
506 Chiba, et al. Informational [Page 9]
508 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
511 allowable within Access-Accept packets (such as those defined
512 within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579],
513 [RFC4372], [RFC4675], [RFC4818], and [RFC4849]).
517 In Disconnect-Request and CoA-Request packets, certain attributes are
518 used to uniquely identify the NAS as well as user session(s) on the
519 NAS. The combination of NAS and session identification attributes
520 included in a CoA-Request or Disconnect-Request packet MUST match at
521 least one session in order for a Request to be successful; otherwise
522 a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification
523 attributes match, and more than one session matches all of the
524 session identification attributes, then a CoA-Request or Disconnect-
525 Request MUST apply to all matching sessions.
527 Identification attributes include NAS and session identification
528 attributes, as described below.
530 NAS identification attributes
532 Attribute # Reference Description
533 --------- --- --------- -----------
534 NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
535 NAS-Identifier 32 [RFC2865] String identifying the NAS.
536 NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
538 Session identification attributes
540 Attribute # Reference Description
541 --------- --- --------- -----------
542 User-Name 1 [RFC2865] The name of the user
543 associated with one or
545 NAS-Port 5 [RFC2865] The port on which a
546 session is terminated.
547 Framed-IP-Address 8 [RFC2865] The IPv4 address associated
549 Vendor-Specific 26 [RFC2865] One or more vendor-specific
550 identification attributes.
551 Called-Station-Id 30 [RFC2865] The link address to which
552 a session is connected.
553 Calling-Station-Id 31 [RFC2865] The link address from which
554 one or more sessions are
556 Acct-Session-Id 44 [RFC2866] The identifier uniquely
557 identifying a session
562 Chiba, et al. Informational [Page 10]
564 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
567 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
568 identifying related sessions.
569 NAS-Port-Id 87 [RFC2869] String identifying the port
571 Chargeable-User- 89 [RFC4372] The CUI associated with one
572 Identity or more sessions. Needed
573 where a privacy Network
574 Access Identifier (NAI) is
575 used, since in this case the
576 User-Name (e.g., "anonymous")
577 may not identify sessions
578 belonging to a given user.
579 Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
580 associated with a session,
583 Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
584 with a session, always sent
585 with Framed-Interface-Id.
587 To address security concerns described in Section 6.1, either the
588 User-Name or Chargeable-User-Identity attribute SHOULD be present in
589 Disconnect-Request and CoA-Request packets.
591 Where a Diameter client utilizes the same Session-Id for both
592 authorization and accounting, inclusion of an Acct-Session-Id
593 Attribute in a Disconnect-Request or CoA-Request can assist with
594 Diameter/RADIUS translation, since Diameter RAR and ASR commands
595 include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be
596 included in Disconnect-Request and CoA-Request packets.
598 A NAS implementing this specification SHOULD send an Acct-Session-Id
599 or Acct-Multi-Session-Id Attribute within an Access-Request. Where
600 an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
601 within an Access-Request, the Dynamic Authorization Client will not
602 know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
603 is attempting to target, unless it also has access to the accounting
604 data for that session.
606 Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
607 present in a CoA-Request or Disconnect-Request, it is possible that
608 the User-Name or Chargeable-User-Identity attributes will not be
609 sufficient to uniquely identify a single session (e.g., if the same
610 user has multiple sessions on the NAS, or if the privacy NAI is
611 used). In this case, if it is desired to identify a single session,
612 session identification MAY be performed by using one or more of the
613 Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
614 Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
618 Chiba, et al. Informational [Page 11]
620 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
623 To assist RADIUS proxies in routing Request packets to their
624 destination, one or more of the NAS-IP-Address or NAS-IPv6-Address
625 attributes SHOULD be present in CoA-Request and Disconnect-Request
626 packets; the NAS-Identifier Attribute MAY be present. Impersonation
627 issues with NAS Identification attributes are discussed in [RFC3579],
630 A Disconnect-Request MUST contain only NAS and session identification
631 attributes. If other attributes are included in a Disconnect-
632 Request, implementations MUST send a Disconnect-NAK; an Error-Cause
633 Attribute with value "Unsupported Attribute" MAY be included.
635 The DAC may require access to data from RADIUS authentication or
636 accounting packets. It uses this data to compose compliant CoA-
637 Request or Disconnect-Request packets. For example, as described in
638 Section 3.3, a CoA-Request packet containing a Service-Type Attribute
639 with a value of "Authorize Only" is required to contain a State
640 Attribute. The NAS will subsequently transmit this attribute to the
641 RADIUS server in an Access-Request. In order for the DAC to include
642 a State Attribute that the RADIUS server will subsequently accept,
643 some coordination between the two parties may be required.
645 This coordination can be achieved in multiple ways. The DAC may be
646 co-located with a RADIUS server, in which case it is presumed to have
647 access to the necessary data. The RADIUS server may also store that
648 information in a common database. The DAC can then be separated from
649 the RADIUS server, so long as it has access to that common database.
651 Where the DAC is not co-located with a RADIUS server, and does not
652 have access to a common database, the DAC SHOULD send CoA-Request or
653 Disconnect-Request packets to a RADIUS server acting as a proxy,
654 rather than sending them directly to the NAS.
656 A RADIUS server receiving a CoA-Request or Disconnect-Request packet
657 from the DAC MAY then add or update attributes (such as adding NAS or
658 session identification attributes or appending a State Attribute),
659 prior to forwarding the packet. Having CoA/Disconnect-Requests
660 forwarded by a RADIUS server can also enable upstream RADIUS proxies
661 to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).
665 If there are any Proxy-State attributes in a Disconnect-Request or
666 CoA-Request received from the Dynamic Authorization Client, the
667 Dynamic Authorization Server MUST include those Proxy-State
668 attributes in its response to the Dynamic Authorization Client.
674 Chiba, et al. Informational [Page 12]
676 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
679 A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
680 State, or Class attributes present in the packet. The forwarding
681 proxy or NAS MUST treat any Proxy-State attributes already in the
682 packet as opaque data. Its operation MUST NOT depend on the content
683 of Proxy-State attributes added by previous proxies. The forwarding
684 proxy MUST NOT modify any other Proxy-State attributes that were in
685 the packet; it may choose not to forward them, but it MUST NOT change
686 their contents. If the forwarding proxy omits the Proxy-State
687 attributes in the request, it MUST attach them to the response before
690 When the proxy forwards a Disconnect-Request or CoA-Request, it MAY
691 add a Proxy-State Attribute, but it MUST NOT add more than one. If a
692 Proxy-State Attribute is added to a packet when forwarding the
693 packet, the Proxy-State Attribute MUST be added after any existing
694 Proxy-State attributes. The forwarding proxy MUST NOT change the
695 order of any attributes of the same type, including Proxy-State.
696 Other attributes can be placed before, after, or even between the
697 Proxy-State attributes.
699 When the proxy receives a response to a CoA-Request or Disconnect-
700 Request, it MUST remove its own Proxy-State Attribute (the last
701 Proxy-State in the packet) before forwarding the response. Since
702 Disconnect and CoA responses are authenticated on the entire packet
703 contents, the stripping of the Proxy-State Attribute invalidates the
704 integrity check, so the proxy MUST recompute it.
708 To simplify translation between RADIUS and Diameter, Dynamic
709 Authorization Clients can include a Service-Type Attribute with value
710 "Authorize Only" within a CoA-Request; see Section 4 for details on
711 Diameter considerations. Support for a CoA-Request including a
712 Service-Type Attribute with value "Authorize Only" is OPTIONAL on the
713 NAS and Dynamic Authorization Client. A Service-Type Attribute MUST
714 NOT be included within a Disconnect-Request.
716 A NAS MUST respond to a CoA-Request including a Service-Type
717 Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST
718 NOT be sent. If the NAS does not support a Service-Type value of
719 "Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause
720 Attribute with a value of 405 (Unsupported Service) SHOULD be
723 A CoA-Request containing a Service-Type Attribute with value
724 "Authorize Only" MUST in addition contain only NAS or session
725 identification attributes, as well as a State Attribute. If other
730 Chiba, et al. Informational [Page 13]
732 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
735 attributes are included in such a CoA-Request, a CoA-NAK MUST be
736 sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)
739 If a CoA-Request packet including a Service-Type value of "Authorize
740 Only" is successfully processed, the NAS MUST respond with a CoA-NAK
741 containing a Service-Type Attribute with value "Authorize Only", and
742 an Error-Cause Attribute with value 507 (Request Initiated). The NAS
743 then MUST send an Access-Request to the RADIUS server including a
744 Service-Type Attribute with value "Authorize Only", along with a
745 State Attribute. This Access-Request SHOULD contain the NAS
746 identification attributes from the CoA-Request, as well as the
747 session identification attributes from the CoA-Request permitted in
748 an Access-Request; it also MAY contain other attributes permitted in
751 As noted in [RFC2869], Section 5.19, a Message-Authenticator
752 attribute SHOULD be included in an Access-Request that does not
753 contain a User-Password, CHAP-Password, ARAP-Password, or EAP-Message
754 Attribute. The RADIUS server then will respond to the Access-Request
755 with an Access-Accept to (re-)authorize the session or an Access-
756 Reject to refuse to (re-)authorize it.
760 The State Attribute is available to be sent by the Dynamic
761 Authorization Client to the NAS in a CoA-Request packet and MUST be
762 sent unmodified from the NAS to the Dynamic Authorization Client in a
763 subsequent ACK or NAK packet.
765 [RFC2865], Section 5.44 states:
767 An Access-Request MUST contain either a User-Password or a
768 CHAP-Password or State. An Access-Request MUST NOT contain both a
769 User-Password and a CHAP-Password. If future extensions allow
770 other kinds of authentication information to be conveyed, the
771 attribute for that can be used in an Access-Request instead of
772 User-Password or CHAP-Password.
774 In order to satisfy the requirements of [RFC2865], Section 5.44, an
775 Access-Request with Service-Type Attribute with value "Authorize
776 Only" MUST contain a State Attribute.
778 In order to provide a State Attribute to the NAS, a Dynamic
779 Authorization Client sending a CoA-Request with a Service-Type
780 Attribute with a value of "Authorize Only" MUST include a State
781 Attribute, and the NAS MUST send the State Attribute unmodified to
782 the RADIUS server in the resulting Access-Request, if any. A NAS
786 Chiba, et al. Informational [Page 14]
788 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
791 receiving a CoA-Request containing a Service-Type Attribute with a
792 value of "Authorize Only" but lacking a State Attribute MUST send a
793 CoA-NAK and SHOULD include an Error-Cause Attribute with a value of
794 402 (Missing Attribute).
796 The State Attribute is also available to be sent by the Dynamic
797 Authorization Client to the NAS in a CoA-Request that also includes a
798 Termination-Action Attribute with the value of RADIUS-Request. If
799 the NAS performs the Termination-Action by sending a new Access-
800 Request upon termination of the current session, it MUST include the
801 State Attribute unchanged in that Access-Request. In either usage,
802 the Dynamic Authorization Server MUST NOT interpret the Attribute
803 locally. A CoA-Request packet MUST have only zero or one State
804 Attribute. Usage of the State Attribute is implementation dependent.
806 3.4. Message-Authenticator
808 The Message-Authenticator Attribute MAY be used to authenticate and
809 integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request,
810 Disconnect-ACK, and Disconnect-NAK packets in order to prevent
813 A Dynamic Authorization Server receiving a CoA-Request or
814 Disconnect-Request with a Message-Authenticator Attribute present
815 MUST calculate the correct value of the Message-Authenticator and
816 silently discard the packet if it does not match the value sent. A
817 Dynamic Authorization Client receiving a CoA/Disconnect-ACK or
818 CoA/Disconnect-NAK with a Message-Authenticator Attribute present
819 MUST calculate the correct value of the Message-Authenticator and
820 silently discard the packet if it does not match the value sent.
822 When a Message-Authenticator Attribute is included within a CoA-
823 Request or Disconnect-Request, it is calculated as follows:
825 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
826 Request Authenticator, Attributes)
828 When the HMAC-MD5 message integrity check is calculated the
829 Request Authenticator field and Message-Authenticator Attribute
830 MUST each be considered to be sixteen octets of zero. The
831 Message-Authenticator Attribute is calculated and inserted in the
832 packet before the Request Authenticator is calculated.
842 Chiba, et al. Informational [Page 15]
844 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
847 When a Message-Authenticator Attribute is included within a CoA-
848 ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated
851 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
852 Request Authenticator, Attributes)
854 When the HMAC-MD5 message integrity check is calculated, the
855 Message-Authenticator Attribute MUST be considered to be sixteen
856 octets of zero. The Request Authenticator is taken from the
857 corresponding CoA/Disconnect-Request. The Message-Authenticator
858 is calculated and inserted in the packet before the Response
859 Authenticator is calculated.
865 It is possible that a Dynamic Authorization Server cannot honor
866 Disconnect-Request or CoA-Request packets for some reason. The
867 Error-Cause Attribute provides more detail on the cause of the
868 problem. It MAY be included within CoA-NAK and Disconnect-NAK
871 A summary of the Error-Cause Attribute format is shown below. The
872 fields are transmitted from left to right.
875 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
876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
877 | Type | Length | Value
878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
892 The Value field is four octets, containing an integer specifying
893 the cause of the error. Values 0-199 and 300-399 are reserved.
894 Values 200-299 represent successful completion, so that these
898 Chiba, et al. Informational [Page 16]
900 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
903 values may only be sent within CoA-ACK or Disconnect-ACK packets
904 and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.
905 Values 400-499 represent fatal errors committed by the Dynamic
906 Authorization Client, so that they MAY be sent within CoA-NAK or
907 Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or
908 Disconnect-ACK packets. Values 500-599 represent fatal errors
909 occurring on a Dynamic Authorization Server, so that they MAY be
910 sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be
911 sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values
912 SHOULD be logged by the Dynamic Authorization Client. Error-Code
913 values (expressed in decimal) include:
917 201 Residual Session Context Removed
918 202 Invalid EAP Packet (Ignored)
919 401 Unsupported Attribute
920 402 Missing Attribute
921 403 NAS Identification Mismatch
923 405 Unsupported Service
924 406 Unsupported Extension
925 407 Invalid Attribute Value
926 501 Administratively Prohibited
927 502 Request Not Routable (Proxy)
928 503 Session Context Not Found
929 504 Session Context Not Removable
930 505 Other Proxy Processing Error
931 506 Resources Unavailable
932 507 Request Initiated
933 508 Multiple Session Selection Unsupported
935 "Residual Session Context Removed" is sent in response to a
936 Disconnect-Request if one or more user sessions are no longer
937 active, but residual session context was found and successfully
938 removed. This value is only sent within a Disconnect-ACK and MUST
939 NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK.
941 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT
942 be sent by implementations of this specification.
944 "Unsupported Attribute" is a fatal error sent if a Request
945 contains an attribute (such as a Vendor-Specific or EAP-Message
946 Attribute) that is not supported.
948 "Missing Attribute" is a fatal error sent if critical attributes
949 (such as NAS or session identification attributes) are missing
954 Chiba, et al. Informational [Page 17]
956 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
959 "NAS Identification Mismatch" is a fatal error sent if one or more
960 NAS identification attributes (see Section 3) do not match the
961 identity of the NAS receiving the Request.
963 "Invalid Request" is a fatal error sent if some other aspect of
964 the Request is invalid, such as if one or more attributes (such as
965 EAP-Message Attribute(s)) are not formatted properly.
967 "Unsupported Service" is a fatal error sent if a Service-Type
968 Attribute included with the Request is sent with an invalid or
969 unsupported value. This error cannot be sent in response to a
972 "Unsupported Extension" is a fatal error sent due to lack of
973 support for an extension such as Disconnect and/or CoA packets.
974 This will typically be sent by a proxy receiving an ICMP port
975 unreachable message after attempting to forward a CoA-Request or
976 Disconnect-Request to the NAS.
978 "Invalid Attribute Value" is a fatal error sent if a CoA-Request
979 or Disconnect-Request contains an attribute with an unsupported
982 "Administratively Prohibited" is a fatal error sent if the NAS is
983 configured to prohibit honoring of CoA-Request or Disconnect-
984 Request packets for the specified session.
986 "Request Not Routable" is a fatal error that MAY be sent by a
987 proxy and MUST NOT be sent by a NAS. It indicates that the proxy
988 was unable to determine how to route a CoA-Request or Disconnect-
989 Request to the NAS. For example, this can occur if the required
990 entries are not present in the proxy's realm routing table.
992 "Session Context Not Found" is a fatal error sent if the session
993 context identified in the CoA-Request or Disconnect-Request does
994 not exist on the NAS.
996 "Session Context Not Removable" is a fatal error sent in response
997 to a Disconnect-Request if the NAS was able to locate the session
998 context, but could not remove it for some reason. It MUST NOT be
999 sent within a CoA-ACK, CoA-NAK, or Disconnect-ACK, only within a
1002 "Other Proxy Processing Error" is a fatal error sent in response
1003 to a CoA or Disconnect-Request that could not be processed by a
1004 proxy, for reasons other than routing.
1010 Chiba, et al. Informational [Page 18]
1012 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1015 "Resources Unavailable" is a fatal error sent when a CoA or
1016 Disconnect-Request could not be honored due to lack of available
1017 NAS resources (memory, non-volatile storage, etc.).
1019 "Request Initiated" is a fatal error sent by a NAS in response to
1020 a CoA-Request including a Service-Type Attribute with a value of
1021 "Authorize Only". It indicates that the CoA-Request has not been
1022 honored, but that the NAS is sending one or more RADIUS Access-
1023 Requests including a Service-Type Attribute with value "Authorize
1024 Only" to the RADIUS server.
1026 "Multiple Session Selection Unsupported" is a fatal error sent by
1027 a NAS in response to a CoA-Request or Disconnect-Request whose
1028 session identification attributes match multiple sessions, where
1029 the NAS does not support Requests applying to multiple sessions.
1066 Chiba, et al. Informational [Page 19]
1068 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1071 3.6. Table of Attributes
1073 The following table provides a guide to which attributes may be found
1074 in which packets, and in what quantity.
1076 Change-of-Authorization Messages
1078 Request ACK NAK # Attribute
1079 0-1 0 0 1 User-Name (Note 1)
1080 0-1 0 0 4 NAS-IP-Address (Note 1)
1081 0-1 0 0 5 NAS-Port (Note 1)
1082 0-1 0 0-1 6 Service-Type
1083 0-1 0 0 7 Framed-Protocol (Note 3)
1084 0-1 0 0 8 Framed-IP-Address (Notes 1, 6)
1085 0-1 0 0 9 Framed-IP-Netmask (Note 3)
1086 0-1 0 0 10 Framed-Routing (Note 3)
1087 0+ 0 0 11 Filter-ID (Note 3)
1088 0-1 0 0 12 Framed-MTU (Note 3)
1089 0+ 0 0 13 Framed-Compression (Note 3)
1090 0+ 0 0 14 Login-IP-Host (Note 3)
1091 0-1 0 0 15 Login-Service (Note 3)
1092 0-1 0 0 16 Login-TCP-Port (Note 3)
1093 0+ 0 0 18 Reply-Message (Note 2)
1094 0-1 0 0 19 Callback-Number (Note 3)
1095 0-1 0 0 20 Callback-Id (Note 3)
1096 0+ 0 0 22 Framed-Route (Note 3)
1097 0-1 0 0 23 Framed-IPX-Network (Note 3)
1098 0-1 0-1 0-1 24 State
1099 0+ 0 0 25 Class (Note 3)
1100 0+ 0 0 26 Vendor-Specific (Note 7)
1101 0-1 0 0 27 Session-Timeout (Note 3)
1102 0-1 0 0 28 Idle-Timeout (Note 3)
1103 0-1 0 0 29 Termination-Action (Note 3)
1104 Request ACK NAK # Attribute
1122 Chiba, et al. Informational [Page 20]
1124 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1127 Request ACK NAK # Attribute
1128 0-1 0 0 30 Called-Station-Id (Note 1)
1129 0-1 0 0 31 Calling-Station-Id (Note 1)
1130 0-1 0 0 32 NAS-Identifier (Note 1)
1131 0+ 0+ 0+ 33 Proxy-State
1132 0-1 0 0 34 Login-LAT-Service (Note 3)
1133 0-1 0 0 35 Login-LAT-Node (Note 3)
1134 0-1 0 0 36 Login-LAT-Group (Note 3)
1135 0-1 0 0 37 Framed-AppleTalk-Link (Note 3)
1136 0+ 0 0 38 Framed-AppleTalk-Network (Note 3)
1137 0-1 0 0 39 Framed-AppleTalk-Zone (Note 3)
1138 0-1 0 0 44 Acct-Session-Id (Note 1)
1139 0-1 0 0 50 Acct-Multi-Session-Id (Note 1)
1140 0-1 0-1 0-1 55 Event-Timestamp
1141 0+ 0 0 56 Egress-VLANID (Note 3)
1142 0-1 0 0 57 Ingress-Filters (Note 3)
1143 0+ 0 0 58 Egress-VLAN-Name (Note 3)
1144 0-1 0 0 59 User-Priority-Table (Note 3)
1145 0-1 0 0 61 NAS-Port-Type (Note 3)
1146 0-1 0 0 62 Port-Limit (Note 3)
1147 0-1 0 0 63 Login-LAT-Port (Note 3)
1148 0+ 0 0 64 Tunnel-Type (Note 5)
1149 0+ 0 0 65 Tunnel-Medium-Type (Note 5)
1150 0+ 0 0 66 Tunnel-Client-Endpoint (Note 5)
1151 0+ 0 0 67 Tunnel-Server-Endpoint (Note 5)
1152 0+ 0 0 69 Tunnel-Password (Note 5)
1153 0-1 0 0 71 ARAP-Features (Note 3)
1154 0-1 0 0 72 ARAP-Zone-Access (Note 3)
1155 0+ 0 0 78 Configuration-Token (Note 3)
1156 0+ 0-1 0 79 EAP-Message (Note 2)
1157 0-1 0-1 0-1 80 Message-Authenticator
1158 0+ 0 0 81 Tunnel-Private-Group-ID (Note 5)
1159 0+ 0 0 82 Tunnel-Assignment-ID (Note 5)
1160 0+ 0 0 83 Tunnel-Preference (Note 5)
1161 0-1 0 0 85 Acct-Interim-Interval (Note 3)
1162 0-1 0 0 87 NAS-Port-Id (Note 1)
1163 0-1 0 0 88 Framed-Pool (Note 3)
1164 0-1 0 0 89 Chargeable-User-Identity (Note 1)
1165 0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5)
1166 0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5)
1167 0-1 0 0 92 NAS-Filter-Rule (Note 3)
1168 0 0 0 94 Originating-Line-Info
1169 0-1 0 0 95 NAS-IPv6-Address (Note 1)
1170 0-1 0 0 96 Framed-Interface-Id (Notes 1, 6)
1171 0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6)
1172 0+ 0 0 98 Login-IPv6-Host (Note 3)
1173 0+ 0 0 99 Framed-IPv6-Route (Note 3)
1174 Request ACK NAK # Attribute
1178 Chiba, et al. Informational [Page 21]
1180 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1183 Request ACK NAK # Attribute
1184 0-1 0 0 100 Framed-IPv6-Pool (Note 3)
1185 0 0 0+ 101 Error-Cause
1186 0+ 0 0 123 Delegated-IPv6-Prefix (Note 3)
1187 Request ACK NAK # Attribute
1191 Request ACK NAK # Attribute
1192 0-1 0 0 1 User-Name (Note 1)
1193 0-1 0 0 4 NAS-IP-Address (Note 1)
1194 0-1 0 0 5 NAS-Port (Note 1)
1195 0 0 0 6 Service-Type
1196 0 0 0 8 Framed-IP-Address (Note 1)
1197 0+ 0 0 18 Reply-Message (Note 2)
1199 0+ 0 0 25 Class (Note 4)
1200 0+ 0 0 26 Vendor-Specific (Note 7)
1201 0-1 0 0 30 Called-Station-Id (Note 1)
1202 0-1 0 0 31 Calling-Station-Id (Note 1)
1203 0-1 0 0 32 NAS-Identifier (Note 1)
1204 0+ 0+ 0+ 33 Proxy-State
1205 0-1 0 0 44 Acct-Session-Id (Note 1)
1206 0-1 0-1 0 49 Acct-Terminate-Cause
1207 0-1 0 0 50 Acct-Multi-Session-Id (Note 1)
1208 0-1 0-1 0-1 55 Event-Timestamp
1209 0 0 0 61 NAS-Port-Type
1210 0+ 0-1 0 79 EAP-Message (Note 2)
1211 0-1 0-1 0-1 80 Message-Authenticator
1212 0-1 0 0 87 NAS-Port-Id (Note 1)
1213 0-1 0 0 89 Chargeable-User-Identity (Note 1)
1214 0-1 0 0 95 NAS-IPv6-Address (Note 1)
1215 0 0 0 96 Framed-Interface-Id (Note 1)
1216 0 0 0 97 Framed-IPv6-Prefix (Note 1)
1217 0 0 0+ 101 Error-Cause
1218 Request ACK NAK # Attribute
1220 The following defines the meaning of the above table entries:
1222 0 This attribute MUST NOT be present in packet.
1223 0+ Zero or more instances of this attribute MAY be present in
1225 0-1 Zero or one instance of this attribute MAY be present in packet.
1226 1 Exactly one instance of this attribute MUST be present in
1234 Chiba, et al. Informational [Page 22]
1236 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1239 (Note 1) Where NAS or session identification attributes are included
1240 in Disconnect-Request or CoA-Request packets, they are used for
1241 identification purposes only. These attributes MUST NOT be used for
1242 purposes other than identification (e.g., within CoA-Request packets
1243 to request authorization changes).
1245 (Note 2) The Reply-Message Attribute is used to present a displayable
1246 message to the user. The message is only displayed as a result of a
1247 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
1248 or CoA-ACK is subsequently sent). Where Extension Authentication
1249 Protocol (EAP) is used for authentication, an EAP-
1250 Message/Notification-Request Attribute is sent instead, and
1251 Disconnect-ACK or CoA-ACK packets contain an EAP-
1252 Message/Notification-Response Attribute.
1254 (Note 3) When included within a CoA-Request, these attributes
1255 represent an authorization change request. When one of these
1256 attributes is omitted from a CoA-Request, the NAS assumes that the
1257 attribute value is to remain unchanged. Attributes included in a
1258 CoA-Request replace all existing values of the same attribute(s).
1260 (Note 4) When included within a successful Disconnect-Request (where
1261 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
1262 sent unmodified by the NAS to the RADIUS accounting server in the
1263 Accounting Stop packet. If the Disconnect-Request is unsuccessful,
1264 then the Class Attribute is not processed.
1266 (Note 5) When included within a CoA-Request, these attributes
1267 represent an authorization change request. Where tunnel attributes
1268 are included within a successful CoA-Request, all existing tunnel
1269 attributes are removed and replaced by the new attribute(s).
1271 (Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and
1272 Framed-Interface-Id attributes are used for session identification,
1273 renumbering cannot be accomplished by including values of these
1274 attributes within a CoA-Request. Instead, a CoA-Request including a
1275 Service-Type Attribute with a value of "Authorize Only" is sent; new
1276 values can be supplied in an Access-Accept sent in response to the
1277 ensuing Access-Request. Note that renumbering will not be possible
1278 in all situations. For example, in order to change an IP address,
1279 IPCP or IPv6CP re-negotiation could be required, which is not
1280 supported by all PPP implementations.
1282 (Note 7) Within Disconnect-Request packets, Vendor-Specific
1283 Attributes (VSAs) MAY be used for session identification. Within
1284 CoA-Request packets, VSAs MAY be used for either session
1285 identification or authorization change. However, the same Attribute
1286 MUST NOT be used for both purposes simultaneously.
1290 Chiba, et al. Informational [Page 23]
1292 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1295 4. Diameter Considerations
1297 Due to differences in handling change-of-authorization requests in
1298 RADIUS and Diameter, it may be difficult or impossible for a
1299 Diameter/RADIUS gateway to successfully translate a Diameter
1300 Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example,
1301 since a CoA-Request only initiates an authorization change but does
1302 not initiate re-authentication, a RAR command containing a
1303 Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot
1304 be directly translated to a CoA-Request. A Diameter/RADIUS gateway
1305 receiving a CoA-Request containing authorization changes will need to
1306 translate this into two Diameter exchanges. First, the
1307 Diameter/RADIUS gateway will issue a RAR command including a
1308 Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE
1309 ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing
1310 access request with a response including the authorization attributes
1311 gleaned from the CoA-Request. To enable translation, the CoA-Request
1312 SHOULD include a Acct-Session-Id Attribute. If the Diameter client
1313 uses the same Session-Id for both authorization and accounting, then
1314 the Diameter/RADIUS gateway can copy the contents of the Acct-
1315 Session-Id Attribute into the Session-Id AVP; otherwise, it will
1316 need to map the Acct-Session-Id value to an equivalent Session-Id for
1317 use within a RAR command.
1319 Where an Acct-Session-Id Attribute is not present in a CoA-Request or
1320 Disconnect-Request, a Diameter/RADIUS gateway will either need to
1321 determine the appropriate Acct-Session-Id or, if it cannot do so, it
1322 can send a CoA-NAK or Disconnect-NAK in reply, possibly including an
1323 Error-Cause Attribute with a value of 508 (Multiple Session Selection
1326 To simplify translation between RADIUS and Diameter, Dynamic
1327 Authorization Clients can include a Service-Type Attribute with value
1328 "Authorize Only" within a CoA-Request, as described in Section 3.2.
1329 A Diameter/RADIUS gateway receiving a CoA-Request containing a
1330 Service-Type Attribute with a value "Authorize Only" translates this
1331 to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
1332 The received RAA is then translated to a CoA-NAK with a Service-Type
1333 Attribute with value "Authorize Only". If the Result-Code AVP in the
1334 RAA has a value in the success category, then an Error-Cause
1335 Attribute with value "Request Initiated" is included in the CoA-NAK.
1336 If the Result-Code AVP in the RAA has a value indicating a Protocol
1337 Error or a Transient or Permanent Failure, then an alternate Error-
1338 Cause Attribute is returned as suggested below.
1340 Within Diameter, a server can request that a session be aborted by
1341 sending an Abort-Session-Request (ASR), identifying the session to be
1342 terminated using Session-ID and User-Name AVPs. The ASR command is
1346 Chiba, et al. Informational [Page 24]
1348 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1351 translated to a Disconnect-Request containing Acct-Session-Id and
1352 User-Name attributes. If the Diameter client utilizes the same
1353 Session-Id in both authorization and accounting, then the value of
1354 the Session-ID AVP may be placed in the Acct-Session-Id Attribute;
1355 otherwise the value of the Session-ID AVP will need to be mapped to
1356 an appropriate Acct-Session-Id Attribute. To enable translation of a
1357 Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be
1360 If the Diameter client utilizes the same Session-Id in both
1361 authorization and accounting, then the value of the Acct-Session-Id
1362 Attribute may be placed into the Session-ID AVP within the ASR;
1363 otherwise the value of the Acct-Session-Id Attribute will need to be
1364 mapped to an appropriate Session-ID AVP.
1366 An Abort-Session-Answer (ASA) command is sent in response to an ASR
1367 in order to indicate the disposition of the request. A
1368 Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to
1369 an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A
1370 Disconnect-NAK received from the NAS is translated to an ASA command
1371 with a Result-Code AVP that depends on the value of the Error-Cause
1372 Attribute. Suggested translations between Error-Cause Attribute
1373 values and Result-Code AVP values are included below:
1375 # Error-Cause Attribute Value Result-Code AVP
1376 --- --------------------------- ------------------------
1377 201 Residual Session Context DIAMETER_SUCCESS
1379 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
1381 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
1382 402 Missing Attribute DIAMETER_MISSING_AVP
1383 403 NAS Identification DIAMETER_REALM_NOT_SERVED
1385 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
1386 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
1387 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
1388 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE
1389 501 Administratively DIAMETER_AUTHORIZATION_REJECTED
1391 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER
1392 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
1393 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
1395 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
1397 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
1398 507 Request Initiated DIAMETER_SUCCESS
1402 Chiba, et al. Informational [Page 25]
1404 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1407 Since both the ASR/ASA and Disconnect-Request/Disconnect-
1408 NAK/Disconnect-ACK exchanges involve just a request and response,
1409 inclusion of an "Authorize Only" Service-Type within a Disconnect-
1410 Request is not needed to assist in Diameter/RADIUS translation, and
1411 may make translation more difficult. As a result, as noted in
1412 Section 3.2, the Service-Type Attribute MUST NOT be used within a
1415 5. IANA Considerations
1417 This document uses the RADIUS [RFC2865] namespace; see
1418 <http://www.iana.org/assignments/radius-types>. In addition to the
1419 allocations already made in [RFC3575] and [RFC3576], this
1420 specification allocates additional values of the Error-Cause
1425 407 Invalid Attribute Value
1426 508 Multiple Session Selection Unsupported
1428 6. Security Considerations
1430 6.1. Authorization Issues
1432 Where a NAS is shared by multiple providers, it is undesirable for
1433 one provider to be able to send Disconnect-Requests or CoA-Requests
1434 affecting the sessions of another provider.
1436 A Dynamic Authorization Server MUST silently discard Disconnect-
1437 Request or CoA-Request packets from untrusted sources. In situations
1438 where the Dynamic Authorization Client is co-resident with a RADIUS
1439 authentication or accounting server, a proxy MAY perform a "reverse
1440 path forwarding" (RPF) check to verify that a Disconnect-Request or
1441 CoA-Request originates from an authorized Dynamic Authorization
1442 Client. In addition, it SHOULD be possible to explicitly authorize
1443 additional sources of Disconnect-Request or CoA-Request packets
1444 relating to certain classes of sessions. For example, a particular
1445 source can be explicitly authorized to send CoA-Request packets
1446 relating to users within a set of realms.
1448 To perform the RPF check, the Dynamic Authorization Server uses the
1449 session identification attributes included in Disconnect-Request or
1450 CoA-Request packets, in order to determine the RADIUS server(s) to
1451 which an equivalent Access-Request could be routed. If the source
1452 address of the Disconnect-Request or CoA-Request is within this set,
1453 then the CoA-Request or Disconnect-Request is forwarded; otherwise it
1454 MUST be silently discarded.
1458 Chiba, et al. Informational [Page 26]
1460 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1463 Typically, the Dynamic Authorization Server will extract the realm
1464 from the Network Access Identifier [RFC4282] included within the
1465 User-Name or Chargeable-User-Identity Attribute, and determine the
1466 corresponding RADIUS servers in the realm routing tables. If the
1467 Dynamic Authorization Server maintains long-term session state, it
1468 MAY perform the authorization check based on the session
1469 identification attributes in the CoA-Request. The session
1470 identification attributes can be used to tie a session to a
1471 particular proxy or set of proxies, as with the NAI realm.
1473 Where no proxy is present, the RPF check can only be performed by the
1474 NAS if it maintains its own a realm routing table. If the NAS does
1475 not maintain a realm routing table (e.g., it selects forwarding
1476 proxies based on primary/secondary configuration and/or liveness
1477 checks), then an RPF check cannot be performed.
1479 Since authorization to send a Disconnect-Request or CoA-Request is
1480 determined based on the source address and the corresponding shared
1481 secret, the Dynamic Authorization Server SHOULD configure a different
1482 shared secret for each Dynamic Authorization Client.
1484 6.2. IPsec Usage Guidelines
1486 In addition to security vulnerabilities unique to Disconnect or CoA
1487 packets, the protocol exchanges described in this document are
1488 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is
1489 RECOMMENDED that IPsec be employed to afford better security,
1490 utilizing the profile described in [RFC3579], Section 4.2.
1492 For Dynamic Authorization Servers implementing this specification,
1493 the IPsec policy would be "Require IPsec, from any to me, destination
1494 port UDP 3799". This causes the Dynamic Authorization Server to
1495 require use of IPsec. If some Dynamic Authorization Clients do not
1496 support IPsec, then a more granular policy will be required: "Require
1497 IPsec, from IPsec-Capable-DAC to me".
1499 For Dynamic Authorization Clients implementing this specification,
1500 the IPsec policy would be "Initiate IPsec, from me to any,
1501 destination port UDP 3799". This causes the Dynamic Authorization
1502 Client to initiate IPsec when sending Dynamic Authorization traffic
1503 to any Dynamic Authorization Server. If some Dynamic Authorization
1504 Servers contacted by the Dynamic Authorization Client do not support
1505 IPsec, then a more granular policy will be required, such as
1506 "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP
1514 Chiba, et al. Informational [Page 27]
1516 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1519 6.3. Replay Protection
1521 Where IPsec replay protection is not used, an Event-Timestamp (55)
1522 [RFC2869] Attribute SHOULD be included within CoA-Request and
1523 Disconnect-Request packets, and MAY be included within CoA-ACK, CoA-
1524 NAK, Disconnect-ACK, and Disconnect-NAK packets.
1526 When the Event-Timestamp Attribute is present, both the Dynamic
1527 Authorization Server and the Dynamic Authorization Client MUST check
1528 that the Event-Timestamp Attribute is current within an acceptable
1529 time window. If the Event-Timestamp Attribute is not current, then
1530 the packet MUST be silently discarded. This implies the need for
1531 loose time synchronization within the network, which can be achieved
1532 by a variety of means, including Simple Network Time Protocol (SNTP),
1533 as described in [RFC4330]. Implementations SHOULD be configurable to
1534 discard CoA-Request or Disconnect-Request packets not containing an
1535 Event-Timestamp Attribute.
1537 If the Event-Timestamp Attribute is included, it represents the time
1538 at which the original packet was sent, and therefore it SHOULD NOT be
1539 updated when the packet is retransmitted. If the Event-Timestamp
1540 Attribute is not updated, this implies that the Identifier is not
1541 changed in retransmitted packets. As a result, the ability to detect
1542 replay within the time window is dependent on support for duplicate
1543 detection within that same window. As noted in Section 2.3,
1544 duplicate detection is REQUIRED for Dynamic Authorization Servers
1545 implementing this specification.
1547 The time window used for duplicate detection MUST be the same as the
1548 window used to detect a stale Event-Timestamp Attribute. Since the
1549 RADIUS Identifier cannot be repeated within the selected time window,
1550 no more than 256 Requests can be accepted within the time window. As
1551 a result, the chosen time window will depend on the expected maximum
1552 volume of CoA/Disconnect-Requests, so that unnecessary discards can
1553 be avoided. A default time window of 300 seconds should be adequate
1554 in many circumstances.
1558 Disconnect Request with User-Name:
1560 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
1561 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
1570 Chiba, et al. Informational [Page 28]
1572 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1575 Disconnect Request with Acct-Session-ID:
1577 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
1578 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
1579 32: 3930 3233 3435 3637 90234567
1581 Disconnect Request with Framed-IP-Address:
1583 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
1584 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
1589 8.1. Normative References
1591 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1595 Requirement Levels", RFC 2119, March 1997.
1597 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
1598 "Remote Authentication Dial In User Service (RADIUS)",
1599 RFC 2865, June 2000.
1601 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1603 [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS
1604 Extensions", RFC 2869, June 2000.
1606 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
1609 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575,
1612 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
1613 Authentication Protocol (EAP)", RFC 3579, September 2003.
1615 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
1616 Network Access Identifier", RFC 4282, December 2005.
1626 Chiba, et al. Informational [Page 29]
1628 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1631 8.2. Informative References
1633 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack",
1634 CryptoBytes Vol.2 No.2, Summer 1996.
1636 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
1637 M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
1638 Support", RFC 2868, June 2000.
1640 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization
1641 and Accounting Transport Profile", RFC 3539, June 2003.
1643 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
1644 Aboba, "Dynamic Authorization Extensions to Remote
1645 Authentication Dial In User Service (RADIUS)", RFC 3576,
1648 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
1649 Arkko, "Diameter Base Protocol", RFC 3588, September
1652 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
1653 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
1655 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
1656 "Chargeable User Identity", RFC 4372, January 2006.
1658 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes
1659 for Virtual LAN and Priority Support", RFC 4675,
1662 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
1663 Attribute", RFC 4818, April 2007.
1665 [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter
1666 Rule Attribute", RFC 4849, April 2007.
1670 This protocol was first developed and distributed by Ascend
1671 Communications. Example code was distributed in their free server
1674 The authors would like to acknowledge valuable suggestions and
1675 feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark
1676 Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore,
1677 Russ Housley, Joe Salowey, Alan DeKok, and David Nelson.
1682 Chiba, et al. Informational [Page 30]
1684 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1687 Appendix A. Changes from RFC 3576
1689 This Appendix lists the major changes between [RFC3576] and this
1690 document. Minor changes, including style, grammar, spelling, and
1691 editorial changes, are not mentioned here.
1693 o The term "Dynamic Authorization Client" is used instead of RADIUS
1694 server where it applies to the originator of CoA-Request and
1695 Disconnect-Request packets. The term "Dynamic Authorization Server"
1696 is used instead of NAS where it applies to the receiver of CoA-
1697 Request and Disconnect-Request packets. Definitions of these terms
1698 have been added (Section 1.3).
1700 o Added requirement for duplicate detection on the Dynamic
1701 Authorization Server (Section 2.3).
1703 o Clarified expected behavior when session identification attributes
1704 match more than one session (Sections 2.3, 3, 3.5, 4).
1706 o Added Chargeable-User-Identity as a session identification
1707 attribute. Removed NAS-Port-Type as a session identification
1708 attribute (Section 3).
1710 o Added recommendation that an Acct-Session-Id or Acct-Multi-
1711 Session-Id Attribute be included in an Access-Request (Section 3).
1713 o Added discussion of scenarios in which the "Dynamic Authorization
1714 Client" and RADIUS server are not co-located (Section 3).
1716 o Added details relating to handling of the Proxy-State Attribute
1719 o Added clarification that support for a Service-Type Attribute with
1720 value "Authorize Only" is optional on both the NAS and Dynamic
1721 Authorization Client (Section 3.2). Use of the Service-Type
1722 Attribute within a Disconnect-Request is prohibited (Sections 3.2,
1725 o Added requirement for inclusion of the State Attribute in CoA-
1726 Request packets including a Service-Type Attribute with a value of
1727 "Authorize Only" (Section 3.3).
1729 o Added clarification on the calculation of the Message-
1730 Authenticator Attribute (Section 3.4).
1732 o Additional Error-Cause Attribute values are allocated for Invalid
1733 Attribute Value (407) and Multiple Session Selection
1734 Identification (508) (Sections 3.5, 4).
1738 Chiba, et al. Informational [Page 31]
1740 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1743 o Updated the CoA-Request Attribute Table to include Filter-Rule,
1744 Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-
1745 VLAN-Name, and User-Priority attributes (Section 3.6).
1747 o Added the Chargeable-User-Identity Attribute to both the CoA-
1748 Request and Disconnect-Request Attribute table (Section 3.6).
1750 o Use of Vendor-Specific Attributes (VSAs) for session
1751 identification and authorization change has been clarified
1754 o Added Note 6 on the use of the CoA-Request for renumbering, and
1755 Note 7 on the use of Vendor-Specific attributes (Section 3.6).
1757 o Added Diameter Considerations (Section 4).
1759 o Event-Timestamp Attribute should not be recalculated on
1760 retransmission. The implications for replay and duplicate
1761 detection are discussed (Section 6.3).
1763 o Operation of the Reverse Path Forwarding (RPF) check has been
1764 clarified. Use of the RPF check is optional rather than
1765 recommended by default (Section 6.1).
1767 o Text on impersonation (included in [RFC3579], Section 4.3.7) and
1768 IPsec operation (included in [RFC3579], Section 4.2) has been
1769 removed, and is now referenced.
1794 Chiba, et al. Informational [Page 32]
1796 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1806 EMail: mchiba@cisco.com
1807 Phone: +1 408 525 7198
1815 EMail: gdommety@cisco.com
1816 Phone: +1 408 525 1404
1824 EMail: meklund@cisco.com
1825 Phone: +1 865 671 6255
1829 RSA, Security Division of EMC
1830 174 Middlesex Turnpike
1833 EMail: david@mitton.com
1837 Microsoft Corporation
1841 EMail: bernarda@microsoft.com
1842 Phone: +1 425 706 6605
1843 Fax: +1 425 936 7329
1850 Chiba, et al. Informational [Page 33]
1852 RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
1855 Full Copyright Statement
1857 Copyright (C) The IETF Trust (2008).
1859 This document is subject to the rights, licenses and restrictions
1860 contained in BCP 78, and except as set forth therein, the authors
1861 retain all their rights.
1863 This document and the information contained herein are provided on an
1864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1866 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1867 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1868 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1871 Intellectual Property
1873 The IETF takes no position regarding the validity or scope of any
1874 Intellectual Property Rights or other rights that might be claimed to
1875 pertain to the implementation or use of the technology described in
1876 this document or the extent to which any license under such rights
1877 might or might not be available; nor does it represent that it has
1878 made any independent effort to identify any such rights. Information
1879 on the procedures with respect to rights in RFC documents can be
1880 found in BCP 78 and BCP 79.
1882 Copies of IPR disclosures made to the IETF Secretariat and any
1883 assurances of licenses to be made available, or the result of an
1884 attempt made to obtain a general license or permission for the use of
1885 such proprietary rights by implementers or users of this
1886 specification can be obtained from the IETF on-line IPR repository at
1887 http://www.ietf.org/ipr.
1889 The IETF invites any interested party to bring to its attention any
1890 copyrights, patents or patent applications, or other proprietary
1891 rights that may cover technology that may be required to implement
1892 this standard. Please address the information to the IETF at
1906 Chiba, et al. Informational [Page 34]
projects / freeradius.git / blob