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 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

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

EAP Key Management Model (draft-ietf-eap-keying) 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

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”)

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

New Attributes EAP-Master-Session-Key EAP-Key-Name EAP-Peer-ID 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

Security Issues Privacy Keywrap Disclosure to unauthorized parties

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.

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 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 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

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)

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

Appendix: Disclosure Prevention Approaches

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

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

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

“LEAP of Faith” Approach Applicability Limitations 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

No Proxy Approach supported in -00 Applicability Limitations 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

NAS as EAP Peer Approach Applicability Limitations 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

Static KEKs Approach Applicability Limitations 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.

Feedback?