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] Groups - TLS 1.2 mechanisms uploaded


Hi Robert -

I don't have any big problems with the TLS derive mechanisms, but I do have a problem exposing the TLS1.2 PRF as a directly callable mechanism.

In the the protocol, the PRF is used to both derive keys and to perform a MAC over the final data.  The problem is that the PRF produces public data by default, which means that you can use the PRF to derive the key data - since both the keys and the MAC are derived from the TLS master key.

I'd provided the fixes for this in conjunction with my C_DeriveKeys proposal.  I've attached only the relevant section above.  Basically, the TLS12MAC mechanism uses the TLS PRF as an internal function and doesn't allow you to specify arbitrary labels. By preventing the specification of arbitrary labels, you can prevent the release of the key material since that key material uses different labels to generate it. 

Lastly, I would prohibit the release of IV material to the CK_SSL_KEY_MAT_OUT structure (para 6 of 1.1.6) as you can cause the release of key material by simply shrinking the lengths of the keys requested for the first four slots - that causes the key material to leak into the IV space.

Mike



On 7/31/2013 8:41 PM, Robert Relyea wrote:
Submitter's message
Please comment on the following areas specifically before we propose this for a ballot:

Mechanism and PARAM names: I changed TLS-> TLS12, but that may not be the best as the mechanism are likely to apply to future versions of TLS as well. Names with _WITH_HASH seemed a little unwieldy, but I wouldn't object to them.

Whether or not I should add the hash text to each mechanism description instead if just in the beginning, PRF and in the PARAM description.

The hash parameter is a CKM_MECHANISM_TYPE hash; with no descriptive prefix (a la ulHash for instance). I did this because I could not find any other examples of a CKM_MECHANISM_TYPE parameter other then in the CKM_MECHANISM structure (where it is devoid of a descriptive prefix as well). I'm will to add one if everyone is agreed. mHash or ulHash may be better.

bob
-- Mr. Robert Relyea
Document Name: TLS 1.2 mechanisms

Description
This adds the new mechanism needed to support TLS 1.2.

TLS 1.2 is basically the same as TLS 1.0 and TLS 1.1 except that in TLS 1.2
the underlying hash used for the PRF can be negotiated as part of the
protocol. This proposal adds a mechanism the parameters for the TLS
mechanism to select the desired hash. A hash of CKM_SHA1 would produce the
same results as the existing TLS mechanism.
Download Latest Revision
Public Download Link

Submitter: Mr. Robert Relyea
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2013-07-31 17:41:06


Attachment: pkcs11-tls-mac.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document



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