idnits 2.17.1 draft-ietf-tls-ctr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 379. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2006) is 6520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4346 (ref. '3') (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Modadugu 3 Internet-Draft Stanford University 4 Expires: December 15, 2006 E. Rescorla 5 Network Resonance 6 June 13, 2006 8 AES Counter Mode Cipher Suites for TLS and DTLS 9 draft-ietf-tls-ctr-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the use of the Advanced Encryption Standard 43 (AES) Counter Mode for use as a Transport Layer Security (TLS) and 44 Datagram Transport Layer Security (DTLS) confidentiality mechanism. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Encrypting Records with AES Counter Mode . . . . . . . . . . . 4 52 3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1.2. Decryption . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.3. Counter Block Construction . . . . . . . . . . . . . . 5 56 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 7 59 4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5.1. Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Introduction 69 Transport Layer Security [3] provides channel-oriented security for 70 application layer protocols. In TLS, cryptographic algorithms are 71 specified in "Cipher Suites, which consist of a group of algorithms 72 to be used together." 74 Cipher suites supported by TLS are divided into stream and block 75 ciphers. Counter mode ciphers behave like stream ciphers, but are 76 constructed based on a block cipher primitive (that is, counter mode 77 operation of a block cipher results in a stream cipher.) This 78 specification is limited to discussion of the operation of AES in 79 counter mode (AES-CTR.) 81 Counter mode ciphers (CTR) offer a number of attractive features over 82 other block cipher modes and stream ciphers such as RC4: 84 Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record 85 compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are 86 saved from not having to transmit an explicit IV, and another 1-16 87 bytes are saved from the absence of the padding block. 89 Random Access: AES-CTR is capable of random access within the key 90 stream. For DTLS, this implies that records can be processed out 91 of order without dependency on packet arrival order, and also 92 without keystream buffering. 94 Parallelizable: As a consequence of AES-CTR supporting random access 95 within the key stream, making the cipher amenable to parallelizing 96 and pipelining in hardware. 98 Multiple mode support: AES-CTR support in TLS/DTLS allows for 99 implementator to support both a stream (CTR) and block (CBC) 100 cipher through the implementation of a single symmetric algorithm. 102 1.1. Conventions Used In This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [1]. 108 2. Terminology 110 This document reuses some terminology introduced in [2] and [3]. The 111 term 'counter block' has the same meaning as used in [2]. However, 112 the term 'IV' in this document, holds the meaning defined in [3]. 114 3. Encrypting Records with AES Counter Mode 116 AES-CTR is functionally equivalent to a stream cipher; it generates a 117 pseudo-random cipher stream that is XORed into the plaintext to form 118 ciphertext. 120 The cipher stream is generated by applying the AES encrypt operation 121 on a sequence of 128-bit counter blocks. Counter blocks, in turn, 122 are generated based on record sequence numbers (in the case of TLS), 123 or a combination of record sequence and epoch numbers (in the case of 124 DTLS.) 126 It should be noted that although the client and server use the same 127 sequence number space, they use different write keys and counter 128 blocks. 130 There is one important constraint on the use of counter mode ciphers: 131 for a given key, a counter block value MUST never be used more than 132 once. 134 This constraint is required because a given key and counter block 135 value completely specify a portion of the cipher stream. Hence, a 136 particular counter block value when used (with a given key) to 137 generate more than one ciphertext leaks information about the 138 corresponding plaintexts. For a detailed explanation, see Section 7 139 of [2]. 141 Given this constraint, the challenge then is in the design of the 142 counter block. We describe the construction of the counter block in 143 the following sections. 145 TLS/DTLS records encrypted with AES-CTR mode use a 146 CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]). 148 3.1. TLS 150 AES counter mode requires the encryptor and decryptor to share a per- 151 record unique counter block. As previously stated, a given counter 152 block MUST never be used more than once with the same key. The 153 following description of AES-CTR mode has been adapted from [2]. 155 3.1.1. Encryption 157 To encrypt a payload with AES-CTR, the encryptor sequentially 158 partitions the plaintext (PT) into 128-bit blocks. The final PT 159 block MAY be less than 128-bits. This partitioning is denoted as: 161 PT = PT[1] PT[2] ... PT[n] 162 In order to encrypt, each PT block is XORed with a block of the key 163 stream to generate the ciphertext (CT.) The keystream is generated 164 via the AES encryption of each counter block value, with each 165 encryption operation producing 128-bits of key stream. 167 The encryption operation is performed as follows: 169 FOR i := 1 to n-1 DO 170 CT[i] := PT[i] XOR AES(CtrBlk) 171 CtrBlk := CtrBlk + 1 172 END 173 CT[n] := PT[n] XOR TRUNC(AES(CtrBlk)) 175 The AES() function performs AES encryption with the fresh key. 177 The TRUNC() function truncates the output of the AES encrypt 178 operation to the same length as the final plaintext block, returning 179 the leftmost bits. 181 3.1.2. Decryption 183 Decryption is similar to encryption. The decryption of n ciphertext 184 blocks is performed as follows: 186 FOR i := 1 to n-1 DO 187 PT[i] := CT[i] XOR AES(CtrBlk) 188 CtrBlk := CtrBlk + 1 189 END 190 PT[n] := CT[n] XOR TRUNC(AES(CtrBlk)) 192 The AES() and TRUNC() operate identically as in the case of 193 encryption. 195 3.1.3. Counter Block Construction 197 To construct the counter block, the leftmost 48-bits of the counter 198 block are set to the rightmost 48-bits of the client_write_IV (for 199 the half-duplex stream originated by the client) or the rightmost 48- 200 bits of the server_write_IV (for the half-duplex stream originated by 201 the server.) The following 64-bits of the counter block are set to 202 record sequence number, and the remaining 16-bits function as the 203 block counter. The block counter is a 16-bit unsigned integer in 204 network byte order (i.e. big-endien). The block counter is initially 205 set to one, and is incremented by one to generate subsequent counter 206 blocks, each resulting in another 128-bits of key stream. 208 The structure of the counter block is depicted below: 210 struct { 211 case client: 212 uint48 client_write_IV; // low order 48-bits 213 case server: 214 uint48 server_write_IV; // low order 48-bits 215 uint64 seq_num; 216 uint16 blk_ctr; 217 } CtrBlk; 219 The seq_num and blk_ctr fields of the counter block are initialized 220 for each record processed, while the IV is initialized immediately 221 after a key calculation is made (key calculations are made whenever a 222 TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num 223 is set to the sequence number of the record, and blk_ctr is 224 initialized to 1. 226 Note that the block counter does not overflow since the maximum size 227 of input to the record payload protection layer in TLS or DTLS 228 (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr 229 allow the generation of 2^20 octets (2^16 AES blocks) of keying 230 material per record. 232 Note that for TLS, no part of the counter block need be transmitted, 233 since the client_write_IV and server_write_IV are derived during the 234 key calculation phase, and the record sequence number is implicit. 236 3.2. DTLS 238 The operation of AES-CTR in DTLS is the same as in TLS, with the only 239 difference being the inclusion of the epoch in the counter block. 240 The counter block is constructed as follows for DTLS: 242 struct { 243 case client: 244 uint48 client_write_IV; // low order 48-bits 245 case server: 246 uint48 server_write_IV; // low order 48-bits 247 uint16 epoch; 248 uint48 seq_num; 249 uint16 blk_ctr; 250 } CtrBlk; 252 For decryption, the epoch and seq_num fields are initialized based on 253 the corresponding values in a received record. 255 3.3. Padding 257 Stream ciphers in TLS and DTLS do not require plaintext padding. 259 3.4. Session Resumption 261 TLS supports session resumption via caching of session ID's and 262 connection parameters on both client and server. While resumed 263 sessions use the same master secret that was originally negotiated, a 264 resumed session uses new keys that are derived, in part, using fresh 265 client_random and server_random parameters. As a result resumed 266 sessions do not use the same encryption keys or IV's as the original 267 session. 269 4. Design Rationale 271 An alternate design for the construction of the counter block would 272 be the use of an explicit 'record tag' (as a substitute for the 273 implicit record sequence number) that could potentially be generated 274 via an LFSR. Such a design, however, suffers a major drawback when 275 used in the TLS or DTLS protocol, without offering any significant 276 benefit: in both TLS and DTLS inclusion of such a tag would incur a 277 bandwidth cost. 279 5. Security Considerations 281 The security considerations for the use of AES-CTR in TLS/DTLS are 282 specified below. The below text is based heavily on that for AES-CTR 283 in IPsec [2]. 285 o Counter blocks must not be used more than once with a given key. 286 Doing so allows a passive attacker to determine the XOR of the 287 affected plain text blocks. Extracting two plaintexts from their 288 XOR is a relatively straightforward operation. Because the 289 counter block is derived from the per-record sequence, this means 290 that sequence numbers MUST never be re-used with different data. 291 Note, however, that retransmitting the same record in DTLS is 292 safe. 293 o AES-CTR can be used in pre-shared key mode, since session keys and 294 not pre-shared keys are used for ciphering. Also, since separate 295 read and write keys are generated, counter blocks generated by 296 client and server can safely overlap. 297 o As with other stream ciphers, data forgery is trivial if no 298 message integrity mechanism is employed. This threat is of no 299 concern in TLS/DTLS since all ciphersuites that support encryption 300 also employ message integrity. 302 5.1. Maximum Key Lifetime 304 TLS/DTLS sessions employing AES-CTR MUST be renegotiated before 305 sequence numbers repeat. In the case of TLS, this implies a maximum 306 of 2^64 records per session, while for DTLS the maximum is 2^48 (with 307 the remaining bits reserved for epoch.) 309 6. IANA Considerations 311 IANA has assigned the following values for AES-CTR mode ciphers: 313 CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 314 CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 315 CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 316 CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 317 CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 318 CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 320 CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 321 CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 322 CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 323 CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 324 CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 325 CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 327 7. Normative References 329 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 330 Levels", BCP 14, RFC 2119, March 1997. 332 [2] Housley, R., "Using Advanced Encryption Standard (AES) Counter 333 Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, 334 January 2004. 336 [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 337 Protocol Version 1.1", RFC 4346, April 2006. 339 Authors' Addresses 341 Nagendra Modadugu 342 Stanford University 343 353 Serra Mall 344 Stanford, CA 94305 345 USA 347 Email: nagendra@cs.stanford.edu 349 Eric Rescorla 350 Network Resonance 351 2483 E. Bayshore Rd., #212 352 Palo Alto, CA 94303 353 USA 355 Email: ekr@networkresonance.com 357 Intellectual Property Statement 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. 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. 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. 381 Disclaimer of Validity 383 This document and the information contained herein are provided on an 384 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 385 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 386 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 387 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 388 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 389 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 391 Copyright Statement 393 Copyright (C) The Internet Society (2006). This document is subject 394 to the rights, licenses and restrictions contained in BCP 78, and 395 except as set forth therein, the authors retain all their rights. 397 Acknowledgment 399 Funding for the RFC Editor function is currently provided by the 400 Internet Society.