Re: [babel] Proposed appendix to Babel-HMAC

[Dave Taht <[e-mail]>]

On Mon, Jan 21, 2019 at 1:40 PM STARK, BARBARA H <[e-mail]> wrote:
>
> 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.

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.

> Barbara
>
> > -----Original Message-----
> > From: Dave Taht
> >
> > Juliusz Chroboczek <[e-mail]> writes:
> >
> > > 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).
> >
> > 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.
> >
> > > 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.
> >
> > 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
> > > -------------------------------------------------
> > >
> > > 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
> >
> > spelling:relevant.
> >
> > > HTTP monster, or something as elegant as a secure hop-to-hop flooding
> > > algorithm.
> >
> > 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"
> >
> > > 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.
> >
> > Feel free to reference hnet here...
> >
> > >
> > > _______________________________________________
> > > babel mailing list
> > > [e-mail]
> > > 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=
> >
> > _______________________________________________
> > babel mailing list
> > [e-mail]
> > 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=
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: [phone]