idnits 2.17.1 draft-ietf-tls-extractor-03.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 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The prime security requirement for extractor outputs is that they be independent. More formally, after a particular TLS session, if an adversary is allowed to choose multiple (label, context value) pairs and is given the output of the PRF for those values, the attacker is still unable to distinguish between the output of the PRF for a (label, context value) pair (different from the ones that it submitted) and a random value of the same length. In particular, there may be settings, such as the one described in Section 4, where the attacker can control the context value; such an attacker MUST not be able to predict the output of the extractor. Similarly, an attacker who does not know the master secret should not be able to distinguish valid extractor outputs from random values. The current set of TLS PRFs is believed to meet this objective, provided the master secret is randomly generated. -- 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 01, 2008) is 5655 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) == Missing Reference: 'DTLS-SRTP' is mentioned on line 114, but not defined == Missing Reference: 'RFC2716' is mentioned on line 211, but not defined ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 01, 2008 5 Expires: May 5, 2009 7 Keying Material Extractors for Transport Layer Security (TLS) 8 draft-ietf-tls-extractor-03.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 5, 2009. 35 Abstract 37 A number of protocols wish to leverage Transport Layer Security (TLS) 38 to perform key establishment but then use some of the keying material 39 for their own purposes. This document describes a general mechanism 40 for allowing that. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 46 3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3 47 4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 4 48 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 49 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 50 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 53 8.2. Informational References . . . . . . . . . . . . . . . . . 7 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 Intellectual Property and Copyright Statements . . . . . . . . . . 8 57 1. Introduction 59 A number of protocols wish to leverage Transport Layer Security (TLS) 60 [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key 61 establishment but then use some of the keying material for their own 62 purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], 63 which uses DTLS to perform a key exchange and negotiate the SRTP 64 [RFC3711] protection suite and then uses the DTLS master_secret to 65 generate the SRTP keys. 67 These applications imply a need to be able to extract keying material 68 (later called Exported Keying Material or EKM) from TLS/DTLS, and 69 securely agree on the upper-layer context where the keying material 70 will be used. The mechanism for extracting the keying material has 71 the following requirements: 73 o Both client and server need to be able to extract the same EKM 74 value. 75 o EKM values should be indistinguishable from random by attackers 76 who don't know the master_secret. 77 o It should be possible to extract multiple EKM values from the same 78 TLS/DTLS association. 79 o Knowing one EKM value should not reveal any information about the 80 master_secret or about other EKM values. 82 The mechanism described in this document is intended to fill these 83 requirements. 85 2. Conventions Used In This Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Binding to Application Contexts 93 In addition to extracting keying material, an application using the 94 keying material has to securely establish the upper-layer context 95 where the keying material will be used. The details of this context 96 depend on the application, but it could include things such as 97 algorithms and parameters that will be used with the keys, 98 identifier(s) for the endpoint(s) who will use the keys, 99 identifier(s) for the session(s) where the keys will be used, and the 100 lifetime(s) for the context and/or keys. At minimum, there should be 101 some mechanism for signalling that an extractor will be used. 103 This specification does not mandate a single mechanism for agreeing 104 on such context; instead, there are several possibilities that can be 105 used (and can complement each other). For example: 107 o One important part of the context -- which application will use 108 the extracted keys -- is given by the disambiguating label string 109 (see Section 4). 110 o Information about the upper-layer context can be included in the 111 optional data after the extractor label (see Section 4). 112 o Information about the upper-layer context can be exchanged in TLS 113 extensions included in the ClientHello and ServerHello messages. 114 This approach is used in [DTLS-SRTP]. The handshake messages are 115 protected by the Finished messages, so once the handshake 116 completes, the peers will have the same view of the information. 117 Extensions also allow a limited form of negotiation: for example, 118 the TLS client could propose several alternatives for some context 119 parameters, and TLS server could select one of them. 120 o The upper-layer protocol can include its own handshake which can 121 be protected using the keys extracted from TLS. 123 It is important to note that just embedding TLS messages in the 124 upper-layer protocol may not automatically secure all the important 125 context information, since the upper-layer messages are not covered 126 by TLS Finished messages. 128 4. Extractor Definition 130 The output of the extractor is intended to be used in a single scope, 131 which is associated with the TLS session, the label, and the context 132 value. 134 An extractor takes as input three values: 136 o A disambiguating label string 137 o A per-association context value provided by the extractor using 138 application 139 o A length value 141 It then computes: 143 PRF(master_secret, label, 144 SecurityParameters.client_random + 145 SecurityParameters.server_random + 146 context_value_length + context_value 147 )[length] 149 Where PRF is the TLS PRF in use for the session. The output is a 150 pseudorandom bit string of length bytes generated from the 151 master_secret. 153 Labels here have the same definition as in TLS, i.e., an ASCII string 154 with no terminating NULL. Label values beginning with "EXPERIMENTAL" 155 MAY be used for private use without registration. All other label 156 values MUST be registered via Specification Required as described by 157 RFC 2434 [RFC2434]. Note that extractor labels have the potential to 158 collide with existing PRF labels. In order to prevent this, labels 159 SHOULD begin with "EXTRACTOR". This is not a MUST because there are 160 existing uses which have labels which do not begin with this prefix. 162 opaque context<0..2^16-1>; 164 The context value allows the application using the extractor to mix 165 its own data with the TLS PRF for the extractor output. One example 166 of where this might be useful is an authentication setting where the 167 client credentials are valid for more than one identity; the context 168 value could then be used to mix the expected identity into the keying 169 material, thus preventing substitution attacks. The context value 170 length is encoded as an unsigned 16-bit quantity (uint16) 171 representing the length of the context value. The context MAY be 172 zero length. 174 5. Security Considerations 176 The prime security requirement for extractor outputs is that they be 177 independent. More formally, after a particular TLS session, if an 178 adversary is allowed to choose multiple (label, context value) pairs 179 and is given the output of the PRF for those values, the attacker is 180 still unable to distinguish between the output of the PRF for a 181 (label, context value) pair (different from the ones that it 182 submitted) and a random value of the same length. In particular, 183 there may be settings, such as the one described in Section 4, where 184 the attacker can control the context value; such an attacker MUST not 185 be able to predict the output of the extractor. Similarly, an 186 attacker who does not know the master secret should not be able to 187 distinguish valid extractor outputs from random values. The current 188 set of TLS PRFs is believed to meet this objective, provided the 189 master secret is randomly generated. 191 Because an extractor produces the same value if applied twice with 192 the same label to the same master_secret, it is critical that two EKM 193 values generated with the same label not be used for two different 194 purposes--hence the requirement for IANA registration. However, 195 because extractors depend on the TLS PRF, it is not a threat to the 196 use of an EKM value generated from one label to reveal an EKM value 197 generated from another label. 199 6. IANA Considerations 201 IANA is requested to create (has created) a TLS Extractor Label 202 registry for this purpose. The initial contents of the registry are 203 given below: 205 Value Reference 206 ----- ------------ 207 client finished [RFC4346] 208 server finished [RFC4346] 209 master secret [RFC4346] 210 key expansion [RFC4346] 211 client EAP encryption [RFC2716] 212 ttls keying material [draft-funk-eap-ttls-v0-01] 214 Future values are allocated via RFC2434 Specification Required 215 policy. The label is a string consisting of printable ASCII 216 characters. IANA MUST also verify that one label is not a prefix of 217 any other label. For example, labels "key" or "master secretary" are 218 forbidden. 220 7. Acknowledgments 222 Thanks to Pasi Eronen for valuable comments and the contents of the 223 IANA section and Section 3. Thanks to David McGrew for helpful 224 discussion of the security considerations. 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 234 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 235 October 1998. 237 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 238 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 240 8.2. Informational References 242 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 243 Security", RFC 4347, April 2006. 245 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 246 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 247 RFC 3711, March 2004. 249 [I-D.ietf-avt-dtls-srtp] 250 McGrew, D. and E. Rescorla, "Datagram Transport Layer 251 Security (DTLS) Extension to Establish Keys for Secure 252 Real-time Transport Protocol (SRTP)", 253 draft-ietf-avt-dtls-srtp-06 (work in progress), 254 October 2008. 256 Author's Address 258 Eric Rescorla 259 Network Resonance 260 2064 Edgewood Drive 261 Palo Alto, CA 94303 262 USA 264 Email: ekr@networkresonance.com 266 Full Copyright Statement 268 Copyright (C) The IETF Trust (2008). 270 This document is subject to the rights, licenses and restrictions 271 contained in BCP 78, and except as set forth therein, the authors 272 retain all their rights. 274 This document and the information contained herein are provided on an 275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 277 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 278 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 279 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 Intellectual Property 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at 304 ietf-ipr@ietf.org.