Subject: [babel] Secdir last call review of draft-ietf-babel-hmac-07

From: Robert Sparks via Datatracker <[email-masked]>
Date: Fri, 28 Jun 2019 11:54:21 -0700

Reviewer: Robert Sparks
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This document is ready for publication as a Proposed Standard RFC, but has a
nit that should be considered before publication.

Nit: (This was part of my early review of -00)

The claim in 1.1 about not requiring persistent storage is contradicted by the
definition of the protocol. At the very least, there is the need to persist the
most recent (index,PC) seen.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 01:44:33 +0200

Dear Robert,

> most recent (index,PC) seen.

I most respectfully disagree.

The whole point of the challenge/response mechanism is to avoid the need
for persistent storage.  If a node loses the information about a neighbour
(e.g. because it has rebooted and lost the index/PC of the neighbour), it
can simply send a new challenge to recover the state.

Here is what is written in Section 2 (Conceptual overview):

   By itself, the PC mechanism is not sufficient to protect against
   replay.  Consider a peer A that has no information about a peer B
   (e.g., because it has recently rebooted).  Suppose that A receives a
   packet ostensibly from B carrying a given PC; since A has no
   information about B, it has no way to determine whether the packet is
   freshly generated or a replay of a previously sent packet.

   In this situation, A discards the packet and challenges B to prove
   that it knows the HMAC key.  It sends a "challenge request", a TLV
   containing a unique nonce, a value that has never been used before
   and will never be used again.  B replies to the challenge request
   with a "challenge reply", a TLV containing a copy of the nonce chosen
   by A, in a packet protected by HMAC and containing the new value of
   B's PC.  Since the nonce has never been used before, B's reply proves
   B's knowledge of the HMAC key and the freshness of the PC.

Should you disagree with the fact that this mechanism allows a node to
recover the state that it has discarded, I request that you provide
an example scenario in which this mechanism fails.

-- Juliusz