idnits 2.17.1 draft-weis-esp-group-counter-cipher-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 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 335. ** 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 (October 13, 2006) is 6404 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 (-09) exists of draft-ietf-msec-ipsec-extensions-02 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 Expires: April 16, 2007 Cisco Systems 5 October 13, 2006 7 Using Counter Modes with Encapsulating Security Payload (ESP) and 8 Authentication Header (AH) to Protect Group Traffic 9 draft-weis-esp-group-counter-cipher-00 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 April 16, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo describes the use of Advanced Encryption Standard (AES) 43 counter modes when applied to the Encapsulating Security Payload 44 (ESP) and Authentication Header (AH) in multiple-sender group 45 applications. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 52 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Recommended IV Formation . . . . . . . . . . . . . . . . . . . 5 56 4. Group Key Management Conventions . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Appendix A. Rationale for the Recommended IV Formation . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 13 71 1. Introduction 73 Several new AES encryption modes of operation have been specified for 74 the IP Encapsulating Security Payload (ESP) [RFC4303]: ESP: Counter 75 Mode (CTR) [RFC3686], Galois/Counter Mode (GCM) [RFC4106], Counter 76 with CBC-MAC Mode (CCM) [RFC4309]; and one that has been specified 77 for both ESP and the Authentication Header (AH): Galois MAC Mode 78 (GMAC) [RFC4543]. These new modes offer advantages over traditional 79 modes of operation. However, they all have restrictions on their use 80 in situations in which multiple senders are protecting traffic using 81 the same key. This document addresses this restriction and describes 82 how these modes can be used with group key management protocols such 83 as the Group Domain of Interpretation (GDOI) protocol [RFC3547] and 84 the Group Secure Association Key Management Protocol (GSAKMP) 85 [RFC4535]. 87 1.1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Problem Statement 95 The counter mode of operation (CTR) [FIPS.800-38A.2001] has become 96 important because of its performance and implementation advantages. 97 It is the basis for several modes of operation that combine 98 encryption, including CCM and GCM. All of the counter-based modes 99 require that, if a single key is shared by multiple encryption 100 engines, those engines must coordinate to ensure that every 101 initialization vector (IV) used with that key is distinct. That is, 102 for each key, no IV value can be used more than once. This 103 restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. 105 All ESP transforms using an AES counter mode have a restriction that 106 an application must not use the same key, IV, and Salt values to 107 protect two different data payloads. Notwithstanding this security 108 condition, AES counter mode ESP transforms are often preferred 109 because of their favorable performance characteristics as compared to 110 other AES modes. 112 Each of the ESP transforms using AES counter mode specify the 113 construction of keying material for point-to-point applications which 114 are keyed by the Internet Key Exchange version 1 (IKE) [RFC2409] or 115 version 2 (IKEv2) [RFC4306]. The specified constructions guarantee 116 that the security condition is not violated by a single sender. 117 However, group applications, where multiple senders encrypt using a 118 single IPsec Security Association (SA), also may find AES counter 119 mode transforms to be valuable. Such groups are possible when IPsec 120 is used to protect network traffic between members of a multiple 121 sender IP multicast application, known as a Many-to-Many Application 122 [RFC3170]. Some Many-to-many Applications are comprised of a large 123 number of senders such that defining an individual IPsec SA for each 124 sender is unmanageable. 126 3. Recommended IV Formation 128 This section specifies a particular construction of the IV that 129 enables a group of senders to safely share a single IPsec SA. A 130 rationale for this method is given in Appendix A. In the recommended 131 construction, each IV is formed by concatenating a Sender Identifier 132 (SID) field with a Sender-Specific IV (SSIV) field. The value of the 133 SID MUST be unique for each sender, across all of the senders sharing 134 a particular Security Association. The value of the SSIV field MUST 135 be unique for each IV constructed by a particular sender for use with 136 a particular SA. The SSIV MAY be chosen in any manner convenient to 137 the sender, e.g. successive values of a counter. The leftmost bits 138 of the IV contain the SID, and the remaining bits contain the SSIV. 140 The number of bits used by the SID may vary depending on group 141 policy, though for each particular Security Association, each SID 142 used with that SA MUST have the same length. Additionally, a 143 conforming implementation MUST support SID lengths of 8, 12, and 16 144 bits. It should be noted that the size of the SID associated with an 145 SA provides a tradeoff between the number of possible senders and the 146 number of packets that each sending station is able to send using 147 that SA. 149 4. Group Key Management Conventions 151 A group uses ESP to protect traffic uses a Group Key Management (GKM) 152 subsystem and protocol [I-D.ietf-msec-ipsec-extensions] to distribute 153 the ESP transform policy and keying material. This document 154 RECOMMENDS that the GKM subsystem on a Group Controller Key Sever 155 (GCKS) both allocate SIDs to group members and distributes them to 156 group members using a GKM protocol such as GDOI or GSAKMP. 158 The following requirements apply to a GKM protocol that manages SIDs. 160 o The GCKS MUST NOT give the same sender identifier to more than one 161 active group member. If the entire set of sender identifiers has 162 been exhausted, the GCKS MUST refuse to allow new group members to 163 join. 165 o The GCKS SHOULD allocate a single sender identifier for each group 166 member, and issue this value to the sender for all group SAs for 167 which that member is a sender. This strategy simplifies the 168 rekeying process. 170 o If a GCKS allocates a single sender identifier to be used with all 171 group SAs for which it is a sender, and it determines that a 172 particular group member is no longer a part of the group, then it 173 MAY re-allocate the sender identifier to a new group member. In 174 this case, the GCKS MUST first delete and replace any active AH or 175 ESP SAs with which the SID may have been used. This is necessary 176 to avoid re-use of an IV with the cipher key associated with the 177 SA. 179 A GKM subsystem MUST support a group member notifying the GCKS that 180 its IV space will soon be exhausted and requires a new SA to be 181 distributed. A group member SHOULD notify the GCKS in advance of its 182 IV space being exhausted. A GCKS MAY choose to ignore this 183 notification based on policy (e.g., if the group member appears to be 184 asking for new SAs so frequent as to negatively affect group 185 communications). 187 5. IANA Considerations 189 Note to RFC Editor: this section may be removed on publication as an 190 RFC. 192 This memo has no IANA considerations. 194 6. Security Considerations 196 This specification provides a method for securely using crypto 197 algorithms that require a unique IV, such as a block cipher mode of 198 operation based on counter mode, in a scenario in which there are 199 multiple encryption devices. When its recommendations are followed, 200 the security of the crypto algorithms is equivalent to the 201 conventional case in which there is a single sender. 203 7. References 205 7.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 211 Counter Mode With IPsec Encapsulating Security Payload 212 (ESP)", RFC 3686, January 2004. 214 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 215 (GCM) in IPsec Encapsulating Security Payload (ESP)", 216 RFC 4106, June 2005. 218 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 219 RFC 4303, December 2005. 221 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 222 Mode with IPsec Encapsulating Security Payload (ESP)", 223 RFC 4309, December 2005. 225 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 226 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 227 May 2006. 229 7.2. Informative References 231 [FIPS.800-38A.2001] 232 National Institute of Standards and Technology, 233 "Recommendation for Block Cipher Modes of Operation", 234 FIPS PUB 800-38A, December 2001, . 237 [I-D.ietf-msec-ipsec-extensions] 238 Weis, B., Gross, G., and D. Ignjatac, "Multicast 239 Extensions to the Security Architecture for the Internet 240 Protocol", draft-ietf-msec-ipsec-extensions-02 (work in 241 progress), June 2006. 243 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 244 (IKE)", RFC 2409, November 1998. 246 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 247 Challenges and Solutions", RFC 3170, September 2001. 249 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 250 Group Domain of Interpretation", RFC 3547, July 2003. 252 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 253 RFC 4306, December 2005. 255 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 256 "GSAKMP: Group Secure Association Key Management 257 Protocol", RFC 4535, June 2006. 259 Appendix A. Rationale for the Recommended IV Formation 261 The two main alternatives for ensuring the uniqueness of IVs in a 262 multi-sender environment are to have each sender include a Sender 263 Identifier (SID) value in either the Salt value or in the explicit IV 264 field (recall that the IV used as input to the crypto algorithm is 265 constructed by concatenating the Salt and the explicit IV). The 266 explicit IV field was chosen as the location for the SID because it 267 is explicitly present in the packet. If the SID had been included in 268 the Salt, then a receiver would need to infer the SID value for a 269 particular ESP packet by recognizing which sender had sent that 270 packet. This inference could be made on the IP source address, if 271 ESP is transported directly over IP. However, if an alternate 272 transport mechanism such as UDP is being used (e.g. for NAT 273 traversal), the method used to infer the sender would need to take 274 that mechanism into account. It is simpler to use the explicit IV 275 field, and thus avoid the need to infer the sender from the packet at 276 all. 278 The normative requirement that all of the SID values used with a 279 particular Security Association must have the same length is not 280 strictly necessary, but was added to promote simplicity of 281 implementation. Alternatively, it would be acceptable to have the 282 SID values be chosen to be the codewords of a variable-length prefix 283 free code. This approach preserves security since the distinctness 284 of the IVs follows from the fact that no SID is a prefix of another; 285 thus any pair of IVs has a subset of bits that are distinct. If a 286 Huffman code is used to form the SIDs, then a set of optimal SIDs can 287 be found, in the sense that the number of SIDs can be maximized for a 288 given distribution of SID lengths. Additionally, there are simple 289 methods for generating efficient prefix free codes whose codewords 290 are octet strings. Nevertheless, these methods were disallowed in 291 order to favor simplicity over generality. 293 Authors' Addresses 295 David A. McGrew 296 Cisco Systems 297 170 W. Tasman Drive 298 San Jose, California 95134-1706 299 USA 301 Phone: +1-408-525-8651 302 Email: mcgrew@cisco.com 304 Brian Weis 305 Cisco Systems 306 170 W. Tasman Drive 307 San Jose, California 95134-1706 308 USA 310 Phone: +1-408-526-4796 311 Email: bew@cisco.com 313 Intellectual Property Statement 315 The IETF takes no position regarding the validity or scope of any 316 Intellectual Property Rights or other rights that might be claimed to 317 pertain to the implementation or use of the technology described in 318 this document or the extent to which any license under such rights 319 might or might not be available; nor does it represent that it has 320 made any independent effort to identify any such rights. Information 321 on the procedures with respect to rights in RFC documents can be 322 found in BCP 78 and BCP 79. 324 Copies of IPR disclosures made to the IETF Secretariat and any 325 assurances of licenses to be made available, or the result of an 326 attempt made to obtain a general license or permission for the use of 327 such proprietary rights by implementers or users of this 328 specification can be obtained from the IETF on-line IPR repository at 329 http://www.ietf.org/ipr. 331 The IETF invites any interested party to bring to its attention any 332 copyrights, patents or patent applications, or other proprietary 333 rights that may cover technology that may be required to implement 334 this standard. Please address the information to the IETF at 335 ietf-ipr@ietf.org. 337 Disclaimer of Validity 339 This document and the information contained herein are provided on an 340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 342 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 343 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 344 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 347 Copyright Statement 349 Copyright (C) The Internet Society (2006). This document is subject 350 to the rights, licenses and restrictions contained in BCP 78, and 351 except as set forth therein, the authors retain all their rights. 353 Acknowledgment 355 Funding for the RFC Editor function is currently provided by the 356 Internet Society.