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

Robert Sparks <rjsparks@nostrum.com> Fri, 02 November 2018 15:45 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C8126BED; Fri, 2 Nov 2018 08:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8smLR2ohVud; Fri, 2 Nov 2018 08:45:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E83124D68; Fri, 2 Nov 2018 08:45:36 -0700 (PDT)
Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA2FjY7L037801 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Nov 2018 10:45:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local
To: Juliusz Chroboczek <jch@irif.fr>
Cc: secdir@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org
References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> <87ftwjpz60.wl-jch@irif.fr>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com>
Date: Fri, 2 Nov 2018 10:45:34 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87ftwjpz60.wl-jch@irif.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ijVcY69x5G-Q82-54246_7IMxRA>
Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Nov 2018 15:45:38 -0000


On 11/2/18 5:11 AM, Juliusz Chroboczek wrote:
> Dear Robert,
>
> Thank you very much for your review.
>
>> Issues:
>> 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.)
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?
>
>> 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 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?
No, that's all moot.
>
>> 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.
> 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.
>
>> 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.
> 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...
>
>> It would be worth building an example of bootstrapping the protocol between
>> 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.
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.
>
>> 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.
> 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