Re: [STDS-802-16] [STDS-802-16-MOBILE] [security] Timeline

I've just come back from a weekend break and noticed that tonight is the date to finalize the requirements & goals. So I'd better get mine in before I go to bed. Here are my requirements for a new security protocol version...

The primary requirements are related to efficiency, security and implementation feasibility:

It must not impose unreasonable compute requirements
It must provide a reasonable level of security to both SS and BS
It must work with existing hardware

No frame format or GMH changes
It should be practical to implement PKMv2 in software and have it work on existing hardware, thus enabling upgradeability.

The secondary requirements are related to style and reflect “the way it’s done in 802.16”:

It should fit into existing capability negotiation mechanisms
It should be backwards compatible with the existing PKMv1
It should map to approximately the same functions as PKMv1. I.E. solve the same problem, only better.

More specifically, the goals of PKMv2 are:

Provide a means for an SS to authenticate the identity of a BS.
Provide for an authenticated, integrity checked TEK exchange
Provide a means for a BS to push a key to an SS. Currently the SS must ask
Provide for efficient rekeying of multicast groups. Currently multicast rekeying is resource inefficient.
Provide a group AK for multicast groups. The lack of a group AK prevents a secure key exchange for multicast groups
Provide sufficient keying material that the requirements of future link ciphers can be met without changes to PKMv2.
Provide an authenticated, integrity checked transport for EAP
Provide appropriate hooks linking EAP state changes to link transport availability
Provide support for enrollment
Minimize the number of basic cryptographic algorithms used to permit easy hardware implementation. E.G. using only AES-128 and RSA.

Other requirements, seen in other people's submissions, but with which I concur include..

Extended 256 bits Key Hierarchy for enhanced key derivation

Shall provide enough key materials to support MAC message protection key and Group Key generations, and future expansion
Shall be able to support EAP inner method Key derivation function if AAA key was generated by inner method

Define top level Security Association that manages security info of MAC messages in either awake and idles state
Mutual authentication is EAP method specific requirement and shall not be captured in 802.16e, unless we want to extend existing PKI based authentication
Secure MAC management messages support (Note: Here MAC Managements messages including PKM EAP encapsulation messages)

Crypto Synchronized Integrity check support against Replay Attack
Confidentiality support for Identity and session info protection

fix and complete EAP encapsulation message defined in current baseline to encapsulate EAP messages as defined in RFC 2284bis ID
Hardware Friendly AES Authentication mode, Authenticated encryption mode, and Encryption mode support
Pre-authentication/Fast Reauthentication support based on below criteria

Shall minimize HO reconnection time
Shall not degrade Security defined in SA

Shall be able to support MBS and other multimedia service

Shall support Macro diversity in neighborhood cells
Shall be able to support crypto binding between PKM based link layer Encrpytion Key and MBS service encryption key by third party service provider

(this latter stuff I copied and pasted.. it's not mine!)

The proposal on flexible encryption location I think needs discussing. The problem seems real, the solution is not something I've done enough study on, so I'm staying away from any recommendations either for or against at this time.

It's 11.38pm now, so I am within the submission time with a whopping 22 minutes to spare :)

-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] On Behalf Of Jeff Mandin
Sent: Thursday, May 27, 2004 6:45 AM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: [STDS-802-16-MOBILE] [security] Timeline

To the Security Adhoc team,

As you know, our objective is a single Security Adhoc contribution document completed by June 25. Below is a timeline to meet that target.

May 31:     Finalize the list of Requirements/Goals for the unified contribution + Call for (individual) contributions
---------

Around this time I'll upload a "strawman" contribution document.

To re-submit a Session 31 contribution to the adhoc, please upload a new revision (ie. using same contribution number + "r2" or whatever) that indicates your proposed modifications to the strawman.

The contributions period is almost 2 weeks long (ie. a long time given our compressed schedule). Please use the time to make sure that your contribution is complete, and that it addresses issues that we've listed. But don't hesitate to upload your contribution earlier if you can.

June 11:      End of Call for Contributions
---------

We'll proceed to discuss the contributions on the reflector and merge the contributions into a single document.

June 18        Initial revision of unified adhoc contribution
---------

Discuss and revise this for one week.

June 25        deadline for submission of adhoc contribution to TGe
--------

- Jeff

Jeff Mandin
Security Adhoc Chair