Subject: [babel] Secdir early review of draft-ietf-babel-hmac-00

From: Robert Sparks <[email-masked]>
Date: Thu, 01 Nov 2018 14:59:58 -0700

Reviewer: Robert Sparks
Review result: Has Issues

This is an early secdir review of draft-ietf-babel-hmac-00

Summary: There are issues in the draft to address

Issues:

The pseudo-header is IPv4-centric.

The protocol allows for multiple HMAC algorithms, but has no mechanism for
signaling which one was used. The MUST NOT at the top of page 8 will need to
be adjusted after that's worked out.  Discussion of what to do at a verifying
peer that doesn't implement a chosen algorithm is also needed.

Nits:

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.

The third bullet at the top of page 4 (among different nodes) has its actors
confused. As stated, communication between A and C is irrelevant to the
communication between B and C.

It would be worth building an example of bootstrapping the protocol between 
two peers that have no previous knowledge of each other.

It's concerning to see a document (even a 00) whose point is to secure a
protocol have no discussion at all in the Security Considerations section. It
will help refine the document to create and maintain a summary of the important
security points in this section going forward.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 02 Nov 2018 11:11:03 +0100

Dear Robert,

Thank you very much for your review.

> The pseudo-header is IPv4-centric.

The diagram in Section 4.1 shows 16-octet addresses, and so, if anything,
it is IPv6-centric.  I may be missing something, but I don't see any place
where we're assuming IPv4.

(The intent, of course, is that the pseudo-header is address-family
independent -- the diagram shows 16-octet addresses, but we've been
careful to avoid mentioning address families in the body text.  If you
have any advice about how to improve that, we're listening.)

> signaling which one was used.

This is the case, and it is the intent -- checking algorithm availability
is done at key provisioning time.

> The MUST NOT at the top of page 8 will need to be adjusted after that's
> worked out.  Discussion of what to do at a verifying peer that doesn't
> implement a chosen algorithm is also needed.

I don't understand.  The first point of Section 4.3 looks clear to me --
a node doesn't compute an HMAC for every HMAC TLV it receives, it computes
an HMAC for every key it has been provisioned with.  Obviously, it knows
the algorithm of every key it has been provisioned with (else it would
have failed at configuration time), and hence there is no issue computing
all required HMACs.

Am I missing something?  Do you have any suggestions about how to make
that clearer?

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

A node is allowed to lose its state at any time, at the cost of one RTT
worth of lost packets (it will need to issue a new challenge to every
peer).  In particular, it need not persist its state across reboots.

You're right, though, that while this is reasonably clear in the
Conceptual Overview section ("Consider a peer A that has no information
about a pair B (e.g., because it has recently rebooted)"), we need to put
an explicit "MAY discard its state at any time" in the normative part.

> communication between B and C.

I have double-checked, and I believe the property is correct as stated.

> two peers that have no previous knowledge of each other.

We've tried to do that in Section 2:

   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.

If you have any advice about how to improve this section, we're listening.

> protocol have no discussion at all in the Security Considerations section.

While we've done our best to describe the claimed security properties of
the protocol in Section 1.2, we still need to write up the Security
Considerations section.  We'll do that as soon as we can spend some time
together with my co-authors.

Thanks again for your work,

-- Juliusz

---

From: Robert Sparks <[email-masked]>
Date: Fri, 2 Nov 2018 10:45:34 -0500

> have any advice about how to improve that, we're listening.)
Ok - skimming to fast and had a divide-by-4 error. Sorry.

I still think you'll need to say something about how you're building the 
pseudo-header for IPv4 vs IPv6.
Are you assuming that the header would be a different size for IPv4, or 
the same size with some zero-packing?
> is done at key provisioning time.
So this is me being new to babel itself - I'll go read the base 
documents more carefully.
> Am I missing something?  Do you have any suggestions about how to make
No, that's all moot.
> I have double-checked, and I believe the property is correct as stated.
I disagree. I think the clause you have in the "then" part of that 
sentence stands alone, and the "if" part has no bearing on it.
Please explain further how A having accepted a packet from C has any 
influence whatsoever on whether B will accept a packet from C?
Maybe the clause just needs restructuring to avoid the "if <> then <>" 
form. Perhaps this construction would work better:

A copy of a valid packet originally sent from C to A and then replayed 
to B will be detected at B as invalid if...
> If you have any advice about how to improve this section, we're listening.
Apologies for asking you to explain what's probably a simple and obvious 
thing,
but, assuming at the beginning of that sentence that neither A nor B 
knows the
other node's current (index, PC), then at the end of the paragraph, B 
_still_ doesn't
know A's (index, PC). I'm assuming the challenge A sent to B is not 
protected by
the basic mechanism in this draft, or B would have to discard it and 
challenge A
so it could learn what A's (index, PC) was before it could even read the 
challenge.
Can you walk me through the parts of the what you have written (or what 
you're
implying by reference) that makes that clear?
clear.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 02 Nov 2018 19:21:49 +0100

> pseudo-header for IPv4 vs IPv6.  Are you assuming that the header would
> be a different size for IPv4, or the same size with some zero-packing?

Noted, will do.

> So this is me being new to babel itself - I'll go read the base documents
> more carefully.

The point here is that the receiver does not need to know the set of HMAC
algorithms implemented by the sender: it just computes its own HMAC of the
packet, and compares the result (bytewise) with every HMAC TLV included by
the sender; if some of the HMAC TLVs use algorithms that are not
understood by the receiver, then the comparison fails, and no harm is
done.

This is, in my understanding, no different from RFC 2328, Appendix D.5.2,
paragraph (2) (which is, as far as I know, unchanged by RFC 5709).

>>> The third bullet at the top of page 4 (among different nodes) has its
>>> actors confused.

> sentence stands alone, and the "if" part has no bearing on it.

That's a subtle point, and one that my colleagues and I have spent
a significant amount of time thinking about.  I'm not happy with the
current formulation, but this is the best I can do right now.  More below.

> A copy of a valid packet originally sent from C to A and then replayed to
> B will be detected at B as invalid if...

That's too strong.  The protocol is designed to protect *multicast*
communication, so a packet sent from C to both A and B will be accepted by
both A and B.  It does not matter if the packet is sent over a link-layer
multicast C->A,B, or twice over link-layer unicast C->A,C->B -- in either
case, it is accepted by both A and B.

The property we have is that if C->A is accepted by A, then C->B is
accepted by B only if both of the following are true:

  - B has previously accepted A's challenge reply;
  - B hasn't accepted any later packet from A.

I agree that this property is confusing, so if you can point us to comparable
protocols and the properties that they provably satisfy, then perhaps it
could help us find a better formulation of the security properties that we
claim.

Thanks,

-- Juliusz