idnits 2.17.1 draft-mglt-6lo-aes-implicit-iv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 17, 2015) is 3356 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: August 21, 2015 LMU Munich 6 February 17, 2015 8 Implicit IV for AES-CBC, AES-CTR, AES-CCM and AES-GCM 9 draft-mglt-6lo-aes-implicit-iv-01.txt 11 Abstract 13 IPsec ESP with AES-CBC, AES-CTR, AES-CCM or AES-GCM sends an IV in 14 each IP packet, which represents 8 or 16 additional bytes. 16 In some context, such as IoT, the cost of sending bytes over 17 computing these bytes is generally in favor of the computation. As a 18 result, it would be better to compute the IV on each party then to 19 send it. 21 The document describes how to the IV can be generated instead of 22 being sent. This document limits the IV generation for AES-CBC, AES- 23 CTR, AES-CCM and AES-GCM but can be used for additional cryptographic 24 mode and suites. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 21, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Implicit IV with AES CBC . . . . . . . . . . . . . . . . . . 3 64 5. Implicit IV with AES-CTR, AES-CCM and AES-GCM . . . . . . . . 4 65 6. Security Consideration . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in[RFC2119]. 77 2. Introduction 79 Using AES in one of the AES-CBC [RFC3602], AES-CTR [RFC3686] 80 encryption mode, or in one of the AES-CCM [RFC4309] and AES-GCM 81 [RFC4104] combined requires the specification of an IV for each ESP 82 packet. Currently this IV is sent in each ESP packet [RFC4303]. 84 IoT devices present new characteristics over traditional devices. 85 One of them is that the balance between extra computation and extra 86 byte sent over the wire is most of the time in favor of extra 87 computation. For such devices, embedding the IV in each packet 88 constitutes an extra cost over computing the IV of each associated 89 packet. 91 Depending on the the AES mode, the IV can be of different sizes and 92 have different properties. AES-CBC needs a 16 byte IV. This IV MUST 93 be chosen at random and MUST be unpredictable. In addition IV MUST 94 NOT be generated with low Hamming distance (like counter) for example 95 -- [RFC3602] Section 3. AES-CTR and AES-CCM need an 8 byte IV. This 96 IV MUST be unique ([RFC3686] Section 2.1). Finally, AES-GCM requires 97 8 byte IV, that must be unique for a given key -- [RFC4104] 98 Section 2. 100 This document defines how for each of the AES-CBC, AES-CTR, AES-CCM 101 and AES-GCM, the IV can be computed by each peer instead of being 102 included in the ESP packet. 104 This document limits its scope to AES as most of devices in the IoT 105 have hardware acceleration for AES, and use AES. However, the 106 description may be extended to additional crypto suites. 108 3. Terminology 110 - IoT: Internet of Things 112 - IV: Initialization Vector 114 4. Implicit IV with AES CBC 116 With AES-CBC, the IV is 16 bytes, random and unpredictable. In this 117 document, the binding between IV and ESP packet is performed using 118 the Sequence Number or the Extended Sequence Number. A clear text 119 payload is derived from the Sequence Number or the Extended Sequence 120 Number. In order to generate the IV randomly, AES is used as a 121 random permutation. A dedicated 16 byte key is used for each peer. 122 key_iv_initiator (resp. key_iv_responder) is used to derive the IV 123 emitted by the initiator (resp. the responder). 125 Keys key_iv_initiator and key_iv_responder MUST be agreed prior IPsec 126 packets are exchanged. When IKEv2 [RFC7296] is used these keys are 127 derived from the KEYMAT. key_iv_initiator is the first key generated, 128 followed by key_iv_responder. 130 Figure 1 (resp. Figure 2) defines a clear text payload derived from 131 a 4 byte Sequence Number (resp. a 8 byte Extended Sequence Number) 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 | Zero | 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Sequence Number | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1: Clear Text Payload for AES-CBC 145 Where, 147 - Sequence Number: the 4 byte Sequence Number carried in the ESP 148 packet. 150 - Zero: a 12 byte array with all bits set to zero. 152 0 1 2 3 153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Zero | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Extended | 159 | Sequence Number | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 2: Clear Text Payload for AES-CBC with Extended Sequence 163 Number 165 Where, 167 - Extended Sequence Number: the 8 byte Extended Sequence Number of 168 the Security Association. The 4 byte low order bytes are carried 169 in the ESP packet. 171 - Zero: a 8 byte array with all bits set to zero. 173 5. Implicit IV with AES-CTR, AES-CCM and AES-GCM 175 With AES-CTR, AES-CCM and AES-GCM, the 8 byte IV MUST NOT repeat. 176 The binding between a ESP packet and its IV is provided using the 177 Sequence Number or the Extended Sequence Number. Figure 3 (resp 178 Figure 4) represents the IV with a regular 4 byte Sequence Number 179 (resp. a 8 byte Extended Sequence Number). 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Zero | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Sequence Number | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 3: IV for AES-CTR, AES-CCM and AES-GCM with 4 byte Sequence 190 Number 192 Where, 193 - Sequence Number: the 4 byte Sequence Number carried in the ESP 194 packet. 196 - Zero: a 4 byte array with all bits set to zero. 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Extended | 202 | Sequence Number | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 4: IV for AES-CTR, AES-CCM and AES-GCM with 8 byte Extended 206 Sequence Number 208 Where, 210 - Extended Sequence Number: the 8 byte Extended Sequence Number of 211 the Security Association. The 4 byte low order bytes are carried 212 in the ESP packet. 214 6. Security Consideration 216 IV generation of the AES-CBC, AES-CTR, AES-CCM and AES-GCM have not 217 been explicitly defined. It has been left to the implementation as 218 long as certain security requirements are met. This document 219 provides an explicit and normative way to generate IVs. The 220 mechanism described in this document meets the IV security 221 requirements of AES-CBC, AES-CTR, AES-CCM and AES-GCM. 223 Randomness is provided by using AES. If this hypothesis is no longer 224 valid, than most probably, none of the AES mode will be considered 225 secure. 227 7. IANA Considerations 229 Each of the AES-CBC, AES-CTR, AES-CCM and AES-GCM crypto suite needs 230 to have their associated cryptographic suite with implicit IV. That 231 is to say the transforms below should be added to the Transform Type 232 1 - Encryption Algorithm Transform IDs: 234 - ENCR_AES_CBC_IMPLICIT_IV 236 - ENCR_AES_CTR_IMPLICIT_IV 238 - ENCR_AES-CCM_8_IMPLICIT_IV 240 - ENCR_AES-CCM_12_IMPLICIT_IV 241 - ENCR_AES-CCM_16_IMPLICIT_IV 243 - AES-GCM with 8 octet ICV and implicit IV 245 - AES-GCM with 12 octet ICV and implicit IV 247 - AES-GCM with 16 octet ICV and implicit IV 249 8. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 255 Algorithm and Its Use with IPsec", RFC 3602, September 256 2003. 258 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 259 Counter Mode With IPsec Encapsulating Security Payload 260 (ESP)", RFC 3686, January 2004. 262 [RFC4104] Pana, M., Reyes, A., Barba, A., Moron, D., and M. Brunner, 263 "Policy Core Extension Lightweight Directory Access 264 Protocol Schema (PCELS)", RFC 4104, June 2005. 266 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 267 4303, December 2005. 269 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 270 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 271 4309, December 2005. 273 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 274 Kivinen, "Internet Key Exchange Protocol Version 2 275 (IKEv2)", STD 79, RFC 7296, October 2014. 277 Appendix A. Document Change Log 279 [draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: changing 280 affiliation. 282 [draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: First version 283 published. 285 Authors' Addresses 287 Daniel Migault (editor) 288 Ericsson 289 8400 boulevard Decarie 290 Montreal, QC H4P 2N2 291 Canada 293 Email: mglt.ietf@gmail.com 295 Tobias Guggemos (editor) 296 LMU Munich 297 Am Osteroesch 9 298 87637 Seeg, Bavaria 299 Germany 301 Email: tobias.guggemos@gmail.com