Re: [LinkSec] Proposed Scope for a LinkSec PAR (Secure Frame Format)
Assuming that a MAC service entity aims to protect against replayed or
even relayed frames, as I think it should, I'm trying to understand the
different levels of effort required to provide the protection.
If a security association (SA) is between exactly two MAC service entities
then any frame belonging to the SA could not be replayed successfully over
a link with a different SA, assuming a cryptographic integrity code is
used. The scope of replay detection then is the scope of the SA. If the
SA scope is link local, then replay detection is also link local (confined
to the entities on that link).
A group SA can be shared by more than two MAC service entities, in which
case the scope of the SA may include multiple links. Thus the scope of
replay detection may grow to multiple links, perhaps spanning different
bridges. It seems that this expanded scope must also be supported if
the notion of a group SA remains.
Dennis
On Mon, 19 May 2003, Mick Seaman wrote:
>
>
> 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
>
>