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

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Intended status:  Standards Track                      February 20, 2008
   7 Expires:  August 23, 2008
   8
   9
  10      Keying Material Extractors for Transport Layer Security (TLS)
  11                     draft-ietf-tls-extractor-01.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 August 23, 2008.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2008).
  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 August 23, 2008                [Page 1]
  56 \f
  57 Internet-Draft               TLS Extractors                February 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  Binding to Application Contexts . . . . . . . . . . . . . . . . 3
  65    4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 4
  66    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  67    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
  68    7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
  69    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  70      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  71      8.2.  Informational References  . . . . . . . . . . . . . . . . . 6
  72    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  73    Intellectual Property and Copyright Statements  . . . . . . . . . . 7
  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 August 23, 2008                [Page 2]
 112 \f
 113 Internet-Draft               TLS Extractors                February 2008
 114
 115
 116 1.  Introduction
 117
 118    A number of protocols wish to leverage Transport Layer Security (TLS)
 119    [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key
 120    establishment but then use some of the keying material for their own
 121    purposes.  A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp],
 122    which uses DTLS to perform a key exchange and negotiate the SRTP
 123    [RFC3711] protection suite and then uses the DTLS master_secret to
 124    generate the SRTP keys.
 125
 126    These applications imply a need to be able to extract keying material
 127    (later called Exported Keying Material or EKM) from TLS/DTLS, and
 128    securely agree on the upper-layer context where the keying material
 129    will be used.  The mechanism for extracting the keying material has
 130    the following requirements:
 131
 132    o  Both client and server need to be able to extract the same EKM
 133       value.
 134    o  EKM values should be indistinguishable from random by attackers
 135       who don't know the master_secret.
 136    o  It should be possible to extract multiple EKM values from the same
 137       TLS/DTLS association.
 138    o  Knowing one EKM value should not reveal any information about the
 139       master_secret or about other EKM values.
 140
 141    The mechanism described in this document is intended to fill these
 142    requirements.
 143
 144
 145 2.  Conventions Used In This Document
 146
 147    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 148    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 149    document are to be interpreted as described in [RFC2119].
 150
 151
 152 3.  Binding to Application Contexts
 153
 154    In addition to extracting keying material, an application using the
 155    keying material has to securely establish the upper-layer layer
 156    context where the keying material will be used.  The details of this
 157    context depend on the application, but it could include things such
 158    as algorithms and parameters that will be used with the keys,
 159    identifier(s) for the endpoint(s) who will use the keys,
 160    identifier(s) for the session(s) where the keys will be used, and the
 161    lifetime(s) for the context and/or keys.  At minimum, there should be
 162    some mechanism for signalling that an extractor will be used.
 163
 164
 165
 166
 167 Rescorla                 Expires August 23, 2008                [Page 3]
 168 \f
 169 Internet-Draft               TLS Extractors                February 2008
 170
 171
 172    This specification does not mandate a single mechanism for agreeing
 173    on such context; instead, there are several possibilities that can be
 174    used (and can complement each other).  For example:
 175
 176    o  One important part of the context -- which application will use
 177       the extracted keys -- is given by the disambiguating label string
 178       (see Section 4).
 179    o  Information about the upper-layer context can be included in the
 180       optional data after the extractor label (see Section 4).
 181    o  Information about the upper-layer context can be exchanged in TLS
 182       extensions included in the ClientHello and ServerHello messages.
 183       This approach is used in [DTLS-SRTP].  The handshake messages are
 184       protected by the Finished messages, so once the handshake
 185       completes, the peers will have the same view of the information.
 186       Extensions also allow a limited form of negotiation:  for example,
 187       the TLS client could propose several alternatives for some context
 188       parameters, and TLS server could select one of them.
 189    o  The upper-layer protocol can include its own handshake which can
 190       be protected using the keys extracted from TLS.
 191
 192    It is important to note that just embedding TLS messages in the
 193    upper-layer protocol may not automatically secure all the important
 194    context information, since the upper-layer messages are not covered
 195    by TLS Finished messages.
 196
 197
 198 4.  Extractor Definition
 199
 200    An extractor takes as input three values:
 201
 202    o  A disambiguating label string
 203    o  A per-association context value provided by the extractor using
 204       application
 205    o  A length value
 206
 207    It then computes:
 208
 209
 210           PRF(master_secret, label,
 211               SecurityParameters.client_random +
 212               SecurityParameters.server_random +
 213               context_value_length + context_value
 214               )[length]
 215
 216    The output is a pseudorandom bit string of length bytes generated
 217    from the master_secret.
 218
 219    Label values beginning with "EXPERIMENTAL" MAY be used for private
 220
 221
 222
 223 Rescorla                 Expires August 23, 2008                [Page 4]
 224 \f
 225 Internet-Draft               TLS Extractors                February 2008
 226
 227
 228    use without registration.  All other label values MUST be registered
 229    via Specification Required as described by RFC 2434 [RFC2434].  Note
 230    that extractor labels have the potential to collide with existing PRF
 231    labels.  In order to prevent this, labels SHOULD begin with
 232    "EXTRACTOR".  This is not a MUST because there are existing uses
 233    which have labels which do not begin with this prefix.
 234
 235    The context value allows the application using the extractor to mix
 236    its own data with the TLS PRF for the extractor output.  The context
 237    value length is encoded as an unsigned 16-bit quantity (uint16)
 238    representing the length of the context value.
 239
 240
 241 5.  Security Considerations
 242
 243    Because an extractor produces the same value if applied twice with
 244    the same label to the same master_secret, it is critical that two EKM
 245    values generated with the same label be used for two different
 246    purposes--hence the requirement for IANA registration.  However,
 247    because extractors depend on the TLS PRF, it is not a threat to the
 248    use of an EKM value generated from one label to reveal an EKM value
 249    generated from another label.
 250
 251
 252 6.  IANA Considerations
 253
 254    IANA is requested to create (has created) a TLS Extractor Label
 255    registry for this purpose.  The initial contents of the registry are
 256    given below:
 257
 258       Value                          Reference
 259       -----                          ------------
 260       client finished                [RFC4346]
 261       server finished                [RFC4346]
 262       master secret                  [RFC4346]
 263       key expansion                  [RFC4346]
 264       client EAP encryption          [RFC2716]
 265       ttls keying material           [draft-funk-eap-ttls-v0-01]
 266
 267    Future values are allocated via RFC2434 Specification Required
 268    policy.  The label is a string consisting of printable ASCII
 269    characters.  IANA MUST also verify that one label is not a prefix of
 270    any other label.  For example, labels "key" or "master secretary" are
 271    forbidden.
 272
 273
 274
 275
 276
 277
 278
 279 Rescorla                 Expires August 23, 2008                [Page 5]
 280 \f
 281 Internet-Draft               TLS Extractors                February 2008
 282
 283
 284 7.  Acknowledgments
 285
 286    Thanks to Pasi Eronen for valuable comments and the contents of the
 287    IANA section and Section 3.
 288
 289
 290 8.  References
 291
 292 8.1.  Normative References
 293
 294    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 295               Requirement Levels", BCP 14, RFC 2119, March 1997.
 296
 297    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
 298               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 299               October 1998.
 300
 301    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 302               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 303
 304 8.2.  Informational References
 305
 306    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 307               Security", RFC 4347, April 2006.
 308
 309    [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 310               Norrman, "The Secure Real-time Transport Protocol (SRTP)",
 311               RFC 3711, March 2004.
 312
 313    [I-D.ietf-avt-dtls-srtp]
 314               McGrew, D. and E. Rescorla, "Datagram Transport Layer
 315               Security (DTLS) Extension to Establish Keys for  Secure
 316               Real-time Transport Protocol (SRTP)",
 317               draft-ietf-avt-dtls-srtp-01 (work in progress),
 318               November 2007.
 319
 320
 321 Author's Address
 322
 323    Eric Rescorla
 324    Network Resonance
 325    2064 Edgewood Drive
 326    Palo Alto, CA  94303
 327    USA
 328
 329    Email:  ekr@networkresonance.com
 330
 331
 332
 333
 334
 335 Rescorla                 Expires August 23, 2008                [Page 6]
 336 \f
 337 Internet-Draft               TLS Extractors                February 2008
 338
 339
 340 Full Copyright Statement
 341
 342    Copyright (C) The IETF Trust (2008).
 343
 344    This document is subject to the rights, licenses and restrictions
 345    contained in BCP 78, and except as set forth therein, the authors
 346    retain all their rights.
 347
 348    This document and the information contained herein are provided on an
 349    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 350    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 351    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 352    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 353    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 354    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 355
 356
 357 Intellectual Property
 358
 359    The IETF takes no position regarding the validity or scope of any
 360    Intellectual Property Rights or other rights that might be claimed to
 361    pertain to the implementation or use of the technology described in
 362    this document or the extent to which any license under such rights
 363    might or might not be available; nor does it represent that it has
 364    made any independent effort to identify any such rights.  Information
 365    on the procedures with respect to rights in RFC documents can be
 366    found in BCP 78 and BCP 79.
 367
 368    Copies of IPR disclosures made to the IETF Secretariat and any
 369    assurances of licenses to be made available, or the result of an
 370    attempt made to obtain a general license or permission for the use of
 371    such proprietary rights by implementers or users of this
 372    specification can be obtained from the IETF on-line IPR repository at
 373    http://www.ietf.org/ipr.
 374
 375    The IETF invites any interested party to bring to its attention any
 376    copyrights, patents or patent applications, or other proprietary
 377    rights that may cover technology that may be required to implement
 378    this standard.  Please address the information to the IETF at
 379    ietf-ipr@ietf.org.
 380
 381
 382 Acknowledgment
 383
 384    Funding for the RFC Editor function is provided by the IETF
 385    Administrative Support Activity (IASA).
 386
 387
 388
 389
 390
 391 Rescorla                 Expires August 23, 2008                [Page 7]
 392 \f