Re: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame Format)
Russ,
It is true that "too many" is a subjective term. But I just incorporated
what it has been discussed in the group.
I would appreciate your comments on Mick's proposed PAR and his analysis
motivating the need of a new standard. If the group agrees that these list
of changes are necessary, then I also agree with Mick in saying that these
are "too many changes". Participants in the call felt the same. We will
discuss this in the meeting.
I have not seen a response to Mick's proposed changes, and your feedback is
certainly very valuable. Can you please elaborate where you would disagree
with that analysis? I include it at the end of the message for reference.
Thanks,
Dolors
----- Original Message -----
From: "Russ Housley" <housley@vigilsec.com>
To: "Dolors Sala" <dolors@ieee.org>; <mick_seaman@ieee.org>; "'LinkSec'"
<stds-802-linksec@ieee.org>
Sent: Tuesday, May 27, 2003 11:41 AM
Subject: Re: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame
Format)
>
>
> >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.
>
> I disagree with number 2. I guess that "too many" is a subjective
measure.
>
> Russ
>
----- 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.
>