Internet DRAFT - draft-stjohns-tls-tls13-crypto-infra
draft-stjohns-tls-tls13-crypto-infra
Network Working Group M. StJohns
Internet-Draft
Intended status: Informational April 9, 2014
Expires: October 11, 2014
TLS Crypto Constructs for Version 1.3
draft-stjohns-tls-tls13-crypto-infra-00
Abstract
This document describes a set of replacements for the TLS
cryptographic constructs for use with TLS1.3 and later. The
constructs used in versions of TLS 1.2 and prior have some issues
with respect to secure implementation using generic security
hardware.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
StJohns Expires October 11, 2014 [Page 1]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from TLS 1.2 . . . . . . . . . . . . . . . . . . 4
2. Key Hierachy . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Key Types . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Keys Derived from the 'premaster' Secret . . . . . . . . 5
2.3. Keys Derived from the 'master' Secret . . . . . . . . . . 5
3. Cryptographic Constructs . . . . . . . . . . . . . . . . . . 6
3.1. Negotiated Pseudo-Random Function . . . . . . . . . . . . 6
3.1.1. CMAC Key Impedence Matching . . . . . . . . . . . . . 6
3.2. Key Derivation Function (KDF) . . . . . . . . . . . . . . 7
3.2.1. Producing One Segment of the Key Stream . . . . . . . 8
3.2.2. Producing the Key Stream . . . . . . . . . . . . . . 9
3.2.3. Key Stream to Keys Conversion . . . . . . . . . . . . 10
3.3. Keyed Message Authentication Functions . . . . . . . . . 10
3.4. Pseudo-random Data Generator Function (PRDG) . . . . . . 10
4. TLS 1.3 Usages . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Premaster Secret Expansion . . . . . . . . . . . . . . . 11
4.2. Master Secret Expansion . . . . . . . . . . . . . . . . . 12
4.3. Finished Message . . . . . . . . . . . . . . . . . . . . 12
4.4. IV Generation . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . 0
5.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document describes a set of replacements for the TLS1.2 and
earlier cryptographic constructs. Those constructs were based on the
concept of a PRF or pseudo-random function. The new constructs still
use a single core function per connection, but describe the mappings
between that core function and the actual TLS usages slightly
differently.
This text is meant to be contributed text or concepts for the next
TLS specification version rather than a stand-alone standard. As
such it's submitted primarily for publication as an internet draft
but may be published as an Informational RFC depending on the timing
of the TLS1.3 work. No attempt has been made to provide specific
edits to the existing TLS1.2 specifications.
StJohns Expires October 11, 2014 [Page 2]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
1.1. Rationale
Although never described as such in the original TLS documents, there
are three standard cryptographic constructs used for different
purposes in the TLS protocol negotiation:
A key derivation function or KDF. This is used to derive the
master secret from the pre-master secret, and to derive the
session keys from the master secret. In TLS1.2 and before this
was described as the key expansion function.
A message authentication function or MAC. This is the keyed MAC
function used to sign the "finished" messages during protocol
negotiation, and shouldn't be confused with the MAC function (if
any) used to protect the record message traffic. In TLS1.2 and
prior, this used the TLS PRF with a specific set of labels and
with the master key used as the key to produce the Finished
message verify_data tag.
A well-known pseudo-random data generator (PRDG). This is used to
provided data for initialization vectors (IV). In TLS1.2 and
before, this was done as part of the derivation of the session
keys and was based on the master secret.
As defined in TLS1.2 ([RFC5246]) and before ([RFC4346] and others),
these functions were based on the TLS-PRF function. Because of the
way they were defined, and given the specific uses of various TLS
keys, it was difficult or impossible to implement these functions
securely in general purpose hardware security modules. It was
trivially easy to extract session key material.
o The TLS master secret was used both as a master key, and as a key
for the MAC function. Since both functions were defined in terms
of the underlying PRF, and the MAC function produced public data,
while the KDF function produced private data, it was trivially
easy to use the MAC function to reproduce the private key stream
as public data.
o The key expansion of the master secret to traffic keys included
the production of IV material. By cryptographic convention, IV
data is considered public data, so the key derivation function was
producing both public and private data. By varying the length of
the requested private key material, it was possible to leak the
key stream data into the produced IVs.
StJohns Expires October 11, 2014 [Page 3]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
1.2. Changes from TLS 1.2
This document makes a few changes in the way keys are used and
derived:
o A single key can't be used to produce both public and private
data.
o A single key can't be used for multiple purposes. Each TLS key is
typed, and can only be used with specific cryptographic constructs
appropriate for its type. To accomplish this, the master secret
is no longer used as a negotiation MAC key. Instead, an
additional key is derived from the premaster secret specifically
as a negotiation MAC key.
o The KDF (aka "key expansion") has been modified to be sensitive of
the length and types of keys to be produced. If any of these
input values change, the underlying key stream changes completely.
This in turn causes all of the individual keys extracted from that
key stream to also change.
o Labels used for the KDF or for the pseudo-random data function may
be any stream of bytes, not just those derived from ASCII strings.
o IV's - if required by the cryptographic suite - are no longer
produced as part of a key derivation step. Specifically, the
'master secret' expansion no longer produces either the 'client
write IV' or the 'server write IV'. Instead, the IVs are produced
using an un-keyed well-known psuedo-random function using the
client and server random bytes as seed material.
2. Key Hierachy
2.1. Key Types
For the purposes of providing cryptographic separation of key
material, each of the keys used within TLS are given a defined type.
These type values are used as input to the Key Deriviation or
expansion processing.
enum { masterKey (1), integrityKey(2),
encryptionKey(4), aeadKey (6) } KeyType;
masterKey: A master key may only be used with the KDF cryptographic
construct. It is only used as a source of key material to produce
subordinate keys. For TLS1.3, the only master keys are the
'premaster' secret and the 'master' secret derived from the
premaster.
StJohns Expires October 11, 2014 [Page 4]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
integrityKey: An integrity key may only be used with a Keyed
Message Authentication construct. These include the HMAC and CMAC
constructs.
encryptionKey: An encryption key may only be used with an
encryption mode construct that isn't also an AEAD construct.
aeadKey: An AEAD (Authenticated Encryption with Associated Data)
key may only be used with an AEAD encyption construct. These
include CCM and GCM. This type was added specifically to
cryptographically isolate keys used for encryption modes from keys
used for AEAD modes derived from or based on plain encryption
modes. For example, AES-CCM mode uses the exact same encryption/
decryption logic as AES-CTR but add a CMAC integrity check.
Without this isolation, it is trivial to defeat the policy
constraints on CCM that prohibit release of decrypted data before
the integrity tag is verified.
Note that a block cipher key (e.g. AES) can be typed as any of
Integrity (e.g. CMAC), Encryption or AEAD depending on its actual
use.
2.2. Keys Derived from the 'premaster' Secret
The following keys are derived from the premaster secret:
master secret: This is the key used to derive session keys for use
with a specific protocol suite. It is always typed as a
masterKey.
negotiation mac key: This is the key used with the negotiation MAC
function to produce the "verify_data" used with the Finished
message. It is always typed as an integrityKey.
The master secret is always 48 bytes (384 bits) in length. The
negotiation mac key is always 32 bytes (256 bits) in length.
[Discussion: Alternately, the mac key is always the native length of
the selected PRF to avoid the impedence match function?]
2.3. Keys Derived from the 'master' Secret
The following keys are derived from the master secret. Depending on
the needs of the selected cipher suite, some of these keys may not
need to derived.
o client write MAC key
o server write MAC key
StJohns Expires October 11, 2014 [Page 5]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
o client write encryption key
o server write encryption key
The lengths of these keys vary per cipher suite. The types of the
'client write MAC key' and the 'server write MAC key' are always
Integrity Key (0x02). The types of the 'client write encryption key'
and 'server write encryption key' are either Encryption Key (0x04) or
AEAD key (0x06).
If a key is not required for the cipher suite, it is omitted from the
derivation step. There is no placeholder of a zero length key.
3. Cryptographic Constructs
3.1. Negotiated Pseudo-Random Function
The negotiated (SecurityParameters.prf_algorithm) pseudo-random
function or PRF is either an HMAC function or CMAC function. If
unspecified, HMAC-SHA256 shall be used.
The HMAC construct is based on an underlying non-invertable hash or
summary function and is formed as per [RFC2104] or [FIPS198].
The CMAC construct is based on an underlying block cipher and is
formed as per [RFC4493] or [SP800-38B].
3.1.1. CMAC Key Impedence Matching
The generic CMAC construct as defined in [SP800-38B] requires a
specific key size based on the underlying block cipher. Unlike the
HMAC specification documents, neither of the CMAC specification
documents describe a way to take a key of any length and adapt it for
use it with CMAC. TLS will use the mechanism suggested in
[SP800-56C] (Key Derivation through Extraction-then-Expansion) [1],
for adapting keys of any length to output a CMAC key. Using the
approach in section 5 of [SP800-56C], and using an all '0's salt,
convert the input key to a key of the appropriate size for the CMAC
function. Process:
1. Set K to input key.
2. If length(K) is equal to length of CMAC output, return K.
3. Set K equal to CMAC ('0', K);
4. Return K.
StJohns Expires October 11, 2014 [Page 6]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
3.2. Key Derivation Function (KDF)
The key derivation function (KDF) used for TLS1.3 and later is the
function described in section 5.1 of [SP800-108] (Key Derivation
Using Pseudorandom Functions [2]), - "KDF in Counter Mode". This KDF
construct is able to produce any amount of key material by using an
incrementing counter, a master key, and some amount of input public
data (e.g. the label, client and server random, etc) to produce
multiple blocks of pseudo-random data which are concatenated to
produce the key data stream.
KDF (key, label, context, bitsToGenerate) ::=
KDF-SP800-108-51 (key, label, context, bitsToGenerate);
The KDF construct allows the derivation of any amount of random data.
It is generally used to generate additional key material. When used
with the 'KeyExpansionContext' Context construct, it has the property
that any change in the number, type or length of the keys to be
derived completely changes the output key stream.
See Section 4.1, Premaster Secret Expansion and Section 4.2,
Master Secret Expansion for the specific orders in which keys are
derived for each usage. By convention, master keys are derived
first, then MAC keys, and then encryption or AEAD keys. Within the
type of keys, client write keys are derived before server write keys.
The general calling form for this KDF is:
K sub O := KDF (K sub I, Label, Context, L)
Where 'K sub O' is the output key stream. The remainder of the
fields are described below in Section 3.2.1.
If 'K sub I' is private data (e.g. typed as a masterSecret), then the
output 'K sub O' is also private data. Otherwise, if 'K sub I' is
public data (e.g. for use below at Section 3.4 in the PRDG), then the
output 'K sub O' is also public data.
If the construct is being used to produce key material (e.g. with the
KeyExpansionContext and a secret key), the output keys are formed by
producing multiple blocks of key stream, concatenating them, and then
splitting up the key stream in to key data of the appropriate lengths
for each derived key. Otherwise, K sub O may be broken up as desired
for the usage.
Although this construct permits the production of fractional byte
(e.g. 12 bit) keys, there are no current TLS keys defined with
fractional byte lengths.
StJohns Expires October 11, 2014 [Page 7]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
3.2.1. Producing One Segment of the Key Stream
Each pseudo-random key stream block 'K(i)' is produced using the
function:
K(i) := PRF (K sub I, i || Label || 0x00 || Context || L)
The values for each input variable (described in step 4.a of section
5.1 of [SP800-108]) are mapped as follows:
PRF: The negotiated TLS1.3 PRF function, generally either an HMAC
or CMAC function.
K sub I: The input master key for this key derivation. For TLS
this is generally either the 'master secret' or 'premaster
secret'.
i: The iteration count represented as a uint32. This is
initialized to '1' for the first block of key material and
incremented for each subsequent block.
Label: A string of bytes used to describe the specific use of the
output of this derivation. For TLS this is usually the ASCII
encoding of either "premaster" or "master secret", but could be
anything if this construct is used for key exporters.
Context: A string of bytes used to differentiate this call to the
KDF from all other calls.
L: The uint32 length in bits of the key stream being produced
during this derivation. For TLS, this is always the sum of the
sizes of the keys being produced from this derivation. E.g. for
the "premaster" derivation, this is the sum of 48*8 or 384 bits
(the length of the TLS master secret) and 32*8 or 256 bits (the
length of the negotiation mac key) or 80*8 of 640 bits.
StJohns Expires October 11, 2014 [Page 8]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
The specific Context construct used depends on what the KDF function
is being used for. The GenericContext may be used for key exporters
and other to-be-defined usages. The KeyExpansionContext is used for
the expansion of keys typed as masterKey, including the pre-master
secret and the expansion of the master secret. The RandomBitContext
is used for the generation of public unpredictable data such as IV's.
enum { generic, expansion, randomBits } ContextTag;
struct {
opaque contextBytes;
} GenericContext;
struct {
uint8 clientRandom[32]; /* ClientHello.random */
uint8 serverRandom[32]; /* ServerHello.random */
uint32 keyCount; /* Num keys to derive */
KeyType keyTypes[keycount];
uint16 keyLengths[keycount]; /* Key lengths in bits */
} KeyExpansionContext;
struct {
uint8 clientRandom[32];
uint8 serverRandom[32];
} RandomBitContext;
struct {
select (ContextTag) { /* implicit selection */
case generic:
GenericContext;
case expansion:
KeyExpansionContext;
case randomBits:
RandomBitContext;
};
} Context;
The clientRandom and serverRandom are the bytes provided by the
ClientHello.random and ServerHello.random fields respectively.
KeyCount is the number of keys being derived with this call to the
KDF. KeyTypes contains the types of keys being derived, and
KeyLengths the matching lengths for those keys in bits.
3.2.2. Producing the Key Stream
StJohns Expires October 11, 2014 [Page 9]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
The output stream, K sub O, is produced by concatenating all of the
K(i) outputs and then truncating to length L. There are CEIL(L/
prfBlockSize) K(i) output blocks where 'prfBlockSize' is the output
size of the PRF in bits:
K sub O :=
KDF (K sub I, Label, Context, L)
:= PRF (K sub I, 1 || Label || 0x00 || Context || L)
PRF (K sub I, 2 || Label || 0x00 || Context || L) +
PRF (K sub I, 3 || Label || 0x00 || Context || L) + ...
[0..CEIL(L/8)]
3.2.3. Key Stream to Keys Conversion
If the desired output is keys, then K sub O is then broken up into
the component keys. The following example assumes key that have bit
lengths that are all multiples of 8.
pos := 0
Key[0] := K sub O[pos..pos+keyLength[0]/8-1]
pos := pos + keyLength[0]
Key[1] := K sub O[pos..pos+keyLength[1]/8-1]
pos := pos + KeyLength[1]
Key[2] := K sub O[pos..pos+keyLength[2]/8-1]
pos := pos + KeyLength[2]
...
3.3. Keyed Message Authentication Functions
The keyed message authentication function (MAC) is the negotiated
CMAC or HMAC PRF function used as is.
MAC (key, data) ::= PRF (key, data);
See Section 4.3, Finished Message for the how this function is used
to produce the Finished message verify_data.
3.4. Pseudo-random Data Generator Function (PRDG)
The pseudo-random data generator function uses the KDF construct
described at Section 3.2 above, but uses a zero key.
PRDG (label, context, bytesNeeded) ::=
KDF ( '0', label, context, bytesNeeded*8)
where:
StJohns Expires October 11, 2014 [Page 10]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
'0': '0' is a key consisting of a bit stream of '0's equal in
length to the natural key length of the underlying PRF function.
E.g. 128 bits if the underlying PRF function is AES-CMAC-128.
label: A byte stream which identifies the general use of the bits
output from this call to the DBRG. For example, this is
"clientAndServerIV" expressed as ASCII bytes when used to derive a
stream of bytes used for IVs.
context: A byte stream used diversify this generation of bytes from
all others. If not otherwise specified, this is the
RandomBitContext structure defined above in Section 3.2.1.
bytesNeeded: The number of bytes needed as output from this call to
the DBRG.
See Section 4.4, IV Generation for how to use this function to
produce IV material if required.
4. TLS 1.3 Usages
This section describes the proposed TLS 1.3 changes to key
derivation, IV production and Finished message signatures.
4.1. Premaster Secret Expansion
The expansion of the pre-master secret always results in two keys:
the master secret and the negotiation MAC key. The master secret has
been defined since the first version of TLS (and its predecessor
SSL). The derivation of the negoiation MAC key is new with this
version.
KeyType keytypes[2] = { masterKey, integrityKey };
uint16 keylengths[2] = { 384, 256 };
KeyExpansionContext context =
{ ClientHello.random,
ServerHellow.random,
2, keytypes, keylengths };
key_block = KDF (pre_master_secret, "master secret v2",
context, 640);
master_secret = key_block[0..47];
negotiation_mac_key = key_block[48..79];
StJohns Expires October 11, 2014 [Page 11]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
4.2. Master Secret Expansion
There are three cases for master key expansion: integrity only,
integrity plus encryption, and finally AEAD. Integrity only modes
need 2 MAC keys, integrity plus encryption modes need 2 MAC keys plus
two encryption keys for a total of 4 keys, and finally AEAD modes
need 2 encryption keys.
Only the AEAD case is expanded below. N.B., if a key is not needed
for a suite - such as integrity keys for AEAD, those keys are neither
derived nor requested. While the general use case of this function
is to generate session keys for TLS, it may be used by key exporters
to generate any number of keys of any type simply by changing the
request parameters.
/* Parameters for AEAD key derivation */
KeyType aeadTypes[2] = { aeadKey, aeadKey };
uint16 aeadLengths[2] =
{ SecurityParameters.enc_key_length * 8,
SecurityParameters.enc_key_length * 8 };
uint32 aeadL = 2 *
SecurityParameters.enc_key_length * 8;
KeyExpansionContext aeadContext =
{ ClientHello.random,
ServerHellow.random,
2, aeadTypes, aeadLengths };
/* Substitute the approriate context and L from above eg */
key_block = KDF (master_secret, "key expansion v2",
aeadContext, aeadL);
/* And then break it down into keys */
client_write_key =
key_block[0..SecurityParameters.enc_key_length-1];
server_write_key =
key_block[SecurityParameters.enc_key_length..
2*SecurityParameters.enc_key_length-1];
4.3. Finished Message
The following replaces the definition of "verify_data" in section
7.4.9 of [RFC5246].
StJohns Expires October 11, 2014 [Page 12]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
verify_data
MAC (negotiation_mac_key, finished_label + handshake_messages)
[0..verify_data_length-1];
Prior versions of TLS used a hash of the handshake messages as input
to the TLS PRF. It's unclear there was any added security benefit to
that approach after the PRF was changed to remove MD5. For this
version, the handshake messages are input without hashing to the CMAC
or HMAC function represented by the PRF.
4.4. IV Generation
If necessary for the cryptosuite, the IV data is produced as follows:
RandomBitContext context =
{ ClientHello.random,
ServerHello.random };
iv_data = PRDG ("clientAndServerIV", context,
2* SecurityParameters.fixed_iv_length * 8);
Then, iv_data is partitioned as follows:
client_write_IV[SecurityParameters.fixed_iv_length];
server_write_IV[SecurityParameters.fixed_iv_length];
5. References
[FIPS198] National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", Federal
Information Processing Standards Publication 198-1, July
2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
StJohns Expires October 11, 2014 [Page 13]
Internet-Draft TLS Crypto Constructs for Version 1.3 April 2014
[SP800-108]
National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom
Functions", NIST Special Publication 800-108, October
2009, <http://csrc.nist.gov/publications/nistpubs/800-108/
sp800-108.pdf>.
[SP800-38B]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", NIST Special Publication
800-38B, May 2005.
[SP800-56C]
National Institute of Standards and Technology,
"Recommendation for Key Derivation through Extraction-
then-Expansion", NIST Special Publication 800-56C, May
2005.
5.2. URIs
[1] http://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf
[2] http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf
Appendix A. Test Vectors
To be provided.
Author's Address
Michael C StJohns
Email: msj@nthpermutation.com
StJohns Expires October 11, 2014 [Page 14]
