IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN:21-09-0164-00-0sec
Title: Detailed analysis on MIA/MSA architecture
Date Submitted:
Authors or Source(s): Rafael Marín-López,
Fernando Bernal
Abstract:
This document discusses specific details on the
MIA/MSA architecture, addressing different key
distribution models (push and pull) and providing
entities’ required functionalities.
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 stated in Section 6 of the
IEEE-SA Standards Board bylaws
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/faq.pdf>
Media Independent Proactive
authentication
ＭＮ
Serving
MSA-KH
Target
MSA-KH
MIA-KH
1*. Media-specific network access authentication
MSK
MSK
.
.
.
Pro-auth
Trigger
2. Proactive media-independent authentication
MSK’/rMSK
MSK’/rMSK
MI-PMK
MI-PMK
1*. Only required if the MN has no already access
to the network through Serving MSA-KH
L-AAA
H-AAA
MN
• Required functionalities
– If MN needs to get network access through the Serving MSA.
• EAP peer for a media-specific authentication.
• Media specific EAP lower layer.
• Secure Association protocol client for the specific media
– If EAP is used for (proactive) media-independent authentication
• EAP peer for media-independent authentication
• Media-independent EAP lower-layer
– If EAP is NOT used for (proactive) media-independent
authentication
• authentication protocol implementation
• media-independent client transport for the authentication protocol.
Serving MSA-KH
• Required functionalities
– EAP authenticator for media-specific
authentication.
– AAA protocol client for a specific media
– Secure Association protocol server for the specific
media
MIA-KH
• Required functionalities
– If EAP is used for (proactive) media-independent
authentication
• EAP server for media-independent authentication
• Media-independent EAP lower-layer
– If EAP is NOT used for (proactive) mediaindependent authentication
• authentication protocol implementation
• media-independent client transport for the
authentication protocol.
– AAA protocol client for a specific media
(H) AAA Server
• Required functionalities
– EAP server for media specific authentication
– EAP server for proactive media-independent
authentication
– AAA protocol for media specific authentication
– AAA protocol for (proactive) media independent
authentication.
Push Key distribution
ＭＮ
Serving
MSA-KH
Target
MSA-KH
MI-PMK
MI-PMK
Key Dist.
Trigger
MS-PMK
3*’. Proactive (Push) Key Dist. signaling
4’. Push key
installation
MS-PMK
Handoff to
target MSA-KH
MIA-KH
.
.
.
5. Security Association
Protocol
3*’. Optional if during Proactive authentication signaling the
MIA pushes MS-PMKs in all target MSAs under MIA-KH control.
MS-PMK
MN
• Required functionalities
– Media independent client protocol for indicating
proactive key distribution.
• This signaling indicates that key distribution is push
model
– Key derivation mechanism to derive MS-PMK.
– Secure Association protocol client for the specific
media
Target MSA-KH
• Required functionalities
– Interface with MIA-KH that allows to receiving a
key in a push fashion.
– Secure Association protocol server for the specific
media
MIA-KH
• Required functionalities
– Media independent server protocol for proactive
key distribution.
– Interface with MSA-KH for sending a key in a push
fashion.
Pull Key Distribution
ＭＮ
Serving
MSA-KH
Target
MSA-KH
MIA-KH
MI-PMK
MI-PMK
*Key Dist.
Trigger
3*’’. Proactive (Pull) Key Dist. signaling [@MIA-MIHF-ID]
Handoff to
target MSA-KH
4’’. Media-specific network access authentication
[MN’s identity = MN-MIHF-ID@MIA-MIHF-ID]
MSK
MSK
5. Security Association
Protocol
3*’’. Optional if during Proactive authentication signaling the
MN has been provided with the MIA-KH’s realm information
or it has been obtained by means of 802.21 IS
MN
• Required functionalities
– Media independent client protocol for indicating
proactive key distribution.
• This signaling indicates that key distribution is pull model
• The MN receives from MIA information about MIA’s realm
that it is useful for AAA routing.
– EAP peer for a media-specific authentication.
– Media specific EAP lower layer.
– Secure Association protocol client for the specific
media
Target MSA-KH
• Required functionalities
– EAP authenticator for a specific media
– AAA client for a specific media
– Secure Association protocol server for the specific
media
MIA-KH
• Required functionalities
– Media independent server protocol for proactive
key distribution.
• This protocol provides MN with MIA’s realm to build an
MN’s identity that it is useful for AAA routing.
– EAP server for media-specific authentication
– AAA protocol server for media-specific
authentication
MIH user processing
EAP/AAA message
vs.
MIHF processing EAP/AAA message
MIH user processing EAP/AAA messages
• EAP layers (EAP method, EAP auth/peer layer,
EAP layer) become MIH user.
• MIHF acts as EAP lower-layer and, as per EAP
specification, it holds the MSK. Thus it can
derive the MI-PMK and MS-PMKs.
• In pull key distribution
– EAP method layer is the MIH user and requests a key (MSPMK) to the MIHF to perform the EAP method.
• In push key distribution
– The protocol used to push a key into the MS-PMK becomes
MIH User and request a MS-PMK to MIHF.
MIH user processing EAP/AAA messages
MIH User
MIH User
EAP method layer
Protocol X for push key
installation
EAP peer layer
EAP layer
MIHF
(e.g. MIH EAP lower-layer)
MSK, MI-PMK, MS-PMKs...
MIH-SAP for EAP authentication
MIH-SAP for pull key distribution
MIH-SAP for push key distribution
MIHF processing EAP/AAA messages
• In the MN:
– Two EAP stacks shall be deployed in the MN. One
for the media specific authentication and other for
the media independent authentication.
• In the MIH authenticator:
– It is used to media-independent authentication
– EAP authenticator stack.
– AAA client implemented within the MIHF may be
required when MIH is acting as EAP authenticator
in pass-through mode.
Discussion
• A priori, “MIH user processing EAP / AAA
messages” model seems a simpler solution
and simplify future deployments.
• But it needs to define the interface between
MIHF and MIH user.
Other pending questions
• Should proactive authentication signaling be
flexible enough to support multiple
authentication protocols not only EAP?
• Is it enough to use EAP as authentication
protocol?