Re: [STDS-802-16-MOBILE] [security] About Security Context Transfer Contribution for fast re-authentication
Think of Mobile IP. Mobile IP is quiet a good concept and its usage is
specified in 3GPP and 3GPP2 standard. Yet still it's not used quite well,
because of its management and deployment difficulty. Also as I mentioned
EAP-TTLS, PEAP is more favored over EAP-TLS, which requires mutual X.509
certificate provisioning.
With the same rational, I'd like to see full security context transfer in
the standard as well, because it'll be quite efficient from the perspective
of radio resource management and database management, etc. But I feel your
concern about security weakness. I prefer to protect these security transfer
with IPSec or the equivalent measure.
----- Original Message -----
From: "Jeff Mandin" <jmandin@STREETWAVES-NETWORKS.COM>
To: <STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
Sent: Monday, July 05, 2004 10:45 PM
Subject: Re: [STDS-802-16-MOBILE] [security] About Security Context Transfer
Contribution for fast re-authentication
> Donnie hi,
>
> The terminology here seems incorrect. "Pre-authentication" generally
> means conducting an authentication exchange in advance or in
> anticipation of HO. And "Fast Reauthorization" generally refers to a
> brief exchange to confirm mutual identity that happens after a network
> entry that was preceded by Pre-authentication.
>
> Though I can't vouch for the terminology or conclusions from your
> subcommittee F2F, from your message it sounds like what you call fast
> re-authentication is really full transfer of Security Context (including
> keys, timers, counters, etc.), which is much more vulnerable than
> pre-authentication followed by AK keying, and possibly too vulnerable
> for 802.16. Key Reuse violates the notion of forward secrecy, opens up
> Replay vulnerabilities, and often provokes disdain from security
> experts. I think that this is basically what Phil is saying.
>
> Regarding SAID_Update, my reply comment was based on the assumption that
> there is no such thing as full Security Context Transfer. If there is
> full Security Context Transfer, then SAID_Update is of course necessary.
>
> Regards,
> - Jeff
>
>
> galahad wrote:
>
> >As you remember, during F2F meeting we had discussion on
pre-authentication
> >and fast reauthentication. And with pre-authentication, key is refreshed
> >between MSS and BS. But with fast authentication, Target BS and MSS may
use
> >AK/TEK keys transferred from serving BS. And people in the F2F meeting
made
> >a consensus on supporting both pre-authentication and fast
> >re-authentication. That's what I remember from the meeting and I checked
> >with Junhyuk. So MSS/BS AK keying may not be unique and transferred
AK/TEK
> >may be used transparently between MSS and target BS. But in this case,
it's
> >better for target BS and MSS renegotiate PKM when MSS and target BS
> >recongise on-going traffic does not flow for the time being not to
interrupt
> >handoff.
> >
> >Due to the over-burden of pre-authentication(e.g. database runout due to
> >huge amount of AK/TEKs and respective timer for just one MSS, two pairs
of
> >AK/TEKs in BS_1, BS_2, BS_ActiveBSSet, and then after movement of MSS to
> >another BS, AK/TEK sets in BS_10, BS_11, BS_ActiveBSSet2), and lots of
radio
> >message transaction and backbone messages, it's better for operators to
> >decide which one be used. So pre-authentication and fast
re-authentication
> >should optionally be supported.
> >
> >So from this perspective, Junhyuk suggested me to put some text on the
fast
> >re-authentication section. Any comment on this or C80216e-04_50r1 is
> >appreciated. Thanks.
> >
> >
> >[Phil] Much of the contributions discussion on transferability of AK is
not
> >true. Each MSS/BS AK keying must be unique (see C80216e-04/200) to
maintain
> >paired/private keying, or else you are useing public keying, a completely
> >different level of security and different set of administration issues.
> >However, incorporating SAID_Update along with CID_Update in 6.3.2.3.8 is
a
> >good idea, and is transferable, thought the language needs scrubbing.
The
> >proposed language for 6.3.20.4, 6.3.2.3.5, 6.3.2.3.6 and 11.5 needs to be
> >harmonized with C80216e-04/144 as it duplicates changes and language in
that
> >contribution. Need substantial revision to D.2.5 to transfer only
> >permissible security elements.
> >
> >==================================
> >Donnie Dongkie Lee
> >Seorindong 99, JongRoGu
> >Seoul, Korea
> >SK Telecom
> >Phone: +82-2-6323-3147
> >Mobile: +82-11-758-4359
> >E-Mail: galahad@nate.com
> > galahad@netsgo.com
> >==================================
> >
> >
> >
>
>
>