doc/protocol/draft-rescorla-tls-opaque-prf-input-00.txt

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Expires:  June 16, 2007                                        M. Salter
   7                                                 National Security Agency
   8                                                        December 13, 2006
   9
  10
  11                        Opaque PRF Inputs for TLS
  12                draft-rescorla-tls-opaque-prf-input-00.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on June 16, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    This document describes a mechanism for using opaque PRF inputs with
  46    Transport Layer Security (TLS) and Datagram TLS (DTLS).
  47
  48
  49
  50
  51
  52
  53
  54
  55 Rescorla & Salter         Expires June 16, 2007                 [Page 1]
  56 \f
  57 Internet-Draft            TLS Opaque PRF Inputs            December 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  The OpaquePRFInput Extension  . . . . . . . . . . . . . . . . . 3
  65      3.1.  Negotiating the OpaquePRFInput Extension  . . . . . . . . . 4
  66      3.2.  PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
  67    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  68      4.1.  Threats to TLS  . . . . . . . . . . . . . . . . . . . . . . 5
  69      4.2.  New Security Issues . . . . . . . . . . . . . . . . . . . . 5
  70      4.3.  Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
  71    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
  72    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  73    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  74      7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  75      7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
  76    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
  77    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  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 & Salter         Expires June 16, 2007                 [Page 2]
 112 \f
 113 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 114
 115
 116 1.  Introduction
 117
 118    TLS [RFC4346] and DTLS [RFC4347] use a 32-byte "Random" value
 119    consisting of a 32-bit time value time and 28 randomly generated
 120    bytes:
 121
 122          struct {
 123             uint32 gmt_unix_time;
 124             opaque random_bytes[28];
 125          } Random;
 126
 127    The client and server each contribute a Random value which is then
 128    mixed with secret keying material to produce the final per-
 129    association keying material.
 130
 131    In a number of United States Government applications, it is desirable
 132    to have some material with the following properties:
 133
 134    1.  It is contributed both by client and server.
 135    2.  It is arbitrary-length.
 136    3.  It is mixed into the eventual keying material.
 137    4.  It is structured and decodable by the receiving party.
 138
 139    These requirements are incompatible with the current Random
 140    mechanism, which supports a short, fixed-length value.  This document
 141    describes a mechanism called "Opaque PRF Inputs for TLS" that meets
 142    these 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.  The OpaquePRFInput Extension
 153
 154    The OpaquePRFInput is carried in a new TLS extension called
 155    "OpaquePRFInput".
 156
 157         struct {
 158             opaque opaque_prf_input_value<0..2^16-1>;
 159         } OpaquePRFInput;
 160
 161    The opaque_prf_input_value is an opaque byte-string which is
 162    generated in an implementation-dependent fashion.  It MAY be
 163    generated by and/or made available to the TLS/DTLS-using application.
 164
 165
 166
 167 Rescorla & Salter         Expires June 16, 2007                 [Page 3]
 168 \f
 169 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 170
 171
 172 3.1.  Negotiating the OpaquePRFInput Extension
 173
 174    The client requests support for the opaque PRF input feature by
 175    sending an "opaque_prf_input" extension in its ClientHello.  The
 176    "extension_data" field contains an OpaquePRFInput value.
 177
 178    When a server which does not recognize the "opaque_prf_input"
 179    extension receives one, it will ignore it as required by [RFC4366].
 180    A server which recognizes the extension MAY choose to ignore it, in
 181    which case it SHOULD continue with the exchange as if it had not
 182    received the extension.
 183
 184    If the server wishes to use the opaque PRF input feature, it MUST
 185    send its own "opaque_prf_input" extension with an
 186    opaque_prf_input_value equal in length to the client's
 187    opaque_prf_input_value.  Clients SHOULD check the length of the
 188    server's opaque_prf_input_value and generate a fatal
 189    "illegal_parameter" error if it is present but does does not match
 190    the length that was transmitted in the ClientHello.
 191
 192    Because RFC 4366 does not permit servers to request extensions which
 193    the client did not offer, the client may not offer the
 194    "opaque_prf_input" extension even if the server requires it.  In this
 195    case, the server should generate a fatal "handshake_failure" alert.
 196
 197    Because there is no way to mark extensions as critical, the server
 198    may ignore the "opaque_prf_input" extension even though the client
 199    requires it.  If a client requires the opaque PRF input feature but
 200    the server does not negotiate it, the client SHOULD generate a fatal
 201    "handshake_failure" alert.
 202
 203 3.2.  PRF Modifications
 204
 205    When the opaque PRF input feature is in use, the opaque PRF input
 206    values MUST be mixed into the PRF along with the client and server
 207    random values during the PMS->MS conversion.  Thus, the PRF becomes:
 208
 209           master_secret = PRF(pre_master_secret, "master secret",
 210                               ClientHello.random +
 211                               ClientHello.opaque_prf_input_value +
 212                               ServerHello.random +
 213                               ServerHello.opaque_prf_input_value)[0..47];
 214
 215    Because new extensions may not be introduced in resumed handshakes,
 216    mixing in the opaque PRF inputs during the MS->keying material
 217    conversion would simply involve mixing in the same material twice.
 218    Therefore, the opaque PRF inputs are only used when the PMS is
 219    converted into the MS.
 220
 221
 222
 223 Rescorla & Salter         Expires June 16, 2007                 [Page 4]
 224 \f
 225 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 226
 227
 228 4.  Security Considerations
 229
 230 4.1.  Threats to TLS
 231
 232    When this extension is in use it increases the amount of data that an
 233    attacker can inject into the PRF.  This potentially would allow an
 234    attacker who had partially compromised the PRF greater scope for
 235    influencing the output.  Hash-based PRFs like the one in TLS are
 236    designed to be fairly indifferent to the input size (the input is
 237    already greater than the block size of most hash functions), however
 238    there is currently no proof that a larger input space would not make
 239    attacks easier.
 240
 241    Another concern is that bad implementations might generate low
 242    entropy opaque PRF input values.  TLS is designed to function
 243    correctly even when fed low-entropy random values because they are
 244    primarily used to generate distinct keying material for each
 245    connection.
 246
 247 4.2.  New Security Issues
 248
 249    As noted in Section 3 it is anticipated that applications may want to
 250    have access to the opaque PRF input values and that they may contain
 251    data that is meaningful at a higher layer.  Because the values are
 252    covered by the TLS Finished message, they are integrity-protected by
 253    TLS.  However, the application must independently provide any
 254    confidentiality necessary for those values.
 255
 256 4.3.  Scope of Randomness
 257
 258    RFC 4366 specifies that when a session is resumed the extensions from
 259    the original connection are used:
 260
 261          If, on the other hand, the older session is resumed, then the
 262          server MUST ignore the extensions and send a server hello
 263          containing none of the extension types.  In this case, the
 264          functionality of these extensions negotiated during the original
 265          session initiation is applied to the resumed session.
 266
 267    This motivates why the the opaque PRF input does not get mixed into
 268    the PRF when generating the keying material from the master secret.
 269    Because the same opaque PRF inputs would be used for every connection
 270    in a session, they would not provide any differentiation in the
 271    keying material between the connections.
 272
 273
 274 5.  IANA Considerations
 275
 276
 277
 278
 279 Rescorla & Salter         Expires June 16, 2007                 [Page 5]
 280 \f
 281 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 282
 283
 284    This document defines an extension to TLS, in accordance with
 285    [RFC4366]:
 286
 287      enum { opaque_prf_input (??) } ExtensionType;
 288
 289    [[ NOTE:  These values need to be assigned by IANA ]]
 290
 291
 292 6.  Acknowledgements
 293
 294    This work was supported by the US Department of Defense.
 295
 296
 297 7.  References
 298
 299 7.1.  Normative References
 300
 301    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 302               Requirement Levels", BCP 14, RFC 2119, March 1997.
 303
 304    [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 305               and T. Wright, "Transport Layer Security (TLS)
 306               Extensions", RFC 4366, April 2006.
 307
 308    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 309               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 310
 311    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 312               Security", RFC 4347, April 2006.
 313
 314    [I-D.ietf-tls-rfc4346-bis]
 315               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 316               1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
 317               October 2006.
 318
 319 7.2.  Informative References
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Rescorla & Salter         Expires June 16, 2007                 [Page 6]
 336 \f
 337 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 338
 339
 340 Authors' Addresses
 341
 342    Eric Rescorla
 343    Network Resonance
 344    2483 E. Bayshore #212
 345    Palo Alto, CA  94303
 346    USA
 347
 348    Email:  ekr@networkresonance.com
 349
 350
 351    Margaret Salter
 352    National Security Agency
 353    9800 Savage Rd.
 354    Fort Meade  20755-6709
 355    USA
 356
 357    Email:  msalter@restarea.ncsc.mil
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Rescorla & Salter         Expires June 16, 2007                 [Page 7]
 392 \f
 393 Internet-Draft            TLS Opaque PRF Inputs            December 2006
 394
 395
 396 Intellectual Property Statement
 397
 398    The IETF takes no position regarding the validity or scope of any
 399    Intellectual Property Rights or other rights that might be claimed to
 400    pertain to the implementation or use of the technology described in
 401    this document or the extent to which any license under such rights
 402    might or might not be available; nor does it represent that it has
 403    made any independent effort to identify any such rights.  Information
 404    on the procedures with respect to rights in RFC documents can be
 405    found in BCP 78 and BCP 79.
 406
 407    Copies of IPR disclosures made to the IETF Secretariat and any
 408    assurances of licenses to be made available, or the result of an
 409    attempt made to obtain a general license or permission for the use of
 410    such proprietary rights by implementers or users of this
 411    specification can be obtained from the IETF on-line IPR repository at
 412    http://www.ietf.org/ipr.
 413
 414    The IETF invites any interested party to bring to its attention any
 415    copyrights, patents or patent applications, or other proprietary
 416    rights that may cover technology that may be required to implement
 417    this standard.  Please address the information to the IETF at
 418    ietf-ipr@ietf.org.
 419
 420
 421 Disclaimer of Validity
 422
 423    This document and the information contained herein are provided on an
 424    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 425    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 426    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 427    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 428    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 429    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 430
 431
 432 Copyright Statement
 433
 434    Copyright (C) The Internet Society (2006).  This document is subject
 435    to the rights, licenses and restrictions contained in BCP 78, and
 436    except as set forth therein, the authors retain all their rights.
 437
 438
 439 Acknowledgment
 440
 441    Funding for the RFC Editor function is currently provided by the
 442    Internet Society.
 443
 444
 445
 446
 447 Rescorla & Salter         Expires June 16, 2007                 [Page 8]
 448 \f
 449