1 / 21

RADEXT WG

RADEXT WG. RADIUS Attributes for WLAN Draft-aboba-radext-wlan-00.txt Jari Arkko (for Bernard Aboba) IETF 63 Paris, France. Document History. Goal: Attributes for existing (and future) IEEE 802.11 usage Potential liaison requests from IEEE 802.11r, IEEE 802.11u

bella
Download Presentation

RADEXT WG

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. RADEXT WG RADIUS Attributes for WLAN Draft-aboba-radext-wlan-00.txt Jari Arkko (for Bernard Aboba) IETF 63 Paris, France

  2. Document History • Goal: Attributes for existing (and future) IEEE 802.11 usage • Potential liaison requests from IEEE 802.11r, IEEE 802.11u • Includes WLAN attributes originally included in draft-congdon-ieee802-02.txt • Allowed-SSID • Allowed-Called-Station-ID • Includes RADIUS attributes corresponding to Diameter EAP (RFC 4072) AVPs: • EAP-Master-Session-Key • EAP-Key-Name (already allocated in RADIUS attribute space) • Accounting-EAP-Auth-Method • Includes attributes described in draft-ietf-eap-keying: • EAP-Peer-ID • EAP-Server-ID

  3. EAP Conversation EAP Method EAP Method EAP Method EAP Peer layer EAP Authenticator layer EAP Authenticator layer EAP layer EAP layer EAP layer Lower Layer Lower Layer AAA AAA EAP Peer EAP Authenticator EAP Server

  4. EAP Key Management Model(draft-ietf-eap-keying) EAP Method Method-ID EAP Peer/ Authenticator Layer EAP Layer Exp. Type || Method-Id MSK EMSK IV (deprecated) Peer-ID Server-ID Session-ID Key-Lifetime Channel Bindings Lower Layer Mandatory Key: Optional

  5. Flow of EAP Keying Parameters EAP Method EAP Method EAP Method EAP Peer layer EAP Authenticator layer EAP Authenticator layer EAP layer EAP layer EAP layer Lower Layer Lower Layer AAA AAA EAP Peer EAP Authenticator EAP Server EAP peer & authenticator only (no backend server) Key: EAP peer & server (authenticator “pass-through”)

  6. AAA Requirements • Replication of keying material • In existing usage, only the MSK is replicated • IV is deprecated (RFC 3748) • EMSK MUST NOT be replicated (draft-ietf-eap-keying) • Transport of other EAP keying parameters • Session-ID: Unique EAP conversation identifier • Each method has its own unique identifier space • Peer-ID & Server-ID: Peer and Server identifiers used by the method • Key-Lifetime: MSK/EMSK lifetime, if negotiated by the method • No need for new AAA attribute, can be handled via Session-Timeout

  7. New Attributes • EAP-Master-Session-Key • Darries the MSK exported by the method • Defined in RFC 4072, allocated as a Diameter AVP • EAP-Key-Name • Carries the EAP Session-ID, if exported by the EAP layer • Defined in RFC 4072, allocated as a RADIUS attribute • EAP-Peer-ID • Carries the Peer-ID, if exported by the method (and requested by the NAS) • EAP-Server-ID • Carries the Server-ID, if exported by the method (and requested by the NAS) • Allowed-SSID • Specifies one or more SSIDs which the STA is allowed to access • With EAP pre-authentication, AAA server may not know which SSID the STA will Associate with • Allowed-Called-Station-ID • Specifies one or more Called-Station-IDs the STA is allowed to access • AAA server may wish to restrict access to one or more BSSIDs

  8. Security Issues • Privacy • Keywrap • Disclosure to unauthorized parties

  9. Privacy • Privacy may be desired • “anonymous@realm” or “@realm” NAIs may be used in EAP-Response/Identity • EAP-Peer-ID or EAP-Server-ID are not sent by the backend server unless requested by the NAS.

  10. Keywrap • -00 proposes use of AES Keywrap (RFC 3394, Section 4.1) • Protection provided on a hop-by-hop basis • Options for the Key Encryption Key (KEK) • Derived from the RADIUS shared secret (-00 approach) • Pros • Requires only a single secret between RADIUS client & server • Cons • If the RADIUS shared secret is compromised, attacker can unwrap the key and can also forge packets • Use a cryptographically separate KEK and MAC key • Pros • RADIUS shared secret no longer a valuable target • Obtaining the RADIUS shared secret does not permit unwrapping of keys (KEK) or forgery of packets (MAC key) • Can be made backward compatible with existing implementations • Cons • Requires three shared secrets between RADIUS client & server • If KEK and MAC key are based on passwords, they are susceptible to offline dictionary attack just like the RADIUS shared secret • Doesn’t matter • Use IPsec to protect RADIUS instead

  11. Disclosure • Disclosure of keying material to unauthorized parties is problematic • See “AAA Key Management”, draft-housley-aaa-key-mgmt-00.txt • Compromise of RADIUS proxy leads to compromise of all RADIUS clients of that proxy (“Domino Effect”) • Fixing this is a known “hard problem” • AAA WG worked on Diameter CMS for several years before giving up • All proposed approaches have some drawbacks • See Appendix for details • Recommendation • Do not attempt to solve the disclosure problem in this document • Consider amending the RADEXT WG charter in future to handle this and other security-related issues (such as FIPS Certification)

  12. Questions • Should this document become a WG work item? • What approach should we take to keywrap? • Do we need to solve the disclosure problem?

  13. Appendix:Disclosure Prevention Approaches

  14. Potential Approaches • Inter-domain as well as intra-domain support • Redirect • DNS-based Key Establishment • “Leap of Faith” • Intra-domain support only • NAS as EAP peer • Static KEKs

  15. Redirect Approach • Approach taken by RFC 4072 (Diameter EAP) • Diameter conversation protected by TLS and/or IPsec • Diameter Agent provides the client with the server address corresponding to the NAI realm • Diameter client contacts the server directly to retrieve keys • Keys protected by TLS and/or IPsec (no keywrap in RFC 4072) • Applicability • Inter-domain and intra-domain use • Limitations • AAA client & agent need to support Redirect • AAA client & server need to use certificates • IKE limitations make it difficult to choose appropriate certificates for a given application • Example: AAA client using IPsec to protect Diameter as well as Telnet or FTP • Server will not know if the IKE initiator intends to set up a Phase I SA for Diameter or FTP, may choose the wrong certificate

  16. DNS-Based Key Establishment • Under development in Terena Mobility Task Force (Eduroam) • RADIUS client utilizes RADIUS server discovery as described in RFC 3588 • RADIUS server public key made available via DNS • DNSSEC used to protect DNS RRs • RADIUS client establishes direct contact with RADIUS server • RADIUS conversation protected by TLS (RADSEC) or IPsec • Running code now available (RADIATOR) • Reference: Eertink, Peddemors, Arends & Wierenga: “Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains” • http://www.eduroam.org/ • http://www.terena.nl/conferences/tnc2005/programme/presentations/show.php?pres_id=51 • Applicability • Inter-domain and intra-domain use • Limitations • AAA client & server need to store Key RRs in the DNS • AAA client & server need to support DNSSEC

  17. “LEAP of Faith” • Approach • NAS & RADIUS server provisioned with static DH keys • Prior to sending an Access-Request to a RADIUS server, the NAS “registers” with the RADIUS server via anonymous DH. • RADIUS server stores the DH parameters associated with each registered NAS • DH-derived key used to derive the KEK used for keywrap of the EAP-Master-Session-Key attribute • Applicability • Inter-domain & intra-domain use • Limitations • Vulnerable to man-in-the-middle attack on initial registration • RADIUS server must store keys for all NASes that communicate with it. • NAS & RADIUS server must natively support registration mechanism

  18. No Proxy • Approach supported in -00 • Assumes RADIUS client talks directly to RADIUS server • Can be combined with re-direct or DNS-based keying approaches to avoid proxy disclosure • Applicability • Inter-domain and intra-domain use • Limitations • Avoids disclosure only when no proxies are used. • At worst, administrative overhead is the same as the static KEK approach

  19. NAS as EAP Peer • Approach • NAS & RADIUS server have a pre-existing relationship • NAS authenticates to the home RADIUS server, derives EAP keying material • EAP keying material used to derive the KEK used to keywrap the EAP-Master-Session-Key attribute • Applicability • Applicable only to intra-domain use (no roaming) • Limitations • NAS must support EAP, as well as share a common EAP (key deriving) method with the RADIUS server • NAS must have an account on the RADIUS server

  20. Static KEKs • Approach • NAS & RADIUS server provisioned with static KEKs • Static KEK used for keywrap of the EAP-Master-Session-Key attribute • Applicability • Applicable to intra-domain use only (no roaming) • Limitations • Manual re-provisioning required if KEK becomes stale • RADIUS server must store a KEK for all NASes that communicate with it.

  21. Feedback?

More Related