On Tue, Oct 22, 2019 at 2:21 PM Bjørn Mork <bj...@mork.no> wrote: > > Christopher Morrow <morrowc.li...@gmail.com> writes: > > > The x.509 system, to be effective here would require a TrustAnchor / > > Root-of-Trust that both parties agreed was acceptable... > > As in a shared TrustAnchor? No. Both ends could use a simple self
as an option, sure. not a great one as you say. (and I agree, today's 'web pki' model just isn't sane for networking) > signed certificate and be configured to trust the other. A hash of the > peers public key would be sufficient for the BGP peer configuration. > This is effectively the same as the md5 problem, right? and there'd have to be a bunch of not-standard machinations in the tls connection to support this behavior... never mind: "Was that E5S or E5s gosh.. can you send me this over IM please?" :) (passing around the fingerprints is hard) > Or you could use more complex PKI models, with a CA hierarchy or > whatever. The point is that TLS doesn't force you to do that > right, I think I said that in the next paragraph: "Hey, you could use psk..." > Authenticating the peer by its public key hash is as simple as using an > TCP-MD5 password. err... is it though? 'foobarbaz' is a long simpler than: SHA1 Fingerprint=A2:A8:74:E7:3C:20:49:E4:2D:5A:6E:97:EF:B2:65:C7:59:44:1A:6E > > To get around that you propose we hopscotch over to 'TLS with > > preshared keys (PSK)'...ok, that smells nice, > > Maybe. Personally I don't see the point. I think ... if we are working away from a static 'key' and to something that could be machine managed in a secure fashion (certs, for instance) we'd be in a better place for: bgp session security bgp session integrity bgp session authentication > >> My personal major gripe with certificate based systems is that many > >> routers don't have an RTC and won't know what time it is until they can > >> NTP, which likely requires protocol adjacencies, and then a dependency > >> loop. > > > > this is also a problem, but really ... your igp should get you to an > > NTP source... or we'd all get to that fairly quickly, right? :) > > (some of this is updating 'best practices' in building / maintaining > > a network, right?) > > You may ignore notAfter and notBegin like DANE does. The ntp issue is I don't know what those fields are but: notBefore=Oct 3 17:13:51 2019 GMT notAfter=Dec 26 17:13:51 2019 GMT maybe you mean these? sure, you CAN ignore those, but that's also 'non-standard, outside openssl-like behavior' so likely to cause problems :( and, you really do want certs with expiry that's 'short' so you don't need to worry about CRL distribution and such. I think anyway. > another reason. But IMHO the most important one is that you don't want > any sort of forced key rotation, where the configuration that was valid > yesterday suddenly becomes invalid. That's a policy designed for a > completely different usecase than running a routing protocol. there are many examples of (outside x509/ssl) key management systems that use date initiated keys though, on network devices. most vendors support a key table for ISIS and OSPF... and LDP (I believe) > You'll probably want to trust your configured pinned peer key for as > long as it is part of your configuration. And if you are using a CA, that seems .. bad. What if someone gets the key material that's not your peer? https://arstechnica.com/information-technology/2019/10/hackers-steal-secret-crypto-keys-for-nordvpn-heres-what-we-know-so-far/ this doesnt' happen too often... wait, yes it does. You want the ability to CRL or expire or make a lost cert less useful. keys/certs/secrets that last forever are not a thing. > then you'll probably want to use a CRL to withdraw specific certificates > instead of depending on a timeout. CRLs imply some external dependency, maybe that's ok depending on your deployment, but I imagine that if we get to a world with a CA per peer-as, there are going to be folk very busy getting CRLs and not so busy getting routes done. there's a tradeoff for each of these things, I imagine a well reasoned paper (juilien?) and some standards (possibly) + implementer work would be necessary to get true forward movement. (and desire to actually do this work) > And before someone claims that notAfter and notBegin validation is > mandated by the RFC 5280 certificate policy - The good authors of RFC > 5280 anticipated that their "Internet applications" policy wouldn't > necessarily fit all: > > Some communities will need to supplement, or possibly replace, this > profile in order to meet the requirements of specialized application > domains or environments with additional authorization, assurance, or > operational requirements. However, for basic applications, common > representations of frequently used attributes are defined so that > application developers can obtain necessary information without > regard to the issuer of a particular certificate or certificate > revocation list (CRL). > > > BTW, using TLS for management protocols is not completely unknown. We > already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably > others I haven't touched yet. The certificate management problem is > pretty much the same for all these. You have a closed group of > clients/servers/peers using explicitly configured sessions. You want > both ends to authenticate each other. You don't necessarily want an > umbrella trust anchor in the form of a CA. Defining trust per session > is fine, using pinned certificates. to each his/her own I suspect... on the 'use pinned certs' thing. I am hoping we can imagine a better world and move there.
