1. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft IEEE 802.1X and RADIUS Security Bernard Aboba Ashwin Palekar Microsoft

2. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft Outline Introduction to RADIUS security RADIUS security vulnerabilities Vulnerabilities of RADIUS and IEEE 802.1X Suggested Fixes

3. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

4. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

5. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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)

6. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

7. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

8. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft RADIUS Vulnerabilities Details available at: http://www.untruth.org/~josh/security/radiushttp://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!

9. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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.

10. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

11. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

12. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft Summary – Vulnerabilities

13. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft 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

14. doc.: IEEE 802.11-01/TBD Submission November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft Feedback?