[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.