1. 21-07-0127-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0127-00-0000 Title: Handover security in a heterogeneous Access Environment IETF HOKEY-IEEE 802.21 Integration Date Submitted: March 15, 2007 Presented at IEEE 802.21 plenary session in Orlando Florida Authors or Source(s): Your Name Here, Your Name Here, Your Name Here Abstract: This is the abstract text. Replace this text with a short statement of the contents and purpose of the presentation. Communicate well, you only have a few lines or so to convey the essence of the slides.

2. 21-07-0127-00-0000 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html

3. 21-07-0127-00-0000 Handover security in a heterogeneous Access Environment IETF HOKEY-IEEE 802.21 Integration References: draft-nakhjiri-hokey-hierarchy-03 draft-ietf-hokey-reauth-ps-01 Madjid Nakhjiri March 15, 2007 For IEEE 802.21

4. 21-07-0127-00-0000 EAP is extensible: Perfect for media independent access control and security management EAP Authentication between end device/user and backend server Mode independence: Point to point authentication, or to EAP/AAA server Can reach home network Over an untrusted visited operator links Over dumb/light edge devices; keep user info/crypto only at the ends Algorithm independence: Easy introduction of crypto-de-jour: only to the ends, not to NAS Media independence signaling: EAP signaling to be Independent of access technology EAP signaling carried over the existing AAA infrastructure Create trust between previously untrusted entities EAP authentication framework was extended with a keying framework Master keys to be used as root keys for setting up other security association

5. 21-07-0127-00-0000 Is EAP enough? EAP is mode and media independent Pros: dumb devices (NAS) can be used while keeping user info at the back (AAA servers); Cons: NAS is unknown, untrusted (can lie) Needed: EAP must be encapsulated over access technology (802.11: EAPOL, 802.16e: PKMv2) Needed: link layer parameters (e.g. NAS ID) to be confirmed EAP is an IETF protocol, link layer out of scope EAP key management only down to authenticators Needed: key management between authenticator and end client (e.g. 802.11i 4 way exchange, 802.16e TEK management) EAP keying not designed with mobility performance in mind Issues with wireless deployments architectures Issues with latency performance Needed: overhaul from integrated mobility-security perspective

6. 21-07-0127-00-0000 EAP Key management framework Holds Peer credential Generation of MSK, EMSK, EAP complete peer Authenticator EAP/AAA server Security Association Protocol (TSKs) EAP over AAA EAP-XXX Method Authentication MSK transport EAP over L2 Transported MSK Generation of TSKs Use TSKs for link security Outside IETF scope Causes issues

7. 21-07-0127-00-0000 Hokey: new WG to deal with EAP deficiencies Goal 1: Optimize performance: Reduce RTs to AAA server Handovers without need for full EAP authentications Roaming to new visited operators/ domains Session extension when current life time expires Goal 2: Preserve Security: No domino effects, Principle of least privilege How 1: Expand EAP keying framework by Complete underspecified parts of EAP key hierarchy (EMSK) Key generation for generic use cases (Mobile IP, handover, etc) Specify key hierarchy for handover, roaming, re-authentication How 2: Define signaling methods that allows for management of those keys

8. 21-07-0127-00-0000 Outside IETF scope Hierarchical 2-level Deployments: (WiMAX, CAPWAP) Authenticator/ Gateway at level1 and BS/AP at level 2 AAA server Gateway 1 BS2 MN Access Domain 1 Managed by ADC1 Access Domain 2 managed by ADC2 BS3 BS1 ADMSK1 HRK ADMSK2 GW2 BS Master key distribution LSAP ADC=Authenticator=Access domain controller ADMSK=Access domain Master key LSAP=Link Security association protocol BS4

9. 21-07-0127-00-0000 802.16e key hierarchy based on EAP MSK EIK | PMK= truncate (MSK, 320) AK=Dot16KDF(PMK, SSID|BSID|”AK”, 160) Based on MS-AAA EAP Delivered to ASN-GW HMAC_KEY_U (160)| HMAC_KEY_D (160)|KEK(128)= Dot16KDF (AK, SSID | BSID| “HMAC_KEYS+KEK”, 448) Pairwise Master Key At ASN gatway AK: Authorization key Derived at ASN-GW Delivered to each BS Requires new PMK or Anchoring of PMK when MS moves to new Authenticator

10. 21-07-0127-00-0000 802.16e/m key hierarchy Had HOKEY been used ADMSK EIK | PMK= truncate (MSK, 320) AK=Dot16KDF(PMK, SSID|BSID|”AK”, 160) created at AAA server, Delivered to ASN-GW HMAC_KEY_U (160)| HMAC_KEY_D (160)|KEK(128)= Dot16KDF (AK, SSID | BSID| “HMAC_KEYS+KEK”, 448) Pairwise Master Key At ASN gatway AK: Authorization key Derived at ASN-GW Delivered to each BS EMSK Based on MS-AAA EAP New ADMSK generated from same EMSK

11. 21-07-0127-00-0000 Hokey scope: Domain level down to authenticator Terminology work under progress ADMSK2 AAA server Authenticator 1 ADMSK1 HRK Authenticator 2 AAA_RK Home Administrative Domain EMSK AAA Visited Domain 1 DSRK1 AAA Visited Domain 2 DSRK2

12. 21-07-0127-00-0000 Outside IETF scope HOKEY framework for common deployments?? Terminology work under progress Generation of MSK, EMSK, peer ADC/ Authenticator EAP/AAA server Link Security Association Protocol (LSAP) EAP over AAA EAP Authentication ADMSK transport EAP over L2 BS master key LSAP-MK LSAP-MK Use LSK for [link traffic] BS/AP EAP over L2 LSAP-MK transport LSAP-MK generation Generation of HRK, ADMSK LSK generation

13. 21-07-0127-00-0000 Will IETF and HOKEY be enough? Scope: Hokey ~EAP ~IETF: No link layer specifics Link level (MS-BS) security association and key derivation methodology is access technology specific today. 802.11i: 4 way handshake 802.16e: AK and authorization exchange, TEK delivery Carrying link level parameters? Link level parameters needed for channel binding, key derivation Link layer parameters are access technology specific Carrying EAP and HOKEY signaling over Link layers? 802.1x and 802.11 over EAPOL, 802.16e over PKMv2 Outside Hokey scope: Hierarchical deployments? Extensions to key hierarchy below authenticator Key distribution from authenticator to base station 802.11r issues, Kerberos, etc How to deal with intra-authenticator handovers (BS-BS)?

14. 21-07-0127-00-0000 How 802.21 can help HOKEY? extending HOKEY to link layer Easy: Define media independent TLVs for carrying security and authorization parameters (channel binding, keying: life time, key usage) Motivation: AAA infrastructure/signaling ends at BS/Authenticator, does not extend to MS Easy or done?: Define media-independent format and transport (commands to carry) for link identifiers (both Mobile identifier and BS identifier) Motivation: link IDs are needed at network level entities behind BS (AAA server/ Domain controller/ Authenticator) and protocol signaling (HOKEY and EAP) for key derivation and security enhancements (e.g. channel binding) Easy: Define syntax and transport for carrying AAA entity IDs (Authenticator/ mobility domain/ visited domain AAA) The MS needs this IDs for key requests and derivations

15. 21-07-0127-00-0000 How 802.21 can help HOKEY? (2) Easy: Define media independent encapsulation (commands) for EAP and HOKEY signaling Motivation: Today: EAPOL (802.11), PKMv2 (802.16e), EAPoverfoo (3GPP2) Easier adoption of EAP and Hokey as extensible and powerful media independent access control tools To do: EAP request/ EAP response Easy: define separate EAP/ HOKEY trigger Motivation: authentication and keying is very time consuming, should start early. Keys can be fetched without actual handover. Ping-ponging Start Pre-authentication/ start key acquisition signaling before the handover completion/ commitment Easy: Key install commands

16. 21-07-0127-00-0000 How 802.21 can help? (3) Tough but Ideal: Media Independent Extension of HOKEY model to cover 2 level deployment: Gateway + BS Motivation: Gateway (authenticator) in IETF scope, base station is not. Motivation 2: IETF does not deal with handovers below authenticator (intra-ADC) To do: Extend HOKEY key hierarchy below gateway and down to BS (this is done in draft-nakhjiri-hokey-hierarchy-03). To do: define methods to carry master keys from infrastructure to BS 802.11r has issues with key transport WiMAX defines an AK transfer protocol, but considers security of the transfer out of scope.

17. 21-07-0127-00-0000 Existing MIH command groups (req/resp, etc) MIH Get status/ MIH Scan MIH Switch MIH Configure Link MIH Net/MN/N2N HO candidate query/ commit/ complete MIH Network (IP) address information Also Link commands Capability Discover Link Event subscribe/unsubscribe Link Configure Thresholds Link Get Parameters

18. 21-07-0127-00-0000 Example of Needed MIH commands/triggers Command: MIH encapsulated-EH-request/response (EH: EAP HOKEY) To encapsulate EAP requests and responses in a link-independent manner (see PKMv2 for 802.16e) TLVs: security parameters to Configure-Link Label for keys to install, life time, scope, context, etc. Identifiers for Authenticator, and AAA server Trigger: start pre-authentication trigger, start hokey signaling trigger

19. 21-07-0127-00-0000 Examples & Illustrations

20. 21-07-0127-00-0000 Initial EAP-XXX Method Authentication Example 2: Initial entry/ EAP compatibility EAP/ key request signaling should be carried by an Media independent encapsulation MN/ Peer AN ADC1 EAP/AAA server EAP success HRK ADMSK AAA_RK EMSK HRK, ADMSK AAA_RK LSAP-MK, ADC-ID LSAP-MK LSAP Authenticator1 EAP success KRQ/CB KRP/CB ADMSK KRP/CB KRQ/CB KRP/CB

21. 21-07-0127-00-0000 Full Key hierarchy generation EMSK HRK ADMSK1 LSAP-MK1 ADC-RK LSK-ELSK-A AAA_RK USRK PRF AAA ID, MN ID MN ID, Authenticator ID HO PRF ADMSKm ADC PRF LSAP-MK2 At EAP server to AAA server MN ID, BS ID Data needed for generation Location of generation, transport At AAA server to ADC At ADC to BS MN ID, BS ID, nonces 802.11: Simultaneous at BS and peer 802.16: at BS to peer Outside HOKEY scope

22. 21-07-0127-00-0000 Example 1: Inter-ADC handover scenario (HOKEY scope) AAA server MN BS1 LSAP-MK3 ADMSK2 AAA-Re-Authentication +Key Request ADC1 ADC2 BS2 BS3 AD 1 AD2

23. 21-07-0127-00-0000 Intra-ADC handover scenario Outside HOKEY scope AAA server BS2 MN BS3 BS1 LSAP-MK2 HRQ ADC1 AD 1 AD2 ADC2 Proactive Reactive LSAP-MK1

24. 21-07-0127-00-0000 Reactive Inter-ADC Handover Keying MIH commands and TLVs to carry signaling HRQ, CB, ADC_RK, AAA_RK MN/EAP Peer AN1AN3ADC 1ADC 2 AAA server Scan: AN3-ID, ADC2_ID* LSAP HRQ, CB HKRQ, CB HRP LSAP_MK HRP HKRB, CB, ADMSK

25. 21-07-0127-00-0000 BACKUP

26. 21-07-0127-00-0000 Key generation considerations Work under progress in HOKEY info from draft-nakhjiri-hokey-hierarchy-03 HRK is derived from EMSK as USRK EAP server holds EMSK and derives HRK AAA server holds HRK PRF based on USRK guidelines: default or negotiated AAA server is HRK Key Holder, HRK used for AAA_RK: fast re-authentication/ADC handover authorization/ADMSK channel binding Per-Authenticator/ADC keys (ADMSK) PRF chosen for handover ADC is ADMSK Key holder, ADMSK used for ADC_RK: fast re-auth to ADC/ AN handover authorization/ LSAP_MK channel binding LSAP_MK: link SAP Master keys for ANs.

27. 21-07-0127-00-0000 Channel binding: To make sure the usage of a shared key limited to only party 1 and party 2 Channel binding Tuple (CBT) (party 1 ID, party 2, other info) Peer-ADC channel: (peer_ID, ADC_ID, other info) If lying ADC: Two CBT copies Downlink: DCBT includes ADC_DID: ADC to MN, reported and signed by MN Uplink: UCBT includes ADC_UID: ADC to AAA, reported and signed by MN DCBT and UCBT must include matching ADC_IDs. Signature keys MN: AAA_RK, both channel binding and re-authentication ADC: ADC-AAA key

28. 21-07-0127-00-0000 Downlink ADC_ID Channel binding (No new messages) extensions and AVPs defined in draft MN/ Peer AAA server MN_MAC(DCBT) ADC XRQ XKRP XRP XKRQ XRQ: HRQ or KRQ XKRQ: HKRQ or KRQ MN_MAC(DCBT), ADC_MAC (UCBT) Verify MACs DCBT=UCBT AAA_MAC(UCBT=DCBT)