search

usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
59 stars 20 forks source link

TLS v1.2 KDF provision for extended master secret #41

Closed swkeypair closed 3 years ago

swkeypair commented 3 years ago

SP 800-52 rev 2 Section 3.4.1 requires support for Extended Master Secret (RFC 7627 Section 4). The text of SP 800-135 rev 1 Section 4.2.2 is vague regarding the scope but references RFC 5246 Section 5 in a footnote and RFC 5246 generally in document citations. Recognizing that:

Q: Does the CAVP have any plan to test RFC 7627 Extended Master Secret as a variant of TLS KDF testing?

The situation may be similar to that of the TLS 1.3 KDF, where there was recognition of the need but some lag in approval. If there is not a plan to test RFC 7627, where should the question of alignment of SP 800-52 and SP 800-135 be directed? It's not clear if NIST CT have a mechanism to register issues of that type for resolution.

swkeypair commented 3 years ago

Edit: fixed section references; added links to SP docs; noted broad definition of the function could be interpreted as covering EMS.

celic commented 3 years ago

We've spoken over email but so the information is here.

We are looking at creating a new revision for TLS KDF that includes the extended master secret. This would be a client breaking change, so a new revision helps confirm the clients opt-in to the new testing. It is on the agenda for the developers.

Kritner commented 3 years ago

This change is on demo in v1.1.0.15. Just realized I still need to do a specification update for this... in the meantime the registration looks like:

{
  "algorithm": "TLS-v1.2",
  "mode": "KDF",
  "revision": "RFC7627",
  "hashAlg": [
    "SHA2-256",
    "SHA2-384",
    "SHA2-512"
  ]
}

same prompt and response file formats as the previous testing, just using "extended master secret" as the label rather than "master secret".

swkeypair commented 3 years ago

The master_secret calculation in RFC7627 requires a session_hash input. The updated TLS KDF test for compliance to RFC7627 is providing random values rather than a session hash value.

Excerpts from request JSON file section with the following properties (whitespace adjusted for readability in this post).

"algorithm": "TLS-v1.2",  "mode": "KDF",  "revision": "RFC7627",
"hashAlg": "SHA2-256",  "keyBlockLength": 1024,  "preMasterSecretLength": 384,  "testType": "AFT",
"preMasterSecret": "4C30166DC61C5939394EF0DF0C44F4454EC4C3DBEB5AF15023FEF085700445A3010BE23AA32B44C1B5A458CEE05DFFD0",
"clientHelloRandom": "39B538D42B36CAF7B221FE9E465EDD80FDDAB9FDDD8F3900DF13A87030541DD9",
"serverHelloRandom": "C80BE771A539A1FCDAADE9B890451E7F803B7160A50B64E19DDD936FBD120EC0",
"clientRandom": "FA2B385ACEC13761D68125F2B6ABB68F86527CF23A65C1FFEC8D1CA6EF1C5584",
"serverRandom": "C792BF5A6E8D45D45ED5543BBA16B24E7FE87284F790599063D94C540A214359"

The RFC 7627 Section 4 specification of Extended Master Secret: master_secret = PRF(pre_master_secret, "extended master secret", session_hash) [0..47];

The extended master secret computation differs from that described in [RFC5246] in the following ways:

Kritner commented 3 years ago

Ah, sorry with the holiday between the start and end of doing that change I dropped the ball on that one...

Getting to a "legitimate, protocol negotiated session_hash" would seemingly go outside of the scope of testing just the KDF, so the inclusion of a session_hash within the prompt file will probably have to suffice.

I'll try to get those changes in within the next day or two.

swkeypair commented 3 years ago

No problem.

so the inclusion of a session_hash within the prompt file will probably have to suffice.

Does that mean that the IUT will supply a session_hash value?

Kritner commented 3 years ago

I'm not sure if I understand the reasoning behind asking:

Does that mean that the IUT will supply a session_hash value?

Would the IUT even have enough information to construct a valid session_hash since we're not exchanging certificates nor a ciphersuite negotiation?

My thought was to keep it more focused on the KDF aspect of the TLSv1.2 KDF: for the ACVP server to provide a "mock" session_hash to be used by both the IUT and ACVP server for the generation of the (extended)master_secret and keyBlock

swkeypair commented 3 years ago

I just didn't understand what you meant by "within a prompt file".

ACVP server to provide a "mock" session_hash to be used by both the IUT and ACVP server for the generation of the (extended)master_secret and keyBlock

That should work.

swkeypair commented 3 years ago

I'll try to get those changes in within the next day or two.

Just checking in on this update.

Kritner commented 3 years ago

Sorry I think these are out there on demo now, I can't double check to confirm at the moment though.

On Thu, Jan 28, 2021, 10:41 AM swkeypair notifications@github.com wrote:

I'll try to get those changes in within the next day or two. Just checking in on this update.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP-Server/issues/41#issuecomment-769173107, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDIDB35AJMGE4PLGE3URDDS4GAUBANCNFSM4T73NRWQ .

Kritner commented 3 years ago

This change is on demo btw

swkeypair commented 3 years ago

The lab and vendor have confirmed that the new tests pass on the demo server. The changes can be moved to production from our point of view, and this issue can then be closed. Please let us know when this will be propagate to Production. Thank you!

Kritner commented 3 years ago

A notification should be coming out shortly, but I believe we're going to go for this friday for the release.

Kritner commented 3 years ago

This change is on prod in release v1.1.0.15