6.12.4 TLS 1.2 Re-authentication

In TLS 1.2 or earlier there is no distinction between re-key, re-authentication, and re-negotiation. All of these use cases are handled by the TLS’ rehandshake process. For that reason in GnuTLS rehandshake is not transparent to the application, and the application must explicitly take control of that process. In addition GnuTLS since version 3.5.0 will not allow the peer to switch identities during a rehandshake. The threat addressed by that behavior depends on the application protocol, but primarily it protects applications from being misled by a rehandshake which switches the peer’s identity. Applications can disable this protection by using the GNUTLS_ALLOW_ID_CHANGE flag in gnutls_init.

The following paragraphs explain how to safely use the rehandshake process.

6.12.4.1 Client side

According to the TLS specification a client may initiate a rehandshake at any time. That can be achieved by calling gnutls_handshake and rely on its return value for the outcome of the handshake (the server may deny a rehandshake). If a server requests a re-handshake, then a call to gnutls_record_recv will return GNUTLS_E_REHANDSHAKE in the client, instructing it to call gnutls_handshake. To deny a rehandshake request by the server it is recommended to send a warning alert of type GNUTLS_A_NO_RENEGOTIATION.

Due to limitations of early protocol versions, it is required to check whether safe renegotiation is in place, i.e., using gnutls_safe_renegotiation_status, which ensures that the server remains the same as the initial.

Function: unsigned gnutls_safe_renegotiation_status (gnutls_session_t session)

session: is a gnutls_session_t type.

Can be used to check whether safe renegotiation is being used in the current session.

Returns: 0 when safe renegotiation is not used and non (0) when safe renegotiation is used.

Since: 2.10.0

6.12.4.2 Server side

A server which wants to instruct the client to re-authenticate, should call gnutls_rehandshake and wait for the client to re-authenticate. It is recommended to only request re-handshake when safe renegotiation is enabled for that session (see gnutls_safe_renegotiation_status and the discussion in Safe renegotiation). A server could also encounter the GNUTLS_E_REHANDSHAKE error code while receiving data. That indicates a client-initiated re-handshake request. In that case the server could ignore that request, perform handshake (unsafe when done generally), or even drop the connection.

Function: int gnutls_rehandshake (gnutls_session_t session)

session: is a gnutls_session_t type.

This function can only be called in server side, and instructs a TLS 1.2 or earlier client to renegotiate parameters (perform a handshake), by sending a hello request message.

If this function succeeds, the calling application should call gnutls_record_recv() until GNUTLS_E_REHANDSHAKE is returned to clear any pending data. If the GNUTLS_E_REHANDSHAKE error code is not seen, then the handshake request was not followed by the peer (the TLS protocol does not require the client to do, and such compliance should be handled by the application protocol).

Once the GNUTLS_E_REHANDSHAKE error code is seen, the calling application should proceed to calling gnutls_handshake() to negotiate the new parameters.

If the client does not wish to renegotiate parameters he may reply with an alert message, and in that case the return code seen by subsequent gnutls_record_recv() will be GNUTLS_E_WARNING_ALERT_RECEIVED with the specific alert being GNUTLS_A_NO_RENEGOTIATION . A client may also choose to ignore this request.

Under TLS 1.3 this function is equivalent to gnutls_session_key_update() with the GNUTLS_KU_PEER flag. In that case subsequent calls to gnutls_record_recv() will not return GNUTLS_E_REHANDSHAKE , and calls to gnutls_handshake() in server side are a no-op.

This function always fails with GNUTLS_E_INVALID_REQUEST when called in client side.

Returns: GNUTLS_E_SUCCESS on success, otherwise a negative error code.