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