idnits 2.17.1 draft-ietf-tls-extractor-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 exporter 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 exporter. Similarly, an attacker who does not know the master secret should not be able to distinguish valid exporter 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 07, 2009) is 5529 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 136, but not defined == Missing Reference: 'RFC2716' is mentioned on line 231, but not defined ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5281 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track March 07, 2009 5 Expires: September 8, 2009 7 Keying Material Exporters for Transport Layer Security (TLS) 8 draft-ietf-tls-extractor-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 8, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 A number of protocols wish to leverage Transport Layer Security (TLS) 57 to perform key establishment but then use some of the keying material 58 for their own purposes. This document describes a general mechanism 59 for allowing that. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 65 3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3 66 4. Exporter Definition . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 8.2. Informational References . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Note: The mechanism described in this document was previously known 78 as "TLS Extractors" but was changed to avoid a name conflict with 79 the use of the term "Extractor" in the cryptographic community. 81 A number of protocols wish to leverage Transport Layer Security (TLS) 82 [RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key 83 establishment but then use some of the keying material for their own 84 purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], 85 which uses DTLS to perform a key exchange and negotiate the SRTP 86 [RFC3711] protection suite and then uses the DTLS master_secret to 87 generate the SRTP keys. 89 These applications imply a need to be able to export keying material 90 (later called Exported Keying Material or EKM) from TLS/DTLS, and 91 securely agree on the upper-layer context where the keying material 92 will be used. The mechanism for exporting the keying material has 93 the following requirements: 95 o Both client and server need to be able to export the same EKM 96 value. 97 o EKM values should be indistinguishable from random by attackers 98 who don't know the master_secret. 99 o It should be possible to export multiple EKM values from the same 100 TLS/DTLS association. 101 o Knowing one EKM value should not reveal any information about the 102 master_secret or about other EKM values. 104 The mechanism described in this document is intended to fulfill these 105 requirements. 107 2. Conventions Used In This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Binding to Application Contexts 115 In addition to exporting keying material, an application using the 116 keying material has to securely establish the upper-layer context 117 where the keying material will be used. The details of this context 118 depend on the application, but it could include things such as 119 algorithms and parameters that will be used with the keys, 120 identifier(s) for the endpoint(s) who will use the keys, 121 identifier(s) for the session(s) where the keys will be used, and the 122 lifetime(s) for the context and/or keys. At minimum, there should be 123 some mechanism for signalling that an exporter will be used. 125 This specification does not mandate a single mechanism for agreeing 126 on such context; instead, there are several possibilities that can be 127 used (and can complement each other). For example: 129 o One important part of the context -- which application will use 130 the exported keys -- is given by the disambiguating label string 131 (see Section 4). 132 o Information about the upper-layer context can be included in the 133 optional data after the exporter label (see Section 4). 134 o Information about the upper-layer context can be exchanged in TLS 135 extensions included in the ClientHello and ServerHello messages. 136 This approach is used in [DTLS-SRTP]. The handshake messages are 137 protected by the Finished messages, so once the handshake 138 completes, the peers will have the same view of the information. 139 Extensions also allow a limited form of negotiation: for example, 140 the TLS client could propose several alternatives for some context 141 parameters, and the TLS server could select one of them. 142 o The upper-layer protocol can include its own handshake which can 143 be protected using the keys exported from TLS. 145 It is important to note that just embedding TLS messages in the 146 upper-layer protocol may not automatically secure all the important 147 context information, since the upper-layer messages are not covered 148 by TLS Finished messages. 150 4. Exporter Definition 152 The output of the exporter is intended to be used in a single scope, 153 which is associated with the TLS session, the label, and the context 154 value. 156 o A disambiguating label string 157 o A per-association context value provided by the application using 158 the exporter 159 o A length value 161 It then computes: 163 PRF(SecurityParameters.master_secret, label, 164 SecurityParameters.client_random + 165 SecurityParameters.server_random + 166 context_value_length + context_value 167 )[length] 169 Where PRF is the TLS PRF in use for the session. The output is a 170 pseudorandom bit string of length bytes generated from the 171 master_secret. 173 Labels here have the same definition as in TLS, i.e., an ASCII string 174 with no terminating NULL. Label values beginning with "EXPERIMENTAL" 175 MAY be used for private use without registration. All other label 176 values MUST be registered via Specification Required as described by 177 RFC 5226 [RFC5226]. Note that exporter labels have the potential to 178 collide with existing PRF labels. In order to prevent this, labels 179 SHOULD begin with "EXPORTER". This is not a MUST because there are 180 existing uses which have labels which do not begin with this prefix. 182 opaque context<0..2^16-1>; 184 The context value allows the application using the exporter to mix 185 its own data with the TLS PRF for the exporter output. One example 186 of where this might be useful is an authentication setting where the 187 client credentials are valid for more than one identity; the context 188 value could then be used to mix the expected identity into the keying 189 material, thus preventing substitution attacks. The context value 190 length is encoded as an unsigned 16-bit quantity (uint16) 191 representing the length of the context value. The context MAY be 192 zero length. 194 5. Security Considerations 196 The prime security requirement for exporter outputs is that they be 197 independent. More formally, after a particular TLS session, if an 198 adversary is allowed to choose multiple (label, context value) pairs 199 and is given the output of the PRF for those values, the attacker is 200 still unable to distinguish between the output of the PRF for a 201 (label, context value) pair (different from the ones that it 202 submitted) and a random value of the same length. In particular, 203 there may be settings, such as the one described in Section 4, where 204 the attacker can control the context value; such an attacker MUST not 205 be able to predict the output of the exporter. Similarly, an 206 attacker who does not know the master secret should not be able to 207 distinguish valid exporter outputs from random values. The current 208 set of TLS PRFs is believed to meet this objective, provided the 209 master secret is randomly generated. 211 Because an exporter produces the same value if applied twice with the 212 same label to the same master_secret, it is critical that two EKM 213 values generated with the same label not be used for two different 214 purposes--hence the requirement for IANA registration. However, 215 because exporters depend on the TLS PRF, it is not a threat to the 216 use of an EKM value generated from one label to reveal an EKM value 217 generated from another label. 219 6. IANA Considerations 221 IANA is requested to create (has created) a TLS Exporter Label 222 registry for this purpose. The initial contents of the registry are 223 given below: 225 Value Reference 226 ----- ------------ 227 client finished [RFC5246] 228 server finished [RFC5246] 229 master secret [RFC5246] 230 key expansion [RFC5246] 231 client EAP encryption [RFC2716] 232 ttls keying material [RFC5281] 233 ttls challenge [RFC5281] 235 Future values are allocated via RFC5226 Specification Required 236 policy. The label is a string consisting of printable ASCII 237 characters. IANA MUST also verify that one label is not a prefix of 238 any other label. For example, labels "key" or "master secretary" are 239 forbidden. 241 7. Acknowledgments 243 Thanks to Pasi Eronen for valuable comments and the contents of the 244 IANA section and Section 3. Thanks to David McGrew for helpful 245 discussion of the security considerations and Alfred Hoenes for 246 editorial comments. 248 8. References 250 8.1. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 256 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 257 May 2008. 259 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 260 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 262 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 263 Protocol Tunneled Transport Layer Security Authenticated 264 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 266 8.2. Informational References 268 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 269 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 270 RFC 3711, March 2004. 272 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 273 Security", RFC 4347, April 2006. 275 [I-D.ietf-avt-dtls-srtp] 276 McGrew, D. and E. Rescorla, "Datagram Transport Layer 277 Security (DTLS) Extension to Establish Keys for Secure 278 Real-time Transport Protocol (SRTP)", 279 draft-ietf-avt-dtls-srtp-07 (work in progress), 280 February 2009. 282 Author's Address 284 Eric Rescorla 285 RTFM, Inc. 286 2064 Edgewood Drive 287 Palo Alto, CA 94303 288 USA 290 Email: ekr@rtfm.com