[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