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

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