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