Re: [STDS-802-16-MOBILE] [handoff] [security] Security Issues for fast handover
I agree with Yong Chang. As the perauthentication seems good from the
perspective of security, practically it has many drawbacks. So I prefer to
go with option 2, recycling the previously negotiated security context,
which is transferred from the serving BS to the target BS through the secure
channel, like IPSec etc.
----- Original Message -----
From: "Jeff Mandin" <jmandin@STREETWAVES-NETWORKS.COM>
To: <STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Sunday, June 06, 2004 11:06 PM
Subject: 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
>
>
>