Here's my comments from Daniels
excellent review.
Questions for the list:
1) any strong feelings on CKM_IKE_PRF_PLUS_DERIVE vs
CKM_IKE2_PRF_PLUS_DERIVE vs CKM_IKE2_PRF_DERIVE (see below).
2) use of bool flag to indicate the presences of an optional key
object in the params rather than indicating the presence with a
non CK_INVALID_HANDLE value. (see below).
On 10/04/2019 02:43 AM, Daniel Minder wrote:
Hi Bob,
thanks for the IKE spec. I don' know IKE so well, so I cannot comment on if it suits the RFCs. Therefore, some more "structural" comments and questions.
If I understand correctly CKM_IKE_PRF_DERIVE is for IKEv1 and IKEv2, CKM_IKE1_PRF_DERIVE and CKM_IKE_APP_B_PRF_DERIVE for IKEv1 only, and CKM_IKE_PRF_PLUS_DERIVE for IKEv2 only. Therefore, I would suggest to use "IKEx" in all the names, i.e. rename CKM_IKE_APP_B_PRF_DERIVE to CKM_IKE1_APP_B_PRF_DERIVE and rename CKM_IKE_PRF_PLUS_DERIVE to CKM_IKE2_PRF_DERIVE (i.e. also get rid of "PLUS"). Params should be renamed accordingly.
I agree CKM_IKE_APP_B_PRF should be CKM_IKE1_APP_B_PRF. It is only
IKEv1 and will only ever be used for IKEv1.
I don't want to get rid of the plus in CKM_IKE_PRF_PLUS_DERIVE
because that's what the spec calls the prf. Right now it's used
only for IKEv2, I don't know if it will be used for future IKE's.
I can go with either CKM_IKE2_PRF_PLUS_DERIVE or
CKM_IKE_PRF_PLUS_DERIVE depending on feedback of the group.
For CKM_IKE_PRF_DERIVE, we should specify the error if bDataAsKey=TRUE and bRekey=TRUE.
Yes. probably CKR_ARGUMENTS_BAD.
On the other hand, do we need bRekey in CKM_IKE_PRF_DERIVE, bHasSeedKey in CK_IKE_PRF_PLUS_DERIVE_PARAMS, bHasPrevKey in CK_IKE1_PRF_DERIVE_PARAMS? We have CK_INVALID_HANDLE, and setting the key handle in the mech param to this value brings the same information as setting the Boolean var. In fact, implementations need to check anyway that the key handle is valid if the Boolean is true.
I put the bools because previous proposals where I used invalid
and NULL entries as implicit flags were rejected in favor of
explicit flags. If anyone has issues with Daniel's proposal here,
speak up now.
CK_IKE_PRF_DERIVE_PARAMS is missing a description for bDataAsKey.
Are the derived keys of any specific type?
Good question. I've sort of punted so far on this because it's
slightly complicated. This might be my first cut.
CKM_IKE_PRF_DERIVE
Input: bDataAsKey == PR_TRUE, input would be CKK_GENERIC key (the
output full output of a DH or ECC operation, length totally
variable). otherwise key type of the underlying prf.
hNewKey (input): CKK_GENERIC key.
Output: key type of the underlying prf.
CKM_IKE1_PRF_DERIVE
CKM_IKE1_APP_B_DERIVE
Input: keytype of the underlying PRF.
hKeygxy (input): CKK_GENERIC key
hPrevKey (input): any key type would be acceptable here
Output: user specified key type.
CKM_IKE2_PRF_PLUS_DERIVE
Input: keytype of the underlying PRF.
hSeedKey (input): CKK_GENERIC_KEY
Output: CKK_GENERIC KEY
I guess is wasn't all that complicated. If these look good I'll
add them to the spec.
Thanks,
Daniel
---
Thanks.
|