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

[STDS-802-16-MOBILE] [security] Issue Resolution and Timeline

Title:
Hello security adhoc team,

A penultimate requirements/goals list will be sent out soon.  Shortly afterwards it will become the final list and a call for contributions will be issued.  Also, it was my bad that the original deadline was set for Memorial Day of some specific country.  Sorry about that and hope that we will work to make up for the lost day.

Thanks to everyone who supplied email inputs and feedback.  I had nonetheless hoped for less murkiness and more convergence by this point.  Two specific issues that we should wrap up so that we can move forward:

1.  Security requirements for MBS/broadcast channel support.

      At this point  I think we all agree about what the channel itself looks like:

             - MBS sends packetized content to be broadcast on multiple Base Stations in a single-frequency network.

             - Precisely the same data must be transmitted by each BS using PHY timing info as supplied by the MBS

    There seems to be 2 approaches to security for this case:

       "Approach A": Since the data must be identically transmitted by all neighboring BSes, there should be no 802.16-MAC-layer confidentiality/authenticity employed  for the broadcast service.  Encryption/message authentication.should be performed at the data-originating MBS (or perhaps transparently offloaded to another entity).

       "Approach B":  The requirement for identical transmissions from all BSes creates new requirements for MAC-layer security which must be built into PKMv2.  Specifically there is now a requirement that the BSes synchronize their encryption/confidentiality states, so that identical keys and IVs are used across all BSes at all times.  Within Approach B, different mechanisms have been suggested as to how to accomplish the synchronization of keys etc.

There are strong opinions about this, so it might stay open in which case it's likely to haunt us later.

2.  Confidentiality of MAC management messages - what is the specific reason we are considering it?

    - It can be computationally expensive for an SS.

    - Geographic privacy is anyway compromised by including SS-ID in RNG-REQ (and, incidentally, Service Level Prediction in RNG-RSP "compromises" information about network provisioning)

    - If disclosure of SSIds is really a concern, the SSIds could actually be left out from EAP-Identity, REG-REQ, and possibly other msgs



- Jeff

Jeff Mandin
Security Adhoc Chair


Johnston, Dj wrote: 
Jeff and other security adhocers,

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 :)

DJ


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