[LinkSec] LinkSec 80-2.1AE Teleconference notes 9/16/03
Teleconference Notes 802.1AE LinkSec
9/16/03
Norm Finn, David Johnston, Dolors Sala, Rene Struik, Allyn Romanow,
Antti Pietelainen, David Nelson
Agenda - discuss DJ's slides
DJ's slides - https:\\www.deadhat.com
Discussion of PN- packet number, used to create a nonce
can't start encrypting or decrypting frame till you have it
#6 - 2 types of header data, what will be authenticated and what won't be
authenticate d
eg., don't authenticate hdr checksequence in 802.16
Gap in time between constructing nonce and encrypting data is a good
thing
#8 ICV Size - some modes susceptible to birthday attack, others not
Pick size based on needed strength, not related to data rate
#9 PN is related to packet rate. need to rekey when run through numbers
Comment- only 3 bytes - why bother to negotiate?
.16 cared a lot
Could be defined per media, rather than per negotiation
If you negotiate PN, what about provider bridges?
#12 last option, fixed list of algs., with size
DJ likes this option best
What about across provider bridge? Might affect security negotiation?
Might choose lower PN with Provider Bridge across slower link
Attacker can operate faster than slower link
#15 All these params should be tied to the cypher type
If shared medium, do you have a single authority for assigning SAs on
this link?
Could restrict to point to point
Use 1 or 2 of the 16 bits, to say this 16 bits is all there is, or
there are an additional 6 bytes, used for extra context
Need for shared media
Can we get rid of SAID, 16 bits, if peer to peer association?
Contextual information lets you know what you're doing, such as:
In this case SAID is so big,
In this case, SAID is not there, not needed
In this case, SAID is 16 bits
Or, we can just say SAID must be a certain size
Might make adoption more difficult
Need to support rekeying - .16 does it well, .11 doesn't - in DJ's
opinion
This group needs to decide what the key management policy is
Isn't key management policy outside of scope? Yes but need to define
a security assoc that presupposes a key update mechanism
.10 problem was that it allowed non interoperable
In terms of the cipher chosen- make sure everyone has a default that
works on local link and across provider bridge,
from among available ciphers
slides #17,18
Frame expansion - beyond tolerable limits for 802.3
Housely suggests either limiting MTU or fragmenting into 2 packets
Norm - one issue with .10 was it allowed arbitrary fragmentation
Anything more than 2 fragments brings in issues of allowing more
capability beyond L2
Agree 2 segments should be max number of segments
slide #19
Do negotiators need to know it's a Provider bridge? Norm says no,
Could be a buffered hub, not a provider bridge.
Don't want to end up with the requirement that you would have to tell,
or know what kind of bridge station is on
.10 fragmentation shouldn't be followed, allows arbitrary fragmentation
vanilla link means not across a provider bridge
DJ- this is a straw man, please poke holes and find something better.
Interim meeting in Sacramento next week, no teleconference, none the
following week either, as is the custom to skip week after face to
face meeting.