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