IEEE 802 21 MEDIA INDEPENDENT HANDOVER DCN 21

IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -09 -0164 -01 -0 sec Title: Detailed analysis on MIA/MSA architecture Date Submitted: 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.

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/sect 6 -7. html#6> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/faq. pdf>

Media Independent Proactive Authentication MN MIH User MIHF MAC Serving MSA-KH Target MSA-KH MIHF MIH User L-AAA H-AAA 1*. Media-specific network access authentication MSK . . . 1*. Only required if the MN has no already access to the network through Serving MSA-KH Pro-auth Trigger 2. Proactive media-independent authentication MSK’/r. MSK MI-PMK MS-PMK(s) *Key exported MS-PMK ** *Key exported MS-PMK MSK’/r. MSK *** MS-PMK * Mandatory when PULL Key distribution is used. It may be performed later when PUSH key distribution is used. ** Required when PULL Key distribution is used. *** Required when PULL key distribution is used. It may be performed later when PUSH key distribution is used.

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 authenticator 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 media independent authentication

(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 MN MIH User MIHF MAC Serving MSA-KH Target MSA-KH MIH User MIHF Key Dist. Trigger MI-PMK 3*’. Proactive (Push) Key Dist. signaling MI-PMK MS-PMK 4’. Push key installation MS-PMK 5. key exported Handoff to target MSA-KH MS-PMK 6. Security Association Protocol 3*’. Optional if during Proactive authentication signaling the MIA pushes MS-PMKs in all target MSAs under MIA-KH control.

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 MN MIH User MIHF MAC Serving MSA-KH Target MSA-KH MIH User MIHF AAA MS-PMK Handoff to target MSA-KH 4’’. Media-specific network access authentication [MN’s identity = *MN-MIHF-ID@MIA-MIHF-ID] MSK 5. Security Association Protocol *NOTE = Regarding identity’s format, it still must be defined.

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 proactive authentication phase (see slide 3): - No MIHF intervention is required (see slide 12)

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.

Media Independent Proactive Authentication EAP Peer / MN MIH USER (e. g. ) Key Manager MIH USER EAP method layer EAP peer layer EAP Authenticator / MIA-KH MIH USER (e. g. ) Key Manager MIH USER EAP method layer EAP peer layer EAP (serv. ) layer EAP layer MIH EAP lower-layer (MIHF) EAP/AAA Server MIH EAP lowerlayer (MIHF) EAP layer AAA/IP MIH-SAP for EAP authentication MIH USER MIH-SAP for pull key distribution MIHF MIH-SAP for push key distribution (Optional) AAA/IP

Push Key Distribution EAP Peer / MN MIH User (e. g. Key Manager/Store) EAP Authenticator / MIA-KH Target MSA-KH MIH User (e. g. Protocol X for push key installation) MAC MIH EAP lowerlayer MIH EAP lower-layer MIH USER MIH-SAP for push key distribution MIHF

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?

BACKUP SLIDES

MIH user processing EAP/AAA messages 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

PULL KEY DISTRIBUTION • Three options could be performed from the MN point of view – [option one] All necesary information is achieved in the Media Independent authentication (Identity and the key (Key exported)) – [option two] Request identity to MIA-KH and request the key to the MIHF. – [option three] Identity is provided in the Media Independent Authentication and the key is requested to the MIHF.