Re: [babel] Proposed appendix to Babel-HMAC

["STARK, BARBARA H" <[e-mail]>]

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
> 
> 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=