Post-handshake authentication – TLS Handshake Protocol Revisited
13.5.2 Post-handshake authentication
If Bob sent the post˙handshake˙auth extension, Alice can ask Bob to authenticate himself any time after their handshake by sending Bob a CertificateRequest message. In that case, Bob must reply with the corresponding authentication messages:
- If Bob decides to authenticate himself, he replies with Certificate, CertificateVerify, and Finished messages
- If Bob decides to ignore Alice’s authentication request, he replies with a Certificate message that contains no certificates, followed by a Finished message
If Bob receives a CertificateRequest message without having sent the post˙handshake˙auth extension, Bob terminates the TLS session and sends Alice an unexpected˙message alert.
Interestingly, because TLS client authentication might involve the user typing in a secret – for instance, if the TLS client is a web browser and the user has to type in their password – servers must tolerate a delayed response from a TLS client. This also includes scenarios where the server receives an arbitrary number of messages between transmitting the CertificateRequest message and receiving the corresponding response from the TLS client.
13.5.3 Key and initialization vector update
Alice and Bob use the KeyUpdate message to signal that they are updating the sending cryptographic keys on their respective ends. KeyUpdate can be sent by either Alice or Bob after they transmit their Finished message.
If, on the other hand, the KeyUpdate message is received before the Finished message, the TLS session must be terminated with an unexpected˙message alert.
Following the KeyUpdate message, the transmitting party must encrypt all of their data using the next generation of the derived secret keys. Similarly, the receiving party must update their receiving keys upon receiving the KeyUpdate message.
The format of the KeyUpdate message is shown in Listing 13.4. The value of the request˙update field determines whether the receiving party should reply with their own KeyUpdate message. If request˙update contains any other value than O or 1, then the receiving party immediately terminates the TLS session and responds with an illegal˙parameter alert.
Listing 13.4: Structure of the KeyUpdate message
enum {
update_not_requested(0),
update_requested(1),
(255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
If request˙update is set to update˙requested, the recipient must reply with their own KeyUpdate message, with request˙update set to update˙not˙requested, to avoid an infinite loop.
Moreover, a TLS party might receive an arbitrary number of messages between transmitting a KeyUpdate requesting a key update and receiving the other party’s KeyUpdate message. However, because the secret keys for sending and receiving data are derived from independent traffic secrets, using the old receive traffic secret has no effect on the forward secrecy of data transmitted prior to the sending party changing the keys.