Re: [STDS-802-16-MOBILE] [handoff] [security] Security Issues for fast handover
I fully agree. #1 and #2 can both be used. I have done enough work on #1
to provide text.
DJ
-----Original Message-----
From: Jung-Won Kim [mailto:jungwon74.kim@samsung.com]
Sent: Sunday, June 06, 2004 7:08 PM
To: Johnston, Dj; STDS-802-16-MOBILE@listserv.ieee.org
Subject: RE: [STDS-802-16-MOBILE] [handoff] [security] Security Issues
for fast handover
Dear Handoff and Security Ad hoc group folks:
One thing we should make sure and understand about the
pre-authentication is the channel condition to the serving BS when a
handover takes place is really bad (otherwise, why does the MSS want to
make a HO?).
But the pre-authentication has one advantage over the
post-authentication (I mean, just the normal authentication). That is,
since the traffic channel is still alive, the MSS and the BS can
communicate each other without waiting for the process being completed.
DJ mentioned that the option #2 (key re-use) could be problematic in a
roaming scenario. Yes, I agree somewhat with that. But the HO occurs
much more often within its own service provider network. In case of a
roaming HO, the MOB-NBR-ADV message informs the terminals in the cell of
the target BS being the one belonging to the other service provider.
Hence, only when it requests the HO to the target BS of the other
provider, the pre-authentication might be performed. At this time, it is
not right to preclude the option #2 due to the roaming scenario, as you
might have already noticed.
Although the kind of the options should be decided by the security ad
hoc group, I just want to point out that the option #1 & #2 can be used
in a mixed fashion.
Best regards,
Jung-Won Kim, Ph. D.
---------------------------------------------------------
Jung-Won Kim, Ph.D.
Senior Engineer
NTP System Lab. 1
Telecommunication Systems Division
Telecommunication Network
Samsung Electronics Co., Ltd.
Office: +82-31-279-3356
Mobile: +82-10-9530-3356
Email: jungwon74.kim@samsung.com
---------------------------------------------------------
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of
Johnston, Dj
Sent: Monday, June 07, 2004 10:18 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [handoff] [security] Security Issues
for fast handover
How do we do this without violating the user-BS trust relationship when
roaming between operators? How does the user know that the BS-BS channel
is secure? It is most likely to not be secure, what with the influence
governments have over fixed networks.
I'm not saying its impossible, I just don't know the answers.
DJ
-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] On Behalf Of galahad
Sent: Sunday, June 06, 2004 5:59 PM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: 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-t
echniques.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
>
>
>