One document matched: draft-urien-tls-keygen-02.txt
Differences from draft-urien-tls-keygen-01.txt
TLS Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Informational June, 2009
Expires: December, 2009
TLS Key Generation
draft-urien-tls-keygen-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The TLS protocol is widely deployed and used over the Internet.
Client and server nodes compute a set of keys called the keys-block,
according to a pseudo random function (PRF). This draft proposes a
keying infrastructure based on the TLS protocol. It suggests
defining an additional Key Distribution Function (KDF) in order to
deliver a set of cryptographic keys. In a peer to peer mode keys are
directly produced as inputs of the KDF functions. For centralized
architectures they are delivered through containers, secured with
keys derived from the KDF function.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Urien Expires December 2009 [Page 1]
TLS Key Generation June 2009
Table of Contents
Abstract........................................................... 1
Conventions used in this document.................................. 1
1 Introduction..................................................... 3
2 Basic Exchanges.................................................. 4
2.1 Full handshake.............................................. 4
2.2 Abbreviated Handshake....................................... 4
2.3 AVP Container............................................... 5
2.4 Data encryption and integrity............................... 6
3 Key Derivation Functions (KDF)................................... 6
3.1 TLS PRF function............................................ 6
3.2 HMAC KDF.................................................... 7
3.3 NIST compatible KDF......................................... 7
3.3.1 PRF functions ........................................ 7
3.3.2 KDF functions ........................................ 8
4 Use cases........................................................ 8
4.1 Hierarchical Model for Content/Service Protection........... 8
5 IANA Considerations.............................................. 9
6 Security Considerations.......................................... 9
7 References....................................................... 9
7.1 Normative References........................................ 9
7.2 Informative References...................................... 9
Authors' Addresses................................................ 10
Full Copyright Statement.......................................... 10
Urien Expires December 2009 [Page 2]
TLS Key Generation June 2009
1 Introduction
The TLS protocol [TLS 1.0] [TLS 1.1] [TLS 1.2] is widely deployed
and used over the Internet. Client and server nodes compute a set of
keys called the keys-block, according to a pseudo random function
(PRF) and two random values client-random and server-random,
respectively produced by these entities.
There is an increasing need in the Internet to set up efficient keys
distribution infrastructures, able to generate and to deliver
cryptographic material required by multiple applications, as
illustrated by section 6.
This draft proposes a keying infrastructure based on the TLS
protocol.
Full or abbreviated handshakes are performed according to the TLS
specification.
We suggest defining additional Key Distribution Functions (KDFi) in
order to deliver a set of cryptographic keys according to the
relation,
Keys = KDFi(master-secret, client-random, server-random, other-
information).
Particular KDF MAY be negotiated by the client according to specific
TLS extensions [TLS-EXT] or dedicated cipher suites.
In a peer to peer mode keys are directly produced as inputs of the
KDF functions, this mode of operation is for example quite suitable
for distributed architecture, in which networks nodes are typically
equipped with X509 certificates and RSA keys.
On the other hand, centralized architectures deliver keys from a
unique server to remotely managed nodes. In this later case
cryptographic keys MUST be delivered through application data,
according to cipher suites negotiated during the TLS handshake, but
working with keys computed with the KDF function.
Urien Expires December 2009 [Page 3]
TLS Key Generation June 2009
2 Basic Exchanges
2.1 Full handshake
The full handshake mode is a four ways handshake that performs one
way or mutual authentication between client and server entities. A
master secret is computed by both parties, and each of them proves
its knowledge of such value by Finished messages, which are
protected according to cryptographic algorithms negotiated between
client and server, and identified by the CipherSuite parameter.
Client Server
(A) ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- (B) ServerHelloDone
(C) Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- (D) Finished
<-------- (E) *AVP Container
*Optional
Figure 1. Full handshake
In the peer to peer mode, keys are computed according to the
selected KDF procedure and its associated information:
Keys = KDF(master-secret, client-random, server-random, other-
information)
In centralized architecture, an AVP attribute conveys a set of keys,
protected according to cryptographic algorithms pointed by the
CipherSuite parameter, but dealing with keys produced by the KDF
function.
2.2 Abbreviated Handshake
The abbreviated handshake mode is a three ways handshake that
performs a mutual authentication between client and server entities,
which share the knowledge of a previous master secret. Each of them
proves this assumption by Finished messages, which are protected
Urien Expires December 2009 [Page 4]
TLS Key Generation June 2009
according to cryptographic algorithms negotiated between client and
server, and identified by the CipherSuite parameter.
Client Server
(A) ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- (B) Finished
(C) [ChangeCipherSpec]
Finished -------->
<------- (D) *AVPs Container
*Optional
Figure 2. Abbreviated handshake
In the peer to peer mode, keys are computing according to the
relation:
Keys = KDF(master-secret, client-random, server-random, other-
information)
In centralized architecture, an AVP attributes conveys a set of
keys, protected according to cryptographic algorithms pointed by the
CipherSuite parameter, but using keys produced by the KDF function.
2.3 AVP Container
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length + Data |
|
| Optional padding bytes +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AVP Container
The AVP format is imported from the [TTLS] document.
The AVP Code is four octets and, combined with the Vendor-ID field
if present, identifies the attribute (i.e. the container structure)
uniquely.
Urien Expires December 2009 [Page 5]
TLS Key Generation June 2009
The 'V' (Vendor-Specific) bit indicates whether the optional Vendor-
ID field is present.
The 'M' (Mandatory) bit indicates whether support of the AVP is
required. If this bit is set to 0, this indicates that the AVP may
be safely ignored if the receiving party does not understand or
support it.
The 'r' (reserved) bits are unused and MUST be set to 0 by the
sender and MUST be ignored by the receiver.
The AVP Length field is three octets, and indicates the length of
this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
(if present) and Data.
Data Length is two octets and indicates the size of data without
padding bytes. According to selected cryptographic algorithms
padding byte MAY be added in order to get a length compatible with
ciphered blocs.
2.4 Data encryption and integrity
Cryptographic keys (Kc and Ki), used by encryption algorithms (Kc)
and MAC procedures (Ki), are derived according to TLS
specifications, by use KDF in place of the TLS PRF function.
A message M is concatenated to L null bytes, where L is the output
length (in bytes) of the HMAC procedure, and optional padding bytes.
If a cipher bloc algorithm is used, then the total length MUST be a
multiple of the bloc size.
M1 = M || 0:L || Pad*
A HMAC is computed over M1
MAC = HMAC(Ki, M1)
A M2 message is built, M2 = M || MAC || Pad*
This M2 message is encrypted in order to produce the data field
Data = {M2}Kc
3 Key Derivation Functions (KDF)
3.1 TLS PRF function
In [TLS extractor] it is suggested to use the TLS PRF function,
according to the relation:
Urien Expires December 2009 [Page 6]
TLS Key Generation June 2009
KDF= PRF(master_secret, label,
client-random || server-random ||
context-value-length || context-value)
3.2 HMAC KDF
We suggest using a HMAC based instantiation for KDF, as introduced
in [HMAC KDF].
The HMAC procedure is identical to the MAC algorithm negotiated
during the handshake session (e.g. HMAC-MD5, HMAC-SHA1, HMAC-
SHA256).
Notations.
- The first argument to a keyed function denotes the key, the value
K is the key to PRF and x its input.
- The symbol || denotes concatenation.
- Given two numbers N and n the symbol N:n represents the value N
written as n-bit integer.
- L is the length in bits, of this output value delivers by the HMAC
procedure
Pseudo Random Key = PRK = HMAC(client-random || server-random,
master-secret)
Keying material, whose length in bits is D, required D/L operations.
First is expressed as
K(1) = HMAC(PRK, 0:L || KeyLabel || 0:32),
Further operations (whose number is i) are computed according to
K(i+1) = HMAC(PRK, K(i)|| KeyLabel || i:32),
where KeyLabel is an ASCII string.
3.3 NIST compatible KDF
3.3.1 PRF functions
The [NIST KDF] standard proposes two candidates for PRF functions:
- PRF = HMAC(s,x), and
- PRF = CMAC(s,x)
Where s is a seed (a secret key in this draft context) and x an
input data (a stream of bytes)
Urien Expires December 2009 [Page 7]
TLS Key Generation June 2009
We suggest to compute s according to [HMAC KDF]
s = PRK = HMAC(client-random || server-random, master-secret)
3.3.2 KDF functions
Two methods are proposed by the [NIST KDF] standard:
- KDF in counter mode, and
- KDF in feedback mode
KDF functions are based on PRF using the PRK key and additional data
such as
- The length (L) of the generated cryptographic material,
- The Label (a binary string) of the derived keying material,
- The Context (a binary string) of the derived keying material (for
example identities of parties who want to compute/use this key)
KDF = PRF(PRK, f(L, Label, context))
4 Use cases
4.1 Hierarchical Model for Content/Service Protection
The ETSI 102 474 standard [TS 102.474] introduces a hierarchical
model for content/service protection mechanisms, targeting digital
IP datacast over video broadcasting. This scheme is a nice
illustration of a centralized architecture, in which cryptographic
keys are securely pushed from head-ends towards terminal devices.
Each terminal device holds a Right Encryption Key (REK).
This cryptographic material is used in conjunction with Keys
Management protocol (KMM) in order to push from head-ends to
terminals Services Rights Keys (SEK).
In turn the Key Stream Message (KSM) protocol, associated to the SEK
key, transport Traffic Encryption Keys (TEK) from head-ends to
terminals.
At last, clear content is encrypted with TEK, and is broadcasted
from head-ends to terminals
As an illustration the TLS protocol MAY be used in order to collect
the SEK keys. The REK cryptographic material can be instantiated
either by a terminal certificate (authenticated by a Certificate-
Verify message) or by a pre-shared key [RFC 4279]. A SEK key is
securely pushed and transported in an AVP container.
Urien Expires December 2009 [Page 8]
TLS Key Generation June 2009
5 IANA Considerations
6 Security Considerations
7 References
7.1 Normative References
[TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999
[TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006
[TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security
(TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt,
March 2008
[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D, Mikkelsen, J,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4346,
April 2006
[RFC 4279] P. Eronen, H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS"), RFC 4279, December 2005.
[NIST KDF] Lily Chen, "Recommendation for Key Derivation Using
Pseudorandom Functions" NIST Special Publication 800-108.
[TS 102.474] ETSI TS 102 474 V1.1.1 (2007-11), Technical
Specification, Digital Video Broadcasting (DVB); IP Datacast over
DVB-H: Service Purchase and Protection.
[CMAC] NIST SP 800-38B, "Recommendation for Block Cipher Modes of
Operation - The CMAC Mode for Authentication", May 2005.
[HMAC] FIPS 198-1, "The Keyed-Hash Message Authentication Code
(HMAC) ", Revision expected to be published in 2008.
[TLS extractor] "Keying Material Extractors for Transport Layer
Security (TLS) ", draft-ietf-tls-extractor-03.txt, November 2008
7.2 Informative References
[TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication
Protocol Version 0 (EAP-TTLSv0)", draft-funk-eap-ttls-v0-05.txt
April 2008
[HMAC-KDF] Krawczyk, H, "On Extract-then-Expand Key Derivation
Functions and an HMAC-based KDF",
http://www.ee.technion.ac.il/~hugo/kdf/, March 2008
Urien Expires December 2009 [Page 9]
TLS Key Generation June 2009
Authors' Addresses
Pascal Urien
Telecom ParisTech
37/39 rue Dareau, 75014 Paris, France
Email: Pascal.Urien@enst.fr
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Expires December 2009
Urien Expires December 2009 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:17:11 |