On Tue, Oct 22, 2019 at 2:21 PM Bjørn Mork <bjorn@mork.no> wrote:
Christopher Morrow <morrowc.lists@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-... 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.