draft-ietf-tls-extractor-06.txt   draft-ietf-tls-extractor-07.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Network Resonance Internet-Draft Network Resonance
Intended status: Standards Track July 12, 2009 Intended status: Standards Track September 07, 2009
Expires: January 13, 2010 Expires: March 11, 2010
Keying Material Exporters for Transport Layer Security (TLS) Keying Material Exporters for Transport Layer Security (TLS)
draft-ietf-tls-extractor-06.txt draft-ietf-tls-extractor-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 January 13, 2010. This Internet-Draft will expire on March 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 20 skipping to change at page 3, line 20
A number of protocols wish to leverage Transport Layer Security (TLS) A number of protocols wish to leverage Transport Layer Security (TLS)
[RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key [RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key
establishment but then use some of the keying material for their own establishment but then use some of the keying material for their own
purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], a purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], a
key management scheme for SRTP which uses DTLS to perform a key key management scheme for SRTP which uses DTLS to perform a key
exchange and negotiate the SRTP [RFC3711] protection suite and then exchange and negotiate the SRTP [RFC3711] protection suite and then
uses the DTLS master_secret to generate the SRTP keys. uses the DTLS master_secret to generate the SRTP keys.
These applications imply a need to be able to export keying material These applications imply a need to be able to export keying material
(later called Exported Keying Material or EKM) from TLS/DTLS, and (later called Exported Keying Material or EKM) from TLS/DTLS to an
securely agree on the upper-layer context where the keying material application or protocol residing at an upper-layer, and securely
will be used. The mechanism for exporting the keying material has agree on the upper-layer context where the keying material will be
the following requirements: used. The mechanism for exporting the keying material has the
following requirements:
o Both client and server need to be able to export the same EKM o Both client and server need to be able to export the same EKM
value. value.
o EKM values should be indistinguishable from random by attackers o EKM values should be indistinguishable from random data by
who don't know the master_secret. attackers who don't know the master_secret.
o It should be possible to export multiple EKM values from the same o It should be possible to export 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 fulfill these The mechanism described in this document is intended to fulfill these
requirements. requirements. This mechanism is compatible with all versions of TLS.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Binding to Application Contexts 3. Binding to Application Contexts
In addition to using an exporter to obtain keying material, an In addition to using an exporter to obtain keying material, an
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Future values are allocated via RFC 5226 Specification Required Future values are allocated via RFC 5226 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 and Section 3. Thanks to David McGrew for helpful IANA section and Section 3. Thanks to David McGrew for helpful
discussion of the security considerations and Alfred Hoenes for discussion of the security considerations and to Vijay Gurbani and
editorial comments. Alfred Hoenes for editorial comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
 End of changes. 7 change blocks. 
13 lines changed or deleted 14 lines changed or added

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