Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hello Juliusz!

My apologizes for the long delay.  Thank you for addressing my DISCUSS points with the updated -08 and the discussion.  I've cleared my ballot.

Roman

> -----Original Message-----
> From: Juliusz Chroboczek [mailto:[e-mail]]
> Sent: Friday, August 16, 2019 6:53 PM
> To: Roman Danyliw <[e-mail]>
> Cc: Donald Eastlake <[e-mail]>; [e-mail]; The IESG
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with
> DISCUSS and COMMENT)
> 
> > Ah, I see it now in Section 4.3 Thanks for the pointer.  This text
> > explains the issues of around keys processing.  I couldn't explicitly
> > find text explaining when multiple HMAC TLVs should be sent.  Where
> > should I be looking?
> 
> Section 5 (key rotation), formerly Appendix A:
> 
>    In order to perform key rotation, the new key is added to all the
>    nodes; once this is done, both the old and the new key are sent in
>    all packets, and packets are accepted if they are properly signed by
>    either of the keys.  At that point, the old key is removed.
> 
> >> I'm leaving this sentence as is -- after trying it out, I don't think
> >> that mentioning the small amount of state caused by reception of a
> >> UDP packet (an ND entry) is informative.
> 
> > I'm not tracking.  "Whatsoever" is an absolute statement.  By all
> > means caveat the sentence by saying no local Babel state (or something
> > to that effect).
> 
> Done.
> 
> >>> (8) Section 1.  Per the “spoof of a malformed packet”, how would an
> >>> HMAC address this?  Even assuming that a node discards the message
> >>> without processing if the HMAC is bad, this would still be a problem
> >>> from a malicious peer.
> 
> >> Please explain.
> 
> > The initial situation I had in mind was if there was a compromised
> > Babel node.  It will have the key to produce a valid HMAC on the
> > crafted packet to cause the peer Babel node to process the packet.
> 
> Yes, this protocol assumes that only honest nodes know the secret key.  We
> make no guarantees, not even of any kind, if you've lost your keys.
> 
> > Another situation which would not involve a malicious Babel node with
> > the key is a node running a buggy Babel implementation.  Imagine this
> > implementation has some kind of (buffer overflow) vulnerability in the
> > routines which parses the packet payload to find the HMAC TLV.  In the
> > worst circumstance, this could hypothetically compromise the Babel
> > node even before the code to verified HMAC and choose to discard the
> > packet or not is made.
> 
> Yes, it could.
> 
> That is the reason why HMAC keys sit in the packet trailer rather than in the
> packet body: you may use a simplified parser that is only able to parse the
> packet trailer.  This parser does not modify any global state, it does not
> modify the packet (there's no need to clear the MAC before recomputing it),
> and it just returns one bit of information.  You are expected to vet this
> specialised parser very carefully, or even run it out-of-process.
> 
> This was debated by the WG; however, once both Toke (BIRD) and Weronika
> and Clara (babeld) had implemented parsing the packet trailer, we agreed
> that this approach makes the implementation much simpler and less error-
> prone.
> 
> -- Juliusz