[LinkSec] Fw: Proposed Scope for a LinkSec PAR (Secure Frame Format)
The message below is from Mick Seaman. The original message bounced due to
the expression "to be removed". I have deleted this expression from the
filter so it can pass through. Please review and comment Mick's recommended
PAR for a new standard.
----- Original Message -----
<....>
> From: "Mick Seaman" <mick_seaman@ieee.org>
> To: "'LinkSec'" <stds-802-linksec@ieee.org>
> Subject: Proposed Scope for a LinkSec PAR (Secure Frame Format)
> Date: Sun, 18 May 2003 12:44:35 -0700
>
> 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
>
>