| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
Yes. It is different in a number of ways. The published PKMv2 key hierarchy is based on a KDF using OMAC only. I have privately distributed a variant that uses either HMAC or OMAC to understand to what extend it harmonizes with the ideas of others, but it isn't a 16e submission yet.
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).
The older 3DES key transfer mechanism is still there. This is orthogonal to PKMv1 ro PKMv2, since it is separately negotiated with the ciphersuit negotiation.
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")
The method of backwards compatibiilty with PKMv1 stations is through supporting PKMv1 and making PKMv2 negotiable.
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.
This discussion has already taken place in other emails. I'll skip it here.
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.
The extent of the burden is something I believe can be mitigated. A similar issue faces 802.11i implementors. Should they throw hardware at WEP or TKIP as well as AES-CCM? In our case it is less burdensome, since the hardware impactful parts of the specification are in std 802.16-2004. The PKMv2 proposals only address the management protocols which are generally the domain of SW implementation and the most compute intensive part (the RSA authorization) shares much in common with PKMv1. The details of the message exchange changes to be secure, but the core algorithm does not.
Generally speaking, I hope that the PKMv2 should support the various possibilities of authorization and encryption modes as a superset of including PKMv1 concepts.
I believe that it does, through the existing PKM, ciphersuite and authourization policy negotiation bits.
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.
I am keen to see your proposal and I hope it moves us towards a harmonized position. My position on an EAP only mode (that the current policy bits support) is necessary for mobile use. For the benefit of the group, I should point out that 188r3 has not been submitted to 16e, it was a private harmonization proposal. I expect (and it seems to be the case) that it will be iterated soon, but in short it ties the KDF function to the OMAC/HMAC bit in the authorization policy support bits.
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