Cody Brookshear Andy Borman RADIUS Protocol Cody Brookshear Andy Borman

RADIUS Protocol Remote Authentication Dial-In User Service Centralized AAA: Authentication Authorization Accounting Dial-up, VPN, Wireless, switches, DSL Clients (NAS) manage these devices

Protocol Overview RADIUS Client sends a message to a RADIUS server RADIUS server authenticates and authorizes requests and sends back a response message Client and server use a pre-shared secret key Accounting messages sent from clients to servers, and acknowledged by servers.

RADIUS Diagram

RADIUS Details Access = Authentication + Authorization RFC 2865 UDP Port 1812 Accounting RFC 2866 UDP Port 1813 One RADIUS message per packet, occupying full UDP data field.

Why UDP instead of TCP? Unique timing requirements: User can wait a few seconds no ack overhead and aggressive packet retransmission required. Users don’t want to wait several minutes send request to alternate server instead.

Why UDP instead of TCP? No special handling for rebooting or offline clients and servers. Don’t worry about lost connections. Stateless protocol. Multi-threaded server to service multiple requests easy to implement with UDP.

Access Messages Access-Request – network access request Possible responses to client: Access-Accept Access-Reject Access-Challenge

Accounting Messages Accounting-Request – send to server about accepted Access-Request. Accounting-Response – server acknowledges receipt and processing

RADIUS Packet Layout

RADIUS Packet Details Code – 8 bit, type of RADIUS packet.

RADIUS Packet Details Identifier – 8 bits, used to match requests and replies. Server can use identifier to detect duplicate requests from the same client IP address Identifiers must be reused frequently though.

RADIUS Packet Details Length – 16 bits. The length of the entire RADIUS packet. If packet received was shorter than Length, it is dropped. If a packet is longer than Length, the extra bits are ignored. Minimum length is 20 bits. Maximum length is 4096 bits.

RADIUS Packet Details Authenticator – 16 bytes, meaning is different for both access and accounting requests and responses. Request Authenticator - a unique, unpredictable random number. Client and server share the same secret. Secret followed by the Request Authenticator and put through MD5 hash, then XORed with user password. Result is placed in the password attribute.

RADIUS Packet Details Response Authenticator – same for all access responses. MD5 hash over concatenated fields: Code + ID + Length + Request Authenticator + Attributes + Secret

Accounting Authenticator Request Authenticator – MD5 hash over concatenated fields: Code + Identifier + Length + 16 zero octets + request attributes + shared secret Response Authenticator – MD5 hash over: Response Code + Identifier + Length + Request Authenticator (being replied to) + response attributes (if any) + shared secret

RADIUS Proxy Servers Server that relays requests to another server. A forwarding server can forward to any number of remote servers. A remote server can have any number of servers forwarding to it.

RADIUS Proxy Servers Example with client, a forwarding and a remote server. 1. Client sends access request to forwarding server. 2. Gets forwarded to remote server. 3. Remote server sends access-accept. 4. Forwarding server sends the access accept to the client.

Client Access-Request Detail Client generated Request identifier (usually incremental) Randomly generated Request Authenticator stored in the Authenticator attribute. Only the User-Password attribute is enciphered, XORed with an MD5 hash created using shared secret + request authenticator to get 16 octet number. Additional 16 octet blocks are hashed using shared secret + prior ciphertext.

Server Response If the server does not have the shared secret for the client, the request is silently dropped. Otherwise, the server can decipher the username and password, and send the Access-Accept or Access-Reject back to the client. Response Authenticator – MD5 hash over: Response Code + Identifier + Length + Request Authenticator (being replied to) + response attributes (if any) + shared secret

Client post-processing Determines if the identifier matches an outstanding request. Performs same Response Authenticator calculation to see if it matches the authenticator of response.

Vulnerability Summary RADIUS hiding method ( MD5 hash and stream cipher) may not be adequate. Client Access-Request message is not authenticated Request Authenticators may be poorly implemented. Administrators may choose the RADIUS shared secrets poorly. Multiple clients sharing the same secret make the key easier to discover.

Access-Request authentication (solution) Some implementations allow the server to require Message-Authenticator attribute in Access-Request messages. Provides client authentication. Message-Authenticator is MD5 hash of the Access-Request message and secret key. Otherwise, server must require account lock out after specified number of failed attempts within a specified time.

Poor Information Entropy (solution) ASCII typed secrets only allow 94 possible characters. Use secrets > 22 characters long, mixing upper and lower case letters, numbers, and punctuation. Use different shared secrets for each server-client pair.

Poor Information Entropy (solution), cont. Use cryptographically strong Request Authenticators. Require strong user passwords. Use authentication counting and lockout to prevent online dictionary attack against user’s password.

Poor Request Authenticator (solution) Remember, the Request Authenticator and the shared secret are combined to create the key stream used to encrypt the User-Password. If the value of the request authenticator is ever repeated (while using the same shared secret), the enciphered information can be exposed. If the Request Authenticator is based on a poorly implemented PRNG, then the number becomes predictable, and also more likely to repeat.

RADIUS encryption vulnerability (solution) Use another protocol as an additional layer of security to encrypt the RADIUS message between the client and server.

Attack on Shared Secret Key Attacker observes a valid Access-Request and associated Access-Accept/Access-Reject packet. Attacker can pre-compute the MD5 state for (Code+ID+Length+RequestAuthorization+Attributes) and make guesses for the hash of the shared secret. Ability to pre-compute leading sections of the keyed hash primitive reduces the computation requirements.

User-Password Attribute attack Attacker can gain information by attempting authentication as the client. The attacker supplies the password and captures the Access-Request packet. Attacker can XOR the protect User-Password attribute with the password he provided, which gives the MD5 hash of (shared secret + request authenticator). The request authenticator is also known, so the attacker can try to calculate the shared secret off-line.

User-Password password Attack Similarly, the attacker attempts to authenticate with a valid username and any password. Attacker captures the Access-Request packet. Attacker can replay modified packets, using the same Request Authenticator value, while changing the password. Can prevent with: server limits on user attempts, passwords > 16 characters, strong data authentication in Access-Request packet.

Request Authenticator Dictionary Attacks Request Authenticator should be unique and non-predictable to be secure. Many implementations use poor PRNGs to provide the Request Authenticator. If the attacker can sniff the traffic, he can passively create a dictionary of Request Authenticators and their associated MD5(shared secret + Request Authenticator) values.

Active User-Password Compromise If the attacker observes a valid Access-Request packet which has a Request Authenticator value in the dictionary, the first 16 octets of the User-Password can be recovered by XORing the stored MD5 hash value.

Replay of Server Response If the attacker observes a Request Authenticator with an identifier that is in the dictionary, the attacker can masquerade as the server, and return the prior response. If the client sends a Access-Request packet with the same Request Authenticator and identifier as a previously observed successful authentication, the attacker can replay the server response, and authenticate to the client without knowing a valid password.

Replay of Server Response Similarly, the attacker could replay server Access-Reject packets to create a Denial-of-Service attack.

Shared Secret Vulnerability The protocol specifically permits the use of the same shared secret by many clients. RADIUS clients sharing the same secret can be viewed as a single client when gathering attack information.

Why use RADIUS? Commonly used in embedded systems (routers, switches, etc), which cannot handle large numbers of users with distinct authentication information. Facilitates centralized user administration (useful for ISPs) Other alternatives have less security. Widely implemented by hardware vendors

Questions What are the possible responses to an Access-Request packet? Access-Accept, Access-Reject, Access-Challenge Explain the unique timing requirements of RADIUS (i.e. why is UPD used rather than TCP). User can wait a few seconds to be authenticated, no ack overhead and aggressive packet retransmission required. Users don’t want to wait several minutes, so a reliable delivery 2 minutes later is unacceptable. Send request to alternate server instead.

Questions How does RADIUS authenticate between the client and server? Using a shared secret. What are the 2 primary concerns or best practices for a RADIUS installation? High “information entropy” (randomness) in the shared secret. Unpredictable and unique random numbers are generated for Request Authentication.

References http://www.celestix.com/products/radius/ http://www.microsoft.com/windows2000/techinfo/administration/radius.asp http://www.untruth.org/~josh/security/radius/radius-auth.html http://en.wikipedia.org/wiki/RADIUS http://www.ietf.org/rfc/rfc2865.txt?number=2865 http://www.ietf.org/rfc/rfc2866.txt?number=2866