RADIUS

From Wikipedia, the free encyclopedia
Jump to: navigation, search
For other uses, see Radius (disambiguation).

Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users that connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc. in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.[1]

Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. These networks may incorporate modems, DSL, access points, VPNs, network ports, web servers, etc.[2]

RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. The Remote Access Server, the Virtual Private Network server, the Network switch with port-based authentication, and the Network Access Server (NAS), are all gateways that control access to the network, and all have a RADIUS client component that communicates with the RADIUS server.[3] RADIUS is often the backend of choice for 802.1X authentication as well.[4]

The RADIUS server is usually a background process running on a UNIX or Microsoft Windows server.[3]

AAA[edit]

Main article: AAA protocol

RADIUS servers use the AAA concept to manage network access in the following two-step process, also known as an "AAA transaction". AAA stands for “authentication, authorization and accounting”. Authentication and Authorization characteristics in RADIUS are described in RFC 2865 while Accounting is described by RFC 2866.

Authentication and authorization[edit]

The user or machine sends a request to a Remote Access Server (RAS) to gain access to a particular network resource using access credentials. The credentials are passed to the RAS device via the link-layer protocol - for example, Point-to-Point Protocol (PPP) in the case of many dialup or DSL providers or posted in an HTTPS secure web form.

In turn, the RAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol.[5]

This request includes access credentials, typically in the form of username and password or security certificate provided by the user. Additionally, the request may contain other information which the RAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the RAS.

The RADIUS server checks that the information is correct using authentication schemes such as PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, other information related to the request, such as the user's network address or phone number, account status, and specific network service access privileges. Historically, RADIUS servers checked the user's information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources — commonly SQL, Kerberos, LDAP, or Active Directory servers — to verify the user's credentials.

RADIUS Authentication and Authorization Flow

The RADIUS server then returns one of three responses to the RAS : 1) Access Reject, 2) Access Challenge, or 3) Access Accept.

  • Access Reject - The user is unconditionally denied access to all requested network resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.
  • Access Challenge - Requests additional information from the user such as a secondary password, PIN, token, or card. Access Challenge is also used in more complex authentication dialogs where a secure tunnel is established between the user machine and the Radius Server in a way that the access credentials are hidden from the RAS.
  • Access Accept - The user is granted access. Once the user is authenticated, the RADIUS server will often check that the user is authorized to use the network service requested. A given user may be allowed to use a company's wireless network, but not its VPN service, for example. Again, this information may be stored locally on the RADIUS server, or may be looked up in an external source such as LDAP or Active Directory.

Each of these three RADIUS responses may include a Reply-Message attribute which may give a reason for the rejection, the prompt for the challenge, or a welcome message for the accept. The text in the attribute can be passed on to the user in a return web page.

Authorization attributes are conveyed to the RAS stipulating terms of access to be granted. For example, the following authorization attributes may be included in an Access-Accept:

  • The specific IP address to be assigned to the user
  • The address pool from which the user's IP should be chosen
  • The maximum length that the user may remain connected
  • An access list, priority queue or other restrictions on a user's access
  • L2TP parameters
  • VLAN parameters
  • Quality of Service (QoS) parameters

Accounting[edit]

RADIUS Accounting Flow

Accounting is described in RFC 2866.

When network access is granted to the user by the NAS, an Accounting Start (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "start") is sent by the NAS to the RADIUS server to signal the start of the user's network access. "Start" records typically contain the user's identification, network address, point of attachment and a unique session identifier.[6]

Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "interim-update") may be sent by the NAS to the RADIUS server, to update it on the status of an active session. "Interim" records typically convey the current session duration and information on current data usage.

Finally, when the user's network access is closed, the NAS issues a final Accounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "stop") to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and other information related to the user's network access.

Typically, the client sends Accounting-Request packets until it receives an Accounting-Response acknowledgement, using some retry interval.

The primary purpose of this data is that the user can be billed accordingly; the data is also commonly used for statistical purposes and for general network monitoring.

Roaming[edit]

Roaming using a proxy RADIUS AAA server.

RADIUS is commonly used to facilitate roaming between ISPs, for example:

  • by companies which provide a single global set of credentials that are usable on many public networks;
  • by independent, but collaborating, institutions issuing their own credentials to their own users, that allow a visitor from one to another to be authenticated by their home institution, such as in eduroam.

RADIUS facilitates this by the use of realms, which identify where the RADIUS server should forward the AAA requests for processing.

Realms[edit]

A realm is commonly appended to a user's user name and delimited with an '@' sign, resembling an email address domain name. This is known as postfix notation for the realm. Another common usage is prefix notation, which involves prepending the realm to the username and using '\' as a delimiter. Modern RADIUS servers allow any character to be used as a realm delimiter, although in practice '@' and '\' are usually used.

Realms can also be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example, somedomain.com\username@anotherdomain.com could be a valid username with two realms.

Although realms often resemble domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names. Realm formats are standardized in RFC 4282, which defines a Network Access Identifier (NAI) in the form of 'user@realm'. In that specification, the 'realm' portion is required to be a domain name. However, this practice is not always followed.

Proxy operations[edit]

When a RADIUS server receives an AAA request for a user name containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the configured home server for that domain. The behavior of the proxying server regarding the removal of the realm from the request ("stripping") is configuration-dependent on most servers. In addition, the proxying server can be configured to add, remove or rewrite AAA requests when they are proxied over time again.

Security[edit]

Roaming with RADIUS exposes the users to various security and privacy concerns. More generally, some roaming partners establish a secure tunnel between the RADIUS servers to ensure that users' credentials cannot be intercepted while being proxied across the internet. This is a concern as the MD5 hash built into RADIUS is considered insecure.[7]

Packet structure[edit]

RADIUS packet data format.

The RADIUS packet data format is shown to the right. The fields are transmitted from left to right, starting with the code, the identifier, the length, the authenticator and the attributes.

RADIUS Codes (decimal) are assigned as follows:

Code Assignment
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 Reserved

The Identifier field aids in matching requests and replies.

The Length field indicates the length of the entire RADIUS packet including the Code, Identifier, Length, Authenticator and optional Attribute fields.

The Authenticator is used to authenticate the reply from the RADIUS server, and is used in encrypting passwords; its length is 16 bytes.

Attribute value pairs[edit]

RADIUS AVP layout

The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs.

AVP Type Assignment
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
18 Reply-Message
19 Callback-Number
20 Callback-Id
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 Acct-Status-Type
41 Acct-Delay-Time
42 Acct-Input-Octets
43 Acct-Output-Octets
44 Acct-Session-Id
45 Acct-Authentic
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause
50 Acct-Multi-Session-Id
51 Acct-Link-Count
52 Acct-Input-Gigawords
53 Acct-Output-Gigawords
55 Event-Timestamp
56 Egress-VLANID
57 Ingress-Filters
58 Egress-VLAN-Name
59 User-Priority-Table
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT-Port
64 Tunnel-Type
65 Tunnel-Medium-Type
66 Tunnel-Client-Endpoint
67 Tunnel-Server-Endpoint
68 Acct-Tunnel-Connection
69 Tunnel-Password
70 ARAP-Password
71 ARAP-Features
72 ARAP-Zone-Access
73 ARAP-Security
74 ARAP-Security-Data
75 Password-Retry
76 Prompt
77 Connect-Info
78 Configuration-Token
79 EAP-Message
80 Message-Authenticator
81 Tunnel-Private-Group-ID
82 Tunnel-Assignment-ID
83 Tunnel-Preference
84 ARAP-Challenge-Response
85 Acct-Interim-Interval
86 Acct-Tunnel-Packets-Lost
87 NAS-Port-Id
88 Framed-Pool
89 CUI
90 Tunnel-Client-Auth-ID
91 Tunnel-Server-Auth-ID
92 NAS-Filter-Rule
94 Originating-Line-Info
95 NAS-IPv6-Address
96 Framed-Interface-Id
97 Framed-IPv6-Prefix
98 Login-IPv6-Host
99 Framed-IPv6-Route
100 Framed-IPv6-Pool
101 Error-Cause Attribute
102 EAP-Key-Name
103 Digest-Response
104 Digest-Realm
105 Digest-Nonce
106 Digest-Response-Auth
107 Digest-Nextnonce
108 Digest-Method
109 Digest-URI
110 Digest-Qop
111 Digest-Algorithm
112 Digest-Entity-Body-Hash
113 Digest-CNonce
114 Digest-Nonce-Count
115 Digest-Username
116 Digest-Opaque
117 Digest-Auth-Param
118 Digest-AKA-Auts
119 Digest-Domain
120 Digest-Stale
121 Digest-HA1
122 SIP-AOR
123 Delegated-IPv6-Prefix
124 MIP6-Feature-Vector
125 MIP6-Home-Link-Prefix
126 Operator-Name
127 Location-Information
128 Location-Data
129 Basic-Location-Policy-Rules
130 Extended-Location-Policy-Rules
131 Location-Capable
132 Requested-Location-Info
133 Framed-Management-Protocol
134 Management-Transport-Protection
135 Management-Policy-Id
136 Management-Privilege-Level
137 PKM-SS-Cert
138 PKM-CA-Cert
139 PKM-Config-Settings
140 PKM-Cryptosuite-List
141 PKM-SAID
142 PKM-SA-Descriptor
143 PKM-Auth-Key
144 DS-Lite-Tunnel-Name
145 Mobile-Node-Identifier
146 Service-Selection
147 PMIP6-Home-LMA-IPv6-Address
148 PMIP6-Visited-LMA-IPv6-Address
149 PMIP6-Home-LMA-IPv4-Address
150 PMIP6-Visited-LMA-IPv4-Address
151 PMIP6-Home-HN-Prefix
152 PMIP6-Visited-HN-Prefix
153 PMIP6-Home-Interface-ID
154 PMIP6-Visited-Interface-ID
155 PMIP6-Home-IPv4-HoA
156 PMIP6-Visited-IPv4-HoA
157 PMIP6-Home-DHCP4-Server-Address
158 PMIP6-Visited-DHCP4-Server-Address
159 PMIP6-Home-DHCP6-Server-Address
160 PMIP6-Visited-DHCP6-Server-Address
161 PMIP6-Home-IPv4-Gateway
162 PMIP6-Visited-IPv4-Gateway
163 EAP-Lower-Layer
164 GSS-Acceptor-Service-Name
165 GSS-Acceptor-Host-Name
166 GSS-Acceptor-Service-Specifics
167 GSS-Acceptor-Realm-Name
168 Framed-IPv6-Address
169 DNS-Server-IPv6-Address
170 Route-IPv6-Information
171 Delegated-IPv6-Prefix-Pool
172 Stateful-IPv6-Address-Pool
173 IPv6-6rd-Configuration
174 Allowed-Called-Station-Id
175 EAP-Peer-Id
176 EAP-Server-Id
177 Mobility-Domain-Id
178 Preauth-Timeout
179 Network-Id-Name
180 EAPoL-Announcement
181 WLAN-HESSID
182 WLAN-Venue-Info
183 WLAN-Venue-Language
184 WLAN-Venue-Name
185 WLAN-Reason-Code
186 WLAN-Pairwise-Cipher
187 WLAN-Group-Cipher
188 WLAN-AKM-Suite
189 WLAN-Group-Mgmt-Cipher
190 WLAN-RF-Band

Vendor-specific attributes[edit]

RADIUS is extensible; many vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs). Microsoft has published some of their VSAs.[8] VSA definitions from many other companies remain proprietary and/or ad-hoc, nonetheless many VSA dictionaries can be found downloading source code of open source RADIUS implementations, for example FreeRADIUS or openRADIUS.

Security[edit]

The RADIUS protocol does not transmit passwords in cleartext between the NAS and RADIUS server (not even with PAP protocol). Rather, a shared secret is used along with the MD5 hashing algorithm to obfuscate passwords. Because this particular implementation is not considered to be a very strong protection of the user's credentials,[9] additional protection, such as IPsec tunnels or physically secured data-center networks, should be used to further protect the RADIUS traffic between the NAS device and the RADIUS server. Additionally, the user's security credentials are the only part protected by RADIUS itself, yet other user-specific attributes such as tunnel-group IDs or vlan memberships passed over RADIUS may be considered sensitive (helpful to an attacker) or private (sufficient to identify the individual client) information as well.[citation needed] The RadSec protocol claims to solve aforementioned security issues.

RADIUS history[edit]

RADIUS was originally specified in an RFI by Merit Network in 1991 to control dial-in access to NSFnet. Livingston Enterprises responded to the RFI with a description of a RADIUS server. Merit Network awarded the contract to Livingston Enterprises that delivered their PortMaster series of Network Access Servers and the initial RADIUS server to Merit. RADIUS was later (1997) published as RFC 2058 and RFC 2059 (current versions are RFC 2865 and RFC 2866).[1]

Now, several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAP servers, various databases, etc. Accounting records can be written to text files, various databases, forwarded to external servers, etc. SNMP is often used for remote monitoring and keep-alive checking of a RADIUS server. RADIUS proxy servers are used for centralized administration and can rewrite RADIUS packets on the fly (for security reasons, or to convert between vendor dialects).

The Diameter protocol was intended as the replacement for RADIUS. While both are Authentication, Authorization, and Accounting (AAA) protocols, the use-cases for the two protocols have since diverged. Diameter is largely used in the 3G space. RADIUS is used elsewhere. One of the largest barriers to having Diameter replace RADIUS is that switches and Access Points typically implement RADIUS, but not Diameter.

Diameter uses SCTP or TCP while RADIUS typically uses UDP as the transport layer. As of 2012, RADIUS can also use TCP as the transport layer with TLS for security.

RFCs[edit]

The RADIUS protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.

RFC Title Date published Related article Related RFCs Notes
RFC 2058 Remote Authentication Dial In User Service (RADIUS) January 1997 RADIUS Obsoleted by RFC 2138
RFC 2059 RADIUS Accounting January 1997 RADIUS Obsoleted by RFC 2139
RFC 2138 Remote Authentication Dial In User Service (RADIUS) April 1997 RADIUS Obsoleted by RFC 2865
RFC 2139 RADIUS Accounting April 1997 RADIUS Obsoleted by RFC 2866
RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 RADIUS
RFC 2607 Proxy Chaining and Policy Implementation in Roaming June 1999
RFC 2618 RADIUS Authentication Client MIB Management information base Obsoleted by RFC 4668
RFC 2619 RADIUS Authentication Server MIB Management information base Obsoleted by RFC 4669
RFC 2620 RADIUS Accounting Client MIB June 1999 Management information base Obsoleted by RFC 4670
RFC 2621 RADIUS Accounting Server MIB June 1999 Management information base Obsoleted by RFC 4671
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS April 2000
RFC 2865 Remote Authentication Dial In User Service (RADIUS) June 2000 RADIUS Updated by RFC 2868, RFC 3575, RFC 5080 This standard describes RADIUS authentication and authorization between a Network Access Server (NAS) and a shared RADIUS authentication server. This protocol is also used to carry configuration information from the RADIUS server to the NAS.
RFC 2866 RADIUS Accounting June 2000 RADIUS This standard describes how accounting information is carried from the NAS to a shared RADIUS accounting server.
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support June 2000 RADIUS Updates RFC 2866
RFC 2868 RADIUS Attributes for Tunnel Protocol Support June 2000 Updates RFC 2865
RFC 2869 RADIUS Extensions June 2000 Updated by RFC 3579, RFC 5080
RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices July 2000
RFC 3162 RADIUS and IPv6 August 2001
RFC 3575 IANA Considerations for RADIUS July 2003
RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Obsoleted by RFC 5176
RFC 3579 RADIUS Support for EAP September 2003 Extensible Authentication Protocol Updates RFC 2869
RFC 3580 IEEE 802.1X RADIUS Usage Guidelines September 2003 802.1X
RFC 4014 RADIUS Attributes Suboption for the DHCP Relay Agent Information Option February 2005
RFC 4372 Chargeable User Identity January 2006
RFC 4590 RADIUS Extension for Digest Authentication July 2006 Obsoleted by RFC 5090
RFC 4668 RADIUS Authentication Client MIB for IPv6 August 2006 Management information base
RFC 4669 RADIUS Authentication Server MIB for IPv6 August 2006 Management information base
RFC 4670 RADIUS Accounting Client MIB for IPv6 August 2006 Management information base
RFC 4671 RADIUS Accounting Server MIB for IPv6 August 2006 Management information base
RFC 4675 RADIUS Attributes for Virtual LAN and Priority Support September 2006
RFC 4679 DSL Forum Vendor-Specific RADIUS Attributes September 2006
RFC 4818 RADIUS Delegated-IPv6-Prefix Attribute April 2007
RFC 4849 RADIUS Filter Rule Attribute April 2007
RFC 5080 Common RADIUS Implementation Issues and Suggested Fixes December 2007 Updates RFC 3579
RFC 5090 RADIUS Extension for Digest Authentication February 2008
RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
RFC 5607 RADIUS Authorization for NAS Management July 2009
RFC 5997 Use of Status-Server Packets in the RADIUS Protocol August 2010 Updates RFC 2866
RFC 6158 RADIUS Design Guidelines March 2011
RFC 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material April 2011
RFC 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) November 2011
RFC 6613 RADIUS over TCP May 2012
RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS May 2012

See also[edit]

Bibliography[edit]

References[edit]

  1. ^ a b John Vollbrecht (2006). "The Beginnings and History of RADIUS". Interlink Networks. Retrieved 2009-04-15. 
  2. ^ Brien Posey (2006-08-31). "SolutionBase: RADIUS deployment scenarios". TechRepublic. Retrieved 2009-04-15. 
  3. ^ a b "How Does RADIUS Work?". Cisco. 2006-01-19. Retrieved 2009-04-15. 
  4. ^ Edwin Lyle Brown (2006). 802.1X Port-Based Authentication. Taylor & Francis. p. 17. ISBN 978-1-4200-4465-2. 
  5. ^ RFC 2865 Remote Authentication Dial In User Service (RADIUS)
  6. ^ RFC 2866 RADIUS Accounting
  7. ^ Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger (2008-12-08). "MD5 considered harmful today - Creating a rogue CA certificate". Technische Universiteit Eindhoven. Retrieved 2009-04-19. 
  8. ^ RFC 2548
  9. ^ An Analysis of the RADIUS Authentication Protocol

External links[edit]