Download presentation
Presentation is loading. Please wait.
Published byRoderick Morrison Modified over 9 years ago
1
1 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-0164-06-0sec Title: Detailed analysis on MIA/MSA architecture Date Submitted: January 5, 2010 Present at IEEE 802.21 meeting in January 2010 San Diego. Authors or Source(s): Fernando Bernal, Rafa Marín- López Abstract: This document discusses specific details on the MIA/MSA architecture, addressing different key distribution models (push and pull) and providing entities’ required functionalities.
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 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 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#6 http://standards.ieee.org/board/pat/faq.pdf
3
3 Differences with previous versions The motivation of MIA is now explicitly explained. We have added and described a new key distribution: proactive pull key distribution. Some deployment analysis has been added.
4
4 Intra-MIH Authenticator Media Specific Authenticator and Key Holder (MSA-KH) Media Specific Authenticator and Key Holder (MSA-KH) POA1 Media Independent Authenticator and Key Holder (MIA-KH) Media Independent Authenticator and Key Holder (MIA-KH) MIHF POA2 Media Specific Authenticator and Key Holder (MSA-KH) Media Specific Authenticator and Key Holder (MSA-KH) POA1 POA2 Media Independent Access Functions (MIH POS+) Media Specific Access Functions MN Serving Access Network Candidate Access Network RP1 Interface _ MIA-KH-MSA-KH RP1 Interface _ MIA-KH-MSA-KH Media Specific Access Functions
5
5 Inter-MIH Authenticator Media Specific Authenticator and Key Holder (MSA-KH) Media Specific Authenticator and Key Holder (MSA-KH) POA1 Media Independent Authenticator and Key Holder (MIA-KH) Media Independent Authenticator and Key Holder (MIA-KH) MIHF POA2 Media Specific Authenticator and Key Holder (MSA-KH) Media Specific Authenticator and Key Holder (MSA-KH) POA1 POA2 Media Independent Access Functions (MIH POS+) Media Specific Access Functions MN Media Independent Authenticator and Key Holder (MIA-KH) (MIA-KH) Media Independent Authenticator and Key Holder (MIA-KH) (MIA-KH) MIHF Serving Access Network Candidate Access Network RP5 RP1 RP2 RP1 Int_ MIA-KH-MSA-KH
6
6 Motivation of MIA architecture Provide support to enable secure media independent handover services These services include the management of different types of key distribution mechanisms: – Push Key Distribution – Reactive Pull Key Distribution – Proactive Pull Key Distribution To securely provide and control the access to these services, an authentication and key establishment are required. Goals – Security – Reduce the handover time – Try to achieve a smooth deployment
7
7 Notation Primitives for EAP authentication Primitives for (reactive or proactive) pull key distribution Primitives for push key distribution Out of scope of 802.21a MIH-SAP Unprotected MIH signalling between MIHF Protected MIH signalling between MIHF
8
8 General Call Flow Candidate MIA Serving MIA MN Step 1: Negotiation phase between MN and Candidate MIA Step 2 & 2’: Media Independent Authentication between MN and Candidate MIA and Key Installation for PULL Key Distr. Step 3: PUSH Key distribution or (Reactive or Proactive) PULL Key distr. execution. Target MSA-KH Step 4: Session Finalization...
9
9 General MI Authentication Phases MIHF MN MIHF MIA Negotiation phase Authentication phase (Step 2 and 2’) Authenticated & Authorized phase (Step 3) Finalization phase (Step 4) (Step 1)
10
10 General Message Exchange Negotiation phase – In this phase both the MN and MIA exchange messages in order to agree on the type of key distribution service (push, reactive pull, proactive pull) and other parameters. Authentication phase – The MN authenticates against the MIA in order to achieve access to the security services. – After this authentication key material is shared between them and the rest of the MIH communication can be protected. – At the end, the negotiated parameters in the previous phase are confirmed. – An authentication session is established Authenticated & Authorized phase – At this point, MIH signalling is protected and MN is authenticated and authorized to use the services provided by the MIA. – Regarding key distribution: If Push Key Distribution was negotiated, some protected MIH signalling is required in order the MN to inform the MIA to install a key in a target MSA. If Reactive Pull Key Distribution is agreed, no need of MIH signalling is required but some state is needed in the MIA that will act as AAA server. If Proactive Pull Key Distribution is agreed, authentication L2 frames are tunnelled to the MIA from the MN; and from the MIA to the target MSA in order to perform a proactive media-specific authentication with the target MSA. That is, the MIA provides a proxy service. Finalization phase – MN and MIA finish the session.
11
11 Serving MSA-KH Target MSA-KH * Auth. Trigger 0*. Media-specific network access authentication 1. Negotiation MSK Media Independent Authentication (I) 0*. Only required if the MN has no already access to the network through Serving MSA-KH MIH User MIHF MN MAC MIH User MIHF MIA H-AAAL-AAA AAA I1 Key Distribution Method agreed 2. Media-independent authentication... I1 I2I3I4 I2 Key Distribution Method confirmed
12
12 Serving MSA-KH Target MSA-KH MSK’/rMSK MI-PMK Media Independent Authentication (II) MIH User MIHF MN MAC MIH User MIHF MIA MS-PMK H-AAAL-AAA AAA MSK’/rMSK MI-PMK MS-PMK I5 I6 2’. Key installation for (reactive or proactive) PULL just after media-independent authentication I2...
13
13 Media Independent Authentication 802.21a scope – Interface I1 This interface transports EAP or an authentication protocol over MIH signaling. In the case of transporting EAP, the MIHF implements an EAP lower-layer functionality. – Interface I2 For Media Independent Authentication it is an internal interface used by the MIA to exchange EAP packets (or any other authentication protocol packets) between the MIHF and the MIH-USER (which is the EAP stack when EAP is used or the authentication protocol implementation). For key distribution, I2 is used to install the derived MS-PMKs and required parameters to the corresponding MIH-USER (e.g. key manager). – This interface is used just after Media Independent Authentication for Reactive or Proactive PULL Key Distribution.
14
14 Media Independent Authentication Outside 802.21a scope – Interface I3 Internal interface to communicate MIH user with AAA client in the MIA-KH order to forward authentication to H-AAA. – Interface I4 Interface to transport EAP or authentication protocol to the H-AAA in order to perform the authentication (e.g. AAA protocol). – Interface I5 This interface is used by the Reactive or Proactive PULL Key Distribution in order to provide the MS-PMK(s) to the AAA server in the MIA. So that, when the MN moves to the target MSA-KH, all key material is available and a fast media-specific re- authentication can be performed. – Interfaces (I6) This interface allows to installa the MS-PMK in the MAC layer (MN side).
15
15 Summary Media Independent Authentication EAP layer EAP peer layer EAP Peer / MN EAP method layer MIH EAP lower- layer (MIHF) EAP Authenticator / MIA-KH AAA/IP EAP (serv.) layer EAP/AAA Server EAP method layer MIH EAP lower-layer (MIHF) EAP layer Primitives for EAP authentication Primitives for pull key distribution MIH USER MIHF MIH USER (e.g.) Key Manager EAP layer EAP auth. layer EAP method layer MIH USER (e.g.) Key Manager I1 I2 I3 I5 I4 Out of scope of 802.21a I2 MIH signalling between MIHF MIH-SAP
16
16 Key Dist. Trigger 3. Proactive (Push) Key Dist. signaling Handoff to target MSA-KH MS-PMK MI-PMK MS-PMK Push Key distribution Serving MSA-KH Target MSA-KH MIH User MIHF MN MAC MIHF MIA MIH User MS-PMK Security Association Protocol I2 I7 I2 I6 I1
17
17 Push Key distribution Interface (I1) – This interface is used to request the MIA-KH the installation of a key (MS-PMK) in the target MSA-KH using MIH signaling. Interfaces (I2, I7) – After MN requests a PUSH Key Distribution with I1, the MIHF in the MIA provides the MS-PMK and other useful information (e.g. key lifetime) to the MIH User (by using I2), which knows how to install the MS-PMK in the target MSA-KH (I7). Interfaces (I2, I6) – After requesting a PUSH Key Distribution through I1, the MIHF in the MN provides the MS-PMK and other useful information (e.g. MS-PMK lifetime) to the MIH User (acting as key manager) (I2) which is in charge of export the MS-PMK to the MAC layer (I6).
18
18 MAC Summary Push Key Distribution MN MIHF MIA-KH MIHF Primitives for push key distribution MIH User (e.g. Protocol X for push key installation) MIH User (e.g. Key Manager/Store) Target MSA-KH MIH USER I1 I2 I6 I7 Protected MIH signaling between MIHF Out of scope of 802.21a MIH-SAP
19
19 Reactive Pull Key Distribution Handoff to target MSA-KH Serving MSA-KH Target MSA-KH MIH User MIHF MN MAC MIHF MIA MIH User MS-PMK Security Association Protocol MSK 3. Media-specific network access re-authentication [MN’s identity = *MN-MIHF-ID@MIA-MIHF-ID] *NOTE = Regarding identity’s format, it must still be defined. MS-PMK MSK AAA
20
20 Reactive Pull Key Distribution Assuming that the MS-PMK used by the EAP (fast) re-authentication mechanism for pull key distribution has been already sent to the MIH user during the authentication phase (see slide 10): -No MIHF intervention is required (see slide 17)
21
21 Proactive Pull Key Distribution (over MIH Signalling) Serving MSA-KH Target MSA-KH MIH User MIHF MN MAC MIA AAA 3. Authentication L2 frames over MIH Tunnel [ MN’s identity for media-specific auth. = *MN-MIHF-ID@MIA-MIHF-ID or user@homedomain ] I1 I9 I2 H-AAAL-AAA I10 Security Association Protocol I2 MIH User MIHF MS-PMK MN’s identity = MN-MIHF-ID@MIA- MIHF-ID I11 MN’s identity = user@homedomain I11
22
22 Serving MSA-KH Target MSA-KH MIH User MIHF MN MAC MIHF MIA MIH User AAA 3. Authentication L2 frames over dynamically established tunnel [ MN’s identity for media-specific auth. = *MN-MIHF-ID@MIA-MIHF-ID or user@homedomain ] I9 MN’s identity = MN-MIHF-ID@MIA- MIHF-ID I11 H-AAAL-AAA I12 MN’s identity = user@homedomain Security Association Protocol TN-PMK MI-PMK I11 Proactive Pull Key Distribution (over DYNAMIC TUNNEL) Dynamically established secure tunnel using TN-PMK I10 TN-PMK MI-PMK TN-PMK I2 MS-PMK 3. Authentication L2 frames over Secure Tunnel
23
23 Proactive Pull Key distribution Interface I1 – This interface is used to transport the media-specific authentication L2 frames from the MN to the MIA. – These messages are protected by the key material provided after the media independent authentication. Interface I2 – Over MIH Signalling. It is used to tranfer L2 frames from MIHF to MIH user and viceversa. – Over Dynamic secure tunnel. It is used to set a TN-PMK that allows to establish a secure tunnel (e.g. IKEv2-PSK). Interface l9 – Interface used between the target MSA-KH and MIA. This interface transports authentication L2 frames to the target MSA-KH from the MIA. Interface l10 – Interface for transporting the media-specific auth. L2 frames to the MAC layer in the MN. Interface l11 – Interface used by the target MSA-KH to communicate with the AAA server. The AAA server may be the MIA or the home AAA. Interface I12 – A dynamically established secure tunnel to transport auth. L2 frames
24
24 MAC Summary Proactive PULL Key Distribution (over MIH Signalling) MN MIHF MIA MIHF MIH User MIH User (e.g. Key Manager/Store) Target MSA-KH Auth. L2 frames over MIH (I1) I2 I10 I9 MIHF Primitives for pull key distribution MIH USER Protected MIH signaling between MIHFs Out of scope of 802.21a MIH-SAP AAA/IP I11 AAA/IP EAP (serv.) layer AAA Server EAP method layer EAP layer I11
25
25 MAC Summary Proactive PULL Key Distribution (over DYNAMIC TUNNEL) MN MIHF MIA MIHF MIH User MIH User (e.g. Key Manager/Store) Target MSA-KH I2 I10 I9 MIHF Primitives for pull key distribution MIH USER Protected MIH signaling between MIHF MIH or dynamically Tunnel Out of scope of 802.21a MIH-SAP AAA/IP I11 L2 frames over Dynamically established secure tunnel using TN-PMK AAA/IP EAP (serv.) layer EAP/AAA Server EAP method layer EAP layer I11
26
26 Serving MSA-KH Target MSA-KH 4. Session Finalization... Session Finalization MIH User MIHF MN MAC MIH User MIHF MIA AAA I1 I2 I5 I2 I7 I2 I6 I2 I6 4b. For Push Key Dist. Remove Keys 4a. For (Reactive or Proactive) Pull Key Dist. Remove dynamically established tunnel I12 Remove Keys 4a’. Only for Proactive Pull Key Dist. over Dynamic tunnel
27
27 Interfaces summary Media Independent Proactive authentication Reactive PULL Key Distribution Proactive PULL Key Distribution PUSH Key Distribution MN I1 I2I2 I6I1 I10 I2 I12I1 I6 I2 Serving MSA-KH Target MSA-KH I9 I11I7 MIA I2 I3 I4I2 I5I1 I11 I2 I12I1 I7 I2 AAA I4I11 Outside 802.21a scope
28
28 DEPLOYMENT ANALYSIS
29
29 PUSH Key Distribution The target MSA-KH needs to provide an interface to allow the MIA to push (or remove) a key.
30
30 Reactive PULL Key Distribution A new MN re-authentication identity must be provided to the MN during the authentication. Once the target MSA-KH receives the MN re-authentication identity, two options are possible: 1.The MSA-KH routes the AAA messages using the realm part of the new MN re-authentication identity to the appropiate MIA MSA- KH AAA routing table has to be updated to point out to the MIA. 2.The target MSA-KH, usings its default AAA route, sends the AAA messages to its default local AAA server, which must be configured to act as AAA proxy for the identity’s realm provided and to forward the AAA messages to the corresponding MIA. Local AAA proxy has to add a new entry in AAA routing table to point out the MIA. Summary: – In either options, no changes to the media-specific wireless technology are required. – Moreover, option 2 does not need any change in the configuration parameters in the deployed MSA-KHs.
31
31 Proactive PULL Key Distribution Similar analysis as Reactive PULL Key Distribution is applicable to Proactive PULL Key Distribution but...... since the MIA provides a proxy service for authentication L2 frames. – The MSA-KHs must be modified in order to accept L2 authentication wireless frames through the wired interface. – A protocol to transport these frames from the MIA to the target MSA- KH is required. (out of the scope of 802.21a) Depending on the MN’s identity: – If the MN uses its original home domain identity (e.g. user@homedomain), the target MSA contacts the home AAA and MIA does not need to act as AAA server. – if the MN uses a new MN re-authentication identity (e.g. MN-MIHF- ID@MIA-MIHF-ID), the MIA has to act as AAA server.
32
32 Some conclusions 802.21a defines EAP (or any other authentication protocol) transport for proactive authentication, key hierarchy and an MIH-SAP primitives with the MIH-USER to support three key distribution models. How the parameters passed by means of the MIH-SAP primitives are used by the media-specific lower layers is out of the scope. 802.21a specification may contain call flows for guidelines to show how these parameters can be used by the media- specific lower-layers. The call flows if contained are only informational. Depending on how these parameters are used, it may or may not require changes to the lower-layer standards and/or implementations. – Reactive PULL Key Distribution do not require these modifications and PUSH Key Distribution and proactive PULL Key Distribution may require these ones (e.g. at firmware level)
33
33 REQUIRED FUNCTIONALITIES FOR EACH ENTITY
34
34 For media-specific network access authentication If MN needs to get network access through the Serving MSA (step 0, slide 9). – EAP peer for a media-specific authentication. – Media specific EAP lower layer. – Secure Association protocol client for the specific media
35
35 For the Media Independent Authentication MN – If EAP is used for media-independent authentication EAP peer for media-independent authentication Media-independent EAP lower-layer (MIHF) – If EAP is NOT used for (proactive) media-independent authentication authentication protocol implementation media-independent client transport for the authentication protocol. Serving MSA-KH – EAP authenticator for media-specific authentication. – AAA protocol client for a specific media – Secure Association protocol server for the specific media MIA – If EAP is used for media-independent authentication EAP authenticator 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. – AAA protocol client for media independent authentication (H) AAA Server – 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
36
36 For PUSH Key distribution MN – 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 – Interface with MIA-KH that allows to receiving a key in a push fashion. – Secure Association protocol server for the specific media MIA – Media independent server protocol for proactive key distribution. – Interface with MSA-KH for sending a key in a push fashion.
37
37 For Reactive PULL Key Distribution MN – 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 – EAP authenticator for a specific media – AAA client for a specific media – Secure Association protocol server for the specific media MIA – EAP server for media-specific authentication – AAA protocol server for media-specific authentication
38
38 For Proactive PULL Key Distribution MN – Interface to obtain/set L2 Frames from/to the MAC layer. – Media independent protocol for transporting L2 frames between the MN and the MIA (Over MIH signalling option). – Secure tunnel protocol for transporting L2 frames between the MN and the MIA (Over dynamic secure tunnel option). – Key derivation mechanism to derive MS-PMK and TN-PMK – EAP peer for a media-specific authentication. – Media specific EAP lower layer. – Secure Association protocol client for the specific media. Target MSA-KH – EAP authenticator for a specific media – AAA client for media-specific (proactive) authentication. – Protocol to receive/send wireless (auth.) L2 frames from/to MIA over the wired interface. – Secure Association protocol server for the specific media MIA – AAA protocol for media-specific (proactive) authentication [NOTE: When MN uses a MN re- authentication identity]. – Protocol to receive/send wireless (auth.) L2 frames from/to the target MSA over the wired interface. – Media independent protocol for transporting L2 frames between the MN and the MIA (Over MIH signalling option). – Secure tunnel protocol for transporting L2 frames between the MN and the MIA (Over dynamic secure tunnel option). Home AAA – AAA protocol for media-specific (proactive) authentication. [NOTE: When MN uses its home domain identity]
39
39 Future work More detailed definition of the interfaces in 802.21a scope.
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.