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
>==================================
>
>
>