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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    > Then it sends a beacon with ASN of x, where x is close to the ASN of
    > packet it wants to attack. JN then packet out to JRC with ASN of x +
    > n1, the attacker can ack it, and then take that packet and replay that
    > to the JRC at ASN of y (where x != y, and y > x). When JRC sends reply
    > packet at y + m, the attacker can reply it back to JN with ASN x + n2
    > and JN will accept it. Now JN has properly rejoined the network (both
    > JN and JRC have authenticated themselves) and JN has keys K1, but
    > thinks ASN is x instead of y. Next packet it sends will be encrypted
    > with K1 and with ASN of x + n3. If x + n3 happens to be the ASN of z
    > the attacker gets two frames encrypted with same key k1 and nonce
    > generated from ASN z. If first try goes wrong it can allow JN to replay
    > until x + n3 > z, and then it can start over again and adjust the
    > starting value of x so it is better guess of how long JN will take when
    > sending frames out...

I'm gonna have to draw this this to get it all, but I think that I see the
point.  If I understood correctly, the attacker can get the JN to be behind
in the ASN game such that it can now see a packet encrypted by the JP and JN
using the same ASN.  It does this by storing legitimate EBs, and replaying
them at a time such that the JN is offset, and the attacker relays the packets.

    > So I do not think we can do anything in the JN <-> JRC protocol to
    > protect against this, the only real way to protect against this, is to
    > send L2 authenticated (but not encrypted) frame after authentication
    > phase from the JN to JRC containing random cookie, and require that JRC
    > to echo it back to JN in similar authenticated but not encrypted frame.

I think maybe somewhere here you mean JP rather than JRC, as the JN and
the JRC are not connected at L2, except via the JN.

    > I.e., make sure the joining process is (I leave out acks in this
    > picture):

"security level X" <--- this is an IEEE802.15.4 thing, not a new creation,
right?

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