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 a 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.
xx-00-sec 1

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
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
xx-00-sec 2

3. Background
The a 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. 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
Fast transition defined in r
TEK 3-way handshake defined in

5. Proposed MIA Key Hierarchy
MSK or rMSK
Document #102 proposed the new key hierarchy.
Document #164 discussed options to distribute MS-PMKs to different MSAs.
The purpose is to prepare for
way handshake;
way handshake,
without going back to the authentication server for full authentication in case of handover.
MI-PMK
MS1-PMK
MS2-PMK
MSA1
MSA2

6. Authentication options in 802.11
Full (and fast) Authentication is executed in higher layer and out of the scope of
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 ; or
Fast transition defined in r
In case of handover, it executes either
Full (or fast) authentication and 4-way handshake; or
Fast BSS transition protocol defined in r

7. 802.11r Key Hierarchy
After a full (proactive) EAP authentication, MIA may deliver MSK (or rMSK) to PMK-R0 key holder, which is the MSA.
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 authentication client in MN, since MN needs to derive a different key hierarchy.
PMK-R0 KH

8. 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 layer 2.
In case of EAP-based authentication after RSA authorization, the EAP messages are authenticated using EIK (derived from Pre-PAK)
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.

9. 802.16 Key Hierarchy MSK PMK EIK AK MAC-Keys KEK
Authenticator
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 (or WiMAX) backbone; and
It will demand to modify authentication client in MN to derive a different key hierarchy.
MSK
PMK
EIK AK
MAC-Keys
KEK BS
*KEK is used to deliver TEKs in the 3-way TEK handshake.

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

11. 3GPP (AKA) Key HierarchyCK IK
USIM K f1
RAND
SQN
AMF
MAC f2 f3 f4 f5
XRES CK IK AK
Generate
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.
The question is how a MIA can help.

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 requires and can recognize.
*We will discuss the possibility for each media late.

13. When a MIA cannot be Used and Why?
In the following case, MIA cannot be used.
A r fast BSS transition; or
A 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 cases, 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. 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
EAP or PSK;
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)!
Authentication Client
Authentication Client
3GPP USIM
Media Independent Authentication Client? MN

15. Authentication Credentials for Different Media
EAP, e.g.
EAP- (T)TLS: server certificate, client certificate (optional) or/and password.
EAP-GPSK: pre-shared symmetric key
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. 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 AP is not trusted in the same way as an BS.
21a is not in a position to combine the different trust models in one “media independent authentication and key hierarchy”!

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

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. That is, a media independent authenticator can only accommodate media specific authentication. (EAP is media independent. But the way to use EAP is media specific!)
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. Open Issues in Using MIA for Proactive Authentication
In , 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 , in case of PKMv1, the authentication is between a MS and a BS, how to use a MIA?
In , 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 to involve the target BS 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 PMKv2?
How to use a MIA in 3GPP case?