11 01 Tbd I Radius Security

582 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
582
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

11 01 Tbd I Radius Security

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

×