[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[4]: SIPP and SKIP. 2 subjects.
Ashar:
>>You are correct that the MDF follows the SAID in IEEE 802.10b (a.k.a.
>>Secure Data Exchange (SDE)). However, your discussion does not point out
>>that the MDF must be a constant for a given security association. That
>>means that a particular SAID vlaue must be followed by the same MDF value
>>forever.
>
>Where exactly in the 802.10 standard does it say this? (I dont have it
>handy, so I cant check).
On pages 12 and 13, in section 2.5.2.1.3, IEEE Std 802.10-1992 says:
The MDF allows the transfer of information that may facilitate, but is
not required for, the processing of the PDU. The MDF is variable in
length and is an integral number of octets up to a maximum of 20. Its
value is indicated by an entry in the SMIB. The MDF my contain any
value and is not used to determine the appropriate security
association. The MDF value is unidirectional attribute of the
security association an is *constant* for the duration of that securty
association. The MDF is optional.
An example of the application of the MDF is an SDE implementation that
does not retain cryptographic state information. the transfer of
cryptographic state information and keting information in the MDF could
facilitate reception processing.
I added the emphasis.
>>DEC wanted this capability in the standard to support a scheme where the
>>SAID specified a key encryption key. The MDF contained the traffic key
>>(and possibly an integrity algorithm key as well), and the key(s) were
>>encrypted in the key encryption key specified by the SAID.
>
>I am not sure I understand this. If the MDF is to remain constant
>for a security association, and the SAID identifies the
>key-encrypting key, then the only time the traffic key (which is in
>the MDF) can be changed is when the key-encrypting-key changes. What
>is the value of separating the two keys then?
In the IEEE 802.10 model, the SAID denotes a shared symmetric key and its
associated attributes. In the case where the MDF is used, the key is the
key encrypting key (KEK), and the MDF value determines the traffic
encryption key (TEK). This scheme offeres two possible advantages:
1. The traffic in each direction can be encrypted in two different TEKs,
while a single KEK is used.
2. When there are many security associations in place between the same two
hosts, the same KEK can be used for all of them, while different TEKs are
used to cryptographically separate each of them.
>>I do not think that a few reserved SAID values will provide the capability
>>that you want...
>
>Why? Could you elaborate?
This ties back to my model of a security association, which is the one used
in IEEE 802.10. In the IEEE 802.10 model, the SAID denotes a shared
symmetric key and its associated attributes. Therefore, it names the KEK.
For a moment, assume that the key management is all worked out, and the
"reserved" SAID tells the destination IPSP how to decrypt the MDF to obtain
the TEK. Fine. Where do the other attributes for the security association
come from? The IEEE 802.10 definition of the MDF explicity says that the
MDF "is not used to determine the appropriate security association."
Reserved SAIDs simply do not get you the two things that are needed to
process the datagram: the key(s) and the attributes of the security
association.
Russ