[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Review of IKE (section 2.64)
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.
I don't see anything in the description that prevents it to applying to the output key.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.
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.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.â
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.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)
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.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?
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 -----Original Message----- From: Robert Relyea <rrelyea@redhat.com> Sent: Mittwoch, 12. Mai 2021 22:31 To: Daniel Minder <Daniel.Minder@utimaco.com>; pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Review of IKE (section 2.64) 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 ________________________________ 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]