RFC 2138
Remote Authentication Dial In User Service (RADIUS)
RFC 2138: Remote Authentication Dial In User Service (RADIUS) 🎀
okay so this one is the RADIUS spec, and it's giving "important infrastructure doc" energy 💅 Its category is Standards Track, it's dated April 1997, and it obsoletes RFC 2058 🦋 The header doesn't list any updates. The authors are C. Rigney (Livingston), A. Rubens (Merit), W. Simpson (Daydreamer), and S. Willens (Livingston). Iconic team 👑
Status of this Memo
bestie, this is an Internet standards track protocol for the Internet community 🌈 They're asking for discussion and suggestions for improvements, and you can check the current edition of "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited, so share away ✨
Abstract
so the gist is that this is a protocol for carrying authentication, authorization, and configuration info between a Network Access Server that wants to authenticate its links and a shared Authentication Server 🔐 It's the whole vibe of "who are you, what are you allowed to do, and how should we set you up" 💜
Implementation Note
⚠️ port number drama alert ⚠️
This memo documents the RADIUS protocol. There was some confusion about port numbers, and honestly it's a whole mess 🙈 Early RADIUS deployments used the wrong port, 1645, which clashes with the "datametrics" service. The officially assigned port for RADIUS is 1812, so use that one, bestie 🫶
Table of Contents
1. Introduction .......................................... 3
1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 5
2. Operation ............................................. 5
2.1 Challenge/Response .............................. 7
2.2 Interoperation with PAP and CHAP ................ 7
2.3 Why UDP? ........................................ 8
3. Packet Format ......................................... 10
4. Packet Types .......................................... 13
4.1 Access-Request .................................. 13
4.2 Access-Accept ................................... 14
4.3 Access-Reject ................................... 15
4.4 Access-Challenge ................................ 17
5. Attributes ............................................ 18
5.1 User-Name ....................................... 21
5.2 User-Password ................................... 22
5.3 CHAP-Password ................................... 23
5.4 NAS-IP-Address .................................. 24
5.5 NAS-Port ........................................ 25
5.6 Service-Type .................................... 26
5.7 Framed-Protocol ................................. 28
5.8 Framed-IP-Address ............................... 29
5.9 Framed-IP-Netmask ............................... 29
5.10 Framed-Routing .................................. 30
5.11 Filter-Id ....................................... 31
5.12 Framed-MTU ...................................... 32
5.13 Framed-Compression .............................. 33
5.14 Login-IP-Host ................................... 33
5.15 Login-Service ................................... 34
5.16 Login-TCP-Port .................................. 35
5.17 (unassigned) .................................... 36
5.18 Reply-Message ................................... 36
5.19 Callback-Number ................................. 37
5.20 Callback-Id ..................................... 38
5.21 (unassigned) .................................... 38
5.22 Framed-Route .................................... 39
5.23 Framed-IPX-Network .............................. 40
5.24 State ........................................... 40
5.25 Class ........................................... 41
5.26 Vendor-Specific ................................. 42
5.27 Session-Timeout ................................. 44
5.28 Idle-Timeout .................................... 44
5.29 Termination-Action .............................. 45
5.30 Called-Station-Id ............................... 46
5.31 Calling-Station-Id .............................. 47
5.32 NAS-Identifier .................................. 48
5.33 Proxy-State ..................................... 48
5.34 Login-LAT-Service ............................... 49
5.35 Login-LAT-Node .................................. 50
5.36 Login-LAT-Group ................................. 51
5.37 Framed-AppleTalk-Link ........................... 52
5.38 Framed-AppleTalk-Network ........................ 53
5.39 Framed-AppleTalk-Zone ........................... 54
5.40 CHAP-Challenge .................................. 55
5.41 NAS-Port-Type ................................... 55
5.42 Port-Limit ...................................... 56
5.43 Login-LAT-Port .................................. 57
5.44 Table of Attributes ............................. 58
6. Examples .............................................. 59
6.1 User Telnet to Specified Host ................... 60
6.2 Framed User Authenticating with CHAP ............ 60
6.3 User with Challenge-Response card ............... 61
Security Considerations ...................................... 63
References ................................................... 64
Acknowledgements ............................................. 64
Chair's Address .............................................. 65
Author's Addresses ........................................... 651. Introduction ✨
okay bestie, let's talk about why this exists 💖 Managing dispersed serial line and modem pools for a ton of users can take serious admin effort. Modem pools are literally a door to the outside world, so they need careful attention to security, authorization, and accounting 🔥 The move is to manage one single "database" of users, which handles authentication (checking user name and password) and also configuration info about what kind of service the user gets, like SLIP, PPP, telnet, or rlogin 🧚
Here are the key features of RADIUS, and they're giving main character 💅
Client/Server Model
- A Network Access Server (NAS) acts as a client of RADIUS. The client passes user info along to designated RADIUS servers, then acts on whatever response comes back 🦋
- RADIUS servers receive user connection requests, authenticate the user, and send back all the configuration info the client needs to deliver service to them 👑
- A RADIUS server can also be a proxy client to other RADIUS servers or other kinds of authentication servers 🌸
Network Security
- Transactions between the client and the RADIUS server are authenticated with a shared secret, and that secret is never sent over the network 🔐
- Any user passwords are sent encrypted between the client and RADIUS server. This means someone snooping on an unsecure network can't figure out a user's password 🙈
Flexible Authentication Mechanisms
- The RADIUS server can support a bunch of ways to authenticate a user 🌈 When it gets the user name and original password the user provided, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms ✨
Extensible Protocol
- All transactions are made up of variable length Attribute-Length-Value 3-tuples 🧚 New attribute values can be added without disturbing existing implementations of the protocol, which is so iconic 😭
1.1. Specification of Requirements
okay so this section explains the requirement words used in the spec 💜 They're often capitalized, so watch for them!
- MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. 🔥
- MUST NOT This phrase means that the definition is an absolute prohibition of the specification. 💀
- SHOULD This word, or the adjective "recommended", means there may be valid reasons in particular circumstances to ignore this item. But the full implications must be understood and carefully weighed before choosing a different course. 🤔
- MAY This word, or the adjective "optional", means this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 🦋
1.2. Terminology
this doc uses a few terms over and over, so let's get them down 📝
- 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 is a session. A session begins at the point where service is first provided and ends at the point where service is ended. A user may have multiple sessions in parallel or in 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. Quiet but thorough 🤫🫶
2. Operation ✨
okay so picture this, bestie 🎀 any user of a RADIUS client shows up with their authentication info. Sometimes that's a customizable login prompt where they type in a username and password 💖. Other times they're using a link framing protocol like the Point-to-Point Protocol (PPP), which has authentication packets that carry that same info 🦋.
Once the client has that info, it may choose to authenticate using RADIUS. To do that, the client builds an Access-Request with Attributes like the user's name, the user's password, the ID of the client, and the Port ID the user is accessing 💅. When a password is present, it gets hidden using a method based on the RSA Message Digest Algorithm MD5 [1] 🔐.
The Access-Request gets sent to the RADIUS server over the network 🌐. If no response comes back within a set amount of time, the request gets re-sent a number of times 🔁. The client can also forward requests to an alternate server (or servers) if the primary server is down or unreachable 🛟. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion 🎠. Retry and fallback algorithms are still the topic of current research, so they aren't specified in detail in this document 🧪.
Once the RADIUS server gets the request, it validates the sending client 🛡️. A request from a client that the RADIUS server doesn't have a shared secret for should be silently discarded 🤫. If the client checks out, the RADIUS server looks through a database of users to find the one whose name matches the request 🔍. Each user entry has a list of requirements that must be met before access is allowed 📋. This always includes verifying the password, but it can also specify which client(s) or port(s) the user is allowed to access 🚪.
The RADIUS server MAY make requests of other servers in order to satisfy the request, and in that case it acts as a client 🔄.
If any condition isn't met, the RADIUS server sends back an Access-Reject response saying this user's request is invalid 🙅♀️. If it wants to, the server MAY include a text message in the Access-Reject, which MAY be displayed by the client to the user 💌. No other Attributes are permitted in an Access-Reject 🚫.
If all conditions are met but the RADIUS server wants to issue a challenge that the user has to respond to, the server sends an Access-Challenge response 🧩. It MAY include a text message for the client to display, prompting the user for a response to the challenge, and it MAY include a State attribute 🎯. If the client receives an Access-Challenge and supports challenge/response, it MAY display the text message (if there is one) to the user, and then prompt them for a response 🙋♀️. The client then re-submits its original Access-Request with a new request ID. The User-Password Attribute is replaced by the response (encrypted), and the State Attribute from the Access-Challenge is included, if there is one 🔑. Only 0 or 1 instances of the State Attributes should be present in a request 1️⃣. The server can respond to this new Access-Request with an Access-Accept, an Access-Reject, or another Access-Challenge 🔀.
If all conditions are met, the list of configuration values for the user goes into an Access-Accept response 🎉. These values include the type of service (for example: SLIP, PPP, Login User) and all the values needed to deliver that service 🛠️. For SLIP and PPP, this may include things like IP address, subnet mask, MTU, desired compression, and desired packet filter identifiers 🌈. For character mode users, this may include things like desired protocol and host 💻.
2.1. Challenge/Response
okay so in challenge/response authentication, the user gets an unpredictable number and gets challenged to encrypt it and send back the result 🧠. Authorized users have special devices like smart cards, or software, that make it super easy to calculate the right response 💳. Unauthorized users don't have the right device or software, and they don't know the secret key needed to fake one, so all they can do is guess at the response 🙈.
The Access-Challenge packet usually contains a Reply-Message with a challenge to show the user, like a numeric value that's unlikely to ever be repeated 🔢. Usually this comes from an external server that knows what kind of authenticator the authorized user should have. That server can pick a random or non-repeating pseudorandom number with an appropriate radix and length 🎲.
The user types the challenge into their device (or software), which calculates a response. The user then enters that response into the client, and the client forwards it to the RADIUS server in a second Access-Request 📲. If the response matches the expected one, the RADIUS server replies with an Access-Accept. Otherwise, it replies with an Access-Reject ✅❌.
Here's the example, verbatim:
Example: The NAS sends an Access-Request packet to the RADIUS Server
with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
just be a fixed string like "challenge" or ignored). The server
sends back an Access-Challenge packet with State and a Reply-Message
along the lines of "Challenge 12345678, enter your response at the
prompt" which the NAS displays. The NAS prompts for the response and
sends a NEW Access-Request to the server (with a new ID) with NAS-
Identifier, NAS-Port, User-Name, User-Password (the response just
entered by the user, encrypted), and the same State Attribute that
came with the Access-Challenge. The server then sends back either an
Access-Accept or Access-Reject based on whether the response matches
what it should be, or it can even send another Access-Challenge.2.2. Interoperation with PAP and CHAP
okay so with PAP, the NAS takes the PAP ID and password and sends them in an Access-Request packet as User-Name and User-Password 🗝️. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected 💡.
With CHAP, the NAS makes a random challenge (preferably 16 octets) and sends it to the user, who sends back a CHAP response along with a CHAP ID and CHAP username 🎀. Then the NAS sends an Access-Request packet to the RADIUS server with the CHAP username as the User-Name, and the CHAP ID and CHAP response as the CHAP-Password (Attribute 3) 📦. The random challenge can go in the CHAP-Challenge attribute or, if it's 16 octets long, it can be placed in the Request Authenticator field of the Access-Request packet 🧁. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected 💫.
The RADIUS server looks up a password based on the User-Name. Then it encrypts the challenge using MD5 over the CHAP ID octet, that password, and the CHAP challenge (taken from the CHAP-Challenge attribute if it's there, otherwise from the Request Authenticator), and compares that result to the CHAP-Password 🔍. If they match, the server sends back an Access-Accept. If not, it sends back an Access-Reject 🥳.
If the RADIUS server can't perform the requested authentication, it should return an Access-Reject 🙃. For example, CHAP needs the user's password to be available in cleartext to the server, so the server can encrypt the CHAP challenge and compare it to the CHAP response 🔓. If the password isn't available in cleartext to the RADIUS server, then the server MUST send an Access-Reject to the client 🚨.
2.3. Why UDP?
okay this is the question everyone asks 🙋♀️: why does RADIUS use UDP instead of TCP as its transport protocol? UDP was chosen for strictly technical reasons 🤓.
There are a bunch of issues to get your head around. RADIUS is a transaction-based protocol with a few interesting characteristics 📚:
- If the request to a primary Authentication server fails, a secondary server must be queried.
To make this work, a copy of the request has to be kept above the transport layer so it can be sent somewhere else. That means retransmission timers are still required 🔁.
- The timing requirements of this protocol are super different from what TCP provides ⏱️.
On one end of the spectrum, RADIUS doesn't need "responsive" detection of lost data. The user is happy to wait several seconds for authentication to finish 🫠. The generally aggressive TCP retransmission (based on average round trip time) isn't needed, and neither is the acknowledgement overhead of TCP 🙅♀️.
On the other end, the user isn't willing to wait several minutes for authentication 😤. So the reliable delivery of TCP data two minutes later isn't useful at all 💀. Using an alternate server quickly lets the user get access before they give up 🏃♀️.
- The stateless nature of this protocol makes UDP a great fit 🧚.
Clients and servers come and go. Systems get rebooted or power cycled independently 🔌. Usually that's not a problem, and with creative timeouts and detection of lost TCP connections, code can be written to handle weird events. UDP, however, completely gets rid of all that special handling 🙌. Each client and server can open their UDP transport just once and leave it open through every kind of failure event on the network 💜.
- UDP simplifies the server implementation 🔥.
In the earliest RADIUS implementations, the server was single threaded. That meant one request was received, processed, and returned before the next one could be handled 😩. This was way too much in environments where the back-end security mechanism took real time (1 or more seconds). The server's request queue would fill up, and in places where hundreds of people were getting authenticated every minute, the request turnaround time grew longer than users were willing to wait. This was especially bad when a lookup in a database or over DNS took 30 or more seconds 💀. The obvious fix was to make the server multi-threaded, and that was simple with UDP 🧵. Separate processes were spawned to serve each request, and those processes could respond directly to the client NAS with a simple UDP packet sent to the original transport of the client 🚀.
It's not all a panacea, though 🙈. As noted, using UDP means one thing that TCP builds in has to be handled manually: with UDP, we have to artificially manage retransmission timers to the same server. They don't need the same timing attention that TCP provides, though 🫶. This one penalty is a small price to pay for the advantages UDP brings to this protocol 🎀.
Without TCP we'd probably still be using tin cans connected by string 🥫🧵. But for this particular protocol, UDP is the better choice 👑.
3. Packet Format ✨
okay bestie, let's get into the packet itself 🎀 Exactly one RADIUS packet rides inside the UDP Data field [2], and the UDP Destination Port field says 1812 (decimal). When a reply goes out, the source and destination ports swap places 🦋
Port numbers were kind of a mess for this protocol 💀 Early RADIUS deployments used the wrongly picked port 1645, which clashes with the "datametrics" service. The officially assigned port for RADIUS is 1812, so that's the one to use 🫶
Here's the summary of the RADIUS data format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
The Code field is one octet, and it tells you what kind of RADIUS packet you're looking at 👑 If a packet shows up with an invalid Code field, it gets silently discarded 🙈
Here are the RADIUS Codes (decimal), assigned like this:
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (experimental)
13 Status-Client (experimental)
255 ReservedCodes 4 and 5 live in the RADIUS Accounting document [9], so I'm not getting into them here 🧚 Codes 12 and 13 are reserved for possible future use, and we won't be mentioning them further either ✨
Identifier
The Identifier field is one octet, and it helps match requests with replies 🎀
Length
The Length field is two octets 🌸 It tells you the length of the whole packet, counting the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field should be treated as padding and should be ignored on reception. If the packet is shorter than the Length field says, it should 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 goes out first. This value is used to authenticate the reply from the RADIUS server, and it's also used in the password hiding algorithm 🫶
Request Authenticator
In Access-Request packets, the Authenticator value is a 16 octet random number, and we call it the Request Authenticator 🦋 It SHOULD be unpredictable and unique over the whole lifetime of a secret (the password shared between the client and the RADIUS server). Why? Because if a request value got reused with the same secret, an attacker could reply with a response they'd intercepted earlier 😭 Since the same secret MAY be used to authenticate with servers in totally different geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness 🌈
The Request Authenticator value in an Access-Request packet SHOULD also be unpredictable 👀 Otherwise an attacker could trick a server into responding to a predicted future request, then use that response to pretend to be that server during a future Access-Request. Main villain behavior, honestly 💀
Protocols like RADIUS can't protect against theft of an authenticated session through realtime active wiretapping attacks. BUT generating unique, unpredictable requests can protect against a wide range of active attacks against authentication 🛡️💜
The NAS and RADIUS server share a secret 🔐 That shared secret, followed by the Request Authenticator, goes through a one-way MD5 hash to make a 16 octet digest value. That digest gets xored with the password the user typed in, and the xored result goes into the User-Password attribute in the Access-Request packet. See the User-Password entry in the Attributes section for the more detailed version 🎀
Response Authenticator
The Authenticator field in Access-Accept, Access-Reject, and Access-Challenge packets is called the Response Authenticator 🌸 It holds a one-way MD5 hash calculated over a stream of octets made up of: the RADIUS packet starting from the Code field (including the Identifier and the Length), the Request Authenticator field from the Access-Request packet, the response Attributes, and then the shared secret. Written out, that's:
ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
where + means concatenation 🧚
Administrative Note
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 🔐 It's preferred that the secret be at least 16 octets. That makes the range big enough to protect against exhaustive search attacks 💪 A RADIUS server SHOULD use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so RADIUS requests can be proxied 🦋
When you're using a forwarding proxy, the proxy has to be able to alter the packet as it passes through in each direction 😭 When the proxy forwards the request, it can add a Proxy-State Attribute. When it forwards a response, it removes the Proxy-State Attribute. Since Access-Accept and Access-Reject replies are authenticated on the entire packet contents, stripping the Proxy-State attribute would invalidate the signature in the packet. So the proxy has to re-sign it 💅
Further details of RADIUS proxy implementation are outside the scope of this document 🧚
Attributes
Lots of Attributes can show up more than once. When that happens, the order of Attributes of the same Type SHOULD be preserved 🌈 The order of Attributes of different Types is not required to be preserved 🫶
In the Attributes section below, where the text talks about which packets an attribute is allowed in, only packets with Codes 1, 2, 3 and 11 are covered, along with attributes defined in this document ✨ There's a summary table at the end of the "Attributes" section. To figure out which Attributes are allowed in packets with Codes 4 and 5, check the RADIUS Accounting document [9] 🎀
4. Packet Types 🦋
The RADIUS Packet type is determined by the Code field in the first octet of the Packet 💜
4.1. Access-Request
Description
Access-Request packets get sent to a RADIUS server. They carry info used to figure out whether a user is allowed access to a specific NAS, plus any special services requested for that user 👑 An implementation that wants to authenticate a user MUST transmit a RADIUS packet with the Code field set to 1 (Access-Request) 🔥
When an Access-Request comes in from a valid client, an appropriate reply MUST be transmitted 💅
An Access-Request MUST contain a User-Name attribute 🎀 It SHOULD contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both, although that is not recommended). It MUST contain either a User-Password attribute or a CHAP-Password attribute 🔐 It SHOULD contain a NAS-Port or NAS-Port-Type attribute, or both, unless the type of access being requested doesn't involve a port or the NAS doesn't distinguish among its ports 🌸
An Access-Request MAY contain additional attributes as a hint to the server, but the server is not required to honor the hint 🧚
When a User-Password is present, it gets hidden using a method based on the RSA Message Digest Algorithm MD5 [1] 🫶
A summary of the Access-Request packet format is shown below. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
1 for Access-Request 🎀
Identifier
The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request 🦋 For retransmissions, the Identifier MUST remain unchanged 💅
Request Authenticator
The Request Authenticator value MUST be changed each time a new Identifier is used 🔐
Attributes
The Attribute field is variable in length, and holds the list of Attributes that are required for the type of service, plus any optional Attributes you want to add 🌈
4.2. Access-Accept
Description
Access-Accept packets get sent by the RADIUS server, and they provide the specific configuration info needed to begin delivering service to the user 🫶 If all Attribute values received in an Access-Request are acceptable, then the RADIUS implementation MUST transmit a packet with the Code field set to 2 (Access-Accept) 👑
When an Access-Accept comes in, the Identifier field gets matched with a pending Access-Request 🧚 On top of that, the Response Authenticator field MUST contain the correct response for the pending Access-Request. Invalid packets are silently discarded 💀
A summary of the Access-Accept packet format is shown below. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
2 for Access-Accept ✨
Identifier
The Identifier field is a copy of the Identifier field of the Access-Request that caused this Access-Accept 💖
Response Authenticator
The Response Authenticator value is calculated from the Access-Request value, as described earlier 🦋
Attributes
The Attribute field is variable in length, and contains a list of zero or more Attributes 🎀
4.3. Access-Reject
Description
okay so if any value in the received Attributes isn't acceptable, the RADIUS server MUST send a packet with the Code field set to 3 (Access-Reject) 🙅♀️. It MAY include one or more Reply-Message Attributes with a text message, which the NAS MAY display to the user 💬.
Here's the Access-Reject packet format! Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
It's 3 for Access-Reject, no notes 💅
Identifier
The Identifier field is a copy of the Identifier field of the Access-Request that caused this Access-Reject. So it's matching up with the request, bestie 🎀
Response Authenticator
The Response Authenticator value is calculated from the Access-Request value, as described earlier 🔐
Attributes
The Attributes field is variable in length and holds a list of zero or more Attributes 📦
4.4. Access-Challenge
Description
Okay this one is a whole plot twist 😭 If the RADIUS server wants to send the user a challenge that needs a response, the RADIUS server MUST answer the Access-Request by sending a packet with the Code field set to 11 (Access-Challenge) 🧩.
The Attributes field MAY have one or more Reply-Message Attributes, and MAY have a single State Attribute, or none. No other Attributes are permitted in an Access-Challenge. Strict! 🙅♀️
When an Access-Challenge comes in, the Identifier field gets matched with a pending Access-Request. On top of that, the Response Authenticator field MUST contain the correct response for that pending Access-Request. Invalid packets get silently discarded 👻
If the NAS doesn't support challenge/response, it MUST treat the Access-Challenge as though it had received an Access-Reject instead. No drama, just rejection 💀
If the NAS does support challenge/response, getting a valid Access-Challenge means a new Access-Request SHOULD be sent. The NAS MAY show the text message, if there is one, to the user, and then prompt them for a response. Then it sends its original Access-Request again, but with a new request ID and Request Authenticator. The User-Password Attribute gets replaced by the user's response (encrypted), and it includes the State Attribute from the Access-Challenge, if there is one. Only 0 or 1 instances of the State Attribute can be present in an Access-Request, so one State is the max, periodt 🙌
A NAS that supports PAP MAY forward the Reply-Message to the dialin client and accept a PAP response, which it can use as though the user had entered the response ✨. If the NAS can't do that, it should treat the Access-Challenge as though it had received an Access-Reject instead.
Here's the Access-Challenge packet format, left to right like always 🌈
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
It's 11 for Access-Challenge 🦋
Identifier
The Identifier field is a copy of the Identifier field of the Access-Request that caused this Access-Challenge 🔁
Response Authenticator
The Response Authenticator value is calculated from the Access-Request value, as described earlier 🔐
Attributes
The Attributes field is variable in length and holds a list of zero or more Attributes 📦
5. Attributes ✨
RADIUS Attributes carry the specific authentication, authorization, information and configuration details for the request and reply. This is the good stuff, bestie 💖
Some Attributes MAY be included more than once. What that means is Attribute-specific, and each Attribute description spells it out 🧠
The end of the list of Attributes is indicated by the Length of the RADIUS packet 🏁
Here's the Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [3]. 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 concerns the following values:
A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.
1 User-Name
2 User-Password
3 CHAP-Password
4 NAS-IP-Address
5 NAS-Port
6 Service-Type
7 Framed-Protocol
8 Framed-IP-Address
9 Framed-IP-Netmask
10 Framed-Routing
11 Filter-Id
12 Framed-MTU
13 Framed-Compression
14 Login-IP-Host
15 Login-Service
16 Login-TCP-Port
17 (unassigned)
18 Reply-Message
19 Callback-Number
20 Callback-Id
21 (unassigned)
22 Framed-Route
23 Framed-IPX-Network
24 State
25 Class
26 Vendor-Specific
27 Session-Timeout
28 Idle-Timeout
29 Termination-Action
30 Called-Station-Id
31 Calling-Station-Id
32 NAS-Identifier
33 Proxy-State
34 Login-LAT-Service
35 Login-LAT-Node
36 Login-LAT-Group
37 Framed-AppleTalk-Link
38 Framed-AppleTalk-Network
39 Framed-AppleTalk-Zone
40-59 (reserved for accounting)
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT-PortLength
The Length field is one octet, and indicates the length of this Attribute, including the Type, Length and Value fields. If an Attribute is received in an Access-Request but with an invalid Length, an Access-Reject SHOULD be transmitted. If an Attribute is received in an Access-Accept, Access-Reject or Access-Challenge packet with an invalid length, the packet MUST either be treated an Access-Reject or else silently discarded 🚦
Value
The Value field is zero or more octets and contains information specific to the Attribute. The format and length of the Value field is determined by the Type and Length fields 🧁
Note that a "string" in RADIUS does not require termination by an ASCII NUL, because the Attribute already has a length field. No null-terminator needed, iykyk 🙈
The format of the Value field is one of four data types:
string 0-253 octets
address 32 bit value, most significant octet first.
integer 32 bit value, most significant octet first.
time 32 bit value, most significant octet first -- seconds
since 00:00:00 GMT, January 1, 1970. The standard
Attributes do not use this data type but it is presented
here for possible use within Vendor-Specific attributes.5.1. User-Name
Description
This Attribute indicates the name of the user to be authenticated. It is only used in Access-Request packets 👤
Here's the User-Name 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
1 for User-Name 🏷️
Length
>= 3
String
The String field is one or more octets. The NAS may limit the maximum length of the User-Name, but the ability to handle at least 63 octets is recommended 📏
The format of the username MAY be one of several forms 🌸:
monolithic: Consisting only of alphanumeric characters. This simple form might be used to locally manage a NAS.simple: Consisting only of printable ASCII characters.name@fqdn: SMTP address. The Fully Qualified Domain Name (with or without trailing dot) indicates the realm in which the name part applies.distinguished name: A name in ASN.1 form used in Public Key authentication systems 🔑
5.2. User-Password 🔐
Description
okay so this Attribute holds the password of the user getting authenticated, or whatever the user types in after an Access-Challenge 🫶. It's only used in Access-Request packets, periodt.
On the way out, the password gets totally hidden 🙈. First it's padded at the end with nulls until it's a multiple of 16 octets. Then a one-way MD5 hash is calculated over a stream of octets made of the shared secret followed by the Request Authenticator. That hash gets XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User-Password Attribute.
If the password is longer than 16 characters, a second one-way MD5 hash is calculated over the shared secret followed by the result of the first xor. That hash gets XORed with the second 16 octet segment of the password and placed in the second 16 octets of the String field. 💅
If necessary, this keeps going, with each xor result being used along with the shared secret to make the next hash for the next segment, up to no more than 128 characters. Iconic 😭
The method comes from the book "Network Security" by Kaufman, Perlman and Speciner [4] pages 109-110. Here's a more precise explanation of how it works 🧚
Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc., with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc.
b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor biThe String will contain c(1)+c(2)+...+c(i), where + denotes concatenation.
On receipt, the process is reversed to get the original password 🔄
A summary of the User-Password Attribute format is shown below. The fields are transmitted from 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
2 for User-Password.
Length
At least 18 and no larger than 130.
String
The String field is between 16 and 128 octets long, inclusive.
5.3. CHAP-Password 💜
Description
This Attribute carries the response value from a PPP Challenge-Handshake Authentication Protocol (CHAP) user, answering the challenge. It's only used in Access-Request packets.
The CHAP challenge value is found in the CHAP-Challenge Attribute (60) if it's present in the packet. Otherwise it's in the Request Authenticator field 🌸
A summary of the CHAP-Password Attribute format is shown below. The fields are transmitted from 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 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
3 for CHAP-Password.
Length
19
CHAP Ident
This field is one octet, and contains the CHAP Identifier from the user's CHAP Response.
String
The String field is 16 octets, and contains the CHAP Response from the user.
5.4. NAS-IP-Address 🌐
Description
This Attribute carries the identifying IP Address of the NAS that's asking to authenticate the user. It's only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier SHOULD be present in an Access-Request packet, bestie 🎀
A summary of the NAS-IP-Address Attribute format is shown below. 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
4 for NAS-IP-Address.
Length
6
Address
The Address field is four octets.
5.5. NAS-Port 🔌
Description
This Attribute carries the physical port number of the NAS that's authenticating the user. It's only used in Access-Request packets. Quick heads up: "port" here means a physical connection on the NAS, NOT a TCP or UDP port number 🙃 Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports.
A summary of the NAS-Port Attribute format is shown below. 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
5 for NAS-Port.
Length
6
Value
The Value field is four octets. Despite the size of the field, values range from 0 to 65535 🍓
5.6. Service-Type 👑
Description
This Attribute carries the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. Main character energy, but make sure it's handled 😤
A summary of the Service-Type Attribute format is shown below. 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
6 for Service-Type.
Length
6
Value
The Value field is four octets.
1 Login
2 Framed
3 Callback Login
4 Callback Framed
5 Outbound
6 Administrative
7 NAS Prompt
8 Authenticate Only
9 Callback NAS PromptThe service types are defined as follows when used in an Access-Accept. When used in an Access-Request, they should be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint. 🤏
Login The user should be connected to a host.
Framed A Framed Protocol should be started for the
User, such as PPP or SLIP.
Callback Login The user should be disconnected and called
back, then connected to a host.
Callback Framed The user should be disconnected and called
back, then a Framed Protocol should be started
for the User, such as PPP or SLIP.
Outbound The user should be granted access to outgoing
devices.
Administrative The user should be granted access to the
administrative interface to the NAS from which
privileged commands can be executed.
NAS Prompt The user should be provided a command prompt
on the NAS from which non-privileged commands
can be executed.
Authenticate Only Only Authentication is requested, and no
authorization information needs to be returned
in the Access-Accept (typically used by proxy
servers rather than the NAS itself).
Callback NAS Prompt The user should be disconnected and called
back, then provided a command prompt on the
NAS from which non-privileged commands can be
executed.5.7. Framed-Protocol 🦋
Description
This Attribute indicates the framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets.
A summary of the Framed-Protocol Attribute format is shown below. 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
7 for Framed-Protocol.
Length
6
Value
The Value field is four octets.
1 PPP
2 SLIP
3 AppleTalk Remote Access Protocol (ARAP)
4 Gandalf proprietary SingleLink/MultiLink protocol
5 Xylogics proprietary IPX/SLIP5.8. Framed-IP-Address 🧚♀️
Description
This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint.
A summary of the Framed-IP-Address Attribute format is shown below. 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
8 for Framed-IP-Address.
Length
6
Address
The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. 💖
5.9. Framed-IP-Netmask 🎀
Description
okay so this Attribute tells the NAS which IP netmask to set up for the user when the user is a router to a network 🌐 It MAY be used in Access-Accept packets. It MAY also show up in an Access-Request packet as a hint from the NAS to the server saying "hey, I'd prefer this netmask," but the server is not required to honor the hint 💅
Here's a summary of the Framed-IP-Netmask Attribute format. Fields go 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
It's 9 for Framed-IP-Netmask 🩷
Length
It's 6 🧚
Address
The Address field is four octets, and it holds the IP netmask of the user 🦋
5.10. Framed-Routing 🌸
Description
This Attribute is about the routing method for the user when the user is a router to a network. It's only used in Access-Accept packets 🚏
Here's the Framed-Routing Attribute format. Left to right, as usual 💜
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
10 for Framed-Routing 🍓
Length
6 ✨
Value
The Value field is four octets. Here's what each value means:
0 None
1 Send routing packets
2 Listen for routing packets
3 Send and Listen5.11. Filter-Id 🦋
Description
This Attribute is the name of the filter list for this user. Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet 🫶
Naming a filter list means the filter can be used on different NASes without caring about the filter-list implementation details. Literally so useful 🔥
Here's the Filter-Id Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
11 for Filter-Id 💖
Length
= 3 🌈
String
The String field is one or more octets, and its contents are implementation dependent. It's meant to be human readable and it MUST NOT affect operation of the protocol 🙈 It is recommended that the message contain displayable ASCII characters from the range 32 through 126 decimal 💅
5.12. Framed-MTU 🧚
Description
This Attribute is the Maximum Transmission Unit to be configured for the user, when it isn't negotiated some other way (like PPP). It's only used in Access-Accept packets 🌷
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
12 for Framed-MTU 🫧
Length
6 🎀
Value
The Value field is four octets. Despite the size of the field, values range from 64 to 65535. Big field energy, small range 💅
5.13. Framed-Compression 🌈
Description
This Attribute is a compression protocol to be used for the link. It MAY be used in Access-Accept packets. It MAY also be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint 🤍
More than one compression protocol Attribute MAY be sent. It's the NAS's job to apply the proper compression protocol to the appropriate link traffic 🛠️
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
13 for Framed-Compression 💜
Length
6 🌸
Value
The Value field is four octets. Here's what each value means:
0 None
1 VJ TCP/IP header compression [5]
2 IPX header compression5.14. Login-IP-Host 🔥
Description
This Attribute is the system to connect the user to, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY also be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint 🏠
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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
14 for Login-IP-Host 🧁
Length
6 ✨
Address
The Address field is four octets. The value 0xFFFFFFFF means the NAS SHOULD allow the user to pick an address 🙌 The value 0 means the NAS SHOULD select a host to connect the user to 🎲 Any other value is the address the NAS SHOULD connect the user to 📍
5.15. Login-Service 💅
Description
This Attribute is the service that should be used to connect the user to the login host. It's only used in Access-Accept packets 🎟️
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
15 for Login-Service 🌙
Length
6 🫶
Value
The Value field is four octets. Here's what each value means:
0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster (proprietary)
4 LAT5.16. Login-TCP-Port 🦄
Description
This Attribute is the TCP port the user gets connected on, when the Login-Service Attribute is also present. It's only used in Access-Accept packets 🚪
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
16 for Login-TCP-Port 🎀
Length
6 🍬
Value
The Value field is four octets. Despite the size of the field, values range from 0 to 65535 💫
5.17. (unassigned) 🫥
Description
ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. 🚫 Nothing to see here, bestie 🙈
5.18. Reply-Message 💬
Description
This Attribute is text which MAY be displayed to the user 👀
When it's in an Access-Accept, it's the success message ✅
When it's in an Access-Reject, it's the failure message ❌ It MAY indicate a dialog message to prompt the user before another Access-Request attempt 🔁
When it's in an Access-Challenge, it MAY indicate a dialog message to prompt the user for a response 🗨️
Multiple Reply-Message's MAY be included, and if any are displayed, they MUST be displayed in the same order as they appear in the packet. Order matters, no cap 📜✨
Here's the Reply-Message Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
18 for Reply-Message 🩷
Length
= 3 🌟
String
The String field is one or more octets, and its contents are implementation dependent. It's intended to be human readable, and it MUST NOT affect operation of the protocol 🫶 It is recommended that the message contain displayable ASCII characters from the range 10, 13, and 32 through 126 decimal 📝 Mechanisms for extension to other character sets are beyond the scope of this specification, so that's a different story for a different day 🌍
5.19. Callback-Number 📞
Description
This Attribute is a dialing string to be used for callback. It MAY be used in Access-Accept packets. It MAY also be used in an Access-Request packet as a hint to the server that a Callback service is desired, but the server is not required to honor the hint 🔁
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
19 for Callback-Number ☎️
Length
= 3 🌈
String
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets 🧠 How this field's allowed usage gets codified is outside the scope of this specification 🙃
5.20. Callback-Id ✨
Description 💌
This Attribute names a place to be called, and the NAS is the one who figures out what that means 📞. It MAY show up in Access-Accept packets, so it's totally optional bestie 🦋
A quick peek at the Callback-Id Attribute format is below. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🔢
20 for Callback-Id 🎀
Length 📏
>= 3 💕
String 🧵
The String field is one or more octets 🫧 The actual format is up to the site or application, and a robust implementation SHOULD support the field as undistinguished octets 🧚 The codification of the range of allowed usage of this field is outside the scope of this specification, so that's a whole other vibe 🙈
5.21. (unassigned) 🫥
Description 🌙
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. Nothing to see here, babe 💤
5.22. Framed-Route 🛣️
Description 🗺️
This Attribute gives routing information that gets configured for the user on the NAS 🚦 It's used in the Access-Accept packet and can show up multiple times, so go wild 🌈
A quick peek at the Framed-Route Attribute format is below. The 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🔢
22 for Framed-Route 🎀
Length 📏
>= 3 💕
String 🧵
The String field is one or more octets, and its contents are implementation dependent 🫠 It's meant to be human readable and MUST NOT affect operation of the protocol 🙅♀️ It is recommended that the message contain displayable ASCII characters from the range 32 through 126 decimal 💅
For IP routes, it SHOULD contain a destination prefix in dotted quad form, optionally followed by a slash and a decimal length specifier. That tells you how many high order bits of the prefix to use 🧠 Then comes a space, a gateway address in dotted quad form, another space, and one or more metrics separated by spaces 🎯 For example:
"192.168.1.0/24 192.168.1.1 1 2 -1 3 400"The length specifier can be left out, and then it should default to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes ✨ For example:
"192.168.1.0 192.168.1.1 1"Whenever the gateway address is specified as "0.0.0.0", the IP address of the user SHOULD be used as the gateway address 🫶
5.23. Framed-IPX-Network 🌐
Description 💫
This Attribute says which IPX Network number to configure for the user 🪩 It's used in Access-Accept packets 💌
A quick peek at the Framed-IPX-Network Attribute format is below. The fields go 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 🔢
23 for Framed-IPX-Network 🎀
Length 📏
6 💕
Value 💎
The Value field is four octets 🫧 The value 0xFFFFFFFE means the NAS should pick an IPX network for the user, like one from a pool of IPX networks the NAS keeps 🏊♀️ Other values should be used as the IPX network for the link to the user 🔗
5.24. State 🌀
Description 🪄
This Attribute can be sent by the server to the client in an Access-Challenge, and it MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if there is one 🫵
This Attribute can also be sent by the server to the client in an Access-Accept that includes a Termination-Action Attribute with the value RADIUS-Request. If the NAS performs 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 shouldn't interpret it at all 🙅♀️ A packet may have only one State Attribute, and how it gets used is implementation dependent 🧁
A quick peek at the State Attribute format is below. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🔢
24 for State 🎀
Length 📏
>= 3 💕
String 🧵
The String field is one or more octets 🫧 The actual format is up to the site or application, and a robust implementation SHOULD support the field as undistinguished octets 🧚
The codification of the range of allowed usage of this field is outside the scope of this specification 🙈
5.25. Class 🏷️
Description 🎟️
This Attribute can be sent by the server to the client in an Access-Accept, and the client should send it unmodified to the accounting server as part of the Accounting-Request packet, if accounting is supported 📊 The client shouldn't interpret it at all 🙅♀️
A quick peek at the Class Attribute format is below. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🔢
25 for Class 🎀
Length 📏
>= 3 💕
String 🧵
The String field is one or more octets 🫧 The actual format is up to the site or application, and a robust implementation SHOULD support the field as undistinguished octets 🧚
The codification of the range of allowed usage of this field is outside the scope of this specification 🙈
5.26. Vendor-Specific 🏢
Description 🧩
This Attribute lets vendors support their own extended Attributes that aren't suitable for general usage 🛠️ It MUST not affect the operation of the RADIUS protocol 🫶
Servers that can't interpret the vendor-specific information a client sends MUST ignore it, although it may be reported 📝 Clients that don't receive the vendor-specific information they want SHOULD make an attempt to operate without it, though they may do so (and report that they're doing so) in a degraded mode 🥲
A quick peek at the Vendor-Specific Attribute format is below. The fields go 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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🔢
26 for Vendor-Specific 🎀
Length 📏
>= 7 💕
Vendor-Id 🆔
The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [3] 📚
String 🧵
The String field is one or more octets 🫧 The actual format is up to the site or application, and a robust implementation SHOULD support the field as undistinguished octets 🧚
The codification of the range of allowed usage of this field is outside the scope of this specification 🙈
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields 🧵 The Attribute-Specific field depends on the vendor's definition of that attribute 💡 Here's an example encoding of the Vendor-Specific attribute using this method 👇
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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-5.27. Session-Timeout ⏰
Description ⏳
This Attribute sets the maximum number of seconds of service that can be given to the user before the session ends or a prompt happens 🚪 It's available to be sent by the server to the client in an Access-Accept or Access-Challenge 💌
A quick peek at the Session-Timeout Attribute format is below. The fields go 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 🔢
27 for Session-Timeout 🎀
Length 📏
6 💕
Value 💎
The field is 4 octets, holding a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to stay connected through the NAS 🔌
5.28. Idle-Timeout 💤
Description 🛌
This Attribute sets the maximum number of consecutive seconds of idle connection allowed for the user before the session ends or a prompt happens 😴 It's available to be sent by the server to the client in an Access-Accept or Access-Challenge 💌
A quick peek at the Idle-Timeout Attribute format is below. The fields go 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 🔢
28 for Idle-Timeout 🎀
Length 📏
6 💕
Value 💎
The field is 4 octets, holding a 32-bit unsigned integer with the maximum number of consecutive seconds of idle time this user should be allowed before the NAS disconnects them 🫶
5.29. Termination-Action ✨
Description 💅
okay so this Attribute tells the NAS what it should do once the specified service is finished 🎀 It's only used in Access-Accept packets, so it only shows up when the server says yes 🫶
Here's the layout of the Termination-Action Attribute. Fields go left to right, obviously 🦋
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 🌸
29 for Termination-Action.
Length 🍓
6
Value ✨
The Value field is four octets. Here are the options:
0 Default
1 RADIUS-RequestIf the Value is set to RADIUS-Request, then once the specified service ends the NAS MAY send a new Access-Request to the RADIUS server, and it includes the State attribute if there is one 🧚 (this is the part where the NAS gets to loop back and ask again, bestie 💜)
5.30. Called-Station-Id 📞
Description 🎀
this Attribute lets the NAS send the phone number the user dialed in the Access-Request packet, using Dialed Number Identification (DNIS) or similar tech 🦋 Heads up, this can be different from the number the call actually came in on 🙈 It's only used in Access-Request packets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌈
30 for Called-Station-Id.
Length 🫶
= 3
String 💖
The String field is one or more octets, and it holds the phone number the user's call came in on.
The actual format is site or application specific. Printable ASCII is recommended, but a robust implementation SHOULD support the field as undistinguished octets 😭 The codification of the range of allowed usage of this field is outside the scope of this specification.
5.31. Calling-Station-Id 📱
Description 💜
this Attribute lets the NAS send the phone number the call came from in the Access-Request packet, using Automatic Number Identification (ANI) or similar tech ✨ It's only used in Access-Request packets.
Layout time 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌸
31 for Calling-Station-Id.
Length 🍓
= 3
String 🔥
The String field is one or more octets, and it holds the phone number the user placed the call from.
The actual format is site or application specific. Printable ASCII is recommended, but a robust implementation SHOULD support the field as undistinguished octets 💀 The codification of the range of allowed usage of this field is outside the scope of this specification.
5.32. NAS-Identifier 🪪
Description 🌟
this Attribute holds a string that identifies the NAS sending the Access-Request 💅 It's only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier SHOULD be present in an Access-Request packet, so at least one of them is there to say who's calling 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌈
32 for NAS-Identifier.
Length 🫶
= 3
String 🦋
The String field is one or more octets, and it should be unique to the NAS within the scope of the RADIUS server 🔐 For example, a fully qualified domain name would be suitable as a NAS-Identifier 🌐
The actual format is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification.
5.33. Proxy-State 🧃
Description 🎀
this Attribute can be sent by a proxy server to another server when it forwards an Access-Request 💌 It MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge 🫶 This attribute should be removed by the proxy server before the response is forwarded to the NAS, so the NAS never sees it 🙈
Usage of the Proxy-State Attribute is implementation dependent, and a description of its function is outside the scope of this specification. Don't go guessing what it does, bestie 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌸
33 for Proxy-State.
Length 🍓
= 3
String 💜
The String field is one or more octets. The actual format is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification.
5.34. Login-LAT-Service 🌺
Description 💖
this Attribute indicates the system the user should be connected to by LAT 🧚 It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY also be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint 🫶
Admins use the service attribute with clustered systems, like a VAX or Alpha cluster 🖥️ In that kind of setup, several time sharing hosts share the same resources (disks, printers, etc.), and admins often set each one up to offer access (service) to each of those shared resources. Each host in the cluster then advertises its services through LAT broadcasts 📡
Sophisticated users often know which service providers (machines) are faster, so they tend to use a node name when starting a LAT connection 🏎️ Other times admins want certain users on certain machines as a basic form of load balancing (even though LAT can already load balance itself, lol) ⚖️
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌈
34 for Login-LAT-Service.
Length 🫶
= 3
String 🦋
The String field is one or more octets, and it holds the identity of the LAT service to use. The LAT Architecture lets this string contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension [6]. All LAT string comparisons are case insensitive 🙌
5.35. Login-LAT-Node 🖥️
Description 🌸
this Attribute indicates the Node the user should be automatically connected to by LAT 💫 It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY also be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🍓
35 for Login-LAT-Node.
Length 🌟
= 3
String 💜
The String field is one or more octets, and it holds the identity of the LAT Node to connect the user to. The LAT Architecture lets this string contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive 🫶
5.36. Login-LAT-Group 👑
Description 🌈
this Attribute contains a string identifying the LAT group codes this user is authorized to use 🔑 It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY also be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint 🧚
LAT supports 256 different group codes, and it uses them as a form of access rights. LAT encodes the group codes as a 256 bit bitmap 🧩
Admins can assign one or more of the group code bits at the LAT service provider. The provider will only accept LAT connections that have those group codes set in the bit map 🚪 Admins assign a bitmap of authorized group codes to each user. LAT gets these from the operating system and uses them in its requests to the service providers 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🌸
36 for Login-LAT-Group.
Length 🍓
34
String 💖
The String field is a 32 octet bit map, most significant octet first. A robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification.
5.37. Framed-AppleTalk-Link ✨
Description 🦋
okay so this Attribute tells the NAS which AppleTalk network number to use for the serial link to the user 🌸 the user here is another AppleTalk router, so it's a router talking to a router, which is giving very specific energy 💅 it only shows up in Access-Accept packets, and it is never used when the user isn't another router 🙅♀️
Here's the layout of the Framed-AppleTalk-Link Attribute. Fields go left to right, like reading a text 💖
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 🎀
37 for Framed-AppleTalk-Link ✨
Length 📏
6
Value 💜
the Value field is four octets, but don't let that fool you 🙈 the actual values only go from 0 to 65535. The special value 0 means this is an unnumbered serial link. Any value from 1 to 65535 means the serial line between the NAS and the user should be given that number as its AppleTalk network number 🧚
5.38. Framed-AppleTalk-Network 🌈
Description 🍓
this one tells the NAS which AppleTalk Network number to probe so it can allocate an AppleTalk node for the user 🫶 again it's only for Access-Accept packets, and it's never used when the user is another router. If you include several of these, the NAS can probe any of the network numbers you listed, so it's got options 👑
Here's how the Framed-AppleTalk-Network Attribute is laid out 🦋
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 🎀
38 for Framed-AppleTalk-Network
Length 📏
6
Value 💜
the Value field is four octets, and the values still only go from 0 to 65535 💅 The special value 0 tells the NAS to assign a network to the user using its default cable range. A value from 1 to 65535 (inclusive) is the AppleTalk Network the NAS should probe to find an address for the user 🌸
5.39. Framed-AppleTalk-Zone 💖
Description 🌷
this Attribute gives the AppleTalk Default Zone for this user 🎀 it's only used in Access-Accept packets, and you're NOT allowed to have more than one instance of it in the same packet, so keep it to one, bestie 🙅♀️
Here's the Framed-AppleTalk-Zone 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 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🎀
39 for Framed-AppleTalk-Zone
Length 📏
= 3
String 🧶
this is the name of the Default AppleTalk Zone for this user 🫶 a robust implementation SHOULD support this field as undistinguished octets, so that's the move 💅
How the range of allowed usage for this field gets codified is outside the scope of this specification 🌈
5.40. CHAP-Challenge 🔥
Description 💜
this Attribute carries the CHAP Challenge that the NAS sent to a PPP Challenge-Handshake Authentication Protocol (CHAP) user 🍓 it's only used in Access-Request packets 🦋
If the CHAP challenge value is 16 octets long, it MAY go in the Request Authenticator field instead of using this attribute, which is a super neat shortcut ✨
Here's the CHAP-Challenge 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 🎀
60 for CHAP-Challenge
Length 📏
= 7
String 🧶
the String field holds the CHAP Challenge 💖
5.41. NAS-Port-Type 🌈
Description ✨
this Attribute says what kind of physical port the NAS is using to authenticate the user 🧚 it can be used instead of NAS-Port (5), or alongside it. It's only used in Access-Request packets. If the NAS tells its ports apart, then either NAS-Port (5) or NAS-Port-Type or both SHOULD be in an Access-Request packet, so really it's about giving the server the info it needs 👑
Here's how the NAS-Port-Type Attribute is laid out 🦋
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 🎀
61 for NAS-Port-Type
Length 📏
6
Value 💜
the Value field is four octets 💅 "Virtual" means a connection to the NAS through some transport protocol, rather than a physical port. Like, if a user telnetted into a NAS to authenticate as an Outbound-User, the Access-Request might include NAS-Port-Type = Virtual as a hint to the RADIUS server that the user wasn't on a physical port 🌸 Here are the values:
0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual5.42. Port-Limit 💕
Description 🌷
this Attribute sets the maximum number of ports the NAS provides to the user 🫶 the server MAY send it to the client in an Access-Accept packet, and it's meant for Multilink PPP [7] or similar stuff 🎀 The NAS MAY also send it to the server as a hint that it wants that many ports, but the server is not required to honor the hint 🙈
Here's the Port-Limit layout 🦋
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 🎀
62 for Port-Limit
Length 📏
6
Value 💜
the field is 4 octets, holding a 32-bit unsigned integer with the maximum number of ports this user should be allowed to connect to on the NAS 🧚
5.43. Login-LAT-Port 🌸
Description 🍓
this Attribute says which Port the user should be connected to by LAT 💅 it MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY also be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint 🫶
Here's the Login-LAT-Port 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 🎀
63 for Login-LAT-Port
Length 📏
= 3
String 🧶
the String field is one or more octets, and it holds the identity of the LAT port to use 💖 The LAT Architecture lets this string contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension 🌈 All LAT string comparisons are case insensitive, so capital letters don't matter 🦋
5.44. Table of Attributes 📋
Description 🌷
this table is your cheat sheet for which attributes can show up in which kinds of packets, and how many of each 🧚 Here it is, bestie 💅
Request Accept Reject Challenge # Attribute
1 0 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
0-1 0 0 0 3 CHAP-Password [Note 1]
0-1 0 0 0 4 NAS-IP-Address
0-1 0 0 0 5 NAS-Port
0-1 0-1 0 0 6 Service-Type
0-1 0-1 0 0 7 Framed-Protocol
0-1 0-1 0 0 8 Framed-IP-Address
0-1 0-1 0 0 9 Framed-IP-Netmask
0 0-1 0 0 10 Framed-Routing
0 0+ 0 0 11 Filter-Id
0 0-1 0 0 12 Framed-MTU
0+ 0+ 0 0 13 Framed-Compression
0+ 0+ 0 0 14 Login-IP-Host
0 0-1 0 0 15 Login-Service
0 0-1 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 18 Reply-Message
0-1 0-1 0 0 19 Callback-Number
0 0-1 0 0 20 Callback-Id
0 0+ 0 0 22 Framed-Route
0 0-1 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 24 State
0 0+ 0 0 25 Class
0+ 0+ 0 0+ 26 Vendor-Specific
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0-1 0 0 0 30 Called-Station-Id
0-1 0 0 0 31 Calling-Station-Id
0-1 0 0 0 32 NAS-Identifier
0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 34 Login-LAT-Service
0-1 0-1 0 0 35 Login-LAT-Node
0-1 0-1 0 0 36 Login-LAT-Group
0 0-1 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 38 Framed-AppleTalk-Network
0 0-1 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 60 CHAP-Challenge
0-1 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 62 Port-Limit
0-1 0-1 0 0 63 Login-LAT-Port
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request MUST contain either a User-Password or a
CHAP-Password, and MUST NOT contain both.
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.Note 1 📝
an Access-Request MUST contain either a User-Password or a CHAP-Password, and it MUST NOT contain both. Pick one, babe 💅
6. Examples ✨
okay bestie, this is the fun part 💖 we're gonna walk through a few examples to see how packets actually flow and which attributes show up. these aren't the only possible ones, just the main vibes 🦋
6.1. User Telnet to Specified Host 📞
the NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named nemo logging in on port 3 🐠
Code = 1 (Access-Request)
ID = 0
Length = 56
Request Authenticator = {16 octet random number}
Attributes:
User-Name = "nemo"
User-Password = {16 octets of Password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator)}
NAS-IP-Address = 192.168.1.16
NAS-Port = 3the RADIUS server authenticates nemo and sends back an Access-Accept UDP packet, telling the NAS to telnet nemo to host 192.168.1.3 🖥️✨
Code = 2 (Access-Accept)
ID = 0 (same as in Access-Request)
Length = 38
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (0), Length (38), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Service-Type = Login-User
Login-Service = Telnet
Login-Host = 192.168.1.36.2. Framed User Authenticating with CHAP 🎀
the NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named flopsy logging in on port 20 with PPP, and flopsy is authenticating with CHAP 🔐 the NAS sends along the Service-Type and Framed-Protocol attributes as a little hint to the RADIUS server that this user wants PPP, although the NAS is not required to do so 🙈
Code = 1 (Access-Request)
ID = 1
Length = 71
Request Authenticator = {16 octet random number also used as
CHAP challenge}
Attributes:
User-Name = "flopsy"
CHAP-Password = {1 octet CHAP ID followed by 16 octet
CHAP response}
NAS-IP-Address = 192.168.1.16
NAS-Port = 20
Service-Type = Framed-User
Framed-Protocol = PPPthe RADIUS server authenticates flopsy and sends an Access-Accept UDP packet to the NAS, telling it to start PPP service and assign flopsy an address out of its dynamic address pool 🌈
Code = 2 (Access-Accept)
ID = 1 (same as in Access-Request)
Length = 56
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (1), Length (56), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = 255.255.255.254
Framed-Routing = None
Framed-Compression = 1 (VJ TCP/IP Header Compression)
Framed-MTU = 15006.3. User with Challenge-Response card 🪪
the NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named mopsy logging in on port 7 🧚
Code = 1 (Access-Request)
ID = 2
Length = 57
Request Authenticator = {16 octet random number}
Attributes:
User-Name = "mopsy"
User-Password = {16 octets of Password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator)}
NAS-IP-Address = 192.168.1.16
NAS-Port = 7the RADIUS server decides to challenge mopsy 👀 it sends back a challenge string and waits for a response, so it sends an Access-Challenge UDP packet to the NAS 💜
Code = 11 (Access-Challenge}
ID = 2 (same as in Access-Request)
Length = 78
Response Authenticator = {16-octet MD-5 checksum of the code (11),
id (2), length (78), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Reply-Message = "Challenge 32769430. Enter response at prompt."
State = {Magic Cookie to be returned along with user's response;
in this example 8 octets of data}mopsy types in her response, and the NAS sends a new Access-Request with that response, including the State Attribute 🔑
Code = 1 (Access-Request)
ID = 3 (Note that this changes)
Length = 67
Request Authenticator = {NEW 16 octet random number}
Attributes:
User-Name = "mopsy"
User-Password = {16 octets of Response padded at end with
nulls, XORed with MD5 checksum of shared secret
plus above Request Authenticator}
NAS-IP-Address = 192.168.1.16
NAS-Port = 7
State = {Magic Cookie from Access-Challenge packet, unchanged}the response was incorrect, so the RADIUS server tells the NAS to reject the login attempt 💀
Code = 3 (Access-Reject)
ID = 3 (same as in Access-Request)
Length = 20
Response Authenticator = {16-octet MD-5 checksum of the code (3),
id (3), length(20), the Request Authenticator from
above, the attributes in this reply if any, and the
shared secret}
Attributes:
(none, although a Reply-Message could be sent)Security Considerations 🔒
okay this section is seriously important, so pay attention bestie 🫶 security issues are the primary topic of this whole document 🚨
realistically, inside or alongside each RADIUS server there's a database that links "user" names to authentication information ("secrets") 🗝️ it isn't expected that one named user would be authenticated by multiple methods. that would leave the user open to attacks that negotiate the least secure method from a set 😱 instead, each named user should have an indication of exactly one method used to authenticate that user name. if a user needs different authentication methods in different situations, then distinct user names SHOULD be used, and each one should identify exactly one authentication method ✨
passwords and other secrets should be stored at their respective ends so that access to them is as limited as possible 🤫 ideally, the secrets should only be accessible to the process that needs them in order to do the authentication 🔐
the secrets should be distributed with a mechanism that limits how many entities handle the secret and therefore learn it 🙅♀️ ideally, no unauthorized person should ever gain knowledge of the secrets. it's possible to achieve this with SNMP Security Protocols [8], but that kind of mechanism is outside the scope of this specification 🦋
other distribution methods are still being researched and experimented with 🧪 the SNMP Security document [8] also has an excellent overview of threats to network protocols, so go read it if you're curious 📚
References 📚
[1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
Private Communications in a Public World", Prentice Hall, March
1995, ISBN 0-13-061466-1.
[5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
[6] ISO 8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
Alphabet No. 1, ISO 8859-1:1987.
<URL:http://www.iso.ch/cate/d16338.html>
[7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
Multilink Protocol (MP)", RFC 1717, University of California
Berkeley, Lloyd Internetworking, Newbridge Networks
Corporation, November 1994.
[8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
LAN Systems, Inc., MIT Laboratory for Computer Science, July
1992.
[9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.Acknowledgments 🌸
RADIUS was originally developed by Livingston Enterprises for their PortMaster series of Network Access Servers 🧡
Chair's Address 🎀
the working group can be contacted via the current chair 💌
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510 426 0770
EMail: cdr@livingston.comAuthors' Addresses 👑
questions about this memo can also be directed to these lovely people 🫶
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510 426 0770
EMail: cdr@livingston.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Road
Ann Arbor, Michigan 48105-2785
EMail: acr@merit.edu
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: wsimpson@greendragon.com
Steve Willens
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: steve@livingston.com📦 where this page comes from
- ietf: rfc2138 1997-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms