RE: [LinkSec] Preliminary view of header format
I would suggest that an SAO (new acronym, willing to swap for existing
acronym, for "Secure Authentication Origin") be included in the SFF (Secure
Frame Format) as a transmitter option.
The purpose of the SAO is to identify the system that performed the "secure
wrapping" since that is, as we know, almost never the end station. If you
are a poor network manager trying to debug what is going wrong it (I
believe) will be really useful to know who it is (that has claimed to)
securely wrapped up the frame.
The SAO is clearly redundant on a true point-to-point link (and should be
omitted). I'm most concerned about the case when a virtual point-to-point
service is being provided across a provider bridged network, or other
infrastructure.
Under the terminology I prefer the SAID is unique only to the secure
association, so has been cleansed of any semantics I would associate with
the SAO. Clearly in 802.10 the SAID combines both SAO and SAID (according to
me) parts. If one followed 802.16 terminology (I am informed) "my" SAID
would be equivalent to their SEQN, but since it has no connotations of
advancing like a sequence number (there is no idea of backwards) SAID is a
superior name to SAID).
The layer independent (important since the security function can go multiple
places in a provider bridging stack) rendition of the SecY (on transmitting
a user data frame) is that it receives a request from its user:
M_UNITDATA.request(
frame_type = user_data_frame,
destination_address,
source_address,
msdu,
user_priority,
access_priority,
fcs)
where the msdu (MAC Service Data Unit) is the PAYLOAD (I believe) in Marcus'
terms, and makes a similar request of the underlying provider, with the msdu
encoding the additional fields:
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.
Most of this is in the diagram I emailed to the list on Thursday 8/21/2003.
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Leech,
Marcus (EXCHANGE:FITZ:8M86)
Sent: Tuesday, September 02, 2003 12:38 PM
To: stds-802-linksec@ieee.org
Subject: [LinkSec] Preliminary view of header format
Here's a preliminary view:
SAID|IV|PAYLOAD|MIC
SAID = 4 bytes Security Association Identifier
IV = Initialization Vector, 4-16 bytes, depending on ciphersuite
PAYLOAD = variable length
MIC = Message Integrity Code, 8-16 bytes, depending on ciphersuite
The SAID could be compressed to a single octet if there is other implicit
context
"lying around" that can uniquely identify this security association. It's
not
clear to me that is possible across all technologies we're talking about
here,
so making it 4 bytes (32-bits) would be consistent with 802.10, and IPSec.
Given the birthday paradox, I'm inclined to conservatism, and perhaps that
8-16 bytes for MIC should be 10-16 bytes. It would probably be prudent
to make a statement in each ciphersuite that negotiation of new keys
(and consequent SAID) should begin when 2**((N/2)-1) messages have been
transmitted under the current key, where N is the MIC size in bits.
--
----------------------------------------------------------------------
Marcus Leech Mail:
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------