| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello DJ, Jose, Jeff, and all:
I would like to comment the DJ's thoughts.
I agree with DJ most of the comments, but I have slightly different thoughts.
I wrote my comment as a embedded sentences between DJ's comments below...
Sincerely, ..... CS
-------------------------------------------------------------------------------------------------
DJ Wrote:
C.S.,
I agree. We should try to get satisfactory text ready for the vancouver meeting in January. You have done most of the groundwork already and we should use your document as a baseline.
The things I think I would like to achieve are..
1) Align your proposal with the AES-CCM mode changes. I will provide text for AES-CCM, but there is some work to do in the area of key derivation that overlaps with yours and so we need to make sure they are correct with respect to each other.
==> I generally agree with using AES-CCM mode. But, as Jeff said "it requires addition of a per-packet IV field," if then, someone would got some negative feelings. So I hope that would be possible to select the mode selection of applying AES-CCM or not.
2) Put in a secure binding between the EAP traffic and the AK. By this I mean derive an EAP authentication key from the AK (using HMAC) and use this key to generate a HMAC-SHA1 digest of each EAP message. We may need to add sequence numbers to the EAP frames as well to guard against replay.
==> I have a thought that EAP messages need not having keys to generate the HMAC, therefore EAP authentication key also need not be required.
==> Having the sequence number has some advantages, so we can apply the sequence number by adding it as a TLV in PKM messages (EAP-Transfer-Req/Rsp).
3) Make device authentication and user authentication optional. So the following cases apply:
1) device auth and user auth => Do PKM x.509 cert authentication and AK key exchange using RSA. Then do EAP based user authentication
2) Only user auth required => Generate shared secret AK using RSA (but no need for an X509 certificate), then do EAP based user authentication
3) Only device auth => Similar to existing PKM.
==> I agree. So, we should add these options to our contribution #62 (C802.16e-03/62) by adding the authentication type negotiation field in SBC-REQ/RSP messages.
==> Jeff's comment about device authentication by using EAP-TTLS is good. But the possibility for applying the ESN/MAC-Address, etc. as an EAP-TTLS-based ID/PW can be studied more.
4) Include the full details of AES-CCM mode link cipher, including 128 bit KEKs to exchange 128 bit TEKs for the 128 bit cipher.
==> I agree. But some more studies needed.
5) Make this all backwards compatible. I.E. a legacy PKM/DES SS would work on a base station that did not demand user authentication and a new SS would work with a legacy PKM/DES base station.
==> I agree. In my understanding, it was already included in our contribution #62 as a default case.
6) Create some sort of recommended practice on EAP methods (E.G. mutual authentication required) and credential type (E.G. Smart cards, sims, password hashing, etc).
==> This is very important thing, but not an easy matter, I think. So I would like to say that we will discuss this as a longer-term issue, and we initially focus on adding the open privacy framework to the current security mechanism in 802.16.
7) Define MIB entries for all our defined objects such as keys and authentication policies, so that it can be included in the MIB proposals that are currently being made.
==> I agree with DJ. We can provide the examples of minimum parts of the MIB. And it needs a discussion of whether we include the MIB stuff in the initial contribution or not.
DJ
--------------------------------------------------------------------------------------------------------------------------------------------------------