I have no problems with adding the Policy steps to the processing.
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 8:56 PM To: Jim Schaad; emu@ietf.org Subject: Re: [Emu] IMSK derivation issue Jim: Thanks for pointing out this issue. How about the following text with slight modification with policy control from both sides to prevent downgrade attack. Added text in red. 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, and the sender's policy accepts MSK based MAC, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other Side. c) If the EMSK is available, but the sender's policy doesn't allow downgrade to MSK generated MAC, then it should only send EMSK based MAC. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, and its policy accepts MSK based MAC, then it validates using the MSK - and if successful generates and returns an MSK generated response. d) If no EMSK Compound MAC was sent, and its policy doesn't accept MSK based MAC, then it handles like an invalid crypto-binding TLV with fatal error. On 9/29/12 4:47 PM, "Jim Schaad" <i...@augustcellars.com> wrote: I agree that the IMSK needs to take into account the existence of the EMSK, however the current text has a severe problem with the way that it is done. It assumes that if the EMSK is exportable on one side, then it will be exportable on the other side as well. I don't believe this is the case. In order for this to work, and to prevent the downgrade attack by a MITM, I believe that the following changes need to be made: 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other side. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, it validates using the MSK - and if successful generates and returns an MSK generated response. If the EMSK compound MAC is removed in transit, then the MSK validated value will fail as the BUFFER string is not modified to recognize that an EMSK Compound MAC was sent. 3. The first send then validates the returned values by: a) If it sent an EMSK Compound value - attempt to validate using the EMSK value. If it fails then go to b else succeed b) Validate using the MSK value using the unmodified buffer. Both sides will then need to remember if the MSK or EMSK value was used for validation in this step, but that is no different than the fact that the MSK is currently being remembered. Jim _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
