RE: [LinkSec] Preliminary view of header format
This is where CCM's associated data field is very useful. You just fill
it with all the header goop that you feel should be authenticated and
you don't have to put it in the ciphertext. However you need to be
careful not to run into the 'mutable bits' problem that 802.11i ran
into.
The discussion and slides today on the conference call addressed the
fact that there exists a fairly direct speed/cost tradeoff in terms of
patent encumberance. This, along with your comments on the interaction
between the mandatory/optional state of ciphersuite elements and
provider bridging led to a consensus that CCM-AES-128 should be
mandatory and that OCB-AES-128 should be optional for higher speed
devices that need it. Following the discussions I'm leaning towards
adding an OMAC mode to address auth only but this is presupposing NIST
chooses OMAC.
I've yet to go through any details on how an OCB frame would be
constructed for LinkSec. Don't hold your breath, I only promised to have
a presentation ready for the call in two weeks.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: Mick Seaman [mailto:mick_seaman@ieee.org]
> Sent: Tuesday, September 02, 2003 7:17 PM
> To: 'Marcus D. Leech'
> Cc: stds-802-linksec@ieee.org
> Subject: RE: [LinkSec] Preliminary view of header format
>
>
>
>
> Thanks Marcus. I wasn't thinking about encrypting the
> addresses of course
> but, just as you say, of integrity checking them (since this
> in the PAR, but
> more importantly denials of service ought to be localisable if not
> preventable). I think it is algorithm dependent whether an
> encrypted version
> of the addresses has to be transmitted as well as the in
> clear copy because
> of the mechanics of the encryption/integrity algorithm. I
> suspect the choice
> of whether you want a "one pass does everything approach" as
> opposed to
> separate integrity and encryption algorithms is speed
> dependent (in the case
> where there's an obvious speed choice). This is where I need
> an education.
> Obviously I'd like to avoid duplication of fields in cipher
> text over media
> that have efficiency issues as a hot topic.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf
> Of Marcus D.
> Leech
> Sent: Tuesday, September 02, 2003 6:52 PM
> To: mick_seaman@ieee.org
> Cc: stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] Preliminary view of header format
>
>
>
> Mick Seaman wrote:
> >
> > M_UNITDATA.request(
> > frame_type = user_data_frame,
> > destination_address,
> > source_address,
> > msdu, = security_tag,
> initialization_vector, original
> msdu,
> > message_integrity_code
> > user_priority,
> > access_priority,
> > fcs) // modified
> >
> > where the security_tag includes the fields MACsecEtherType,
> Flags, [SAO],
> > SAID
> > and the message_integrity_code is calculated across the fields
> > destination_address, source_address, security_tag,
> initialization_vector,
> > original msdu, with the two addresses treated as if they
> were encoded in
> > canonical format and immediately prepended to the rest of
> the data, though
> > of course in the case where there is a complex underlying
> provider the
> final
> > "on the wire" frame format may contain any number of fields
> particular to
> > that provider and placed before the addresses or between
> the addresses or
> > indeed anywhere in the frame, just as long as they are
> removed by the time
> > the parameters reach the same height in the receive stack.
> >
> This raises an interesting issue that I have been thinking about since
> looking more at combined modes like OCB. In some places,
> like IPsec,
> the integrity coverage is wider than the encryption coverage (you
> can't encrypt addresses, or things will go to the wrong place :-)).
> In a "one pass does everything" mode like OCB, you have to do
> a little bit of footwork to prepend the addresses, and other goop
> that logically is only part of the integrity calculation, but might
> possibly be carried along in the ciphertext portion, redundantly,
> just so that the decrypt-and-verify operation works properly on
> the other side.
>
> --
> ----------------------------------------------------------------------
> Marcus Leech Mail: Dept 8M70,
> MS 012, FITZ
> Advisor Phone: (ESN) 393-9145 +1 613
> 763 9145
> Security Architecture and Planning Fax: (ESN) 393-2754 +1 613
> 763 2754
> Nortel Networks mleech@nortelnetworks.com
> -----------------Expressed opinions are my own, not my
> employer's------
>
>
>