IKE v2 seems to provide wrong parameters

[fabiendeboyser]

environment
The environment the issue was experienced = Demo

testSessionId
The test session ID = 549202

vsId
The vectorSet ID displaying the issue = 2601060 / 2601061* / 2601062 / 2601063 / 2601064

Algorithm registration
The pertinent algorithm registration pieces (algorithm tested, capabilities, etc) in json format
"vsId": 2601061,
"algorithm": "kdf-components",
"mode": "ikev2",
"revision": "1.0",
"isSample": false,
"testGroups": [
{
"tgId": 1,
"hashAlg": "SHA2-224",
"dhLength": 8192,
"nInitLength": 64,
"nRespLength": 2048,
"derivedKeyingMaterialLength": 16384,
"derivedKeyingMaterialChildLength": 16384,
"testType": "AFT",
"tests": [

Endpoint in which the error is experienced
https://[acvpUrl]/acvp/[endpoint] GET = Not applicable

Expected behavior
A clear and concise description of what you expected to happen

• Test vectors received with expected results (samples test vectors and demo test vectors)
• When testing is performed on our implementation, we are not able to obtain similar results
• When testing with online implementation, following carefully the steps of construction as detailed in the spec, this is still not working

Additional context
Add any other context about the problem here.

[celic]

Do you want intermediate values from a specific test case? If so, pick a vsId and tcId and I'll generate the intermediate values for it.

[fabiendeboyser]

This might be helpful, we will try to reproduce:
"vsId": 2601061, "tcId": 1,

[celic]

That has expired. Can you either drop the prompt here or provide an active vector set?

[fabiendeboyser]

Thanks Chris, i have just generated a new vector set:
"vsId": 2699518, "tcId":1

[celic]

tmp_ikev2.txt

That one is a bit big. Here's a test case that is smaller. This is tcId 268. Note the bitlengths of nInit and nResp defined in the test group are not multiples of 8.

tmp_ikev2_small.txt

[fabiendeboyser]

Hi Chris, thanks for providing us this dataset
We have looked into this, and we are not sure how the concatenation is performed

ni=8B328569B49B57AC7208E20F1082BDB49A781881650E381C8A20777BAB0CEF5F3B775CA0DB0610AABFFA28E5BA99372B9A100065187C13E7F3408FC54617A69AEE9CA847CE57A49ADD10FD79160B7D1A05BD9351A7FDFBC3BF2AF87FA0EDBBBD733EF117B35CE90D41A862F45FD312CBC030D301B519B9FFB45B84B74506435FE53D20
nr=BF6EFE049C9BABADA2100CF74FA7C3712FA0644172CB9045EE01FF5D732E86336D018345DC491F4A8D66CEF77B5A1F2279BAEC9040
spii=287CF7A623193D47
spir=7C87CE308F725FD8

What we would expect of (ni || nr || spii | spir) is the full concatenation of the parameters (meaning one after the other)

Nevertheless, on your input, we see that from the last byte of ni something happened and the data is different = transforming "3D20" to "3D 37"

This hints that there is something happening on your concatenation starting from the last byte of ni
This is also the case for the other concatenation
From that the rest of the concatenation operation is totally different

Can you please have a look and confirm if there is an issue on the concatenation operation or whether we are not performing the operation accurately?

Many thanks

[celic]

ni or nInit in this example is not a multiple of 8 bits in length. So 3D 20 would have 11 bits, 0011 1101 001 and can be concatenated to form 3D 37 or 0011 1101 0011 0111 that has 16 bits.

[fabiendeboyser]

Thanks for point this out Chris!

I checked the reference = https://pages.nist.gov/ACVP/draft-celi-acvp-kdf-ikev2.html

We see that the registration example integrates an increment maybe this can help for the overall size..
Nonetheless, this seems not an input parameter in the registration table

Is it possible to input the parameter during the algorithm registration?

(we will do some registration tests next week to test this)

[celic]

Good. The length of nInit and nResp are provided in the test group properties as bits.