[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: SIPP and SKIP. 2 subjects.
Ashar:
You said:
>> I'm a bit confused by the comments about SAIDs being reserved
>>to indicate a particular key exchange. The idea of an SAID is that it
>>is selected by the local IPSP entity (IPSPE?) for use as the SOLE
>>selector for security transformation processing for incoming packets.
>
>Yes, I understand that this is the model that one uses with SAIDs
>and session-oriented key-management. However, this is not the
>model that SKIP uses, and I am not sure that the IPSP protocol
>should constrain the meaning of the SAID, simply to rule out
>SKIP-like key-management.
>
>The way the SAID would be used with SKIP is that the SAID is
>combined with further information following the SAID
>itself (namely the packet encryption key) to determine how to
>perform the security transformation.
>
>This, I believe, is a more general use of SAIDs than the one
>you've described above. Certainly, Clause 2 of the 802.10
>protocol permits this style of determining how to perform the
>security transformation (using the MDF field which optionally
>follows the SAID), and I, for one, would not be happy to see
>a more restrictive model be part of the IPSP description.
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.
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 do not think that a few reserved SAID values will provide the capability
that you want...
Russ