Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Tero:

Some clarification questions below:


> Now, if JN is using extended address to generate nonce, the nonce will be
> different for all other nonces ever used, even the ASN is faked, and has been

This is assuming that the attacker is not attacking the same device twice, isn't it?

> used before. On the other hand if JN also receives short address assignment
> from the JRC, JRC needs to make sure that short address has not been
> assigned to anybody else before, as if it was used by someone else, and frame
> sent by JN is encrypted, then attacker will now have two packets with same
> ASN, and short address, meaning same nonce, and it can now decrypt packets.

That's unless new keys are given if the short address is reattributed, correct?

> Note, that attacker might be able to replay valid ACKs for the frame sent by
> the JN, provided that the JRC (or whoever JN sent the message
> to) happened to ack message using the same ASN attacker faked for JN.

Your mean that the faked ASN is only slightly in the future, so the attacker can repeat messages from the pledge after that delay?

> If JN sends message to JRC which only JRC can reply, and uses wrong ASN, the
> JRC will not be able to decrypt/validate that frame because of wrong ASN in
> nonce, and will drop it silently, so if JN uses wrong ASN it might be getting
> ACKs, but it will not get any real reply frames back from real participants in the
> network. After it will not receive confirmation from JRC that it has proper keys
> and ASN, it knows something went wrong.

I'm not sure about the status of sync'ing the JRC with the network. Minimal-security does not discuss it. Talking to Malisa to improve that piece proactively to the sec-dir review.

I'll propose text based on your reply and Malisa's separately.

Many thanks for your clarifications!

Pascal