doc/protocol/draft-rescorla-tls-extractor-00.txt

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Intended status:  Standards Track                       January 14, 2007
   7 Expires:  July 18, 2007
   8
   9
  10      Keying Material Extractors for Transport Layer Security (TLS)
  11                   draft-rescorla-tls-extractor-00.txt
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on July 18, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2007).
  41
  42 Abstract
  43
  44    A number of protocols wish to leverage Transport Layer Security (TLS)
  45    to perform key establishment but then use some of the keying material
  46    for their own purposes.  This document describes a general mechanism
  47    for allowing that.
  48
  49
  50
  51
  52
  53
  54
  55 Rescorla                  Expires July 18, 2007                 [Page 1]
  56 \f
  57 Internet-Draft               TLS Extractors                 January 2007
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
  65    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
  66    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
  67    6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  68      6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
  69      6.2.  Informational References  . . . . . . . . . . . . . . . . . 5
  70    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  71    Intellectual Property and Copyright Statements  . . . . . . . . . . 6
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Rescorla                  Expires July 18, 2007                 [Page 2]
 112 \f
 113 Internet-Draft               TLS Extractors                 January 2007
 114
 115
 116 1.  Introduction
 117
 118    A number of protocols wish to leverage Transport Layer Security (TLS)
 119    [4] or Datagram TLS (DTLS) [5] to perform key establishment but then
 120    use some of the keying material for their own purposes.  A typical
 121    example is DTLS-SRTP [6], which uses DTLS to perform a key exchange
 122    and negotiate the SRTP [3] protection suite and then uses the DTLS
 123    master_secret to generate the SRTP keys.
 124
 125    These applications imply a need to be able to extract Exported Keying
 126    Material (EKM) from TLS/DTLS.  This mechanism has the following
 127    requirements:
 128
 129    o  Both client and server need to be able to extract the same EKM
 130       value.
 131    o  EKM values should be indistinguishable from random by attackers
 132       who don't know the master_secret.
 133    o  It should be possible to extract multiple EKM values from the same
 134       TLS/DTLS association.
 135    o  Knowing one EKM value should not reveal any information about the
 136       master_secret or about other EKM values.
 137
 138    The mechanism described in this document is intended to fill these
 139    requirements.
 140
 141
 142 2.  Conventions Used In This Document
 143
 144    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 145    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 146    document are to be interpreted as described in [1].
 147
 148
 149 3.  Extractor Definition
 150
 151    An extractor takes as input two values:
 152
 153    o  A disambiguating label string
 154    o  A length value
 155
 156    It then computes:
 157
 158
 159           PRF(master_secret, "EXTRACTOR" + label,
 160               SecurityParameters.client_random +
 161               SecurityParameters.server_random)[length]
 162
 163    The output is a pseudorandom bit string of length bytes generated
 164
 165
 166
 167 Rescorla                  Expires July 18, 2007                 [Page 3]
 168 \f
 169 Internet-Draft               TLS Extractors                 January 2007
 170
 171
 172    from the master_secret.
 173
 174    Label values MUST be registered via Specification Required as
 175    described by RFC 2434 [2].
 176
 177
 178 4.  Security Considerations
 179
 180    Because an extractor produces the same value if applied twice with
 181    the same label to the same master_secret, it is critical that two EKM
 182    values generated with the same label be used for two different
 183    purposes--hence the requirement for IANA registration.  However,
 184    because extractors depend on the TLS PRF, it is not a threat to the
 185    use of an EKM value generated from one label to reveal an EKM value
 186    generated from another label.
 187
 188
 189 5.  IANA Considerations
 190
 191    Section Section 3 requires that all extractor labels be registered
 192    via 2434 Specification Required.  IANA has created a TLSExtractor
 193    registry for this purpose.  Future values MUST be allocated via
 194    Specification Required as described in [RFC2434].
 195
 196
 197 6.  References
 198
 199 6.1.  Normative References
 200
 201    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 202         Levels", BCP 14, RFC 2119, March 1997.
 203
 204    [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 205         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 206
 207    [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 208         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
 209         RFC 3711, March 2004.
 210
 211    [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
 212         Protocol Version 1.1", RFC 4346, April 2006.
 213
 214    [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 215         Security", RFC 4347, April 2006.
 216
 217
 218
 219
 220
 221
 222
 223 Rescorla                  Expires July 18, 2007                 [Page 4]
 224 \f
 225 Internet-Draft               TLS Extractors                 January 2007
 226
 227
 228 6.2.  Informational References
 229
 230    [6]  Rescorla, E. and D. McGrew, "Datagram Transport Layer Security
 231         (DTLS) Extension to Establish Keys for  Secure Real-time
 232         Transport Protocol (SRTP)", draft-mcgrew-tls-srtp-00 (work in
 233         progress), June 2006.
 234
 235
 236 Author's Address
 237
 238    Eric Rescorla
 239    Network Resonance
 240    2483 E. Bayshore #212
 241    Palo Alto, CA  94303
 242    USA
 243
 244    Email:  ekr@networkresonance.com
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Rescorla                  Expires July 18, 2007                 [Page 5]
 280 \f
 281 Internet-Draft               TLS Extractors                 January 2007
 282
 283
 284 Full Copyright Statement
 285
 286    Copyright (C) The Internet Society (2007).
 287
 288    This document is subject to the rights, licenses and restrictions
 289    contained in BCP 78, and except as set forth therein, the authors
 290    retain all their rights.
 291
 292    This document and the information contained herein are provided on an
 293    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 294    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 295    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 296    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 297    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 298    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 299
 300
 301 Intellectual Property
 302
 303    The IETF takes no position regarding the validity or scope of any
 304    Intellectual Property Rights or other rights that might be claimed to
 305    pertain to the implementation or use of the technology described in
 306    this document or the extent to which any license under such rights
 307    might or might not be available; nor does it represent that it has
 308    made any independent effort to identify any such rights.  Information
 309    on the procedures with respect to rights in RFC documents can be
 310    found in BCP 78 and BCP 79.
 311
 312    Copies of IPR disclosures made to the IETF Secretariat and any
 313    assurances of licenses to be made available, or the result of an
 314    attempt made to obtain a general license or permission for the use of
 315    such proprietary rights by implementers or users of this
 316    specification can be obtained from the IETF on-line IPR repository at
 317    http://www.ietf.org/ipr.
 318
 319    The IETF invites any interested party to bring to its attention any
 320    copyrights, patents or patent applications, or other proprietary
 321    rights that may cover technology that may be required to implement
 322    this standard.  Please address the information to the IETF at
 323    ietf-ipr@ietf.org.
 324
 325
 326 Acknowledgment
 327
 328    Funding for the RFC Editor function is provided by the IETF
 329    Administrative Support Activity (IASA).
 330
 331
 332
 333
 334
 335 Rescorla                  Expires July 18, 2007                 [Page 6]
 336 \f
 337