diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-extractor-01.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-extractor-01.txt | 392 |
1 files changed, 0 insertions, 392 deletions
diff --git a/doc/protocol/draft-ietf-tls-extractor-01.txt b/doc/protocol/draft-ietf-tls-extractor-01.txt deleted file mode 100644 index a992f2b24f..0000000000 --- a/doc/protocol/draft-ietf-tls-extractor-01.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - -Network Working Group E. Rescorla -Internet-Draft Network Resonance -Intended status: Standards Track February 20, 2008 -Expires: August 23, 2008 - - - Keying Material Extractors for Transport Layer Security (TLS) - draft-ietf-tls-extractor-01.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 August 23, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). - -Abstract - - A number of protocols wish to leverage Transport Layer Security (TLS) - to perform key establishment but then use some of the keying material - for their own purposes. This document describes a general mechanism - for allowing that. - - - - - - - -Rescorla Expires August 23, 2008 [Page 1] - -Internet-Draft TLS Extractors February 2008 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 - 3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3 - 4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 8.2. Informational References . . . . . . . . . . . . . . . . . 6 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rescorla Expires August 23, 2008 [Page 2] - -Internet-Draft TLS Extractors February 2008 - - -1. Introduction - - A number of protocols wish to leverage Transport Layer Security (TLS) - [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key - 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], - which uses DTLS to perform a key exchange and negotiate the SRTP - [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 keying material - (later called Exported Keying Material or EKM) from TLS/DTLS, and - 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 - value. - o EKM values should be indistinguishable from random by attackers - who don't know the master_secret. - o It should be possible to extract multiple EKM values from the same - TLS/DTLS association. - o Knowing one EKM value should not reveal any information about the - master_secret or about other EKM values. - - The mechanism described in this document is intended to fill these - requirements. - - -2. 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 [RFC2119]. - - -3. Binding to Application Contexts - - In addition to extracting keying material, an application using the - keying material has to securely establish the upper-layer layer - 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. - - - - -Rescorla Expires August 23, 2008 [Page 3] - -Internet-Draft TLS Extractors February 2008 - - - 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 - - An extractor takes as input three values: - - o A disambiguating label string - o A per-association context value provided by the extractor using - application - o A length value - - It then computes: - - - PRF(master_secret, label, - SecurityParameters.client_random + - SecurityParameters.server_random + - context_value_length + context_value - )[length] - - The output is a pseudorandom bit string of length bytes generated - from the master_secret. - - Label values beginning with "EXPERIMENTAL" MAY be used for private - - - -Rescorla Expires August 23, 2008 [Page 4] - -Internet-Draft TLS Extractors February 2008 - - - use without registration. All other label values MUST be registered - via Specification Required as described by RFC 2434 [RFC2434]. Note - that extractor labels have the potential to collide with existing PRF - labels. In order to prevent this, labels SHOULD begin with - "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 - - 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 - values generated with the same label be used for two different - purposes--hence the requirement for IANA registration. However, - 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 - generated from another label. - - -6. IANA Considerations - - IANA is requested to create (has created) a TLS Extractor Label - registry for this purpose. The initial contents of the registry are - given below: - - Value Reference - ----- ------------ - client finished [RFC4346] - server finished [RFC4346] - master secret [RFC4346] - key expansion [RFC4346] - client EAP encryption [RFC2716] - ttls keying material [draft-funk-eap-ttls-v0-01] - - Future values are allocated via RFC2434 Specification Required - policy. The label is a string consisting of printable ASCII - characters. IANA MUST also verify that one label is not a prefix of - any other label. For example, labels "key" or "master secretary" are - forbidden. - - - - - - - -Rescorla Expires August 23, 2008 [Page 5] - -Internet-Draft TLS Extractors February 2008 - - -7. Acknowledgments - - Thanks to Pasi Eronen for valuable comments and the contents of the - IANA section and Section 3. - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - -8.2. Informational References - - [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer - Security", RFC 4347, April 2006. - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [I-D.ietf-avt-dtls-srtp] - McGrew, D. and E. Rescorla, "Datagram Transport Layer - Security (DTLS) Extension to Establish Keys for Secure - Real-time Transport Protocol (SRTP)", - draft-ietf-avt-dtls-srtp-01 (work in progress), - November 2007. - - -Author's Address - - Eric Rescorla - Network Resonance - 2064 Edgewood Drive - Palo Alto, CA 94303 - USA - - Email: ekr@networkresonance.com - - - - - -Rescorla Expires August 23, 2008 [Page 6] - -Internet-Draft TLS Extractors February 2008 - - -Full 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. - - 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 ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - 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. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Rescorla Expires August 23, 2008 [Page 7] - |