6.12.4 Re-authentication

In TLS there is no distinction between rekey, 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).

Function: int gnutls_rehandshake (gnutls_session_t session)

session: is a gnutls_session_t type.

This function will renegotiate security parameters with the client. This should only be called in case of a server.

This message informs the peer that we want to renegotiate parameters (perform a handshake).

If this function succeeds (returns 0), you must call the gnutls_handshake() function in order to negotiate the new parameters.

Since TLS is full duplex some application data might have been sent during peer’s processing of this message. In that case one should call gnutls_record_recv() until GNUTLS_E_REHANDSHAKE is returned to clear any pending data. Care must be taken, if rehandshake is mandatory, to terminate if it does not start after some threshold.

If the client does not wish to renegotiate parameters he should reply with an alert message, thus the return code will be GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be GNUTLS_A_NO_RENEGOTIATION . A client may also choose to ignore this message.

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