RE: [LinkSec] LinkSec Teleconf notes 8/19/03
The notes below bring up the discussion we had where it was asserted
(maybe by me?) that we should pick one mandatory cipher mode.
I now think differently. It also in the slides I sent yesterday (but I'm
still getting linksec mails I sent a week ago).
The two primary cipher/mode pairs of choice seem to be the combo
crypto/integrity modes AES-CCM and AES-OCB. Others may apply here,
insert your preferred mode here.
Here are the tradeoffs..
AES-CCM
- Unencumbered -> cheap
- Stream cipher -> only encrypt needed -> smaller die area than
OCB
- Inherently serial at the block level -> limits top speed
AES-OCB
- Encumbered - requires $$
- Data mangler - encrypt and decrypt needed - bigger dia area
than CCM
- Parallel at the block level -> Top speed is much much higher
than CCM
The reasons for selecting one over the other include a hard engineering
constraint, namely top speed.
It may be futile mandating CCM for a 100Gig optical link since the
crypto can't be implemented to be fast enough, whereas OCB is a viable
option.
It may be very undesirable to specify OCB for low power, low cost
devices since the extra cost and power associated with OCB would impact
the product.
So my assertion is that Linksec should define the table of ciphersuites
but leave it to individual MAC/PHYs adopting LinkSec to specify if a
particular ciphersuite entry is mandatory. The obvious outcome being
that high speed wired groups would mandate a parallizable mode and
groups with lower throughput technologies might mandate a less resource
hungry option.
Different ciphers used between different network technologies is hardly
going to be an interoperability problem.
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: Allyn Romanow [mailto:allyn@cisco.com]
> Sent: Friday, August 22, 2003 9:44 AM
> To: stds-802-linksec@ieee.org
> Cc: allyn Romanow
> Subject: [LinkSec] LinkSec Teleconf notes 8/19/03
>
>
>
> 8/19/03 802.1 LinkSec Teleconference Notes
>
>
> Attendees: Dolors Sala, Dan Romascanu, Tom Dineen, David
> Johnston, Allyn
> Romanow, Mick Seaman, Antti Pietilainen, Onn Haran, Ali Abeye, Mani
> Mahalingam
>
> Agenda: Go over Onn's slides
>
> Are the transmit and recv seqns the same as the SAID?
> a terminological issue
> SAID is fixed during connection whereas seqn changes
> seqn used so each secY will know which key is being used
>
> terminology - no term for an SAID that might last a year, as
> distinguished from one that might last for 5 seconds
>
> Onn- the reason for the seqn number is to have a smooth key exchange
> 802.16 uses seqn to identify which key
> does it increment? causes issue with recirculation
>
> Mick will put together a diagram and send it to the list. He will take
> what Onn has said and make a picture. There is not technical
> difference between what Mick was saying and what Onn is, just a
> terminology difference
>
> Reason to call out interface is for modularity so can change
> cipher in the
> future?
>
> choice of encryption algorithm
> Want to have one be mandatory
> but is there an alg. that would be acceptable worldwide?
> regulatory requirements different around the world
> Encryption alg. and message authentication alg.
> .11i has a single alg. for both -- CCMP
> pick an operable one, in addition to null. Some choices are-
> null, RC4, AES
> AES is the easy choice. All agreed
>
> Modes- some do encryption and authentication at the same time, need to
> recommend modes
> terminology same as .10 - use ICV nomenclature instead of MAC to avoid
> confusion of using MAC in two ways- Message Authentication
> and Media Access.
> opinions on the alg.? should be a parameter, so can change in
> future. Future-proofing is desirable. Authentication algs last about 2
> years before discover flawed.
> SHA1 is pretty stable
> engineering nice to have - want to base on same block cipher as the
> crypto, from a hardware perspective. look at options. CCMP and OCB.
> wise to limit now? no
> how user comunity feels about - encryption alg A and MAC B and they
> can't be the same-
> issue with .3, tell them packet size, if alg. not fixed then packet
> size is variable.
> future proofing is an issue in choosing algs.
> comes down to detail of describing tables - maybe
>
> key exhange - limit key storage
> Design so that number of keys in use at any one time should be small
> hope that when a packet shows up only 2 possible keys could be applied
> to it
>
> IV Initiation Vector
> Exchange must be smooth
> not easy to guarantee that IV will be identical at both ends
> different requirements for different ciphers - some ciphers require IV
> to be different, randomized, not randomized, transmitted with data,
> without data, etc.
> The IV can be very long 64 bits. .11 is 48 bits; there was alot of
> discussion iflong enough.
> Reordering, IV space can get partitioned, eats into bit space.
> IV defined in a way that number of bytes is negotiable? need
> to spec the alg.
> It is possible to describe the IV for all algs. Look at all the algs.,
> can find common bits of IV usage and incorporate that in our
> standard. Shouldn't be too hard.
>
> Need to specify the parameters for the encryption alg.
>
> Next week - discussion of Onn's updated slides and DJ's
> presentation sent to
> list
>
> terminology - LMI lower ISS for secY
> Mick- ISS Internal Subnet Service, see slides from the Plenary
> LMI- standard way of shuffling things up and down interface stack, it
> makes sure you don't get into cirucular difficulties
> see .1q for more
>
> We need to make a collection of the algorithms
> Onn will update presentation based on comments
> For next week - DJ's and Onn's update and anything else
> Allyn will be out, volunteers to take notes welcome, otherwise Dolors
> will take notes for next two times.
>
>
>
>
>
>
>
>