Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [security] About Security Context Transfer Contribution for fast re-authentication

Title:
Comments inline.

- Jeff Mandin
Security Adhoc Chair

Johnston, Dj wrote:
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.
I agree that  contrib 04/206 is something different from pre-auth, and that it's a good approach.

However the name has stuck. The adhoc might want to
impose a better name if it can arrive at a consensus position.
The name is significant because saying that "the MSS periodically does pre-auth" connotes quite a different scenario from "the MSS periodically sends a request for  the AAA server to refresh the distributed keys".

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.

One very nice aspect of this approach is that the "scattering" can be triggered according to various schemes: ie. both BS-initiated and SS-initiated eg.

    *  In some environments, it might be feasible for the AAA-server to preemptively scatter keys to all BSes in a domain. 

    *  In another environment, a BS might instruct the scattering to all the neighbors of an MSS's current serving BS. 

    *  An unprepared Target BS can request a Master Key from the AAA-server upon receipt of RNG-REQ from the MSS.

     * etc.

All of that is out of our immediate scope of course - provided, as you say, that we ensure that the airside signalling is defined appropriately.

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.
Not to take anything away from Jesse, but the 802.11 people have been looking at this for a while. eg. http://sec.ietf.org/saag/17-July-2003/L2SAAG/img9.html
They call it "proactive key distribution".

 BR,
- Jeff

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