Radius (data-processing)

RADIUS ( Remote Authentication Dial-In Using Service ) is a Protocole Client-serveur making it possible to centralize data of Authentification. In French one often prefers to speak about identification to translate English authentication , because the identification carried out by a Radius waiter is a checking of name of user (attribute 1 username) and of password (attribute 2 To use-Password or 3 Chap-Password). The French authentification is defined like the checking deepened by an expert or a member of the legal profession and corresponds to the Anglicism strong authentification for " strong authentication" , but the abuse language is current.

Standardization

The last version of the protocol RADIUS is standardized by IETF in two RFC: RFC 2865 (RADIUS authentication) and RFC 2866 (RADIUS accounting) of June 2000. The successor of the Radius protocol could be the protocol Diameter (word game on the double of the ray). The protocol is often called AAA (Authentication Authorization Accounting), the phase of authorization (definition of the rights of access) being accomplished at the time of the answer of identification (addition of attributes to the package Authentication Response). Another example of protocol AAA could be TACACS from Cisco, but he is owner and since the publication of the standard 802.1X which gives in appendix D like only example of implementation the Radius protocol, this one became a standard in fact of the AAA.

Utility

The goal of RADIUS was in the beginning to allow FAI (Suppliers of Access Internet) or ISP (Internet Providers Service) to authenticate the distant users using connections by Modem STN starting from multiple waiters but of only one base users. In the preceding situation, the names and passwords of the users were to be duplicated in each apparatus needing to identify users. In the same way, the authentification POP , the email was to be managed by this skew. The identification on the Web sites by a name and a password is also managed in RADIUS, the Apache waiter is one of most widespread the Radius customers. It is always the most current use of the protocol RADIUS: name and password of connection to the Internet, but more and more the wireless networkings or telegraphic have there also recourse to identify the users.

The protocol RADIUS makes it possible to make the connection between needs for identification and a bases users by ensuring the data transmission of Authentification in a standardized way. The operation of Authentification is initiated by a customer service RADIUS, which can be a case of distant access (NAS: Network Server Access), an access point wireless networking, a fire wall (firewall), a switch, another waiter. The waiter treats it while reaching if necessary for an external base: database SQL, directory LDAP, accounts of user of machine or field; a Radius waiter has for that a certain number of interfaces or methods.

Operation of the identification

The user station ( supplicant in the RFC) transmits a Requête access to a customer RADIUS to enter on the network. This customer is given the responsability to require information identifying the user: the name of user (login) and the Password for example.

The customer RADIUS generates according to the protocol a Requête Access-Request containing information of Authentification. The waiter RADIUS can treat itself this request or transmit it to another waiter RADIUS by a mechanism called Proxy Radius. The Radius waiter in charge of the final identification (called Home Radius) can treat the request if it has sufficient elements in the Access-Request or ask extra informations by reference of package Access Challenge, to which the customer will answer by another Access-Request, and so on. The exchanges are retransmis by the chain of waiters intermediate Radius proxy in a direction and the other.

When the Radius waiter has sufficient elements (to a dozen exchanges for the complex protocols of type EAP) the waiter RADIUS validates or refuses the identification while returning a Paquet of the type: Access-Accept or Access-Reject .

Protocols of password

RADIUS knows two protocols of password nativement: PAP (exchange in light of the name and the password), and CHAP (exchange based on a chopping on both sides with exchange only of the “challenge”). The protocol envisages two separate attributes: To use-Password and CHAP-Password.

Since were grafted the Microsoft variations: MS-CHAP and MS-CHAP-V2; their similarity with CHAP makes it possible in the same way to transport them in RADIUS, on the initiative of the waiter and provided of course of possibility of transport from beginning to end of supplicant with the Radius customer, the customer to the Radius waiter and finally of the Radius waiter to the database of identification.

It is on this last stage that often the pack wounds: nothing is envisaged for example in LDAP to transport the challenge nor the specific stages of MS-CHAP or MS-CHAP-V2, which blow finish exclusively on local bases of Microsoft identification for the Radius waiter.

Authorization

The identification RADIUS can be enriched by an authorization, for example for a customer of supplier of access his address IP, its maximum time of connection, its time of inactivity. All these parameters are defined by attributes of the package in the RFC, in fact for this example attribute 8, more known under its name " convivial" Framed-IP-Address, although the protocol knows in fact only the numbers, and the attributes Session-Timeout and Idle-Timeout. The standard attributes are defined in the RFC, the specific attributes of a supplier or VSA (Vendor Specific Attributes) are multiplexed in attribute 26: each supplier sees himself allotting a single number (1 for Cisco!) making it possible to identify it, a byte of this attribute defines a number of VSA, which makes it possible each supplier to define up to 255 specific attributes for its material. The Radius waiter adapts to these " dialectes" by dictionaries of attributes.

Accounting (accounting)

The second function of a Radius waiter is the accounting (or accounting) ensuring at the same time the journalizing of the access and the invoicing. Defined by RFC different, managed on ports UDP different (1646 or 1813 for most current whereas the identification is made on the ports 1645 or 1812), this function is often provided by a program or even a different waiter.

The accounting is based on two types of principal packages: Accounting Start and Accounting Stop, a session is defined like the interval between Start and a Stop. The package Accounting Start emitted by the Radius customer after effective connection of the user following a phase of successful identification contains source data: name of user (but not the useless password here), addresses IP affected, date and hour of connection, type of connection, service type, etc

When the user disconnects himself from the service or that the Radius customer disconnects it on inactivity, going beyond of time of connection or other, this Radius customer sends a package Accounting Stop with the same identifier of session, the Radius waiter can then close the session and journalize the disconnection, often with a great number of parameters in the Stop package: time of connection, type of use, many packages and of bytes exchanged according to the various protocols, and possibly of more confidential information on the visited sites or exchanged contents.

There exist other types of packages of accounting: Intermediary (emitted with periodic intervals by the customer between Start and Stop, useful if the Stop would be lost), One (the Radius customer started) and Off (the Radius customer will stop), this last for memory, he is rare that an apparatus prevents before breaking down or to plant.

To facilitate the work of connection between the phase of identification and the phase of accounting (the waiter radius can have received hundreds of other requests between the two), the Class attribute is sent towards the customer with the package Access-Accept; the Radius customer has as instructions to return it such as it is in the package Accounting Start. The Radius waiter can thus include in this attribute all the useful informations to make the connection between an identification successful, accompanied often by a reservation by resources - channel, PVC or address IP for example - and the effective use of these resources.

If the operation is abandoned (there is no package Accounting Start corresponding after a successful identification), a mechanism must restore the reserved resources; the majority of the implementations use a mechanism of temporization for that ( phantom accounting record ). The resources reserved by the identification, occupied by Accounting Start are normally released by the package Accounting Stop, which implies for example that a Radius waiter cannot allot of IP addresses that if it manages also the function of accounting.

The accounting has also a legal function: the access to the Internet must be identified, and any user must be traçable at least towards a bank card or account number, this is why the function of accounting is always activated at the preserved FAI and recordings: on letter of request of a judge, the FAI can provide the identification to a given moment of any address IP.

Limitations

RADIUS was conceived for identifications by modem, on slow and not very sure connections; it is the reason of the choice of protocol UDP, explained well in RFC2138. This technical choice of a nonaggressive protocol led to hard exchanges based on temporizations of réémission, exchanges of acknowledgment of delivery which were justified as much as connection to the Internet concerned the principle " bottle with the mer" of UDP, but do not take place any more to be for example between operators in the activities of Roaming or Proxy Radius - > Diameter uses TCP or STCP
RADIUS bases its identification on the only principle of the couple name/password; adapted perfectly at the time (1996), this concept had to be adapted for example for the identification of the mobile terminals by their number IMEI or their call number (Calling-Station-ID in Radius) without password (whereas the RFC prohibits the empty password!)
RADIUS ensures a transport in light, only the password is quantified to chopping; the quite relative safety of the protocol rests on only the secret Shared and imposes the security of the exchanges between the customer and the waiter by physical safety or VPN - > Diameter can use IPSec or TLS
RADIUS limits the attributes, managed in the form of chain " Pascal" with a byte at the head giving the length, with 255 bytes, coherent with the concept of name/password, but unsuited to any attempt at introduction of Biometrics (Fund of eye, Digital fingerprint) of Cryptography (certificate) - > Diameter uses attributes on 32 bits instead of 8 (already present in certain extensions EAP of RADIUS, in particular TTLS)
RADIUS is strictly customer-server, from where discussions and brawls of protocols owners when a waiter must legitimately kill a pirate session on a customer - > Diameter has mechanisms of call of the customer by the waiter
RADIUS does not ensure of mechanism of identification of the waiter; however to be made pass for a waiter is an excellent means of collecting names and passwords - > EAP ensures a mutual identification of the customer and waiter

Obsolete versions of RADIUS

the first version of RADIUS goes back to January 1997 and was defined by RFC 2058 and RFC 2059. Only a prototype of Merritt code existed, no realization according to these RFC did not arrive on the market.
the second version dates from the same year (April 1997) and was defined by RFC 2138 and RFC 2139. The Radius waiters of first generation used these RFC, some are still in production.

Extensions of RADIUS

EAP (Extensible Authentication Protocol) is a protocol conceived to extend the functions of the Radius protocol to more complex types of identification; it is independent of the material of the Radius customer and directly negotiated with supplicant (station customer, terminal of access). It is what made it possible to quickly set up it on a maximum of apparatuses network since it uses only two Radius attributes being used as protocol of transport, and led to an explosion of the types EAP: EAP-MD5 defined in the RFC like example, but also EAP-TLS, EAP-TTLS, EAP-PEAP (version 0 Microsoft, version 1 Cisco, version 2 soon), EAP-MS-CHAP-V2, EAP-AKA, EAP-LEAP and EAP-FAST (Cisco), EAP-SIM, etc
802.1X is a protocol ensuring the identification by port for the access to a network; it is not explicitly dependant on RADIUS in its principle and uses in all its definitions the " terms; AAA" waiter; and " AAA" protocol; , but it is that the appendix D of the reference document mentions like " exemple" of protocol and waiter AAA the only RADIUS. All the known implementations of 802.1X are thus pressed on RADIUS.
Diameter is not really an extension but a successor of the protocol RADIUS; it is based on TCP whereas Radius is in UDP, it uses attributes of big size (Radius is limited to 254 bytes per attribute) and it is intended for the exchanges between waiters on sure connections; the Diameter waiters (not deployed for the moment) are generally compatible Radius. A certain number of the types of Diameter attributes are found already in EAP-TTLS for example.

See too

802.1x
Protocol AAA
FreeRADIUS
DIAMETER
Terminal Access Controller Access-Control System (TACACS)

Random links: