Optimizing MIH SA Establishment for Single Radio Handover

 
21-07-xxxx-00-0000
 
1
IEEE 802.21
DCN: 21-16-
00xx
-00-0000
Title: 
Some key points for Remedy 1 proposed in 21-15-00-0036-00-SAUC for
Comments #106, #107, #108 and #109
Date Submitted: Feb.19, 2016
Presented at teleconference Feb. 22, 2016
Authors or Source(s):
 
Lily Chen
 (NIST)
Abstract: This presentation explains some key points in adoption remedy 1
proposed in 21-15-00-0036-00-SAUC for Comments #106, #107, #108 and
#109
 
Some key points for Remedy 1 proposed in 21-15-
00-0036-00-SAUC for Comments #106, #107, #108
and #109
 
Lily Chen (NIST)
Feb. 19, 2016
 
Optimize MIH SA establishment for Single Radio
Handover
 
Whenever, it is possible, MN shall establish SA with TPoS with the methods
provided in 21m (developed as in task group 21a)
The reason for the fact that the mechanisms provided in 21m cannot be used is not well
understood
The issue is that MN cannot directly talk to TPoS, however
In 21m, EAP is executed between an MN and PoS
EAP is executed on the top of MIH (see Figure 40 of 21m)
The optimized MIH SA establishment for Single Radio Handover is provided as an
option
SPoS generates a key K and distributes it to TPoS and MN
MN and TPoS shall use the key K as it is generated through EAP as in 21m to derive other keys
(see Figure 46 of 21m)
The cipher suites are defined in 21m for TPoS and MN to negotiate (tables 24 and 25 in 21m)
The optimized method must be restricted to reduce the security damage through
domino effect
If home domains of SPoS and TPoS have a kind of agreement, then there shall be a way to
provide key K from a higher level entity
In fact, it may be more reasonable to allow SPoS to derive a key K from whatever established
before with MN, in stead of generating K from no where.
In any case, it is a default to fall back to EAP between MN and TPoS
 
The interfaces
 
What are not needed in the current 21.1
 
The interface between MN and SPoS is
protected through a cipher-suite defined in 21m
PRF
sPoS
 is not needed
K
sPoS
 is not needed
The interface between SPoS and TPoS is
protected through an out-of-the-scope
mechanism (see the first paragraph of 5.14)
PRF
stpos
 is not needed
K
stpos
 is not needed
 
The PoS is a convenient and natural place to locate
security services, and roaming partners have in
place agreements that can be used to beneficially
establish the needed security agreements between
different PoS modules in partner networks. 
It is
expected that the PoS functions in partner
networks must often communicate by data paths
that traverse the external Internet; in such cases, a
secure communication channel must exist or must
be established between the partners
. 
It is out of
scope for this document to specify exactly how the
secure communication channel should be
established, but this can be done by configuration
when the partners enter into their roaming
agreement. It can also be done on demand by
using IKEv2 (RFC 7296) [B36]. 
The following
overview describes in more detail the
circumstances enabling dynamic establishment of
security association between the SPoS and the
TPoS.
 
What are still needed in the current 21.1
 
Nonce-T and Nonce-N are still
needed for key derivation from
K to the keys needed to
establish protections between
MN and TPoS
The ciphersuite coded as c is
still needed
(see 9.2.2. in 21m)
 
Nonce -N
 
Nonce -T
Slide Note
Embed
Share

This presentation discusses the optimization of MIH (Media Independent Handover) Security Association (SA) establishment for single radio handover. It covers the key points and methods proposed for enhancing the communication between Mobile Node (MN) and Top Point of Service (TPoS) using cipher suites and key generation procedures developed in task group 21m. The aim is to improve security measures and communication efficiency during handover processes within wireless networks.

  • Optimization
  • MIH
  • SA Establishment
  • Single Radio Handover
  • Security

Uploaded on Aug 23, 2024 | 3 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. IEEE 802.21 DCN: 21-16-00xx-00-0000 Title: Some key points for Remedy 1 proposed in 21-15-00-0036-00-SAUC for Comments #106, #107, #108 and #109 Date Submitted: Feb.19, 2016 Presented at teleconference Feb. 22, 2016 Authors or Source(s): Lily Chen (NIST) Abstract: This presentation explains some key points in adoption remedy 1 proposed in 21-15-00-0036-00-SAUC for Comments #106, #107, #108 and #109 21-07-xxxx-00-0000 1

  2. Some key points for Remedy 1 proposed in 21-15- 00-0036-00-SAUC for Comments #106, #107, #108 and #109 Lily Chen (NIST) Feb. 19, 2016

  3. Optimize MIH SA establishment for Single Radio Handover Whenever, it is possible, MN shall establish SA with TPoS with the methods provided in 21m (developed as in task group 21a) The reason for the fact that the mechanisms provided in 21m cannot be used is not well understood The issue is that MN cannot directly talk to TPoS, however In 21m, EAP is executed between an MN and PoS EAP is executed on the top of MIH (see Figure 40 of 21m) The optimized MIH SA establishment for Single Radio Handover is provided as an option SPoS generates a key K and distributes it to TPoS and MN MN and TPoS shall use the key K as it is generated through EAP as in 21m to derive other keys (see Figure 46 of 21m) The cipher suites are defined in 21m for TPoS and MN to negotiate (tables 24 and 25 in 21m) The optimized method must be restricted to reduce the security damage through domino effect If home domains of SPoS and TPoS have a kind of agreement, then there shall be a way to provide key K from a higher level entity In fact, it may be more reasonable to allow SPoS to derive a key K from whatever established before with MN, in stead of generating K from no where. In any case, it is a default to fall back to EAP between MN and TPoS

  4. The interfaces This key K shall be used in the same way as the key obtained from EAP, like MSK (Fig.46) K MN MAIK MIIK MIEK This interface shall be protected at the MIH level by the method specified in 21m K K SPOS TPOS This interface can be protected by the mechanisms out of the scope of 21

  5. What are not needed in the current 21.1 The interface between MN and SPoS is protected through a cipher-suite defined in 21m PRFsPoS is not needed KsPoS is not needed The interface between SPoS and TPoS is protected through an out-of-the-scope mechanism (see the first paragraph of 5.14) PRFstpos is not needed Kstpos is not needed The PoS is a convenient and natural place to locate security services, and roaming partners have in place agreements that can be used to beneficially establish the needed security agreements between different PoS modules in partner networks. It is expected that the PoS functions in partner networks must often communicate by data paths that traverse the external Internet; in such cases, a secure communication channel must exist or must be established between the partners. It is out of scope for this document to specify exactly how the secure communication channel should be established, but this can be done by configuration when the partners enter into their roaming agreement. It can also be done on demand by using IKEv2 (RFC 7296) [B36]. The following overview describes in more detail the circumstances enabling dynamic establishment of security association between the SPoS and the TPoS.

  6. What are still needed in the current 21.1 Nonce-T and Nonce-N are still needed for key derivation from K to the keys needed to establish protections between MN and TPoS The ciphersuite coded as c is still needed (see 9.2.2. in 21m) K MN MAIK MIIK MIEK K K SPOS TPOS Nonce -N Nonce -T

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#