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

Juliusz Chroboczek <> Fri, 02 November 2018 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCC331276D0; Fri, 2 Nov 2018 11:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rMihIIFhHQNz; Fri, 2 Nov 2018 11:21:58 -0700 (PDT)
Received: from ( [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71302124C04; Fri, 2 Nov 2018 11:21:58 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id wA2ILoVV008561; Fri, 2 Nov 2018 19:21:50 +0100
Received: from (localhost []) by (Postfix) with ESMTP id 9780B4BB47; Fri, 2 Nov 2018 19:21:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id oLz_D1lh5_0u; Fri, 2 Nov 2018 19:21:54 +0100 (CET)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 084D54BB42; Fri, 2 Nov 2018 19:21:50 +0100 (CET)
Date: Fri, 02 Nov 2018 19:21:49 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Robert Sparks <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 ( []); Fri, 02 Nov 2018 19:21:50 +0100 (CET)
X-Miltered: at korolev with ID 5BDC95BE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5BDC95BE.000 from<>
X-j-chkmail-Score: MSGID : 5BDC95BE.000 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Nov 2018 18:22:01 -0000

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

Noted, will do.

>>> The protocol allows for multiple HMAC algorithms, but has no mechanism for
>>> signaling which one was used.

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

> 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

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.

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

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


-- Juliusz