1 / 14

IEEE 802.1X and RADIUS Security

IEEE 802.1X and RADIUS Security. Bernard Aboba Ashwin Palekar Microsoft. Outline. Introduction to RADIUS security RADIUS security vulnerabilities Vulnerabilities of RADIUS and IEEE 802.1X Suggested Fixes. RADIUS Security Features. RADIUS application layer security

uma-sanford
Télécharger la présentation

IEEE 802.1X and RADIUS Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE 802.1X and RADIUS Security Bernard Aboba Ashwin Palekar Microsoft 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 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 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 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) 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 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 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! 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. 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 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 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft

  12. Summary – Vulnerabilities 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 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft

  14. Feedback? Warren Barkley, Tim Moore, Bernard Aboba/Microsoft

More Related