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



Jeff and Security Folks, I put my comments with bracket [Donnie] below.
 
Thanks.
----- Original Message -----
Sent: Tuesday, May 25, 2004 10:46 PM
Subject: Re: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2

 
Jeff,
 
Thanks for putting together PKMv2 issues.
My comment is inlined below
 
----- Original Message -----
Sent: Tuesday, May 25, 2004 3:33 AM
Subject: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2

To the Security Adhoc group,

It was good to meet all of you in Shenzhen.  What follows is an initial summary of the security issues and desired features (ie. requirements) for PKMv2 (and other pieces) as distilled from the discussions last week. This list assumes PKM-EAP as the starting point; so mutual authentication, AK establishment handshake etc. are not in the list.  Important editorial/document structure issues are similarly omitted for the time being.
[JH] I think we should also need to add new PKMv2 key hierarchy, since larger key size is definitely desirable for key derivation and future expansion. 
 [Donnie] If the mutual authentication is mentioned here from the context of PKM, it's within the scope of IEEE 802.16. But if that is mentioned from the context of EAP-TLS etc, then it's outside of our standards scope.

My own opinions on the particular issues are contained in square brackets.  I'm sure that I'm missing some issues, so please respond with additional problem statements or details together with your opinions.
[JH] I see some other missing security issues here but I will wait until we reconcile your list first.
 

1. MAC management messages are currently vulnerable to Replay attack. 

Specifically:  an attacker can capture and replay a packet such as HO-Ind or Location-Update, inducing undesirable consequences.  Replaying PKM-Key-Rsp could enable an attacker to force an SS to use an old (and possibly cracked) TEK.

    [Serious issue.  Must fix]

2.  Currently, the EAP-Transfer messages are forgeable, which could enable a Denial-of-Service attack.

The EAP inner methods used in 802.16 are assumed to be "safe" in the 802.16 environment..  Nevertheless, an attacker can still repeatedly forge the EAP-success or failure msgs to disrupt the authentication exchange (cf. RFC 2284bis section 7)  The significance of this threat is mitigated by the fact that Denial Of Service is always possible in a wireless environment if the attacker can eliminate or change packets, or simply generate noise.

    [We can debate whether and to what extent this should be regarded as severe. Some protective solutions might be trivial - however if more a complex scheme for protecting against this in handover adds latency to the handover it might not be worth doing (particularly if the forgery protection is still less-than-perfect).]
 
[JH]  Protection of EAP messages is desirable especially in case of Link Layer can inherently provide it.  It should protect EAP from most of security vunerabilities listed in RFC2284bis ID including forging user identity, ciphersuites, result indication, and so on.  Handoff latency is more like pre-authentication and fast re-authentication issue.

 [Donnie] As JH mentioned, protection of EAP messages is desirable and is achieved when link layer, specifically PKM, supports. That's why I'd like to put EAP after PKM Key exchange phase. If the EAP can utilise the protection which PKM security layer supports it'll have minimum impact on the current PKMv1 and the vendors easily add EAP modules over PKM layer.
 
3. Sending EAP and other MAC-mgt messages unencrypted (as we do currently) enables a snooper to determine which SSes (ie. SS-IDs/Mac Addresses) are present in the geographic area.
 
 [Donnie] As I mentioned in bullet number 2, EAP could be encrypted using PKM security mechanism or could be protected by newly defined mechanism like IEEE C802.16e-04/67.

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.]

 
[JH] I think we need to elaborate little bit more here, it is not very clear what is the issue here.
PKMv2 should support Group SA and Group key management, in addition to that there was a proposal for Broadcast service and its security over 802.16.
 
[Donnie] One conecern about central key management is that it'll make a backend server to be heavily loaded with lots of security-related stuff. From the past experience, with EAP-TTLS or PEAP maximum authentications per second(MAPS) was 30~40 whereas MAPS for EAP-MD5 was 2000. From the perspective of security, putting everything related with security into backend server seems beautiful. But considering the real-world situation from the operator's perspective, that's a quite different story. One more thing, as I said at Shenzhen mtg, EAP-TLS seems beautiful at a quick glance. But considering the deployment of subscriber's X.509 is not that easy. That's why EAP-TTLS or PEAP is born. I'd like to emphasize the operator and the customer's views on this. I don't want to see the cart is pushing the horse.

5.  The existing PKM Traffic Encryption Key distribution mechanism (ie. PKM-KeyReq/Rsp) do not provide "liveness"/key freshness guarantees.

    [ Currently 802.16 downlink Security Associations are effectively-speaking always multicast (ie. the AAA server is the only entity which knows whether a particular Service Flow is available to more than one SS), so we're limited as to what we can do on the downlink unless we change the semantics of the SFId.. We can change it on the uplink easily however.]

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.

7.  There is currently no explicit "authorization" Security Association.

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]
 
[JH] Preauthentication/Fast-reauthentication whatwever it is called can be provided in many ways, however regardless of use of freshed-derived key materials or recycling previous key material it still involves MAC mgt messages
 
[Donnie] I support the fast-reauthentication or short-hand reauthentication. One of my previous contribution was about recycling the AK/TEK at the target BS. One concern about preauthentication is that preauthentication through backbone msg may put additional burden because actual handoff may not happen and preauthentication may interrupt the on-going traffic connection although these two use different connection(primary management connection for PKM and transport connection for traffic). Alternatively to the fast-reautication(if fast-reauthentication is not desirable), target BS may allow the traffic flow for short time until the current connection goes dormant. In cellular world, when a MS handoffs between MSC, target MSC delays authentication until the ongoing voice connection is finished.
Thanks,
JH SONG
 
 

- Jeff Mandin
Security Adhoc Chair



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