Re: [pkcs11] HMAC vs. generic-secret key type amendment

[Michael StJohns <msj@nthpermutation.com>]

On 10/3/2013 8:05 PM, Peter Gutmann wrote:
> Apparently this never made it to the list during yesterday's conference call,
> this is a re-send:
>
> -- Snip --
>
> The document I mentioned, or at least a late draft, is still on the RSA
> server:
>
> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a4d2.pdf

I had problems downloading this via a browser - it kept ending up 
getting stored as a zero length file.  I had to break out the real ftp 
command and do it that way.


> This isn't quite the final version (which vanished somewhere at RSA), but the
> "Background" section should give enough of the rationale for why the change
> was needed.  As I mentioned on the call, at the time the users that were
> affected by this were using HMAC so this is a point solution rather than an
> attempt to redefine MAC usage in general, which would presumably have required
> much bigger changes.

The explanation in the document is PKCS11 centric (e.g. you can't 
actually use HMACs and be compliant with PKCS11 so here's the fix) 
rather than security centric (You shouldn't use the same key for HMACs, 
CMACs and key derivation because there are security issues with that, 
and you probably shouldn't use the same key for encryption and CMAC 
because there may be security issues with that).

I think both narratives are helpful.  But the explanatory text that was 
appropriate when this was proposed as a standalone amendment should 
probably not be incorporated into the final text if this becomes an 
integrated part of the standard.

Going back to the above document, it specifies individual types for each 
of the hash functions.  I collapsed this slightly into specifying types 
only for families of hash functions.  I have a slight preference for the 
latter because of how I think something like CKA_DERIVE_TEMPLATE will 
need to be specified: in a way that allows you to support the 
negotiation of a set of crypto suites from a single master secret key 
(yup -TLS is rearing its ugly head again).    Thoughts?

I also specified a set of CMAC key types (which also get used for GMAC) 
which are the same as the set of known symmetric key types with a 
specific bit set in the manifest constant.


I'm on travel during the next call.  I'd like to ask that someone 
propose a straw poll(s) to figure out where we're going.

Poll 1:  a) don't split off HMAC types - fix the language to allow 
generic secrets to be used with HMAC; b) split off HMAC types, one per 
hash function; c) split off hmac types one per family of hash 
functions.  For (b) and (c) ensure the language for C_Sign and C_Verify 
deprecates and eventually prohibits the use of generic secrets and 
non-HMAC symmetric key types with HMAC signature modes.   For the 
purposes of evaluating this - if the sum of the votes for  (b) and (c) 
are greater than the number of votes for (a), then the result is "split 
off HMAC types"   (if this needs to be split into two different votes to 
get that result, then please do so)

Poll 2: a) don't split off CMAC types - ensure the language for 
symmetric secret key types includes their use in CMAC signature 
functions; b) split off CMAC types, one per symmetric key type - ensure 
the language for C_Sign and C_Verify deprecates and eventually prohibits 
the use of generic secrets and non-CMAC symmetric key types with CMAC 
signature modes.

Poll 3: a) don't split off master secret types - ensure the language for 
generic secrets is appropriate going forward for key derivation; b) 
split off CKK_MASTER_SECRET - ensure the language for C_DeriveKey 
deprecates and eventually prohibits the use of generic secrets and non 
master secret keys for key derivation.

For the above "deprecates and eventually prohibits" means that for 3.0 
we support both, but provide a mechanism to lock out generic secrets and 
non-appropriate types for a specific token, for 4.0 generic secrets are 
locked out of the use (as well as non-CMAC symmetric keys for CMAC)

If anyone else would like to propose an alternative straw poll or set of 
straw polls, be my guest.

Mike



> Peter.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php