kdf-components: IKEv2 KDF - missing SA full-rekeying testing

[null0link]

Currently IKEv2 KDF is tested by the following test cases:

"tests": [
  {
    "tcId": 1,
    "gir": "DEBB121F462376CB9...",
    "girNew": "84C351B81361A5...",
    "nInit": "C1728473C73E82C...",
    "nResp": "8C2E6D0C726AEDF...",
    "spiInit": "78189EB34DEDC70E",
    "spiResp": "00D4927A59969560"
  }
]

expecting the following responses:

"tests":[
  {
    "tcId":1,
    "sKeySeed":"a4014a98ddd7274c1988a918346706d3cdf68a76",
    "sKeySeedReKey":"1f37d347683a99daf0061a7a53df6b4972110f3c",
    "derivedKeyingMaterial":"0fe39f797425ad29460f8...",
    "derivedKeyingMaterialChild":"4d239df6d04ac02b...",
    "derivedKeyingMaterialDh":"373d28974d7f4ec688b..."
  }
]

This theoretically tests IKE SA rekeying by validating sKeySeedReKey from the response vectors. However in the real scenario every time a new SKEYSEED is generated (the first one or after rekeying), the new keying material is generated too (this is not tested by ACVP in rekeying SAs scenario). Then from single IKE SA, multiple CHILD_SAs are being generated. According to section 2.17 of RFC4306, each time child SA is generated, it takes SK_d from existing IKE SA Derived Keying Material. Also to perform IKE_SAs rekeying (section 2.18 of RFC4306) the SK_d is needed too.
Because current form of test cases do not test full rekeying scenario and kind of enforces not-usable IKEv2 KDF implementation (if you implement KDF basing only on ACVP testing requirements, it probably won't be usable to derive multiple child's SAs or derive keying material after SA rekeying, as you have to supply SK_d as an input for the KDF algorithm, which is not provided by current tests), I suggest to split current test case into two scenarios (cases):

1. deriving first SA, and
2. rekeying

This could be represented by the following vectors:

tests cases:

"tests": [
{
"tcId": 1,
"rekeying": false,
"gir": "DEBB121F462376CB9...",
"girNew": "84C351B81361A5...",
"nInit": "C1728473C73E82C...",
"nResp": "8C2E6D0C726AEDF...",
"spiInit": "78189EB34DEDC70E",
"spiResp": "00D4927A59969560"
},
{
"tcId": 2,
"rekeying": true,
"SK_d": "0fe39f797425ad29460f8",
"gir": "84C351B81361A5...",
"girNew": "84C351B81361A5...",
"nInit": "C1728473C73E82C...",
"nResp": "8C2E6D0C726AEDF...",
"spiInit": "78189EB34DEDC70E",
"spiResp": "00D4927A59969560"
}
]

responses:

"tests":[
{
"tcId":1,
"sKeySeed":"a4014a98ddd7274c1988a918346706d3cdf68a76",
"sKeySeedReKey":"1f37d347683a99daf0061a7a53df6b4972110f3c",
"derivedKeyingMaterial":"0fe39f797425ad29460f8...",
"derivedKeyingMaterialChild":"4d239df6d04ac02b...",
"derivedKeyingMaterialDh":"373d28974d7f4ec688b..."
},
{
"tcId":2,
"sKeySeed":"1f37d347683a99daf0061a7a53df6b4972110f3c",
"sKeySeedReKey":"1f37d347683a99daf0061a7a53df6b4972110f3c",
"derivedKeyingMaterial":"0fe39f797425ad29460f8...",
"derivedKeyingMaterialChild":"4d239df6d04ac02b...",
"derivedKeyingMaterialDh":"373d28974d7f4ec688b..."
}
]

Summary of changes:

• input vectors:
  • addition of rekeying
  • addition of SK_d when rekeying is true
• response vectors:
  • removal of sKeySeedReKey

When performing rekeying (rekeying: true) then gir, not girNew, should be used to derive a new sKeySeed.

This is only a suggestion, but I think it will result in better tested algorithm implementations as well they will be more suited to real life use cases.

[null0link]

Hey @jbrock24 I just want to check if you have any thoughts on this?

[jbrock24]

Hi @null0link, I apologize, but due to circumstances out of our control we were unable to respond and handle these. This is a priority for us, I will have a response for this soon.