Re: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame Format)
Below is an initial text of the 5 criteria. Please review and suggest
improvements. For reference, I included the proposed Scope and Purpose from
Mick.
We will discuss the 5 criteria tomorrow in the call.
Dolors
-------
Broadmarket potential
[a) Broad sets of applicability
b) Multiple vendors and numerous users
c) Balanced costs (LAN versus attached stations)]
-----
1.. Public networks for residential and business applications represent a
new and very broad application space for IEEE802 wireline technologies. This
project complements EFM, RPR and future projects by addressing the security
issues with a general view and taking the Ethernet transition from
enterprise to subscriber access networks as the first target application.
2.. At the Call for Interest on November 2002, 32 individuals from 18
companies representing both vendors and users expressed their support for
the project. 50-70 individuals from more than 30 companies have attended
the study group sessions.
3.. IEEE 802.1 vendors and users are able to achieve an optimal cost
balance between the network infrastructure components and the attached
stations.
-----
Compatibility
[a) Conformance with 802 Overview and Architecture
b) Conformance with 802.1D, 802.1Q, 802.1f
c) Compatible managed object definitions1.]
-----
1.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with the 802 Overview and Architecture.
2.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with 802.1D, 802.1Q, 802.1f.
3.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with 802.1x, though extensions to these standards may be
proposed as additional work items.
4.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with provider bridge specification defined by 802.1ad TG.
5.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with point-to-multipoint specification defined by 802.3ah TF.
---------
Distinct Identity
[a) Substantially different from other IEEE 802 standards.
b) One unique solution per problem (not two solutions to a problem).
c) Easy for the document reader to select the relevant specification.]
------------
1.. There is no existing link security specification for IEEE 802 wireline
technologies
2.. IEEE802.10 is a general security mechanism applicable to all IEEE802
MAC technologies. However, it has never been used and it requires too many
changes to be used for the target applications of the proposed project.
3.. The proposed project will leverage as much as possible from existing
802 link security mechanisms that are defined in 802.10, 802.11, 802.15,
802.16.
4.. The proposed project will be formatted as a new IEEE Std 802.1
document.
-------
Technical Feasibility
[a) Demonstrated system feasibility.
b) Proven technology, reasonable testing.
c) Confidence in reliability.]
-----
1.. Security mechanisms for IEEE802 wireless access networks are defined.
IEEE 802 security expertise and additional expertise from other security
forums such as IETF Security Area will be used to define the specification
for this project.
2.. The proposed project will be based on mature security technologies and
re-use specifications developed by IEEE802 and other standards bodies to the
extent possible. It will only develop new mechanisms when strictly
necessary.
3.. IEEE802.1 has a successful track record in defining security protocols
for IEEE 802 technologies and also in defining link protocols independent of
the access technologies. This experience will be used for the definition of
this project and will follow the rigorous review process of IEEE802.1 WG.
-----
Economic Feasibility
[a) Known cost factors, reliable data.
b) Reasonable cost for performance.
c) Consideration of installation costs.]
------
1.. The goal of this project is to offer a security mechanism that
balances the level of data security with the cost and performance of the
access technology.
2.. Link security mechanisms are incorporated to other link mechanisms at
a reasonable cost increment. Initial studies show that encryption at the
Gbps rate is also possible with a similar relative cost increment.
3.. The security mechanism will add negligible cost relative to the
installation cost of the access technology.
----- Original Message -----
From: "Mick Seaman" <mick_seaman@ieee.org>
To: "'LinkSec'" <stds-802-linksec@ieee.org>
Sent: Tuesday, May 20, 2003 1:26 AM
Subject: [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
>
>