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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    > During the authentication the JRC needs to provide the keying material
    > to the joining node, but that does NOT provide protection against
    > spoofed ASN. After the node has actual keys used in the network it
    > still needs to verify the ASN by sending some message to JRC using
    > authentication and verify that JRC replies to that.

I thought that the 6LRs could provide authentication of the beacons with the
network-wide-key, and that we could (after the join process), verify the beacon we
saw, using the key(s) that the JRC provided.

    > If this 2nd step is omitted attacker do following attack:

>Joining node (JN)   attacker	     		  JRC
>		    <- beacon for ASN=23	  <- beacon for ASN=44
>See beacon
>from attacker,
>assume ASN=23.

So this is a replay of the valid beacon with ASN=23.

    > 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 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.

I thought that we have text in 6tisch-minimal about needing to rekey the
network if we run out of short-addresses for this reason.  Well, no.
We explain how to rekey well, but not why to rekey :-)

Are you suggesting that we need to put this in the architecture document too?
Maybe we should have included the ASN as an attribute in the JRC response.

    > 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.

Still, that's more code to implement a heuristic.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-