📄 rfc5176.txt
字号:
0+ 0 0 18 Reply-Message (Note 2) 0 0 0 24 State 0+ 0 0 25 Class (Note 4) 0+ 0 0 26 Vendor-Specific (Note 7) 0-1 0 0 30 Called-Station-Id (Note 1) 0-1 0 0 31 Calling-Station-Id (Note 1) 0-1 0 0 32 NAS-Identifier (Note 1) 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 44 Acct-Session-Id (Note 1) 0-1 0-1 0 49 Acct-Terminate-Cause 0-1 0 0 50 Acct-Multi-Session-Id (Note 1) 0-1 0-1 0-1 55 Event-Timestamp 0 0 0 61 NAS-Port-Type 0+ 0-1 0 79 EAP-Message (Note 2) 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 87 NAS-Port-Id (Note 1) 0-1 0 0 89 Chargeable-User-Identity (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 0 0 96 Framed-Interface-Id (Note 1) 0 0 0 97 Framed-IPv6-Prefix (Note 1) 0 0 0+ 101 Error-Cause Request ACK NAK # Attribute The following defines the meaning of the above table entries: 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.Chiba, et al. Informational [Page 22] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). (Note 2) The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where Extension Authentication Protocol (EAP) is used for authentication, an EAP- Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK packets contain an EAP- Message/Notification-Response Attribute. (Note 3) When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing values of the same attribute(s). (Note 4) When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the NAS to the RADIUS accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed. (Note 5) When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attributes are included within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s). (Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and Framed-Interface-Id attributes are used for session identification, renumbering cannot be accomplished by including values of these attributes within a CoA-Request. Instead, a CoA-Request including a Service-Type Attribute with a value of "Authorize Only" is sent; new values can be supplied in an Access-Accept sent in response to the ensuing Access-Request. Note that renumbering will not be possible in all situations. For example, in order to change an IP address, IPCP or IPv6CP re-negotiation could be required, which is not supported by all PPP implementations. (Note 7) Within Disconnect-Request packets, Vendor-Specific Attributes (VSAs) MAY be used for session identification. Within CoA-Request packets, VSAs MAY be used for either session identification or authorization change. However, the same Attribute MUST NOT be used for both purposes simultaneously.Chiba, et al. Informational [Page 23] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20084. Diameter Considerations Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, since a CoA-Request only initiates an authorization change but does not initiate re-authentication, a RAR command containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be directly translated to a CoA-Request. A Diameter/RADIUS gateway receiving a CoA-Request containing authorization changes will need to translate this into two Diameter exchanges. First, the Diameter/RADIUS gateway will issue a RAR command including a Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing access request with a response including the authorization attributes gleaned from the CoA-Request. To enable translation, the CoA-Request SHOULD include a Acct-Session-Id Attribute. If the Diameter client uses the same Session-Id for both authorization and accounting, then the Diameter/RADIUS gateway can copy the contents of the Acct- Session-Id Attribute into the Session-Id AVP; otherwise, it will need to map the Acct-Session-Id value to an equivalent Session-Id for use within a RAR command. Where an Acct-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, a Diameter/RADIUS gateway will either need to determine the appropriate Acct-Session-Id or, if it cannot do so, it can send a CoA-NAK or Disconnect-NAK in reply, possibly including an Error-Cause Attribute with a value of 508 (Multiple Session Selection Unsupported). To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request, as described in Section 3.2. A Diameter/RADIUS gateway receiving a CoA-Request containing a Service-Type Attribute with a value "Authorize Only" translates this to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The received RAA is then translated to a CoA-NAK with a Service-Type Attribute with value "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, then an Error-Cause Attribute with value "Request Initiated" is included in the CoA-NAK. If the Result-Code AVP in the RAA has a value indicating a Protocol Error or a Transient or Permanent Failure, then an alternate Error- Cause Attribute is returned as suggested below. Within Diameter, a server can request that a session be aborted by sending an Abort-Session-Request (ASR), identifying the session to be terminated using Session-ID and User-Name AVPs. The ASR command isChiba, et al. Informational [Page 24] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 translated to a Disconnect-Request containing Acct-Session-Id and User-Name attributes. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Session-ID AVP may be placed in the Acct-Session-Id Attribute; otherwise the value of the Session-ID AVP will need to be mapped to an appropriate Acct-Session-Id Attribute. To enable translation of a Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be present. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Acct-Session-Id Attribute may be placed into the Session-ID AVP within the ASR; otherwise the value of the Acct-Session-Id Attribute will need to be mapped to an appropriate Session-ID AVP. An Abort-Session-Answer (ASA) command is sent in response to an ASR in order to indicate the disposition of the request. A Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A Disconnect-NAK received from the NAS is translated to an ASA command with a Result-Code AVP that depends on the value of the Error-Cause Attribute. Suggested translations between Error-Cause Attribute values and Result-Code AVP values are included below: # Error-Cause Attribute Value Result-Code AVP --- --------------------------- ------------------------ 201 Residual Session Context DIAMETER_SUCCESS Removed 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS (Ignored) 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 402 Missing Attribute DIAMETER_MISSING_AVP 403 NAS Identification DIAMETER_REALM_NOT_SERVED Mismatch 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE 501 Administratively DIAMETER_AUTHORIZATION_REJECTED Prohibited 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED Removable 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY Error 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 507 Request Initiated DIAMETER_SUCCESSChiba, et al. Informational [Page 25] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Since both the ASR/ASA and Disconnect-Request/Disconnect- NAK/Disconnect-ACK exchanges involve just a request and response, inclusion of an "Authorize Only" Service-Type within a Disconnect- Request is not needed to assist in Diameter/RADIUS translation, and may make translation more difficult. As a result, as noted in Section 3.2, the Service-Type Attribute MUST NOT be used within a Disconnect-Request.5. IANA Considerations This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. In addition to the allocations already made in [RFC3575] and [RFC3576], this specification allocates additional values of the Error-Cause Attribute (101): # Value --- ----- 407 Invalid Attribute Value 508 Multiple Session Selection Unsupported6. Security Considerations6.1. Authorization Issues Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Requests or CoA-Requests affecting the sessions of another provider. A Dynamic Authorization Server MUST silently discard Disconnect- Request or CoA-Request packets from untrusted sources. In situations where the Dynamic Authorization Client is co-resident with a RADIUS authentication or accounting server, a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request packets relating to users within a set of realms. To perform the RPF check, the Dynamic Authorization Server uses the session identification attributes included in Disconnect-Request or CoA-Request packets, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the CoA-Request or Disconnect-Request is forwarded; otherwise it MUST be silently discarded.Chiba, et al. Informational [Page 26] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables. If the Dynamic Authorization Server maintains long-term session state, it MAY perform the authorization check based on the session identification attributes in the CoA-Request. The session identification attributes can be used to tie a session to a particular proxy or set of proxies, as with the NAI realm. Where no proxy is present, the RPF check can only be performed by the NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g., it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed. Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client.6.2. IPsec Usage Guidelines In addition to security vulnerabilities unique to Disconnect or CoA packets, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security, utilizing the profile described in [RFC3579], Section 4.2. For Dynamic Authorization Servers implementing this s⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -