Re: [LinkSec] Preliminary view of header format
Marcus:
This is the reason that 802.11i is using CCM. It allows header information
to be covered by the integrity check value even though they are not covered
by encryption. NIST is going to include CMC as one of the approved AES modes.
CCM is documented in an IETF Internet-Draft: draft-housley-ccm-mode-02.txt.
Russ
At 09:51 PM 9/2/2003 -0400, Marcus D. Leech wrote:
>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------