RADIUS

Last updated

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

Contents

RADIUS is a client/server protocol that runs in the application layer, and can use either TCP or UDP. Network access servers, which control access to a network, usually contain a RADIUS client component that communicates with the RADIUS server. [1] RADIUS is often the back-end of choice for 802.1X authentication. [2] A RADIUS server is usually a background process running on UNIX or Microsoft Windows. [1]

Protocol components

RADIUS is an AAA (authentication, authorization, and accounting) protocol that manages network access. RADIUS uses two types of packets to manage the full AAA process: Access-Request, which manages authentication and authorization; and Accounting-Request, which manages accounting. Authentication and authorization are defined in RFC 2865 while accounting is described by RFC 2866.

Authentication and authorization

The user or machine sends a request to a Network Access Server (NAS) to gain access to a particular network resource using access credentials. The credentials are passed to the NAS 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 NAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol. [3]

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 NAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the NAS.

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 Drawing RADIUS 1812.svg
RADIUS Authentication and Authorization Flow

The RADIUS server then returns one of three responses to the NAS: 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 NAS.
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 NAS stipulating terms of access to be granted. For example, the following authorization attributes may be included in an Access-Accept:

When a client is configured to use RADIUS, any user of the client presents authentication information to the client. This might be with a customizable login prompt, where the user is expected to enter their username and password. Alternatively, the user might use a link framing protocol such as the Point-to-Point Protocol (PPP), which has authentication packets which carry this information.

Once the client has obtained such information, it may choose to authenticate using RADIUS. To do so, the client creates an "Access- Request" containing such Attributes as the user's name, the user's password, the ID of the client and the port ID which the user is accessing. When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5.

Accounting

RADIUS Accounting Flow Drawing RADIUS 1813.svg
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. [4]

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

Roaming using a proxy RADIUS AAA server. Drawing Roaming RADIUS.png
Roaming using a proxy RADIUS AAA server.

RADIUS is commonly used to facilitate roaming between ISPs, including by:

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

Realms

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. RFC 7542 [5] replaced RFC 4282 in May 2015.

Proxy operations

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.

Proxy Chaining is possible in RADIUS and authentication/authorization and accounting packets are usually routed between a NAS Device and a Home server through a series of proxies. Some of advantages of using proxy chains include scalability improvements, policy implementations and capability adjustments. But in roaming scenarios, the NAS, Proxies and Home Server could be typically managed by different administrative entities. Hence, the trust factor among the proxies gains more significance under such Inter-domain applications. Further, the absence of end to end security in RADIUS adds to the criticality of trust among the Proxies involved. Proxy Chains are explained in RFC 2607.

Security

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. [6]

Packet structure

RADIUS packet data format. RADIUS packet format.svg
RADIUS packet data format.

RADIUS is transported over UDP/IP on ports 1812 and 1813. [7]

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.

Assigned RADIUS Codes (decimal) include the following: [8]

CodeAssignment
1Access-Request
2Access-Accept
3Access-Reject
4Accounting-Request
5Accounting-Response
11Access-Challenge
12Status-Server (experimental)
13Status-Client (experimental)
40Disconnect-Request
41Disconnect-ACK
42Disconnect-NAK
43CoA-Request
44CoA-ACK
45CoA-NAK
255Reserved

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

RADIUS AVP layout RADIUS AVP layout.svg
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.

Vendor-specific attributes

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. [9] VSA definitions from many other companies remain proprietary and/or ad hoc, nonetheless many VSA dictionaries can be found by downloading the source code of open source RADIUS implementations, for example FreeRADIUS.

RFC 2865 provide basic encoding that attribute should follow, within the description value of Vendor Length field is not explicit but should be understood within a attribute-value context. This Vendor Length is length of Value in byte plus 2 bytes, those two byte counts for Vendor Type and Vendor Length. The number of octets for encoding Vendor Type and Vendor Length is implementation specific, and some vendors use 2 octets for type, length, or both. Specific values are determined by using format=2,2 keyword in the freeradius dictionary.

Vendor-Specific attributes follows this encoding which is used by freeradius implementation using vendor specific dictionaries.

26 (1Byte)Length (1Byte)Vendor Id (4 bytes Big Endian)Vendor type/attribute (1Byte)Vendor Length (1 Byte) = 2 + length of (Value)Value

Security

The RADIUS protocol transmits obfuscated passwords using a shared secret and the MD5 hashing algorithm. As this particular implementation provides only weak protection of the user's credentials, [10] 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.

History

As more dial-up customers used the NSFNET a request for proposal was sent out by Merit Network in 1991 to consolidate their various proprietary authentication, authorization and accounting systems. Among the early respondents was Livingston Enterprises and an early version of the RADIUS was written after a meeting. The early RADIUS server was installed on a UNIX operating system. Livingston Enterprises was acquired by Lucent and together with Merit steps were taken to gain industry acceptance for RADIUS as a protocol. Both companies offered a RADIUS server at no charge. [11] In 1997 RADIUS was published as RFC 2058 and RFC 2059, current versions are RFC 2865 and RFC 2866. [12]

The original RADIUS standard specified that RADIUS is stateless and should run over the User Datagram Protocol (UDP). For authentication it was envisaged that RADIUS should support the Password Authentication Protocol (PAP) and the Challenge-Handshake Authentication Protocol (CHAP) over the Point-to-Point Protocol. Passwords are hidden by taking the MD5 hash of the packet and a shared secret, and then XORing that hash with the password. The original RADIUS also provided more than 50 attribute-value pairs, with the possibility for vendors to configure their own pairs. [13]

The choice of the hop-by-hop security model, rather than end-to-end encryption, meant that if several proxy RADIUS servers are in use, every server must examine, perform logic on and pass on all data in a request. This exposes data such as passwords and certificates at every hop. RADIUS servers also did not have the ability to stop access to resources once an authorisation had been issued. Subsequent standards such as RFC 3576 and its successor RFC 5176 allowed for RADIUS servers to dynamically change a users authorization, or to disconnect a user entirely. [14]

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.

Standards documentation

The RADIUS protocol is currently defined in the following IETF RFC documents.

RFCTitleDate publishedRelated articleRelated RFCsNote
RFC 2058 Remote Authentication Dial In User Service (RADIUS)January 1997RADIUSObsoleted by RFC 2138
RFC 2059 RADIUS AccountingJanuary 1997RADIUSObsoleted by RFC 2139
RFC 2138 Remote Authentication Dial In User Service (RADIUS)April 1997RADIUSObsoleted by RFC 2865
RFC 2139 RADIUS AccountingApril 1997RADIUSObsoleted by RFC 2866
RFC 2548 Microsoft Vendor-specific RADIUS AttributesMarch 1999RADIUS
RFC 2607 Proxy Chaining and Policy Implementation in RoamingJune 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 MIBJune 1999 Management information base Obsoleted by RFC 4670
RFC 2621 RADIUS Accounting Server MIBJune 1999 Management information base Obsoleted by RFC 4671
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUSApril 2000
RFC 2865 Remote Authentication Dial In User Service (RADIUS)June 2000RADIUSUpdated 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 AccountingJune 2000RADIUSThis standard describes how accounting information is carried from the NAS to a shared RADIUS accounting server.
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol SupportJune 2000RADIUSUpdates RFC 2866
RFC 2868 RADIUS Attributes for Tunnel Protocol SupportJune 2000Updates RFC 2865
RFC 2869 RADIUS ExtensionsJune 2000Updated by RFC 3579, RFC 5080
RFC 2882 Network Access Servers Requirements: Extended RADIUS PracticesJuly 2000
RFC 3162 RADIUS and IPv6 August 2001
RFC 3575 IANA Considerations for RADIUSJuly 2003
RFC 3576 Dynamic Authorization Extensions to RADIUSJuly 2003Obsoleted by RFC 5176
RFC 3579 RADIUS Support for EAPSeptember 2003 Extensible Authentication Protocol Updates RFC 2869
RFC 3580 IEEE 802.1X RADIUS Usage GuidelinesSeptember 2003 802.1X
RFC 4014 RADIUS Attributes Suboption for the DHCP Relay Agent Information OptionFebruary 2005
RFC 4372 Chargeable User IdentityJanuary 2006
RFC 4590 RADIUS Extension for Digest AuthenticationJuly 2006Obsoleted by RFC 5090
RFC 4668 RADIUS Authentication Client MIB for IPv6August 2006 Management information base
RFC 4669 RADIUS Authentication Server MIB for IPv6August 2006 Management information base
RFC 4670 RADIUS Accounting Client MIB for IPv6August 2006 Management information base
RFC 4671 RADIUS Accounting Server MIB for IPv6August 2006 Management information base
RFC 4675 RADIUS Attributes for Virtual LAN and Priority SupportSeptember 2006
RFC 4679 DSL Forum Vendor-Specific RADIUS AttributesSeptember 2006
RFC 4818 RADIUS Delegated-IPv6-Prefix AttributeApril 2007
RFC 4849 RADIUS Filter Rule AttributeApril 2007
RFC 5080 Common RADIUS Implementation Issues and Suggested FixesDecember 2007Updates RFC 3579
RFC 5090 RADIUS Extension for Digest AuthenticationFebruary 2008
RFC 5176 Dynamic Authorization Extensions to RADIUSJanuary 2008
RFC 5607 RADIUS Authorization for NAS ManagementJuly 2009
RFC 5997 Use of Status-Server Packets in the RADIUS ProtocolAugust 2010Updates RFC 2866
RFC 6158 RADIUS Design GuidelinesMarch 2011
RFC 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying MaterialApril 2011
RFC 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)November 2011
RFC 6613 RADIUS over TCPMay 2012Experimental
RFC 6614 Transport Layer Security (TLS) Encryption for RADIUSMay 2012Experimental
RFC 6911 RADIUS Attributes for IPv6 Access NetworksApril 2013Standards track
RFC 6929 Remote Authentication Dial-In User Service (RADIUS) Protocol ExtensionsApril 2013Updates RFC 2865, RFC 3575, RFC 6158
RFC 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUSSeptember 2014Experimental
RFC 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)Oct 2015Experimental
RFC 8044 Data Types in RADIUSJanuary 2017Updates: 2865, 3162, 4072, 6158, 6572, 7268
RFC 8559 Dynamic Authorization Proxying in the RADIUS ProtocolApril 2019Standards track

See also

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

In computing, the Challenge-Handshake Authentication Protocol (CHAP) is an authentication protocol originally used by Point-to-Point Protocol (PPP) to validate users. CHAP is also carried in other authentication protocols such as RADIUS and Diameter.

Password Authentication Protocol (PAP) is a password-based authentication protocol used by Point-to-Point Protocol (PPP) to validate users. PAP is specified in RFC 1334.

SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded. A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.

Terminal Access Controller Access-Control System refers to a family of related protocols handling remote authentication and related services for network access control through a centralized server. The original TACACS protocol, which dates back to 1984, was used for communicating with an authentication server, common in older UNIX networks including but not limited to the ARPANET, MILNET and BBNNET. It spawned related protocols:

IEEE 802.1X is an IEEE Standard for port-based network access control (PNAC). It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.

An authentication protocol is a type of computer communications protocol or cryptographic protocol specifically designed for transfer of authentication data between two entities. It allows the receiving entity to authenticate the connecting entity as well as authenticate itself to the connecting entity by declaring the type of information needed for authentication as well as syntax. It is the most important layer of protection needed for secure communication within computer networks.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

A network access server (NAS) is a group of components that provides remote users with a point of access to a network.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the encoding of ID and password joined by a single colon :.

<span class="mw-page-title-main">Digest access authentication</span> Method of negotiating credentials between web server and browser

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

AAA refers to Authentication, Authorization and Accounting.

In cryptography, CRAM-MD5 is a challenge–response authentication mechanism (CRAM) based on the HMAC-MD5 algorithm. As one of the mechanisms supported by the Simple Authentication and Security Layer (SASL), it is often used in email software as part of SMTP Authentication and for the authentication of POP and IMAP users, as well as in applications implementing LDAP, XMPP, BEEP, and other protocols.

<span class="mw-page-title-main">HTTP 403</span> HTTP status code indicating that access is forbidden to a resource

HTTP 403 is an HTTP status code meaning access to the requested resource is forbidden. The server understood the request, but will not fulfill it, if it was correct.

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.

In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.

References

  1. 1 2 "How Does RADIUS Work?". Cisco. 2006-01-19. Retrieved 2009-04-15.
  2. ↑ Edwin Lyle Brown (2006). 802.1X Port-Based Authentication. Taylor & Francis. p. 17. ISBN   978-1-4200-4465-2.
  3. ↑ RFC 2865 Remote Authentication Dial In User Service (RADIUS)
  4. ↑ RFC 2866 RADIUS Accounting
  5. ↑ Dekok, A. (May 2015). "The Network Access Identifier". Internet Engineering Task Force (IETF). doi: 10.17487/RFC7542 . Retrieved 8 May 2021.{{cite journal}}: Cite journal requires |journal= (help)
  6. ↑ 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.
  7. ↑ "Configure NPS UDP Port Information". Microsoft. 2020-08-07. Retrieved 2021-06-20.
  8. ↑ "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)". Ietf Datatracker. Internet Engineering Task Force (IETF). July 2003. Retrieved 8 May 2021.
  9. ↑ RFC 2548
  10. ↑ An Analysis of the RADIUS Authentication Protocol
  11. ↑ Jonathan Hassell (2003). RADIUS: Securing Public Access to Private Resources. O'Reilly Media. pp. 15–16. ISBN   9780596003227.
  12. ↑ John Vollbrecht (2006). "The Beginnings and History of RADIUS" (PDF). Interlink Networks. Retrieved 2009-04-15.
  13. ↑ Jonathan Hassell (2003). RADIUS: Securing Public Access to Private Resources. O'Reilly Media. p. 16. ISBN   9780596003227.
  14. ↑ "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". Ietf Datatracker. Internet Engineering Task Force. January 2008. Retrieved 8 May 2021.

Bibliography

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.