[Babel-users] MAC rekeying in babeld and information model

[STARK, BARBARA H]

> -----Original Message-----
> From: Toke Høiland-Jørgensen <toke at toke.dk>
> Sent: Friday, January 17, 2020 6:27 AM
> To: Juliusz Chroboczek <jch at irif.fr>; babel-users at lists.alioth.debian.org
> Cc: STARK, BARBARA H <bs7652 at att.com>; babel at ietf.org
> Subject: Re: [Babel-users] MAC rekeying in babeld and information model
> 
> Juliusz Chroboczek <jch at irif.fr> writes:
> 
> > 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
> >
> > <URL mauled by AT&T mail system>
> >
> > 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.
> 
> 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