• Like
  • Save
11 01 Tbd I Radius Security
Upcoming SlideShare
Loading in...5
×
 

11 01 Tbd I Radius Security

on

  • 726 views

 

Statistics

Views

Total Views
726
Views on SlideShare
726
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    11 01 Tbd I Radius Security 11 01 Tbd I Radius Security Presentation Transcript

    • IEEE 802.1X and RADIUS Security Bernard Aboba Ashwin Palekar Microsoft 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
      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
      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
      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)
      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
      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
      November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
    • 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 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.
      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
      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
      November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
    • Summary – Vulnerabilities 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
      November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft
    • Feedback? November 2001 Warren Barkley, Tim Moore, Bernard Aboba/Microsoft