Re: [STDS-802-16-MOBILE] [security] Summary of issues and requirements for PKMv2
JunHyuk hi,
Please don't wait with the missing issues. Instead please prepare a list
and send it to the reflector as soon as you can.
- Jeff
Jeff Mandin
Security Adhoc Chair
JUNHYUK SONG wrote:
> Jeff,
> Thanks for putting together PKMv2 issues.
> My comment is inlined below
>
> ----- Original Message -----
> *From:* Jeff Mandin <mailto:jmandin@STREETWAVES-NETWORKS.COM>
> *To:* STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
> <mailto:STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
> *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.
>
> 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.]
>
> [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.
>
> 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
> Thanks,
> JH SONG
>
> - Jeff Mandin
> Security Adhoc Chair
>
>
>