[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