Introduction to Radius Authentication Protocol-and RFC guidance

The usual, first-glance wiki: Remote User dial-in authentication Service (RADIUS, Remote authentication Dial in User Service) is an AAA protocol that means simultaneous verification (authentication), A Network transport Protocol (Protocol) for licensing (authorization) and billing (accounting) Three services, typically used for network access, or mobile IP services, for LAN and roaming services.
Https://zh.wikipedia.org/wiki/RADIUS

The above introduction is from Wikipedia. Speak of authority, but not too understood. We will cover the following issues in detail here, in the hope that the first contact radius of the small partners to help:

1) What Radius is exactly.
2) Radius application and mode of operation.
3) Radius of the Protocol details.

I. What is Radius in the end.

The above Wikipedia is very specific, Radius remote dial-in service, it integrates authentication, authorization and billing functions. How do you understand this problem? For a not very appropriate chestnut, broadband ADSL dial-up access to the background authentication and billing system can be used in radius, or the v-p-n system of the background verification billing system is the use of radius scenarios.

Of course, the concept of radius can not be limited to "dial", in fact, not only this "dial-up" service, and almost any other service, the use of RADIUS for authentication, authorization and billing services.

Two. how Radius works.

We take the example of building v-p-n to describe how radius works.

The figure has three roles, V-p-n (hereinafter referred to as the XXX server) server, client and RADIUS server.

Radius primarily works between the XXX server and the RADIUS server, and the customer is almost directly inaccessible.

For the RADIUS protocol, the XXX server is actually a client, and the RADIUS server is the server that really provides the service.
(If you look at an English document, the RFC has chapters that specifically explain client and server.)

In this way, radius is more like the protocol of the C/S mode.

So the discussion behind the main focus on the XXX server and RADIUS server, please do your own brain repair.

Three. Radius of the Protocol details.
Here's an introduction to the general details, highlighting how to read the RfC. With the direction, it's much easier to read the RFC again. It is not the responsibility of the RFC to describe in detail how each byte is generated.

As a reference, this is the radius of the rfc:https://tools.ietf.org/html/rfc2865

1) First, RADIUS is a UDP-based protocol, and all packets are encapsulated in the UDP protocol.
As to why UDP, rather than TCP, see the RFC explanation: why UDP?

2) The format of the RADIUS protocol package.
Basically, the RADIUS protocol has four types of packages:

Access-RequestAccess-AcceptAccess-RejectAccess-Challenge

All four types of packages have a uniform format: https://tools.ietf.org/html/rfc2865#page-13

These four packages communicate between the XXX server and the RADIUS server to complete the process.

, the first three interactions are required, and the next two green asterisks are not required.

First, the XXX server sends a ACCESS-REQUEST packet to radius, which contains information such as user information and password hashes for authentication.
At this point the server has four choices:
First, if the authentication passes, it returns a "access-accept" packet, and the authentication is completed.
Second, if the authentication does not pass, then return "Access-reject", authentication fails.
Thirdly, if the server deems it necessary, it can return a "access-challenge" packet, allowing the user to provide additional information to complete the authentication. The XXX server, after receiving the "Access-challenge" message, needs to ask the user for additional information, and then form a new "access-request" packet to the RADIUS server to continue authentication. At this point the server can repeat first, or second.
Finally, if there is a problem with the "access-request" packet, the server can also take a "silent discard" (silently discard) way, without any reaction.

This is the main communication flow.

Generally speaking, the format of the "Access-request" packet is important as a RADIUS client. He is responsible for encrypting the authentication information to the RADIUS server.
Let's introduce the format of the "Access-request" packet:
Https://tools.ietf.org/html/rfc2865#page-17

  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 ...   +-+-+-+-+-+-+-+-+-+-+-+-+-

We now introduce the "Attributes" data area later. This contains the user's password information.
The RADIUS protocol encapsulates identity information, such as username, password, and so on, into a single attribute.
For a chestnut, you may need at least two attribute, one user name and the other password hash. This is the simplest way to do it.

Https://tools.ietf.org/html/rfc2865#page-22

Currently, there are two ways to package the password in radius,
One is: User-password, https://tools.ietf.org/html/rfc2865#page-27
The other is: Chap-password, https://tools.ietf.org/html/rfc2865#page-28

The two methods are just the hash of the password calculation method is not the same. The concrete generation method is quite clear. The RfC is clearly written, and it's not much to say.

Here, the client process for the RADIUS authentication protocol is basically complete. As for the service side, generally do not write their own. You can use open source off-the-shelf services.

Welcome to my personal Independent blog: https://blog.byNeil.com

Introduction to Radius Authentication Protocol-and RFC guidance