[LinkSec] UPDATED Notes from Teleconf 5/20/03
This is an updated version of the notes- the first draft was duplicated
and had (more) errors.
Allyn
----
Folks,
This was a fairly long meeting and I attempted to capture the full
conversation - feel free to clarify any garbled points.
A summary of the important points precedes the more detailed notes.
============================================================
5/20/03 LinkSec Meeting
Dolors Sala, chair, dolors@ieee.org
Allyn Romanow, notes, allyn@cisco.com
Attendees:
Joshua Zhao, David Nelson, Dennis Volcano, Mick Seaman,
Antti Pietilainen, Dan Romanescu, Dolors Sala, Ken Alonge, Onn Haren,
Norm Finn, Renee Struik, Mani Mahalingam, Tom Dineen, Allyn Romanow
Summary
-------
Discussion of PAR - Norm and Mick proposals
Went over Mick's proposal of scope in detail (sent 5/19/03).
Anonymity is impossible to provide, since traffic analysis can provide
information through which provider and subscriber can be deduced.
Integrity provided for the data origin, producing the Secure
Frame Format SFF; and confidentiality is provided for the data, the
MAC SDU. Control Frames won't have confidentiality, but different MACs
will be treated as desired by appropriate working groups.
Replay protection is in-scope, though its importance isn't decided yet.
Agreement that can't depend on in-order sequence delivery, needs to be
"connectionless" in that sense
Important that the Secure Frame Format SFF does not provide any higher
layer services.
LinkSec group may create multiple PARs for different services for
which there need to be standards. This is secure data transport only
and there will be other PARs to deal with key management and dot1x,
and any other development, and changes to standards that may be needed.
There was a general consensus to accept Mick's scope as a starting
point. Posted to list on 5/20/03 by both Mick and Dolors. This PAR
will be a new 802.1 task group, for example, 802.1AE.
The current work item is for everyone to draft their own 5 criteria,
post it to mailing list for discussion on the list and in the teleconf
next week.
======================================================================
Discussion of PAR - Norm and Mick proposals
Mick - working on PAR is very important
Hopes we will complete it before working on any specific pieces, such
as key management
One thing that gets in way of security is that you can't really
prevent traffic analysis
Thus, non-confidential fields may as well be in clear
This will help with network management without hindering the purpose of the
standard
Any of required Link Layer fields could be in clear
Needs SAID or equivalent to verify the origin where the frame was secured
It uniquely id's who is wrappng up the frame
Difficult to have anonymity, too many ways to find things out
EPON - is anonymity a requirement for subscriber/provider relationship?
If media is shared, how can you have anonymity?
In PON logical link ID, obscures the MAC address
Mick and Dave- don't think you can prevent people knowing who is sending to
whom on the EPON. Even without visibility of MAC address, there's enough
other info available to deduce.
Antti doesn't agree
Disagreement
Traffic analysis techniques will disclose who's talking with whom
Mick's proposal -
Integrity for data origin
Confidentiality - content of the PDU only
SCOPE -
Secure Frame Format SFF - how frames are secured on the media
Confidentiality of MAC SDU
Scope of confidentiality is the transported MAC data
Doesn't extend to DA or tags or preceding information that may be
defined by a service
Definitions are as in .10
Identity is applied to the entity securing the frame, the entity making the SFF
When frame is relayed, you know who has done the security transformation.
Important for network diagnostics
Origination identification - like an SAID.
That is to say, data origin identification combines identification of
the key in use as well as the entity that secured the frame.
Or, it may be that you want to separate these two. There are
implications for the size of the SAID, whether or not you combine the
two functions.
Unicast, multicast, and broadcast are included
Scope does not say explicitly single hop, leaving room for extension.
Secure association (SA) between MAC layer entities
MAC internal sub-layer service or MAC enhanced sub-layer service
Can use in an end station
Attached to an individual LAN, as in dot1D, implementing 802.3, 802.5, as
distinct from a bridged network
We could change scope
We could accommodate going through a dumb bridge
Design of frame format - Mick doesn't want to put something in it which will
be unused if multihop doesn't work out, because that leads to having a
testing and exposure problem
Could accommodate Source Address, DA, relaying, by placement of
security tag in the frame.
Includes a number of things of interest here,
Frames secured and relayed - by bridges, by VLAN bridges
Confidentiality preserved
Know what entity in the network did the securing
Connectionless?? what did that mean in Mick's PAR?
Connectionless integrity - meaning not rely on connection setup
Can't assume ordering of frames
Out of order frames can be problematic for some crypto algs.
Can confidentiality depend on ordering?
Ethernet delivers out-of-order frames
We shouldn't depend on in-order delivery
Implications for the design of replay detection, confidentiality and
identity
Would scope be hurt if took out the word connectionless?
Doesn't want to depend on an ordered sequencing
Each frame depends on itself. Can't rely for it's confidentiality on
fact that other frames are there.
Connectionless service is impt. but has implications for what crypto
technologies can be used.
Two endpoints, or can have multiple stations, with SAs coming and
going, must know when can flush SAs, if no hint from connections, have
to provide this signaling by some other means,
but not at this layer
Normally an SA would have a management protocol for setting up,
maintaining, and tearing down. Mick wants this out of band - without
relationship to the timing of relaying SDUs.
The secure frame format shouldn't provide any of these higher layer
services. All key management needs to done at a higher layer.
At this layer, we may impose some requirements on key management, but
we will not do it at this level.
LinkSec group may do another PAR which will focus on key management.
This is secure data transport only and there will be other PARs to
deal with key management and dot1x, and any other development and
changes to standards that may be needed.
Replay protection -
Mick thinks we shouldn't have it at this level. He finds argument for
replay protection is weak and he doesn't want to add complexity by
putting it in at this layer
However, if the group thinks it is a vital objective, then he thinks
it needs to be done in this PAR.
Replay is within the scope, but perhaps it's not important - Mick
thinks not, but that's his opinion. Replay will be addressed within
the scope of the group.
There is general agreement that replay protection is in-scope for the group.
Joshua- with respect to priority, access control is more impt. than
confidentiality.
Replay, he thinks is very important
Mick agrees that frame shouldn't be able to be "replayed" into other ports
Securing frames between MAC internal sublayers and between MAC enhanced
internal sublayers would defend against the same frames being
transported between two other entities
Dave Nelson - in connectionless datagram environment, replay has no meaning
Only has meaning at a higher level where there is a threat model
If it's a credential or something that gets some service, can be very impt.
What do you want to guarantee to the higher layer?
Guarantee where frame came from, that it is the one sent, not another
Then have to include in the scope encryption alg. as well as key distribution
Do we want this standard to prohibit replay?
.10 didn't support replay protection
They were looking at wired LANs only, felt there was no need.
Control Frames-
Sub MAC layer frames also were not protected, .10 situated between MAC and LLC.
Should be clear that Mick's scope also doesn't protect sub frames,
only MAC data SDUs.
Architecture - comprises two parts
1- key labeling for MAC stack, delineates portion of frame for confidentiality
2- encryption part
Apply transform to frame on other side of MAC internal sublayer
Delineate portions of the frame, any number of link layer headers,
before go into the confidentiality
Don't encrypt at the bottom
Do PAUSE frames get encrypted?
This is something for 802.3 to decide
802.3 stack is an onion- many layers
Mick has a scheme so that PAUSE frames don't need to be encrypted
PAUSE frames are beneath you
Brings up issues of OAM and what layer it should be at
Antti says control frames should be encrypted
Mick - says doesn't want to extend scope to include all types of MAC layers
then, exclude all management frames?
depends on where in the stack the management frame is located
Mick - management frames should be sent using mechanisms that make them look
like ordinary user data. They should use services of the stack
EPON has a lot of messages for determining who can speak for how long,
They are MAC control frames, look like PAUSE frames
Techniques in this PAR would apply, but we have a chicken and egg problem
Which is first establishing key, or control frame? - startup is a problem
Mick feels this needs to be dealt with in 802.3ah.
Someone has an idea how this should work - ONU registers in
unprotected mode, establish SA, de-regisister, then re-register
and then you are in secure mode. This is an 802.3ah issue.
Is it reasonable to authenticate, provide integrity without confidentiality,
for control frames?
That's okay
Dolors - previously we had thought MAC control frames would be decided
later, but Mick's PAR suggests the decision on how to treat them will be now
Mick - would do two classes of frames. Some that behave as user data
and some that must be considered special to the functioning of the
MAC. Then some configuration of the MAC can be considered as an
application running over the MAC, and make use of its services. One
should define the smallest possible number of frames and processes
that are to be the bootstrapping procedure. Can use LinkSec for
the user data type of frames. We should minimize the other type of frames.
Whittle down a problem to the smallest hardest core.
It is not worthwhile to consider whether we can treat all of management, the
interesting thing is what needs to be considered a control frame, or
what exactly is management - only stuff you absolutely are unable to
can't put elsewhere.
Bootstrap procedure set needs to be as small as possible. The rest of
procedures are treated as general purpose.
separate PAR - in 802.3 to integrate LinkSec into EPON application
Mick -how many keys is a receiver using at one time?
Nearest neighbor pt to pt connections
Usually more than one key, modest size set
Important to get early sight of
Norm is comfortable with Mick's proposal as a starting point
Mick will do a couple of slides, and boiler plate info
We need to think of 5 criteria
Everyone should think of what we want to say on 5 criteria
It may take a lot of time to sort through different ideas and converge
Consensus to move forward on Mick's scope proposal - meaning that this
part (PAR) of LinkSec will be a separate workgroup in 802.1, say,
802.1AE, for example
For the teleconf next week, everyone put in their two cents for the 5
criteria. Post to the mailing list and we will discuss next week.