Re: [LinkSec] Proposed Scope for a LinkSec PAR (Secure Frame Format)
Dennis:
You are correct. To support replay protection in a group SA, a separate
window must be maintained for each source MAC address. This can become a
fair amount of memory. I would think that support for such checking should
be optional.
Russ
At 12:15 PM 5/23/2003 -0700, Dennis Volpano wrote:
>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
> >
> >