Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd)

David Schinazi <dschinazi.ietf@gmail.com> Tue, 27 November 2018 21:53 UTC

Return-Path: <dschinazi.ietf@gmail.com>
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 66259130E1B for <babel@ietfa.amsl.com>; Tue, 27 Nov 2018 13:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 i3gRA_9vWfca for <babel@ietfa.amsl.com>; Tue, 27 Nov 2018 13:53:56 -0800 (PST)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 A5268130DC4 for <babel@ietf.org>; Tue, 27 Nov 2018 13:53:56 -0800 (PST)
Received: by mail-pg1-x52e.google.com with SMTP id 70so8464253pgh.8 for <babel@ietf.org>; Tue, 27 Nov 2018 13:53:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VmYGdW/mL1g537ZCUgtQPJ6fTh3DFHwDQPsdwXqekHs=; b=KBxJKXdREwOBjaQfjfVPEHD2nvMByXys3bx+Gl4wUVyoVJ4vAubKRxR1eQCIxnSOcp vdMyslbQmJ7ZuQGIeaG5bB9HhVHxzqCoKDN9bM5KXjIxw+0qSp+PugbFjzLvcM9ROZr9 vU/BqfGAJAaOnMlKKIwtbFwyOyrbHi2pduo78NG3zlLSVGem/HZTsbM2tHDLm0ZjyFJm YakisnIIhFiZKHrO/Sd8y10Z3SNCt4oTd+FQvnCDLxgjV2vXXMJtaq+GP8Qzo+PvM1re ZI82vCUe+7sddmoBSQZZq/n0RXB5LUn66TGE6KXQ+1qW0rcWQ+tRDuzdXEdZNAqrmuEC eynw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VmYGdW/mL1g537ZCUgtQPJ6fTh3DFHwDQPsdwXqekHs=; b=N4pNVLMEzIx4fKd5/2SaX1KTz3UBpWN3SQPTXtILMHGEXgilPABKsjQ+JLYJ0nQdyA UxGpLmn+nfQ3Q4YrxPW9s/dQtloer2Nt67OblNGpbPMNi/JP05HsctztocQrsddiBLaY 8o02eKQLkcEuEzvxWhH8Y077HwHbS5BT6JY0yh7eYeGyq9WwoZCHJ6EbOlkQwatgW7/Y MelutqSnAulJ70qdyAFNp+mRnjuKRhBDSlNhChrjPaWRnk9xeq4XiBRSMuP01jV9RkPf fGNMm1hc1ht0XToeqZT8EUBvTsuAzv6WxMVMTPHZ2nClv1Kfjy+4Ea3W3/XBUaKHdvyO VSRg==
X-Gm-Message-State: AGRZ1gKJHbp6fzr5U9krxE3lOAEs+kYQ1YeV3Ql9PChGMnvERTaGmrly mGGHoWcgzT4Ub23JTcreQ0ZN5cxdcuWAAqTS5E5e71oG
X-Google-Smtp-Source: AJdET5exLdWS8QMQxyGQ3w32ytqKxeMumkekMj52xJyJirquR8Hvc63OXomuwGTof/JDS7xCbnYStVzzp/LAD3Xeic4=
X-Received: by 2002:a62:6ec8:: with SMTP id j191mr34641179pfc.198.1543355635739; Tue, 27 Nov 2018 13:53:55 -0800 (PST)
MIME-Version: 1.0
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <CAA93jw6268QC1kmHEasJ-FbyXL_mgfQc_C-6cdksHd02ceb2Kw@mail.gmail.com> <87k1kzwnmn.fsf@toke.dk> <CAA93jw756p-78D5ciJEeXa0fpMAaFXBJEn+km8d5HCA3dX9eDw@mail.gmail.com> <877egzwkc2.fsf@toke.dk>
In-Reply-To: <877egzwkc2.fsf@toke.dk>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 27 Nov 2018 13:53:44 -0800
Message-ID: <CAPDSy+7bLenrRpkJTpc_4qN-rpoEgfO6iYUEWx74ma--6GHRrQ@mail.gmail.com>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>
Cc: Dave Taht <dave.taht@gmail.com>, babel@ietf.org, babel-users@lists.alioth.debian.org
Content-Type: multipart/alternative; boundary="0000000000006e30b7057bac7cd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/lGdKzo-ea58kmNvBhYdxktIhrpo>
Subject: Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd)
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: Tue, 27 Nov 2018 21:54:11 -0000

Maybe I'm misunderstanding, but I think this issue is not comparable to
DNSSEC. The key difference here (no pun intended) is that you can operate
Babel-HMAC with multiple keys at the same time. So your rollover becomes a
simple two step process:
0) all routers are functioning with OLD_KEY configured
1) go into all routers one by one and configure them to use both OLD_KEY
and NEW_KEY
2) go into all routers one by one and configure them to only use NEW_KEY
3) profit

You don't need any notion of time, or any added complexity to the spec.

If some of the routers are down during step (1), you get to decide whether
to either wait for them to come back, or skip them and effectively
disconnect them from the network based on the urgency of your key rollover.
Anything beyond that becomes a key management problem that is specific to
your deployment, not to the routing protocol you use.

On Mon, Nov 26, 2018 at 2:22 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Dave Taht <dave.taht@gmail.com> writes:
>
> > On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
> >>
> >> Dave Taht <dave.taht@gmail.com> writes:
> >>
> >> > To me this leaves the biggest problem remaining is key rotation. Me
> >> > being me, and remembering just how hard it was to get dnssec working
> >> > on systems lacking reliable time,
> >>
> >> The Babel HMAC extension as currently specified does not rely on wall
> >> clock time in any way, so not really sure how a comparison to dnssec is
> >> relevant?
> >
> > More below. Relative time is ok, too. 3000 seconds from now, start
> > rolling over. Stop signing records with the old key as soon as
> > everyone you can currently hear uses the new key, 6000 seconds from
> > now, retire the old key unconditionally.
>
> Well, you would handle this by whatever mechanism you use to configure
> your routers in the first place...
>
> >> > Setting that aside for the moment, having a standardized file format
> >> > for babel keys would be a boon and boost interoperability between
> >> > bird/babel and other possible implementations.
> >>
> >> From the point of view of each routing daemon this would just make Babel
> >> a special snowflake.
> >
> > ok. That leaves how to get new keys into nodes running different
> > daemons. Anyone for IKEv2?
> >
> > My out of bound way is via scp and ssh.
>
> I think Juliusz' insistence that we shouldn't reinvent key distribution
> is wise. See above; you need to configure the daemons in the first place
> anyway...
>
> > Also the present babeld cannot rewrite it's entire config file (so far
> > as I know). I think bird can...
>
>
> Yup, a 'bird reconfigure' will re-read the entire config file and apply
> it if it parses successfully.
>
> > but I don't trust it.
>
> Your trust issues are probably best resolved between you and your daemon ;)
>
> >> What we can do is to specify the format in the information model if a
> >> cross-implementation format is really needed (which I'm not really
> >> convinced of, either)...
> >
> > To quote from appendix A:
> >
> > "In order to perform key rotation, the new key is added to all the
> > nodes; once this is done, both the old and the new key are sent in all
> > packets, and packets are accepted if they are properly signed by
> > either of the keys. At that point, the old key is removed."
> >
> > My key points made here are "the new key is added to *all* the
> > nodes"... which may or may not be up over the course of days, or weeks
> > for whatever definition of "all" you have ... "Once this is done" -
> > how can you tell? -  "and packets are accepted if they are properly
> > signed by either of the keys" hopefully you log this ... "the old key
> > is removed".
> >
> > perhaps "deprecated, no longer actively used for signing, then removed
> > after a suitable period"?
>
> Hmm, having a way to mark a key as "verify only" may be useful for
> simpler monitoring. But really, you *could* derive the same information
> from the opposite bit (track how many neighbours don't sign with the new
> key yet). So then it becomes more of an efficiency issue (you could save
> one signature on the wire during rotation). Not sure if it's worth
> specifying another bit in the spec for this? Or if such a configuration
> mode should even be in the spec at all?
>
> > So, if you do a key rotation and X routers are offline or inaccessible
> > at that particular time... they are going to stay inaccessible
> > forevermore, unless rekey'd via sneakernet, climbing on trees, and
> > other forms of manual intervention.
>
> Presumably your key rotation policy would take into account the outage
> schedules of the routers in your network? :)
>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users