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

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



Title:
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.

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.

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

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.

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

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]

- Jeff Mandin
Security Adhoc Chair