Re: [pkcs11] Groups - TLS 1.2 mechanisms uploaded

[Michael StJohns <msj@nthpermutation.com>]

On 8/22/2013 9:08 PM, Wan-Teh Chang wrote:
> Mike, Bob R.,
>
> Your proposal has three sets of rules about key sensitivity and
> extractability.
>
> The first set of rules is used for CKM_TLS12_MASTER_KEY_DERIVE and
> CKM_TLS12_MASTER_KEY_DERIVE_DH. The second set of rules is used for
> CKM_TLS12_KEY_AND_MAC_DERIVE and CKM_TLS12_KEY_SAFE_DERIVE. The
> third set of rules is used for CKM_TLS_KDF. (The three sets of rules
> are listed at the end of this message.)
>
> Question 1: does CKM_TLS_KDF need its own set of rules?
>
> It seems that the rules for the master key derivation mechanisms
> should be appropriate for CKM_TLS_KDF because these mechanisms all
> derive one generic secret key from another generic secret key.

The current set of rules (for all KDFs and derivation mechanisms) are 
somewhat problematic in that most of them allow the derived key(s) to be 
set to any sensitivity level.  The "simple" kdfs have what I consider to 
be a more reasonable approach.   This KDF mirrors the simple KDFs 
basically to try and deal with the re-derive and extract vulnerability.

It was somewhat of an arbitrary choice, and I expect that as part of the 
CKA_DERIVE_TEMPLATE discussion we'll go back and re-do pretty much all 
of the KDF sensitivity treatments once we have a way of restricting 
downstream keys.  For now, I believe this is the safest choice.


> Note: I may have found the answer to this question. See my next question.
>
> Question 2: I found that the rules for CKM_TLS_KDF are based on the
> rules for CKM_EXTRACT_KEY_FROM_KEY (with "base key" changed to
> "original key"). The only important change is that "from a default value"
> is changed to "from the original key". Why the change?

"from a default value" means that implementers will make different 
choices.  From the original key gets you a predictable behavior 
regardless of token implementation.
> I assume "from the original key" also implies if the original key doesn't
> have the CKA_SENSITIVE attribute, neither will the derived key. Correct?

Incorrect - sort of.  CKA_SENSITIVE, CKA_EXTRACTABLE and others are 
always present or always have a default value (e.g. CKA_DERIVE has a 
default value of false, so you always need to add it to the key with a 
value of true if you want to use the key for derives).   So if the 
original key doesn't have the CKA_SENSITIVE attribute, the key is 
assumed to have the default value for the attribute and so will the 
derived key.  (*sigh* I'm not sure why this is a token specific default, 
but that's what the document says).

[Note to self: propose language to deal with defaults and "privilege" 
attributes in a more sensible manner}

Mike



> Thanks,
> Wan-Teh Chang
>
> ==========
>
> 1. CKM_TLS12_MASTER_KEY_DERIVE and CKM_TLS12_MASTER_KEY_DERIVE_DH:
>
> This mechanism has the following rules about key sensitivity and
> extractability:
> * The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for
>    the new key can both be specified to be either CK_TRUE or CK_FALSE.
>    If omitted, these attributes each take on some default value.
> * If the base key has its CKA_ALWAYS_SENSITIVE attribute set to
>    CK_FALSE, then the derived key will as well.  If the base key has its
>    CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then the derived key
>    has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its
>    CKA_SENSITIVE attribute.
> * Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute
>    set to CK_FALSE, then the derived key will, too.  If the base key has
>    its CKA_NEVER_EXTRACTABLE attribute set to CK_TRUE, then the derived
>    key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite value
>    from its CKA_EXTRACTABLE attribute.
>
> 2. CKM_TLS12_KEY_AND_MAC_DERIVE and CKM_TLS12_KEY_SAFE_DERIVE:
>
> All four keys inherit the values of the CKA_SENSITIVE,
> CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE, and CKA_NEVER_EXTRACTABLE
> attributes from the base key.  The template provided to C_DeriveKey may
> not specify values for any of these attributes which differ from those
> held by the base key.
>
> 3. CKM_TLS_KDF:
>
> This mechanism has the following rules about key sensitivity and
> extractability:
> * If the original key has its CKA_SENSITIVE attribute set to CK_TRUE, so
>    does the derived key.  If not, then the derived key’s CKA_SENSITIVE
>    attribute is set either from the supplied template or from the
>    original key.
> * Similarly, if the original key has its CKA_EXTRACTABLE attribute set
>    to CK_FALSE, so does the derived key.  If not, then the derived key’s
>    CKA_EXTRACTABLE attribute is set either from the supplied template or
>    from the original key.
> * The derived key’s CKA_ALWAYS_SENSITIVE attribute is set to CK_TRUE if
>    and only if the original key has its CKA_ALWAYS_SENSITIVE attribute
>    set to CK_TRUE.
> * Similarly, the derived key’s CKA_NEVER_EXTRACTABLE attribute is set to
>    CK_TRUE if and only if the original key has its CKA_NEVER_EXTRACTABLE
>    attribute set to CK_TRUE.
>
> 4. CKM_EXTRACT_KEY_FROM_KEY:
>
> This mechanism has the following rules about key sensitivity and
> extractability:
> * If the base key has its CKA_SENSITIVE attribute set to CK_TRUE, so
>    does the derived key. If not, then the derived key’s CKA_SENSITIVE
>    attribute is set either from the supplied template or from a default
>    value.
> * Similarly, if the base key has its CKA_EXTRACTABLE attribute set
>    to CK_FALSE, so does the derived key. If not, then the derived key’s
>    CKA_EXTRACTABLE attribute is set either from the supplied template or
>    from a default value.
> * The derived key’s CKA_ALWAYS_SENSITIVE attribute is set to CK_TRUE if
>    and only if the base key has its CKA_ALWAYS_SENSITIVE attribute
>    set to CK_TRUE.
> * Similarly, the derived key’s CKA_NEVER_EXTRACTABLE attribute is set to
>    CK_TRUE if and only if the base key has its CKA_NEVER_EXTRACTABLE
>    attribute set to CK_TRUE.