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