1 / 30

RADIUS Security Issues

Gabriel
Télécharger la présentation

RADIUS Security Issues

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. RADIUS Security Issues NIST RADIUS Security Review June 29, 2005 Bernard Aboba Microsoft http://www.drizzle.com/~aboba/RADEXT/NIST-RADIUS.ppt

    3. RADIUS Specifications RFCs RFC 2865: Authentication & Authorization (DS) RFC 2866: Accounting (I) RFC 2867: Accounting extensions for Tunneling (I) RFC 2868: Attributes for Tunneling (I) RFC 2869: RADIUS Extensions (I) RFC 3162: RADIUS and IPv6 (PS) RFC 3575: IANA Considerations (PS) RFC 3576: Dynamic Authorization Extensions (I) RFC 3579: RADIUS Support for EAP (I) RFC 3580: IEEE 802.1X Usage Guidelines (I) Internet-Drafts (RADEXT WG Work items) draft-ietf-radext-digest-auth: Digest Authentication draft-ietf-radext-chargeable-user-id-05.txt: Chargeable User Identity draft-ietf-geopriv-radius-lo-02.txt: Location objects in RADIUS Key: DS = Draft Standard PS = Proposed Standard I = Informational

    4. Sample RADIUS Usage Scenarios PPP Dialup (PAP/CHAP/MS-CHAPv1/v2/EAP) PPP over Ethernet (ADSL) VPN authentication PPTP, L2TP, IPsec tunnel mode with/XAUTH or IKEv2 802.1X, 802.11i, 802.16e iSCSI authentication (CHAP) HTTP/SIP Digest

    5. RADIUS Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code = 1 octet Identifier = 1 octet Length = 2 octets Authenticator = 16 octets

    6. Code Values (RFC 3575) # Message Reference ---- ------------------------- --------- 1 Access-Request [RFC2865] 2 Access-Accept [RFC2865] 3 Access-Reject [RFC2865] 4 Accounting-Request [RFC2865] 5 Accounting-Response [RFC2865] 6 Accounting-Status [RFC2882] (now Interim Accounting) 7 Password-Request [RFC2882] 8 Password-Ack [RFC2882] 9 Password-Reject [RFC2882] 10 Accounting-Message [RFC2882] 11 Access-Challenge [RFC2865] 12 Status-Server (experimental) [RFC2865] 13 Status-Client (experimental) [RFC2865] 21 Resource-Free-Request [RFC2882] 22 Resource-Free-Response [RFC2882] 23 Resource-Query-Request [RFC2882] 24 Resource-Query-Response [RFC2882] 25 Alternate-Resource- Reclaim-Request [RFC2882] 26 NAS-Reboot-Request [RFC2882] 27 NAS-Reboot-Response [RFC2882] 28 Reserved 29 Next-Passcode [RFC2882]

    7. Points of Note UDP is the only transport specified in RADIUS RFCs Authentication: port 1812 Accounting: port 1813 RADIUS over TLS (RADSEC) now in use RADIUS packet header has no version field Early versions of Diameter used a reserved CODE value to signal a new version (254) Authenticator processing The Authenticator field is fixed length (128 bits) No mechanism for negotiation of Authenticator algorithms

    8. RADIUS Threat Model (RFC 3579, Section 4.1) An adversary may attempt to acquire confidential data (e.g. user location) and identities by snooping RADIUS packets. An adversary may launch a dictionary attack against the RADIUS shared secret. An adversary may attempt to modify packets containing RADIUS messages. An adversary may attempt to inject packets into a RADIUS conversation. An adversary may launch a known plaintext attack, hoping to recover the key stream corresponding to a Request Authenticator. An adversary may attempt to replay a RADIUS exchange. An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to peer passwords. An authenticated NAS may attempt to forge NAS or session identification attributes. A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS. An attacker may attempt to act as a man-in-the-middle.

    9. RADIUS Application Layer Security Trust established between RADIUS clients and servers via shared secret (Often ignored) advice from RFC 2865: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. Support for per-packet integrity and authentication Request Authenticator: Accounting-Request, CoA-Request, Disconnect-Request Response Authenticator: Access-Accept/Reject/Challenge, Accounting Response, CoA-Response, Disconnect-Response Message-Authenticator attribute: required for RADIUS/EAP, Digest Attribute hiding Standardized attributes: User-Password, Tunnel-Password Vendor Specific Attributes (VSAs): RFC 2548

    10. RADIUS Application Layer Security (contd) No support for per-packet confidentiality Replay protection Event-Timestamp: Accounting-Request (optional), CoA-Request, Disconnect-Request (SHOULD) Request Authenticator: Access-Request (Mandatory). More advice from RFC 2865: In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. The Request Authenticator value in an Access-Request packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access- Request. Limitations The Request-Authenticator is not a counter, so RADIUS servers typically do not check for Request Authenticator reuse.

    11. The Authenticator Field Access-Request (RFC 2865) Request-Authenticator = 16 octet random number Access-Accept/Reject/Challenge (RFC 2865) Response-Authenticator = MD5(Code+Identifier+Length+RequestAuthenticator+Attributes+Secret) Accounting-Request (RFC 2866) Request-Authenticator = MD5(Code+Identifier+Length+16 zero octets+Attributes+Secret) Accounting-Response (RFC 2866) Response-Authenticator = MD5(Code+Identifier+Length+RequestAuthenticator+Attributes+Secret) CoA-Request and Disconnect-Request (RFC 3576) Request-Authenticator = MD5(Code+Identifier+Length+16 zero octets+Attributes+Secret) CoA-ACK/NAK, Disconnect-ACK/NAK (RFC 3576) Response-Authenticator = MD5(Code+Identifier+Length+RequestAuthenticator+Attributes+Secret)

    12. Message-Authenticator Attribute (RFC 3579) Access-Request Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) Access-Challenge/Accept/Reject Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) Accounting/CoA/Disconnect Request and Response Message-Authenticator calculation not defined in RFC 2866, 3576, so attribute is typically not used. Circular dependency: Request Authenticator depends on attributes, Message-Authenticator depends on the RA Potential solution: calculate Message-Authenticator assuming that both the authenticator field and Message-Authenticator attributes are zero.

    13. RADIUS Attribute Hiding From RFC 2868: Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P [plaintext] into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation). User-Password (RFC 2865) b(1) = MD5(S + R), c(1) = p(1) xor b(1), C = c(1) b(2) = MD5(S + c(1)), c(2) = p(2) xor b(2), C = C + c(2) b(i) = MD5(S + c(i-1)), c(i) = p(i) xor b(i), C = C + C(i) Tunnel-Password (RFC 2868) A (Salt)=16-bit unsigned integer Salt unique within each Access-Accept, left-most bit must be set b(1) = MD5(S + R + A), c(1) = p(1) xor b(1), C = c(1) b(2) = MD5(S + c(1)), c(2) = p(2) xor b(2), C = C + c(2) b(i) = MD5(S + c(i-1)), c(i) = p(i) xor b(i), C = C + c(i)

    14. RADIUS Attribute Hiding (contd) Microsoft VSAs (RFC 2548) MS-CHAP-MPPE-Keys Used to transmit MS-CHAPv1 keys Same mechanism as User-Password b(1) = MD5(S + R) MS-MPPE-Send-Key, MS-MPPE-Recv-Key Used to transmit MSK exported by EAP methods Uses mechanism similar to Tunnel-Password scheme b(1) = MD5(S + R + A), A (Salt)=16-bit unsigned integer Salt unique within each Access-Accept, left-most bit must be set

    15. Can We Eliminate MD5 Usage in RADIUS? Authenticator Field RADIUS client can request a new hash algorithm in the Access-Request Server supporting the proposed algorithm uses it in the Response Authenticator, includes an algorithm attribute Hash algorithm cant be negotiated within Accounting/CoA/Disconnect-Requests, since the Request Authenticator is a keyed MAC, not a nonce If the server doesnt support the new algorithm it must drop the packet. Result: Eliminating MD5 from the Authenticator Field requires a major protocol change (e.g. a version number) or manual configuration (difficult in large networks)

    16. Can We Eliminate MD5 Usage in RADIUS? Attributes Access/Accounting/CoA/Disconnect-Request Hash algorithm cant be negotiated prior to sending a Request RADIUS client and server need to be manually configured to send and accept the new algorithm. Access-Accept (Tunnel Password, VSAs) RADIUS server returns new attributes if the client requests them. Otherwise, legacy attributes are sent Summary: not easy to eradicate MD5 within RADIUS Eliminating MD5 from the Authenticator Field requires manual configuration or major protocol change. Upgrade required for RADIUS clients, proxies, and servers Eliminating MD5 from attributes in the Access-Request requires manual configuration or a major protocol change in situations where Message-Authenticator is required (e.g. 802.11 usage) Upgrade required for RADIUS clients, proxies and servers.

    17. RADIUS over IPsec Anticipated in RFC 2869, Section 5.14 (Message-Authenticator): IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure. IPsec usage defined in RFC 3162, optional in [DIGEST], RECOMMENDED in RFC 3576, 3579 RFC 3576, Section 5.3 and RFC 3579, Section 4.2: Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management. RADIUS over IPsec addresses known RADIUS security vulnerabilities (RFC 3579, Section 4.3) Protects against both MD5 collisions and dictionary attacks on MD5 & HMAC-MD5

    18. RADIUS over IPsec: Feasibility IKEv1 & IPsec now supported by all popular operating systems Upgrade typically not required for RADIUS proxies and servers. IPsec supported by some existing Access Points Aruba: http://www.wi-fitechnology.com/displayarticle1750.html Linksys: http://www.google.com/search?q=Linksys+IPsec&hl=en&lr=&start=50&sa=N Certificate support not required IKE Main Mode with pre-shared key can be used Hardware acceleration not required RADIUS/IPsec SAs are long-lived AES can be efficiently implemented in software IKE SA establishment negligible over the life of an SA, even with PFS Example: RADIUS server 100 authentications/second, 1000 octet packets, AES ciphersuite @ 60 cycles/octet in software (RFC 3723) 8 Access-Request/Response messages, Accounting-Request/Response Load = 60 million cycles/second, not an issue for a 3 Ghz server CPU! Example: AP 10 authentications/second = 6 million cycles/second, feasible on a 200 Mhz processor Commercial deployment in progress

    19. Suggested Approach to FIPS Compliance REQUIRE use of RADIUS over IPsec ESP with a non-null FIPS-compliant cipher (RFC 3162, 3576, 3579) Addresses all threats, including disclosure and offline dictionary attacks on MD5 Partial MD5 removal (Optional) Standardize new key attributes with FIPS-compliant key-wrap Non-goal Eradication of all MD5 usage within RADIUS

    20. Appendix A: Known RADIUS Vulnerabilities

    21. RADIUS Vulnerabilities: Questions & Answers Can an attacker modify Access-Requests in transit? Yes, if they dont contain a Message-Authenticator attribute. The Request-Authenticator is a nonce in Access-Request packets. Message-Authenticator is optional in packets with User-Password, CHAP-Password or ARAP-Password attributes [RFC3579]. Message-Authenticator is recommended in packets without User-Password, CHAP-Password, ARAP-Password or EAP-Message attributes [RFC3579] Message-Authenticator is mandatory in packets containing EAP-Message [RFC3579] or Digest attributes [DIGEST] User-Password is a cleartext password encrypted using the RADIUS shared secret, so it authenticates the user as well as the packet, but does not integrity protect the packet. ARAP-Password, CHAP-Password authenticate the user, but not the packet; no integrity protection Can an attacker replay Accounting/CoA/Disconnect-Request packets? Yes, if they dont contain Event-Timestamp. However, Billing Engines typically do duplicate elimination, so replay of Accounting-Request packets is not a major concern. Can an attacker sniff RADIUS packets? Yes. RADIUS only encrypts hidden attributes, not the entire packet.

    22. Q&A (contd) Can an attacker mount an offline dictionary attack on the RADIUS shared secret? 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 Doesnt help with cracking EAP methods resistant to dictionary attack

    23. Q&A (contd) Can an attacker decrypt hidden attributes in realtime? 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

    24. RADIUS Vulnerabilities in Detail Sources: RFC 3579, Section 4.3 An Analysis of the RADIUS Authentication Protocol, Joshua Hill, 2001 http://www.untruth.org/~josh/security/radius/radius-auth.html Privacy User-Name, Calling-Station-ID, NAS identification, location attributes sent in the clear. RADIUS can be sent over a wireless, either by design (e.g. an AP mesh) or due to an attack (ARP poisoning). Result: Exposure of user location. Partial Mitigation: User-Name privacy Forgery 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).

    25. RADIUS Vulnerabilities (contd) Replay Attacker can replay Accounting-Request, Disconnect-Request and CoA-Requests that do not contain an Event-Timestamp attribute Request Authenticator is a 128-bit quantity intended to be unpredictable and pseudo-random, but implementations may not use a cryptographic quality random number generator The Request Authenticator MUST be globally and temporally unique across the entire network, in case the RADIUS shared secret is (mis)used on multiple NASes RADIUS servers typically do not detect replay attacks, so if the RADIUS shared secret is reused, an attacker can replay an Access-Request (possibly on 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.

    26. RADIUS Vulnerabilities (contd) 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 Message-Authenticator attribute Attacker can attempt offline attack on any packet with a Message-Authenticator attribute HMAC-MD5 usage in Message-Authenticator attribute makes the attack more expensive, so Response Authenticator is weakest link.

    27. RADIUS Vulnerabilities (contd) 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 If Request Authenticator repeats on any RADIUS client using the same shared secret, then the User-Password attribute is compromised. Salt in Tunnel-Password, MS-MPPE-SEND-Key, MS-MPPE-RECV-Key makes the attack harder; Salt + Request Authenticator need to repeat. Note: Where PAP is not used (such as in EAP authentication), attack against User-Password not possible

    28. RADIUS Vulnerabilities (contd) Online 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)

    29. Mitigating RADIUS Vulnerabilities Implementations Support RADIUS over IPsec as RECOMMENDED in RFC 3576, 3579 Use a cryptographic quality random number generator for the Request Authenticator (see RFC 1750) Send Message-Authenticator attribute in all packets Require Message-Authenticator in all packets with an EAP-Message or Digest attribute Configuration Require use of a different, high-entropy RADIUS shared secret for each RADIUS client-server pair Dont limit secret to 16 characters Utilize a randomly generated shared secret Do not configure PAP for any user No PAP method in EAP, but EAP-TTLS supports PAP inside the TLS tunnel! Result: RADIUS proxy can send a User-Password attribute

    30. Feedback?

More Related