At Thu, 27 Dec 2018 11:57:54 +0100, Bjørn Mork <[email protected]> wrote: > > Chris Morrow <[email protected]> writes: > > > tls brings with it cert issues. > > Well. How bad does it have to be? Yes, you have to manage private > keys. That's the same for TCP-AO, SSH and TLS. Or any other transport > security protocol. No real difference.
you have to at least manage private keys, plus you need to monitor/manage certificates on the devices, and rotate them over time. you probably do NOT want to just place a ~forever certificate on your device(s) and you probably want some unique identification per device/certificate. you probably want CRL checking as well... and you need to operate a CA in a semi-secure fashion. you must be able to revoke certs, check client/server certificate details upon connection(s) and log out appropriate details so debugging connection problems is a reasonably quick effort. the devices must have a reasonable method to manage the actual cert/key content, with a reasonable method to refresh the certificate/key in use by the services on the device(s). There is some work in this area happening on most vendor gear I follow due to the push(ing) to use gRPC for streaming telemetry (instead of snmp) and gRPC for config management. (grpc is the new netmod is the new xml is the new .....) The certificate management MAY only work for the 'gRPC' part of the device/os though :( Looking at one particular vendor (not juniper) the 'which certificate/key to use' is very 'service' specific :( without any real mapping (except an uploaded bash script??? wtf?) of which cert/key to which service(s). it's pretty depressing to watch the myopic vendor process on this :( you must keep time sync'd reasonably closely as well. > I assume the perceived issue with TLS is that private keys have short > life spans? But they don't have to in a RPKI setup. You will want to no, you want short lifespans, think of a typical lifespan on the order of 'days'... like less than 7 days in some cases, and perhaps shorter depending upon which jurisdiction the device lands in. > manage the CA(s) yourself, and can implement the policies you need. If > you want keys with "infinite" life spans, then that's possible. The infinite is.. infinitely naive. please do not do infinite certificate lifetimes. > servers validating router certificates can easily check revoked keys, > using a simple CRL or whatever. So you can issue a certificate to your > router and just forget about ever updating it, just like you do with all > your other passwords ;-) uhm, no. this is perhaps the worst advice evar. Are you also just injecting your igp into your egp? :) > The only difference is that there is a way to actually withdraw that > password. > > TLS is nice. Don't be fooled by all the lousy infrastructure > implementations. Certificate management does not have to suck. agreed, it doesn't... except that basically all implementations for network gear are sucky (today) and bespoke. hurray, job security? :( > And there is no reason to believe that TCP-AO key management will suck > less - until we've seen it implemented. oh I agree about this... wait there's karp! (https://tools.ietf.org/wg/karp/) ha, just kidding that ended up as a pile of fail :( There are key management schemes to be cribbed from in other network device management things, particularly I think the ISIS/ospf in particular. I think both juniper/cisco offer 'key tables' as options there with timed swap from key to key. That's not an unreasonable option, except managing AO (in the case of BGP) means potentially managing quite the matrix of neigh/keys/times... and coordinating with your peers could get entertaining :( It would be better than 'I set my md5 key to "chocolate" (no quotes) in 1996.. we're still good with that, right?' :) For rpki-rtr you should have a smaller matrix of things you actually control though (2-3 cache's per device with 2-3 keys 'last, current, next') -chris _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
