1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-0126-02-0sec
Title: Proactive Authentication and MIH Securit
Date Submitted: September 1, 2009
Authors or Source(s):
Rafa Marin-Lopez (University of Murcia)
Subir Das (Telcordia)
Abstract:
This document discusses the “Interface _MIA-KH-MSA-KH”

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 outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development
IEEE 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
sec

3. Architecture- Example A
Media Specific Authenticator and Key Holder
(MSA-KH)
POA1
Media Independent Authenticator and Key Holder
(MIA-KH)
MIHF
POA2
Media Specific Authenticator and
Key Holder
Media Independent
Access Functions
(MIH POS+)
Media Specific MN
Serving Access
Network
Candidate Access
RP1
Interface _MIA-KH-MSA-KH
sec

4. Architecture- Example B
Media Specific Authenticator and Key Holder
(MSA-KH)
POA1
Media Independent Authenticator and Key Holder
(MIA-KH)
MIHF
POA2
Media Independent
Access Functions
(MIH POS+)
Media Specific MN
Serving Access
Network
Candidate Access
RP5
RP1
RP2
Int_MIA-KH-MSA-KH
sec

5. Interface _MIA-KH-MSA-KH
Do we need to define this interface within a?
Pros: If we define, the proposed architecture can be used with the media specific technology and we provide a complete solution
Cons: If we do not define, this will be implementation specific
The bottom line is someone needs to implement in order for the architecture to work
Our decision of defining this interface may depend upon how difficult it would be for us to define?
sec

6. Alternative-I
We work with respective IEEE WGs such as, and to introduce the pre-authentication architecture
Understand what needs to be done to push or pull the media dependent PMK from media dependent authenticator
If they accept our proposal it is doable
Difficult task?
sec

7. Alternative-II
We define the interface within a in such a way that there is no impact (or very very little) in media specific authenticator
Media specific authenticator accepts the keys the way it accepts the key from AAA server
Define AAA protocol attribute(s)
For example, use vendor specific (IEEE in this case) RADIUS attribute(s) or work with IETF RAD-EXT WG to define new attributes
sec

8. Alternative-III Do nothing Left unspecified
For example, r does not define the interface between R0 and R1 key holders
sec

9. (AAA/EAP server for MS auth.)
Pull Key Distribution
Candidate MIA
(EAP auth. for MIH auth.)
(AAA/EAP server for MS auth.)
Peer (MN)
(EAP peer)
Target MSA
MSK
Peer and Candidate MIA share a MSK derived from a previous MIH Pre-Auth/Proactive Re-auth execution
MSK
...
Handoff
EAP Fast Re-authentication mechanism (EAP-FRM/ERP...)
AAA-Req (FRP/EAP)
AAA-Resp (rMSK)
rMSK
rMSK
Security Association Protocol
sec

10. Possible New MIH Authenticator Model (1)
MIHF
EAP authenticator
Media Independent Authenticator and Key Holder
(MIA-KH)
Media Specific Authenticator and
Key Holder
(MSA-KH)
Media Specific Authenticator and Key Holder
(MSA-KH)
RP1
RP1
POA1
POA2
POA1
POA2
Serving MIH Authenticator Port
Candidate MIH Authenticator Port MN MN
sec

11. Possible New MIH Authenticator Model (2)
The MIH Authenticator controls several ports
These ports are media-specific ports.
Thus: Do nothing about the protocols or interfaces within the MIH authenticator to perform push key distribution. (Alternative III).
First alternative: to define a set of security requirements for the interface between MIA and MSA for push key distribution without defining the interface itself.
These requirements can help to vendors and other WGs to define that interface specifically for a technology as long as they accomplish the security requirements.
Second alternative: exploring the "push model" work and see what it is needed in both e and
sec