6.12.5 TLS 1.3 re-authentication and re-key

The TLS 1.3 protocol distinguishes between re-key and re-authentication. The re-key process ensures that fresh keys are supplied to the already negotiated parameters, and on GnuTLS can be initiated using gnutls_session_key_update. The re-key process can be one-way (i.e., the calling party only changes its keys), or two-way where the peer is requested to change keys as well.

The re-authentication process, allows the connected client to switch identity by presenting a new certificate. Unlike TLS 1.2, the server is not allowed to change identities. That client re-authentication, or post-handshake authentication can be initiated only by the server using gnutls_reauth, and only if a client has advertised support for it. Both server and client have to explicitly enable support for post handshake authentication using the GNUTLS_POST_HANDSHAKE_AUTH flag at gnutls_init.

A client receiving a re-authentication request will "see" the error code GNUTLS_E_REAUTH_REQUEST at gnutls_record_recv. At this point, it should also call gnutls_reauth.

To make re-authentication transparent to the application when requested by the server, use the GNUTLS_AUTO_REAUTH and GNUTLS_POST_HANDSHAKE_AUTH flags on the gnutls_init call. In that case the re-authentication will happen in the call of gnutls_record_recv that received the reauthentication request.