RE: stds-802-16-mobile: Re: Security Issues Discussion
Hi All,
Chulsik, I agree with the general framework you laid out. You also got a
good discussion going...:)
Here are some important questions we need to answer before we settle
down on the exact solutions.
(1) What is the scope of device cert?
The Mfr. cert that is currently defined in PKM, should it be limited as
a device credential only. Now in the DOCSIS model of CPE deployment, it
would be ok. This is because the Provider owns/distrbutes the CPE.
But in models where the CPE maybe purchased off the shelf, what is the
purpose and use of the device certificate? Will there be a global CA for
device manufacturers that is available to verify the device certificate
for any service provider network?
(2) Is the user cert the only preferred user authentication credential
or other credentials as well should be supported?
Whenever a user certificate needs to be supported, we have to also
realize how it might be provisioned. Though this maybe outside the scope
of 802, it would be helpful to develop some informative text on this
subject. This maybe needed for other significant user credentials
supported as well.
(3) What are the benefits of doing device authentication in addition to
user authentication? Do we do device authentication everytime on Network
entry in addition to user authentication, or is there a better
mechanism?
(4) During handoffs, do we used a EAP method based fast resume of the
authentication or we do a AK based fast resume? What are the
implications each method?
(5) What are the Key Derivation options? What is the best way forward?
For EAP there is keying framework draft which has been developed, do we
stick that mode of key derivation or do we do a modified version of
what's in PKM?
(http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.t
xt)
For PKM mode today, if we need to add AES-CCM support, as DJ pointed out
we need to make changes in the key derivation and also the TEK exchange?
For this to be backwards compatible, we will need to have two key
derivation models for PKM, one for DES-CBC(existing) and the other for
AES-CCM support. Is this acceptable?
I will try to put together some of these points in a draft contribution
by early next week.
best regards,
jose
> -----Original Message-----
> From: owner-stds-802-16-mobile@majordomo.ieee.org
> [mailto:owner-stds-802-16-mobile@majordomo.ieee.org] On
> Behalf Of Jeff Mandin
> Sent: Wednesday, November 19, 2003 4:46 AM
> To: Johnston, Dj
> Cc: stds-802-16-mobile@ieee.org
> Subject: 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.
> >
>
>
>
>
>
>