OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] Proposed IKE spec for 3.1

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.

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.

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.

Input: keytype of the underlying PRF.
hSeedKey (input): CKK_GENERIC_KEY

I guess is wasn't all that complicated. If these look good I'll add them to the spec.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]