Re: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame Format)
Mick-
Everything you seem to be suggesting for the new SFF is accomplishable with
SDE, with minor modifications. It is not any great effort for us to update
the existing .10-1998 Standard to accommodate the proposed features. Most
of what you are describing as "excess baggage" is basically a text deletion
exercise.
Also, your mention of the Probe mechanism has no bearing on the SDE
protocol -- the Probe mechanism is part of our Key Management Standard,
which is a completely separate issue. SDE simply looks for an existing
Security Association in the SMIB. If none exists, it notifies some
management entity, which goes off and creates one. In our current Standard,
that happens to be our Key Management Protocol, which at times utilizes the
Probe mechanism. It could just as well notify .1X, or some other key
management entity.
Ken
----- Original Message -----
From: "Mick Seaman" <mick_seaman@ieee.org>
Cc: <stds-802-linksec@ieee.org>
Sent: Tuesday, May 27, 2003 5:04 PM
Subject: RE: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame
Format)
>
>
> Russ,
>
> I rest my case, with the changes described there are few of the 802.10
pages
> remaining unchanged. I counted the pages by half page in my prior
analysis.
> There will be no interoperability between 802.10 and the new SFF, nor is
any
> desired. There is no need to accidentally import and additional baggage or
> prior scope from 802.10 SDE that goes beyond the proposed PAR - this is a
> very important point, if as it seems there are still thoughts about
> retaining probe mechanisms and other relics. The prior members of 802.10
can
> be acknowledged in the new standard. The amount of editing work involved
> will not be greater to construct a clean new draft than it will be to edit
> the material in place. I'll offer to do it if need be, I seem to be
getting
> plenty of practice with Frame these days.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> Housley
> Sent: Tuesday, May 27, 2003 1:45 PM
> To: Dolors Sala
> Cc: stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] Proposed 5 criteria for LinkSec PAR (Secure Frame
> Format)
>
>
>
> Dolors:
>
> >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.
>
> Okay. Here it is ...
>
> > > 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:
>
> Like "too many," the phrase "very extensive" are very subjective.
>
> > >
> > > 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.
>
> I completely agree with the need to provide integrity protection for MAC
SA
> and DA. I completely disagree that this is a "complete revision" to
> 802.10. It is, in fact, a very minor change. I believe the needed
> revisions could be done in less than a day, including the figures.
>
> > > 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.
>
> I agree that the SAID needs to be explicit.
>
> > > 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.
>
> There has been discussion of this on the list, and there is clearly not
> full agreement that only "single hop" should be supported. I think that
> there are topologies that avoid the need for a probe to discover the
> decryptor that ought to be employed.
>
> I agree that the security protocol should, as an option, be able to
> support plaintext transfer of the .1Q tag.
>
> > > 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.
>
> I understand the desire to avoid registration, and the proposed mechanism
> deserves full consideration. The changes to 802.11 SDE to support a
longer
> SAID are trivial!
>
> > > 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.
>
> Agree. Again, this is a very straightforward update to 802.10 SDE. In
> fact this approach was discussed during the development of SDE, but it was
> politically unacceptable at the time. Further, Xerox assigned an
EtherType
> for encryption. I wonder if they would be willing to donate it to this
> effort...
>
> > > 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.
>
> I have no problem with getting rid of the MDF. It has always been
> optional. It was included to get Digital Equipment Corporation on
> board. I am sure that their use of this field, which is covered by a
> patent, has no constituency.
>
> > > 7. The fragmentation option needs to go, it has no place at this
layer,
> and
> > > will not find any deployment.
>
> If other optional features, such as security labels, are accommodated,
then
> fragmentation is needed. Note that not every implementation needs to
> support them. There is no issue if the security association does not
> include these features. If there is not constituency for these features,
I
> have no problem dropping them. Some folks use .1Q tags as a form of
> security label, so there may be no need for the more complicated one.
>
> Russ
>
>
>
>