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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
