[LinkSec] Notes from meeting 12/10/02
NOTE: there's a quick synopsis at the end
================================
12/10 ECSG Link Security
Dolors Sala, Chair, dolors@ieee.org
notes by Allyn Romanow, allyn@cisco.com
Mick Seaman, Marcus Leech, Dennis Volpano, Michael Wright, Peter
Boucher, Bob Moskowitz, Dave Nelson, Jesse Walker, Areg Alimian,
Allyn Romanow,Dan Romascanu, Paul Lambert,Russ Housley, Dolors Sala,
Mani Mahalingam (sorry if i left anyone off)
teleconf only allows 12, Dolors and others couldn't get on, started late at
2:30 ET
Dolors
discuss contributions for Vancouver
there are 3 so far - Mick, Dennis, Paul
Feedback on Dennis contribution
update roadmap
Dennis - 2 phased approach
first phase - leverage 802.1x and 802.10- can accomplish quickly,
point to point
2nd phase more difficult - group security, protect all unicast traffic
authenticate to join group, trust all memebers in group, protects L2
protocols - Spanning Tree, ARP
he's gotten feedback, seems that biggest problem people have is with
re-keying and group rekeying when leave group
there are ways to do it in a distributed fashion
trust model, enterprise is different from a SP case
deny access, can be done asynchronously, efficiently
Marcus - uncomfortable about group shared key.
not clear on semantics of the group, what's a group for?
If he understands properly, it sounds like the same goals as IETF
MSEC, but htey are doing it further up in the stack
not clear what the usage scenario for this is
Consider a large enterprise, such as where he works, there's no
benefit from any group key management at L2,
because he doesn't trust colleagues on the same Ethernet as he is
How to define groups at L2 isn't clear
swallow a large hairball. Maybe he has misunderstood
Bob M- had issue with groups also. Many small groups, multiple access
groups, Ethernet with 2 bridges, hundreds of groups with 3 in each
group. What's the model and bounding of the model?
Marcus - Bob's example is degenerate case of a group. Network
infrastructure is not relevant to user, but user does care who he
shares key material with no better security if share key with hundreds
of colleagues
Mick - jumping to a solution. Sounds like assume every port is on
shared media segment- not the usual case, alot of access ports are
point to point. Don't assume all LANs are shared media. Lack of
relevance Need an arch that covers both shared media and point to
point
Why is point to point different than 802.1x?
.1x assumes model of what protecting, who is protected against what
there are other interesting models that 1x doesn't cover
Assumes connect and that is it, not good for handoff,
This is second order, possible to do protection for roaming in a .1x
model
Mick - beware of assumptions on roadmap that users don't want to buy
into
Marcus - corporate, user doesn't want to share keys with a bunch of hostile
people
Dennis - This is not what he proposed, he can form group in any way, do
it based on VLAN, but VLAN membership is not one to one with whom you
want to talk
Want to provide link layer integrity and authentication within the
group, for protocols that run at that layer
Privacy is another story.
Dave Nelson - Question, is your motivation to protect L2 protocols and
not those above? or, do you want to protect integrity of everything
that runs on top of L2 as well? Concern about layering, what's the
benefit of layers and layers of locked boxes?
It's no harder to address the general case
Russ(?) What's the trust model, who's the end consumer? They are the
entitites that need to be protected. L3 and above are irrelevant, if
they are running their own protection mechanisms.
only worry about L2?
We have been missing a discussion of whether upper levels consume L2 resources
.1x already solves this, doesn't it?
We are concerned about privacy and integrity which .1x doesn't address
Does what's been talked about here work well with STP?
why different?
Mick - 3 things:
1, In this case, if a message is acceptable to one, it must be
acceptable to all, shared medium, can't pass thru any state where
different participants think different things about the state
2, Also, plug and play is an important feature
3. Getting started problem, if not already running, can't distribute key,
chicken and egg problem. In this case, it is the groups you are
trying to secure, who are the ones that get the infrastructure working
STP something of a discovery protocol. chicken and egg. ongoing or
bootstapping?
Mick - Basic philosophy of design, there is no beginning of the world,
Discontinuous events can always happen, must design for this, new
participants can join, links can fail
(who?)- if STP is too hairy to protect, higher level protocols can be
protected. The problem in need of solution is L2 protocols that are
unprotected and CAN be protected (i.e., not those that can't be
protected)
What's this SG supposed to protect? Privacy and integrity for L2s
that don't have it? or a wrapper for the other layers?
802.3ah perceived as insecure by customers, need to at least solve this
problem
(Paul??) protecting traffic, privacy, integrity, nonrepudiation,
confidentiality, authentication. Feels it is an open an issue whether
.1x is applicable
Mick- Make sure no one could use shared net to attack
not just integrity, also don't want to receive unwanted packets
Marcus - .3ah as a scenario
SP cares a lot about customer to customer confidentiality and
integrity - risk of law suits in shared media
Customers care about confidentiality and integrity,
need both
Integrity- get access control and traffic isolation for free
Mick- fit in traffic separation somewhere
Dolors - need actual contribution that states agreed requirements
Dennis lead this?
Dennis agrees, will modify his presentation, incorporate comments
Dennis - his first phase is close in spriit to what's being discussed
for point to point. Need to handle both point to point and shared
access. Thought of treating shared case as phase 2, way to treat group
traffic, orthogonal to phase 1, broadcast key, or something, do
something better. How groups get organized, he is not saying, depends
on how used, how join, how configure, all work to be done
downstream. Thinks it's right framework. Chicken and egg with respect to
spanning tree
Paul -not sure if this is the right way to start, i.e., by fixing .1x
base requirement encryption, confidentiality and integrity
traffic separation easy to accomplish
key management - .1x could be made to work,
but .1x has alot of deficiencies
He wants to start with requirements
pairwise distribution, enrollment mechanisms
groups, in .11 they have their own group mechanism
objets to solutions rather than requirements
Mick - 802.1 WG has a particular history and view of the term
"requirements". When people say reqmts they are contstructing their own
model, so that their solution will work and others won't. People
tailor reqquirements for their favorite solutions, in order to gain
proprietary advantage. Requirements often stands for a proxy for
battle. So now in 802.1 they need to bring in a model of how they are
thinking, what model they have in mind that will generate a set of
requirements. It's the conceptual model that underlines and informs
the requirements, not the other way around. So in 802.1 they want to
hear what the model is.
They advocate a top down and bottom up approach.
Dolors - requirements - in advance, solutions must meet
Mick - need to iterate between requirements and solutions
model of how the requirements will be made real
e.g., as traffic separation falls out of confidentiality
Dolors - if people have material that states requirements they should
contribute them and Dennis will pull them together
send Dennis an email
Dave Nelson- wrt requirements, what about the user's golden fleece,
single sign-on? should it be considered here? We need to consider
this. Single sign-on is the dream that users have one persona that
gets them in everywhere - the bank, the computer, the club, etc. He
says it's a golden fleece, cause never attained in practice, but users
want it.
Marcus - We should do nothing to make single sign-on difficult, but we
should not spend alot of effort to make it easy. our authentication
scheme shouldn't preclude single sign-on.
Bob M. - can be a bad idea, so don't preclude it, but don't legislate it
We should avoid having a new type of credential that would screw up
single sign-on.
Consensus on this point.
Dan - we should think about plugging into existing framework, such as AAA
Dennis - Question, especially for Mick, are we trying to guard against
replay in a bridged LAN?
Mick - who's replaying for what purpose?
Marcus - can snoop an encrypted fully confidential message and replay
it, may have disasterous consequences
IPSec initially had no replay, didn't last long, realized needed
replay
Mick - the question is what are you protecting against, in a secure net, what
forms of intruder do you need to protect against? if it's a bridge
misbehaving, stopping it from replay would be tough
Marcus - protecting against malfeasance of people running network is
very difficult to do.
Russ- confused about different scenarios, until we get to them, don't think
we can have a common model
Mick - agrees, a single LAN solution that doesn't involve bridges
would be irrelevant
Russ - bridges need to be suppported in the architecture
Dennis - bridges an important part, so asked about replay, is it a threat?
what protocols are vulnerable to replay?
Russ - protection of MAC control track is part of our work, don't know
if replay is important. At the rate things are being added onto MACs,
if replay isn't important today it will be
Dennis - need to be addressed across a bridged LAN? it's hard, hope
not required.
Everyone send Dennis what they think should be in requirements
he'll do another pass, will put out on mailing list
---------
Mick's contribution
He'll introduce it now, quick highlights
Objectives:
1. Set down what many people think are obvious assumptions, but aren't stated
anywhere. Write down common assumptions.
2. What he thinks of as .1x framework, loosely-- the problem it assumes,
keep outsiders out of net, successively build in larger number of
threats into the model
Cover different infrastructures up to roaming
Paul - has a contribution, had to drop off call, sent just before the call
Dolors
Action items-
-Continue discussion of requirements
-Feedback on models, scope, how are we doing?
- Think about placement of the study group? think of for next call. where do
we want it, 802.1, executive committee?
-if we want to get PAR done, have to accomplish alot in Vancouver
-how do we want to target the Vancouver mtg.?
Dolors
PAR approval by plenary requires to be ready one month before, mid february.
march 9-14, so by feb. 9.
Mick - never seen a SG agree on a PAR at it's first meeting
Dolors - agrees
Wants to know how we want to target the vancouver mtg.
should it continue as a 802.1 SG or EC SG?
Mick - goals for Vancouver
1. Group talking together seriously with shared vision of what the formal
results should be and what the problem is, develop a sense of working together
2. Preliminary breakdown of the work, from which you can eventually
derive the PAR, how to partition the problem.
requires a serious amount of engagement, not on just the call
For a new group, coming to a shared understanding of terms and
demonstrated ability to work together is a major necessary first step.
Dolors - we need to answer the plenary about putting the SG in 802.1
Mick - should have a good handle of what parts of solution will give relevance
SG is chartered at each meeting, so the question is whether SG wants
to be in 802.1 next time
Dolors was asked to have the group consider the 802.1 offer to host
the SG. The SG will be reauthorized as a SG at END of march plenary,
so it will be authorized to run during the March plenary.
Friday is when an answer is needed to the question of SG going into 802.1
Teleconf - let Dan know if there are problems getting a higher
capacity teleconf for next time.
Dolors, how do people feel about taping the call? so that people can
listen. People agreed but didn't think it would be too useful, so it
won't be taped unless there is demand.
Materials -want a public incoming web page at the web site, in
addition to email, right now can't do it. Dolors will check and see
how it can be done. Then take out of incoming and put in the official
directory. Incoming allows rapid distribution.
==============
Quick synopsis:
Discussion of Dennis' 2 phased roadmap proposal
first phase -point to point, similar to 802.1x
second phase - groups for shared model, questions on how they work,
what they are, if they are a good idea.
Discussion of what the trust model is. Who is being protected against
what? What scenarios? What protections? Confidentiality and integrity
at L2 in addition to authentication provided by .1x.
What's unique about L2 from security perspective?
What's the goal? 802.3ah security, and something more general.
What are the scenarios, from which to derive a common model?
What are the requirements? How requirements are used and useful.
Send requirements to Dennis, he will pull them together and send them
out for discussion. What model underlies the requirements?
Single sign-on and replay protection were discussed.
Mick introduced his contribution that sets out common assumptions
Planning -
Action items- requirements; feedback on models, scope; where SG should
be; what to target at the Vancouver meeting.
Suggested goals for Vancouver meeting: shared vision of type of
results, ability to work together; partitioning of the problem