RADIUS Protocol in a nutshell
The general radius operation works as above. Host presents authentication information to radius client. Client sends message to server. Server validates the shared secret. Server also 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.
The Radius packet format is as below,
The code field identifies the type of radius packet. Identifier field detects a duplicate request. Authenticator field is used to authenticate the reply from the server and is used in the password hiding algorithm. Radius attributes (AVP) carry the specific authentication, authorization, information, and configuration details for the request and reply like username, user-password, chap-password, nas ip address, nas port, service type and so on.
Radius Accounting works as below, client generates an accounting start packet. Server acknowledges reception of the packet. At the end of the service, client generates a stop packet. Server acknowledges reception of the packet.
The shortcomings of Radius Protocol are,
- Does not 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.
- Does not define re-transmission (UDP), which is a major issue in accounting.
- Does not provide for explicit support for agents, including proxies, redirects, and relays.
- Server initiated messages are optional.
- Does not support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes.