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

Re: [STDS-802-16] [Security] Cleaning up 802.16e security

Title: [전체회신] [STDS-802-16] Cleaning up 802.16e security
Yigal and all,
 
Several members have pointed out to me that I misinterpreted Chulsook's posting and that, in fact, we both agree on the nature of 'interoperability'. I apologize to Chulsook for any misunderstanding.
 
However, I still worry about an imprecise interpretation/reduction of the matrix compatibility equation presented in the PAR.  The PAR specifically requires 16e MSS to interoperate with 16d BS, and 16d SS to interoperate with 16e BS. That is it.

For security that means we don't screw around with the original RSA-DES security structure or function and that all 16e devices must support RSA-DES. That does not mean that we cannot add a new, more robust security mode that a 16e MSS and 16e BS could use to advantage: PKMv2. Chulsook is certainly correct that we should try to reuse as much 16d material as possible in 16e. This has been the groups policy on all subject prior art subject matter. But when the changes required to the 16d feature or function are so substantial, sometimes it is better to handle those in a new PKMv2 security subset (just as PKMv1 is a security subset) and not risk damaging the existing PKMv1 language while shoehorning major changes in. This assumes major changes are warranted of course.  And lengthy security review determined that substantial changes are required to support mobility, a much more dynamic and higher security risk environment by far than fixed.  I believe the security contributions have done much to balance continuity of 16d security concepts and mechanics with 16e harsh security requirements.
 
In Short, creation of PKMv2 was the prudent and, in fact, less intrusive mechanism to achieve the necessary security goals for mobility. If we have concern over specific feature changes to PKMv2, as Chulsook did, we should bring that forward for discussion. It seems to me that Chulsook indicated that many of his concerns had been addressed and accommodated.
 
I just wanted to note that specification that for a 16e device to work in mobility mode it must support PKMv2 is completely in harmony with the interoperability requirements. PKMv2 required for mobility would still let the 16e MSS device connect to 16d networks using PKMv1 in what is by definition fixed service. And 16d SS would not be injured when talking to 16e BS in PKMv1 because 16d SS don't do mobility anyway.  So having PKMv2 be synonymous with mobility works perfectly in the backwards compatibility matrix.

Thanks,
Phil
----- Original Message -----
From: Yigal
Sent: Thursday, July 22, 2004 3:35 AM
Subject: Re: [STDS-802-16] Fw: [STDS-802-16] [Security] Cleaning up 802.16e security

Hi Philip, Chulsik,
 
I fully support Chulsik.
I believe that what Chulsik is trying to say is that we expect a mobile subscriber to be able to communicate with a fixed BS, and we expect a fixed BS to handle mobile subscribers. It is a very simple concept, and very important from deployment point of view (this is also the main point that distinguishes our group from 802.20).
 
BR,
Yigal Leiba
 
 
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Phillip Barber
Sent: Thursday, July 22, 2004 7:08 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] Fw: [STDS-802-16] [Security] Cleaning up 802.16e security

Chulsook,
 
I must disagree with your definition of 'backwards compatability'. Maybe it is an issue of language.
 
It is not necessary that all features adopted in 16e be backwards compatable to fixed, only that functions and features that replace or add-on to existing fixed methods maintain a mode of operation that is completely backwards campatable.  New features or functions need not be represented in fixed mode at all--after all, that is the function of an Amendment PAR TG, to add new material and/or amend existing material in an existing standards document.  New features like mobility, sleep, and idle mode are examples of new features that are not previously represented in the fixed document and have no basis for compatability. Security is an example of a function/feature that is existant in the fixed document, so in 16e we are required to maintain a mode of operation exactly the same as in the fixed document, and we cannot alter the existing security messaging structure in such a way that it is not compatable with the fixed document.  Other than that, we are certainly free to add any new security feature, be it PKMv2 or UltimateSecurityMethodvN.
 
After due deliberation, we find it necessary and prudent to provide methods of higher security operation for mobile environment with its higher requirements. We are fortunate that the state-of-the-art in security continues to evolve and provide us tools to enhance, and continue to enhance in the future, our security methods.  The new security methods were considered by a dedicated group over substantial time prior to arriving at the agreed solutions. Keying size, key components, keying method, all of these were considered and appropriate decisions made based on that available state-of-the-art. You make no compelling new argument as to why employing the previous key structure into PKMv2 would decrease complexity while supporting similar security assurance.
 
The previous method for RSA-DES is completely unchanged.  That is all the backwards compatability we need.
 
Thanks,
Phil
 
----- Original Message -----
From: 윤철식
Sent: Wednesday, July 21, 2004 9:12 PM
Subject: [STDS-802-16] [전체회신] [STDS-802-16] Cleaning up 802.16e security

Hi, DJ and all.


I would like to comment on the approaches of PKMv2 to upgrade the current PKMv1.

In my opinion, when we upgrade or revise the currently fixed specifications, we shall provide the backward compatibility to the older one. Even in the case of backward compatibility cannot be fully supported, we should clearly resolve the known problems in the current specification by maximizing the reusability of the current one. But, the PKMv2 overlooked these issues.

Currently proposed PKMv2 is a new and separate PKM protocol with PKMv1. The Key hierarchy (C802.16e-188r2) is different with that of PKMv1 (It is more systematically designed and conceptually better than the older one, but it is not compatible with that). The Key lengths are different and the input parameters are different, even if to the same algorithms:

-       PKMv1 AK = 160 bits, PKMv2 AK = 128 bits;
-       PKMv1 & PKMv2 HMAC Key Derivation Function is different, even though the SHA-1 algorithm is used to both, and its key length (160 vs. 128) and input parameters too.

And the PKMv2 uses the newly defined AES_Key_Wrap for transferring keys as mandatory feature for PKMv2 (In session #32, the AES_Key_Wrap was accepted already. But, I hope it will to be modified to include the older key transferring mechanisms).

Anyway, we can say the current PKMv2 (and its key hierarchy (188r2)) is not backward compatible with PKMv1. And it is not fully supported one of the most important goals and  requirements of the PKMv2 - "It should be backward compatible with the existing PKMv1." (See Ad Hoc documents: Jeff Mandin, "PKMv2 - Goals and Requirements"; David Johnston, "A New PKM for 802.16")

 
As you know, TGe PAR (IEEE 802.16-02/48r4, approved in 2002-12-11, and the only valid one) state that the following two types of interoperability (or backward compatibility) should be supported: "Subscriber stations specified herein, within stationary, shall interoperate with base stations in IEEE Std 802.16a. Base stations specified herein shall interoperate with stationary subscriber stations specified in IEEE Std 802.16a." The exact meaning of IEEE Std 802.16a should be interpreted as IEEE Std 802.16-2004.

On the basis of that PAR statement, the TGe-based MSS, when stationary, shall be interoperable with the TGd-based BSs (supporting PKMv1 only), but the PKMv2 is not backward compatible with PKMv1 so that the requirements are not fulfilled. And the TGd-based BS shall interoperate with the TGd-based SS (supporting PKMv1 only), but when the TGe-based BS cannot provide the PKMv1 capability, the requirements are not satisfied, too.

Therefore, in order to provide the backward compatibility (and/or interoperability) with TGd, the TGe-based MSSs and BSs shall provide both of the PKMv1 and PKMv2 capabilities. It is a too much burden and the duplicated functionality to the MSSs. 

Generally speaking, I hope that the PKMv2 should support the various possibilities of authorization and encryption modes as a superset of including PKMv1 concepts.

Fortunately, DJ proposed and showed me the modified Key hierarchy mechanism (188r3) to mitigate our uneasiness by introducing the HMAC SHA-1 key generation, and modified to change the proposal to allow EAP-only mode. We have been reviewing the proposal and we would like to propose an alternative by slightly change the DJ's proposal to maximize the backward compatible and reusable features with PKMv1. By doing that, we can reduce the overhead of implementing the two completely different mechanisms in each Mobile subscriber station, and will get a soft-landing from PKMv1 to PKMv2.


Sincerely,

Chulsik Yoon,
Senior Engineer, ETRI


P.S.

I would like to mention the data encryption issue of PKMv2, not relating to the Key hierarchy issue.

In PKMv2, we have generally agreed on using the AES algorithm for key management and data encryption. So, in my thought, if we select the PKMv2 based key management methodology, then we will also use the AES algorithm (not the DES algorithm) for data encryption. In the current specification, only the AES-CCM mode can be provided to data encryption using AES algorithm. Even thought, the AES-CCM can provide the high security capabilities by using the Counter and Message Integrity Check with AES, it needs a large amount of overhead (total 12 bytes of overhead per PDU; 4 bytes PN and 8 bytes of Cypertext ICV). In my opinion, most of the user service needs not this type of highly secure mechanisms, except the monetary transactions such as internet banking, mobile commerce, etc. Therefore, the another AES mode (not CCM), not having too much overhead for data encryption transaction, need to be added to the current security mechanisms in IEEE 802.16 specifications.

Thank You.

원본 내용:

보낸사람: owner-stds-802-16@listserv.ieee.org[dj.johnston@INTEL.COM]
받는사람: STDS-802-16@listserv.ieee.org
제목: [STDS-802-16] Cleaning up 802.16e security
받은날짜: 2004/07/17 토 12:15


All,
I think the input to the security work went rather well. We got most of the underlying mechanisms in the spec. Compare this with the time it took 802.11i to get to this stage. Of course we had the benefit of their hindsight.

As some of us discussed in the meeting, there are a few things to be done with the security work but also there seems to be agreement that we need to identify and limit the list of things we need to do, in order to bring the work to a close.

My list of things to be done is as follows:
    EAP Key agreement
    Generic Management Frame Protection
    PKMv2 Key Hierarchy
    PKMv2 Security State Machines
    Test Vectors (for the crypto algorithms operating over packets)
    Vulnerability analysis/corrections
    General clean up of the contributions that were accepted (we have LB14c for that)
I have vague memories of Jeff having another item for this list but its leaked from my head.
I will try to coordinate a consensus position on what the key heirarchy should be. So I'd appreciate comment on it. Particularly from anyone who disliked the current proposal enough to vote against it. I don't think the discussion in the meeting shed much light on what the concerns were, since I still don't know.

EAP Key agreement is in a similar situation. Jeff provided text, but it didn't pass. Therefore any input on what is needed to make it pass is welcome.

Anyone who can commit to filling in other parts of the framework should declare their interest, so people interested in contributing to the same areas can compare notes.

Hopefully we can reach some sort of consensus before the next meeting.
Regards,
DJ