doc.: ieee 802.11-01/tbd submission november 2001 warren barkley, tim moore, bernard aboba/microsoft...

November 2001

Warren Barkley, Tim Moore, Bernard Aboba/Microsoft

doc.: IEEE 802.11-01/TBD

Submission

IEEE 802.1X and RADIUS Security

Bernard Aboba

Ashwin Palekar

Microsoft

November 2001



Submission

Outline

• Introduction to RADIUS security• RADIUS security vulnerabilities• Vulnerabilities of RADIUS and IEEE 802.1X• Suggested Fixes

November 2001



Submission

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



Submission

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



Submission

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



Submission

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



Submission

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



Submission

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



Submission

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



Submission

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



Submission

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



Submission

Summary – Vulnerabilities

PPP PPP PPP/802 PPP/802Attack PAP CHAP EAP-MD5 EAP-TLS/SRPOffline dictionary attack on RADIUS shared secret X X X XReal-time decryption of hidden attributes ?Offline dictionary attack on CHAP Response X XOnline attack against password X XForged Access-Request packets X XReplay of Access-Accept/Reject packets ? ? ? ?

November 2001



Submission

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



Submission

Feedback?

doc.: ieee 802.11-01/tbd submission november 2001 warren barkley, tim moore, bernard aboba/microsoft...

Documents