RFC 2869
RADIUS Extensions
RFC 2869: RADIUS Extensions 🎀
Okay bestie, this one is from the Network Working Group, and it's titled RADIUS Extensions 💖. It's filed as Informational, so it's sharing info for the Internet community rather than setting a standard. It's dated June 2000 and was written by C. Rigney of Livingston, W. Willats of Cyno Technologies, and P. Calhoun of Sun Microsystems 👑. The header doesn't list any RFCs it obsoletes or updates.
Status of This Memo 📝
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🌸
This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server. It does this using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. ✨
Table of Contents 🗂️
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 4
2.1 RADIUS support for Interim Accounting Updates.... 4
2.2 RADIUS support for Apple Remote Access
Protocol ........................................ 5
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) .................................. 11
2.3.1 Protocol Overview ............................... 11
2.3.2 Retransmission .................................. 13
2.3.3 Fragmentation ................................... 14
2.3.4 Examples ........................................ 14
2.3.5 Alternative uses ................................ 19
3. Packet Format ......................................... 19
4. Packet Types .......................................... 19
5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22
5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 23
5.4 ARAP-Password ................................... 24
5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 26
5.7 ARAP-Security ................................... 27
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 28
5.10 Prompt .......................................... 29
5.11 Connect-Info .................................... 30
5.12 Configuration-Token ............................. 31
5.13 EAP-Message ..................................... 32
5.14 Message-Authenticator ........................... 33
5.15 ARAP-Challenge-Response ......................... 35
5.16 Acct-Interim-Interval ........................... 36
5.17 NAS-Port-Id ..................................... 37
5.18 Framed-Pool ..................................... 37
5.19 Table of Attributes ............................. 38
6. IANA Considerations ................................... 39
7. Security Considerations ............................... 39
7.1 Message-Authenticator Security .................. 39
7.2 EAP Security .................................... 39
7.2.1 Separation of EAP server and PPP authenticator .. 40
7.2.2 Connection hijacking ............................ 41
7.2.3 Man in the middle attacks ....................... 41
7.2.4 Multiple databases .............................. 41
7.2.5 Negotiation attacks ............................. 42
8. References ............................................ 43
9. Acknowledgements ...................................... 44
10. Chair's Address ....................................... 44
11. Authors' Addresses .................................... 45
12. Full Copyright Statement .............................. 471. Introduction ✨
RFC 2865 [1] describes the RADIUS Protocol as it's actually implemented and deployed today 💅. RFC 2866 [2] then explains how Accounting can be performed with RADIUS.
This memo suggests a few extra Attributes that can be added to RADIUS for useful jobs 🧚. These Attributes don't have much field experience yet, so they should be considered experimental 🧪.
The Extensible Authentication Protocol (EAP) [3] is a PPP extension that adds support for more authentication methods within PPP 🔐. This memo covers how the EAP-Message and Message-Authenticator attributes can be used to bring EAP support into RADIUS 🦋.
All attributes are made of variable length Type-Length-Value 3-tuples. The best part is that new attribute values can be added without disturbing existing implementations of the protocol 🌈.
1.1. Specification of Requirements
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 RFC 2119 [4]. These are the requirement words, so pay attention to them 👀.
An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant". One that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant." 💯
A NAS that doesn't implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that can't offer ARAP service MUST NOT implement the RADIUS attributes for ARAP 🙅♀️. A NAS MUST treat a RADIUS access-request asking for an unavailable service as an access-reject instead 🚫.
1.2. Terminology
This document uses the following terms 📖:
- service: The NAS provides a service to the dial-in user, such as PPP or Telnet.
- session: Each service the NAS provides to a dial-in user counts as a session. The beginning of the session is the point where service is first provided, and the end is the point where service is ended. A user may have multiple sessions in parallel or in series if the NAS supports that, and each session generates a separate start and stop accounting record 🎀.
- silently discard: This means the implementation throws the packet away without any further processing 🫥. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet. It SHOULD also record the event in a statistics counter 📊.
2. Operation
Operation is identical to what's defined in RFC 2865 [1] and RFC 2866 [2]. Same vibes, no surprises 🤝.
2.1. RADIUS support for Interim Accounting Updates
When a user is authenticated, a RADIUS server sends an Access-Accept in response to a successful Access-Request 🎉. If the server wants to receive interim accounting messages for that user, it must include the Acct-Interim-Interval RADIUS attribute in the message. That attribute tells you the interval in seconds between interim messages ⏰.
You can also statically configure an interim value on the NAS itself. Heads up, though: a locally configured value on the NAS MUST override the value found in an Access-Accept 🙅♀️.
This scheme doesn't break backward interoperability. A RADIUS server that doesn't support this extension will simply not add the new Attribute, and NASes that don't support it will ignore the Attribute 🫶.
Note that all information in an interim message is cumulative. For example, the number of packets sent is the total since the beginning of the session, not since the last interim message 📈.
The idea is that an Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message, except for the Acct-Term-Cause attribute 🧾.
Since all the information is cumulative, a NAS MUST ensure that only a single generation of an interim Accounting message for a given session is present in the retransmission queue at any given time. No duplicate drama in the queue 🙅♀️💅.
A NAS MAY use a fudge factor to add a random delay between Interim Accounting messages for separate sessions. This keeps everything from being sent at the same moment, which could otherwise happen if a primary link was recently restored and lots of dial-up users were directed to the same NAS at once 🌊.
The Network and NAS CPU load of using Interim Updates should be carefully considered, and appropriate values of Acct-Interim-Interval should be chosen. Don't just pick a number and hope for the best 🥹.
2.2. RADIUS support for Apple Remote Access Protocol
RADIUS (Remote Authentication Dial-In User Service) gives multiple dial-in Network Access Server (NAS) devices a way to share a common authentication database 🤝✨.
The Apple Remote Access Protocol (ARAP) is how AppleTalk network traffic gets sent over point-to-point links. That's typically asynchronous and ISDN switched-circuit connections, but not exclusively 📱. Apple is moving toward ATCP on PPP for future remote access services, but ARAP is still a common way for the installed base of Macintosh users to make remote network connections, and it's likely to stay that way for a while 🍎.
ARAP is supported by several NAS vendors who also support PPP, IPX and other protocols in the same NAS 🧩. ARAP connections in these multi-protocol devices often aren't authenticated with RADIUS. And if they are, each vendor makes its own individual solution to the problem 😤.
This section describes how to use additional RADIUS attributes to support ARAP 💖. RADIUS client and server implementations that implement this specification should be able to authenticate ARAP connections in an interoperable manner 🫶.
This section assumes you already know RADIUS. It also goes into some detail on how ARAP operates before getting into the proposed ARAP RADIUS attributes 🧠.
There are two features of ARAP this document does not address 🙅♀️:
- User initiated password changing. This isn't part of RADIUS, but it can be implemented through a software process other than RADIUS 🔑.
- Out-of-Band messages. At any time, the NAS can send messages to an ARA client that appear in a dialog box on the dial-in user's screen 💬. These aren't part of authentication, so they don't belong here. However, a Reply-Message attribute in an Access-Accept may be sent down to the user as a sign-on message of the day string using the out-of-band channel 🌅.
Okay bestie, so we've got the ARAP section still going, and this part is where the good stuff starts 🦋 We tried really hard to respect the spirit of the existing RADIUS protocol, making design choices that play nicely with prior art ✨ We also had to strike a balance between flooding the RADIUS world with brand-new attributes and hiding all of ARAP inside one multiplexed ARAP attribute string or inside Extended Authentication Protocol (EAP) [3] machinery 💅
Still, ARAP is different enough from PPP that it deserves a small set of its own similarly named attributes 🎀
We're assuming an ARAP-aware RADIUS server can do DES encryption and generate security module challenges. This matches the general RADIUS vibe of smart server, simple NAS 🧚
ARAP authenticates a connection in two phases 🌸 The first is a "Two-Way DES" random number exchange that uses the user's password as a key. It's "Two-Way" because the ARAP NAS challenges the dial-in client to authenticate itself, and the dial-in client challenges the ARAP NAS right back 🔥
Here's how ARAP does it:
- The NAS sends two 32-bit random numbers to the dial-in client in an ARAP
msg_auth_challengepacket. - The dial-in client uses the user's password to DES encrypt the two random numbers it got from the NAS. Then it sends that result, the user's name, and two 32-bit random numbers of its own back to the NAS in an ARAP
msg_auth_requestpacket. - The NAS checks that the encrypted random numbers from the dial-in client are what it expected. If they are, it encrypts the dial-in client's challenge using the password and sends it back in an ARAP
msg_auth_responsepacket ✨
Note that if the dial-in client's response was wrong, meaning the user typed the wrong password 🙈, the server can start a retry sequence, up to the maximum number of retries the NAS allows. In that case, when the dial-in client gets the ARAP msg_auth_response packet, it acknowledges it with an ARAP msg_auth_again packet 💀
After this first "DES Phase," the ARAP NAS MAY initiate a secondary authentication phase using what Apple calls "Add-In Security Modules." 🍓 Security Modules are small bits of code that run on both the client and the server, and they're allowed to read and write arbitrary data across the communications link to do extra authentication work. Various security token vendors use this mechanism to authenticate ARA callers 👑
ARAP lets security modules read and write anything they like, but every existing security module uses simple challenge and response cycles, maybe with some overall control information. This document assumes all existing security modules can be supported with one or more challenge/response cycles 🫶
To complicate things (classic), ARAP sends some profile information after the DES Phase and before the Security Module phase. So besides the challenge responses, this profile information must also be present, at kind of unusual times 😭 Thankfully, the information is only a few pieces of numeric data related to passwords, and this document packs it all into one new attribute 💖
Presenting an Access-Request to RADIUS on behalf of an ARAP connection is pretty straightforward ✨ The ARAP NAS generates the random number challenge, then receives the dial-in client's response, the dial-in client's challenge, and the user's name. As long as the user isn't a guest, the following gets forwarded in an Access-Request packet: User-Name (up to 31 characters long), Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional attributes you want, like Service-Type, NAS-IP-Address, NAS-Id, NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 🦋
The Request Authenticator is a 16 octet random number generated by the NAS 🎀 The low-order 8 octets of this number get sent to the dial-in user as the two 4 octet random numbers needed in the ARAP msg_auth_challenge packet. Octets 0-3 are the first random number, and Octets 4-7 are the second 🧚
The ARAP-Password in the Access-Request has a 16 octet random number field, and it carries the dial-in user's response to the NAS challenge plus the client's own challenge to the NAS. The high-order octets hold the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets), and the low-order octets hold the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets) 🌈
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages 💅
If the RADIUS server doesn't support ARAP, it SHOULD return an Access-Reject to the NAS 🙅♀️
If the RADIUS server does support ARAP, it should verify the user's response using the Challenge (from the lower order 8 octets of the Request Authenticator) and the user's response (from the low order 8 octets of the ARAP-Password) 🔍
If that authentication fails, the RADIUS server should send an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Message attributes. If Password-Retry is there, the ARAP NAS MAY choose to start another challenge-response cycle, up to a total number of times equal to the integer value of the Password-Retry attribute 🔥
If the user is authenticated, the RADIUS server should return an Access-Accept packet (Code 2) to the NAS, with ID and Response Authenticator as usual, and these attributes:
Service-TypeofFramed-Protocol.Framed-Protocolof ARAP (3).Session-Timeoutwith the maximum connect time for the user, in seconds. If the user gets unlimited time,Session-Timeoutshould not be included in the Access-Accept packet, and ARAP will treat that as an unlimited timeout (-1) ♾️ARAP-Challenge-Response, containing 8 octets with the response to the dial-in client's challenge. The RADIUS server works this out by taking the dial-in client's challenge from the high order 8 octets of theARAP-Passwordattribute and doing DES encryption on it, using the authenticating user's password as the key. If the user's password is less than 8 octets long, it gets padded at the end with NULL octets to a length of 8 before being used as a key. If the user's password is more than 8 octets long, an Access-Reject MUST be sent instead 🚫ARAP-Features, containing information the NAS should send to the user in an ARAP "feature flags" packet. Its layout is:- Octet 0: If zero, the user cannot change their password. If non-zero, the user can. (RADIUS doesn't handle the password changing itself, it just passes along the attribute that says whether ARAP indicates they can.)
- Octet 1: Minimum acceptable password length (0-8).
- Octet 2-5: Password creation date in Macintosh format, defined as 32 bits unsigned, representing seconds since Midnight GMT January 1, 1904.
- Octet 6-9: Password Expiration Delta from create date, in seconds.
- Octet 10-13: Current RADIUS time in Macintosh format.
- Optionally, a single
Reply-Messagewith a text string up to 253 characters long, which MAY be sent down to the user to show in a sign-on/message of the day dialog 📣 Framed-AppleTalk-Networkmay be included 🍎Framed-AppleTalk-Zone, up to 32 characters long, may be included 🌸
ARAP defines the idea of a list of zones for a user. Along with the list of zone names, there's a Zone Access Flag (used by the NAS) that says how to use that list. The dial-in user may only be allowed to see the Default Zone, or only the zones in the zone list (inclusive), or any zone except those in the zone list (exclusive) 🗺️
The ARAP NAS handles this with a named filter that contains (at least) zone names. This solves the problem where one RADIUS server is managing different NAS clients that may not be able to "see" every zone name in a user's zone list. Zone names only mean something "at the NAS." The downside is that zone filters have to be set up on the NAS somehow, then referenced by the RADIUS Filter-Id 🤓
ARAP-Zone-Access contains an integer that specifies how the "zone list" for this user should be used. If this attribute is present and the value is 2 or 4, then a Filter-Id must also be present to name the zone list filter the access flag applies to ⭐
Including a Callback-Number or Callback-Id attribute in the Access-Accept MAY cause the ARAP NAS to disconnect after sending the Feature Flags, so it can start callback processing in an ARAP-specific way 📞
Other attributes may be present in the Access-Accept packet as well 💜
An ARAP NAS needs other info to finish bringing up the connection to the dial-in client. The good news is it can get that info without any help from RADIUS, either through configuration via SNMP, a NAS administration program, or by working it out from the AppleTalk stack on the NAS. Specifically:
AppearAsNetandAppearAsNodevalues, sent to the client to tell it which network and node numbers to use in its datagram packets.AppearAsNetcan come from theFramed-AppleTalk-Networkattribute, or from configuration or the AppleTalk stack on the NAS 🧠- The "default" zone, which is the name of the AppleTalk zone the dial-in client will appear in. (Or it can be specified with the
Framed-AppleTalk-Zoneattribute.) 🌷 - Other very NAS-specific stuff, like the name of the NAS and smartbuffering information. (Smartbuffering is an ARAP mechanism that swaps common AppleTalk datagrams for small tokens, to improve slow-link performance in a few common traffic situations.) 🐢
- "Zone List" information for this user. The ARAP specification defines a "zone count" field, which is actually unused 🙃
RADIUS supports ARAP Security Modules like this 🔐
After DES authentication is done, the RADIUS server may tell the ARAP NAS to run one or more security modules for the dial-in user. The underlying protocol supports running multiple security modules in series, but in practice, all current implementations only allow running one. You can support multiple modules through multiple Access-Challenge requests, but this facility will probably never get used 😴
We also assume that even though ARAP lets security modules have a free-form dialog between each end of the point-to-point link, in actual practice all security modules can be reduced to a simple challenge/response cycle 💅
If the RADIUS server wants the ARAP NAS to run a security module, it should send an Access-Challenge packet to the NAS, with (optionally) the State attribute, plus the ARAP-Challenge-Response, ARAP-Features, and two more attributes:
ARAP-Security: a four octet security module signature, containing a Macintosh OSType. 🍬ARAP-Security-Data: a string that carries the actual security module challenge and response. 🎀
2.2. RADIUS Support for Apple Remote Access Protocol (continued) ✨
Okay so once the security module is done doing its thing, the NAS packages up its response in an ARAP-Security-Data attribute and sends it to the RADIUS server in a second Access-Request 💅. It also includes the State from the Access-Challenge. The authenticator field has no special info in this case, and you can tell this is happening because the State attribute is there 🔍🫶
2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 🧚
Okay, so the Extensible Authentication Protocol (EAP), described in [3], is basically the standard way to plug extra authentication methods into PPP ✨ Thanks to EAP you can add stuff like smart cards, Kerberos, Public Key, One Time Passwords, and more 🔐 To make EAP work inside RADIUS, this document introduces two new attributes, EAP-Message and Message-Authenticator. This section explains how to use them 🎀
The RADIUS server basically acts as a shuttle 🚌 It passes RADIUS-encapsulated EAP Packets back and forth between the NAS and a backend security server. The conversation between the RADIUS server and the backend security server usually happens over a proprietary protocol made by the backend security server vendor. But it's also possible to use RADIUS-encapsulated EAP through the EAP-Message attribute 💖 This is honestly iconic because the RADIUS server can support EAP without needing any authentication-specific code, since that code can live on the backend security server instead 🌸
2.3.1. Protocol Overview 🦋
Okay, the EAP conversation between the authenticating peer (dial-in user) and the NAS starts with negotiating EAP within LCP. Once EAP is negotiated, the NAS MUST send an EAP-Request/Identity message to the authenticating peer, unless identity is determined some other way, such as through Called-Station-Id or Calling-Station-Id 🙈 The peer then replies with an EAP-Response/Identity, and the NAS forwards it to the RADIUS server in the EAP-Message attribute of a RADIUS Access-Request packet. The RADIUS Server will typically use that EAP-Response/Identity to figure out which EAP type should be applied to the user 🔥
Now here's the part I'm obsessed with 😭 To let non-EAP aware RADIUS proxies forward the Access-Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name attribute, and MUST include the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. NAS-Port or NAS-Port-Id SHOULD be included in the attributes the NAS sends in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address MUST be included. Then, to let EAP-unaware proxies forward the Access-Reply, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing gets really messy to manage 💀
If identity is determined through another means, such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request 🍓
Lowkey, skipping the identity round-trip saves a trip, but it can't be used everywhere 🥺 Sometimes the user's identity isn't needed at all. For example, authentication and accounting might be handled based on Called-Station-Id or Calling-Station-Id. So an EAP-Request/Identity packet might never get sent by the NAS to the authenticating peer. When that's the case, the NAS will send the RADIUS server a RADIUS Access-Request packet containing an EAP-Message attribute that signifies EAP-Start. EAP-Start is indicated by an EAP-Message attribute with a length of 2 (no data). However, it should be noted that since no User-Name attribute is included in the Access-Request, this approach is not compatible with RADIUS as specified in [1], and it also can't easily be used when proxies are deployed, like in roaming or shared use networks 🌈
If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing an EAP-Message attribute. If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. The EAP-Message attribute carries an encapsulated EAP packet, which then gets passed on to the authenticating peer ✨ If the NAS didn't send an EAP-Request/Identity message to the peer first, the Access-Challenge will typically contain an EAP-Message attribute encapsulating an EAP-Request/Identity message, asking the dial-in user to identify themself. The NAS then responds with a RADIUS Access-Request packet containing an EAP-Message attribute that encapsulates an EAP-Response. The conversation keeps going until either a RADIUS Access-Reject or Access-Accept packet is received 🔁
Reception of a RADIUS Access-Reject packet, with or without an EAP-Message attribute encapsulating EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to the authenticating peer 🚫 A RADIUS Access-Accept packet with an EAP-Message attribute encapsulating EAP-Success successfully ends the authentication phase 🎉 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain all of the expected attributes that are currently returned in an Access-Accept packet 👑
The scenario above means the NAS never has to manipulate an EAP packet, which is so clean 🧼 An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer.
For proxied RADIUS requests there are two ways to process things 🧠 If the domain is determined based on the Called-Station-Id, the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is determined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server 🛰️
For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would happen if the message was proxied to a RADIUS Server that doesn't support the EAP-Message extension. When the NAS gets an Access-Reject like this, it MUST send an LCP Terminate Request to the authenticating peer, and disconnect 💔
2.3.2. Retransmission 🔄
As noted in [3], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. So if an EAP packet gets lost in transit between the authenticating peer and the NAS (or the other way around), the NAS will retransmit it. As in RADIUS [1], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server 💅
Note that it may be necessary to adjust retransmission strategies and authentication timeouts in certain cases 👀 For example, when a token card is used, extra time may be needed for the user to find the card and enter the token. Since the NAS usually won't know the required parameters, the RADIUS server has to provide them. This can be done by including Session-Timeout and Password-Retry attributes within the Access-Challenge packet 🎀
If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of Session-Timeout gives the NAS the maximum number of seconds it should wait for an EAP-Response before retransmitting the EAP-Message to the dial-in user ⏱️
2.3.3. Fragmentation 🧩
Using the EAP-Message attribute, the RADIUS server can encapsulate an EAP packet that's bigger than the MTU on the link between the NAS and the peer. Since the RADIUS server can't use MTU discovery to find out the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute, so the RADIUS server gets this info 🦋
2.3.4. Examples 📚
The example below shows the conversation between the authenticating peer, NAS, and RADIUS server for a One Time Password (OTP) authentication. OTP is only used here for illustration 🧁 Other authentication protocols could have been used too, although they might show somewhat different behavior 🌸
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase startsNow the case where the NAS first sends an EAP-Start packet to the RADIUS server 🫣 The conversation would look like this:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase startsOkay, so now let's look at what happens when the client totally flops EAP auth 💀 Here's how that convo goes:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- PPP EAP-Failure
(client disconnected)Next up, the case where the RADIUS server or proxy doesn't support EAP-Message at all 🙈 The convo goes like this:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)Now here's a messy one 🌀 The local RADIUS Server does support EAP-Message, but the remote RADIUS Server doesn't. So it looks like this:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
RADIUS
Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS Server)
<- PPP LCP Terminate
(User Disconnected)What if the authenticating peer doesn't support EAP, but EAP is required for that user? 😤 Then it goes like this:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)And last but not least, the NAS doesn't support EAP, but EAP is required for that user 🙅♀️ Here's that convo:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-CHAP
auth
PP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)2.3.5. Alternative uses ✨
Right now, the convo between the backend security server and the RADIUS server is proprietary, because there's no standard for it yet 😩 To get more standardization going and make sure RADIUS vendors and backend security vendors can actually work together, it is recommended that RADIUS-encapsulated EAP be used for this conversation.
This is a big win because it lets the RADIUS server support EAP without needing authentication-specific code baked into it. That authentication-specific code can live on a backend security server instead, which is so smart 🧠
When RADIUS-encapsulated EAP is used between a RADIUS server and a backend security server, the security server will typically send back an Access-Accept/EAP-Success message without the attributes that would normally come in an Access-Accept. So the RADIUS server MUST add those attributes before it sends an Access-Accept/EAP-Success message to the NAS. Don't skip this part, bestie 🫶
3. Packet Format
Packet Format is identical to what's defined in RFC 2865 [1] and 2866 [2]. Same vibes, no changes 🎀
4. Packet Types
Packet types are identical to those defined in RFC 2865 [1] and 2866 [2]. Literally the same 💅
Check the "Table of Attributes" below to see which types of packets can contain which attributes defined here 🦋
5. Attributes
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response 🔥
Some attributes MAY be included more than once. What that does depends on the attribute, and each attribute description spells it out 🌈 The order of attributes of the same type SHOULD be preserved. The order of attributes of different types is not required to be preserved, so you're free there ✨
The end of the list of attributes is marked by the Length of the RADIUS packet 🧚
The attribute format summary is the same as in RFC 2865 [1], but it's repeated here so you don't have to flip around. Fields go left to right 👑
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
The Type field is one octet. The up-to-date values of the RADIUS Type field are listed in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. This specification covers the following values:
1-39 (refer to RFC 2865 [1], "RADIUS")
40-51 (refer to RFC 2866 [2], "RADIUS Accounting")
52 Acct-Input-Gigawords
53 Acct-Output-Gigawords
54 Unused
55 Event-Timestamp
56-59 Unused
60-63 (refer to RFC 2865 [1], "RADIUS")
64-67 (refer to [6])
68 (refer to [7])
69 (refer to [6])
70 ARAP-Password
71 ARAP-Features
72 ARAP-Zone-Access
73 ARAP-Security
74 ARAP-Security-Data
75 Password-Retry
76 Prompt
77 Connect-Info
78 Configuration-Token
79 EAP-Message
80 Message-Authenticator
81-83 (refer to [6])
84 ARAP-Challenge-Response
85 Acct-Interim-Interval
86 (refer to [7])
87 NAS-Port-Id
88 Framed-Pool
89 Unused
90-91 (refer to [6])
92-191 UnusedLength
The Length field is one octet, and it tells you the length of this attribute, including the Type, Length and Value fields. If an attribute shows up in a packet with an invalid Length, the entire request should be silently discarded 🙈
Value
The Value field is zero or more octets and holds information specific to the attribute. The format and length of the Value field are determined by the Type and Length fields 🍓
Heads up: none of the types in RADIUS terminate with a NUL (hex 00) 😭 That goes for "text" and "string" types too. The Attribute has a length field and doesn't use a terminator. Text contains UTF-8 encoded 10646 [8] characters, and String contains 8-bit binary data. Servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings ⚠️
The Value field comes in five data types, and "text" is a subset of "string." Keep these straight!
text 1-253 octets containing UTF-8 encoded 10646 [8]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
string 1-253 octets containing binary data (values 0 through
255 decimal, inclusive). Strings of length zero (0) MUST
NOT be sent; omit the entire attribute instead.
address 32 bit unsigned value, most significant octet first.
integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first --
seconds since 00:00:00 UTC, January 1, 1970.5.1. Acct-Input-Gigawords 🌸
Description 💖
This attribute tells you how many times the Acct-Input-Octets counter has wrapped around 2^32 over the course of the service. It can only show up in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update. ✨
Here's the layout, read 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 🎀
52 for Acct-Input-Gigawords.
Length 🧚
6
Value 💅
The Value field is four octets.
5.2. Acct-Output-Gigawords 🦋
Description 💖
This one is the mirror image of the last. It tells you how many times the Acct-Output-Octets counter has wrapped around 2^32 while the service was being delivered. Same rules apply: it can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update. 🔥
Here's the layout, read 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 🎀
53 for Acct-Output-Gigawords.
Length 🧚
6
Value 💅
The Value field is four octets.
5.3. Event-Timestamp ⏰
Description 💖
This attribute goes in an Accounting-Request packet to record when the event happened on the NAS. The time is in seconds since January 1, 1970 00:00 UTC. 🌸
Here's the layout, read 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 🎀
55 for Event-Timestamp
Length 🧚
6
Value 💅
The Value field is four octets, encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC.
5.4. ARAP-Password 🔐
Description 💖
This attribute only shows up in an Access-Request packet that has a Framed-Protocol of ARAP. 🎀
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. So you don't need all of them, just one of the set. ✨
Here's the layout, read 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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🎀
70 for ARAP-Password.
Length 🧚
18
Value 💅
This attribute holds a 16 octet string, carrying the dial-in user's response to the NAS challenge plus the client's own challenge to the NAS. The high-order octets (Value1 and Value2) hold the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets). The low-order octets (Value3 and Value4) hold the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets). 🫶
5.5. ARAP-Features 🌟
Description 💖
This attribute is sent in an Access-Accept packet with a Framed-Protocol of ARAP. It carries password information that the NAS should sent to the user in an ARAP "feature flags" packet. 💜
Here's the layout, read 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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🎀
71 for ARAP-Features.
Length 🧚
16
Value 💅
The Value field is a compound string with info the NAS should send to the user in the ARAP "feature flags" packet. Here's what each piece does:
- Value1: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.)
- Value2: Minimum acceptable password length, from 0 to 8.
- Value3: Password creation date in Macintosh format, defined as 32 unsigned bits representing seconds since Midnight GMT January 1, 1904.
- Value4: Password Expiration Delta from create date in seconds.
- Value5: Current RADIUS time in Macintosh format.
5.6. ARAP-Zone-Access 🗺️
Description 💖
This attribute is included in an Access-Accept packet with a Framed-Protocol of ARAP. It tells the NAS how the ARAP zone list for the user should be used. 🌈
Here's the layout, read 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 🎀
72 for ARAP-Zone-Access.
Length 🧚
6
Value 💅
The Value field is four octets, encoding an integer with one of these values:
1 Only allow access to default zone
2 Use zone filter inclusively
4 Use zone filter exclusivelyThe value 3 is skipped 🙈, not because these are bit flags, but because 3 in some ARAP implementations means "all zones", which is the same as not specifying a list at all under RADIUS.
If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to. Don't skip this one, bestie! 💀
5.7. ARAP-Security 🔒
Description 💖
This attribute names the ARAP Security Module to be used in an Access-Challenge packet. 🫶
Here's the layout, read 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 🎀
73 for ARAP-Security.
Length 🧚
6
Value 💅
The Value field is four octets, containing an integer that specifies the security module signature, which is a Macintosh OSType. (Macintosh OSTypes are 4 ascii characters cast as a 32-bit integer.) 🔥
5.8. ARAP-Security-Data 📦
Description 💖
This attribute carries the actual security module challenge or response. You'll find it in Access-Challenge and Access-Request packets. 🌸
Here's the layout, read left to right. 🦋
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🎀
74 for ARAP-Security-Data.
Length 🧚
>=3
String 💅
The String field contains the security module challenge or response that goes with the ARAP Security Module named in ARAP-Security. 💜
5.9. Password-Retry 🔁
Description 💖
This attribute MAY be included in an Access-Reject to show how many authentication attempts a user may be allowed before being disconnected. 🙌
It's mainly meant for use with ARAP authentication. 🍓
Here's the layout, read 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 🎀
75 for Password-Retry.
Length 🧚
6
Value 💅
The Value field is four octets, containing an integer that specifies the number of password retry attempts to permit the user. 🫶
5.10. Prompt 💬
Description 💖
This attribute is only used in Access-Challenge packets. It tells the NAS whether it should echo the user's response as it is entered, or not echo it. 🙈
Here's the layout, read 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 🎀
76 for Prompt.
Length 🧚
6
Value 💅
The Value field is four octets. The values are:
0 No Echo
1 Echo5.11. Connect-Info 🔌✨
Description
okay so this attribute is how the NAS spills the tea on what kind of connection the user has 💅 The NAS MAY send it in an Access-Request or Accounting-Request to say what the user's connection is like 🫶
Here's the Connect-Info attribute format at a glance. Fields go left to right 👀
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 77 for Connect-Info 🎀
Length
It has to be >= 3 🌸
Text
The Text field is UTF-8 encoded 10646 [8] characters 🌈 The connection speed SHOULD go at the very start of the first Connect-Info attribute in the packet 💖 If the transmit and receive speeds are different, both can go in that first attribute: transmit speed first (the speed the NAS modem transmits at), then a slash (/), then the receive speed, and then other info if you want 🧚
Examples: "28800 V42BIS/LAPM" or "52000/31200 V90" ✨
You can have more than one Connect-Info attribute in an Accounting-Request packet 🦋 This makes room for the ITU's plans to have modems report more connection info in a standard format, which might go over 252 octets 😭
5.12. Configuration-Token 🧩
Description
this one is for big distributed authentication networks that run on proxies 🌐 A RADIUS Proxy Server sends it to a RADIUS Proxy Client in an Access-Accept to say which kind of user profile to use 💜 It should not be sent to a NAS 🙅♀️
Here's the format, left to right 👀
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 78 for Configuration-Token 🍓
Length
= 3 🫶
String
The String field is one or more octets 🌸 What the info actually looks like is up to the site or the application, and a robust implementation SHOULD handle the field as plain undistinguished octets 💅 How the allowed usage of this field gets organized is outside the scope of this spec 🙈
5.13. EAP-Message 🔐
Description
this attribute wraps up Extended Access Protocol [3] packets 🎁 That way the NAS can authenticate dial-in users with EAP without actually having to understand EAP itself 🧠✨
The NAS takes any EAP messages it gets from the user, puts them into one or more EAP attributes, and forwards them to the RADIUS Server inside an Access-Request 💌 The server can send EAP messages back in Access-Challenge, Access-Accept and Access-Reject packets 🦋
A RADIUS Server that gets EAP messages it doesn't understand SHOULD return an Access-Reject 🙅♀️
The NAS puts EAP messages from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS Server in an Access-Request message 💖 If there are multiple EAP-Messages in an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in that packet 🎀 Access-Accept and Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, holding EAP-Success or EAP-Failure 👑
EAP is expected to power a bunch of authentication methods, including ones with strong cryptography 🔥 To keep attackers from messing with EAP by attacking RADIUS/EAP (like by changing the EAP-Success or EAP-Failure packets), RADIUS/EAP needs integrity protection at least as strong as what the EAP methods use themselves 😭🔒
So the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets that have an EAP-Message attribute 🛡️💜
Access-Request packets with an EAP-Message attribute but no Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server 🙈 A RADIUS Server that supports EAP-Message MUST calculate the correct Message-Authenticator value and silently discard the packet if it doesn't match what was sent 💅 A RADIUS Server that does not support EAP-Message MUST return an Access-Reject if it gets an Access-Request with an EAP-Message attribute 🚫 And a RADIUS Server that gets an EAP-Message attribute it doesn't understand MUST return an Access-Reject too 🙃
Access-Challenge, Access-Accept, or Access-Reject packets with an EAP-Message attribute but no Message-Authenticator attribute SHOULD be silently discarded by the NAS 🫣 A NAS that supports EAP-Message MUST calculate the correct Message-Authenticator value and silently discard the packet if it doesn't match what was sent ✨
Here's the EAP-Message attribute format 👀
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 79 for EAP-Message 🌈
Length
= 3 💖
String
The String field holds EAP packets, as defined in [3] 🎀 If a packet has multiple EAP-Message attributes, their values should be concatenated, which lets RADIUS pass EAP packets longer than 253 octets 🧚✨
5.14. Message-Authenticator 🛡️
Description
this attribute MAY be used to sign Access-Requests so nobody can spoof them when using CHAP, ARAP or EAP authentication 🫶 It MAY be used in any Access-Request 💅 It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute 🔐
A RADIUS Server that receives an Access-Request with a Message-Authenticator Attribute present MUST calculate the correct Message-Authenticator value and silently discard the packet if it doesn't match what was sent 🙅♀️
A RADIUS Client that receives an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator Attribute present MUST calculate the correct Message-Authenticator value and silently discard the packet if it doesn't match what was sent 💜
Earlier drafts of this memo called this attribute "Signature," but Message-Authenticator is more precise 🤓 It works exactly the same, it just got a better name ✨
Here's the format, left to right 👀
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 80 for Message-Authenticator 🦋
Length
18 🌸
String
When it's in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [9] checksum of the entire Access-Request packet, covering Type, ID, Length and authenticator, with the shared secret as the key 🔑 It goes like this:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the checksum is calculated, the signature string should be treated as sixteen octets of zero 🙈
For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated using the Request-Authenticator from the Access-Request this packet is replying to 💌
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)Again, the signature string should be treated as sixteen octets of zero when calculating it. The shared secret is the key for the HMAC-MD5 hash 🗝️ The value gets calculated and inserted into the packet before the Response Authenticator is calculated 🧠
This attribute isn't needed if User-Password is present, but it's super useful for stopping attacks on other kinds of authentication 🛡️ It's meant to stop an attacker from setting up a "rogue" NAS and running online dictionary attacks against the RADIUS server 😤 It does NOT protect against "offline" attacks, where the attacker grabs packets with (for example) a CHAP challenge and response and runs a dictionary attack on them offline 💀
IP Security will eventually make this attribute unnecessary, so think of it as an interim measure 🫶
5.15. ARAP-Challenge-Response 🎀
Description
this attribute gets sent in an Access-Accept packet with Framed-Protocol of ARAP, and it has the response to the dial-in client's challenge 💖
Here's the format, 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 84 for ARAP-Challenge-Response 🧚
Length
10 🌈
Value
The Value field holds an 8 octet response to the dial-in client's challenge 🔐 The RADIUS server works it out by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute, then doing DES encryption on that value with the authenticating user's password as the key 🧠 If the user's password is shorter than 8 octets, it gets padded with NULL octets at the end up to 8 before it's used as a key 💅
5.16. Acct-Interim-Interval ⏰
Description
this attribute says how many seconds there are between each interim update for this specific session ⏱️ It can only show up in the Access-Accept message 🫶
Here's the format, 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
It's 85 for Acct-Interim-Interval 🍓
Length
6 🎀
Value
The Value field holds how many seconds there are between each interim update the NAS sends for this session 💖 The value MUST NOT be smaller than 60 🚫 The value SHOULD NOT be smaller than 600, and you should think carefully about how it affects network traffic 🌐🫶
Heads up bestie: a tiny interval can absolutely flood the network, so don't skip the math 😭
5.17. NAS-Port-Id ✨
Description 🔌
okay so NAS-Port-Id is a text string that tells you which port on the NAS is authenticating the user 🫶. it only shows up in Access-Request and Accounting-Request packets 💌. also, bestie, "port" here means a physical connection on the NAS, NOT a TCP or UDP port number 🙅♀️. don't mix those up!!
Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports 💅. NAS-Port-Id is made for NASes that can't easily number their ports 🎀.
The fields go left to right, and here's the layout 👇
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🧚
87 for NAS-Port-Id.
Length 📏
= 3
Text 🍓
The Text field holds the name of the port, written as UTF-8 encoded 10646 [8] characters. main character energy for port names ✨
5.18. Framed-Pool 🌸
Description 🦋
this one is giving address pools 🏊♀️. it contains the name of an assigned address pool that SHOULD be used to assign an address for the user 💖. if a NAS doesn't support multiple address pools, the NAS should ignore this Attribute 🙈. address pools are usually for IP addresses, but they can be used for other protocols too, as long as the NAS supports pools for those protocols 🌈.
The fields go left to right, and here's the layout 👇
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 👑
88 for Framed-Pool
Length 📏
= 3
String 💜
The string field contains the name of an assigned address pool configured on the NAS.
5.19. Table of Attributes 🗂️
okay this table is your cheat sheet for which attributes can show up in which kind of packet 🔥. Acct-Input-Gigawords, Acct-Output-Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in an Accounting-Request packet. Connect-Info may have 0+ instances in an Accounting-Request packet. The other attributes added in this document must not be present in an Accounting-Request 💀.
Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute[Note 1] An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes 🚫. if it doesn't contain any of those four attributes, it SHOULD contain a Message-Authenticator 🔐. and if any packet type contains an EAP-Message attribute, it MUST also contain a Message-Authenticator 🫶.
here's the decoder ring for the entries above 💅
0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.6. IANA Considerations 🦋
The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces, as described in the "IANA Considerations" section of [1], in accordance with BCP 26 [10] 🌈.
7. Security Considerations 🚨
okay this part is SERIOUS, bestie 😭. the attributes other than Message-Authenticator and EAP-Message in this document have no additional security considerations beyond those already identified in [1]. so the stuff below is where the drama is 🎭.
7.1. Message-Authenticator Security 🔐
Access-Request packets with a User-Password establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used 🗝️. Access-Request packets with CHAP-Password or EAP-Message do not have a User-Password attribute, so the Message-Authenticator attribute should be used in access-request packets that do not have a User-Password, in order to establish the identity of the NAS sending the request 🫶.
7.2. EAP Security 💜
since the whole purpose of EAP is to give PPP authentication enhanced security, it is critical that RADIUS support for EAP be secure 😱. in particular, the following issues must be addressed:
- Separation of EAP server and PPP authenticator
- Connection hijacking
- Man in the middle attacks
- Multiple databases
- Negotiation attacks
7.2.1. Separation of EAP server and PPP authenticator 🧩
it's possible for the EAP endpoints to mutually authenticate, negotiate a ciphersuite, and derive a session key for later use in PPP encryption 🔑.
this doesn't cause an issue on the peer, since the peer and EAP client live on the same machine. all that's needed is for the EAP client module to pass the session key to the PPP encryption module 💖.
it gets messier with RADIUS, though 🙃. the PPP authenticator usually won't live on the same machine as the EAP server. for example, the EAP server might be a backend security server, or a module sitting on the RADIUS server 🖥️.
when the EAP server and PPP authenticator are on different machines, there are a few security implications. firstly, mutual authentication happens between the peer and the EAP server, NOT between the peer and the authenticator 👀. this means the peer can't validate the identity of the NAS or tunnel server it's talking to 😬.
as described earlier, when EAP/RADIUS is used to encapsulate EAP packets, the Message-Authenticator attribute is required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server ✅. since the Message-Authenticator attribute involves an HMAC-MD5 hash, the RADIUS server can verify the integrity of the Access-Request as well as the NAS or tunnel server's identity 🕵️♀️. similarly, Access-Challenge packets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 hash, so the NAS or tunnel server can determine the integrity of the packet and verify the identity of the RADIUS server 🫡. and EAP packets sent via methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server 🛡️✨.
the second issue with an EAP server and PPP authenticator on different machines is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator 🚚. so a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key 🔁. the specification of this transit mechanism is outside the scope of this document 📄.
7.2.2. Connection hijacking 🪝
in this form of attack, the attacker tries to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the backend security server 😈. RADIUS doesn't support encryption, and as described in [1], only Access-Reply and Access-Challenge packets are integrity protected 🙀. the integrity protection mechanism described in [1] is weaker than what some EAP methods are likely to use, which makes it possible to subvert those methods by attacking EAP/RADIUS 💀.
so to authenticate every packet in the EAP exchange, all EAP/RADIUS packets MUST be authenticated using the Message-Authenticator attribute, as described previously 🔐🚨.
7.2.3. Man in the middle attacks 🕶️
since RADIUS security is based on shared secrets, end-to-end security is NOT provided when authentication or accounting packets are forwarded along a proxy chain 🔗. as a result, an attacker who takes control of a RADIUS proxy will be able to modify EAP packets in transit 😭.
7.2.4. Multiple databases 🗄️
in lots of cases, a backend security server gets deployed alongside a RADIUS server to provide EAP services. unless the backend security server also works as a RADIUS server, two separate user databases will exist, each holding information about the security requirements for the user 🙃. that's a weakness, because security can be compromised by a successful attack on either server or on their backend databases 💔. with multiple user databases, adding a new user may take multiple operations, which raises the chances of error 🫠. it gets worse when user information is also kept in an LDAP server, because then three stores of user information may exist 🌪️.
to address these threats, consolidation of databases is recommended 🌈✨. this can be done by having both the RADIUS server and backend security server store information in the same backend database, by having the backend security server provide a full RADIUS implementation, or by consolidating both the backend security server and the RADIUS server onto the same machine 🧁.
7.2.5. Negotiation attacks 🕵️♀️
okay so a negotiation attack is literally the sneakiest move 😤 a rogue NAS, tunnel server, RADIUS proxy, or RADIUS server tries to trick the authenticating peer into picking a weaker login method so it's way easier to grab the user's password. like, a session that should totally be EAP gets shoved down to CHAP or PAP, or an EAP connection gets downgraded to a weaker EAP type like MD5. 💀 rogue devices used to feel like a far-off problem, but after the telephone company switching system compromises described in [11], it's giving very real vibes 😬
the fix is to kill every downward negotiation 🔪 and that happens with per-connection policy on the authenticating peer's side, plus per-user policy on the RADIUS server's side.
for the authenticating peer, the policy should be set per connection ✨ that means it can negotiate EAP for one service and CHAP for another, even when both services share the same phone number. iconic, honestly 💅
with per-connection policy, the peer only tries EAP on sessions where EAP is expected 🎯 so if it picks EAP, it's basically saying "I need this level of security." if that can't happen, something's misconfigured, or the peer might be talking to the wrong server entirely 🙈 so if the NAS can't negotiate EAP, or the EAP-Request from the NAS is a different EAP type than what the peer expects, the authenticating peer MUST disconnect. and a peer that's expecting EAP MUST NOT negotiate CHAP or PAP. no exceptions bestie 🚫
now for the NAS, figuring out whether a user needs EAP might not be possible until the user's identity is known 🤔 like on shared-uses NASes, one reseller might do EAP while another doesn't 🍓 so if any users of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every call. this stops an EAP-capable client from having to authenticate twice, which would weaken security 😭 nobody wants a double login that leaks info 🫶
if CHAP gets negotiated, the NAS passes the User-Name and CHAP-Password attributes to the RADIUS server in an Access-Request packet 📦 if the user doesn't need EAP, the server replies with an Access-Accept or Access-Reject, whichever fits. but if CHAP was negotiated and EAP is actually required, the RADIUS server MUST respond with an Access-Reject, NOT an Access-Challenge/EAP-Message/EAP-Request packet 🛑 and the authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation goes from CHAP to EAP. no sneaky switcheroos 🔥
if EAP was negotiated but the RADIUS proxy or server doesn't support it, the server or proxy MUST respond with an Access-Reject 💔 then the NAS MUST send an LCP-Terminate and disconnect the user. this is the right move, because the peer is expecting EAP and that expectation can't be met 🙃 an EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP was negotiated at the start.
ngl this one is a debugging nightmare 😭 an EAP-incapable RADIUS proxy can cause weird problems that are super hard to diagnose. a user dialing in from one location (with an EAP-capable proxy) might log in just fine via EAP, while that same user dialing into another location (with an EAP-incapable proxy) gets disconnected every single time. ✨ if it's inconsistent, check the proxies first 🕵️♀️
8. References 📚
- [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
- [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
- [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
- [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
- [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
- [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
- [9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [11] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995.
9. Acknowledgements 🫶
RADIUS and RADIUS Accounting were originally developed by Livingston Enterprises (now part of Lucent Technologies) for their PortMaster series of Network Access Servers. ✨
The section on ARAP is adopted with permission from "Using RADIUS to Authenticate Apple Remote Access Connections" by Ward Willats of Cyno Technologies (ward@cyno.com). 🍎
The section on Acct-Interim-Interval is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. 💜
The section on EAP is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space. 🌈 the whole crew deserves a group hug 🤗
10. Chair's Address 🎀
the RADIUS working group can be reached through the current chair 📮
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com11. Authors' Addresses 🦋
questions about this memo can also be sent here 💌
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: cdr@telemancy.comquestions on ARAP and RADIUS go to 🍓
Ward Willats
Cyno Technologies
1082 Glen Echo Ave
San Jose, CA 95125
Phone: +1 408 297 7766
EMail: ward@cyno.comquestions on EAP and RADIUS can go to any of these 3 legends 👑
Pat R. Calhoun
Network and Security Research Center
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.comAllan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104
Phone: +1 734 995 1697
EMail: arubens@tutsys.comBernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com12. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved. 💖
the legal bit, word for word, because it matters 🙏
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society. thank you, legends 🧚✨
📦 where this page comes from
- ietf: rfc2869 2000-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms