OASIS PKCS 11 TC

 View Only
  • 1.  Review of IKE (section 2.64)

    Posted 04-13-2021 22:20
    I found two types. One was in the original proposal, the other seems to happen in transcription. In 2.64.2 in CK_IKE2_PRF_PLUS_DERIVE_PARAMS: SeedData should be pSeedData (it's correct in the header file and in the description below and the original proposal). In section 2.64.6, the follow paragraph is missing from both the original proposal and the spec. (I think it was found after the proposal) If CKA_VALUE_LEN is less then or equal to the prf length and bHasKeygxy is FALSE, then the new key is simply the base key truncated to CKA_VALUE_LEN (specified in RFC2409 appendix B). Otherwise the prf below is executed and the derived keys value is CKA_VALUE_LEN bytes of the resulting prf. bob


  • 2.  RE: [pkcs11] Review of IKE (section 2.64)

    Posted 04-14-2021 08:13
    Hi Bob, Thank you for your review. I have fixed the typo and added the wording wrt. CKA_VALUE_LEN, in PKCS#11 3.1 WD04 sections 6.64.2 and 6.64.6. Best regards, Dieter


  • 3.  RE: [pkcs11] Review of IKE (section 2.64)

    Posted 04-14-2021 13:37
    Bob, please note that there are 6 identifiers defined in the IKE section that do NOT appear in the header file: : CKR_KEY_RANGE_ERROR, CK_IKE1_EXTENDED_DERIVE_PARAMS, CK_IKE1_EXTENDED_DERIVE_PARAMS_PTR, CK_IKE1_PRF_DERIVE_PARAMS_PTR, CK_IKE2_PRF_PLUS_DERIVE_PARAMS_PTR, CK_IKE_PRF_DERIVE_PARAMS_PTR. See my private mail of March 31st. There are more missing identifiers in other Moreover, the new error code CKR_KEY_RANGE_ERROR should be added to section 5.1.6. Or different error codes should be returned! In fact, reading sections 6.64.3 to 6.64.6 we could return CKR_ATTRIBUTE_VALUE_INVALID and CKR_TEMPLATE_INCOMPLETE. Daniel ________________________________ Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com Seat: Aachen Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.


  • 4.  Re: [pkcs11] Review of IKE (section 2.64)

    Posted 05-12-2021 20:31
    On 4/14/21 6:36 AM, Daniel Minder wrote: Bob, please note that there are 6 identifiers defined in the IKE section that do NOT appear in the header file: : CKR_KEY_RANGE_ERROR, CK_IKE1_EXTENDED_DERIVE_PARAMS, CK_IKE1_EXTENDED_DERIVE_PARAMS_PTR, CK_IKE1_PRF_DERIVE_PARAMS_PTR, CK_IKE2_PRF_PLUS_DERIVE_PARAMS_PTR, CK_IKE_PRF_DERIVE_PARAMS_PTR. See my private mail of March 31st. There are more missing identifiers in other Moreover, the new error code CKR_KEY_RANGE_ERROR should be added to section 5.1.6. Or different error codes should be returned! In fact, reading sections 6.64.3 to 6.64.6 we could return CKR_ATTRIBUTE_VALUE_INVALID and CKR_TEMPLATE_INCOMPLETE. The actual error should be CKR_KEY_SIZE_RANGE it was a typo in the original proposal (I didn't intend to create a new error type. bob Daniel ________________________________ Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com Seat: Aachen Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.


  • 5.  RE: [pkcs11] Review of IKE (section 2.64)

    Posted 05-25-2021 21:54
    Bob, I've sent this to you earlier privately but resending now to the list as reply to your mail. I'm not convinced that CKR_KEY_SIZE_RANGE is correct. In Section 5.1.6 CKR_KEY_SIZE_RANGE is defined as: Although the requested keyed cryptographic operation could in principle be carried out, this Cryptoki library (or the token) is unable to actually do it because the supplied key s size is outside the range of key sizes that it can handle . When looking at other occurrences of CKR_KEY_SIZE_RANGE and how it s described there (mainly sections 5.12.4 and 5.18.3) the error applies to the input key. In 6.64.3 (IKE PRF DERIVE) it s applied to the derived key. You write: If CKA_VALUE_LEN is specified, it must equal the underlying prf or CKR_KEY_RANGE_ERROR is returned." So, it s not about an input key (baseKey) but about a mismatch with the prf s output length. So, in fact, the attribute in the template is wrong. Therefore, CKR_ATTRIBUTE_VALUE_INVALID seems more suitable to me. The same holds for 6.64.4 (IKEv1 PRF DERIVE), where you write: If CKA_VALUE_LEN is greater then the prf, CKR_KEY_RANGE_ERROR is returned. In 6.64.5 (6.64.5 IKEv2 PRF PLUS DERIVE) it s different: CKA_VALUE_LEN must be set in the template or CKR_KEY_RANGE_ERROR will be returned. This is a perfect match for CKR_TEMPLATE_INCOMPLETE. The same holds for 6.64.6 (6.64.6 IKEv1 Extended Derive) I have two more remarks/questions to 6.64.5: This mechanism uses the base key and a feedback version of the prf to generate sufficient bytes to cover all the session keys. The application will then use CKM_EXTRACT_KEY_FROM_KEY to pull out the various subkeys." This mechanism is to be used with C_Derive, which can generate one (1) new key. So, how does this match this description talking about all the session keys and various subkeys ? CKA_VALUE_LEN must be set in the template or CKR_KEY_RANGE_ERROR will be returned. If CKA_KEY_TYPE is not specified, the output key type will be CKK_GENERIC_SECRET. This sounds similar to other mechanisms that require CKA_VALUE_LEN only if the key length is not implicitly given by the key type. I m not an IKE specialist, but can this be the case here? Regards, Daniel


  • 6.  Re: [pkcs11] Review of IKE (section 2.64)

    Posted 05-26-2021 17:38
    On 5/25/21 2:53 PM, Daniel Minder wrote: Bob, I've sent this to you earlier privately but resending now to the list as reply to your mail. I'm not convinced that CKR_KEY_SIZE_RANGE is correct. In Section 5.1.6 CKR_KEY_SIZE_RANGE is defined as: Although the requested keyed cryptographic operation could in principle be carried out, this Cryptoki library (or the token) is unable to actually do it because the supplied key s size is outside the range of key sizes that it can handle . I think the description describes the cases below. When looking at other occurrences of CKR_KEY_SIZE_RANGE and how it s described there (mainly sections 5.12.4 and 5.18.3) the error applies to the input key. I don't see anything in the description that prevents it to applying to the output key. In 6.64.3 (IKE PRF DERIVE) it s applied to the derived key. You write: If CKA_VALUE_LEN is specified, it must equal the underlying prf or CKR_KEY_RANGE_ERROR is returned." So, it s not about an input key (baseKey) but about a mismatch with the prf s output length. So, in fact, the attribute in the template is wrong. Therefore, CKR_ATTRIBUTE_VALUE_INVALID seems more suitable to me. While CKR_ATTRIBUTE_VALUE_INVALID does apply, it seems less specific to me. In this case your are failing because you are asking for a key outside the range that is supported. The same holds for 6.64.4 (IKEv1 PRF DERIVE), where you write: If CKA_VALUE_LEN is greater then the prf, CKR_KEY_RANGE_ERROR is returned. In 6.64.5 (6.64.5 IKEv2 PRF PLUS DERIVE) it s different: CKA_VALUE_LEN must be set in the template or CKR_KEY_RANGE_ERROR will be returned. This is a perfect match for CKR_TEMPLATE_INCOMPLETE. The same holds for 6.64.6 (6.64.6 IKEv1 Extended Derive) So I still prefer CKR_KEY_RANGE_ERROR for these, but I would be OK with the CKR_ATTRIBUTE_VALUE/CKR_TEMPLATE_INCOMPLETE if the majority of the TC prefers. I have two more remarks/questions to 6.64.5: This mechanism uses the base key and a feedback version of the prf to generate sufficient bytes to cover all the session keys. The application will then use CKM_EXTRACT_KEY_FROM_KEY to pull out the various subkeys." This mechanism is to be used with C_Derive, which can generate one (1) new key. So, how does this match this description talking about all the session keys and various subkeys ? Repeated calls returns each key. This allows cleaner application of the templates to the various keys used by ike. It's already working quite well in libreswan using NSS vendor specific implementations of this same spec. CKA_VALUE_LEN must be set in the template or CKR_KEY_RANGE_ERROR will be returned. If CKA_KEY_TYPE is not specified, the output key type will be CKK_GENERIC_SECRET. This sounds similar to other mechanisms that require CKA_VALUE_LEN only if the key length is not implicitly given by the key type. I m not an IKE specialist, but can this be the case here? Yes, In this case the resulting key is the input to multiple CKM_EXTRACT_KEY_FROM_KEY. The alternative would have been to create a bunch of keys handles with multiple templates which can be variable in number depending on the symmetric algorithms ike is using. I'd also say it's a little late to object to the basic design at this point. bob Regards, Daniel