[LinkSec] Teleconference notes from 6/17/03
IEEE 802.1 LinkSec Teleconference Notes 6/17/03
Dolors Sala, Chair, dolors@ietf.org
Allyn Romanow, Notes, allyn@cisco.com
attendees: Tom Dineen, Dolors Sala, Norm Finn, Bob Moskowitz, Antti
Pietilainen, David Nelson, Allyn Romanow
Summary:
No meeting next week, June 24
Next teleconf is July 1
Discussion of what topologies are in scope.
Discussion of authentication and what changes are necessary to dot1x -
It needs to be made useful for peer to peer communication model
Issues that need to be considered are provider problem - two
simulataneous SAs; and how do we want to handle shared medium, in
terms of key distribution, authentication, SAs?
===============================================================
More Detailed Notes:
Discussion followup from the Ottawa meeting
What about security between two endpoints with arbitrary bridges (B)
in-between? Does anyone want this?
Distinguish end2end vs bridge to bridge
You think you have a circuit and a bridge gets put in
Norm - an SA between 2 Bs, stick another B in between
What's it mean put B in between?
How does the B get there?
Cut cable, then you loose the SA
Need to set up new SAs
No way for Bs to discover and deal with each other except via the B in between.
If subscriber Bs connected via a Provider Bridge
Want this to work, 2 customer Bs connected by an ethernet provider
How get customer Bs to also have an SA with their local provider, edge Bridge.
Bob - thinks it can be done
Norm - assume Customer Bs can contact each other using a multicast or unicast
MAC address going thru Provider Bridge
Bob has some ideas, which he is writing up, how 802.1x needs major
re-working for LinkSec
Norm - frames from Provider Edege B to Customer Edge B and other CB to
this B, no clear way of distinguishing at Customer B which one the
packet came from
Except by source MAC address and that is not usually what you want to
use, though it could be used.
Because establishing an SA, just need a handle, in order to know which
association we are talkng about.
Always assume .1x is over insecure link
IETF - what do we need from/for this coming IETF? Nothing. RFC 2284BIS is
in last call
November IETF - possibly we will have something for the SAAG (Security
Area Group or AAA WG
Dolors - workplan on what we should be doing now?
How should be we address Bob's architecture?
He will explain more about authentication
Focus on the PAR, reason for existence, exactly what it is we are protecting
If IETF is looking at ARP and Neighbor Discovery, which is L2
supporting an L3 function, that is similar to us.
Norm - which management frames are you talking about?
Bob - what are we protecting? management frames, .11 has specific
management frames
Above MAC, protect something riding in the MAC
Norm's concerns are:
1. The provider problem - a customer wants two simultaneous SAs one to
local Provider switch and other to other customer at end of the link.
Only one of these authenticated, encrypted, maybe, not sure.
How to make .1x handle this case?
2. How do we want to handle a shared medium? two devices able to be
authenticated
What is the model we should use? The 802.11 model? A single shared
key? What do we want to do?
By referring to .11, we mean complicated by multicast access point,
can multicast to all stations
Other media are protected from each other because they can't MC
to everyone.
But in hub this protection doesn't exist.
.11 is a star topology, while a wired hub isn't
Any station can source a frame using shared key,
packet appears to come from the network, can't tell that it didn't come
from the switch.
Would have to change switch if wanted to adopt the .11 model
Some good jokes about this
Norm - The problem for two bridges is this: Each B has end stations
hanging off of it. There are two connections between the two bridges,
for redundancy; if one goes down the other takes over. With .1x, it
matters what the addresses of the endpoints of the connection between
the bridges are. This is problematic if one of the connections goes
down and is replaced by the other - the address endpoints will be
incorrect for .1x authentication. Two possible approaches to solving
this problem. One is to teach the authenticator not to care what these
switch addresses are, the other is to change the SA, a handoff. Norm
has preference for the teaching-not-to care alternative.
Bob - setting up Multicast (MC) SAs is hard
MSec (Multicast Security) WG in IETF -does group key establishment
We should become familiar with this work.
http://ietf.org/html.charters/msec-charter.html
Two bridges and a shared medium, SA's chop up into small MC domains, 1
end station and two Bs. Puts complication in bridge and bounds
problem by limiting number of members in the group. Bs know who is in
charge
How efficient do you want MC to be?
One approach if want to keep problem small, if this only needs
to work for pt to pt, or okay if shared medium with only 2 Bs.
RSTP works this way now - if there are 3 Bs, one B doesn't participate
Dot1x uses a client server model, definite initiator and responder,
This doesn't work for what we are discussing.
We are discussing peer to peer communication.
We need a peer to peer authentication model.
There are good security protocols for peer to peer
IKE for example
Will we have digestible changes to .1x?
Bob says yes - there has been some discussion with involved people
Authentication between peers is an important change in .1x
From pairwise model, 2 devices on link, to multiple peers in shared media
1 client two bridges, for example.
How will the authentication architecture look?
Bob is working on it with Paul Congdon and others
key management is part that was hard for IPSec as well
When will he have something to discuss?
Maybe by end of this week
PAR - Scope. Question from Antti
Objective is that the header be correct in terms of source MAC address.
Can't pretend to be someone else.
Can't guard against delivering to the wrong place, bridges can deliver
to the wrong place.
But can guard against someone using someone else's address as the
source
No meeting next week
11i ad hoc is next week
EFM is next week also
no meeting next week, meet July 1