Re: [Babel-users] MAC rekeying in babeld and information model
> From: Juliusz Chroboczek > > > 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 :) > > 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. 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
> > 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. 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. > > 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. 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
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 > > > > Juliusz Chroboczek 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 > > > > > > > > > > > > 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? > > > > 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
> -Original Message- > From: Toke Høiland-Jørgensen > Sent: Friday, January 17, 2020 6:27 AM > To: Juliusz Chroboczek ; babel-us...@lists.alioth.debian.org > Cc: STARK, BARBARA H ; ba...@ietf.org > Subject: Re: [Babel-users] MAC rekeying in babeld and information model > > Juliusz Chroboczek 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 > > > > > > > > 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? > > 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] Reworked implementation of Babel-over-DTLS
> I’ve finally managed to rework my implementation of Babel-over-DTLS > (spoiler: it seems to be working). Thanks to Juliusz for the help. Cool. This is great. > It is unclear to me how the user interface to provide certificates and private > keys should look like, and if we prefer CA certificates or self-signed. > Perhaps > the draft should be more specific about that. Since no one else answered, here are my opinions... My reading of the babel-dtls draft (and DTLS references) is 2 types of certificates are mentioned: X.509 is mandatory and Raw Public Key is optional. Raw Public Key has no signature (self or CA). X.509 can be self-signed or signed by someone else (i.e., a CA). In all cases, the implementation needs (somehow) to be configured with the certificates it trusts for use with Babel. If CAs are going to be trusted to sign usable-for-my-Babel-network certs, then the implementation needs to be configured with CA X.509 certificates that are trusted by the owner of the Babel network. For a basic implementation, I would suggest having a Babel trust store for certificates that are directly trusted for use with Babel (independent of whether or how they are signed). If the certificate is in the Babel trust store, it's trusted. If you also want to support CA-signed trust of X.509 certificates (that are not yet in the Babel trust store), then you need a store of trusted Babel CA certificates. This store MUST NOT be the same trust store used for any web browsers or software updates, etc. It MAY be a trust store of CAs trusted to sign certificates for devices allowed to operate on this (local or virtually local) network. Even if you support CA-signed, you can store received certificates signed by trusted CAs in the "directly trusted" Babel store for future direct trust. As for user interface: One way to do this simply would be to allow a person to provide a file (for trusted certificates) with one or more certificates in PEM format. For the device's own certificate, you could probably get it to generate its own (self-signed certificate) and then provide a file with the certificate in PEM format (that you can then load into other devices). Since the certificate was locally generated, it will already have the private key -- so you won't need to deal with that. All certificate-generating utilities support PEM. If you're running a CA that will generate all the certificates and associated private keys, you'll need to see what file formats that CA implementation supports, for exporting certificates and private keys. Then support that. PEM will likely be supported, but you'll need to see how Certificate+Key gets done. Barbara ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
FYI. IETF policies re "downrefs" in standards track RFCs is described in https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/html/rfc8067). In short, it's not prohibited, but careful review is required. Note RFC3967 Section 2 first bullet There are a number of circumstances in which an IETF document may need to make a normative reference to a document at a lower maturity level, but such a reference conflicts with Section 4.2.4 of [RFC2026]. For example: o A standards track document may need to refer to a protocol or algorithm developed by an external body but modified, adapted, or profiled by an IETF informational RFC, for example, MD5 [RFC1321] and HMAC [RFC2104]. Note that this does not override the IETF's duty to see that the specification is indeed sufficiently clear to enable creation of interoperable implementations. Barbara > Dave Taht writes: > > > https://tools.ietf.org/html/rfc7693 is informational. Is that good > enough? > > That's what I'm not sure about; it's neither standards track nor backed by a > working group. So someone with more knowledge of IETF process than me > needs to weigh in here :) > -Toke > > ___ > babel mailing list > ba...@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_babel=DwICAg=LFYZ- > o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=- > 6LF6X6DzeRccquqfCJFAeSx31uwzB0oM82nApUzuPo=1QakSDy0dO0qZVEb > YiyJb6tj_NKEToWqiVanTi-rv6k= ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
