[LinkSec] Meeting notes 12/3
12/3 Link Security ECSG Meeting Notes
Taken by Allyn Romanow, allyn@cisco.com
(comments on the notes welcome - are they too detailed? easy/hard to
follow? etc.-send me email if you have a suggestion)
First meeting
attendees: Dorlors Sala, David Halasz, Mick Seaman, Dan Romascanu,
Antti Pietilainen, Ron Housley, Bob Gaglianello, Allyn Romanow
Allyn will be the note taker. Informal notes, people can add detail
about what they have said, if they wish.
Details of how to meet and work together:
Decided to meet Tuesday at 2 ET for one hour.
Tentative time, Dolors will check with those not on the call.
Discuss technical work that needs to be done
March is the plenary, the PAR needs to be ready
working from Dolors email ..
The agenda for the meeting is to work on the charter of the SG:
> 1. Evaluate link security architecture issues with the objective
> of identifying the broader scope that can be common to
> all MAC solutions
>
> 2. Develop a PAR and 5 Criteria for a new standard for
> link security that can be applied to IEEE 802 networks,
> and in particular to 802.3 networks
>
> 3. Make a recommendation on the placement of the
> project within IEEE 802 and/or existing working groups
>
> Contributions on the following topics are encouraged:
>
> 1. General Requirements
> - Target scenarios
> - General definition of security for 802 networks
> - Backwards compatibility requirements
> - Summary of 802.10, 802.11, 802.15, 802.16 Requirements
> 2. Threat model
> - Proposed Ethernet Threat model
> - Summary of 802.10, 802.11, 802.15, 802.16 Threat model
> 3. General framework
> - Security architecture proposals
> - Evaluation studies of existing security architectures
> - Layer model Proposals
> - Proposals of MAC independent functionality
> 4. MAC specific
> - Proposals for ethernet dependent functionality
> 5. PAR and 5 Criteria
Mick Seaman
Great to have this outline of work to do
His primary concern is that the work be relevant. 802.10 turned
out not to be used because it wasn't very relevant.
802.10 specifies security between pair of communicating stations, which is
covered by a higher leayer, by, for example, IPSsec
The main challenge is to make it relevant- has been missed before
The concern of relevancy spreads over all the work items in Dolors list
Need to identify risks
Allyn - would relevancy fall out of a proper risk analysis?
Mick - not really. It is possible to do threat analysis and still miss
the point.
link layer solutions, have firewall capability, create boundaries
between parts of the network
when get onto a network, it needs to be easy to pick up protocols, to get
started
This is quite different than a model of communication between 2 end-stations
Secure different parts of the network from each other -
.1x is different than what IPSec offers
David Halasz
usage scenarios tend to make things clear
where people see it being used
agreed
Dolors
how can we distinguish how general vs how specific our scope?
how can we balance these?
Mick - has a model in mind
3-party model- 3-party firewall-type security model
extension of .1x in direction that .11 has taken
supplicant accesses resources thru a point or set of points, controlled by
.1x
Protect one part of the network from another part of the network
map this model to EPON
Bob Moskowitz - has been thinking of authentication of parties to
the network, Needham-Schroeder.
smooth handoff between media types
what is nature of the network? of the authentication services?
connecting using different MAC types as you move around, handoffs
between types of connections, wired and wireless
Mick - We don't want something so general that the market can produce
something more specific alot more easily
Bob - What defines the network?
what's authenticating?
what authorizations may it have?
access net thru point of connection to the network, someone decides
who gets them
Mick - 3 sets of parties
the 3 parties are: network attachment- it needs to know who gets on
the net; the network owner- provides/owns an authentication
service; supplicant - the party that wants to attach
Build up from a simple model, adding complexity
first assume all parties are wired together, so know everthing,
successively break down the security, introducing vulnerabilities
Dolors
architecture model
agree on a single model?
what do we need to identify
write down the model with the variances and nuances
Bob willing to work with Mick
Mick presentation before the Vancouver mtg.
How does this meeting dovetail with the .1 meeting? For people who
want to be in both. Mick says will have to figure out how to avoid
conflicts.
Reason there was an upsurge of interest by .1 group- they considered
what happened to .10 before.
If we adopt 3 party model, network access point provides a form of
bridging, so has to be fit into .1 already. Make sure we have something
that is relevant.
Russ- A significant part of .10 was built on top of
Needham-Schroeder. Key management needs to be completely re-vamped.
Bob - look at state machine to see how authentication works
Russ - there is no state machine for .10, it wasn't one of the requirements
What do we want to borrow from .10?
are there general methods that .10 uses that we can import?
Mick - In our objectives, all types of events that can occur and how
to do the implementations need to be spelled out so taht someone who does
not know security can implement it.
Antti- Usage scenarios- needed in detail, not just abstract 3 parties.
Usage scenarios are better than a vague description
Mick - distinction between types of solutions, some focussed toward a
PC attached to a network, running a codebase, runs the same code no
matter what kind of net it's trying to access. In the other model, the
access point is a small embedded device, for example, stuck in the
ground, as for metro, put minimum code in there.
these are two very different access devices.
Mick will prepare something in writing and send it on the mailing list
before before next meeting.
Antti- People should think of real usages. produce usage
scenarios, where there is needed additional security more than what we
have now. For every MAC that we are going to produce a solution, we need
a scenario. If we don't have a scenario for a MAC, we don't do
security for that MAC.
Scope needs to be clarified before deciding which MACs we are going to
address.
Architecture model. Mick and Bob working on.
Russ - How we should approach the key management? it's the hardest part
to get right in the architecture and implementation.
3 party architecture model, has a relationship with key management.
patents have expired since .10 was done. All 2-party was under patent
at that time.
Now, the range of possible decisions is greater.
Is three-party really the best model?
What legacy that you regret will be built by using 3 party rather than 2-party?
don't know without scenarios.
build a pairwise relationship between 2 parties, does third party help
or hinder?
scenarios - EPON
home scenario - multiple connections from different security domains
into the home
Antti will produce EPON scenario
Summary- for Vancouver meeting we need:
scenarios,
arch model
key management
Is key mgmt higher level or link level? need a complete specification
of at least one working solution.
Russ- This is why .10 had a funky charter - in order to include writing
application protocols
This is one reason why .10 may be useful vehicle for the work now,
because of it's charter
People should advertise the call for scenarios
suggestions: if we don't have someone to advocate a scenario, we
shouldn't worry about it till they show up.
minutes to be sent on 12/4 to reflector