Re: [STDS-802-16-MOBILE] [handoff] [security] Security Issues for fast handover
Yong hi,
See detailed comments inline.
Have you seen the material on Key Caching from 802.16e D3? Perhaps you
can propose some text on these issues for the Adhoc Strawman document.
Regards,
- Jeff Mandin
Security Adhoc Chair
PS. For the 802.11 perspective see:
http://www.drizzle.com/~aboba/IEEE/11-04-0377-01-frfh-analysis-roaming-techniques.ppt
Yong Chang wrote:
>[STDS-802-16-MOBILE] [Handoff] Minutes from conference call on 6/2/04Dear Handover adhoc and Security adhoc peoples,
>
>Big bottleneck to make fast handover with Level 2 and 3 in handover adhoc's common understanding
>is to perform PKM procedure at the target BS.
>The full PKM procedure with multiple transactions over the air will take a long time at the target BS
>because one transaction(PKM-REQ/RSP) takes usually 7-8 frames processing time, that is 35-40ms.
>Hence, In order to resolve this problem, main approach for resolution is to skip the PKM procedure at the target BS.
>
>However, from the security perspective, it's not make sense that the target BS skips to authenticate the MSS entering to itself.
>
>
I agree w/ what you've said here. We need to minimize HO latency as
much as we can without compromising security.
>Accordingly, there are two requirements for the fast handover.
>
>1. The target BS shall skip all PKM procedure or perform at a minimum of PKM procedure.
>2. The target BS shall be able to authenticate the MSS before the MSS enters to the target BS.
>
>
>
>
Agreed.
Requirement 1 is that there is a MINIMUM of PKM transactions, since
there is always a need to prove who you are.
Requirement 2 is that the Target BS and SS have the capability to set up
a Secure Association before the HO. In practice of course, HO can
sometimes happen before the Secure Association is successfully set up.
>For meeting the above two requirements, there are usually two approaches for the target BS as followings:
>In the following approaches, the basic assumption is that the serving BS and the target BS, both trust each other.
>
>1. The target BS pre-authenticate the MSS via the serving BS.
> This approach is that the serving BS may be a proxy of MSS to perform the PKM procedure over the backbone with the target BS.
> That is, the security context is negotiated between the serving BS and the target BS.
> Finally, the serving BS can pass new security context to the MSS in the HO-RSP or BSHO-RSP messages.
>
> This approach has an overhead such that the serving BS shall negotiate the security context with all candidate target BSs and
> the target BS shall start the timer to retain the MSS's security context till the MSS successfully enters into the target BS itself.
>
>
>
Preauthentication can be done slightly differently as well. The SS can
communicate with the Target BS over the backbone (perhaps to an IP
address/port that is advertised in NBR_ADV), without the need for the
serving BS to act as a proxy.
>2. The target BS shall reuse the authentication of the serving BS.
> This approach is that the target BS reuse the authenticated result and its Authorization key again came from the serving BS.
>
Number 2 is attractive in some ways, but in practice it is considered
VERY bad security technique to reuse keys. One reason is that it
violates Forward Secrecy: ie. someone who intercepts your keys
somewhere can decode all of your previous traffic.
There are alternatives however. One approach is:
- the Serving BS and SS both apply a Pseudo-Random Function to
derive a new Security Context
- the Serving BS then transmits the new Context to the Target BS on
a protected channel (eg. using IPSEC), just as it does for Service Flow
information
>Basically, I think that the approach 2 is better.
>
>Any opinion ?
>
>
>
Approach 2 (with the modifications mentioned) is preferable from a
latency perspective as you say. Preauthentication will also be needed
(especially in interprovider cases). We should have some text for Annex
D about the two scenarios.
>Sincerely yours,
>
>Yong Chang/Ph.D
>Samsung Electronics.
>
>
>
>
>
- Jeff