idnits 2.17.1 draft-ietf-tls-ctr-00.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 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. ** 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 (February 26, 2006) is 6605 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) ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. '3') 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: August 30, 2006 E. Rescorla 5 Network Resonance 6 February 26, 2006 8 AES Counter Mode Cipher Suites for TLS and DTLS 9 draft-ietf-tls-ctr-00.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 August 30, 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. AES Counter Mode . . . . . . . . . . . . . . . . . . . 4 54 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 6 57 4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Introduction 67 Transport Layer Security [3] provides channel-oriented security for 68 application layer protocols. In TLS, cryptographic algorithms are 69 specified in "Cipher Suites, which consist of a group of algorithms 70 to be used together." 72 Cipher suites supported by TLS are divided into stream and block 73 ciphers. Counter mode ciphers behave like stream ciphers, but are 74 constructed based on a block cipher primitive (that is, counter mode 75 operation of a block cipher results in a stream cipher.) This 76 specification is limited to discussion of the operation of AES in 77 counter mode (AES-CTR.) 79 Counter mode ciphers (CTR) offer a number of attractive features over 80 other block cipher modes and stream ciphers such as RC4: 82 Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record 83 compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are 84 saved from not having to transmit an explicit IV, and another 1-16 85 bytes are saved from the absence of the padding block. 87 Random Access: AES-CTR is capable of random access within the key 88 stream. For DTLS, this implies that records can be processed out 89 of order without dependency on packet arrival order, and also 90 without keystream buffering. 92 Parallelizable: As a consequence of AES-CTR supporting random access 93 within the key stream, the cipher can be easily parallelized. 95 Multiple mode support: AES-CTR support in TLS/DTLS allows for 96 implementator to support both a stream (CTR) and block (CBC) 97 cipher through the implemention of a single symmetric algorithm. 99 1.1. Conventions Used In This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [1]. 105 2. Terminology 107 This document reuses some terminology introduced in [2] and [3]. The 108 term 'counter block' has the same meaning as used in RFC3686, 109 however, the term 'IV', in this document, holds the meaning defined 110 in [3]. 112 3. Encrypting Records with AES Counter Mode 114 The use of AES-CTR in TLS/DTLS turns out to be fairly 115 straightforward, with the additional benefit that the method of 116 operation in TLS/DTLS mimics, to a large extent, that in IPsec. The 117 primary constraint on the use of counter mode ciphers is that for a 118 given key, a counter block value MUST never be used more than once 119 (see Section 7 of [2] for a detailed explanation.) In TLS/DTLS 120 ensuring that counter block values never repeat during a given 121 session is straightforward as explained in the following sections. 123 SSL/TLS records encrypted with AES-CTR mode use a 124 CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]). 126 3.1. TLS 128 The cipher stream generated by AES-CTR is much like the cipher stream 129 generated by stream ciphers like RC4. For reasons described in 130 Section 7 of [2], a counter block value MUST never be used more than 131 once with a given key. This is achieved by having part of the per- 132 record IV determined by the record sequence number. Although the 133 client and server use the same sequence number space, they use 134 different keys and IVs. 136 3.1.1. AES Counter Mode 138 AES counter mode requires the encryptor and decryptor to share a per- 139 record unique counter block. A given counter block MUST never be 140 used more than once with the same key. For a more in-depth 141 discussion of AES-CTR operation, refer to Section 2.1 of [2]. The 142 following description of AES-CTR mode has been adapted from [2]. 144 To encrypt a payload with AES-CTR, the encryptor partitions the 145 plaintext, PT, into 128-bit blocks. The final block MAY be less than 146 128 bits. 148 PT = PT[1] PT[2] ... PT[n] 150 Each PT block is XORed with a block of the key stream to generate the 151 ciphertext, CT. The AES encryption of each counter block results in 152 128 bits of key stream. 154 To construct the counter block, the most significant 48 bits of the 155 counter block are set to the 48 low order bits of the client_write_IV 156 (for the half-duplex stream originated by the client) or the 48 low 157 order bits of the server_write_IV (for the half-duplex stream 158 originated by the server.) The following 64 bits of the counter 159 block are set to record sequence number, and the remaining 16 bits 160 function as the block counter. The least significant bit of the 161 counter block is initially set to one. This counter value is 162 incremented by one to generate subsequent counter blocks, each 163 resulting in another 128 bits of key stream. 165 struct { 166 case client: 167 uint48 client_write_IV; // low order 48-bits 168 case server: 169 uint48 server_write_IV; // low order 48-bits 170 uint64 seq_num; 171 uint16 blk_ctr; 172 } CtrBlk; 174 The seq_num and blk_ctr fields of the counter block are initialized 175 for each record processed, while the IV is initialized immediately 176 after a key calculation is made (key calculations are made whenver a 177 TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num 178 is set to the sequence number of the record, and blk_ctr is 179 initialized to 1. 181 Note that the block counter does not overflow since the maximum TLS/ 182 DTLS record size is 14 KB and 16 bits of blk_ctr allow the generation 183 of 1MB of keying material per record. 185 The encryption of n plaintext blocks can be summarized as: 187 FOR i := 1 to n-1 DO 188 CT[i] := PT[i] XOR AES(CtrBlk) 189 CtrBlk := CtrBlk + 1 190 END 191 CT[n] := PT[n] XOR TRUNC(AES(CtrBlk)) 193 The AES() function performs AES encryption with the fresh key. 195 The TRUNC() function truncates the output of the AES encrypt 196 operation to the same length as the final plaintext block, returning 197 the most significant bits. 199 Decryption is similar. The decryption of n ciphertext blocks can be 200 summarized as: 202 FOR i := 1 to n-1 DO 203 PT[i] := CT[i] XOR AES(CtrBlk) 204 CtrBlk := CtrBlk + 1 205 END 206 PT[n] := CT[n] XOR TRUNC(AES(CtrBlk)) 208 For TLS, no part of the counter block need be transmitted, since the 209 client_write_IV and server_write_IV are derived during the key 210 calculation phase, and the record sequence number is implicit. 212 3.2. DTLS 214 The operation of AES-CTR in DTLS is the same as in TLS, with the only 215 difference being the inclusion of the epoch in the counter block. 216 The counter block is constructed as follows for DTLS: 218 struct { 219 case client: 220 uint48 client_write_IV; // low order 48-bits 221 case server: 222 uint48 server_write_IV; // low order 48-bits 223 uint16 epoch; 224 uint48 seq_num; 225 uint16 blk_ctr; 226 } CtrBlk; 228 The epoch and record sequence number used for generating the counter 229 block are extracted from the received record. 231 3.3. Padding 233 Stream ciphers in TLS and DTLS do not require plaintext padding. 235 3.4. Session Resumption 237 TLS supports session resumption via caching of session ID's and 238 connection parameters on both client and server. While resumed 239 sessions use the same master secret that was originally negotiated, a 240 resumed session uses new keys that are derived, in part, using fresh 241 client_random and server_random parameters. As a result resumed 242 sessions do not use the same encryption keys or IVs as the original 243 session. 245 4. Design Rationale 247 An alternate design for the construction of the counter block would 248 be the use of an explicit 'record tag' (as a substitute for the 249 implicit record sequence number) that could potentially be generated 250 via an LFSR. Such a design, however, suffers two major drawbacks 251 when used in the TLS or DTLS protocol, without offering any 252 significant benefit: (1) in both TLS and DTLS inclusion of such a tag 253 would incur a bandwidth cost, (2) all TLS and DTLS associations have 254 per-record sequence numbers which can be used to ensure counter 255 uniqueness. 257 5. Security Considerations 259 See Section 7. of [2]. 261 5.1. Maximum Key Lifetime 263 TLS/DTLS sessions employing AES-CTR MUST be renegotiated before 264 sequence numbers repeat. In the case of TLS, this implies a maximum 265 of 2^64 records per session, while for DTLS the maximum is 2^48 (with 266 the remaining bits reserved for epoch.) 268 6. IANA Considerations 270 IANA has assigned the following values for AES-CTR mode ciphers: 272 CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 273 CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 274 CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 275 CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 276 CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 277 CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX }; 279 CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 280 CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 281 CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 282 CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 283 CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 284 CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX }; 286 7. Normative References 288 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 289 Levels", BCP 14, RFC 2119, March 1997. 291 [2] Housley, R., "Using Advanced Encryption Standard (AES) Counter 292 Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, 293 January 2004. 295 [3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 296 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 298 Authors' Addresses 300 Nagendra Modadugu 301 Stanford University 302 353 Serra Mall 303 Stanford, CA 94305 304 USA 306 Email: nagendra@cs.stanford.edu 308 Eric Rescorla 309 Network Resonance 310 2483 E. Bayshore Rd., #212 311 Palo Alto, CA 94303 312 USA 314 Email: ekr@networkresonance.com 316 Intellectual Property Statement 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at 338 ietf-ipr@ietf.org. 340 Disclaimer of Validity 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 345 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 346 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 347 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 350 Copyright Statement 352 Copyright (C) The Internet Society (2006). This document is subject 353 to the rights, licenses and restrictions contained in BCP 78, and 354 except as set forth therein, the authors retain all their rights. 356 Acknowledgment 358 Funding for the RFC Editor function is currently provided by the 359 Internet Society.