stds-802-16-mobile: Re: Security Issues Discussion
DJ hi,
Thanks for your msg. Keep in mind that we need to currently focus and
arrive at agreement on the framework (or "network model" ).
> 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.
AES-CCM cipher should work with the regular PKM as well ie. it should be
added to the text in a way which is orthogonal to the addition of
EAP-TLS.
We need text to explain why DES-CBC is not sufficient. We will
certainly be asked to defend the choice of AES-CCM because it requires
addition of a per-packet IV field.
>
> 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.
>
Can you write a description of the Replay Attack vulnerability?
> 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.
This model is a good starting point. But what about the possibility of
"only device auth" for a provider that does not support full PKI?
EAP-TTLS could be used to support non-PKI device auth.
> 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.
>
> 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.
Agreed.
>
> 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).
>
> 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.
These are best left for the "larger" security working group. They
shouldn't appear in our framework or initial contribution.
- Jeff Mandin
Streetwaves Networking
>
> DJ
>
>
> David Johnston
> Intel Corporation
> Chair, IEEE 802 Handoff ECSG
>
> Email : dj.johnston@intel.com
> Tel : 503 380 5578 (Mobile)
> Tel : 503 264 3855 (Office)
>
> -----Original Message-----
> *From:* csyoon@etri.re.kr [mailto:csyoon@etri.re.kr]
> *Sent:* Tuesday, November 18, 2003 9:20 PM
> *To:* Puthenkulam, Jose P; Johnston, Dj;
> jmandin@streetwaves-networks.com
> *Subject:* Security Issues Discussion
>
> Dear Jose, DJ, and Jeff,
>
> Hi! I'm Chulsik Yoon.
> It was very good start we discussed and shared with the various
> persons of the idea of adding open security architecture above the
> current PKM architecture of 802.16.
>
> As I told you before, I reported the result of the meeting and my
> thought of promoting the work fruitfully. We discussed and
> concluded our basic stance to work that issue.
>
> We assigned and encouraged the following engineers to work with
> the Ad Hoc group members:
> Park, Ae Soon : aspark@etri.re.kr (Principal research engineer)
> Yun, Mi Young : myyun@etri.re.kr (Research engineer)
> Cho, Seok Heon : chosh@etri.re.kr (Research engineer), and me
> (csyoon@etri.re.kr)
>
> I will work as the contact point of ETRI members. And other
> research engineers will participate in the discussion case by case:
>
> Lee, Sang Ho (leesh@etri.re.kr)
> Moon, Jung Mo (jmmoon@etri.re.kr)
> Chang, Sung Cheol (scchang@etri.re.kr)
>
> Our basic thought to work is as follows:
> - We will cooperate with Intel (Jose and DJ), StreetWaves (Jeff),
> and other members who interested in the open privacy architecture
> and interworking between different networks.
>
> - The main players will discuss and construct the framework
> agreed between them, and afterwards we will release to other
> working group members for review and comment.
>
> - We hope that our contributions (C802.16e-03/62 &
> C802.16e-03/63) will be treated as the base document to work to
> constructing the framework.
>
> - The resulting document will be described as a contribution
> document to submit the next meeting (Session #29, Vancouver) by
> the name of main contributors.
>
> - We will list up the other issues to discuss in this Ad Hoc
> group such as coexistence of original privacy mechanisms and open
> privacy mechanisms, security issues during handover, and
> enhancement of privacy mechanisms, etc. So we will promote this Ad
> Hoc group works as the seed for the enhancement of 802.16
> specification in security and higher layer capabilities.
>
> - We will utilize the e-mail discussions between Ad Hoc group
> members as the main tools for discussion.
>
>
> I'm looking forward to your reply (your opinions).
>
>
> Sincerely,
>
> Chulsik Yoon
>
> p.s. You can call me C.S. or YOON.
>