[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