Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Nico Williams <[e-mail]>]

On Fri, Mar 05, 2021 at 01:13:57PM -0500, Viktor Dukhovni wrote:
> This harks back to another recent thread where it was noted that one
> needs to make a distinction between authentication and authorisation.
> 
> The integrity of a TLS 1.3 session (which always performs ephemeral key
> agreement that offers forward-secrecy) is not compromised if later the
> signing keys of one of the parties is compromised.  So there is no need
> to check CRLs or renegotiate to just to maintain a secure connection.
> 
> On the server side, if the client's identity is used as a key into an
> authorisation table, one just needs to periodically (or even at each
> logical request) to revalidate the client's authorisation, there is
> generally no need to "re-authenticate" the client.

Yes, authorization is probably getting conflated here.  Suppose the
authorization is local and slow to be updated.  E.g., when an employee
separates from their employer, local authorization may not get updated
with much celerity, so if the subject's certificate expires sooner than
local authz could get updated, then re-authenticating the subject would
help.  (This assumes credentials do expire with celerity, but that is
good practice.)

That might seem weird, but consider a stateful file server, something
like NFSv4, say, and suppose that a client connects, authenticates,
successfully opens some file to which they were authorized and... maybe
now they can use that open file reference forever, much as one expects
in POSIX.  Except NFSv4 will require reauthentication though, so the
client cannot in fact use that open file reference forever.  But the
NFSv4 server (I think) will not re-evaluate ACLs for existing open file
handles as the ACLs change (per POSIX).  Re-authenticating the client
does serve something of an authorization purpose in the file server
example.  (Of course, a file server doesn't need to hew to POSIX on
this, and could re-evaluate ACLs for open file references, and/or it
could have a revocation feature like BSD's revoke(2) that lets users
forcibly close open file references.)

> If there is a concern that a server may somehow mid-session cease to be
> [...]

+1