1. 1 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-00xx-00-sec Title: The Role of a Media Independent Authenticator Date Submitted: December 30, 2009 Present at IEEE 802.21a Teleconference, January 5, 2010 Authors: Lily Chen (NIST) Abstract: This document looks into media specific handover cases to understand the role of a media independent authenticator. The presentation also identifies some open issues for further study. 121-09-00xx-00-sec

2. 2 2 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf

3. 3 Background The 802.21a document #102 introduced a network entity called media independent authenticator (MIA) to accommodate media independent (proactive) authentication protocol. The document #102 considers a MIA as a key holder (MIA-KH) and further introduced a new key hierarchy to prepare the media specific authenticator (MSA) with a media specific PMK (MS_PMK) for a fast handover. Document #164 discussed key distribution options from a MIA to MSAs. This presentation will look into different handover cases to understand the role of a MIA.

4. 4 Authentication Terminologies Full Authentication - usually with a server and can be executed in a proactive way such as EAP with the home authentication server 3GPP AKA with an Authentication Center in HLR (HS) Fast Authentication - can be executed with a local server in a proactive way such as EAP Re-authentication Protocol (ERP) Session Key Establishment - usually established with a PoA to protect wireless data traffic such as 4-way handshake in 802.11 Fast transition defined in 802.11r TEK 3-way handshake defined in 802.16

5. 5 Authentication options in 802.11 Full (and fast) Authentication is executed in higher layer and out of the scope of 802.11 It assumes that a full (or fast) authentication will provide a MSK (or rMSK) to the authenticator and then further derive a PMK for an AP which STA will be associated with Session Key Establishment is either 4-way handshake in 802.11; or Fast transition defined in 802.11r In case of handover, it executes either Full (or fast) authentication and 4-way handshake; or Fast BSS transition protocol defined in 802.11r

6. 6 Authentication Options in 802.16 Full (and fast) Authentication (PKMv1 or PKMv2) is executed in a MAC sub-layer. In case of EAP-based authentication, it is encapsulated. In case of EAP-based authentication after RSA authorization, the EAP messages are authenticated using EIK (derived from AK) Session Key Establishment is A 3-way TEK (GTEK, GKEK) handshake (and 2-way TEK delivery); In case of handover, it has three options (00) Full (or fast) authentication and TEK 3-way handshake; (10) Re-use PMK for a TEK 3-way handshake. No full authentication. (11) Re-use PMK and TEK. No full authentication and no TEK 3-way handshake.

7. 7 Authentication options in 3GPP Full (and fast) Authentication is AKA, which will generate session key IK and CK. In case of handover, it executes Full authentication to obtain CK and IK; or Nothing. Re-use IK and CK.

8. 8 Proposed MIA Key Hierarchy Document #102 proposed the new key hierarchy. Document #164 discussed options to distribute MS-PMKs to different MSAs. The purpose is to prepare for 802.11 4-way handshake; 802.16 3-way handshake, without going back to the authentication server for full authentication in case of handover. MSK or rMSK MI-PMK MS 1 -PMKMS 2 -PMK MSA 1 MSA 2

9. 9 802.11r Key Hierarchy After a full (proactive) EAP authentication, MIA may deliver MSK (or rMSK) to PMK-R0 key holder. Why not deliver different MS-PMKs to different PMK-R1 key holders? It will require a modification of R0 KH and R1 KHs interface; and It will require a modification to 802.11 authentication client in MN, since MN needs to derive a different key hierarchy. PMK-R0 KH

10. 10 802.16 Key Hierarchy After a full (proactive) EAP authentication, MIA may deliver MSK (or rMSK) to the BS. Why not generate different MS-PMKs for different BSs? With options 10 and 11, serving BS is configured to deliver the same PMK or PMK and TEKs to the target BS through 802.16 (or WiMAX) backbone; and It will demand to modify 802.16 authentication client in MN to derive a different key hierarchy. MSK PMKEIK AK MAC-KeysKEK Generated in the BS and MS *KEK is used to deliver TEKs in the 3-way TEK handshake.

11. 11 3GPP (AKA) Key Hierarchy Full authentication is executed with AuC in HLR(HS). In MS, CK and IK are derived in USIM. CK and IK are re-used in 3GPP to 3GPP handover. It is a question that how a MIA can help. K f1f1 RAND SQNAMF MAC f2f2 f3f3 f4f4 f5f5 XRESCKIKAK Generate K CKIK USIM

12. 12 When a MIA may be Needed & for What? If for the next handover, a full (or fast) authentication is needed, then a MIA may accommodate a proactive authentication, when it is possible*. The role includes Forward the authentication protocol to the corresponding authentication server; and Deliver the keys (e.g. MSK) to the target MSA. But The authentication protocol must be the one specified for the media specific access authentication. The keys must match whatever the MSA require and can recognize. *We will discuss the possibility for each media late.

13. 13 When a MIA cannot be Used and Why? In the following case, MIA cannot be used. A 802.11r fast BSS transition; or A 802.16 handover with option 10 (Re-use PMK ) or 11 (Re- use PMK and TEKs); 3GPP handover. Why If a MIA is involved in the above case, it will require to modify the existing MSA (or PoA). Otherwise, The existing MSAs would not be able to use the keys delivered by the MIA.

14. 14 Inside a Mobile Node In order to access different media networks, a mobile node must be able to conduct authentication with different media specific access networks. Specifically, it must support 802.11 EAP or PSK; 802.16 PKMv1 or/and PKMv2; 3GPP AKA; and more They may use different credentials and authenticate different identities. They may even be executed with different servers (entities)! 802.11 Authentication Client 802.16 Authentication Client 3GPP USIM Media Independent Authentication Client? MN

15. 15 Authentication Credentials for Different Media 802.11 EAP, e.g. EAP- (T)TLS: server certificate, client certificate (optional) or/and password. EAP-GPSK: pre-shared symmetric key 802.16 PKMv1 or PKMv2 Manufacture issued device (MS) X.509 certificate for RSA public key; BS certificate for signature (PKMv2); plus EAP credentials (PKMv2- EAP after RSA device mutual authorization.) 3GPP AKA USIM with symmetric key K. What will be the authentication credentials and identities for media independent authentication?

16. 16 Issues with Media Independent Authentication If a media independent authentication is introduced, What will be the authentication credentials and identities for media independent authentication? Is media independent authentication client a standalone client? In order to access a media specific network, the MN will execute either a media specific or media independent authentication, Who is entitled to make such modification to media specific PoAs? 21a can not make these decisions! Different media assume different trust models. For example, an 802.11 AP is not trusted in the same way as an 802.16 BS. 21a is not in a position to combine the different trust models in one media independent authentication and key hierarchy!

17. 17 A Possible Picture for 802.11 802.11 Auth Client 802.16 Auth Client 3GPP USIM MIHF MN PoS- MIA 802.11 Auth Server 802.16 Auth Server 3GPP AuC/HLR AAA MSK PMK-R0 KH PMK-R1 KH A PMK-R1 KH B PMK-R1 A PMK-R1 B When the target network is a 802.11 and a full or fast authentication is needed, a MIA may accommodate a proactive full or fast authentication required for 802.11 access. MSK is delivered to a PKM-R0 KH, which is considered as a MSA (a PMK-R1 KH is a PoA). Existing 802.11r

18. 18 Summary and Conclusion It is indicated that a PoS may be used as a MIA to accommodate a proactive (full or fast) authentication, even though some open issues are pending for further study (see next page). The proactive authentication must be the one specified for the target media specific network access authentication. A general media independent authentication and key hierarchy will require modifying the existing MSAs, PoAs, media specific handover options, and media specific trust model. 21a should not introduce a media independent authentication and media independent key hierarchy to override the existing media specific authentication.

19. 19 Open Issues In 802.11, PMK-R0 key holder is an authenticator (in the sense of 802.1X). It accepts a MSK after a full (or fast) authentication. Does it need any change to accept a MSK from a MIA without being involved in the full (or fast) authentication? In 802.16, in case of PKMv1, the authentication is between a MS and a BS, how to use a MIA? In 802.16, in case of PKMv2, BS and MS actually first discovery each other, link up, and even conduct a RSA authorization before EAP starts between MS and AAA server. If a MIA is employed, how can the BS be involved in a proactive authentication? Without the BS involved, EAP cannot be encapsulated in a MAC sub- layer. Does this imply a change to BS or 802.16 PMKv2? How to use a MIA in 3GPP case?