[Babel-users] [babel] Reworked implementation of HMAC authentication

[Mahesh Jethanandani]

I believe I had brought this up before. There is a YANG keychain model (RFC 8177) that might help provide some guidance here.

But before we get there, there is one clarification. There is no babel-security-obj any more. The current tree diagram for babel is as follows ...

   +-- babel-information
      +-- babel-implementation-version
      +-- babel-enable
      +-- router-id
      +-- babel-supported-link-types
      +-- self-seqno
      +-- babel-metric-comp-algorithms
      +-- babel-security-supported
      +-- babel-hmac-enable
      +-- babel-hmac-algorithms
      +-- babel-dtls-enable
      +-- babel-dtls-cert-types
      +-- babel-stats-enable
      +-- babel-stats-reset
      +-- babel-constants

… with security configured by whether HMAC is enabled or not, and whether DTLS is enabled or not. And there is no reference to a per-interface configuration. So, currently, as defined, both HMAC and DTLS are global. Based on what I am reading here, it appears that is not what was intended. So I will join Barbara in saying we do not want to cause a rebellion by suggesting something totally radical here :-)

BTW, do we want to maintain the ability to have a global config for security such that it applies to all interfaces? 

Back to the question at hand, and the guidance that the keychain model provides for symmetric keys used by routing protocols. Again this is the YANG tree diagram for keychains.

   +--rw key-chains
      +--rw key-chain* [name]
      |  +--rw name                       string
      |  +--rw description?               string
      |  +--rw accept-tolerance {accept-tolerance}?
      |  |  +--rw duration?   uint32
      |  +--ro last-modified-timestamp?   yang:date-and-time
      |  +--rw key* [key-id]
      |     +--rw key-id                    uint64
      |     +--rw lifetime
      |     |  +--rw (lifetime)?
      |     |     +--:(send-and-accept-lifetime)
      |     |     |  +--rw send-accept-lifetime
      |     |     |     +--rw (lifetime)?
      |     |     |        +--:(always)
      |     |     |        |  +--rw always?            empty
      |     |     |        +--:(start-end-time)
      |     |     |           +--rw start-date-time?
      |     |     |           |       yang:date-and-time
      |     |     |           +--rw (end-time)?
      |     |     |              +--:(infinite)
      |     |     |              |  +--rw no-end-time?       empty
      |     |     |              +--:(duration)
      |     |     |              |  +--rw duration?          uint32
      |     |     |              +--:(end-date-time)
      |     |     |                 +--rw end-date-time?
      |     |     |                         yang:date-and-time

What this implies is that key-chains are declared globally, and each key-chain, indexed by a name, defines a bunch of keys, referenced by a key-id, each of which have their own lifetime, both on the send and receive side.

If the desire is to have a key per interface, that interface would then have a reference to one of the key-chains. Ideally, a separate key rotation protocol decides which key is used out of the chain. But since we never quite got around to defining that protocol in KARP, each implementation is left to decide how to pick the key. Sharing of keys between interfaces can be had by having both interfaces refer to the same keychain. 

Few things would have to happen to the existing documents in Babel. The IM should be updated to provide a reference from the interface to the babel-hmac-obj/babel-dtls-obj, and add a reference to a keychain instead of a key itself. If a global security configuration is desired, where every flag gets the same security configuration, then we will need a global flag to state so. Secondly, in the YANG model for Babel, we augment the keychain model to support ability to add/delete/rotate/synchronize keys separately, and update the data model to mirror any changes we make to the IM.

Cheers.

> On Mar 12, 2019, at 5:45 AM, Toke Høiland-Jørgensen <toke=40toke.dk at dmarc.ietf.org> wrote:
> 
> Juliusz Chroboczek <jch at irif.fr> writes:
> 
>>> FWIW, Bird will also use the simpler mechanism (a key is part of the
>>> iface config).
>> 
>> How do you share a key between interfaces?
> 
> You can set them globally or per-interface (interface options in general
> are just overrides of the global per-protocol options). I'm not sure
> what happens if you set both, actually.
> 
> If you want to, say, use the same key on two interfaces, but not a
> third, you'd have to copy the config line to both interface configs.
> 
> There are also a bunch of per-key options, such as active times and an
> ID. See the 'password' entry here:
> https://bird.network.cz/?get_doc&v=20&f=bird-3.html#ss3.3
> 
> I haven't played around with this extensively, but am planning to do
> that once I get around to updating the implementation to the latest
> version of the draft...
> 
> -Toke
> 
> _______________________________________________
> babel mailing list
> babel at ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/babel-users/attachments/20190312/ac9766e6/attachment.html>