idnits 2.17.1 draft-ietf-msec-ipsec-group-counter-modes-06.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 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 (September 10, 2010) is 4939 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) == Outdated reference: A later version (-11) exists of draft-ietf-msec-gdoi-update-06 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC Working Group D. McGrew 3 Internet-Draft B. Weis 4 Intended status: Standards Track Cisco Systems 5 Expires: March 14, 2011 September 10, 2010 7 Using Counter Modes with Encapsulating Security Payload (ESP) and 8 Authentication Header (AH) to Protect Group Traffic 9 draft-ietf-msec-ipsec-group-counter-modes-06 11 Abstract 13 Counter modes have been defined for block ciphers such as the 14 Advanced Encryption Standard (AES). Counter modes use a counter, 15 which is typically assumed to be incremented by a single sender. 16 This memo describes the use of counter modes when applied to the 17 Encapsulating Security Payload (ESP) and Authentication Header (AH) 18 in multiple-sender group applications. 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 March 14, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 59 3. IV formation for Counter Modes with Group Keys . . . . . . . . 5 61 4. Group Key Management Conventions . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Appendix A. Rationale for the IV formation for Counter Modes 74 with Group Keys . . . . . . . . . . . . . . . . . . . 12 76 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The IP Encapsulating Security Payload (ESP) specification [RFC4303] 83 and Authentication Header (AH) [RFC4302] are security protocols for 84 IPsec [RFC4301]. Several new AES encryption modes of operation have 85 been specified for ESP: Counter Mode (CTR) [RFC3686], Galois/Counter 86 Mode (GCM) [RFC4106], Counter with CBC-MAC Mode (CCM) [RFC4309]; and 87 one that has been specified for both ESP and AH: the Galois MAC Mode 88 (GMAC) [RFC4543]. A Camellia counter mode [RFC5528] and a GOST 89 counter mode [RFC4357] have also been specified. These new modes 90 offer advantages over traditional modes of operation. However, they 91 all have restrictions on their use in situations in which multiple 92 senders are protecting traffic using the same key. This document 93 addresses this restriction and describes how these modes can be used 94 with group key management protocols such as the Group Domain of 95 Interpretation (GDOI) protocol [RFC3547] and the Group Secure 96 Association Key Management Protocol (GSAKMP) [RFC4535]. 98 1.1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Problem Statement 106 The counter mode of operation (CTR) [FIPS.800-38A.2001] has become 107 important because of its performance and implementation advantages. 108 It is the basis for several modes of operation that combine 109 authentication with encryption, including CCM and GCM. All of the 110 counter-based modes require that, if a single key is shared by 111 multiple encryption engines, those engines must coordinate to ensure 112 that every initialization vector (IV) used with that key is distinct. 113 That is, for each key, no IV value can be used more than once. This 114 restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. 115 In cryptographic terms, the IV is a nonce. (Note that CBC mode 116 [RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and 117 CCM do not have these restrictions.) 119 All ESP and AH transforms using a block cipher counter mode have a 120 restriction that an application must not use the same key, IV, and 121 Salt values to protect two different data payloads. Notwithstanding 122 this security condition, block cipher counter mode transforms are 123 often preferred because of their favorable performance 124 characteristics as compared to other modes. 126 Each of the block cipher counter mode transforms specify the 127 construction of keying material for point-to-point applications which 128 are keyed by the Internet Key Exchange version 2 (IKEv2) [RFC4306]. 129 The specified constructions guarantee that the security condition is 130 not violated by a single sender. Group applications of IPsec 131 [RFC5374] may also find counter mode transforms to be valuable. Some 132 group applications can create a IPsec SA per sender, which meets the 133 security condition, and no further specification is required. 134 However, IPsec can be used to protect group applications known as 135 Many-to-Many Applications [RFC3170], where a single IPsec Security 136 Association (SA) is used to protect network traffic between members 137 of a multiple-sender IP multicast application. Some Many-to-Many 138 Applications are comprised of a large number of senders, in which 139 case defining an individual IPsec SA for each sender is unmanageable. 141 3. IV formation for Counter Modes with Group Keys 143 This section specifies a particular construction of the IV that 144 enables a group of senders to safely share a single IPsec SA. This 145 construction conforms to the recommendations of [RFC5116]. A 146 rationale for this method is given in Appendix A. In the 147 construction defined by this specification, each IV is formed by 148 concatenating a Sender Identifier (SID) field with a Sender-Specific 149 IV (SSIV) field. The value of the SID MUST be unique for each 150 sender, across all of the senders sharing a particular Security 151 Association. The value of the SSIV field MUST be unique for each IV 152 constructed by a particular sender for use with a particular SA. The 153 SSIV MAY be chosen in any manner convenient to the sender, e.g. 154 successive values of a counter. The leftmost bits of the IV contain 155 the SID, and the remaining bits contain the SSIV. By way of example, 156 Figure 1 shows the correct placement of an 8-bit SID within an 157 Initialization Vector. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 162 ! SID ! ! 163 +-+-+-+-+-+-+-+-+ SSIV ! 164 ! ! 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 167 Figure 1. IV with an 8-bit SID 169 The number of bits used by the SID may vary depending on group 170 policy, though for each particular Security Association, each SID 171 used with that SA MUST have the same length. To facilitate 172 interoperability, a conforming implementation MUST support SID 173 lengths of 8, 12, and 16 bits. It should be noted that the size of 174 the SID associated with an SA provides a tradeoff between the number 175 of possible senders and the number of packets that each sending 176 station is able to send using that SA. 178 4. Group Key Management Conventions 180 Group applications use a Group Key Management System (GKMS) composed 181 of one or more Group Controller Key Server (GCKS) entities [RFC3740]. 182 The GKMS distributes IPsec transform policy and associated keying 183 material to authorized group members. This document RECOMMENDS that 184 the GKMS both allocate unique SIDs to group members and distribute 185 them to group members using a GKM protocol such as GDOI or GSAKMP. 186 The strategy used by the GKMS does not need to be mandated in order 187 to achieve interoperability; the GKMS is solely responsible for 188 allocating SIDs for the group. Allocating SIDs sequentially is 189 acceptable as long as the allocation method follows the requirements 190 in this section. 192 The following requirements apply to a GKMS that manages SIDs. One 193 example of such a GKMS is [I-D.ietf-msec-gdoi-update]. 195 o For each SA for which sender identifiers are used, the GKMS MUST 196 NOT give the same sender identifier to more than one active group 197 member. If the GKMS is uncertain as to the SID associated with a 198 group member it MUST allocate it a new one. If more than one 199 entity within the GKMS is distributing sender identifiers, then 200 the sets of identifiers distributed by each entity MUST NOT 201 overlap. 203 o If the entire set of sender identifiers has been exhausted, the 204 GKMS MUST refuse to allow new group members to join. 205 Alternatively, the GKMS could distribute replacement ESP or AH 206 security associations to all group members. When replacement SAs 207 are distributed, the GKMS could also distribute larger SID values 208 so that more senders can be accommodated. 210 o The GKMS SHOULD allocate a single sender identifier for each group 211 member, and issue this value to the sender for all group SAs for 212 which that member is a sender. This strategy enables both the 213 GKMS and the senders to avoid managing SIDs on a per-SA basis. It 214 also simplifies the rekeying process, since SIDs do not need to be 215 changed or re-issued along with replacement SAs during a rekey 216 event. 218 o When a GKMS determines that a particular group member is no longer 219 a part of the group, then it MAY re-allocate any sender identifier 220 associated with that group member for use with new group member. 221 In this case, the GKMS MUST first delete and replace any active AH 222 or ESP SAs with which the SID may have been used. This is 223 necessary to avoid re-use of an IV with the cipher key associated 224 with the SA. 226 5. IANA Considerations 228 Note to RFC Editor: this section may be removed on publication as an 229 RFC. 231 This memo has no IANA considerations. 233 6. Security Considerations 235 This specification provides a method for securely using cryptographic 236 algorithms that require a unique IV, such as a block cipher mode of 237 operation based on counter mode, in a scenario in which there are 238 multiple cryptographic devices that each generate IVs. This is done 239 by partitioning the set of possible IV values such that each 240 cryptographic device has exclusive use of a set of IV values. When 241 the recommendation in this specification are followed, the security 242 of the cryptographic algorithms is equivalent to the conventional 243 case in which there is a single sender. Unlike CBC mode CTR, GCM, 244 GMAC, and CCM do not require IVs that are unpredictable. 246 The security of a group depends upon the correct operation of the 247 group members. Any group member using an SID not allocated to it may 248 reduce the security of the system. 250 As is the case with a single sender, a cryptographic device storing 251 keying material over a reboot is responsible for storing a counter 252 value such that upon resumption it never re-uses counters. In the 253 context of this specification, the cryptographic device would need to 254 store both SID and SSIV values used with a particular IPsec SA in 255 addition to policy associated with the IPsec SA. 257 A group member that reaches the end of its IV space MUST stop sending 258 data traffic on that SA. This can happen if the group member does 259 not notify the GKMS in time for the GKMS to remedy the problem (e.g., 260 to provide the group member with a new SSID or to provide a new SA), 261 or if the GKMS ignores the notification for some reason. In this 262 case, the group member should re-register with the GCKS and expect to 263 receive the SAs that it needs to continue participating in the group. 265 This specification does not address virtual machine rollbacks that 266 may cause the cryptographic device to re-use nonce values. 268 Other security considerations applying to IPsec SAs with multiple 269 senders are described in [RFC5374]. 271 7. Acknowledgements 273 The authors wish to thank David Black, Sheela Rowles, and Alfred 274 Hoenes for their helpful comments and suggestions. 276 8. References 278 8.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 284 December 2005. 286 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 287 RFC 4303, December 2005. 289 8.2. Informative References 291 [FIPS.800-38A.2001] 292 National Institute of Standards and Technology, 293 "Recommendation for Block Cipher Modes of Operation", 294 FIPS PUB 800-38A, December 2001, . 297 [H52] Huffman, D., "A Method for the Construction of Minimum- 298 Redundancy Codes", Proceedings of the IRE, Volume:40, 299 Issue:9, On page(s): 1098-1101, ISSN: 0096-8390, 300 September 1952, . 303 [I-D.ietf-msec-gdoi-update] 304 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 305 of Interpretation", draft-ietf-msec-gdoi-update-06 (work 306 in progress), July 2010. 308 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 309 Challenges and Solutions", RFC 3170, September 2001. 311 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 312 Group Domain of Interpretation", RFC 3547, July 2003. 314 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 315 Algorithm and Its Use with IPsec", RFC 3602, 316 September 2003. 318 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 319 Counter Mode With IPsec Encapsulating Security Payload 320 (ESP)", RFC 3686, January 2004. 322 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 323 Architecture", RFC 3740, March 2004. 325 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 326 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 327 RFC 3948, January 2005. 329 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 330 (GCM) in IPsec Encapsulating Security Payload (ESP)", 331 RFC 4106, June 2005. 333 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 334 Internet Protocol", RFC 4301, December 2005. 336 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 337 RFC 4306, December 2005. 339 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 340 Mode with IPsec Encapsulating Security Payload (ESP)", 341 RFC 4309, December 2005. 343 [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 344 Cryptographic Algorithms for Use with GOST 28147-89, GOST 345 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 346 Algorithms", RFC 4357, January 2006. 348 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 349 "GSAKMP: Group Secure Association Key Management 350 Protocol", RFC 4535, June 2006. 352 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 353 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 354 May 2006. 356 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 357 Encryption", RFC 5116, January 2008. 359 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 360 Extensions to the Security Architecture for the Internet 361 Protocol", RFC 5374, November 2008. 363 [RFC5528] Kato, A., Kanda, M., and S. Kanno, "Camellia Counter Mode 364 and Camellia Counter with CBC-MAC Mode Algorithms", 365 RFC 5528, April 2009. 367 Appendix A. Rationale for the IV formation for Counter Modes with Group 368 Keys 370 The two main alternatives for ensuring the uniqueness of IVs in a 371 multi-sender environment are to have each sender include a Sender 372 Identifier (SID) value in either the Salt value or in the explicit IV 373 field (recall that the IV used as input to the crypto algorithm is 374 constructed by concatenating the Salt and the explicit IV). The 375 explicit IV field was chosen as the location for the SID because it 376 is explicitly present in the packet. If the SID had been included in 377 the Salt, then a receiver would need to infer the SID value for a 378 particular AH or ESP packet by recognizing which sender had sent that 379 packet. This inference could be made on the IP source address, if AH 380 or ESP is transported directly over IP. However, if an alternate 381 transport mechanism such as UDP is being used [RFC3948] (e.g. for NAT 382 traversal), the method used to infer the sender would need to take 383 that mechanism into account. It is simpler to use the explicit IV 384 field, and thus avoid the need to infer the sender from the packet at 385 all. 387 The normative requirement that all of the SID values used with a 388 particular Security Association must have the same length is not 389 strictly necessary, but was added to promote simplicity of 390 implementation. Alternatively, it would be acceptable to have the 391 SID values be chosen to be the codewords of a variable-length prefix 392 free code. This approach preserves security since the distinctness 393 of the IVs follows from the fact that no SID is a prefix of another; 394 thus any pair of IVs has a subset of bits that are distinct. If a 395 Huffman code [H52] is used to form the SIDs, then a set of optimal 396 SIDs can be found, in the sense that the number of SIDs can be 397 maximized for a given distribution of SID lengths. Additionally, 398 there are simple methods for generating efficient prefix free codes 399 whose codewords are octet strings. Nevertheless, these methods were 400 disallowed in order to favor simplicity over generality. 402 Appendix B. Example 404 This section provides an example of SID allocation and IV generation, 405 as defined in this document. A GCKS administrator determines that 406 the group has one SA that is shared by all senders. The algorithm 407 for the SA is AES-GCM using an SID of size 8 bits. 409 When the first sender registers with the GCKS, it is allocated SID 1. 410 The sender subsequently sends AES-GCM encrypted packets with the 411 following IVs (shown in network byte order): 0x0100000000000001, 412 0x0100000000000002, 0x0100000000000003, ... with a final value of 413 0x01FFFFFFFFFFFFFF. The second sender registering with the GCKS is 414 allocated SID 2, and begins sending packets with the following IVs: 415 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with 416 a final value of 0x02FFFFFFFFFFFFFF. 418 According to group policy, the GCKS may later distribute policy and 419 keying material for a replacement SA. When group senders begin 420 sending AES-GCM packets encrypted with the new SA each sender 421 continues to use the SID value previously allocated to it. For 422 example, the sender allocated SID 2 would being sending on a new SA 423 with IV values of 0x0200000000000001, 0x0200000000000002, 424 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF. 426 Authors' Addresses 428 David A. McGrew 429 Cisco Systems 430 170 W. Tasman Drive 431 San Jose, California 95134-1706 432 USA 434 Phone: +1-408-525-8651 435 Email: mcgrew@cisco.com 437 Brian Weis 438 Cisco Systems 439 170 W. Tasman Drive 440 San Jose, California 95134-1706 441 USA 443 Phone: +1-408-526-4796 444 Email: bew@cisco.com