[LinkSec] Proposed Scope for a LinkSec PAR (Secure Frame Format)
The following proposed PAR scope and purpose is a friendly, at least in
spirit, alternative to that proposed by Norm Finn to amend 802.10-1998. A
summary of my reasons for proposing this alternative PAR follows the
proposed scope and purpose under the heading 'Rationale for New Standard'.
*12. Scope of Proposed Project
[Projected output including technical boundaries. REVISED STANDARDS -
Projected output including the scope of the original standard, amendments
and additions. Please be brief (less than 5 lines).]
To define a secure frame format to ensure the connectionless confidentiality
of MAC Service Data Units (MSDUs) and to ensure data origin identification
and the connectionless integrity of the MAC frames that convey these MSDUs
using a secure association between MAC layer entities providing the MAC
Internal Sublayer Service (-1-) or the MAC Enhanced Internal Sublayer
Service (-2-). This proposed standard will not include key management but
will make use of other projects to establish the secure association.
References: -1- IEEE Std 802.1D, -2- IEEE Std 802.1Q.
*13. Purpose of Proposed Project:
[Intended users and user benefits. REVISION STANDARDS - Purpose of the
original standard and reason for the standard's revision. Please be brief
(less than 5 lines).]
This standard will allow secure communication over publicly accessible LAN
media, and allow the use of -3-, already widespread and supported by
multiple vendors, in additional applications. References -3- IEEE Std
802.1X.
Rationale for a New Standard:
A new standard is proposed (referred to as SFF below), instead of a revision
of 802.10-1998 (referred to as .10 below), because of the very extensive
changes required to .10 to adjust to this different scope and purpose, and
the small amount of actual text from .10 that would make its way into the
proposed project:
1. SFF needs to provide integrity for the MAC destination and source
addresses. The amount of casual mischief that can be caused at a distance in
a public network is otherwise great. SFF should not replicate the MAC DA &
SA in the enciphered and integrity checked portion of the MAC frame, apart
from being more implementation work, this is just a potential source of
additional errors or non-standard extension (when they don't match the clear
header copies what does an implementation do?). Instead the integrity check
needs to include MAC DA & SA (as it very well can do, but is not specified
in .10). This requires a complete revision to the 'architecture' and
positioning of the SFF function from that presented in .10.
2. SFF requires data origin identification (that is to say identification of
the system that includes the SFF TAG, performs encryption, and add the
integrity check), since it cannot be assumed that this is the SA of the
frame. In group key situations at least this cannot (otherwise is somewhat
restrictive) be implicit in a SAID of less than 48 bits +, and anyway not
being explicit in security protocols is a prime cause of weaknesses.
3. If SFF is ever going to support anything but nearest neighbor/single hop
interaction (there seems to be support for 'extensibility' in this
direction, perhaps we'll discover why it is too hard) then .1Q tags carried
in the frame need also to be in the clear (or perhaps some of them do if the
frame contains more than one) and who is to say that there will not be other
future protocol developments that will require additions to the clear
portion of a frame carried on a secure association.
4. SFF Group SAIDs have to be allocated without requiring a new registration
authority (unless some overwhelming argument can be made) and without
requiring every customer organization to register with the IEEE. So they
need to structured very differently to .10 and may be somewhat longer, 48
bits plus 16 being an obvious if not the best approach.
5. SFF needs to use an Ethertype (and the SNAP SAP encoding of that
Ethertype on media that do not support native Ethertypes), otherwise the
standard will not be used because of industry needs to develop an Ethertype
format for use in those circumstances where extended frames are desirable.
SFF needs to explicitly address the effects of the minimum frame size on
conversions (adding and removing SFF functions) as did .1Q.
6. The MDF facility, an opportunity for a vendor to include whatever
proprietary information wished under the guise of standards adherence needs
to be expunged from the document.
7. The fragmentation option needs to go, it has no place at this layer, and
will not find any deployment.
Surveying 802.10-1998 I find that it contains 110 pages, 105 when the IEEE
boiler plate and the autogenerated contents list is removed. Of these
pages:
8 pages of Clause 1 contain nothing substantive that will not change, apart
from the references and general definitions which are quite generic and not
specific to .10, these can be bulk copied across.
47 out of 54 pages of Clause 2 appear to need total replacement (half page
granularity used in counting through), apart from PDU format specific items
most of this is accounted for by the very complete description of the
management framework (802.1B etc.).
Clauses 3 and 4 only occupy half a page of general sentiment.
Annex 2A is an informative Annex with quite a lot of history, some useful
generic observations, but nothing of particular technical depth that needs
saving.
Annex 2B (informative) is very specific to the exact PDU format of .10,
which will need extensive revision even if I am not correct in the majority
of my points above.
Annex 2C (informative) is SDE and .10 group development specific history.
Annex 2D (informative) is an architectural discussion that needs completely
redoing, and most removing, it is in support of the architectural placement,
which is weak and needs revision for our use.
Annex 2E (normative) is about fragmentation, and simply needs to*be*removed.
Annex 2F (normative) is about ASN.1 encodings for management, no longer
required.
Annex 2G (normative) is about GDMO arcs for management, I believe this is no
longer required, in any case not core expertise for this document.
Annex 2H (informative) is format specific and will need completely redoing,
a set of observations, not deeply technical.
Annexes 2I, 2J, 2K (all informative) are interesting and detailed matter on
security labels, I can't determine how they would apply going forward yet
(12 pages).
Annex 2L is the PICS, which will require complete redoing given the
necessary scope of the changes.
In summary I found 19 pages of carefully constructed technical detail that
may survive (12 in informative Annexes), about a dozen pages that could be
simply lifted into any other closely related standard (like SFF), and the
rest that will probably be discarded.
Starting any project by setting out to sift through and trying to find value
in a existing standard that is 80% or more not on target strikes me as a
very long and arduous road to pursue, and one that will be intercepted even
if we start down it. The considerable intellectual value in .10 is in one or
two quite crisply capsulated notions, like the SAID, there is no reason that
existing terminology and thought should not be largely preserved around
these and the credit given to their originators (including the .10 original
voters for historic reference in the boiler plate might be appropriate.
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Norman
Finn
Sent: Tuesday, May 06, 2003 12:27 PM
To: LinkSec
Subject: [LinkSec] Proposed Scope for LinkSec PAR [resend from 22 April]
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