Subject: [babel] Proposed appendix to Babel-HMAC

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Jan 2019 01:12:16 +0100

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.

---

From: Dave Taht <[email-masked]>
Date: Sat, 19 Jan 2019 06:09:49 -0800

> Key representation

human slavery is usually not in the domain of the ietf, and is usually
only in the domain of corporations and oppressive governments.

yes, I laughed, but there is a huge movement to rid the language of the
master/slave analogy across all of tech.

> wrong size should be rejected rather than extended or hashed.

I figure I've lost on the BASE64 idea. Still I felt 0xthekey for hex was
a good idea rather than just thekey

> Static provisioning through a management protocol

spelling:relevant.

> HTTP monster, or something as elegant as a secure hop-to-hop flooding

It is obvious that some frustration and perhaps, vodka, were leaking
through this proposed appendix.

", something as complex as XML over HTTP, or a secure hop-to-hop"

> link-local IPv6 communication.

Feel free to reference hnet here...

>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 21 Jan 2019 21:39:46 +0000

Hi Dave,
I'm not sure this proposed appendix is still being considered? In mine and Juliusz' last exchange re the babel-hmac draft, I said I would be satisfied with an easy-to-fine (i.e., in the Table of Contents) definition for the term "HMAC Key" in the draft. Which we agreed was 
## The HMAC Key
The HMAC key is a string of bytes the length of which is exactly the 
block size of the HMAC algorithm being used. Note this is different 
from the [RFC2104] definition.

This doesn't specify base64 or hex format.

But in the information model, I proposed the parameter be binary datatype (noting that I would be using a hexBinary datatype with the TR-181 data model). No-one disagreed with me, so I declared the decision made. 

If we think there is value in an appendix on configuration of the HMAC key, I'm fine with that. But I sense an anxiousness to proceed with declaring WGLC triumphant and sending babel-hmac on to IESG. Alternately, I could see such an appendix potentially belonging in the information-model -- where it wouldn't clutter up hmac-babel, and where we could also discuss (more generically) distribution of credentials.
Barbara

> -----Original Message-----
> From: Dave Taht
> 
> > 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.
> >
> > 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).
> 
> human slavery is usually not in the domain of the ietf, and is usually only in
> the domain of corporations and oppressive governments.
> 
> > implementations support a configuration syntax where the key is
> > expressed as a string of hexadecimal digits (both uppercase or
> > lowercase should be
> > hexadecimal digits for a SHA-256 key).  It is recommended that keys of
> > the wrong size should be rejected rather than extended or hashed.
> 
> I figure I've lost on the BASE64 idea. Still I felt 0xthekey for hex was a good
> idea rather than just thekey
> 
> > [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.
> >
> > 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
> 
> spelling:relevant.
> 
> It is obvious that some frustration and perhaps, vodka, were leaking through
> this proposed appendix.
> 
> > 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.
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_babel&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8T
> >
> q4vrfog&m=rVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=uSNNUw
> MZqU_Co5
> > Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=rVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=
> uSNNUwMZqU_Co5Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=

---

From: Dave Taht <[email-masked]>
Date: Mon, 21 Jan 2019 13:46:46 -0800

> If we think there is value in an appendix on configuration of the HMAC key, I'm fine with that. But I sense an anxiousness to proceed with declaring WGLC triumphant and sending babel-hmac on to IES…

I can live with this approach.

If the appendix is considered necessary anywhere I would substitute
"human minions" for "human slaves" as being more PC.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 22 Jan 2019 17:32:32 +0100

Barbara said:

> I'm not sure this proposed appendix is still being considered?

My understanding is the same as Barbara's, we're no longer doing an
appendix.

> But in the information model, I proposed the parameter be binary
> datatype (noting that I would be using a hexBinary datatype with the
> TR-181 data model).

Perhaps you might mention that hex is the preferred human-readable format
for this particular piece of data?

> If we think there is value in an appendix on configuration of the HMAC
> key, I'm fine with that.

It makes me a little uncomfortable -- I'd rather we didn't give any
implementation advice until we've got more implementation experience.
(How many times have you looked at an RFC, started to implement the advice
in their informative appendix, just to find out that it cannot reasonably
be implemented, or at least not without a lot more work than the appendix
implies?)

> "human minions" for "human slaves" as being more PC.

Heh.  You do realise that the word has sexual undertones in French?

-- Juliusz