Extensions to EAP Keying (EAPExt)

1. Extensions to EAP Keying (EAPExt) {ldondeti, vidyan}@qualcomm.com

2. Outline • Motivation & problems to solve • Current Solutions, Gaps and Issues • 802.11 Model (802.11i, 802.11r, CAPWAP) • 802.16e Model • IKEv2 and its use of EAP • Current MSK usage summary • Extending the EAP keying hierarchy • EMSK usage • Use cases and requirements • Key derivation and caching requirements • Method agnostic EAP re-authentication requirements • Key derivation and delivery requirements • Visited domain keying requirements • PSK bootstrapping requirements • Notes on co-existence with existing solutions • Conclusion IETF66 Montreal

3. AAA-based Network Access Architecture AAA / EAP Server Auth – Authenticator EP – Enforcement Point … Authm Auth0 … … EPn2 EP12 EPn1 EP11 Peer IETF66 Montreal

4. Terminology • Enforcement Point (EP) • A logical entity that shares the TSK with the EAP peer and is responsible for port control • Initial Authenticator • The EAP authenticator with which the peer performs a full EAP exchange • Target Authenticator • An authenticator to which the peer may potentially roam • New Authenticator • The authenticator to which the peer roams; this authenticator may be one of the target authenticators IETF66 Montreal

5. Areas of Work & Motivation • EMSK usage and hierarchy • Motivation: Consistent and extensible definition of the EMSK hierarchy • Method agnostic EAP re-authentication • Motivation: Efficient EAP re-authentication upon re-attachment to points in the same domain • Visited domain key hierarchy • Motivation: Efficient EAP re-authentication in the visited domain • PSK Bootstrapping using EAP • Motivation: Installation of stronger PSKs; reduction in provisioning complexity IETF66 Montreal

6. 802.11 Reference Architecture AAA Figure shows the components of an 802.11-based architecture employing CAPWAP. The CAPWAP protocol handles the intra-AC (also viewed as intra-authenticator) roaming case. 802.11r partially addresses inter-AC roaming (as long as the ACs are within the same ESS and served by the same MDC) The proposed EMSK hierarchy handles inter-AC roaming irrespective of any ESS/MDC/ subnet boundaries. … ACm AC0 … … WTPn2 WTP1 WTPn1 WTP1 CAPWAP Protocol Peer EAP (Re-)authentication/(Roaming) IETF66 Montreal

7. 802.11r architecture (1/2) AAA Figure shows the components of an 802.11r-based architecture 80211r defines an R0-KH and several R1-KHs.. The R0-KH receives the MSK (uses the high 256 bits) and computes an R0-Key and R1-Keys corresponding to each R1-KH R0-KH to R1-KH key delivery has not been specified It is imperative that the key delivery happens over a secure channel This model results in a full-mesh of secure channels between the ACs or authenticators within an ESS R0-KH R1-KH2 … R1-KH1 … … WTPn2 WTP1 WTPn1 WTP1 Secure channel Peer IETF66 Montreal

8. 802.11r architecture (2/2) AAA In this mode of operation, an external MDC is used instead of the MDC being different for each peer. The MDC/R0-KH establishes a secure channel with each of the R1-KHs. Fewer secure channels, but an extra infrastructure entity is involved. MDC/R0-KH … R1-KHn R1-KH1 … … Secure channel WTPn2 WTP1 WTPn1 WTP1 Peer IETF66 Montreal

9. … PMK-R11 PMK-R1n … TSK1 TSKn Current 802.11i/802.11r Key Hierarchy Long Term Credential MSK EMSK Figure shows the existing 802.11i and 802.11r key hierarchy This key hierarchy does not use the EMSK; the second half of the MSK is used to derive the 802.11r R0-Key This is not a universal model used by other architectures employing EAP. PMK-R0 PMK TSK 802.11i 802.11r IETF66 Montreal

10. Current 802.16e Key Hierarchy Long Term Credential MSK EMSK MSK2 EIK PMK Figure shows the existing 802.16e key hierarchy This key hierarchy does not use the EMSK; The MSK is used in at least two different ways The MSK is used to derive a KEK, which encrypts a TEK selected by the BS PMK2 AK KEK IETF66 Montreal

11. MSK usage and limitations • The entire MSK is delivered to the Initial Authenticator • Parts of the MSK cannot be used to derive key material for other authenticators • MSK delivery mechanisms cannot be re-defined now • MSK usage is inconsistent across EAP lower layers • 802.11i uses the first half of the MSK for TSK generation • 802.11r uses the second half of the MSK as key material • 802.16e uses either 160 bits or 320 bits of the MSK depending on the mix of RSA and EAP based authentication and authorization • IKEv2 uses all 512 bits of the MSK in computing the AUTH payload • Conclusion: the MSK is not extensible for any other purpose IETF66 Montreal

12. Extending EAP – EMSK Usage • Specified in draft-salowey-eap-emsk-deriv-01 • Goal is to specify a tight spec for EMSK derivation and usage • Allow an extensible model for the EMSK for future uses • Usage Specific Root Keys (USRK) derived from EMSK • Every usage must be clearly defined and a usage label registered using an RFC IETF66 Montreal

13. Proposed EMSK Hierarchy Long Term Credential MSK EMSK … TSK USRK1 USRKn IETF66 Montreal

14. EMSK/USRK Key Derivation and Caching • Extended Master Session Key (EMSK) • EMSK derivation done by the EAP method • EMSK MUST NOT be used to protect any data directly • EMSK SHOULD be used for USRK generation only; EMSK SHOULD NOT be used directly to derive child keys for specific cryptographic operations • Usage Specific Root Key (USRK) • The usage definition MUST NOT use the EMSK in any other way except to derive USRKs • The usage definition SHOULD NOT require caching of the EMSK • Usage definition MUST define distinct key labels • Usage definitions MUST define the length of their USRK • Usage definitions MUST define how they use their USRK IETF66 Montreal

15. Method Agnostic EAP Re-authentication • Some EAP methods allow faster re-authentication • E.g., TLS session resumption, AKA re-authentication • Minimum of two roundtrips with the server • No modification to EAP messaging • Hence, cannot complete in less than 2 roundtrips • Results in unacceptable network access latency upon roaming • Method agnostic EAP re-authentication • Re-authentication without re-execution of EAP method • Proof of possession using key material from a previous EAP session • Single roundtrip exchange • Requires modification to EAP messaging • Results in a key between the peer and authenticator IETF66 Montreal

16. … TSK1 TSKn EMSK Hierarchy for Roaming / Re-authentication Long Term Credential Figure shows proposed key hierarchy for intra and inter authenticator roaming. The derivation of USRKs from the EMSK is specified in draft-salowey-eap-emsk-deriv-01. The rRK (Re-authentication Root Key) is a USRK defined for roaming purposes. The rRK is maintained at the AAA/EAP server. The rMSK is a re-authentication MSK from which TSKs are derived. The rMSK is delivered to the authenticator. This hierarchy allows the addition of fast re-authentication capability to 802.11i easily. The rMSK can be treated just as the MSK. MSK EMSK … TSK rRK Other RKs … rMSK1 rMSKn rIK IETF66 Montreal

17. EAP Efficient Re-authentication (EAP-ER) AAA Server Peer Auth1 Auth2 Full EAP Exchange MSK, EMSK, rRK MSK, EMSK, rRK, rIK EAP Request Identity EAP Re-authentication Response AAA (EAP) ([PNonce, Peer ID] rIK) AAA (EAP) rIK, rMSK EAP Re-authentication Information ([ASNonce] rIK, rMSK) ([ASNonce] rIK) rMSK Secure Association Protocol (TSK Generation) IETF66 Montreal

18. rMSK Delivery • rMSK must be delivered to the new authenticator following re-authentication • Options for key delivery • Pull and push models • Push model • Does not allow randomness contribution by the peer • Is not supported by RADIUS • Does not scale • Results in keys on target authenticators that the peer may never roam to • Target authenticators must store keys, key names, associated nonces, lifetimes, and other attributes for many peers unnecessarily • Peer needs to be involved in a re-authentication protocol anyway to receive nonces or other attributes • No value in the push model seen • Peer-initiated, on-demand pull model makes most sense! IETF66 Montreal

19. Visited Domain Authentication • Faster re-authentication while roaming in a visited domain • Eliminate the need to contact the home AAA server every time • Desirable to keep visited AAA servers stateless • Need to explore visited domain re-authentication IETF66 Montreal

20. PSK bootstrapping • Several protocols use PSKs for entity authentication • Configuring PSKs in all servers is an administrative burden • Sometimes keys are shared to get around the complexity • Configured PSKs may not be changed often enough and may not be as strong as they need to be • Proposal: Support PSK bootstrapping through EAP keying • Key derivation and delivery semantics need to be studied • Actual protocol is likely to be independent of EAP • Unlike any EAP re-authentication mechanisms IETF66 Montreal

21. Co-existence • New protocols and keying hierarchies must co-exist with existing schemes • E.g., 802.11r, 802.16e, CAPWAP IETF66 Montreal

22. Conclusion • Necessary areas of work • EMSK Usage and hierarchy • Method independent EAP re-authentication • Visited domain authentication and keying • PSK bootstrapping IETF66 Montreal

23. Requirements Discussion • MUST co-exist with other existing EAP keying based schemes • The keying hierarchy or protocol extensions must not preclude the use of the CAPWAP protocol • EMSK MUST be used as the root key for extensions to EAP keying hierarchy • Disparate uses of the MSK rules it out as a candidate • MUST work with the current AAA models • E.g., RADIUS only allows pull model operation • Any keying hierarchy and protocol defined MUST be lower layer independent in order to provide the capability over heterogeneous technologies • The defined protocols MAY, however, require some additional support from the lower layers that use it • Extensions to EAP MUST NOT require modifications to EAP methods • The designs and protocols MUST satisfy the Housley criteria • Any EAP keying extension mechanisms MUST be immune to domino effects • The solution MUST use the AAA server as the key store • The solution SHOULD use the AAA server as the key store? • Optionally a new entity is introduced, at the additional cost • An EAP re-authentication protocol defined MUST NOT exceed a single roundtrip to the server IETF66 Montreal