<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Actually for card readers, the offline verification nature of
certificates is probably a nice property. But client certs pose
all sorts of other problems like their scalability, ease of making
changes (roles, etc), and other kinds of considerations that make
you want to fetch more information online... which completely
negates the advantages of offline verification. Just the CRL
problem would probably sink you since when you fire an employee
you want access to be cut off immediately. <br>
</p>
<p>The other thing that would scare me in general with expecting
offline verification is the *reason* it's being used is for
offline might get forgotten and back comes the online dependencies
while nobody is looking.</p>
<p>BTW: you don't need to reach the trust anchor, though you almost
certainly need to run OCSP or something like it if you have client
certs.<br>
</p>
<p>Mike<br>
</p>
<div class="moz-cite-prefix">On 10/5/21 1:34 PM, Matthew Petach
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmG1=rVjrbYQruXCiW9BELyBo2rDOFtLqYxrz6w5pZj1uLoQA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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>
</blockquote>
</body>
</html>