Test Cases to verify TLS 1.3 Key Update functionality.

[asant57]

For test cases defined for the FCS_*_EXT.1.1 SFR's, there are currently no test cases to verify the TOE correctly handles Key Update handshake Records as defined by RFC 8446 Section 4.6.3. This functionality is required by the RFC and therefore should be effectively tested by the lab as any TLS 1.3 peer may send the record and it would be expected that conformant TOE's correctly handle the records.

If 'TLS 1.3 (RFC 8446) is selected in FCS_*_EXT.1.1 (e.g. FCS_TLSC_EXT.1.1) the following scenarios should be tested:

• There should be a test case that verifies the TOE rejects Key Update Records that are not issued at the appropriate time (e.g. before the peer has issued the Finished record).
• There should be a test case that verifies the TOE rejects Key Update Records that contain an invalid KeyUpdateRequest value.
• There should be a test case that verifies the TOE correctly handles a Key Update Record that contains the 'update_not_requested' value. That is to say the TOE MAY send a Key Update Record and correctly updates the peer which has send the Key Update record application_secret keys.
• There should be a test case that verifies the TOE correctly handles a Key Update Record that contains the 'update_requested' value. That is to say the TOE MUST respond with it's own Key Update record containing 'update_not_requested' and correctly updates both session application_secret keys (the client and the server application_secret key values).