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

EAP layer

Lower Layer

EAP Method

EAP Authenticator

layer

EAP layer

Lower Layer

EAP Peer EAP Authenticator

EAP Method

EAP Authenticator

layer

EAP layer

AAA

EAP Server

AAA

EAPLayer

EAP Key Management Model(draft-ietf-eap-keying)

EAP Method

MSK EMSK IV(deprecated)

Peer-ID Server-ID

Method-ID

Key-Lifetime

EAP Peer/Authenticator

Layer

Session-ID

Exp. Type || Method-Id

Lower LayerChannelBindings

Key:Mandatory

Optional

Flow of EAP Keying Parameters

EAP Method

EAP Peer layer

EAP layer

Lower Layer

EAP Method

EAP Authenticator

layer

EAP layer

Lower Layer

EAP Peer EAP Authenticator

EAP Method

EAP Authenticator

layer

EAP layer

AAA

EAP Server

AAA

Key:EAP peer & authenticator only (no backend server)

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

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

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

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

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