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 usage
Potential liaison requests from IEEE r, IEEE u
Includes WLAN attributes originally included in draft-congdon-ieee 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)
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 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

8. Security Issues
Privacy
Keywrap
Disclosure to unauthorized parties

9. Privacy Privacy may be desired
or 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
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

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

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

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

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

21. Feedback?