Subject: [babel] Questions about HMAC authentication

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 07 Jun 2018 16:00:12 +0200

Dear all,

Clara and Weronika (in copy of this mail) have made some progress in
implementing HMAC authentication.  A few comments and questions.

1. What shall we put in the pseudo-header?  Our current strawman proposal is

  source IP
  destination IP

Do we need to add the port numbers (which are normally constant)?
Anything else?

(Note on this subject that including the source IP complicates the
implementation somewhat -- at the time when you're generating the HMAC,
the source address is not known yet; for it to be known, you need to
either use a connected socket or double-guess the kernel.  It's only
a problem if the interface has multiple link-local addresses, which
shouldn't normally happen.)

2. Denis' definition of the HMAC TLV contains a Key ID.  We don't
understand what the Key ID is for, so we're omitting it for now.  We'd be
grateful for guidance.

3. TS/PC is 32 bits of TS and 16 bits of PC.  Make it 32+32?

4. I was thinking about adding a flag to TS/PC that indicates that the TS
is UTC time modulo 2^32.  This avoids a replay attack when both the sender
and the receiver have a reliable hardware clock, but the receiver has lost
its ANM state.

(Suppose that A is sending TS/PC with the UTC bit set, and B has lost its
ANM state.  If B has a reliable clock, it can discard any packet that is
more than one minute or so in the past, which avoids a trivial replay
attack.)

Advice?  Criticism?  Objections?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 07 Jun 2018 16:22:28 +0200

> Do we need to add the port numbers (which are normally constant)?

Hmm, technically you are not following the spec if you change the port
number, are you? So it would technically be acceptable to exclude those?

> shouldn't normally happen.)

Well if you don't want to guess you could conceivably add a hash for
each one?

> understand what the Key ID is for, so we're omitting it for now.  We'd be

As I understood it it's an ID that you put into your configuration, and
you only verify a signature if you have a key with a corresponding ID.
Cuts down on hash operations for things that wouldn't match anyway. If
you don't use this, what do you do with multiple keys?

> 3. TS/PC is 32 bits of TS and 16 bits of PC.  Make it 32+32?

Not sure. Why?

> Advice?  Criticism?  Objections?

How do you determine if you have a reliable clock? What happens if you
are wrong? This seems like an option that most people would just end up
turning off because someone somewhere had problems with clock accuracy
an yelled about it on the internet...

-Toke

---

From: David Schinazi <[email-masked]>
Date: Mon, 11 Jun 2018 17:33:14 -0700

> On Jun 7, 2018, at 07:22, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 

Awesome!

> number, are you? So it would technically be acceptable to exclude those?

Agree that we don't need them now, but it gives us the option for easier future extensibility.

> Well if you don't want to guess you could conceivably add a hash for

I dislike this option, allowing multiple hashes reduces the security as attackers
could send many hashes to increase their odds of collision.

> you don't use this, what do you do with multiple keys?

Yes, my understanding is that having an identifier is much more efficient
if you have many keys configured, and reduces the impact of DoS attacks.

> an yelled about it on the internet...

I also think hoping for a *reliable* clock is optimistic and opens up a whole range
of failure patterns when the clocks drift apart.

I think the correct fix to that attack is to only accept updates from a neighbor
once you've confirmed that they've ACKed a recent Hello seqno of yours.

David