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