N_U serves as a session identifier. That is the reason it is bounced back in 
message_2.

Both N_U and N_V is not needed in message_3. In the updated version on  Github 
only a single session identifier is used in message_3

Sent from my Cray-1

> On 24 Feb 2017, at 15:07, Göran Selander <goran.selan...@ericsson.com> wrote:
> 
> Michael, 
> 
> This has already been updated in the latest version on the Github:
> https://ericssonresearch.github.io/EDHOC/
> 
> 
> As I mentioned we will submit to the IETF a new version next week, pending
> some expected review comments.
> 
> Göran
> 
> 
>> On 2017-02-24 14:15, "Michael Richardson" <mcr+i...@sandelman.ca> wrote:
>> 
>> 
>> N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))|
>>   | <---------------------------------------------------------------+
>>       |                             message_2
>> |
>>           |
>> |
>>   |                                                                 |
>>       |    N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3)))
>> 
>> Why is N_U echoed back to U in message 2?
>> Why are N_U and N_V included in message 3?
>> 
>> If the nonce acts as a defense against off-path attacks, then at least
>> N_U does not need to be in message 3.  Including N_U in message 2 defends
>> an off-path attacker racing V to reply to message_1, which seems unlikely.
>> 
>> 
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
> 

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to