One document matched: draft-urien-tls-keygen-00.txt
TLS Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Informational June 18, 2008
Expires: December 18, 2008
TLS Key Generation
draft-urien-tls-keygen-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008). All rights reserved.
Abstract
The TLS protocol is widely deployed and used over the Internet.
Client and server nodes compute a set of keys called the key-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.
Urien Expires December 2008 [Page 1]
TLS Key Generation June 2008
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.
Table of Contents
Copyright Notice...................................................1
Abstract...........................................................1
Conventions used in this document..................................2
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 Function (KDF)....................................6
4 IANA Considerations..............................................7
5 Security Considerations..........................................7
6 References.......................................................7
6.1 Normative References........................................7
6.2 Informative References......................................8
Authors' Addresses.................................................8
Intellectual Property Statement....................................8
Disclaimer of Validity.............................................8
Copyright Statement................................................9
Acknowledgment.....................................................9
Urien Expires December 2008 [Page 2]
TLS Key Generation June 2008
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 key-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
distribution infrastructures, able to generate and to deliver
cryptographic keys required by multiple protocols.
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 an additional Key Distribution Function (KDF) in
order to deliver a set of cryptographic keys according to the
relation,
Keys = KDF(master-secret, client-random, server-random, "key
expansion").
However 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 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 2008 [Page 3]
TLS Key Generation June 2008
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
relation:
Keys = KDF(master-secret, client-random, server-random, "key
expansion")
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
according to cryptographic algorithms negotiated between client and
server, and identified by the CipherSuite parameter.
Urien Expires December 2008 [Page 4]
TLS Key Generation June 2008
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, "key
expansion")
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.
The 'V' (Vendor-Specific) bit indicates whether the optional Vendor-
ID field is present.
Urien Expires December 2008 [Page 5]
TLS Key Generation June 2008
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 Function (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).
Urien Expires December 2008 [Page 6]
TLS Key Generation June 2008
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 set to "key expansion".
4 IANA Considerations
5 Security Considerations
6 References
6.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
Urien Expires December 2008 [Page 7]
TLS Key Generation June 2008
6.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
Authors' Addresses
Pascal Urien
Telecom ParisTech
37/39 rue Dareau, 75014 Paris, France
Email: Pascal.Urien@enst.fr
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE
Urien Expires December 2008 [Page 8]
TLS Key Generation June 2008
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Urien Expires December 2008 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 01:17:23 |