RFC 3576
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) 🎀
okay bestie, this is RFC 3576 🦋 It's from the Network Working Group and it came out in July 2003. It's marked as Informational, so it's not a standards-track spec. The title is Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). Five people wrote it: M. Chiba and G. Dommety, M. Eklund (Cisco Systems, Inc.), D. Mitton (Circular Logic, UnLtd.), and B. Aboba (Microsoft Corporation). The header doesn't list any document it obsoletes or updates. 💅
Status of this Memo ✨
this memo is giving "here's some info for the internet community" 📚 It is not a standard of any kind. Distribution is unlimited, so go share it 💜
Copyright Notice 📜
the Internet Society owns the copyright (2003) and all rights are reserved 🔒
Abstract 🌸
this doc describes an extension to RADIUS that's already out in the wild in network access server products. It lets things change while a user is already connected 🔥 That means kicking users off and changing what they're allowed to do during their session. It's giving main character energy 👑
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 301. Introduction ✨
okay so RADIUS, which is defined in [RFC2865], doesn't support unsolicited messages from the RADIUS server to the Network Access Server (NAS) 🙈 The server can't just show up and start a conversation.
but honestly, people really want to change session stuff without making the NAS start the exchange. Like, an admin might need to end a user's session while it's happening 💀 Or if a user's authorization level changes, their authorization attributes might need to be added or removed from the session.
so several vendors built extra RADIUS commands to allow those unsolicited messages from the server to the NAS 🔥 These commands cover Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages end a user session immediately, and CoA messages change session authorization attributes, like data filters 💖
1.1. Applicability 🎯
this protocol is being recommended as an Informational RFC instead of a standards-track one 💅 The reason is that some problems can't be fixed without breaking compatibility with the implementations that are already deployed. That includes security vulnerabilities, plus semantic ambiguities that come from how the CoA commands were designed 😭 Fixes are recommended, but they can't be made mandatory, because that would break existing implementations.
ngl, the existing implementations don't do authorization checks. So an ISP sharing a NAS with another ISP could disconnect or change authorizations for the other ISP's users 💀 To fix that, a "Reverse Path Forwarding" check is recommended. See Section 5.1. for the details 🌈
existing implementations also use per-packet authentication and integrity protection algorithms that have known weaknesses [MD5Attack] 🙅♀️ For stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 5.3. for the details 🔐
then there's replay protection, which the existing implementations don't have. To support replay detection, it is recommended that the Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. Implementations should be configurable to silently discard messages that lack the Event-Timestamp Attribute 🫶 See Section 5.4. for the details 🧚
here's the CoA semantic mess. Existing CoA-Request implementations identify the affected session and supply the authorization changes. Since the RADIUS Attributes in those requests can be used for either session identification or authorization change, it may not be clear which job a given attribute is doing 🤯
Diameter [Diameter] doesn't have this problem 💅 In Diameter, an authorization change is requested by a command that uses Attribute Value Pairs (AVPs) only for identification. That kicks off a standard Request/Response sequence where the authorization changes are supplied. So in no Diameter command can an AVP have multiple potential meanings ✨
because RADIUS and Diameter handle change-of-authorization requests differently, a Diameter/RADIUS gateway may have a hard time (or be totally unable to) translate existing implementations of this spec into Diameter messages 😩 For example, a Diameter command that changes any attribute used for identification in existing CoA-Request implementations can't be translated, since that authorization change is impossible to carry out in existing implementations. Translating existing Disconnect-Request or CoA-Request messages into Diameter is also tricky, because a Disconnect- Request or CoA-Request message will need to be translated into multiple Diameter commands 🌸
to make translation between RADIUS and Diameter easier, a Service-Type Attribute with the value "Authorize Only" can (optionally) be included in a Disconnect-Request or CoA-Request 🦋 That kind of Request contains only identification attributes. A NAS that supports the "Authorize Only" Service-Type responds with a NAK containing a Service-Type Attribute with the value "Authorize Only" and an Error-Cause Attribute with the value "Request Initiated". The NAS then sends an Access-Request containing a Service-Type Attribute with the value "Authorize Only". This is basically what happens in Diameter, so a Diameter/RADIUS gateway can translate it more easily 🔥
1.2. Requirements Language 📜
in this document, a few words are used to signal the requirements of the spec 🎀 They're often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜
1.3. Terminology 🧚
this doc uses the following terms a lot:
Network Access Server (NAS): The device providing access to the
network.
service: The NAS provides a service to the user,
such as IEEE 802 or PPP.
session: Each service provided by the NAS to a
user constitutes a session, with the
beginning of the session defined as the
point where service is first provided
and the end of the session defined as
the point where service is ended. A
user may have multiple sessions in
parallel or series if the NAS supports
that.
silently discard: This means the implementation discards
the packet without further processing.
The implementation SHOULD provide the
capability of logging the error,
including the contents of the silently
discarded packet, and SHOULD record the
event in a statistics counter.2. Overview 🦋
this section covers the most commonly implemented features of Disconnect and Change-of-Authorization messages 💖
2.1. Disconnect Messages (DM) 💜
a Disconnect-Request packet is sent by the RADIUS server to end a user session on a NAS and throw away all of its associated session context 💀 The packet goes to UDP port 3799. It identifies both the NAS and the user session that should end, using the identification attributes described in Section 3 🎯
+----------+ Disconnect-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+the NAS answers a Disconnect-Request from the RADIUS server with either a Disconnect-ACK, if all the associated session context was discarded and the user session is no longer connected, or a Disconnect-NAK, if the NAS couldn't disconnect the session and discard all of its associated session context 🙃 A NAS MUST respond to a Disconnect-Request that includes a Service-Type Attribute with the value "Authorize Only" with a Disconnect-NAK, and a Disconnect-ACK MUST NOT be sent 🚫 A NAS MUST respond to a Disconnect-Request that includes a Service-Type Attribute with an unsupported value with a Disconnect-NAK. An Error-Cause Attribute with the value "Unsupported Service" MAY be included 🌈 A Disconnect-ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for Admin-Reset ✨
2.2. Change-of-Authorization Messages (CoA) 🦋
okay so CoA-Request packets carry info for changing session authorizations on the fly ✨ this is usually how you swap out data filters. The filters can be ingress or egress kind, and they get sent alongside the identification attributes (more on those in section 3) 💅 The port and packet format (see Section 2.3.) are the same as for Disconnect-Request messages, so it's giving consistency 🫶
The following attribute MAY be sent in a CoA-Request:
Filter-ID (11): names a data filter list to be applied to the session that the identification attributes map to 🌸
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+So the NAS answers a CoA-Request from the RADIUS server with a CoA-ACK if it manages to change the user session's authorizations, or a CoA-NAK if the Request didn't work out 💀 A NAS MUST respond to a CoA-Request that includes a Service-Type Attribute set to "Authorize Only" with a CoA-NAK, and a CoA-ACK MUST NOT be sent 🙅 A NAS MUST also respond to a CoA-Request with a Service-Type Attribute holding an unsupported value with a CoA-NAK. An Error-Cause Attribute with value "Unsupported Service" MAY be included there 🎀
2.3. Packet Format 🎀
okay this part is the nitty-gritty 🤓 For either Disconnect-Request or CoA-Request messages, UDP port 3799 is the destination port. For responses, the source and destination ports get reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field 💖
Here's a quick summary of the data format, with fields transmitted left to right ✨
The packet format is made up of Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format. All of these fields mean the same thing they do in RADIUS [RFC2865]. The Authenticator field MUST be calculated the same way as specified for an Accounting-Request in [RFC2866] 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code 🔢
The Code field is one octet and tells you what type of RADIUS packet you're looking at. Packets received with an invalid Code field MUST be silently discarded 🙈 The RADIUS codes (decimal) for this extension are assigned as follows:
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]Identifier 🪪
The Identifier field is one octet, and it helps match requests with replies. The RADIUS client can spot a duplicate request if it has the same server source IP address, source UDP port, and Identifier within a short span of time 👀
Unlike RADIUS as defined in [RFC2865], the responsibility for retransmitting Disconnect-Request and CoA-Request messages lies with the RADIUS server. If the RADIUS server doesn't receive a response after sending these messages, it will retransmit 🔁
The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged 💜
If the RADIUS server is retransmitting a Disconnect-Request or CoA-Request to the same client as before, and the Attributes haven't changed, the same Request Authenticator, Identifier, and source port MUST be used. If any Attributes have changed, a new Authenticator and Identifier MUST be used 🧩
Note that if the Event-Timestamp Attribute is included, it gets updated when the packet is retransmitted. That changes the content of the Attributes field and means you need a new Identifier and Request Authenticator ⏰
If the Request to a primary proxy fails, a secondary proxy must be queried, if available. Issues relating to failover algorithms are described in [AAATransport]. Since this counts as a new request, a new Request Authenticator and Identifier MUST be used. However, where the RADIUS server is sending directly to the client, failover typically does not make sense, since Disconnect or CoA messages need to be delivered to the NAS where the session resides 🏠
Length 📏
The Length field is two octets. It indicates the length of the packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and the maximum length is 4096 🌈
Authenticator 🔐
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the messages between the RADIUS server and client 🦋
Request Authenticator 📝
In Request packets, the Authenticator value is a 16 octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting-Request, as specified in [RFC2866] ✨
Note that the Request Authenticator of a Disconnect or CoA-Request can't be done the same way as the Request Authenticator of a RADIUS Access-Request, because there's no User-Password Attribute in a Disconnect-Request or CoA-Request 🙅♀️
Response Authenticator 🎁
The Authenticator field in a Response packet (e.g. Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator. It holds a one-way MD5 hash calculated over a stream of octets: the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response Attributes if there are any, followed by the shared secret. The resulting 16 octet MD5 hash value gets stored in the Authenticator field of the Response packet 🔒
Administrative note: as noted in [RFC2865] Section 3, the secret (the password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. RADIUS clients MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied 🛡️
Attributes 🧾
In Disconnect and CoA-Request messages, all Attributes are treated as mandatory. A NAS MUST respond to a CoA-Request containing one or more unsupported Attributes or Attribute values with a CoA-NAK. A Disconnect-Request containing one or more unsupported Attributes or Attribute values MUST be answered with a Disconnect-NAK 🚫
State changes resulting from a CoA-Request MUST be atomic 💅 If the Request is successful, a CoA-ACK is sent and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful, a CoA-NAK MUST be sent and the requested authorization changes MUST NOT be made. Similarly, a state change MUST NOT occur as a result of an unsuccessful Disconnect-Request. Here, a Disconnect-NAK MUST be sent 🌸
Since within this specification attributes may be used for identification, authorization, or other purposes, even if a NAS implements an attribute for use with RADIUS authentication and accounting, it may not support including that attribute within Disconnect-Request or CoA-Request messages, given the difference in attribute semantics. This is true even for attributes specified within [RFC2865], [RFC2868], [RFC2869], or [RFC3162] as allowable within Access-Accept messages 🤯
As a result, attributes beyond those specified in Section 3.2. SHOULD NOT be included within Disconnect or CoA messages, since this could produce unpredictable results. Yikes, unpredictable results are not the vibe 😭
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute. When the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions can be made about its location within the list of Attributes 🧐 Since Disconnect and CoA responses are authenticated on the entire packet contents, stripping the Proxy-State Attribute invalidates the integrity check, so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet 🫧
If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy MUST include those Proxy-State Attributes in its response to the server. The forwarding proxy MAY include the Proxy-State Attributes in the Disconnect-Request or CoA-Request when it forwards the request, or it MAY omit them in the forwarded request. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it to the server 💖
3. Attributes ✨
okay so this section is where the NAS and the session get to be introduced to each other 💅 In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS 🖥️ as well as a user session on that NAS 🎀. All NAS identification attributes included in a Request message MUST match for a Disconnect-Request or CoA-Request to be successful. If they don't, a Disconnect-NAK or CoA-NAK SHOULD be sent 🙈
For session identification attributes, the User-Name and Acct-Session-Id Attributes MUST match if they're included. Other session identification attributes SHOULD match. If a mismatch of session identification attributes shows up, a Disconnect-NAK or CoA-NAK SHOULD be sent. Using NAS or session identification attributes to map to unique or multiple sessions is beyond the scope of this document, so we're not going there today 🧚 The identification attributes include NAS and session identification attributes, as described below.
NAS identification attributes
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.To cover the security concerns in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets, and one or more additional session identification attributes MAY also be there 🔐 To cover the security concerns in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets. The NAS-Identifier Attribute MAY be present in addition 💖
If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute-values is unsupported, a CoA-NAK MUST be sent. Same deal for a Disconnect-Request: if there are one or more unsupported attributes or attribute values in it, a Disconnect-NAK MUST be sent 🚫
Now the "Authorize Only" rule, which is giving strict vibes 👑 Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included. Only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA-Request, implementations MUST send a CoA-NAK, and an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK, and an Error-Cause Attribute with value "Unsupported Attribute" MAY be included 🌸
3.1. Error-Cause
Description
It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason 😭 That's where the Error-Cause Attribute comes in, giving more detail on what went wrong. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages.
Here's the Error-Cause Attribute format. The fields are transmitted from left to right 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
101 for Error-Cause
Length
6
Value
The Value field is four octets, holding an integer that specifies the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so these values may only be sent within a Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK ✨ Values 400-499 represent fatal errors committed by the RADIUS server, so they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server 📝 The Error-Code values (expressed in decimal) include:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request InitiatedLet's go through each one, bestie 🫶
"Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK 🧹
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification. Lowkey a plot twist, but it's still on the list 🙃
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported 🚨
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request 🕵️
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request 🪞
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as one or more attributes (such as EAP-Message Attribute(s)) not being formatted properly 💀
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request has an invalid or unsupported value 🎭
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy that receives an ICMP port unreachable message after attempting to forward a Request to the NAS 📡
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session 🚧
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can happen if the required entries are not present in the proxy's realm routing table 🗺️
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS 🔍
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK 🔒
"Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing 🛠️
"Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.) 🧠
"Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server 🚀
3.2. Table of Attributes ✨
okay bestie, this table is basically the cheat sheet 📝💅 It tells you which attributes can show up in which packets, and how many of each you're allowed to send. Let's go 🦋
Change-of-Authorization Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 7 Framed-Protocol [Note 3]
0-1 0 0 8 Framed-IP-Address [Note 1]
0-1 0 0 9 Framed-IP-Netmask [Note 3]
0-1 0 0 10 Framed-Routing [Note 3]
0+ 0 0 11 Filter-ID [Note 3]
0-1 0 0 12 Framed-MTU [Note 3]
0+ 0 0 13 Framed-Compression [Note 3]
0+ 0 0 14 Login-IP-Host [Note 3]
0-1 0 0 15 Login-Service [Note 3]
0-1 0 0 16 Login-TCP-Port [Note 3]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0 0 19 Callback-Number [Note 3]
0-1 0 0 20 Callback-Id [Note 3]
0+ 0 0 22 Framed-Route [Note 3]
0-1 0 0 23 Framed-IPX-Network [Note 3]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 3]
0+ 0 0 26 Vendor-Specific [Note 3]
0-1 0 0 27 Session-Timeout [Note 3]
0-1 0 0 28 Idle-Timeout [Note 3]
0-1 0 0 29 Termination-Action [Note 3]
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service [Note 3]
0-1 0 0 35 Login-LAT-Node [Note 3]
0-1 0 0 36 Login-LAT-Group [Note 3]
0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 62 Port-Limit [Note 3]
0-1 0 0 63 Login-LAT-Port [Note 3]
0+ 0 0 64 Tunnel-Type [Note 5]
0+ 0 0 65 Tunnel-Medium-Type [Note 5]
0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
0+ 0 0 69 Tunnel-Password [Note 5]
0-1 0 0 71 ARAP-Features [Note 3]
0-1 0 0 72 ARAP-Zone-Access [Note 3]
0+ 0 0 78 Configuration-Token [Note 3]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
0+ 0 0 83 Tunnel-Preference [Note 5]
0-1 0 0 85 Acct-Interim-Interval [Note 3]
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 88 Framed-Pool [Note 3]
0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0+ 0 0 98 Login-IPv6-Host [Note 3]
0+ 0 0 99 Framed-IPv6-Route [Note 3]
0-1 0 0 100 Framed-IPv6-Pool [Note 3]
0 0 0+ 101 Error-Cause
Request ACK NAK # Attribute
Disconnect Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 8 Framed-IP-Address [Note 1]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 4]
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0 0+ 0+ 101 Error-Cause
Request ACK NAK # AttributeNow the notes, which are where the real drama is 🎀
[Note 1] Okay so, if a NAS or session identification attribute shows up in a Disconnect-Request or CoA-Request, it's only there to say who or which session 🪪 It's strictly for identification. These attributes MUST NOT be used for anything else, like sneaking in an authorization change inside a CoA-Request 🙅♀️ no cap, that's a hard boundary 🔒
[Note 2] The Reply-Message attribute is how you show a little message to the user 💌 It only gets displayed if the Disconnect-Request or CoA-Request was successful, meaning a Disconnect-ACK or CoA-ACK gets sent after. If EAP is being used for authentication, you send an EAP-Message/Notification-Request attribute instead, and then the Disconnect-ACK or CoA-ACK comes back carrying an EAP-Message/Notification-Response attribute 🦋
[Note 3] When these attributes are in a CoA-Request, they're basically asking for an authorization change 💅 If one of them gets left out, the NAS assumes that value stays exactly the same ✨ And whatever you do include replaces all the existing values of that same attribute, so no sneaky leftovers 🧹
[Note 4] If the Disconnect-Request works and a Disconnect-ACK goes out, the Class attribute SHOULD be passed along unmodified by the client to the accounting server in the Accounting Stop packet 📦 If the Disconnect-Request doesn't work out, then the Class attribute isn't processed at all 🙈
[Note 5] Same vibe as Note 3: inside a CoA-Request, these tunnel attributes are an authorization change request 🚇 And if tunnel attributes get sent in a successful CoA-Request, all the existing tunnel attributes are wiped and replaced by the new ones 🫧
[Note 6] This one is giving Diameter energy 🌈 When a Disconnect-Request or CoA-Request has a Service-Type attribute with the value "Authorize Only", it means the request only has NAS and session identification attributes in it. The NAS should then try reauthorization by sending an Access-Request with a Service-Type attribute of "Authorize Only" 🔁 The whole point is to make things easier to translate between the two protocols 🤝 Supporting Service-Type is optional inside CoA-Request and Disconnect-Request messages. If it's not included, the Request can have both identification and authorization attributes together 🧁 A NAS that doesn't support the "Authorize Only" value inside a Disconnect-Request MUST respond with a Disconnect-NAK that has no Service-Type attribute in it, and it MAY include an Error-Cause attribute with the value "Unsupported Service" 🙅♀️ Same deal for a CoA-Request: that NAS MUST respond with a CoA-NAK with no Service-Type attribute, and it MAY include an Error-Cause attribute with the value "Unsupported Service" 💀
A NAS that DOES support the "Authorize Only" value inside Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK (respectively) that contains a Service-Type attribute with the value "Authorize Only", plus an Error-Cause attribute with the value "Request Initiated" 🎉 Then the NAS sends an Access-Request to the RADIUS server with a Service-Type attribute of "Authorize Only" 📨 That Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, along with the session attributes from the Request that are legal to include in an Access-Request, as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162] 📚 As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that doesn't contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message attribute 🔐 The RADIUS server should send back an Access-Accept to (re-)authorize the session, or an Access-Reject to refuse to (re-)authorize it 🫶
[Note 7] The State attribute is something the RADIUS server can send to the NAS in a Disconnect-Request or CoA-Request 🧩 The NAS MUST send it back unmodified to the RADIUS server in a subsequent ACK or NAK message 🔁 If a Service-Type attribute with the value "Authorize Only" comes along with a State attribute in a Disconnect-Request or CoA-Request, then the State attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request, if there is one 📬 The RADIUS server can also send a State attribute to the NAS in a CoA-Request that also has a Termination-Action attribute with the value RADIUS-Request 🚪 If the client carries out the Termination-Action by sending a new Access-Request when the current session ends, it MUST include the State attribute unchanged in that Access-Request 🫡 In either usage, the client MUST NOT interpret the attribute locally 🙅♀️ A Disconnect-Request or CoA-Request packet must have only zero or one State attribute 🔢 How you use the State attribute is implementation dependent 🛠️ And if the RADIUS server doesn't recognize the State attribute in the Access-Request, then it MUST send an Access-Reject ❌
Last bit: here's the legend that decodes all those 0, 0+, 0-1 and 1 entries 🧚
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
1 Exactly one instance of this attribute MUST be present in packet.4. IANA Considerations ✨
Okay bestie, IANA stuff time 🧚. This document uses the RADIUS [RFC2865] namespace, which lives at http://www.iana.org/assignments/radius-types 🌸. There are six updates for the section called RADIUS Packet Type Codes, and these Packet Types get allocated in [RADIANA] 💜:
40- Disconnect-Request41- Disconnect-ACK42- Disconnect-NAK43- CoA-Request44- CoA-ACK45- CoA-NAK
Next up, a new Service-Type value for "Authorize Only" is being requested 🎀. This document also uses the UDP [RFC768] namespace, found at http://www.iana.org/assignments/port-numbers 🦋. The authors are asking for a port assignment from the Registered ports range 🫶. Last but not least, this specification allocates the Error-Cause Attribute (101) with these decimal values. Literally so many codes 💀:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated5. Security Considerations 🔐
Okay this section is SERIOUS, so pay attention 👀. Everything here is about who gets to do what, and getting it wrong is a whole disaster 😭.
5.1. Authorization Issues
Picture a NAS that's shared by multiple providers. It's really not okay for one provider to be able to send Disconnect-Request or CoA-Request messages that mess with another provider's sessions 🙅♀️.
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources 🚫. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request actually comes from an authorized RADIUS server 🕵️♀️. On top of that, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets for certain classes of sessions 💅. For example, a particular source can be explicitly authorized to send CoA-Request messages for users within a set of realms 👑.
So here's how the RPF check goes 🧠. The proxy uses the session identification attributes that are included in Disconnect-Request or CoA-Request messages, so it can figure out which RADIUS server(s) an equivalent Access-Request could be routed to. If the source address of the Disconnect-Request or CoA-Request is inside that set, then the Request is forwarded. Otherwise it MUST be silently discarded 🗑️.
Typically the proxy pulls the realm out of the Network Access Identifier [RFC2486] that's included in the User-Name Attribute, then looks up the matching RADIUS servers in its proxy routing tables 🗺️. Those RADIUS servers for that realm are then compared against the source address of the packet. And if there's no RADIUS proxy around, the NAS itself is going to have to do the RPF check 🫠.
Since being allowed to send a Disconnect-Request or CoA-Request is decided by the source address and the matching shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server 🔑. Main character security energy 💖.
5.2. Impersonation
Let's talk about the drama 🎭. [RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
When RADIUS requests get forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address the RADIUS server sees 🙈. Also, since the NAS-Identifier Attribute doesn't need to contain an FQDN, that attribute might not be resolvable to the source address the RADIUS server observed, even when there's no proxy at all 🤷♀️.
So the authenticity check that a RADIUS server or proxy does does NOT verify that the NAS identification attributes are correct 😬. This makes it possible for a rogue NAS to forge the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier Attributes inside a RADIUS Access-Request, so it can pretend to be some other NAS 👻. It's also possible for a rogue NAS to forge session identification attributes like Called-Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ] 🚨. That could trick the RADIUS server into sending Disconnect-Request or CoA-Request messages, with forged session identification attributes in them, to a NAS that an attacker is targeting 😱.
To deal with these vulnerabilities, RADIUS proxies SHOULD check whether the NAS identification attributes (see Section 3.) match the source address of packets coming from the NAS 🔍. Where one or more attributes don't match, Disconnect-Request or CoA-Request messages SHOULD be silently discarded 🗑️.
Heads up: this check isn't always possible 🙃. Since theNAS-IdentifierAttribute doesn't have to correspond to an FQDN, it might not be resolvable to an IP address that could be matched against the source address. And where a NAT exists between the RADIUS client and proxy, checking theNAS-IP-AddressorNAS-IPv6-AddressAttributes may not be feasible 🌪️.
5.3. IPsec Usage Guidelines 🔒✨
okay bestie, so besides the security stuff that's unique to Disconnect and CoA messages, these exchanges are open to the exact same vulnerabilities as RADIUS [RFC2865] 😭. It is RECOMMENDED that IPsec be used to get way better security 🔐.
Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported too, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to give you per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management 🗝️.
Within RADIUS [RFC2865], a shared secret is used for hiding Attributes like User-Password, and it's also used when computing the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used for computing both the Request Authenticator and the Response Authenticator 🧮.
Since in RADIUS a shared secret gives you confidentiality as well as integrity protection and authentication, only IPsec ESP with a non-null transform can provide security services that are enough to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret 💅.
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret 🚨.
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform 🙅♀️.
A typical IPsec policy for an IPsec-capable RADIUS client is:
"Initiate IPsec, from me to any destination port UDP 1812"
This IPsec policy makes the RADIUS client set up an IPsec SA before it sends any RADIUS traffic. If some RADIUS servers the client contacts don't support IPsec, then you'll need a more granular policy:
"Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812."
For a client implementing this specification, the policy would be:
"Accept IPsec, from any to me, destination port UDP 3799"
This makes the RADIUS client accept (but not require) IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support IPsec 🌸.
For an IPsec-capable RADIUS server, a typical IPsec policy is:
"Accept IPsec, from any to me, destination port 1812"
This makes the RADIUS server accept (but not require) IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec 🦋.
For servers implementing this specification, the policy would be:
"Initiate IPsec, from me to any, destination port UDP 3799"
This makes the RADIUS server initiate IPsec when it sends RADIUS extension traffic to any RADIUS client. If some RADIUS clients the server contacts don't support IPsec, then you'll need a more granular policy, like:
"Initiate IPsec, from me to IPsec-capable-RADIUS-client, destination port UDP 3799"
Where IPsec is used for security and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check 🛂. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role 👑.
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec 🏛️.
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec 🧾.
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In an IPsec deployment that only supports certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client 🙈.
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre-shared key. Instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used 🎀.
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys, even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers 🧚.
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so RADIUS exchanges that require a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling of RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983] ⚡.
5.4. Replay Protection ⏰
Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this Attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH] 🕰️.
Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended ✨.
6. Example Traces 🧪
Okay, here are some example traces. Each one shows the hex dump of a Disconnect Request, so you can see what the bytes actually look like 👀.
Disconnect Request with User-Name:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261Disconnect Request with Acct-Session-ID:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567Disconnect Request with Framed-IP-Address:
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 02037. References 📚
7.1. Normative References
- [RFC1305] Mills, D., "Network Time Protocol (version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
- [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
- [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
7.2. Informative References
- [RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
- [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
- [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
- [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
- [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
- [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
- [NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
8. Intellectual Property Statement ✨
Okay so, the IETF is basically saying "we're not picking a side on who owns what here" 💅. They don't say whether any patents or other rights apply to the tech in this doc, whether licences exist, or whether they even looked for any. If you want the details on how the IETF handles rights for standards-track and standards-related docs, check out BCP-11 📚. Claims of rights that were filed for publication, promised licences, or results from trying to get a general licence for implementers or users can all be requested from the IETF Secretariat 🎀.
The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to tell them about it. Send that info to the IETF Executive Director 🫶.
9. Acknowledgments 🌸
Literally the origin story: this protocol was first developed and shipped by Ascend Communications 🦋. Their free server kit came with example code too, which is so cute.
The authors also wanted to shout out the people who gave them super helpful suggestions and feedback 🥰:
Avi Lior <avi@bridgewatersystems.com>Randy Bush <randy@psg.net>Steve Bellovin <smb@research.att.com>Glen Zorn <gwz@cisco.com>Mark Jones <mjones@bridgewatersystems.com>Claudio Lapidus <clapidus@hotmail.com>Anurag Batta <Anurag_Batta@3com.com>Kuntal Chowdhury <chowdury@nortelnetworks.com>Tim Moore <timmoore@microsoft.com>Russ Housley <housley@vigilsec.com>
Iconic contributors, all of them 👑✨.
10. Authors' Addresses 💅
Here's where you can find the authors, bestie 💖:
Murtaza Chiba
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA, 95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845
EMail: david@mitton.com
Phone: +1 978 683 1814
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 732911. Full Copyright Statement 🫶
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈
Here's the vibe on sharing this doc: anyone can copy it and pass it around, and people can even write derivative works that comment on it or help people implement it 🦋. Those copies and derivative works can be published and distributed too, in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 🎀.
The document itself can't be changed in any way, though. That means no removing the copyright notice or references to the Internet Society or other Internet organizations 🚫. The exceptions are when it's needed for developing Internet standards, which follows the copyright procedures in the Internet Standards process, or when it's being translated into a language other than English 🌍.
The permissions above are perpetual, and the Internet Society and its successors or assignees won't revoke them 💜.
The doc and its info are provided on an "AS IS" basis, and the Internet Society and the Internet Engineering Task Force totally disclaim everything, which is the same legal energy as:
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3576 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms