Re: [babel] Shepherd's review of draft-ietf-babel-hmac-02

[Juliusz Chroboczek <[e-mail]>]

>> I disagree.  The only property that the index needs to satisfy is that it
>> is never reused for a different PC sequence for a given (key, sender)
>> pair.  In particular, if a node never loses state (e.g. it has reliable
>> persistent storage), then it never needs to change indices -- and in that
>> case, a 0-octet index is suitable.

> Well, say that in the draft. It's come up as a gut objection in
> everybody thus far.

From Section 6:

   Second, it assumes that indices and nonces are generated uniquely
   over the lifetime of a key used for HMAC computation (more precisely,
   indices must be unique for a given (key, source) pair, and nonces
   must be unique for a given (key, source, destination) triple).  This
   property can be satisfied either by using a cryptographically secure
   random number generator to generate indices and nonces that contain
   enough entropy (64-bit values are believed to be large enough for all
   practical applications), or by using a reliably monotonic hardware
   clock.  If unicity cannot be guaranteed (e.g., because a hardware
   clock has been reset), then rekeying is necessary.

> I'm still working out how to go about attacking things. One way is to
> force the daemon to crash (malformed packet, a ping of death, some
> other vulnerability in another daemon that can send a kill -9 to this
> process), on restart, which resets the pc, and forces choosing a new
> index. With a zero length index, well...

You detect that you've suffered a crash, and you refuse to run until you
detect a key rotation.  Or you detect that you've suffered a crash, and
switch to 64-bit indices until the next key rotation.

I'm not saying that that's the right way to implement this protocol (it's
too complex and fragile for my taste), but if someone is intent on saving
every extra bit on the wire, the protocol allows that.

-- Juliusz