[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.
- [babel] Proposed appendix to Babel-HMAC Juliusz Chroboczek
- Re: [babel] Proposed appendix to Babel-HMAC Dave Taht
- Re: [babel] Proposed appendix to Babel-HMAC STARK, BARBARA H
- Re: [babel] Proposed appendix to Babel-HMAC Dave Taht
- Re: [babel] Proposed appendix to Babel-HMAC Juliusz Chroboczek