RFC 2058
Remote Authentication Dial In User Service (RADIUS)
RFC 2058: Remote Authentication Dial In User Service (RADIUS) 💖
okay bestie, this is RFC 2058 and it's giving classic networking doc energy 🎀 It's a Standards Track document from the Network Working Group, dated January 1997. The authors are C. Rigney (Livingston), A. Rubens (Merit), W. Simpson (Daydreamer), and S. Willens (Livingston). The title block doesn't list anything it obsoletes or updates.
Status of This Memo ✨
so this is an Internet standards track protocol for the Internet community, and it literally wants discussion and suggestions for improvements 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract 🦋
this doc describes a protocol for carrying authentication, authorization, and configuration info between a Network Access Server (the one that wants to authenticate its links) and a shared Authentication Server. main character energy for sure 👑
Table of Contents 📚
1. Introduction .......................................... 3
1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 4
2. Operation ............................................. 5
2.1 Challenge/Response .............................. 6
2.2 Interoperation with PAP and CHAP ................ 7
2.3 Why UDP? ........................................ 8
3. Packet Format ......................................... 9
4. Packet Types .......................................... 12
4.1 Access-Request .................................. 12
4.2 Access-Accept ................................... 14
4.3 Access-Reject ................................... 15
4.4 Access-Challenge ................................ 16
5. Attributes ............................................ 17
5.1 User-Name ....................................... 20
5.2 User-Password ................................... 21
5.3 CHAP-Password ................................... 22
5.4 NAS-IP-Address .................................. 23
5.5 NAS-Port ........................................ 24
5.6 Service-Type .................................... 25
5.7 Framed-Protocol ................................. 27
5.8 Framed-IP-Address ............................... 28
5.9 Framed-IP-Netmask ............................... 29
5.10 Framed-Routing .................................. 29
5.11 Filter-Id ....................................... 30
5.12 Framed-MTU ...................................... 31
5.13 Framed-Compression .............................. 32
5.14 Login-IP-Host ................................... 33
5.15 Login-Service ................................... 33
5.16 Login-TCP-Port .................................. 34
5.17 (unassigned) .................................... 35
5.18 Reply-Message ................................... 35
5.19 Callback-Number ................................. 36
5.20 Callback-Id ..................................... 37
5.21 (unassigned) .................................... 37
5.22 Framed-Route .................................... 38
5.23 Framed-IPX-Network .............................. 39
5.24 State ........................................... 39
5.25 Class ........................................... 40
5.26 Vendor-Specific ................................. 41
5.27 Session-Timeout ................................. 43
5.28 Idle-Timeout .................................... 44
5.29 Termination-Action .............................. 44
5.30 Called-Station-Id ............................... 45
5.31 Calling-Station-Id .............................. 46
5.32 NAS-Identifier .................................. 47
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 ........................... 53
5.40 CHAP-Challenge .................................. 54
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 ................... 59
6.2 Framed User Authenticating with CHAP ............ 60
6.3 User with Challenge-Response card ............... 61
SECURITY CONSIDERATIONS ...................................... 62
REFERENCES ................................................... 63
ACKNOWLEDGEMENTS ............................................. 63
CHAIR'S ADDRESS .............................................. 64
AUTHORS' ADDRESSES ........................................... 641. Introduction ✨
okay so managing dispersed serial line and modem pools for a ton of users can take a LOT of admin support 😭 Modem pools are basically a link to the outside world, so they need serious care when it comes to security, authorization, and accounting. The move is to manage one single "database" of users. That gives you authentication (checking the user name and password) plus configuration info about what kind of service to give the user (for example SLIP, PPP, telnet, or rlogin) 💅
Key features of RADIUS are:
1.1. Specification of Requirements 🎀
in this doc, a few words are used to signal the requirements of the spec. They're often capitalized, so here's the lowdown:
- MUST: this word, or the adjective "required", means the definition is an absolute requirement of the spec.
- MUST NOT: this phrase means the definition is an absolute prohibition of the spec.
- SHOULD: this word, or the adjective "recommended", means there can be legit reasons in particular circumstances to ignore this item. But the full implications need to be understood and carefully weighed before picking a different course 🧐
- MAY: this word, or the adjective "optional", means this item is one of an allowed set of alternatives. An implementation that doesn't include this option MUST be prepared to interoperate with another implementation that does include the option 🦋
1.2. Terminology 🧚
this doc frequently uses these terms:
- service: the NAS provides a service to the dial-in user, like 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 can have multiple sessions in parallel or in series if the NAS supports that 🌸
- silently discard: this means the implementation discards the packet without any further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter 🙈
2. Operation ✨
okay so bestie, here's how the whole RADIUS dance goes 💃. A user shows up at a client, the NAS (Network Access Server), and gives it their login info 🔑. That could be a customizable login prompt where they type a username and password, or a link framing protocol like the Point-to-Point Protocol (PPP), which has authentication packets that carry the same info. Either way, the client now has the goods 🎀.
Once the client has the info, it can decide to authenticate with RADIUS 🔐. To do that, it builds an "Access-Request" packet with stuff like the user's name, the user's password, the client's ID, and the Port ID the user is trying to access. If there's a password in there, it gets hidden using a method based on the RSA Message Digest Algorithm MD5 [1]. Very secret, very protected, very slay 🤫.
The Access-Request gets sent to the RADIUS server over the network 🌐. If no response comes back in time, the client re-sends the request a few times 🔁. The client can also forward requests to an alternate server (or servers) if the primary one is down or unreachable 🆘. The alternate can get used after a number of tries to the primary fail, or in a round-robin fashion 🎠. Retry and fallback algorithms are still being researched, so they aren't specified in detail in this document 🧪.
Now when the RADIUS server gets the request, it checks the sending client first 👀. If the server doesn't have a shared secret for that client, the request should be silently discarded 🤐. Rude, but that's the vibe. If the client is valid, the server looks through a database of users to find the one whose name matches ✅. Each user entry has a list of requirements that must be met before access is allowed 📋. Verifying the password is always on that list, but it can also say which clients or ports the user is allowed to access 🚪.
The RADIUS server MAY make requests of other servers in order to satisfy the request, in which case it acts as a client 🤝. Iconic networking behavior, honestly.
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, and the client MAY display that message to the user 💬. No other Attributes are permitted in an Access-Reject 🚫. Hard limit, no exceptions, periodt 💅.
If all conditions are met but the server wants the user to answer a challenge, it sends an "Access-Challenge" response 🧩. It MAY include a text message for the client to display, asking the user to respond to the challenge, and it MAY include a State attribute 🏷️. If the client gets an Access-Challenge and supports challenge/response, it MAY display the text message, if there is one, and then prompt the user for a response 🙋♀️. The client then re-submits its original Access-Request with a new request ID. This time the User-Password Attribute gets replaced by the response (encrypted), and the State Attribute from the Access-Challenge gets included if there was one 🔄. Only 0 or 1 instances of the State Attributes should be present in a request 1️⃣. After that, the server can reply with an Access-Accept, an Access-Reject, or another Access-Challenge. Endless loop vibes 🌀.
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 actually deliver that service 🛠️. For SLIP and PPP, that can mean an IP address, a subnet mask, an MTU, desired compression, and desired packet filter identifiers 🌐. For character mode users, it can mean things like the desired protocol and host 🖥️.
2.1. Challenge/Response 🧠
okay so in challenge/response authentication, the user gets an unpredictable number and has to encrypt it and send the result back 🔢. Authorized users have special devices, like smart cards or software, that make it easy to calculate the correct response 💳. Unauthorized users don't have the right device or software, and they don't know the secret key needed to fake one, so they can only guess at the response 🙈. Not happening, bestie.
The Access-Challenge packet usually has a Reply-Message with a challenge to show the user, like a numeric value that's unlikely ever to repeat 🔢✨. This usually 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's an Access-Reject 🚫.
Here's a full example, because examples are everything 📖:
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 🤝
For PAP, the NAS takes the PAP ID and password and sends them in an Access-Request packet as the 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 💡.
For CHAP, things get a little more involved 🧁. The NAS generates a random challenge (preferably 16 octets) and sends it to the user 🎲. The user 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 go 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 💡.
Then the RADIUS server does the math 🧮. It 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 present, otherwise from the Request Authenticator). It 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 in cleartext on the server so it can encrypt the CHAP challenge and compare it to the CHAP response 🔓. If the RADIUS server doesn't have the password in cleartext, then the server MUST send an Access-Reject to the client 🚨. No exceptions, no vibes-only approvals.
2.3. Why UDP? 🦋
A super frequently asked question is why RADIUS uses UDP instead of TCP as its transport protocol 🤔. Here's the tea: UDP was chosen for strictly technical reasons 💅.
There are a few issues you need to understand first. RADIUS is a transaction based protocol with some pretty interesting characteristics 📚:
- If the request to a primary Authentication server fails, a secondary server must be queried.
To make that work, a copy of the request has to be kept above the transport layer so it can be sent somewhere else. This means retransmission timers are still required 🔁.
- The timing requirements of this protocol are significantly different from what TCP provides ⏱️.
On one end of the spectrum, RADIUS doesn't need a "responsive" detection of lost data 😌. The user is willing 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 to get authenticated 😤. So reliable delivery of TCP data two minutes later isn't useful at all 💀. Quickly switching to an alternate server lets the user get access before they give up 🏃♀️.
- The stateless nature of this protocol makes UDP a natural 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 🧩. But UDP completely eliminates any of that special handling 🙌. Each client and server can open their UDP transport just once and leave it open through all types of failure events 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 even started. This was unmanageable in environments where the back-end security mechanism took real time (1 or more seconds) 🐢. The server request queue would fill up. In places where hundreds of people were being authenticated every minute, the turnaround time got longer than users were willing to wait. This was especially bad when a specific lookup in a database or over DNS took 30 or more seconds 😭. The obvious fix was making the server multi-threaded 🧵. With UDP, that was simple. Separate processes were spawned to serve each request, and they could respond directly to the client NAS with a simple UDP packet sent back to the original transport of the client 🚀.
It's not all a panacea, though 🙈. As noted, using UDP means one thing that TCP handles for you has to be managed by hand. With UDP, we have to artificially manage retransmission timers to the same server 🛎️. They don't need the same timing attention that TCP gives, but it's still work. This one penalty is a small price to pay for the advantages UDP brings to this protocol 💖.
Without TCP we would still probably be using tin cans connected by string 🥫🧵. But for this particular protocol, UDP is the better choice, and that's the whole tea 🫶✨.
3. Packet Format 💖
okay bestie, so exactly one RADIUS packet gets tucked inside the UDP Data field [2] 🎀, and the UDP Destination Port is set to 1812 (decimal) 💅. when a reply gets made, the source and destination ports swap places 🔄
here's the RADIUS data format at a glance 👀. fields get sent 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 holding 🧚. if a packet shows up with an invalid Code field, it just gets silently discarded 🫥 (ghosted, literally).
here's how the Code numbers (decimal) are assigned 📋:
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 get their own story in the RADIUS Accounting document [9], so I'm not going to talk about them further here 📚. codes 12 and 13 are kept aside for possible future use, and I'm skipping them too 🙈
Identifier
the Identifier field is one octet, and it helps match requests up with their 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 sitting 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 is, 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 is transmitted first. this value is used to authenticate the reply from the RADIUS server, and it's also used in the password hiding algorithm. so it's doing double duty, iconic 👑
Request Authenticator
in Access-Request packets, the Authenticator value is a 16 octet random number, called the Request Authenticator 🎲. the value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server). why? because if a request value got repeated with the same secret, an attacker could reply with a response they had intercepted earlier. 💀 the scary part is real.
since the same secret MAY be used to authenticate with servers in disparate 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, lest an attacker trick a server into responding to a predicted future request. then they could use that response to masquerade as that server to a future Access-Request. not a vibe 😭
although protocols such as RADIUS can't protect against theft of an authenticated session through realtime active wiretapping attacks, generating unique, unpredictable requests can protect against a wide range of active attacks against authentication 🛡️ that's the main character move right there.
the NAS and the RADIUS server share a secret 🤫. that shared secret, followed by the Request Authenticator, goes through a one-way MD5 hash to create a 16 octet digest value. that digest gets xored with the password the user typed in, and the xored result is placed in the User-Password attribute in the Access-Request packet 🔐. check the entry for User-Password in the section on Attributes for the full, detailed version 📖
Response Authenticator
the value of 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. followed by the shared secret, obvs. written out it's:
ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)where + denotes 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. this makes sure there's a big enough range for the secret to hold up 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 that 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. because Access-Accept and Access-Reject replies are authenticated over 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
plenty of Attributes can show up more than once. in that case, the order of Attributes of the same Type SHOULD be preserved 📋. the order of Attributes of different Types is not required to be preserved. chill 😌
in the section below on "Attributes", 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, go 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 are sent to a RADIUS server 📨. they carry the info used to decide 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) 🔓
upon receipt of an Access-Request 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's hidden using a method based on the RSA Message Digest Algorithm MD5 [1] 🕵️♀️
here's a summary of the Access-Request packet format. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 bring along 🎁
4.2. Access-Accept
Description
Access-Accept packets are sent by the RADIUS server 🎉. they provide the specific configuration info needed to start 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) ✅. on reception of an Access-Accept, the Identifier field is matched with a pending Access-Request. additionally, the Response Authenticator field MUST contain the correct response for the pending Access-Request. invalid packets are silently discarded 🫥
here's a summary of the Access-Accept packet format. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 holds a list of zero or more Attributes 🌈
4.3. Access-Reject 🚫✨
Description
okay so if ANY of the Attributes the server gets back are not 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 what the Access-Reject packet looks like. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
It's 3 for Access-Reject 🍓
Identifier
This is a copy of the Identifier field from the Access-Request that caused this Access-Reject. Main character matching energy 👑
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 holds a list of zero or more Attributes 💜
4.4. Access-Challenge 🌸
Description
If the RADIUS server wants to send the user a challenge that needs a response, then 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 🙈.
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 are silently discarded 💀.
If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead 🙅♀️.
If the NAS does support challenge/response, getting a valid Access-Challenge means a new Access-Request SHOULD be sent 🦋. The NAS MAY display the text message, if there is one, to the user, and then prompt the user for a response. It then sends its original Access-Request with a new request ID and Request Authenticator, with the User-Password Attribute replaced by the user's response (encrypted), and including 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 🎀.
A NAS that supports PAP MAY forward the Reply-Message to the dialin client and accept a PAP response, which it can then use as though the user had typed the response in 🌈. If the NAS cannot do that, it should treat the Access-Challenge as though it had received an Access-Reject instead 😭.
Here's the Access-Challenge packet format. Fields go left to right, same as 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
This is a copy of the Identifier field from 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. They're basically the juicy details 🍓
Some Attributes MAY be included more than once. What that does is specific to each Attribute, and it's spelled out in each Attribute's description 🌸.
The end of the Attribute list is marked by the Length of the RADIUS packet 🧚.
Here's the Attribute format. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
The Type field is one octet. Up-to-date values of the RADIUS Type field are 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 covers 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 says how long this Attribute is, counting the Type, Length and Value fields 📏. If an Attribute arrives in an Access-Request with an invalid Length, an Access-Reject SHOULD be sent 🙅♀️. If an Attribute arrives in an Access-Accept, Access-Reject or Access-Challenge packet with an invalid length, the packet MUST either be treated as an Access-Reject or else 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 🦋.
Note that a "string" in RADIUS does not need to end with an ASCII NUL, because the Attribute already has a length field 💅.
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's included here for possible use within Vendor-Specific attributes 🕰️.
5.1. User-Name 💖
Description
This Attribute says who the user is that needs to be authenticated 🫶. It's only used in Access-Request packets 🎀.
Here's the User-Name Attribute format. 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
It's 1 for User-Name 🍓
Length
>= 3 📏
String
The String field is one or more octets. The NAS may limit how long the User-Name can be, but it's recommended that it can handle at least 63 octets 🌸.
The format of the username MAY be one of several forms 💅:
- monolithic: Consists only of alphanumeric characters. This simple form might be used to locally manage a NAS 🧁.
- simple: Consists 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 being authenticated, or whatever the user types in after an Access-Challenge 🔐 It's only used in Access-Request packets.
bestie, the password gets hidden when it's sent 🙈 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 the shared secret followed by the Request Authenticator. That hash gets XORed with the first 16 octet segment of the password, and the result goes into the first 16 octets of the String field.
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 that first xor. It gets XORed with the second 16 octet segment, and goes into the second 16 octets of the String field ✨
if needed, this keeps going, with each xor result used with the shared secret to make the next hash for the next segment, up to no more than 128 characters. the whole thing is giving layers 🧅
the method comes from the book "Network Security" by Kaufman, Perlman and Speciner [4] pages 109-110. here's the more precise version:
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. reverse engineering, but make it secure 🔥
Format 🧩
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 holds 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 lives in the CHAP-Challenge Attribute (60) if that's in the packet. If it isn't, the value is in the Request Authenticator field instead 🫶
Format 🧩
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 holds the CHAP Identifier from the user's CHAP Response.
String 🧵
the String field is 16 octets, and holds the CHAP Response from the user.
5.4. NAS-IP-Address 🌐
Description 💖
this Attribute indicates the identifying IP Address of the NAS that's asking for authentication of 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. the NAS really should show up with one of these, no cap 🙌
Format 🧩
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 indicates 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.
Format 🧩
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. Even though the field is that big, values only go from 0 to 65535 💁♀️
5.6. Service-Type 👑
Description 🌸
this Attribute indicates the type of service the user has asked for, or the type of service that's going 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. lowkey strict, but it's fair 😤
Format 🧩
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 mean the following when they're used in an Access-Accept. When they're 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.
Format 🧩
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. the server can say no, bestie 🙃
Format 🧩
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 means the NAS should let the user pick an address (e.g. Negotiated). The value 0xFFFFFFFE means the NAS should pick an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values mean 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 configure for the user when the user is a router connecting to a network 🌐. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint from the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint 💅.
Here's the Framed-IP-Netmask format. Read it 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
6
Address
The Address field is four octets specifying the IP netmask of the user.
5.10. Framed-Routing 🧚
Description
This one is giving routing method for the user, when the user is a router to a network 🛣️. It is only used in Access-Accept packets.
Format time:
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, and these are the vibes:
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.
Identifying a filter list by name is so smart, bestie. It lets the filter work on different NASes without caring about how each filter-list implementation works under the hood 🧠.
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
11 for Filter-Id 🎟️.
Length
>= 3
String
The String field is one or more octets, and what's in it is 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.
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 is only used in Access-Accept packets.
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. I know, that's a lot of room, but the values only range from 64 to 65535 📏.
5.13. Framed-Compression 💜
Description
This Attribute is the compression protocol to be used for the link 🗜️. It MAY be used in Access-Accept packets. It MAY 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 is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic 🎯.
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, and the menu is:
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 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.
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 select an address 🙋♀️. The value 0 means the NAS SHOULD select a host to connect the user to 🎲. Other values mean 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 is only used in Access-Accept packets.
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, and the options are:
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 is connected with, when the Login-Service Attribute is also present 🚪. It is only used in Access-Accept packets.
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. Type 17 is just sitting there, unassigned, no cap 💀.
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, periodt.
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 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 10, 13, and 32 through 126 decimal. Mechanisms for extension to other character sets are beyond the scope of this specification 🌍.
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 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.
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 🧩.
The codification of the range of allowed usage of this field is outside the scope of this specification 📚.
5.20. Callback-Id ✨
Description
okay so this Attribute names a place to be called, and the NAS is the one who figures out what to do with it 📞 It MAY be used in Access-Accept packets 💖
Here's the shape of the Callback-Id Attribute. Fields go left to right, obviously 🎀
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
It's 20 for Callback-Id 🦋
Length
It has to be >= 3 🌸
String
The String field is one or more octets 💅 What the info actually means is up to each site or app, and a robust implementation SHOULD support the field as undistinguished octets 🫶 How you're allowed to use this field is outside the scope of this spec, so don't look here for that 🙈
5.21. (unassigned)
Description
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. 💀 nothing to see here, bestie 🧚
5.22. Framed-Route 🛣️
Description
This Attribute hands out routing info that gets configured for the user on the NAS 🗺️ It shows up in the Access-Accept packet and can appear multiple times 👑
Here's the Framed-Route layout, 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 22 for Framed-Route ✨
Length
It has to be >= 3 💖
String
The String field is one or more octets, and what's in it is 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, and you can optionally add a slash plus a decimal length specifier. That tells you how many high order bits of the prefix should be used 🎯 After that comes a space, a gateway address in dotted quad form, another space, and then 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 off, 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 gets configured for the user 🌐 It's used in Access-Accept packets 🦄
Here's the layout, fields 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 23 for Framed-IPX-Network 💜
Length
It's 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 around 🧚 Any other value 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 🔐
It can also be sent by the server to the client in an Access-Accept that includes a Termination-Action Attribute with the value of RADIUS-Request 🛑 If the NAS does 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, no interpretation by the client should be made 🙈 A packet may have only one State Attribute 🦋 Using the State Attribute is implementation dependent 🌸
Here's the State layout, 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
It's 24 for State ✨
Length
It has to be >= 3 💖
String
The String field is one or more octets 💅 What the info actually means is up to each site or app, and a robust implementation SHOULD support the field as undistinguished octets 🫶 How you're allowed to use this field is outside the scope of this spec 🙈
5.25. Class 🏷️
Description
The server can send this Attribute to the client in an Access-Accept, and the client should send it back unmodified to the accounting server as part of the Accounting-Request packet if accounting is supported 📊 No interpretation by the client should be made 🙈
Here's the Class layout, 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
It's 25 for Class 🌈
Length
It has to be >= 3 💖
String
The String field is one or more octets 💅 What the info actually means is up to each site or app, and a robust implementation SHOULD support the field as undistinguished octets. How you're allowed to use this field is outside the scope of this spec 🫶
5.26. Vendor-Specific 🏢
Description
This Attribute lets vendors support their own extended Attributes that aren't suitable for general use 🧩 It MUST not affect the operation of the RADIUS protocol 🔒
Servers that can't interpret the vendor-specific info a client sends MUST ignore it, although it may be reported 📝 Clients that don't get the vendor-specific info they wanted SHOULD make an attempt to operate without it, although they may do so (and report that they're doing so) in a degraded mode 🥲
Here's the Vendor-Specific layout, 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
It's 26 for Vendor-Specific 🦋
Length
It has to be >= 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 [2] 🧠
String
The String field is one or more octets 💅 What the info actually means is up to each site or app, and a robust implementation SHOULD support the field as undistinguished octets 🫶 How you're allowed to use this field is outside the scope of this spec 🙈
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields, like this 🧁 The Attribute-Specific field depends on how the vendor defines 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 max number of seconds of service the user gets before the session or prompt ends 💅 The server can send it to the client in an Access-Accept or Access-Challenge 🌸
Here's the layout, 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 27 for Session-Timeout 🧁
Length
It's 6 🍓
Value
The field is 4 octets, holding a 32-bit unsigned integer with the max number of seconds this user should be allowed to stay connected by the NAS 🫶
5.28. Idle-Timeout 💤
Description
This Attribute sets the max number of consecutive seconds of idle connection the user is allowed before the session or prompt ends 🥱 The server can send it to the client in an Access-Accept or Access-Challenge 🌈
Here's the layout, 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 28 for Idle-Timeout 🍓
Length
It's 6 💖
Value
The field is 4 octets, holding a 32-bit unsigned integer with the max number of consecutive seconds of idle time this user should be allowed before the NAS disconnects them 🫧
5.29. Termination-Action 💖
Description
Okay bestie, this Attribute tells the NAS what to do once the service is finished 🎀 It only shows up in Access-Accept packets, so it's the server's little note to the NAS. 💅
Here's the format. 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
It's 29 for Termination-Action ✨
Length
It's 6 🌸
Value
The Value field is four octets long 🧚
0 Default
1 RADIUS-RequestNow the spicy part 🔥 If the Value is set to RADIUS-Request, then when the specified service ends, the NAS MAY send a new Access-Request to the RADIUS server, and it can include the State attribute if there is one. Iconic behaviour, honestly 👑
5.30. Called-Station-Id 🦋
Description
This Attribute lets the NAS put the phone number the user dialed into the Access-Request packet 📞 It uses Dialed Number Identification Service (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.
Format time 🍓 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
It's 30 for Called-Station-Id 💜
Length
It's >= 3 ✨
String
The String field is one or more octets, and it holds the phone number that the user's call came in on 📱
The actual format is up to the site or application, so it's pretty flexible 🌈 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 💅 It uses Automatic Number Identification (ANI) or similar tech. It's only used in Access-Request packets.
Format check 🎀 Left to right, always:
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
It's 31 for Calling-Station-Id 🌸
Length
It's >= 3 🦋
String
The String field is one or more octets, and it contains the phone number that the user placed the call from ☎️
Same deal as the Called-Station-Id: the 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 is a string that identifies the NAS that sent 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 pick your fighter 👑
Format, babe 🍓
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
It's 32 for NAS-Identifier 💜
Length
It's >= 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 🔥 A fully qualified domain name would be a super suitable NAS-Identifier, iconic 🌈
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, and 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 goes on to the NAS.
How it gets used is implementation dependent 🧚 A description of its function is outside the scope of this specification.
Heads up, this one is a bit of a secret keeper. It MUST come back exactly as it was sent, so don't go changing it 🙈
Format 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
It's 33 for Proxy-State 🌸
Length
It's >= 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 tells the system the user should be connected to over 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 doesn't have to honor the hint 🤷♀️
Okay, the backstory is iconic 👑 Administrators use the service attribute with clustered systems, like a VAX or Alpha cluster. In that setup, a bunch of time-sharing hosts share the same resources (disks, printers, etc.), and admins usually set each one up to offer access to 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 🏎️ Some admins also want certain users on certain machines, kind of as a primitive form of load balancing, even though LAT can balance load on its own 🧚
Format, obviously 🎀
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
It's 34 for Login-LAT-Service 💜
Length
It's >= 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, so no stressing about capital letters 💅
5.35. Login-LAT-Node 🍓
Description
This Attribute says which 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 💖
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
It's 35 for Login-LAT-Node 🧚
Length
It's >= 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 allows the same character set as the LAT service string: $ (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 holds a string that identifies 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 has 256 different group codes, and it uses them as a form of access rights 🔥 LAT encodes the group codes as a 256 bit bitmap, which is very giving bit-level energy 🤓
Admins can assign one or more of the group code bits at the LAT service provider, and the provider will only accept LAT connections that have those group codes set in the bitmap 🛡️ The admins assign a bitmap of authorized group codes to each user. LAT gets those from the operating system and uses them in its requests to the service providers. Main character energy 👑
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
It's 36 for Login-LAT-Group 🌸
Length
It's 34 🎀
String
The String field is a 32 octet bit map, with the 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 one is giving serial link vibes 🌸 It's the AppleTalk network number that should be used for the serial link to the user, and the user is another AppleTalk router (router-to-router, very iconic). It only shows up in Access-Accept packets, and it is never used when the user isn't another router. no cap, it's a strict bouncer 💅
A summary of the Framed-AppleTalk-Link 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
37 for Framed-AppleTalk-Link 🎀
Length
6
Value
The Value field is four octets 🧚 Even though the field is that big, values only range from 0 to 65535. The special value of 0 means this is an unnumbered serial link (no network number, very minimalist 🤍). A value of 1-65535 means the serial line between the NAS and the user should be assigned that value as an AppleTalk network number.
5.38. Framed-AppleTalk-Network 🌈
Description
this one is the network number the NAS should probe so it can allocate an AppleTalk node for the user 🔥 It's only used in Access-Accept packets, and it's never used when the user is another router. Multiple instances of this Attribute are allowed, and they mean the NAS may probe using any of the network numbers specified. so basically it's like "hey, try these networks, any of them is fine" 🫶
A summary of the Framed-AppleTalk-Network 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
38 for Framed-AppleTalk-Network ✨
Length
6
Value
The Value field is four octets. Despite the size, values range from 0 to 65535. The special value 0 means the NAS should assign a network for the user, using its default cable range (the NAS just picks, bestie 🧁). A value between 1 and 65535 (inclusive) means the AppleTalk Network the NAS should probe to find an address for the user.
5.39. Framed-AppleTalk-Zone 🌸
Description
this one is the AppleTalk Default Zone to be used for this user 💜 It's only used in Access-Accept packets. Multiple instances of this attribute in the same packet are not allowed (one zone, periodt 💅).
A summary of the Framed-AppleTalk-Zone 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type
39 for Framed-AppleTalk-Zone 🎀
Length
= 3
String
This is the name of the Default AppleTalk Zone to be used for this user. A robust implementation SHOULD support the field as undistinguished octets. (a strong implementation really should handle it that way, that's the vibe 🫶)
The codification of the range of allowed usage of this field is outside the scope of this specification. (somebody else's problem, bestie, not this doc's 💅)
5.40. CHAP-Challenge 🔐
Description
this one holds 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 be placed in the Request Authenticator field instead of using this attribute. (so it's optional, which is very chill 🌈)
A summary of the CHAP-Challenge 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
TypeType
60 for CHAP-Challenge 🧚
Length
= 7
String
The String field contains the CHAP Challenge.
5.41. NAS-Port-Type 🔥
Description
this one tells you the type of the physical port of the NAS that's authenticating the user 🦋 It can be used instead of or in addition to the NAS-Port (5) attribute. It's only used in Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. (so that's the recommended combo, slay ✨)
A summary of the NAS-Port-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
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, instead of through a physical port. For example, if a user telnetted into a NAS to authenticate himself as an Outbound-User, the Access-Request might include NAS-Port-Type = Virtual as a hint to the RADIUS server that the user was not on a physical port (the server gets the tea 🫖👀).
0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual5.42. Port-Limit 👑
Description
this one sets the maximum number of ports the NAS provides to the user 🌈 This Attribute MAY be sent by the server to the client in an Access-Accept packet. It's meant for Multilink PPP [7] or similar stuff. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint (the server can say no, that's allowed 💅).
A summary of the Port-Limit 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
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 one says which Port the user is supposed to 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 be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint (same energy as Port-Limit, the server has the final say 🫶).
A summary of the Login-LAT-Port 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
63 for Login-LAT-Port 🎀
Length
= 3
String
The String field is one or more octets, and holds the identity of the LAT port to use. The LAT Architecture allows this string to 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 (no "Port" vs "port" drama, we don't do that here 💅).
5.44. Table of Attributes 📋
The following table is a cute little guide to which attributes can show up in which kinds of packets, and how many of each. It's the cheat sheet you'll want bookmarked 🌈
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. (one or the other, never both, that's the rule 🙅♀️)
The following table defines what the entries in the table above mean 🧁
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.6. Examples ✨
okay so bestie, this section is literally the fun part 🎀 it's a few examples showing how packets flow and which attributes show up. they are NOT the full list, there are tons of other ways this could go 🦋
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
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 to the NAS, telling it to telnet nemo to host 192.168.1.3 🧚
Code = 2 (Access-Accept)
ID = 0 (same as in Access-Request)
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (0), 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, using CHAP 🌈 the NAS sends along the Service-Type and Framed-Protocol attributes as a hint that this user wants PPP, but the NAS is not required to do that 🙈
Code = 1 (Access-Request)
ID = 1
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 an address for the user out of its dynamic address pool 🦋
Code = 2 (Access-Accept)
ID = 1 (same as in Access-Request)
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (1), 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
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, sending back a challenge string and waiting 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)
Response Authenticator = {16-octet MD-5 checksum of the code (11),
id (2), 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}the user enters their response, and the NAS sends a new Access-Request with that response and includes the State Attribute 😭
Code = 1 (Access-Request)
ID = 3 (Note that this changes)
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)
Response Authenticator = {16-octet MD-5 checksum of the code (3),
id (3), 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 🔒
Security issues are the primary topic of this document. This part is important, bestie, so read it carefully 👑
in practice, within or associated with each RADIUS server, there is a database that links "user" names to authentication information ("secrets") 🗝️ it is not anticipated that one named user would be authenticated by multiple methods. that would make the user vulnerable 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 circumstances, then distinct user names SHOULD be employed, each identifying 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 to perform the authentication 🧱
the secrets should be distributed with a mechanism that limits how many entities handle (and therefore learn) the secret. ideally, no unauthorized person should ever learn the secrets. this is possible with SNMP Security Protocols [8], but that mechanism is outside the scope of this specification 🙅♀️
other distribution methods are currently being researched and experimented with. the SNMP Security document [8] also has an excellent overview of threats to network protocols 📚
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 J. Davin, "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 2059, January 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
6920 Koll Center Parkway, Suite 220
Pleasanton, California 94566
Phone: +1 510 426 0770
EMail: cdr@livingston.comAuthors' Addresses 🦋
questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
6920 Koll Center Parkway, Suite 220
Pleasanton, California 94566
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
6920 Koll Center Parkway, Suite 220
Pleasanton, California 94566
EMail: steve@livingston.com📦 where this page comes from
- ietf: rfc2058 1997-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms