[LinkSec] Proposed Scope for LinkSec PAR
For your discussion, here is a proposed scope for one PAR for LinkSec.
First, the Scope and Purpose of the existing IEEE Std. 802.10-1998:
his standard was developed to provide security in IEEE 802 Local Area
Networks (LANs) and Metropoli-tan Area Networks (MANs). The model for
providing security services is described in Clause 1. A Secure Data
Exchange (SDE) protocol for IEEE 802 LANs and MANs is defined in
Clause 2. Key management in IEEE 802 LANs and MANs is described in
Clause 3 (published separately as IEEE Std 802.10c-1998). While SDE
is independent of any key management or system management
implementation, the security services described in this standard
depend on management information provided by management entities.
Now, a proposal for a scope for a new LinkSec PAR:
Amend IEEE Std. 802.10-1998 in the following ways: 1) Modify the
Secure Data Exchange protocol to use an Ethertype encapsulation,
support replay protection, provide for a single Security Association
to connect up to all of the MACs attached to a single LAN, and support
Provider Bridges (802.1AD). 2) Modify the description of bridge usage
of 802.10 to use this single LAN Security Association. 3) Specify how
to use IEEE Std. 802.1X-2001 (and its successors) to perform Secure Key
Management.
Brief justification and/or discussion starter:
a. The suggestion is to amend 802.10-1998, as it has a lot of good
stuff.
b. Three parts to the scope: encapsulation (SDE protocol), the
description (not specification) of how bridges use it, and
specifying how to apply 802.1X to the problem of key exchange.
c. This PAR does not cover the changes to 802.1X required to support
the new LinkSec document; that would be a separate PAR.
d. Within the SDE protocol, certain deficiencies need to be addressed:
1. The LLC encapsulation now used cannot support giant frames, and
support for giant frames is needed. Therefore, we need EtherType.
2. The current header format, I believe, precludes adding a sequence
number to each data frame, which is required for replay protection.
3. The current SDE requires unicast frames to use an Individual SAID,
and multicast frames to use a Group SAID. Group SAIDs are an
IEEE-managed address space. This seems to preclude, for example,
a single security association between two bridges that encrypts
every frame exchanged between them.
4. There may be some issues with the scope of SAIDs and Provider
Bridges.
-- Norm