stds-802-16-mobile: RE: Security Issues Discussion
Comments embedded below..
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: Jeff Mandin [mailto:jmandin@streetwaves-networks.com]
> Sent: Wednesday, November 19, 2003 4:46 AM
> To: Johnston, Dj
> Cc: stds-802-16-mobile@ieee.org
> Subject: 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.
Yes it should be orthogonal, however the key exchange (that is tied into
the PKM protocol) must have a 128 bit key exchange added and PKM needs
to know to apply the appropriate length key exchange based on the
cipher. This is the only overlap that I see.
>
> 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.
>
Here's my quick DES-CBC bashing attempt...
DES-CBC is privacy only. It does not provide for data origin
authenticity or replay protection. It also requires a randomized IV and
if you fail to acheieve sufficient randomness (a common problem) the
security is lost. In the base spec, I am unclear as to how this
randomness is guaranteed. The DES IV seems to be generated from non
random sources.
Also the collision avoidance guarantees of the key and IV are only
statistical, collisions (an hence publication of the TEK) can happen at
any time. The incrementing PN of CCM mode does not suffer this problem
and provides implementations with a clear indication of when it is
necessary to re-key.
> >
> > 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?
>
I'll need to think about it.. I'm not convinced that it's a problem yet.
We can probably observe what is reasonable EAP-conduit practice from
802.1X.
> > 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.
>
Using EAP for device auth is a reasonable goal. We need to think how to
integrate this with the AK key exchange mechanism in PKM since as it
stands, PKM does the device auth right now and we need to think
carefully about the merits of undoing and effective PKI based mechanism.
> > 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.
>
This needs to be defined somewhere for device interoperability. We
should work out where.
> - 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.
> >
>
>
>
>
>
>