RE: [LinkSec] comments on scope of effort
Dennis,
Of course it is important to understand the threats, this is just part of
the standarrd security lecture "First you have to understand your threats
..." unfortunately the lecture has been the same for the last 20 years (and
probably much longer), so it alone didn't get us anywhere (or rather it got
us just where we are today).
After that I part company with your analysis "each of the working groups an
design and implement solutions that meet the reqts but are tailored to
exploit properties that are unique to their network architectures". We don't
really have a network architecture per working group, they largely specify
MACs which are then connected by bridges (a .11 access point is a funny sort
of bridge, IMHO) and attached to by PCs (and other devices) that, if the
solution for any MAC other than 802.3 is to be viable, have a large amount
in common with how they treat MACs of different types, probably with largely
transparent roaming across a number of the types. Moreover solutions have
to work with networks that comprise MACs of different types (Embedded
devices, or "silicon roaches", have a different set of cost and technology
drivers which means that the architecture has a challenge of not imposing
processing loads on links of certain MAC characteristics).
Howvever I certainly wouldn't want to discourage you from making forward
progress with your threat analysis. Having a number of people do real work
and then selecting from the best that emerges is often a better strategy
when there is a very wide range of perspectives and backgrounds than having
a larger number discuss what work should be done by others who don't share
their views.
Mick
-----Original Message-----
From: Dennis Volpano [mailto:volpano@cranitesystems.net]
Sent: Wednesday, December 04, 2002 7:16 PM
To: Mick Seaman
Cc: stds-802-linksec@ieee.org
Subject: RE: [LinkSec] comments on scope of effort
Mick,
Unfortunately I was unable to take part in the conference call
so my comments are based on the minutes emailed to the reflector.
It's important to identify security reqts and your threat model. You
agree with this, yes? 802.11 TGi did not do this which led to a lot of
confusion and questions of the sort "do we need to treat this threat?"
Now the question is whether the group should do more. I don't think so
because each of the working groups can design and implement solutions
that meet the reqts but are tailored to exploit properties that are unique
to their network architectures. This is where "state machines" are
specified. However, I can imagine some reqts even being formulated as
state machines if this is preferable.
The working groups need concrete L2 security properties they must preserve
in their designs. Fundamental questions need to be answered. This is
what the group should address. It's not a trivial task and it's very
concrete. I and others don't believe it would be a waste of time.
Dennis
On Wed, 4 Dec 2002, Mick Seaman wrote:
>
> Dennis,
>
> I don't think anyone on the call was talking about designing or
redesigning
> "some new 3 party security model". The discussion on this starts from
> examining what 802.1X was and is becoming to address .11 requirements, and
> what that trajectory and intervening points could offer for other
> developments (like .3ah).
>
> Separately if all this group produces are a set of abstracted
requirements,
> I and others believe it would be a waste of time. For security
> implementation to become real on 802 networks it needs real definite
> implementation oriented expression, like answering the question "what
state
> machines do I implement in my access point?" for implementors whose
primary
> focus is not security design. Protocols get implemented when someone
offers
> up code or state machines that can be transliterated into code (or gates).
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Dennis
> Volpano
> Sent: Wednesday, December 04, 2002 2:15 PM
> To: stds-802-linksec@ieee.org
> Subject: [LinkSec] comments on scope of effort
>
>
>
>
> Having thought a lot about link security (802.11 voting member) and after
> attending the last three 802.1 meetings, I'd like to share my perspective
> on the linksec ECSG, specifically its scope.
>
> Let me begin with a brief bio as an introduction of myself.
>
> BRIEF BIO
>
> Associate Professor of Computer Science, Naval Postgraduate School.
> Chief Scientist, Cranite Systems Inc.
>
> Research interests.
> Proving security protocols correct, develop new forms of computational
> reductions for proving the strength of security protcols, type systems
> and logical systems for reasoning about security. Work funded by ARPA
> and the NSF.
>
> General Chair of the 16th and 17th IEEE Computer Security Foundations
> Workshops in 2003 and 2004.
>
> SCOPE of the LINKSEC GROUP
>
> A security model or protocols for security are developed out of
> a need to meet a set of security reqts. I propose that this new
> group focus on producing a reqts document for 802 as NIST has done for
> crypto modules with FIPS 140-2. Forget about trying to design some
> new security model (3 party vs 2 party etc) because it will invariably
> not fit within some useful network model in the future. As a group, we
> just need to articulate our security reqts for the link layer. If the
> group ever needs to standarize a "security solution", it should be minimal
> such as identifying bits, preamble or otherwise, reserved for security
> information, not adoption of protocols for key mgmt or authentication
> for instance. There will be plenty of room for vendors to tweak security
> their way but all will have to meet the 802 reqts to be linksec compliant.
>
> Here are some examples of reqts and issues that will lead to reqts. Keep
> in mind that this is only a first attempt at a reqts set.
>
> 1) Is link security really what Norm Finn calls a bundle of secure
> point-to-point links, or is it group security? I would argue that
> group security is what you want at L2 with point-to-point security
> provided at L3 or above. This protects spanning tree, arp, gvrp and
> any other group-address-based L2 protocols. Group security is more
> manageable and is a natural extension of 802.1Q with the obvious
> identification of a group with a VLAN. Since we cannot expect all hosts
> to be security smart, we must assume stupid LAN segments will exist. 1Q
> already has a notion of stupid segment called untagged segments. It seems
> to me that EPON and RPR could benefit from an extension of 1Q.
>
> 2) When a station leaves a group, it should be possible to prevent it
> from participating in any L2 protocol between remaining members of the
> group. Furthermore, it should be possible to prevent the station from
> interpreting frames between remaining members. This reqt is needed for
> at least public-space WLAN providers but it will not be mandatory since
> it is of limited use in other trust models (e.g. Enterprise).
>
> 3) A pluggable MAC service primitive (ala PAM) exists for sending and
> receiving frames that carry an auth header and encapsulated payload.
>
> 4) An abstract class exists for a security association, borrowing
> attributes from 802.10
>
> 5) A pluggable MAC service primitive exists for mapping all 802.1v VLAN
> classifications and some other protocols to a security association which
> may be the null association.
>
> 6) How should replay be treated? Should it be required that a port be
> able to detect a data frame already received at the same port, or at
> another port, perhaps on a different bridge?
>
> Regards,
> Dennis Volpano
>
>
>