November 2001 doc.: IEEE 802.

11-01/TBD

IEEE 802.1X and RADIUS Security

Bernard Aboba
Ashwin Palekar
Microsoft

Warren Barkley, Tim Moore, Bernard

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

Outline

• Introduction to RADIUS security

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

Warren Barkley, Tim Moore, Bernard

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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
Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

Summary – Vulnerabilities
PPP PPP PPP/802 PPP/802
Attack PAP CHAP EAP-MD5 EAP-TLS/SRP
Offline dictionary attack on RADIUS shared secret X X X X
Real-time decryption of hidden attributes ?
Offline dictionary attack on CHAP Response X X
Online attack against password X X
Forged Access-Request packets X X
Replay of Access-Accept/Reject packets ? ? ? ?

Warren Barkley, Tim Moore, Bernard

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

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

Submission
Aboba/Microsoft
 November 2001 doc.: IEEE 802.11-01/TBD

Feedback?

Warren Barkley, Tim Moore, Bernard

Submission
Aboba/Microsoft