draft-ietf-tls-extractor-00.txt   draft-ietf-tls-extractor-01.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Network Resonance Internet-Draft Network Resonance
Intended status: Standards Track December 19, 2007 Intended status: Standards Track February 20, 2008
Expires: June 21, 2008 Expires: August 23, 2008
Keying Material Extractors for Transport Layer Security (TLS) Keying Material Extractors for Transport Layer Security (TLS)
draft-ietf-tls-extractor-00.txt draft-ietf-tls-extractor-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 21, 2008. This Internet-Draft will expire on August 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
A number of protocols wish to leverage Transport Layer Security (TLS) A number of protocols wish to leverage Transport Layer Security (TLS)
to perform key establishment but then use some of the keying material to perform key establishment but then use some of the keying material
for their own purposes. This document describes a general mechanism for their own purposes. This document describes a general mechanism
for allowing that. for allowing that.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
3. Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3 3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3
4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 3 4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informational References . . . . . . . . . . . . . . . . . 5 8.2. Informational References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Introduction 1. Introduction
A number of protocols wish to leverage Transport Layer Security (TLS) A number of protocols wish to leverage Transport Layer Security (TLS)
[4] or Datagram TLS (DTLS) [5] to perform key establishment but then [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key
use some of the keying material for their own purposes. A typical establishment but then use some of the keying material for their own
example is DTLS-SRTP [6], which uses DTLS to perform a key exchange purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp],
and negotiate the SRTP [3] protection suite and then uses the DTLS which uses DTLS to perform a key exchange and negotiate the SRTP
master_secret to generate the SRTP keys. [RFC3711] protection suite and then uses the DTLS master_secret to
generate the SRTP keys.
These applications imply a need to be able to extract Exported Keying These applications imply a need to be able to extract keying material
Material (EKM) from TLS/DTLS. This mechanism has the following (later called Exported Keying Material or EKM) from TLS/DTLS, and
requirements: securely agree on the upper-layer context where the keying material
will be used. The mechanism for extracting the keying material has
the following requirements:
o Both client and server need to be able to extract the same EKM o Both client and server need to be able to extract the same EKM
value. value.
o EKM values should be indistinguishable from random by attackers o EKM values should be indistinguishable from random by attackers
who don't know the master_secret. who don't know the master_secret.
o It should be possible to extract multiple EKM values from the same o It should be possible to extract multiple EKM values from the same
TLS/DTLS association. TLS/DTLS association.
o Knowing one EKM value should not reveal any information about the o Knowing one EKM value should not reveal any information about the
master_secret or about other EKM values. master_secret or about other EKM values.
The mechanism described in this document is intended to fill these The mechanism described in this document is intended to fill these
requirements. requirements.
2. Conventions Used In This Document 2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [RFC2119].
3. Signalling Extractors 3. Binding to Application Contexts
Other protocols which wish to use extractors SHOULD have some way for In addition to extracting keying material, an application using the
the peers to signal that an extractor will be used. An example is a keying material has to securely establish the upper-layer layer
TLS extension, as used in DTLS-SRTP. context where the keying material will be used. The details of this
context depend on the application, but it could include things such
as algorithms and parameters that will be used with the keys,
identifier(s) for the endpoint(s) who will use the keys,
identifier(s) for the session(s) where the keys will be used, and the
lifetime(s) for the context and/or keys. At minimum, there should be
some mechanism for signalling that an extractor will be used.
This specification does not mandate a single mechanism for agreeing
on such context; instead, there are several possibilities that can be
used (and can complement each other). For example:
o One important part of the context -- which application will use
the extracted keys -- is given by the disambiguating label string
(see Section 4).
o Information about the upper-layer context can be included in the
optional data after the extractor label (see Section 4).
o Information about the upper-layer context can be exchanged in TLS
extensions included in the ClientHello and ServerHello messages.
This approach is used in [DTLS-SRTP]. The handshake messages are
protected by the Finished messages, so once the handshake
completes, the peers will have the same view of the information.
Extensions also allow a limited form of negotiation: for example,
the TLS client could propose several alternatives for some context
parameters, and TLS server could select one of them.
o The upper-layer protocol can include its own handshake which can
be protected using the keys extracted from TLS.
It is important to note that just embedding TLS messages in the
upper-layer protocol may not automatically secure all the important
context information, since the upper-layer messages are not covered
by TLS Finished messages.
4. Extractor Definition 4. Extractor Definition
An extractor takes as input two values: An extractor takes as input three values:
o A disambiguating label string o A disambiguating label string
o A per-association context value provided by the extractor using
application
o A length value o A length value
It then computes: It then computes:
PRF(master_secret, label, PRF(master_secret, label,
SecurityParameters.client_random + SecurityParameters.client_random +
SecurityParameters.server_random)[length] SecurityParameters.server_random +
context_value_length + context_value
)[length]
The output is a pseudorandom bit string of length bytes generated The output is a pseudorandom bit string of length bytes generated
from the master_secret. from the master_secret.
Label values MUST be registered via Specification Required as Label values beginning with "EXPERIMENTAL" MAY be used for private
described by RFC 2434 [2]. Note that extractor labels have the use without registration. All other label values MUST be registered
potential to collide with existing PRF labels. In order to prevent via Specification Required as described by RFC 2434 [RFC2434]. Note
this, labels SHOULD begin with "EXTRACTOR". This is not a MUST that extractor labels have the potential to collide with existing PRF
because there are existing uses which have labels which do not begin labels. In order to prevent this, labels SHOULD begin with
with this prefix. "EXTRACTOR". This is not a MUST because there are existing uses
which have labels which do not begin with this prefix.
The context value allows the application using the extractor to mix
its own data with the TLS PRF for the extractor output. The context
value length is encoded as an unsigned 16-bit quantity (uint16)
representing the length of the context value.
5. Security Considerations 5. Security Considerations
Because an extractor produces the same value if applied twice with Because an extractor produces the same value if applied twice with
the same label to the same master_secret, it is critical that two EKM the same label to the same master_secret, it is critical that two EKM
values generated with the same label be used for two different values generated with the same label be used for two different
purposes--hence the requirement for IANA registration. However, purposes--hence the requirement for IANA registration. However,
because extractors depend on the TLS PRF, it is not a threat to the because extractors depend on the TLS PRF, it is not a threat to the
use of an EKM value generated from one label to reveal an EKM value use of an EKM value generated from one label to reveal an EKM value
generated from another label. generated from another label.
skipping to change at page 5, line 8 skipping to change at page 6, line 8
Future values are allocated via RFC2434 Specification Required Future values are allocated via RFC2434 Specification Required
policy. The label is a string consisting of printable ASCII policy. The label is a string consisting of printable ASCII
characters. IANA MUST also verify that one label is not a prefix of characters. IANA MUST also verify that one label is not a prefix of
any other label. For example, labels "key" or "master secretary" are any other label. For example, labels "key" or "master secretary" are
forbidden. forbidden.
7. Acknowledgments 7. Acknowledgments
Thanks to Pasi Eronen for valuable comments and the contents of the Thanks to Pasi Eronen for valuable comments and the contents of the
IANA section. IANA section and Section 3.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Norrman, "The Secure Real-time Transport Protocol (SRTP)", (TLS) Protocol Version 1.1", RFC 4346, April 2006.
RFC 3711, March 2004.
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 8.2. Informational References
Protocol Version 1.1", RFC 4346, April 2006.
[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
8.2. Informational References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[6] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security [I-D.ietf-avt-dtls-srtp]
(DTLS) Extension to Establish Keys for Secure Real-time McGrew, D. and E. Rescorla, "Datagram Transport Layer
Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work in Security (DTLS) Extension to Establish Keys for Secure
progress), November 2007. Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-01 (work in progress),
November 2007.
Author's Address Author's Address
Eric Rescorla Eric Rescorla
Network Resonance Network Resonance
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 23 change blocks. 
53 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/