Hi Hannes You're right, I rushed the answer. You would only need to perform the CRL check on all existing connections, not re-authenticate. This would then kill the session for the recently revoked certificate.
So I've mainly worked on solutions involving mobile devices; laptops and phones. Normally if the device is lost/stolen it's gone and assumed compromised. You wont be issuing it a new certificate for that device. cheers On Sun, Mar 7, 2021 at 3:50 PM Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > Focusing on one sentence from below: > > > > - I've found that the best method to prevent the device from > connecting is for the certificate to be revoked, the CRL refreshed and then > a re-authentication performed on all active connections. > > > > Why would you trigger re-authentication of all connections? You could > terminate the connection of the device with the compromised certificate. > > > > In your IPSec VPN scenario, how do you get a new certificate to the > compromised device? > > > > Ciao > > Hannes > > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of * Graham Bartlett > *Sent:* Sunday, March 7, 2021 12:16 PM > *To:* Peter Gutmann <pgut...@cs.auckland.ac.nz> > *Cc:* John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; TLS > List <tls@ietf.org> > *Subject:* Re: [TLS] Question to TLS 1.3 and certificate revocation > checks in long lasting connections > > > > Hi > > > > I have a fair amount of hands on experience with IPsec VPNs, and many > organisations look to use TLS in a similar manner. > > > > To give you an example of where you might look to perform a regular > revocation check on long lived connections; > > > > Solution with many remote devices (think remote access, so phones, > laptops, IoT devices etc) > > A remote device is compromised, on the gateway there could be 1000s of > devices connected. > > I've found that most vendor solutions aren't geared up for an admin to > easily determine the compromised device and prevent this reconnecting. Most > organisations have a disconnect between the SOC, PKI team and the team that > manages the remote access gateway, getting a process that'll involve all 3 > teams usually doesn't work. > > > > I've found that the best method to prevent the device from connecting is > for the certificate to be revoked, the CRL refreshed and then a > re-authentication performed on all active connections. > > > > I'm not as familiar with TLS as I am IPsec, but hope that this explains > a scenario where I feel re-authentication would be very valuable. > > > > cheers > > > > On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> > wrote: > > Nico Williams <n...@cryptonector.com> writes: > > >When expirations are short, you will not forget to renew. That's part of > the > >point of short-lived certificates. > > So instead of getting one chance a year for your control system to break > itself if the renewal fails, you get hundreds of them? > > Peter. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
