Subject: [babel] MAC rekeying in babeld and information model

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 16 Jan 2020 19:45:36 +0100

Dear all,

Antonin and I have spent the afternoon looking at his work on MAC rekeying
in babeld.  His code is available in branch hmac-rekeying of

    https://github.com/MisterDA/babeld

Now... we've got an issue with the information model.

Following the information model, Antonin adds the following attribute to
keys:

   key-use sign|verify|both

I'm a little puzzled by the purpose of this attribute.  What usage
scenarios is it useful in?  In particular, it does not appear to subsume
the sign-only interface attribute, which is useful in incremental
deployment scenarios.

Thanks,

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 17 Jan 2020 12:27:08 +0100

> the sign-only interface attribute, which is useful in incremental

Hmm, I think this notion originally comes from Bird's password
configuration support?
https://bird.network.cz/?get_doc&v=20&f=bird-3.html - search for 'password'.

I guess you could use it for a kind of asymmetrical verification
procedure? I.e., a route server could have its own key that it signs
with, that all peers with the route server will accept, but each peer
has its own key it signs with, that the route server is set up to
accept. That way the peers wouldn't peer with each other, but all go
through the route server? This would not prevent malicious actors, of
course (they could just start signing with the route server's key), but
it could prevent accidental misconfiguration.

Dunno exactly what the original intention with the Bird option is,
though. I can ask on the Bird list?

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 17 Jan 2020 14:51:29 +0000

> -----Original Message-----
> From: Toke Høiland-Jørgensen <[email-masked]>
> Sent: Friday, January 17, 2020 6:27 AM
> To: Juliusz Chroboczek <[email-masked]>; [email-masked]
> Cc: STARK, BARBARA H <[email-masked]>; [email-masked]
> Subject: Re: [Babel-users] MAC rekeying in babeld and information model
> 
> > Antonin and I have spent the afternoon looking at his work on MAC
> > rekeying in babeld.  His code is available in branch hmac-rekeying of
> >
> > <URL mauled by AT&T mail system>
> >
> > scenarios is it useful in?  In particular, it does not appear to
> > subsume the sign-only interface attribute, which is useful in
> > incremental deployment scenarios.
> 
> Hmm, I think this notion originally comes from Bird's password configuration
> support?
> <URL mauled by AT&T mail system>
> search for 'password'.
> 
> I guess you could use it for a kind of asymmetrical verification procedure?
> I.e., a route server could have its own key that it signs with, that all peers
> with the route server will accept, but each peer has its own key it signs with,
> that the route server is set up to accept. That way the peers wouldn't peer
> with each other, but all go through the route server? This would not prevent
> malicious actors, of course (they could just start signing with the route
> server's key), but it could prevent accidental misconfiguration.
> 
> Dunno exactly what the original intention with the Bird option is, though. I
> can ask on the Bird list?
> 
> -Toke

I don't remember precisely and would need to go looking for the emails. I think it did come from Toke's comments. But if an implementation doesn't support asymmetric signing, it can just hard-code the parameter to "both", not allow configuration of the parameter, and be done with it.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 17 Jan 2020 15:13:54 +0000

BTW, I just looked at the -10 revision of 
https://tools.ietf.org/html/draft-ietf-babel-information-model-10

Since that revision has Boolean (true/false) parameters of babel-key-use-sign and babel-key-use-verify (but not key-use with values of sign/verify/both), I did want to be sure we were talking about the right model revision.
Barbara

> From: STARK, BARBARA H
> > I.e., a route server could have its own key that it signs with, that
> > all peers with the route server will accept, but each peer has its own
> > key it signs with, that the route server is set up to accept. That way
> > the peers wouldn't peer with each other, but all go through the route
> > server? This would not prevent malicious actors, of course (they could
> > just start signing with the route server's key), but it could prevent
> accidental misconfiguration.
> >
> > though.. I can ask on the Bird list?
> >
> > -Toke
> 
> I don't remember precisely and would need to go looking for the emails. I
> think it did come from Toke's comments. But if an implementation doesn't
> support asymmetric signing, it can just hard-code the parameter to "both",
> not allow configuration of the parameter, and be done with it.
> Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 19 Jan 2020 14:14:29 +0100

> Since that revision has Boolean (true/false) parameters of
> babel-key-use-sign and babel-key-use-verify (but not key-use with values
> of sign/verify/both), I did want to be sure we were talking about the
> right model revision.

The second part of my inquiry -- how does the information model enable
incremental deployment?  Section 5 of draft-ietf-babel-mac.

Toke, it would be helpful if we could understand what key-use is intended
for.  My personal opinion right now is that we should:

  - remove key-use from the draft;

  - add a per-interface configuration "allow-unauthentified", which, if set,
    causes all packets received on that interface to be accepted, whether
    signed, unsigned, or incorrectly signed.

Incremental deployment is an important feature, and I think that we need
to make really sure that the information model allows it.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 20 Jan 2020 16:23:56 +0000

> > babel-key-use-sign and babel-key-use-verify (but not key-use with
> > values of sign/verify/both), I did want to be sure we were talking
> > about the right model revision.
> 

Incremental deployment is enabled through the interfaces object babel-mac-verify parameter. Set this parameter to false until all routers have key(s). Then set to true.

> Incremental deployment is an important feature, and I think that we need to
> make really sure that the information model allows it.

The key-use-sign and key-use-verify are only peripherally involved in incremental deployment and key rotation -- you need to have at least one key with key-use-verify=true and key-use-sign=true. The common case when incrementally deploying will be to provide a single key with valid and sign = true and all interfaces' babel-mac-verify = false. Once all routers have the key, set babel-mac-verify to true in all routers. When rotating, the common case will be to provide an additional key with valid and sign = true. Once the new key is in all routers, delete old one.

I don't think an additional per-interface parameter is needed. I think babel-mac-verify should be fine. If the group wants to remove the key-use parameters and only support symmetrical keying, I have no objection. We could also make those parameters optional-to-implement (square brackets), with the expectation that an implementation wouldn't implement them if it only supports symmetric keying.
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 20 Jan 2020 17:28:34 +0100

Juliusz Chroboczek <[email-masked]> writes:

> for.

I've asked on the Bird list (cc'ed to babel@ietf).

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 20 Jan 2020 20:54:41 +0100

> Incremental deployment is enabled through the interfaces object
> babel-mac-verify parameter. Set this parameter to false until all
> routers have key(s). Then set to true.

Ah, ok.  That's fine, then, sorry for missing it.

> I don't think an additional per-interface parameter is needed. I think
> babel-mac-verify should be fine.

Agreed.

> If the group wants to remove the key-use parameters and only support
> symmetrical keying, I have no objection. We could also make those
> parameters optional-to-implement (square brackets), with the expectation
> that an implementation wouldn't implement them if it only supports
> symmetric keying.

Shall we wait for Toke to express an opinion?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 21 Jan 2020 14:39:03 +0100

> Shall we wait for Toke to express an opinion?

As I just replied in the other thread: The Bird implementation is going
to have this facility no matter what we specify in the spec, but I'm
fine with having it optional, or omitting it from the spec entirely, as
long as we don't forbid having a key-use parameter :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 21 Jan 2020 14:45:30 +0100

> long as we don't forbid having a key-use parameter :)

It is my understanding that it's already effectively optional -- it can be
exported as read-only (paragraph 3.9 of the draft).  I suggest we let
Barbara decide whether she wants to explicitly mark it as optional.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 Jan 2020 18:00:00 +0000

> From: Juliusz Chroboczek <[email-masked]>
> 
> > As I just replied in the other thread: The Bird implementation is
> > going to have this facility no matter what we specify in the spec, but
> > I'm fine with having it optional, or omitting it from the spec
> > entirely, as long as we don't forbid having a key-use parameter :)
> 
> exported as read-only (paragraph 3.9 of the draft).  I suggest we let Barbara
> decide whether she wants to explicitly mark it as optional.

I find it confusing to have parameters an implementation has no use for. The "MAY choose to expose as read-only" is actually a bit awkward in this case, since ideally, users can add entries to the object (in which case it's weird to have read-only parameters set by the implementation). It's not disallowed -- just weird. I would like to mark them optional to implement. I don't think this would impact the YANG model (because the YANG model doesn't deal with the mandatory/optional to implement aspects of the spec)?
Barbara