[LinkSec] Telconf Notes 5/6/03
Sorry, I overlooked sending these after the last meeting-
Summary at the top
Allyn
=================================
5/6/03
Dolors Sala, chair, dolors@ieee.org
Allyn Romanow, notes, allyn@cisco.com
Summary:
Rene went through his slides, available on mailing list.
Discussion of scope - whether it is end to end, protecting user data,
or hop by hop, providing separation of customer traffic, and providing
protection outside of provider's domain. General consensus on scope to
be limited to hop by hop.
No meeting next week, resume on 5/20. We will discuss Norm's proposal
for PAR, and mailing list discussion of it.
=============
Attendees:
Rene Struik, Norm Finn, Ken Alonge, DJ Johnston, Marcus Leech, David
Nelson. Dolors Tom Dineen, Antti Pietilainen
Rene went over slides, to be sent on mailing list
Do we need to insist that we encrypt data?
It is a negotiation between sender and receiver
Specify policies
802, switched, mixed types of networks, type of network is relevant to
the type of network security
This is end to end security
We are doing hop to hop, link layer security,
It is all about administrators making decisions varying by links, e.g.,
if in a secure room treated differently than in an uncontrolled environment
We're not here to tackle end to end security, that is an L3 issue
We do MAC address to MAC address,
What's the point of link layer security? The application cares about end to end
Disagreee - use link level security for services that are not end to
end applicaton data security. In particular, to separate customer traffic,
or if my traffic is going to areas outside my control, want L2 protection
If multihop, with every node encrypt and decrypt, then every node is
trusted
Norm -May do security to protect network infrastructure, not to protect user
data, maybe used to secure network from intruders rather than protect user data
Not for protecting credit cards
Limit to protection of network
application level security under the domain of applications
Within an enterprise, can use link security to protect user data, end
to end, but not as soon as go outside enterprise
Link layer hop by hop security and not the only tool in the toolbox;
it is one of many
Be aware of rest, know where fit in, but don't take on everything
Agreement on scope and practicality to focus on link layer, hop by hop
This is what is missing in the total security picture
What kind of services provide? Need to provide some freedom
Local regulation
Security policies and security associations
We made need several protocols
Markets have different security needs
e.g., some manufacturers in 802.11 can't do PKI encryption
Always choices in encryption algs., ranging from no encryption to very
high level of encryption
Framework in which plug in your own crypto alg.- 802.11i did this
We have another parameter that wasn't in 802.10 - we want to run at line
speed, 1 Gbs, or 10Gbs
General agreement
At least one version of security we do must support linespeed operation
Have to have electable crypto
You can only put one encryption alg. in asic, so we will need to pick one
Need to standardize encryption of data stream, needs to be interoperable
Can there be link level security that provides end to end security?
Receive at MAC layer at other end
Such a thing is provided by 802.10, and not used
Doesn't know that other end is 802.10
Can't go thru router, not usable
Everyone needs to read 802.10, it is mandatory for doing this work.
There is a lot of wisdom in the document
All protocols we specify need to be confined up to and not including FCS
Link layer encaps minus CRC, must not include preamble
pseudowire doesn't have preamble
MAC service interface rather than physical interface, 802.10 got it right
EPON in principle one hop, proposed to encrypt CRC
Getting into mechanisms before definition of the problem
Let's focus back on threat model.
How can we get intiital threat model?
What is feedback for Rene?
Norm asks people to respond to his proposed PAR
802.1aa - modifications to dot1x
Authentication server in device doing authentication
Punts authentication alg.
Not a rich collection in IETF, not fill everyone's needs
Will we need a second PAR?
Lean implementation? Why offer up multiple security policies?
One policy not going to meet everyone's requirements
If have different policies, and need to use 802.1x with 20k lines of
code, it won't work for everything.
Not sure that a device with less than 20k of code will allow any
security mechanism
Low rate wireless is a very constrained environment
Someone did implementation of AES counter mode and some other
functions, 15k lines of code
Low rate wants 6k lines for hardware,
Including public or symmetric key exchange
What's lower bound on requirement? codesize and h/w cost
Broadcom 2.4 Gbs AES CBC
Counter mode pipelines
Strive for low cost, low power implementation
Marcus- doesn't want to drive standard on basis of least capable device.
That's why we'll need a suite of algs.
We have 10 GE, and highly constrained environments, plus differing
regulatory envs., they differ radically worldwide
Agreement that algs. will be chosen from widely used ones
FIPS approved
For requirements, put in something about various niche requirements
Next meeting- 5/20/03
Discuss PAR
Also discuss on email,
Next week is 802.11 interim, and EFM in Korea, Norm also gone
so next week mtg off. 2 weeks talk about PAR 5/20
Goal - document should be sent a certain amount of time before teleconf
Send out an advisory 24 hours in advance