11 01 Tbd I Radius Security
- 1. IEEE 802.1X and RADIUS Security Bernard Aboba Ashwin Palekar Microsoft November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 2. Outline Introduction to RADIUS security RADIUS security vulnerabilities Vulnerabilities of RADIUS and IEEE 802.1X Suggested Fixes November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 3. RADIUS Security Features RADIUS application layer security Trust established between RADIUS clients and servers via shared secret Support for per-packet integrity and authentication Request and Response Authenticator fields Message-Authenticator attribute Support for hiding of specific attributes Standardized attributes: User-Password, Tunnel-Password Microsoft Vendor Specific Attributes (VSAs) No general support for confidentiality No support for replay protection 128-bit Authentication Request Authenticator field is pseudo-random and unpredictable Not a counter, RADIUS servers typically do not check for reuse RADIUS over IPsec Support for per-packet integrity, authentication, confidentiality and replay protection for both authentication and accounting packets Usage described in RFC 3162 November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 4. Per-Packet Authentication & Integrity Authentication packets without EAP-Message attribute (RFC 2865) No per-packet authentication for Access-Request packets Access-Request packet contains a 128-bit pseudo-random Request Authenticator (RA) In Access-Request packets, RA is really a nonce, not an Authenticator RA nonce used in hiding of user passwords sent within Access-Requests Result: Access-Request packets are not authenticated Per-packet authentication for Access-Challenge, Access-Reject, Access-Accept packets 128-bit Response Authenticator = MD5(Code + Identifier + Length + Request Authenticator + Attributes + Shared Secret) Note: NAS-IP-Address or NAS-Identifier attributes MUST NOT be included in this calculation, since they cannot be included in Access-Challenge, Access-Reject and Access-Accept packets November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 5. Per Packet Integrity & Authentication (cont’d) Authentication packets with EAP-Message attribute (RFC 2869) Per-packet authentication for all packets RFC 2869 requires inclusion of the Message-Authenticator attribute within packets containing EAP-Message attributes (Access-Request, Access-Accept, Access-Reject, Access-Challenge) Message-Authenticator attribute provides per-packet authentication For Access-Request, Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) For Access-Accept, Access-Reject, Access-Challenge, Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) Accounting packets (RFC 2866) Per-packet authentication for Accounting-Request, Accounting-Response packets Accounting-Request Authenticator = MD5(Code + Identifier + Length + 16 zero octets + Request Attributes + Shared Secret) NAS-IP-Address or NAS-Identifier attributes MAY be included in this calculation, 0-1 of these attributes MAY be included in the Accounting-Request (but not the Accounting-Response). Accounting-Response Authenticator = MD5(Accounting-Response Code, Identifier, Length, Accounting-Request Authenticator, Response attributes, Shared Secret) November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 6. Attribute Hiding User-Password (RFC 2865) Utilized for PPP PAP authentication (now deprecated) PAP now most frequently used with token card authentication Also utilized for HTTP Basic authentication Cleartext authentication not supported within EAP, so User-Password attributes are never sent in IEEE 802.1X authentication over RADIUS Key stream generated from RADIUS shared secret and 128-bit request authenticator B1 = MD5(Secret + RA) Bi = MD5(S + c(i-1)) Ciphertext based on XOR’ing keystream with the cleartext password Ci = Pi XOR Bi Pi = ith 128-bit block of the password Tunnel-Password (RFC 2868) Similar to User-Password hiding scheme B1 = MD5(Secret + RA + Salt), Salt=16-bit unsigned integer Salt unique within each Access-Accept, left-most bit must be set November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 7. Attribute Hiding (cont’d) Microsoft VSAs (RFC 2548) MS-CHAP-MPPE-Keys Used to transmit MS-CHAPv1 keys Same mechanism as User-Password scheme B1 = MD5(Secret + RA) MS-MPPE-Send-Key, MS-MPPE-Recv-Key MAY be used to transmit EAP keys Uses mechanism similar to Tunnel-Password scheme B1 = MD5(Secret + RA + Salt), Salt=16-bit unsigned integer Salt unique within each Access-Accept, left-most bit must be set November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 8. RADIUS Vulnerabilities Details available at: http://www.untruth.org/~josh/security/radius Offline dictionary attack on RADIUS Shared Secret via RFC 2865 Response Authenticator or RFC 2866 Request or Response Authenticators Many implementations only allow shared-secrets that are ASCII characters, and less than 16 characters; resulting RADIUS shared secrets are low entropy! Attacker can capture Access-Request/Response or Accounting-Request or Accounting-Response for an offline dictionary attack MD5 state can be pre-computed so dictionary attack is efficient Offline dictionary attack on RADIUS Shared Secret via EAP-Message attribute Attacker can attempt offline attack on any packet with an EAP-Message attribute HMAC-MD5 usage in EAP-Message attribute makes the attack more expensive, so Response Authenticator is weakest link. Real-time decryption of hidden attributes An attacker authenticating via PAP can, by collecting RADIUS Access-Request packets, determine the keystream used to protect the User-Password attribute Enables the attacker to collect Request Authenticators/IDs and corresponding key streams For each captured keystream, attacker can generate new keystreams for each Salt Value As table of RA/ID/Salt values increases, real-time decryption of User-Password, Tunnel-Password, MPPE-Key attributes becomes possible Note: Where PAP is not used (such as in EAP authentication), attack against User-Password not possible Known plaintext attack against Tunnel-Password An attacker cracking a User-Password can send a forged Access-Request, receive back a Access-Response containing a tunnel password attribute and salt Since MD5(Secret+RA) is known, as is Salt, it is possible to immediately calculate MD5(Secret+RA+Salt) Tunnel-Password is immediately compromised! November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 9. RADIUS Vulnerabilities (cont’d) Online dictionary attack against the PAP password Works for RADIUS servers enabling replay of Request Authenticator (16 octets) and Identifier (only one octet) fields By authenticating with PAP and capturing the User-Password attribute, attacker can derive the key stream for an RA and ID Attacker can then attempt an online dictionary attack against the user password of 16 characters or less, using the same Request authenticator, Identifier and key stream. Note: this attack is not possible if a Message-Authenticator attribute is required (such as in EAP messages) Forging Attacker can forge RADIUS Access-Request packets (since these packets are not authenticated) Note: this attack not possible if Message-Authenticator attribute is present (e.g. EAP Access-Request). Access-Accept/Reject Replay Request Authenticator is a 128-bit quantity intended to be unpredictable and pseudo-random However, not all implementations use a credible pseudo-random number generator Same RADIUS shared secret often used on multiple NASen – implies that Request Authenticator MUST be globally and temporally unique across the entire network If the Request Authenticator and Identifier are reused by NAS, then an attacker can replay the Access-Response (possibly to another NAS!) Replay not confined to the original NAS, since the NAS-Identifier or NAS-IP-Address attributes MUST NOT be included in Access-Response packets. November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 10. Is Offline Dictionary Attack on RADIUS Shared Secret Possible? Simple answer: yes Offline dictionary attack only requires capturing a single Request/Response Authenticator pair Administrators frequently choose shared secrets amenable to dictionary attack RADIUS implementations often only allow 16 character passwords; English dictionary words only have 1.2 bits of entropy per character Same Shared Secret often used for multiple NASen Once Shared Secret is compromised, RADIUS security ineffective Hidden attributes can be decrypted on the fly All packet types can be forged But… Still need to mount offline dictionary attacks on CHAP, EAP-MD5 Doesn’t help with cracking methods invulnerable to dictionary attack, like EAP TLS or SRP November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 11. Is Real-Time Decryption Really Possible? If Request-Authenticator is random and globally and temporally unique (as required in RFC 2865), then this attack is infeasible. Example At 10 Gbps, 1 million NASen can send maximum of 2 billion RADIUS Access-Request/second, or 73.54 quadrillion Access-Requests/year Cycling through 128-bit request authenticator space will take more than a trillion years! However, if Request Authenticator is not randomly generated, then it can repeat Using the same shared secret on each NAS makes this more likely November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 12. Summary – Vulnerabilities November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 13. Suggested Fixes Don’t allow PAP EAP authentication already requires this (no PAP support) Use credible generator for Request Authenticator (see RFC 1750) Use RADIUS over IPsec ESP with a non-null transform (RFC 3162) Inclusion of Message-Authenticator attribute in all packets RFC 2869 already requires this for EAP authentication Use a high-entropy RADIUS shared secret Don’t limit shared secret to 16 characters Utilize a randomly generated shared secret Use of a different shared secret for each RADIUS client-server pair November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
- 14. Feedback? November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft