Re: [babel] Minor clarification to HMAC

When a node detects a new neighbour (by receiving a multicast hello), it
sends a challenge.
I can imagine several ways to implement this:
- create the neighbor entry at this point
- have a separate table of pending challenges
- come up with a clever stateless scheme involving cookies (maybe?)
But how the node handles the challenge is an implementation matter.
A rate-limiting and anti-DoS mechanism can be added to all of these.

Therefore, I support adding this MAY, because it gives implementors leeway.

David

On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg <markus.stenberg@iki.fi>
wrote:

> In terms of security properties, notably resource exhaustion/contention, I
> am bit leery of creating entry before validity of remote party is actually
> verified (= challenge response received). I prefer the old text. I am not
> quite sure why the second 'may need to be created' is there..
>
> I guess naive implementation would just remember specific nonces it has
> sent/freceived, but for new peers you can also just use e.g. nonce that
> contains timestamp (+ peer address (+- something))[1], which allows
> challenge sender to remain stateless until challenge responder proves they
> have the key.
>
> So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)
>
> Cheers,
>
> -Markus
>
> [1] extra stuff is mostly for replay protection purposes, but I am not
> sure if it is a threat or not in this case. I have just cycled 140km, sue
> me.
>
> > On 28.06.2019, at 16.21, Juliusz Chroboczek <jch@irif.fr> wrote:
> >
> > Dear all,
> >
> > Sawssen and Étienne (in copy of this mail) are currently working on
> > cleaning up and completing the reference implementation of
> draft-...-hmac.
> > We have just realised that the draft is not quite clear on two points.
> >
> > The draft says that a neighbour entry MUST NOT be created before HMAC is
> > verified (Section 4.3 first bullet).
> >
> > It later says that a neighbour entry "might need to be created" when
> > a challenge is sent, and "may need to be created" when a challenge is
> > received.  However, it does not say whether it is legal to create an
> entry
> > earlier.
> >
> > I would therefore like to kindly request the permission of the group and
> > the chairs to add the following between the first and second bullet
> points
> > of Section 4.3:
> >
> >  * A neighbour entry for the sender of the packet MAY be created at this
> >    stage.  (Alternatively, an implementation MAY delay the creation of
> >    a neighbour entry until a challenge request or reply is received.)
> >
> > This clarification does not invalidate any implementations, it just makes
> > the intent of the draft authors more explicit.
> >
> > -- Juliusz
> >
> >
> > _______________________________________________
> > babel mailing list
> > babel@ietf.org
> > https://www.ietf.org/mailman/listinfo/babel
> >
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>