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

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Intended status:  Standards Track                      December 19, 2007
   7 Expires:  June 21, 2008
   8
   9
  10      Keying Material Extractors for Transport Layer Security (TLS)
  11                     draft-ietf-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 June 21, 2008.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (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 June 21, 2008                 [Page 1]
  56 \f
  57 Internet-Draft               TLS Extractors                December 2007
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3
  65    4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
  66    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
  67    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
  68    7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
  69    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  70      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  71      8.2.  Informational References  . . . . . . . . . . . . . . . . . 5
  72    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  73    Intellectual Property and Copyright Statements  . . . . . . . . . . 6
  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 June 21, 2008                 [Page 2]
 112 \f
 113 Internet-Draft               TLS Extractors                December 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.  Signalling Extractors
 150
 151    Other protocols which wish to use extractors SHOULD have some way for
 152    the peers to signal that an extractor will be used.  An example is a
 153    TLS extension, as used in DTLS-SRTP.
 154
 155
 156 4.  Extractor Definition
 157
 158    An extractor takes as input two values:
 159
 160    o  A disambiguating label string
 161    o  A length value
 162
 163    It then computes:
 164
 165
 166
 167 Rescorla                  Expires June 21, 2008                 [Page 3]
 168 \f
 169 Internet-Draft               TLS Extractors                December 2007
 170
 171
 172           PRF(master_secret, label,
 173               SecurityParameters.client_random +
 174               SecurityParameters.server_random)[length]
 175
 176    The output is a pseudorandom bit string of length bytes generated
 177    from the master_secret.
 178
 179    Label values MUST be registered via Specification Required as
 180    described by RFC 2434 [2].  Note that extractor labels have the
 181    potential to collide with existing PRF labels.  In order to prevent
 182    this, labels SHOULD begin with "EXTRACTOR".  This is not a MUST
 183    because there are existing uses which have labels which do not begin
 184    with this prefix.
 185
 186
 187 5.  Security Considerations
 188
 189    Because an extractor produces the same value if applied twice with
 190    the same label to the same master_secret, it is critical that two EKM
 191    values generated with the same label be used for two different
 192    purposes--hence the requirement for IANA registration.  However,
 193    because extractors depend on the TLS PRF, it is not a threat to the
 194    use of an EKM value generated from one label to reveal an EKM value
 195    generated from another label.
 196
 197
 198 6.  IANA Considerations
 199
 200    IANA is requested to create (has created) a TLS Extractor Label
 201    registry for this purpose.  The initial contents of the registry are
 202    given below:
 203
 204       Value                          Reference
 205       -----                          ------------
 206       client finished                [RFC4346]
 207       server finished                [RFC4346]
 208       master secret                  [RFC4346]
 209       key expansion                  [RFC4346]
 210       client EAP encryption          [RFC2716]
 211       ttls keying material           [draft-funk-eap-ttls-v0-01]
 212
 213    Future values are allocated via RFC2434 Specification Required
 214    policy.  The label is a string consisting of printable ASCII
 215    characters.  IANA MUST also verify that one label is not a prefix of
 216    any other label.  For example, labels "key" or "master secretary" are
 217    forbidden.
 218
 219
 220
 221
 222
 223 Rescorla                  Expires June 21, 2008                 [Page 4]
 224 \f
 225 Internet-Draft               TLS Extractors                December 2007
 226
 227
 228 7.  Acknowledgments
 229
 230    Thanks to Pasi Eronen for valuable comments and the contents of the
 231    IANA section.
 232
 233
 234 8.  References
 235
 236 8.1.  Normative References
 237
 238    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 239         Levels", BCP 14, RFC 2119, March 1997.
 240
 241    [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 242         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 243
 244    [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 245         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
 246         RFC 3711, March 2004.
 247
 248    [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
 249         Protocol Version 1.1", RFC 4346, April 2006.
 250
 251    [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 252         Security", RFC 4347, April 2006.
 253
 254 8.2.  Informational References
 255
 256    [6]  McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
 257         (DTLS) Extension to Establish Keys for  Secure Real-time
 258         Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work in
 259         progress), November 2007.
 260
 261
 262 Author's Address
 263
 264    Eric Rescorla
 265    Network Resonance
 266    2064 Edgewood Drive
 267    Palo Alto, CA  94303
 268    USA
 269
 270    Email:  ekr@networkresonance.com
 271
 272
 273
 274
 275
 276
 277
 278
 279 Rescorla                  Expires June 21, 2008                 [Page 5]
 280 \f
 281 Internet-Draft               TLS Extractors                December 2007
 282
 283
 284 Full Copyright Statement
 285
 286    Copyright (C) The IETF Trust (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, THE IETF TRUST AND
 295    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 296    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 297    THE 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 June 21, 2008                 [Page 6]
 336 \f
 337