idnits 2.17.1 draft-mglt-ipsecme-diet-esp-iv-generation-00.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 (July 2, 2014) is 3578 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) -- Looks like a reference, but probably isn't: '1' on line 252 == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-00 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: January 3, 2015 Orange / LMU Munich 6 July 2, 2014 8 Diet-ESP: Generating compressed IV and SN 9 draft-mglt-ipsecme-diet-esp-iv-generation-00.txt 11 Abstract 13 Diet-ESP describes how to compress the various ESP fields, thanks to 14 the Diet-ESP Context. This document describes how the IV fields that 15 belong to the encrypted payload can be compressed. 17 The document describes the extensions of the the Diet-ESP Context as 18 well as the compression protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 3, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Diet-ESP context extension . . . . . . . . . . . . . . . . . 4 58 5. Pseudo Random Function . . . . . . . . . . . . . . . . . . . 4 59 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 5 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 10.2. Informational References . . . . . . . . . . . . . . . . 6 66 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Requirements notation 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in[RFC2119]. 76 2. Introduction 78 Diet-ESP [I-D.mglt-ipsecme-diet-esp] describes how to compress ESP 79 fields. Fields are compressed according to a Diet-ESP Context. 80 Diet-ESP has been described as a specific ROHC [RFC5795] framework 81 that has no IR, IR-DYN nor any feed back ROHC message. It works in 82 the Unidirectional mode of operation (U mode), and all necessary 83 parameters are transmitted via the Diet-ESP Context that is 84 negotiated between the two peers. As a result Diet-ESP defines a 85 very specific and simplified ROHC framework which makes possible to 86 implement Diet-ESP without implementing the whole ROHC. 88 In fact, Diet-ESP avoids ROHC complexity as a lot of parameters have 89 already been negotiated with IKEv2 [RFC5996]. 91 The Initialization Vector (IV) is defined as a input for AES 92 encryption and decryption. In order to provide the appropriated IV 93 value AES-CBC [RFC3602] and AES-CTR [RFC3686] sends the IV in each IP 94 packet as shown in figure Figure 1. In fact the output of AES-CTR 95 and AES-CBC outputs a payload where the encrypted data is appended to 96 the IV. 98 The IV MUST have to properties 1) they MUST be unpredictable by 99 someone observing the network, then 2) the IV MUST be unique. The 100 size of the IV differs depending on the encryption algorithm. AES- 101 CTR has an 8 byte IV and AES-CBC a 16 byte IV. 103 This document defines a way to avoid sending the IV in each packet. 104 Instead peers agree on a suite of pseudo random bytes. This makes 105 the IV predictable by both peers only, and random to the rest of the 106 world. As the IV can be derived by both peers, it may be removed 107 completely from each IP packet. Another way is to only provide the 108 LSB of the generated IV so receiver can better identify the 109 appropriated IV used for decryption. 111 Note that the ICV of standard ESP [RFC4303] and Diet-ESP ICV includes 112 the whole IV. As a result, the IV MUST be restored prior to the ICV 113 check. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 118 | Security Parameters Index (SPI) | ^ 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 120 | Sequence Number | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 122 | | |Int. 123 ~ Initialization Vector (variable) ~ |Cov- 124 | | |ered 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 126 | | | 127 ~ Encrypted Payload (variable) ~ | 128 | | v 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 130 | | 131 ~ Authentication Data (variable) ~ 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1: The IV in the ESP payload. 137 Section 4 describes the new parameters for the Diet-ESP Context. 138 Section 5 describes how the Pseudo Random Function is derived, and 139 Section 6 describes the protocol. 141 3. Terminology 143 - IoT: Internet of Things 145 - IV: Initialization Vector 146 - ICV: Integrity Check Value 148 - PRF: Pseudo Random Function 150 4. Diet-ESP context extension 152 To enable the compression of the IV, the Diet-ESP context defined in 153 [I-D.mglt-ipsecme-diet-esp] is extended with to values: 155 IV_COMPRESSION: 156 Defines if the IV is generated and compresses. 158 IV_PRFT (optional): 159 Defines the Pseudo Random Function Transform used for the Pseudo 160 Random Function. Available IDs are defined in [1] 161 Section Transform Type 2 - Pseudo random Function Transform IDs. 162 Section 2.13 [RFC5996] defines how the PRF is derived. By default 163 PRF_AES_128_CBC is the Pseudo Random Function Transform 164 considered. 166 IV_LSB: 167 Defines the number of Least Significant Bytes of the IV carried by 168 the payload. 170 5. Pseudo Random Function 172 The Pseudo Random Function (PRF) is defined from the Pseudo Random 173 Function Transform in Section 2.13 [RFC5996]. Unless specified 174 otherwise PRF_AES128_XCBC [RFC4434] is the default Pseudo Random 175 Function Transform. 177 The PRF "prf+" described in Section 2.13 [RFC5996] takes two 178 arguments designated as K and S. In this document K is the 179 encryption key and S is the authentication key appended to the string 180 "IV random generation". The string results in non null S value even 181 if no integrity algorithms are negotiated. 183 6. Protocol Description 185 IV generation and compression is performed only and only if 186 IV_COMPRESSION is set. Otherwise, the IV is embedded into the packet 187 and sent on the wire as described in [RFC4303]. 189 When IV_COMPRESSION is set, the PRD is defined as described in 190 Section 5. On the sending part, the ICV or Diet-ESP ICV is computed, 191 the IV is compressed to its LSB, before it is sent on the wire. On 192 te receiver part, the IV is decompress prior to the ICV check, then 193 decryption is performed with the decompressed IV. 195 7. IANA Considerations 197 There are no IANA consideration for this document. 199 8. Security Considerations 201 9. Acknowledgment 203 The current draft represents the work of Tobias Guggemos while his 204 internship at Orange [GUGG14] . 206 Diet-ESP is a joint work between Orange and Ludwig-Maximilians- 207 Universitaet Munich. We thank Daniel Palomares and Carsten Bormann 208 for their useful remarks, comments and guidance. 210 10. References 212 10.1. Normative References 214 [I-D.mglt-ipsecme-diet-esp] 215 Migault, D., Guggemos, T., and D. Palomares, "Diet-ESP: a 216 flexible and compressed format for IPsec/ESP", draft-mglt- 217 ipsecme-diet-esp-00 (work in progress), March 2014. 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 223 Algorithm and Its Use with IPsec", RFC 3602, September 224 2003. 226 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 227 Counter Mode With IPsec Encapsulating Security Payload 228 (ESP)", RFC 3686, January 2004. 230 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 231 4303, December 2005. 233 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 234 Internet Key Exchange Protocol (IKE)", RFC 4434, February 235 2006. 237 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 238 Header Compression (ROHC) Framework", RFC 5795, March 239 2010. 241 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 242 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 243 5996, September 2010. 245 10.2. Informational References 247 [GUGG14] Guggemos, TG., "Diet-ESP: Applying IP-Layer Security in 248 Constrained Environments (Masterthesis)", September 2014. 250 10.3. URIs 252 [1] http://www.iana.org/assignments/ikev2-parameters/ 253 ikev2-parameters.xhtml#ikev2-parameters-6 255 Appendix A. Document Change Log 257 [draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: First version 258 published. 260 Authors' Addresses 262 Daniel Migault (editor) 263 Orange 264 38 rue du General Leclerc 265 92794 Issy-les-Moulineaux Cedex 9 266 France 268 Phone: +33 1 45 29 60 52 269 Email: daniel.migault@orange.com 271 Tobias Guggemos (editor) 272 Orange / LMU Munich 273 Am Osteroesch 9 274 87637 Seeg, Bavaria 275 Germany 277 Email: tobias.guggemos@gmail.com