[LinkSec] UPDATED Notes from Teleconf 4/8/03 - includes brief summary
Hi Folks,
Sorry, I meant to give a brief summary and neglected to in the original notes-
Allyn
==============================================================
LinkSec SG Meeting Notes
4/8/03
Dolors Sala, dolors@ietf.org chair
Allyn Romanow, allyn@cisco.com, notes
Attendees:
Paul Congdon, Tom Denine, Ken Alonge, Dolors Sala, Jeff Waters, Bob
Moskowitz,Allyn Romanow, Mani Mahalingam,
Brief Summary:
Consensus that PPP should not be under consideration
Discussion of Bob Moskowitz's slides on architecture, sent to mailing list 4/8
How should MAC level management frames be treated? Do they need
integrity protection?
This is a major high-level outstanding issue for consensus
There was a discussion and some disagreement on how bridge PDUs should
be treated and how they are considered from a MAC point of view,
whether or not they need special treatment.
Threat model will be discussed in next week's teleconf.
=============================================
More Detailed Notes:
See Bob's slides
Discussion of PPP: Question - why PPP?
still used on provider links
cross bridge security associations
provider PPP link between two bridges, SA traverses between secure
bridges with unsecure bridges inbetween.
PPP like a full duplex MAC, below 802.1
developed for dial-up circuits, over Sonet, trans-atlantic links
over Ethernet-- unattractive, used in DSL but not elsewhere
used to do billing and control
general feeling that we won't include PPP
defined as a link layer
have to draw line somewhere
applicable to other link layers but we are doing 802 only
want to reign in the scope
Agreement to leave out considering PPP
provider view of LinkSec - 3 things provider looking for
1. billing - authentication
other authorization steps could be mentioned along with billing
eg QoS, rate limiting
AAA allows billing, etc.
by Provider, Bob means both enterprise and provider ethernet
Bob will forward Norm's notes
bi-directional authentication
where each side authenticates the other, symmetric
authentication protocols? what assumptions?
wants to avoid specific protocols like EAP in the architecture
handoff discussion: need to layer signalling
linksec does transparency of handoff
3 indept. concepts in handoff:
1. authentication is satisfied with bi-directional authentication
2. key installation
3. port or entity, whether in use or doing this ahead of time, a third
component. link can be authenticated prior to use.
think about these three independently, provides flexibility
Discussion of how to treat management frame:
integrity of management frame, MAC control frames
two issues - EFM, 802.3 MAC layer
second- a client of the MAC, like SNMP or RMON
Bob means the first issue not the second
if key management in place beforehand, can authenticate on initial frame
integrity of MAC management frames can be problematic- too specific
can provide a methodology to be applied by individual MACs
we can provide encapsulation
then you're in the .11 domain of providing security within individual MACs
multiple sets of keys, key hierarchies
EAP talking about key hierarchy
keys for MAC control distinct from keys for data
goes across numerous, possibly not participating, bridges
group keys - .11 has this concept
define a methodology a media can use
Does someone maintain a list of high level issues?
No, Allyn will
What are high level things we need consensus on?
Whether going to deal with integrity of MAC level frames?
integrity of management frames
should we be concerned with integrity of bridge management frames?
newer bridge work, GMRP, GVRP
multicast pruning GMRP, group multicast registration protocol
VLANS, group VLAN registration protocol
SNMP, RMON - those bridge management protocols that run above MAC service,
like data, would look like any other data frame
from MAC point of view they are data frames
frames are defined similarly to MAC layer protocols, fixed definition
by bridge layer protos, special formats and handling
bridging security model - this is a multicast problem, dealt with in
802.1d work
SNMP and RMON can be dealt with as client frames, whereas these
multicast protocols are different, technically below a secure layer
Paul disagrees
bridge PDUS are not special from a MAC point of view
special from a relay point of view
Can ask and defer to Mick Seaman, expert on the layering models
disagreement on treatment of these frames
should they be secured or not?
value in securing them, but not clear they need special treatment
data frames -privacy
integrity for MAC control management frames
are we to assume security is above MAC and below bridge layer?
802.10 is above MAC
802.1d figure 6.1 section 6
relay part of MAC or not?
disagreement on how it's interpreted