[LinkSec] Teleconf 12/17 notes
Here are notes from the Conference call today - with the usual apologies to
people whose names I mangled, and whose messages I sorely garbled. Send
corrections, suggestions to me or the list, whichever seems appropriate -
thanks, Allyn
12/17 ECSG for LINKSEC
chair Dolors Sala, dolors@ieee.org
notes Allyn Romanow, allyn@cisco.com
----------------------------
Volunteers?: Is anyone willing to help post documents to the IEEE
website? We need about 4 volunteers - people will send you
documents and you have to post the documents to the IEEE website, to
prevent large attachments on the email list. Please let Dolors know if you
volunteer. thanks-
-----------------------
A brief summary at end
------------------------
Attendees:
Mick Seaman, Allyn Romanow, Dolors Sala, Bob Mskowitz, Michael Wright, Dave
Nelson, Dan Romascanu, Peter Boucher, Joshua Vahao, Dennis Volpano, Fred
Haish, Antti Pietilainen
pre-meeting conversation: Mick and Dave
We should do a profile based on what's needed, then match 802.10 to it.
There are too many options in .10
yes problem needs to be narrowed
Too many solutions a bad thing
Security is a system design, 802 is at the MACs only
look at DOCSIS - similar problem?
yes, same concerns as EPON
prevent theft of service and protect customers from each other
Dolors - DOCSIS encaps the entire frame
put fields in front of the frame
802.16 arch is very similar to DOCSIS
no fields in clear outside?
single key upstream, multiple keys downstream, 1 SA upstream
[SA= Security Association]
Mick - each receeiver on LAN only has to decrypt under 1 key
The problem is which key should you use to decrypt? if receive frame
from upstream
headend receives all frames
several SAs, headend belongs to all
multiple multicast SAs on downstream
SA sent in clear, the rest is protected
protects one listener from another
down stream cable modems, headend uses different keys for different
cable modems
one key for me, one for each group, get the SAID in clear which says
which key to use
encrypt after the first 12 bytes of the frame, first 12 Bytes not encrypted
CRC encrypted, so if change source address or destination address,
need to change CRC
CRC is a guessing game, not a hamming distance
would cause trouble in 802.3
some people think still need hamming distance of 4
START meeting
Dolors - put summary on list
four topics
prepare material for f2f meeting
-requirements discussion - where agree and where not?
-what is authentication entity as we define the arch?
-Jesse Walker asking what's wrong with 802.10, we need a good analysis
of it, or we are in danger of making same mistake and being irrelevant
-where should work be done? David H. suggested it should go back to 802.3
if we only want to do EPON case
[note biz = business]
Start with requirements, then can see if 802.10 is relevant
Dennis - sent out outline, no feedback yet
Dave Nelson - do we need to backup and restate requirements in the
business domain?
we have been arguing about who's being authenticated etc.,
but if we are clear on biz requirements we can then translate them into
technical requirements
Mick - seconds strongly - we need to know about the system we are trying
to protect.
Is this effort meeting a business need?
Requirements in absence of biz model doesn't make sense, we are missing in this
dimension
Dolors - what exactly?
Mick - top down biz requirements
e.g., 802.3ah needs to be secure, needs a label saying "this is
secure"
[SP=Service Provider]
Dave Nelson - commonality between EPON and cable modems, biz concerns,
prevent theft of service from the SP, protect customers from each other at L2,
separate from each other, make sure that billing gets done appropriately
Mick - existing AAA repositaries can be used, it is a criterion for successful
deployment
no one wants to develop yet another policy protocol
Dolors- if we refer to Paul's initial requirements doc, is that a good
description?
Dave - that's the second layer, it says what level of confidentiality, etc.
The first level requirememts include - to protect against theft of service,
customers who want a free ride.
Provider wants to protect customers from each other, need to provide
segregation, may sue the provider.
Billing records must be appropriate and be maintained, non-repudiation
These biz requirements are from perspective of SP, to make sure that
service they offer is economically viable
How you do each of these- maps to Pauls list
Bob M.- wants to add to the requirements list
SP wants simplicity and to be able to move between media easily -
needs consistency between media.
Mick - absolutely clear from a SP viewpoint, don't want to re-do
framework and re-train people as you change the media in the last link
to the customer. That's why solution needs to be 802 wide, so won't have a
different system for each MAC type. Need to use same DB and operational
resources in core of the network.
Are Dennis and Paul's requirements at the same level? Dennis thinks they are
at same level and he has tried to incorporate Paul's list in his.
Dolors - how should we refer to these different types of requirements
for a presentation?
Agree what are top level reqmts
Mick - it's clearer to use Dave's label of business requirements
rather than to refer to them as top level.
Dolors - Dave do you want to put a note on the reflector?
Dave - I can summarize
Not sure if the 3 I've stated apply to all segments of network
Applies to Metro and SP, not enterprise and private nets
This can help us focus on what we are trying to protect
There may be different biz requirements for different sublayers,
Is there really one link layer encryption, or do we need different
ones according to market segment?
We have some disagreement on this. It would be good to agree
Mick - provider based networks, this is an area of new work in 802.1,
a lot of large organizations are like SPs,
so they have needs that are the same as conventional SPs.
?? - legal issues that a corporation can have can be similar to that
of an SP
Mick - large enterprise may want to identify with SP requirements
Dolors - okay to say we just focus on SP?
Mick - doesn't cover everything, but we can focus on it as a method of
approach, and let the other enterprise issues that are not covered bubble up.
Dave will start thread on mailing list for biz requirements.
Dennis - looking for feedback on his list, posted 12/13. how do these
requirememts map to biz requirements?
could go thru list and ask if relevant to biz requirements
association between these two levels, hasn't thought about yet
Dave - restate Dennis' list and take a swag at which biz requirements
they mandate from.
try this now, goes thru list
With respect to Dennis' list posted:
MAC control - distinction between MAC-client management/control and MAC-client
data
Under bullet Authenticated MAC-client data, authenication ID - major
disagreement, impact on scalabilty of solution
MAC client data - segments that don't want to participate in protocol, but
are considered secure
Confidential MAC-client data
We don't understand what needs to be private?
identifying privacy needed
Mick - dispute over what SAID is in frame
Depends on where can efficiently decrypt frame, e.g., a provider
backbone carrying traffic for multiple customers, customers may not
know what VLAN they are assigned to.
At what point can you look at the frame and ID reliably and at which
point you cannot.
what is being authenticated here?
There are two models - in one, users roam and use convenient machines
In the other - machines are being identified and requires security on the
machines, machines are trusted
If want heightened security, want secure machine
A biz decision as to whether human users using multiple machines are
legally responsible for what's on the machine
Dave - can only authenticate an entity that holds a key,
can't authenticate a user who has compromised their key
There may be cases for both
If provider allows retrieve email on trip, authenticate on a guest machine,
whereas at primary location, device authentication is sufficient
Mick - existing models that don't assume the user himself is
authenticated, but is authenticated by possession of the device.
For example, a one-time number device.
Dennis - there may not be one privacy ID, but could be many - is that
your point?
Mick - a biz model knows what entity needs to be authenticated
A biz model in which people wander and are responsible for the equipment they
use, might be done in two stage approach, get MAC address temporarily,
Russ suggested something along these lines.
Doesn't mean that the service is necessarily tied to a person
Dennis - continue with list
Replay- unanswered questions
Multiple 802 Mac protos - issue from Paul's list
Enrollment- he has no comment
Dave - question - on the Multiple 802 MAC protocols bullet, does it
mean that key management must be an 802 protocol?
This would be a real mistake
All key management is L3 and above. Really out of scope for this group
to define. Definitely not an 802 protocol
Mick - we get in architectural trouble when we use the architecture to
define both the scope and the packet transmission and receive
functions as well.
Would be a great mistake to assume key management done by protocol with no
addressing above LLC.
Has heard alot of discussion on how groups can't work at L2, bogus,
Can define an application protocol in support of an 802 network
Dave - this is not a turf thing, addressing in higher level,
He meant that you shouldn't define crypto and key management protocols
if you're not a card-carrying cryptographer
need to find an algorithm that has some experience behind it
Antti -802.11 and 802.16 have defined key management
Dave - .11 made more progress when they got cryptographers onboard
Antti - having cryptographers can cause some problems
Dennis - .11 is defining some key management
Dave - if you find a key management scheme that works, great, if you
can't and have to invent or modify, you up the ante of the group
significantly, and the work needs to be done by cryptography experts.
All the work for key management is done at higher levels, the L2 part is small
Dolors - security mechanism shouldn't depend on protocols riding on top
of it, it should be completely self-contained.
[this was filled in after conference by Mick, as it wasn't clear in
the notes-]
Mick - The argument has been stated that layer 2 security must not have higher
layer dependencies, since the higher layers run over layer 2 they would be
de facto compromised, and all the protocols involved in securing layer 2
(autentication, authorisation, .. key mangement) must be layer 2 protocols.
This argument is flawed because:
(1) In some cases the higher layer protocols run over a part (A) of the
network that is attached to the part that is to be secured (B), so they are
not compromised. Example .1X Authenticator to Authentication Server.
(2) The idea "a secure/secured LAN" is short for a "LAN on which some or all
of the communications has been secured from (some) attack" and doesn't
preclude some communications on the LAN being secured by mechanisms
particular to those conversations and with no other dependency on other
communication on the LAN being secured. Examples: the Otway-Rees variant of
private key Needham-Schroder, Neuman-Stubblebine.
Dolors - means we are trying to define security at level 2, so can't
depend on L3
Mick - not exactly
A L2 network may have some things on it that are secure and others
that are insecure
There is not inherently a logical recursion problem
Dave - you can meet the criterion of being self-contained if you live
with pre-shared keys, which works for small nets, where you meet
someplace and distribute keys
A key management scheme where keys are not pre-shared, but distributed
over net, needs an application layer to accomplish the secure key distribution
Peter - example on reflector, start with unsecure, establish security
that allows you to start
interface that allows you to insert keys, may be all that's needed at
L2
Mick - agrees that this solution has to be complete, otherwise it won't be
implemented
Dolors - is this a biz requirement? that it is self-contained
Dave -self-contained - the way to shoot yourself in the foot
Means and methods for self-sufficiency don't scale
Antti- need interoperable systems
Mick - completeness of specification, not the same as self-sufficiency
need to be complete, if want anyone to use standard
Self-sufficiency is a hazard
Antti - do we want to do all the job in 802 or tell ITU what to do?
Dave - design with the largest component that you can, re-use existing
technology that's applicable
Once get requirements, do a literature review and find the protocols
that do the job
Antti - where would these other protocols be defined?
Mick- in 802 start making the list, may find it's already done somewhere else
Dolors - back to Dennis' list, should this item about not requiring
non-802 protocols be left out of our requirements list?
What if a piece of the solution comes from another standards body?
Dave - find the building blocks, use a key scheme if it is well
tested, point to the standard
Dennis - too early to say if there is an off the shelf solution for key
management, should leverage proven technology as much as possible.
Mick can't assume authenication server gets accessed via L2
Dolors - any questions on DOCSIS that Antti or she can answer?
Dave - can someone who knows DOCSIS write a summary?
Dolors- there is a summary, from New Orleans meeting, comparative
analysis of link security mechanisms
2 page executive summary that Cable Labs have, she can give reference
BPI 100 pages, Baseline Privacy Interface
Antti - 802.16 has directly copied from DOCSIS. He has an executive summary of
802.16, he'll look and find security section
Dolors will send pointers out to the list
Dennis - what about being able to post to a public place on website
instead of putting documents in email?
Dolors - IEEE doesn't support anonymous FTP site
Mick - how they do it for 802.1 - complicated they mirror IEEE list with a
Cisco site, some people have passwd, they post for other people
He's not expert, someone else did it, Neil Jarvis
Using IEEE, we can name enough people 4-5 who can post docs, so won't
be a burden for one, instead of sending attachments on mailing list
issue - a large number of people, in 802.3, 300 people, would cause
too many large emails, when you are on dialup
Instead send email to one or two people who can post on website
Another idea is to use discretion on whether to send in email or use
website, according to the size of doc - if large use website, if small
send in email
Choose a number for attachment size, 802.3 has a number
EFM initially big docs, didn't pass, imposes some discipline on
presentations
Find out Howard's number and adopt that
Some WGs use a template for contributions, imposes minimum overhead,
ppt, no logos, etc.
Dennis - wants a doc for requirements, his list plus biz requirements,
go into January meeting with this doc pretty well worked out
Dolors - include additional requirements
thread of archived email on website
if attachments aren't in email it makes reading archive more difficult
Dennis - wants one point of reference, one place people can go to see
requirements,
wants a doc on the web of status in progress, including proposed model etc.
Is anyone interested in helping to post attachments?
--------------------------
Allyn's Brief Summary:
Agenda- Four topics - requirements, authentication, analysis of
802.10 - why wasn't it used?, Organizationally, where should work be done?
Meeting focused on requirements, didn't get to the other topics
We need to clearly state business requirements and derive technical
requirements from them. We are weak here.
Three business requirements are: protect provider from consumer
stealing resources, protect customers from each other so that
customers cannot sue providers, provide environment for correct
billing. All these are in behalf of the provider (sometimes enterprise
organizations are like providers with same issues).
Focus our efforts on providers and any strictly enterprise
requirements should become clear. Dave Nelson will post note on
business requirements to mailing list.
The EPON problem is similar to cable modem. We should look at
DOCSIS. Dolors will post references on mailing list.
Feedback on list of technical requirements posted by Dennis to the
mailing list, on 12/13. Dennis will post updated list to website.
Discussion of whether all the protocols used must be 802
protocols. Some aspects of security, key management in particular,
needs to be done by applications at L3 and above L7, session
layer. However, certainly a completely specified solution is required
to be successful.
Large documents will be posted on IEEE website rather than sent in
email as attachment. Please send such documents to a small group who will
have access to put them on the website. Volunteers for small group?
Will post a note with details to the mailing list when it is set up.