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

[STARK, BARBARA H]

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
> 
> > From: Toke Høiland-Jørgensen <toke at toke.dk>
> >
> > 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