User presents auth info to client.
Client sends “message” to Server.
Can load-balance servers.
Server validates the shared secret.
Radius server consults DB when
receiving the request.
Server can “accept”, “reject”,
“challenge” the user.
If all conditions are met, server
sends a list of configuration values
(like IP address, MTU, .. etc) to the
user in the response.
Used with devices
such as smart cards.
number to the user,
back the result.
With proxy RADIUS, one RADIUS server receives an authentication
(or accounting) request from a RADIUS client (such as a NAS),
forwards the request to a remote RADIUS server, receives the reply
from the remote server, and sends that reply to the client, possibly with
changes to reflect local administrative policy.
A common use for proxy RADIUS is roaming.
The choice of which server receives the forwarded request SHOULD
be based on the authentication "realm".
Retransmission timers are required.
The timing requirements of this particular
protocol are significantly different than TCP
The stateless nature of this protocol simplifies
the use of UDP.
UDP simplifies the server implementation.
Radius Packet – Code Field
The Code field is one octet, and identifies the type of RADIUS packet.
RADIUS Codes (decimal) are assigned as follows:
Radius Packet – Identifier Field
Aids in matching requests and replies.
The RADIUS server can detect a duplicate
request if it has the same client source IP
address and source UDP port and Identifier
within a short span of time.
Radius Packet – Authenticator Field
This value is used to authenticate the reply
from the RADIUS server, and is used in the
password hiding algorithm.
Request Authenticator and Response
Radius Packet – Attributes
RADIUS Attributes carry the specific authentication,
authorization, information and configuration details for
the request and reply.
Client generates an Accounting
start packet to accounting server.
Server acknowledges reception of
At the end of the service, client
generates a stop packet.
Server acknowledges reception of
Doesn't define fail-over mechanisms.
Does not provide support for per-packet confidentiality.
In Accounting it assumes that replay protection is provided by the backend
server not the protocol.
Doesn't Define re-transmission (UDP), which is a major issue in
does not provide for explicit support for agents, including proxies,
redirects, and relays.
Server-initiated messages are optional.
RADIUS does not support error messages, capability negotiation, or a
mandatory/non-mandatory flag for attributes.
It evolved from and replaces RADIUS protocol.
Ability to exchange messages and deliver AVPs.
Extensibility, required in [RFC2989], through addition
of new applications, commands, and AVPs
Basic services necessary for applications, such as the
handling of user sessions or accounting
A Juniper Radius product.
Delivers a total authentication, authorization, and accounting
(AAA) solution on the scale required by Internet service
providers and carriers.
Provides data services for wireline, wireless carriers.
Modular design that supports add-on functionality to meet
your specific site requirements (SIM, CDMA, WiMAX, Session
SBR - Features
Centralized management of user access control and security simplifies access administration.
powerful proxy RADIUS features enable to easily distribute authentication and accounting requests to
the appropriate RADIUS server for processing.
External authentication features enable you to authenticate against multiple, redundant
Structured Query Language (SQL) or Lightweight Directory Access Protocol (LDAP) databases
according to configurable load balancing and retry strategies.
Support for a wide variety of 802.1X-compliant access points and other network access servers.
You can define user’s allowed access hours
Multiple management interfaces (GUI, LCI, CLI, XML/HTTPS, SNMP).
3GPP support facilitates the management of mobile sessions and their associated resources