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

Re: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2



Title: Message
Some thought edited in below.. 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, May 24, 2004 11:33 AM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2

To the Security Adhoc group,

 [snip] 
4.  It's been considered desirable to support a model where a backend server (eg. multimedia broadcast content distribution server) is responsbile for key management.

     [ I think that the best way to support such a broadcast distribution model would be with IP-layer security/key management and IP multicasting.  Then the MAC layer (ie.BS-to-multiple-SS) security/key mgt. would be entirely transparent to the content broadcast service.]
 
I have a problem with defining an IP distribution mechanism since it is not layer 2. Certainly a management procedure or recommended practice could map IP distibution to a well defined L2 distributions. However at the least we need to provide a L2 distribution mechanism within the MAC. We cannot assume IP to be present, particularly with the ethernet, 802.1Q and ATM convergence sublayers.

 [snip] 
6.  The PKM-KeyReq/Key-Rsp is inefficient for distributing TEKs of Security Associations that are actually used by multiple SS. ie. as things stand now, each individual SS sends a KeyReq and receives the key in KeyRsp.  A more efficient "push mode" TEK distribution is desirable.
 
For this to be possible, without enabling forgery by members of the multicast group, it seems that the 'pushed' key needs to be signed with the BS private key, using an asymmetric key digest mechanism (RSA? DSA?).
 
There is a lesser level improvement, which is BS initiated key transfer. This allows the BS to preempt the key transfer time and spread the load of key transfers.
 
 [snip] 
8.   Support for Pre-authentication is desirable - ie. enabling an SS to authenticate with a potential target BS via the backbone (and establish a shared Master Key) before doing the HO.

    [Preauth is an important feature, and can coexist with schemes that receive freshly-derived Master Key material from a trusted peer BS or ASA server..  However there seems to be no particular motivation for running preauthentication inside the MAC - instead: preauthentication via a higher-layer mechanism (eg. PANA) using the ordinary packet transport is appropriate.  Note also that running preauthentication inside MAC mgt messages leads to clumsy multiple-step proxying, as the BS security sublayers would sometimes need to forward messages between subnets or to different providers]
 
Same L2-L3 argument as for key distribution above.
Pre-auth and cunning key derivation schemes could indeed co-exist. I'm not sure if the world will thank us for picking 2 solutions though. It seems that effective pre-auth needs to be tied into the handover decision making entity (in the NMS?) since it is that that knows where it might want to pre-auth to. I suspect a similar line of reasoning applies to key derivation schemes. Either way, its an argument for putting the fast handover security messaging in the right place in the architecture.
 

- Jeff Mandin
Security Adhoc Chair
 
DJ