Re: [STDS-802-16-MOBILE] [security] About Security Context Transfer Contribution for fast re-authentication
On the matter of terminology, I agree that pre-authentication is
something of a misnomer. The routable PKM thing I was promoting (that
turned out to be a lemon) was certainly pre-authentication (I.E.
authenticate before associate) but the key derivation scheme proposed is
something else. However the name has stuck. The adhoc might want to
impose a better name if it can arrive at a consensus position.
I see it as prior key establishment. The authentication happens once
with the AAA server and the authentication process yields per BS keys
computable by the AAA server and the SS. So the AAA server can scatter
the keying to BSs via the backhaul.
Taking advantage of this requires a little bit of airside signaling.
Therefore we need a name to attach to this bit of behaviour so we can
refer to it. For now, pre-authentication is the name.
'Per-BS Key Establishment' sounds a bit klunky to me, as does 'AAA
server mediated PMK distribution'. alternatively we could go for a
functional description like 'fast PMK establishment'. Perhaps Jesse
should get naming rights, he's the one who proposed it in the first
place.
It's gone 11.00 PM, so I have nothing to say about SAID_Update at this
time :)
DJ
-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] On Behalf Of Jeff
Mandin
Sent: Monday, July 05, 2004 6:45 AM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
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 ==================================
>
>
>