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

   1
   2
   3
   4 Network Working Group                                        N. Modadugu
   5 Internet-Draft                                       Stanford University
   6 Expires: December 15, 2006                                   E. Rescorla
   7                                                        Network Resonance
   8                                                            June 13, 2006
   9
  10
  11             AES Counter Mode Cipher Suites for TLS and DTLS
  12                        draft-ietf-tls-ctr-01.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 December 15, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    This document describes the use of the Advanced Encryption Standard
  46    (AES) Counter Mode for use as a Transport Layer Security (TLS) and
  47    Datagram Transport Layer Security (DTLS) confidentiality mechanism.
  48
  49
  50
  51
  52
  53
  54
  55 Modadugu & Rescorla     Expires December 15, 2006               [Page 1]
  56 \f
  57 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63      1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
  64    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    3.  Encrypting Records with AES Counter Mode . . . . . . . . . . .  4
  66      3.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  67        3.1.1.  Encryption . . . . . . . . . . . . . . . . . . . . . .  4
  68        3.1.2.  Decryption . . . . . . . . . . . . . . . . . . . . . .  5
  69        3.1.3.  Counter Block Construction . . . . . . . . . . . . . .  5
  70      3.2.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  71      3.3.  Padding  . . . . . . . . . . . . . . . . . . . . . . . . .  7
  72      3.4.  Session Resumption . . . . . . . . . . . . . . . . . . . .  7
  73    4.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . .  7
  74    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  75      5.1.  Maximum Key Lifetime . . . . . . . . . . . . . . . . . . .  8
  76    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
  77    7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
  78    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
  79    Intellectual Property and Copyright Statements . . . . . . . . . . 10
  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 Modadugu & Rescorla     Expires December 15, 2006               [Page 2]
 112 \f
 113 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 114
 115
 116 1.  Introduction
 117
 118    Transport Layer Security [3] provides channel-oriented security for
 119    application layer protocols.  In TLS, cryptographic algorithms are
 120    specified in "Cipher Suites, which consist of a group of algorithms
 121    to be used together."
 122
 123    Cipher suites supported by TLS are divided into stream and block
 124    ciphers.  Counter mode ciphers behave like stream ciphers, but are
 125    constructed based on a block cipher primitive (that is, counter mode
 126    operation of a block cipher results in a stream cipher.)  This
 127    specification is limited to discussion of the operation of AES in
 128    counter mode (AES-CTR.)
 129
 130    Counter mode ciphers (CTR) offer a number of attractive features over
 131    other block cipher modes and stream ciphers such as RC4:
 132
 133    Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record
 134       compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are
 135       saved from not having to transmit an explicit IV, and another 1-16
 136       bytes are saved from the absence of the padding block.
 137
 138    Random Access: AES-CTR is capable of random access within the key
 139       stream.  For DTLS, this implies that records can be processed out
 140       of order without dependency on packet arrival order, and also
 141       without keystream buffering.
 142
 143    Parallelizable: As a consequence of AES-CTR supporting random access
 144       within the key stream, making the cipher amenable to parallelizing
 145       and pipelining in hardware.
 146
 147    Multiple mode support: AES-CTR support in TLS/DTLS allows for
 148       implementator to support both a stream (CTR) and block (CBC)
 149       cipher through the implementation of a single symmetric algorithm.
 150
 151 1.1.  Conventions Used In This Document
 152
 153    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 154    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 155    document are to be interpreted as described in [1].
 156
 157
 158 2.  Terminology
 159
 160    This document reuses some terminology introduced in [2] and [3].  The
 161    term 'counter block' has the same meaning as used in [2].  However,
 162    the term 'IV' in this document, holds the meaning defined in [3].
 163
 164
 165
 166
 167 Modadugu & Rescorla     Expires December 15, 2006               [Page 3]
 168 \f
 169 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 170
 171
 172 3.  Encrypting Records with AES Counter Mode
 173
 174    AES-CTR is functionally equivalent to a stream cipher; it generates a
 175    pseudo-random cipher stream that is XORed into the plaintext to form
 176    ciphertext.
 177
 178    The cipher stream is generated by applying the AES encrypt operation
 179    on a sequence of 128-bit counter blocks.  Counter blocks, in turn,
 180    are generated based on record sequence numbers (in the case of TLS),
 181    or a combination of record sequence and epoch numbers (in the case of
 182    DTLS.)
 183
 184    It should be noted that although the client and server use the same
 185    sequence number space, they use different write keys and counter
 186    blocks.
 187
 188    There is one important constraint on the use of counter mode ciphers:
 189    for a given key, a counter block value MUST never be used more than
 190    once.
 191
 192    This constraint is required because a given key and counter block
 193    value completely specify a portion of the cipher stream.  Hence, a
 194    particular counter block value when used (with a given key) to
 195    generate more than one ciphertext leaks information about the
 196    corresponding plaintexts.  For a detailed explanation, see Section 7
 197    of [2].
 198
 199    Given this constraint, the challenge then is in the design of the
 200    counter block.  We describe the construction of the counter block in
 201    the following sections.
 202
 203    TLS/DTLS records encrypted with AES-CTR mode use a
 204    CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]).
 205
 206 3.1.  TLS
 207
 208    AES counter mode requires the encryptor and decryptor to share a per-
 209    record unique counter block.  As previously stated, a given counter
 210    block MUST never be used more than once with the same key.  The
 211    following description of AES-CTR mode has been adapted from [2].
 212
 213 3.1.1.  Encryption
 214
 215    To encrypt a payload with AES-CTR, the encryptor sequentially
 216    partitions the plaintext (PT) into 128-bit blocks.  The final PT
 217    block MAY be less than 128-bits.  This partitioning is denoted as:
 218
 219    PT = PT[1] PT[2] ...  PT[n]
 220
 221
 222
 223 Modadugu & Rescorla     Expires December 15, 2006               [Page 4]
 224 \f
 225 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 226
 227
 228    In order to encrypt, each PT block is XORed with a block of the key
 229    stream to generate the ciphertext (CT.)  The keystream is generated
 230    via the AES encryption of each counter block value, with each
 231    encryption operation producing 128-bits of key stream.
 232
 233    The encryption operation is performed as follows:
 234
 235
 236          FOR i := 1 to n-1 DO
 237            CT[i] := PT[i] XOR AES(CtrBlk)
 238            CtrBlk := CtrBlk + 1
 239          END
 240          CT[n] := PT[n] XOR TRUNC(AES(CtrBlk))
 241
 242    The AES() function performs AES encryption with the fresh key.
 243
 244    The TRUNC() function truncates the output of the AES encrypt
 245    operation to the same length as the final plaintext block, returning
 246    the leftmost bits.
 247
 248 3.1.2.  Decryption
 249
 250    Decryption is similar to encryption.  The decryption of n ciphertext
 251    blocks is performed as follows:
 252
 253
 254          FOR i := 1 to n-1 DO
 255            PT[i] := CT[i] XOR AES(CtrBlk)
 256            CtrBlk := CtrBlk + 1
 257          END
 258          PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))
 259
 260    The AES() and TRUNC() operate identically as in the case of
 261    encryption.
 262
 263 3.1.3.  Counter Block Construction
 264
 265    To construct the counter block, the leftmost 48-bits of the counter
 266    block are set to the rightmost 48-bits of the client_write_IV (for
 267    the half-duplex stream originated by the client) or the rightmost 48-
 268    bits of the server_write_IV (for the half-duplex stream originated by
 269    the server.)  The following 64-bits of the counter block are set to
 270    record sequence number, and the remaining 16-bits function as the
 271    block counter.  The block counter is a 16-bit unsigned integer in
 272    network byte order (i.e. big-endien).  The block counter is initially
 273    set to one, and is incremented by one to generate subsequent counter
 274    blocks, each resulting in another 128-bits of key stream.
 275
 276
 277
 278
 279 Modadugu & Rescorla     Expires December 15, 2006               [Page 5]
 280 \f
 281 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 282
 283
 284    The structure of the counter block is depicted below:
 285
 286           struct {
 287              case client:
 288                  uint48 client_write_IV;  // low order 48-bits
 289              case server:
 290                  uint48 server_write_IV;  // low order 48-bits
 291              uint64 seq_num;
 292              uint16 blk_ctr;
 293           } CtrBlk;
 294
 295    The seq_num and blk_ctr fields of the counter block are initialized
 296    for each record processed, while the IV is initialized immediately
 297    after a key calculation is made (key calculations are made whenever a
 298    TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num
 299    is set to the sequence number of the record, and blk_ctr is
 300    initialized to 1.
 301
 302    Note that the block counter does not overflow since the maximum size
 303    of input to the record payload protection layer in TLS or DTLS
 304    (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr
 305    allow the generation of 2^20 octets (2^16 AES blocks) of keying
 306    material per record.
 307
 308    Note that for TLS, no part of the counter block need be transmitted,
 309    since the client_write_IV and server_write_IV are derived during the
 310    key calculation phase, and the record sequence number is implicit.
 311
 312 3.2.  DTLS
 313
 314    The operation of AES-CTR in DTLS is the same as in TLS, with the only
 315    difference being the inclusion of the epoch in the counter block.
 316    The counter block is constructed as follows for DTLS:
 317
 318        struct {
 319           case client:
 320               uint48 client_write_IV;  // low order 48-bits
 321           case server:
 322               uint48 server_write_IV;  // low order 48-bits
 323           uint16 epoch;
 324           uint48 seq_num;
 325           uint16 blk_ctr;
 326        } CtrBlk;
 327
 328    For decryption, the epoch and seq_num fields are initialized based on
 329    the corresponding values in a received record.
 330
 331
 332
 333
 334
 335 Modadugu & Rescorla     Expires December 15, 2006               [Page 6]
 336 \f
 337 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 338
 339
 340 3.3.  Padding
 341
 342    Stream ciphers in TLS and DTLS do not require plaintext padding.
 343
 344 3.4.  Session Resumption
 345
 346    TLS supports session resumption via caching of session ID's and
 347    connection parameters on both client and server.  While resumed
 348    sessions use the same master secret that was originally negotiated, a
 349    resumed session uses new keys that are derived, in part, using fresh
 350    client_random and server_random parameters.  As a result resumed
 351    sessions do not use the same encryption keys or IV's as the original
 352    session.
 353
 354
 355 4.  Design Rationale
 356
 357    An alternate design for the construction of the counter block would
 358    be the use of an explicit 'record tag' (as a substitute for the
 359    implicit record sequence number) that could potentially be generated
 360    via an LFSR.  Such a design, however, suffers a major drawback when
 361    used in the TLS or DTLS protocol, without offering any significant
 362    benefit: in both TLS and DTLS inclusion of such a tag would incur a
 363    bandwidth cost.
 364
 365
 366 5.  Security Considerations
 367
 368    The security considerations for the use of AES-CTR in TLS/DTLS are
 369    specified below.  The below text is based heavily on that for AES-CTR
 370    in IPsec [2].
 371
 372    o  Counter blocks must not be used more than once with a given key.
 373       Doing so allows a passive attacker to determine the XOR of the
 374       affected plain text blocks.  Extracting two plaintexts from their
 375       XOR is a relatively straightforward operation.  Because the
 376       counter block is derived from the per-record sequence, this means
 377       that sequence numbers MUST never be re-used with different data.
 378       Note, however, that retransmitting the same record in DTLS is
 379       safe.
 380    o  AES-CTR can be used in pre-shared key mode, since session keys and
 381       not pre-shared keys are used for ciphering.  Also, since separate
 382       read and write keys are generated, counter blocks generated by
 383       client and server can safely overlap.
 384    o  As with other stream ciphers, data forgery is trivial if no
 385       message integrity mechanism is employed.  This threat is of no
 386       concern in TLS/DTLS since all ciphersuites that support encryption
 387       also employ message integrity.
 388
 389
 390
 391 Modadugu & Rescorla     Expires December 15, 2006               [Page 7]
 392 \f
 393 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 394
 395
 396 5.1.  Maximum Key Lifetime
 397
 398    TLS/DTLS sessions employing AES-CTR MUST be renegotiated before
 399    sequence numbers repeat.  In the case of TLS, this implies a maximum
 400    of 2^64 records per session, while for DTLS the maximum is 2^48 (with
 401    the remaining bits reserved for epoch.)
 402
 403
 404 6.  IANA Considerations
 405
 406    IANA has assigned the following values for AES-CTR mode ciphers:
 407
 408    CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 409    CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 410    CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 411    CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 412    CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 413    CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
 414
 415    CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 416    CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 417    CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 418    CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 419    CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 420    CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
 421
 422 7.  Normative References
 423
 424    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 425         Levels", BCP 14, RFC 2119, March 1997.
 426
 427    [2]  Housley, R., "Using Advanced Encryption Standard (AES) Counter
 428         Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
 429         January 2004.
 430
 431    [3]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
 432         Protocol Version 1.1", RFC 4346, April 2006.
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Modadugu & Rescorla     Expires December 15, 2006               [Page 8]
 448 \f
 449 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 450
 451
 452 Authors' Addresses
 453
 454    Nagendra Modadugu
 455    Stanford University
 456    353 Serra Mall
 457    Stanford, CA  94305
 458    USA
 459
 460    Email: nagendra@cs.stanford.edu
 461
 462
 463    Eric Rescorla
 464    Network Resonance
 465    2483 E. Bayshore Rd., #212
 466    Palo Alto, CA  94303
 467    USA
 468
 469    Email: ekr@networkresonance.com
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Modadugu & Rescorla     Expires December 15, 2006               [Page 9]
 504 \f
 505 Internet-Draft              TLS/DTLS AES-CTR                   June 2006
 506
 507
 508 Intellectual Property Statement
 509
 510    The IETF takes no position regarding the validity or scope of any
 511    Intellectual Property Rights or other rights that might be claimed to
 512    pertain to the implementation or use of the technology described in
 513    this document or the extent to which any license under such rights
 514    might or might not be available; nor does it represent that it has
 515    made any independent effort to identify any such rights.  Information
 516    on the procedures with respect to rights in RFC documents can be
 517    found in BCP 78 and BCP 79.
 518
 519    Copies of IPR disclosures made to the IETF Secretariat and any
 520    assurances of licenses to be made available, or the result of an
 521    attempt made to obtain a general license or permission for the use of
 522    such proprietary rights by implementers or users of this
 523    specification can be obtained from the IETF on-line IPR repository at
 524    http://www.ietf.org/ipr.
 525
 526    The IETF invites any interested party to bring to its attention any
 527    copyrights, patents or patent applications, or other proprietary
 528    rights that may cover technology that may be required to implement
 529    this standard.  Please address the information to the IETF at
 530    ietf-ipr@ietf.org.
 531
 532
 533 Disclaimer of Validity
 534
 535    This document and the information contained herein are provided on an
 536    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 537    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 538    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 539    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 540    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 541    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 542
 543
 544 Copyright Statement
 545
 546    Copyright (C) The Internet Society (2006).  This document is subject
 547    to the rights, licenses and restrictions contained in BCP 78, and
 548    except as set forth therein, the authors retain all their rights.
 549
 550
 551 Acknowledgment
 552
 553    Funding for the RFC Editor function is currently provided by the
 554    Internet Society.
 555
 556
 557
 558
 559 Modadugu & Rescorla     Expires December 15, 2006              [Page 10]
 560 \f
 561