[babel] HMAC and DTLS cryptographic state can be maintained indefinitely

[Juliusz Chroboczek <[e-mail]>]

Hi.  I think I have a nit against both Babel security drafts (HMAC and
DTLS).  The fix is easy, but I'd like to hear the list's opinion first.

Executive summary: both security mechanisms associate the cryptographic
state with the neighbour entry.  In both mechanisms, an attacker may
prevent the neighbour entry from expiriting, thus maintaining the
cryptographic state for an arbitrary time.  While this does not lead to
any obvious vulnerability, it is worrying, and should be fixed.
Fortunately, the fix is easy.

1. The issue

Both security mechanisms rely on a pairwise exchange that leads to both
peers estabilishing cryptographic state in their neighbour tables.  In the
case of HMAC, the cryptographic exchange is called the "challenge", and
the state is the current index and seqno.  In the case of DTLS, the
exchange is the DTLS handshake, and the state is the current DTLS state.

If A has a neighbour entry for a peer B, and the peer B leaves the
network, then A's neighbour entry for B will eventually expire.  However,
in some cases an attacker C can prevent the neighour entry for B from
expiring, as described below.

1.1 HMAC

In HMAC, an attacker can replay a correctly signed packet with an index
different from A's current index.  This causes B to send a challenge, and
keep the challenge data in the neighbour entry; if replayed packets are
sent often enough, the neighbour entry will never expire, and the
cryptographic state will live forever.

1.2 DTLS

In DTLS, Hellos are unauthentified.  Hence, it is enough for the attacker
to send fake Hellos to prevent the neighbour entry from expiring.


2. What can an attacker do?

The issue outlined above does not cause an obvious vulnerability -- the
cryptographic state does not allow any obvious replay attacks.  There is
one troubling case, though.

Suppose that just before B leaves the network, it sends an announcement
that is not received by A (due to packet loss), but is captured by an
attacker C.  Then C may choose to maintain A's cryptographic state for
a long time, then replay B's announcement.  It can do that only once -- if
it attempts to replay it twice, then A's replay detection mechanism will
trigger.

It's not obvious if delaying a single announcement by an arbitrary amount
of time is a vulnerability, but I'm sure I'm not the only person it makes
feel uncomfortable.


3. The fix

The obvious fix is to require that A discards its cryptographic state
after a bounded amount of time.

In HMAC, Hellos are authentified, so it is an easy matter to simply
discard the cryptographic state (but not the neighbour entry) whenever the
Hello history becomes empty.  I am planning to add wording to that effect
to Section 4.1 of the draft:

  The receiver MUST ensure that the cryptographic state (index and seqno)
  is discarded after no packet has been accepted for the sender for
  a bounded time.  A simple solution is to discard the index and seqno
  whenever the both hello histories in the neighbour entry becomes empty
  (see Appendix A of RFC6126bis); another solution is to discard the index
  and seqno after a fixed time interval (e.g. 5 minutes) has elapsed since
  the last accepted packet.

In DTLS, Hellos are not authentified, so the above solution won't work.
I suggest requiring that the DTLS state be discarded whenever the IHU
timer expires. 


4. Please comment

I'm going to update the DTLS draft pretty soon, so please comment.


5. Acknowledgments

Thanks to Pierre Letouzey and Yann Régis-Gianas for the discussion that
lead to the issue described in this mail.