NIAP: View Technical Decision Details
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0040:  Clarifications to Tests for TLSS Requirements in MDM PP V2.0

Publication Date

Protection Profiles

Other References
PP_MDM_V2.0, requirement FCS_TLSS_EXT.1.1

Issue Description

The following tests for FCS_TLSS_EXT.1.1 need clarifications:

  • Test 3 asks for the evaluation to craft a MITM test where the client sends a key exchange message for a different cipher suite (e.g., send an RSA KeyEx message when the Server selected a ciphersuite specifying ECDEH or DHE KeyEx).  However, the client’s key exchange message doesn’t have any encoding to allow the server to distinguish between an RSA, DHE, or ECDHE key exchange message.  Only the length varies, and depending upon the key sizes (prime, modulus, curves) involved, the server cannot necessarily assume that the message is of the wrong type. Given that, a server expecting a client keyEx message containing an RSA encrypted pre-master secret is bound by the TLS RFCs, which specify in section of the TLS v1.2 RFC 5246 that in the event of a bad key exchange:
In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected.  Instead, it MUST continue the handshake with a randomly generated premaster secret.  It may be useful to log the real cause of failure for troubleshooting purposes; however, care  must be taken to avoid leaking the information to an attacker (through, e.g., timing, log files, or other channels.)
  • Test 4, bullet 2 requires that the evaluator modify the signature block in the client's key exchange handshake message, but the client key exchange message does not contain a signature block/field.
  • Test 4, bullet 5 requires that the evaluator send a garbled message from the client after the client has issued the ChangeCipherSpec message. This is redundant with the preceding bullet.

Test 3: Change wording to:

Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE sends a fatal alert after receiving the client’s change cipher spec message.

Test 4, bullet 2: Change wording to:

Modify the signature block in the the client’s Certificate Verify handshake message (if using mutual authentication) and verify that the server denies the client’s Finished handshake message.

Test 4, bullet 5: Change wording to:

Send a valid Server Finished message in plaintext and verify the client sends a fatal alert upon receipt and does not send any application data.  The server’s Finished message shall contain valid verify_data and shall parse correctly using a network protocol analysis tool.


The changes clarify and correct the tests and ensure that they are performed in accordance with the TLS RFCs.

Site Map              Contact Us              Home