Subject: [Uta] Short term client certs and long lived connections!

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 8 Jan 2021 11:34:44 +0100

Hi!

I am working on a project where we issue short term client TLS certs, with just a few days lifespan. 

I realized that in some protocols, like SIP, MQTT, XMPP, we have quite long lived client connections over connection-oriented protocols. During those connections, a cert may expire.

I have looked, but found no advice, on how to handle that situation. If a SIP client authenticates with a client cert that is valid for 42 hours more, opens a connection that stays open for a long time, several lifespans…

Another situation is that the client cert is valid, but another cert in the trust chain expires.  The intermediate cert or the server cert may expire during the connection lifetime, as an example.

What should the server and client do here? I imagine the connection should be closed when the one of the certs in the mutual chain of trust expires. 

Do we have any document that describes this situation?

Regards,
/Olle

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 8 Jan 2021 11:38:23 -0500

On Fri, Jan 08, 2021 at 11:34:44AM +0100, Olle E. Johansson wrote:

> I realized that in some protocols, like SIP, MQTT, XMPP, we have quite
> long lived client connections over connection-oriented protocols.
> During those connections, a cert may expire.
> 
> I have looked, but found no advice, on how to handle that situation.
> If a SIP client authenticates with a client cert that is valid for 42
> hours more, opens a connection that stays open for a long time,
> several lifespans…
> 
> 
> Another situation is that the client cert is valid, but another cert
> in the trust chain expires.  The intermediate cert or the server cert
> may expire during the connection lifetime, as an example.
> 
> What should the server and client do here? I imagine the connection
> should be closed when the one of the certs in the mutual chain of
> trust expires. 

No in fact in typicall applications, where certificates are *identity*
certificates, nothing should happen, certainly nothing quite as
counter-productive as closing the connection.  If the identity was
valid at the start of the connection, it remains valid even after
the certificate expires.  Do you delete all old signed mail from
your mailbox when the S/MIME certificate expires?

Now if the client makes various API requests during the lifetime of the
connection, and these are subject to entitlement checks, you probably
want to make sure that stale entitlements are not cached forever.

Therefore, with *capability* certs, it may indeed make sense to require
a new client certificate after the original expires, and if that takes
a new connection, then so be it.

-- 
    Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Jan 2021 10:12:18 +0100

> On 8 Jan 2021, at 17:38, Viktor Dukhovni <[email-masked]> wrote:
> 
Ok, so if I understand you right, I should focus on the validity of the cert
for authentication only, not for authorization. If the authorization to perform
certain tasks is withdrawn, a server may close the connection or just decide
to deny any request.

I don’t think that’s very clear in many documents, but let’s aim for making
it clear in the future :-)

> a new connection, then so be it.

I am not familiar with those certs, but will investigate :-)

Thank you for your response!

/Olle