<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 8:57 AM Kain, Becki (.) <<a href="mailto:bkain1@ford.com">bkain1@ford.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why ever would have a card reader on your external facing network, if that was really the case why they couldn't get in to fix it?<br></blockquote><div><br></div><div>Let's hypothesize for a moment.</div><div><br></div><div>Let's suppose you've decided that certificate-based </div><div>authentication is the cat's meow, and so you've got </div><div>dot1x authentication on every network port in your </div><div>corporate environment, all your users are authenticated </div><div>via certificates, all properly signed all the way up the </div><div>chain to the root trust anchor.</div><div><br></div><div>Life is good.</div><div><br></div><div>But then you have a bad network day.  Suddenly, </div><div>you can't talk to upstream registries/registrars, </div><div>you can't reach the trust anchor for your certificates, </div><div>and you discover that all the laptops plugged into </div><div>your network switches are failing to validate their </div><div>authenticity; sure, you're on the network, but you're </div><div>in a guest vlan, with no access.  Your user credentials </div><div>aren't able to be validated, so you're stuck with the </div><div>base level of access, which doesn't let you into the </div><div>OOB network.</div><div><br></div><div>Turns out your card readers were all counting on </div><div>dot1x authentication to get them into the right vlan </div><div>as well, and with the network buggered up, the </div><div>switches can't validate *their* certificates either, </div><div>so the door badge card readers just flash their </div><div>LEDs impotently when you wave your badge at </div><div>them.</div><div><br></div><div>Remember, one attribute of certificates is that they are </div><div>designated as valid for a particular domain, or set of </div><div>subdomains with a wildcard; that is, an authenticator needs </div><div>to know where the certificate is being presented to know if </div><div>it is valid within that scope or not.   You can do that scope </div><div>validation through several different mechanisms, </div><div>such as through a chain of trust to a certificate authority, </div><div>or through DNSSEC with DANE--but fundamentally, </div><div>all certificates have a scope within which they are valid, </div><div>and a means to identify in which scope they are being </div><div>used.  And wether your certificate chain of trust is </div><div>being determined by certificate authorities or DANE, </div><div>they all require that trust to be validated by something </div><div>other than the client and server alone--which generally </div><div>makes them dependent on some level of external </div><div>network connectivity being present in order to properly </div><div>function.   [yes, yes, we can have a side discussion about </div><div>having every authentication server self-sign certificates </div><div>as its own CA, and thus eliminate external network </div><div>connectivity dependencies--but that's an administrative </div><div>nightmare that I don't think any large organization would</div><div>sign up for.]</div><div><br></div><div>So, all of the client certificates and authorization servers </div><div>we're talking about exist on your internal network, but they </div><div>all counted on reachability to your infrastructure </div><div>servers in order to properly authenticate and grant </div><div>access to devices and people.  If your BGP update </div><div>made your infrastructure servers, such as DNS servers, </div><div>become unreachable, then suddenly you might well </div><div>find yourself locked out both physically and logically </div><div>from your own network.</div><div><br></div><div>Again, this is purely hypothetical, but it's one scenario </div><div>in which a routing-level "oooooops" could end up causing </div><div>physical-entry denial, as well as logical network access </div><div>level denial, without actually having those authentication </div><div>systems on external facing networks.</div><div><br></div><div>Certificate-based authentication is scalable and cool, but </div><div>it's really important to think about even generally "that'll </div><div>never happen" failure scenarios when deploying it into </div><div>critical systems.  It's always good to have the "break glass </div><div>in case of emergency" network that doesn't rely on dot1x, </div><div>that works without DNS, without NTP, without RADIUS, </div><div>or any other external system, with a binder with printouts </div><div>of the IP addresses of all your really critical servers and </div><div>routers in it which gets updated a few times a year, so that </div><div>when the SHTF, a person sitting at a laptop plugged into </div><div>that network with the binder next to them can get into the </div><div>emergency-only local account on each router to fix things.</div><div><br></div><div>And yes, you want every command that local emergency-only </div><div>user types into a router to be logged, because someone <br></div><div>wanting to create mischief in your network is going to aim </div><div>for that account access if they can get it; so watch it like a </div><div>hawk, and the only time it had better be accessed and used </div><div>is when the big red panic button has already been hit, and </div><div>the executives are huddled around speakerphones wanting </div><div>to know just how fast you can get things working again.  ^_^;</div><div><br></div><div>I know nothing of the incident in question.  But sitting at home,</div><div>hypothesizing about ways in which things could go wrong, this </div><div>is one of the reasons why I still configure static emergency </div><div>accounts on network devices, even with centrally administered </div><div>account systems, and why there's always a set of "no dot1x" </div><div>ports that work to get into the OOB/management network even </div><div>when everything else has gone toes-up.   :)</div><div><br></div><div>So--that's one way in which an outage like this could have </div><div>locked people out of buildings.   ^_^;</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div>[ready for the deluge of people pointing out I've overly simplified the </div><div>validation chain for certificates in order to keep the post short and </div><div>high-level.   ^_^; ]</div></div></div>