kdf ikev2 issues

[badi95]

i've written a kdf ikev2 backend that's basically just your ikev2 cavs test ported to receive acvp data. The tests pass when Ni and Nr are the same length and their lengths (nInitLength, nRespLength) are divisible by 8, but when I test with vectors where Ni and Nr have different lengths and are not divisible by 8 then I'm not able to generate correct SKEYSEED. I haven't been able to test with vectors where Ni and Nr are different lengths, but their lengths are divisible by 8 because I don't have any tests that match that criteria.

[smuellerDD]

Am Donnerstag, 29. Oktober 2020, 21:10:37 CET schrieb badi95:

Hi badi95,

i've written a kdf ikev2 backend that's basically just your ikev2 cavs test ported to receive acvp data.

As I was involved in 2 IKEv2 CAVS test developments, could you give me a hint which implementation you are looking at?

The tests pass when Ni and Nr are the same length and their lengths (nInitLength, nRespLength) are divisible by 8, but when I test with vectors where Ni and Nr have different lengths and are not divisible by 8 then I'm not able to generate correct SKEYSEED. I haven't been able to test with vectors where Ni and Nr are different lengths, but their lengths are divisible by 8 because I don't have any tests that match that criteria.

When you refer to the lengths that you send to the ACVP server during requesting the test vectors, I would expect that you need multiples of 8 as the length values are in bits as defined by ACVP. I am unaware that any IKE KDF implementation can handle input data that is not multiples of a byte nor that they can generate output that is a fraction of a byte.

Ciao Stephan

[badi95]

Hi Stephan, Thanks for the reply. I'm basing my backend on your opensuse patch for strongswan about 5 years ago. I got it working with cavs tests on strongswan 5.6.0 2 days after when we were required to switch to acvp tests :(

I figured the lengths would need to be divisible by 8 also, so I was surprised when the .req.json file I am testing with showed this:

"tgId": 1, "hashAlg": "SHA2-256", "dhLength": 2048, "nInitLength": 1843, "nRespLength": 128, "derivedKeyingMaterialLength": 1280, "testType": "AFT", "tests": [

I'm going to request new test vectors from the company we are working with to certify our implementation.

[smuellerDD]

Am Freitag, 30. Oktober 2020, 14:50:00 CET schrieb badi95:

Hi badi95,

Hi Stephan, Thanks for the reply. I'm basing my backend on your opensuse patch for strongswan about 5 years ago. I got it working with cavs tests on strongswan 5.6.0 2 days after when we were required to switch to acvp tests :(

I have a backend that invokes the application directly and parses the application's output :-)

But good that you got it working.

I figured the lengths would need to be divisible by 8 also, so I was surprised when the .req.json file I am testing with showed this:

"tgId": 1,

        "hashAlg": "SHA2-256",
        "dhLength": 2048,
        "nInitLength": 1843,
        "nRespLength": 128,
        "derivedKeyingMaterialLength": 1280,
        "testType": "AFT",
        "tests": [

I'm going to request new test vectors from the company we are working with to certify our implementation.

Whoops, an odd nInitLength? That looks like a typo. In any case, the ACVP protocol defines all values as bits unless explicitly stated.

Ciao Stephan

[badi95]

I initially thought it was a mistake as well, but looking at the other tests 2/3 of the SHA-256 tests have an odd nInitLength or nRespLenght, it is the same for the SHA-512 tests. If it is not a mistake and we are required to test with odd length nInitLenght or nRespLength would the current implementation of the parser support that? All the lengths I've seen in the structures are in bytes.

[smuellerDD]

Am Freitag, 30. Oktober 2020, 15:14:30 CET schrieb badi95:

Hi badi95,

I initially thought it was a mistake as well, but looking at the other tests 2/3 of the SHA-256 tests have an odd nInitLength or nRespLenght, it is the same for the SHA-512 tests. If it is not a mistake and we are required to test with odd length nInitLenght or nRespLength would the current implementation of the parser support that? All the lengths I've seen in the structures are in bytes.

You are not required do support such odd values. Your lab has to specify the supported data lengths during registration at the ACVP server.

Ciao Stephan

[badi95]

Ohh thank goodness, I was worried I was going to have to patch strongswan and the acvpparser to support odd lengths. That would have been a real pain. I'll reach out to our lab to get valid test vectors. Thanks so much for your help.