doc/protocol/draft-rescorla-tls-extended-random-00.txt

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                                RTFM, Inc.
   6 Intended status:  Informational                                M. Salter
   7 Expires:  October 31, 2008                      National Security Agency
   8                                                           April 29, 2008
   9
  10
  11                      Extended Random Values for TLS
  12                draft-rescorla-tls-extended-random-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 October 31, 2008.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2008).
  42
  43 Abstract
  44
  45    This document describes an extension for using larger client and
  46    server Random values with Transport Layer Security (TLS) and Datagram
  47    TLS (DTLS).
  48
  49
  50
  51
  52
  53
  54
  55 Rescorla & Salter       Expires October 31, 2008                [Page 1]
  56 \f
  57 Internet-Draft             Extended TLS Random                April 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
  64    3.  The ExtendedRandom Extension  . . . . . . . . . . . . . . . . . 3
  65      3.1.  Negotiating the ExtendedRandom Extension  . . . . . . . . . 4
  66      3.2.  PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
  67    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  68      4.1.  Threats to TLS  . . . . . . . . . . . . . . . . . . . . . . 5
  69      4.2.  Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
  70    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
  71    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
  72    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  73      7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  74      7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
  75    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
  76    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  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 & Salter       Expires October 31, 2008                [Page 2]
 112 \f
 113 Internet-Draft             Extended TLS Random                April 2008
 114
 115
 116 1.  Introduction
 117
 118    TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
 119    "Random" value consisting of a 32-bit time value time and 28 randomly
 120    generated 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    The United States Department of Defense has requested a TLS mode
 132    which allows the use of longer public randomness values for use with
 133    high security level cipher suites like those specified in Suite B
 134    [I-D.rescorla-tls-suiteb].  The rationale for this as stated by DoD
 135    is that the public randomness for each side should be at least twice
 136    as long as the security level for cryptographic parity, which makes
 137    the 224 bits of randomness provided by the current TLS random values
 138    insufficient.
 139
 140    This document specifies an extension which allows for additional
 141    randomness to be exchanged in the Hello messages.
 142
 143
 144 2.  Conventions Used In This Document
 145
 146    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 147    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 148    document are to be interpreted as described in [RFC2119].
 149
 150
 151 3.  The ExtendedRandom Extension
 152
 153    This document defines a new TLS extension called "extended_random".
 154
 155    The "extended_random" extension carried in a new TLS extension called
 156    "ExtendedRandom".
 157
 158         struct {
 159             opaque extended_random_value<0..2^16-1>;
 160         } ExtendedRandom;
 161
 162    The extended_random_value MUST be a randomly generated byte string.
 163    A cryptographically secure PRNG [RFC4086] SHOULD be used.
 164
 165
 166
 167 Rescorla & Salter       Expires October 31, 2008                [Page 3]
 168 \f
 169 Internet-Draft             Extended TLS Random                April 2008
 170
 171
 172 3.1.  Negotiating the ExtendedRandom Extension
 173
 174    The client requests support for the extended randomness feature by
 175    sending an "extended_random" extension in its ClientHello.  The
 176    "extension_data" field contains an ExtendedRandom value.
 177
 178    When a server which does not recognize the "extended_random"
 179    extension receives one, it will ignore it as required.  A server
 180    which recognizes the extension MAY choose to ignore it, in which case
 181    it SHOULD continue with the exchange as if it had not received the
 182    extension.
 183
 184    If the server wishes to use the extended randomness feature, it MUST
 185    send its own "extended_random" extension with an
 186    extended_random_value equal in length to the client's
 187    extended_random_value.  Clients SHOULD check the length of the
 188    server's extended_random_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 TLS does not permit servers to request extensions which the
 193    client did not offer, the client may not offer the "extended_random"
 194    extension even if the server requires it.  In this case, the server
 195    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 "extended_random" extension even though the client
 199    requires it.  If a client requires the extended randomness input
 200    feature but the server does not negotiate it, the client SHOULD
 201    generate a fatal "handshake_failure" alert.
 202
 203 3.2.  PRF Modifications
 204
 205    When the extended randomness feature is in use, the extended random
 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.extended_random_value +
 212                               ServerHello.random +
 213                               ServerHello.extended_random_value)[0..47];
 214
 215    Because new extensions may not be introduced in resumed handshakes,
 216    mixing in the extended inputs during the MS->keying material
 217    conversion would simply involve mixing in the same material twice.
 218    Therefore, the extended random inputs are only used when the PMS is
 219    converted into the MS.
 220
 221
 222
 223 Rescorla & Salter       Expires October 31, 2008                [Page 4]
 224 \f
 225 Internet-Draft             Extended TLS Random                April 2008
 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 extented random 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.  Scope of Randomness
 248
 249    TLS specifies that when a session is resumed the extensions from the
 250    original connection are used:
 251
 252         If, on the other hand, the older session is resumed, then the
 253         server MUST ignore the extensions and send a server hello
 254         containing none of the extension types.  In this case, the
 255         functionality of these extensions negotiated during the original
 256         session initiation is applied to the resumed session.
 257
 258    This motivates why the the extended randomness does not get mixed
 259    into the PRF when generating the keying material from the master
 260    secret.  Because the same values would be used for every connection
 261    in a session, they would not provide any differentiation in the
 262    keying material between the connections.
 263
 264
 265 5.  IANA Considerations
 266
 267    This document defines an extension to TLS, in accordance with
 268    [I-D.ietf-tls-rfc4366-bis]:
 269
 270      enum { extended_random (??) } ExtensionType;
 271
 272    [[ NOTE:  These values need to be assigned by IANA ]]
 273
 274
 275
 276
 277
 278
 279 Rescorla & Salter       Expires October 31, 2008                [Page 5]
 280 \f
 281 Internet-Draft             Extended TLS Random                April 2008
 282
 283
 284 6.  Acknowledgements
 285
 286    This work was supported by the US Department of Defense.
 287
 288
 289 7.  References
 290
 291 7.1.  Normative References
 292
 293    [I-D.ietf-tls-rfc4346-bis]
 294               Dierks, T. and E. Rescorla, "The Transport Layer Security
 295               (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
 296               (work in progress), March 2008.
 297
 298    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
 299               Requirements for Security", BCP 106, RFC 4086, June 2005.
 300
 301 7.2.  Informative References
 302
 303    [I-D.ietf-tls-rfc4366-bis]
 304               3rd, D., "Transport Layer Security (TLS) Extensions:
 305               Extension Definitions", draft-ietf-tls-rfc4366-bis-02
 306               (work in progress), February 2008.
 307
 308    [I-D.rescorla-tls-suiteb]
 309               Salter, M. and E. Rescorla, "Suite B Cipher Suites for
 310               TLS", draft-rescorla-tls-suiteb-02 (work in progress),
 311               April 2008.
 312
 313    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 314               Requirement Levels", BCP 14, RFC 2119, March 1997.
 315
 316    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 317               Security", RFC 4347, April 2006.
 318
 319
 320 Authors' Addresses
 321
 322    Eric Rescorla
 323    RTFM, Inc.
 324    2064 Edgewood Drive
 325    Palo Alto, CA  94303
 326    USA
 327
 328    Email:  ekr@rtfm.com
 329
 330
 331
 332
 333
 334
 335 Rescorla & Salter       Expires October 31, 2008                [Page 6]
 336 \f
 337 Internet-Draft             Extended TLS Random                April 2008
 338
 339
 340    Margaret Salter
 341    National Security Agency
 342    9800 Savage Rd.
 343    Fort Meade  20755-6709
 344    USA
 345
 346    Email:  msalter@restarea.ncsc.mil
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 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 October 31, 2008                [Page 7]
 392 \f
 393 Internet-Draft             Extended TLS Random                April 2008
 394
 395
 396 Full Copyright Statement
 397
 398    Copyright (C) The IETF Trust (2008).
 399
 400    This document is subject to the rights, licenses and restrictions
 401    contained in BCP 78, and except as set forth therein, the authors
 402    retain all their rights.
 403
 404    This document and the information contained herein are provided on an
 405    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 406    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 407    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 408    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 409    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 410    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 411
 412
 413 Intellectual Property
 414
 415    The IETF takes no position regarding the validity or scope of any
 416    Intellectual Property Rights or other rights that might be claimed to
 417    pertain to the implementation or use of the technology described in
 418    this document or the extent to which any license under such rights
 419    might or might not be available; nor does it represent that it has
 420    made any independent effort to identify any such rights.  Information
 421    on the procedures with respect to rights in RFC documents can be
 422    found in BCP 78 and BCP 79.
 423
 424    Copies of IPR disclosures made to the IETF Secretariat and any
 425    assurances of licenses to be made available, or the result of an
 426    attempt made to obtain a general license or permission for the use of
 427    such proprietary rights by implementers or users of this
 428    specification can be obtained from the IETF on-line IPR repository at
 429    http://www.ietf.org/ipr.
 430
 431    The IETF invites any interested party to bring to its attention any
 432    copyrights, patents or patent applications, or other proprietary
 433    rights that may cover technology that may be required to implement
 434    this standard.  Please address the information to the IETF at
 435    ietf-ipr@ietf.org.
 436
 437
 438 Acknowledgment
 439
 440    Funding for the RFC Editor function is provided by the IETF
 441    Administrative Support Activity (IASA).
 442
 443
 444
 445
 446
 447 Rescorla & Salter       Expires October 31, 2008                [Page 8]
 448 \f