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

[Juliusz Chroboczek <[e-mail]>]

Dear Robert,

> 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.

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