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------