idnits 2.17.1 draft-rescorla-tls-extractor-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 232. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC4346' on line 142 -- Looks like a reference, but probably isn't: 'RFC2716' on line 143 ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (ref. '4') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (ref. '5') (Obsoleted by RFC 6347) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-00 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Network Resonance 4 Intended status: Standards Track November 17, 2007 5 Expires: May 20, 2008 7 Keying Material Extractors for Transport Layer Security (TLS) 8 draft-rescorla-tls-extractor-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 A number of protocols wish to leverage Transport Layer Security (TLS) 42 to perform key establishment but then use some of the keying material 43 for their own purposes. This document describes a general mechanism 44 for allowing that. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 50 3. Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3 51 4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 3 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 54 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 57 8.2. Informational References . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 Intellectual Property and Copyright Statements . . . . . . . . . . 6 61 1. Introduction 63 A number of protocols wish to leverage Transport Layer Security (TLS) 64 [4] or Datagram TLS (DTLS) [5] to perform key establishment but then 65 use some of the keying material for their own purposes. A typical 66 example is DTLS-SRTP [6], which uses DTLS to perform a key exchange 67 and negotiate the SRTP [3] protection suite and then uses the DTLS 68 master_secret to generate the SRTP keys. 70 These applications imply a need to be able to extract Exported Keying 71 Material (EKM) from TLS/DTLS. This mechanism has the following 72 requirements: 74 o Both client and server need to be able to extract the same EKM 75 value. 76 o EKM values should be indistinguishable from random by attackers 77 who don't know the master_secret. 78 o It should be possible to extract multiple EKM values from the same 79 TLS/DTLS association. 80 o Knowing one EKM value should not reveal any information about the 81 master_secret or about other EKM values. 83 The mechanism described in this document is intended to fill these 84 requirements. 86 2. Conventions Used In This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [1]. 92 3. Signalling Extractors 94 Other protocols which wish to use extractors SHOULD have some way for 95 the peers to signal that an extractor will be used. An example is a 96 TLS extension, as used in DTLS-SRTP. 98 4. Extractor Definition 100 An extractor takes as input two values: 102 o A disambiguating label string 103 o A length value 105 It then computes: 107 PRF(master_secret, label, 108 SecurityParameters.client_random + 109 SecurityParameters.server_random)[length] 111 The output is a pseudorandom bit string of length bytes generated 112 from the master_secret. 114 Label values MUST be registered via Specification Required as 115 described by RFC 2434 [2]. Note that extractor labels have the 116 potential to collide with existing PRF labels. In order to prevent 117 this, labels SHOULD begin with "EXTRACTOR". This is not a MUST 118 because there are existing uses which have labels which do not begin 119 with this prefix. 121 5. Security Considerations 123 Because an extractor produces the same value if applied twice with 124 the same label to the same master_secret, it is critical that two EKM 125 values generated with the same label be used for two different 126 purposes--hence the requirement for IANA registration. However, 127 because extractors depend on the TLS PRF, it is not a threat to the 128 use of an EKM value generated from one label to reveal an EKM value 129 generated from another label. 131 6. IANA Considerations 133 IANA is requested to create (has created) a TLS Extractor Label 134 registry for this purpose. The initial contents of the registry are 135 given below: 137 Value Reference 138 ----- ------------ 139 client finished [RFC4346] 140 server finished [RFC4346] 141 master secret [RFC4346] 142 key expansion [RFC4346] 143 client EAP encryption [RFC2716] 144 ttls keying material [draft-funk-eap-ttls-v0-01] 146 Future values are allocated via RFC2434 Specification Required 147 policy. The label is a string consisting of printable ASCII 148 characters. IANA MUST also verify that one label is not a prefix of 149 any other label. For example, labels "key" or "master secretary" are 150 forbidden. 152 7. Acknowledgments 154 Thanks to Pasi Eronen for valuable comments and the contents of the 155 IANA section. 157 8. References 159 8.1. Normative References 161 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 162 Levels", BCP 14, RFC 2119, March 1997. 164 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 165 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 167 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 168 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 169 RFC 3711, March 2004. 171 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 172 Protocol Version 1.1", RFC 4346, April 2006. 174 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 175 Security", RFC 4347, April 2006. 177 8.2. Informational References 179 [6] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security 180 (DTLS) Extension to Establish Keys for Secure Real-time 181 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-00 (work in 182 progress), July 2007. 184 Author's Address 186 Eric Rescorla 187 Network Resonance 188 2064 Edgewood Drive 189 Palo Alto, CA 94303 190 USA 192 Email: ekr@networkresonance.com 194 Full Copyright Statement 196 Copyright (C) The IETF Trust (2007). 198 This document is subject to the rights, licenses and restrictions 199 contained in BCP 78, and except as set forth therein, the authors 200 retain all their rights. 202 This document and the information contained herein are provided on an 203 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 204 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 205 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 206 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 207 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 208 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 210 Intellectual Property 212 The IETF takes no position regarding the validity or scope of any 213 Intellectual Property Rights or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; nor does it represent that it has 217 made any independent effort to identify any such rights. Information 218 on the procedures with respect to rights in RFC documents can be 219 found in BCP 78 and BCP 79. 221 Copies of IPR disclosures made to the IETF Secretariat and any 222 assurances of licenses to be made available, or the result of an 223 attempt made to obtain a general license or permission for the use of 224 such proprietary rights by implementers or users of this 225 specification can be obtained from the IETF on-line IPR repository at 226 http://www.ietf.org/ipr. 228 The IETF invites any interested party to bring to its attention any 229 copyrights, patents or patent applications, or other proprietary 230 rights that may cover technology that may be required to implement 231 this standard. Please address the information to the IETF at 232 ietf-ipr@ietf.org. 234 Acknowledgment 236 Funding for the RFC Editor function is provided by the IETF 237 Administrative Support Activity (IASA).