[babel] Proposed appendix to Babel-HMAC

Juliusz Chroboczek <jch@irif.fr> Wed, 16 January 2019 00:12 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D612D4F2 for <babel@ietfa.amsl.com>; Tue, 15 Jan 2019 16:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P_tQZAYbiLj for <babel@ietfa.amsl.com>; Tue, 15 Jan 2019 16:12:22 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [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 ietfa.amsl.com (Postfix) with ESMTPS id 0D5CF126C01 for <babel@ietf.org>; Tue, 15 Jan 2019 16:12:21 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0G0CE25019894 for <babel@ietf.org>; Wed, 16 Jan 2019 01:12:14 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3B2742A7CC for <babel@ietf.org>; Wed, 16 Jan 2019 01:12:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id YSQgUEDLRHNN for <babel@ietf.org>; Wed, 16 Jan 2019 01:12:18 +0100 (CET)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 087722A7CA for <babel@ietf.org>; Wed, 16 Jan 2019 01:12:16 +0100 (CET)
Date: Wed, 16 Jan 2019 01:12:16 +0100
Message-ID: <87h8e9bgv3.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: babel@ietf.org
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 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 16 Jan 2019 01:12:14 +0100 (CET)
X-Miltered: at korolev with ID 5C3E76DE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5C3E76DE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5C3E76DE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/RgT2WxwkRNQZ4pEOq5kKv0Gydno>
Subject: [babel] Proposed appendix to Babel-HMAC
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jan 2019 00:12:24 -0000

Key representation
==================

The protocol described in this document assumes the presence of one or
more keys in entries of the interface table (Section 3.1) that have been
securely provisioned by means outside of the protocol.  In this appendix,
we describe how this provisioning might happen.

Static configuration file
-------------------------

In the simplest case, the keys are taken from a static configuration file.
When that is the case, the keys should either be drawn randomly using
a good source of entropy, or generated from a user-provided passphrase
using a good Key Derivation Function (KDF).

In either case, the keys should be distributed to all routers using a some
secure channel (e.g., ssh login or human slaves carrying USB flashkeys).
The user-provided passphrase, if any, should not be distributed to the
routers, but rather kept on a secure central host where key generation
happens.

In the interest of interoperability, it is recommended that all Babel
implementations support a configuration syntax where the key is expressed
as a string of hexadecimal digits (both uppercase or lowercase should be
accepted) of exactly the right size to yield an HMAC key (e.g., 64
hexadecimal digits for a SHA-256 key).  It is recommended that keys of the
wrong size should be rejected rather than extended or hashed.

Static provisioning through a management protocol
-------------------------------------------------

In a slightly more advanced implementation, HMAC keys are provisioned
using a management protocol, either a standard XML over HTTP horror
[NETCONF, TR-69], or an elegant ad-hoc protocol.  In that case, the keys
should be expressed in whatever format the management protocol uses for
representing raw binary data, and keys should be rejected unless they have
exactly the right size for a given HMAC algorithm (e.g., 32 octets for
a SHA-256 key).  If the management protocol has no usual syntax for binary
blobs, hexadecimal is recommended.

Key distribution protocol
-------------------------

The recommended approach is to use a centralised key distribution server
that periodically generates a new key.  In that approach, the central
server generates a new key every 20 minutes or so and installs it on all
the secure interfaces of all the routers in a given routing domain; after
all routers have been updated, the central server performs a second pass
to remove the now-obsolete keys.  The on-the-wire protocol involved could
be something as simple as connecting over ssh to every router and editing
the relevan configuration files, something as complex as a an XML over
HTTP monster, or something as elegant as a secure hop-to-hop flooding
algorithm.

It is important that the key distribution algorithm should be able to
recover from failed key installation, which may happen if a router was not
reachable at the time a new key was being installed.  In the case of
a protocol that uses global unicast, this can be ensured either by using
a separate management network, or by designing the network so that there
is a connected backbone that is not secured by HMAC.  The elegant solution
to the problem is to use a key distribution protocol that only relies on
link-local IPv6 communication.