idnits 2.17.1 draft-ietf-ipsec-ui-suites-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 237 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). == Unrecognized Status in 'Intended status: Best Common Practice', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (April 14, 2004) is 7314 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 Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-ietf-ipsec-ui-suites-06.txt VPN Consortium 3 April 14, 2004 4 Expires in six months 5 Intended status: Best Common Practice 7 Cryptographic Suites for IPsec 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to 32 provide privacy and authentication between the initiator and responder. 33 There are many such algorithms available, and two IPsec systems cannot 34 interoperate unless they are using the same algorithms. This document 35 specifies optional suites of algorithms and attributes that can be used 36 to simplify the administration of IPsec when used in manual keying mode, 37 with IKE version 1, or with IKEv2. 39 1. Introduction 41 This document is a companion to IPsec [RFC2401] and its two key exchange 42 protocols, IKE [RFC2409] and IKEv2 [IKEv2]. Like most security 43 protocols, IPsec, IKE, and IKEv2 allow users to chose which 44 cryptographic algorithms they want to use to meet their security needs. 46 Implementation experience with IPsec in manual key mode and with IKE has 47 shown that there are so many choices for typical system administrators 48 to make that it is difficult to achieve interoperability without careful 49 pre-agreement. Because of this, the IPsec Working Group agreed that 50 there should be a small number of named suites that cover typical 51 security policies. These suites may be presented in the administrative 52 interface of the IPsec system. These suites, often called "UI suites" 53 ("user interface suites"), are optional and do not prevent implementers 54 from allowing individual selection of the security algorithms. 56 Although the UI suites listed here are optional to implement, this 57 document is intended for Best Common Practice because implementers who 58 call particular suites by the names used here have to conform to the 59 suites listed in this document. These suites should not be considered 60 extensions to IPsec, IKE, and IKEv2, but instead administrative methods 61 for describing sets of configurations. 63 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 64 this document are to be interpreted as described in [RFC2119]. 66 2 UI suites 68 This section lists optional, non-mandatory suites that may be presented 69 to system administrators to ease the burden of choosing among the many 70 options in IPsec systems. These suites cannot cover all of the options 71 that an administrator needs to select. Instead, they give values for a 72 subset of the options. 74 Note that these UI suites are simply collections of values for some 75 options in IPsec. Use of UI suites does not change the IPsec, IKE, or 76 IKEv2 protocols in any way. Specifically, the transform substructure in 77 IKE and IKEv2 must be used to give the value for each specified option 78 regardless of whether or not UI suites are used. 80 Implementations that use UI suites SHOULD also provide a management 81 interface for specifying values for individual cryptographic options. 82 That is, it is unlikely that UI suites are a complete solution for 83 matching the security policies of many IPsec users, and therefore an 84 interface that gives a more complete set of options should be used as 85 well. 87 IPsec implementations that use these UI suites SHOULD use the suite 88 names listed here. IPsec implementations SHOULD NOT use names different 89 than those listed here for the suites that are described, and MUST NOT 90 use the names listed here for suites that do not match these values. 91 These requirements are necessary for interoperability. 93 Note that the suites listed here are for use of IPsec in virtual private 94 networks. Other uses of IPsec will probably want to define their own 95 suites and give them different names. 97 Additional suites can be defined by RFCs. The strings used to identify 98 UI suites are registered by IANA. 100 2.1 Suite "VPN-A" 102 This suite matches the commonly-used corporate VPN security used in 103 IKEv1 at the time this document's publication. 105 IPsec: 106 Protocol ESP [RFC2406] 107 ESP encryption TripleDES in CBC mode [RFC2451] 108 ESP integrity HMAC-SHA1-96 [RFC2404] 110 IKE and IKEv2: 111 Encryption TripleDES in CBC mode [RFC2451] 112 Pseudo-random function HMAC-SHA1 [RFC2104] 113 Integrity HMAC-SHA1-96 [RFC2404] 114 Diffie-Hellman group 1024-bit MODP [RFC2409] 116 Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be 117 supported by both parties in this suite. The initiator of this exchange 118 MAY include a new Diffie-Hellman key; if it is included, it MUST be of 119 type 1024-bit MODP. If the initiator of the exchange includes a 120 Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and 121 it MUST of type 1024-bit MODP. 123 2.2 Suite "VPN-B" 125 This suite is what many people expect the commonly-used corporate VPN 126 security that will be used within a few years of the time this 127 document's publication. 129 IPsec: 130 Protocol ESP [RFC2406] 131 ESP encryption AES with 128-bit keys in CBC mode [AES-CBC] 132 ESP integrity AES-XCBC-MAC-96 [AES-XCBC-MAC] 134 IKE and IKEv2: 135 Encryption AES with 128-bit keys in CBC mode [AES-CBC] 136 Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128] 137 Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC] 138 Diffie-Hellman group 2048-bit MODP [RFC3526] 140 Rekeying of Phase 2 (for IKE) or the CREATE_CHILD_SA (for IKEv2) MUST be 141 supported by both parties in this suite. The initiator of this exchange 142 MAY include a new Diffie-Hellman key; if it is included, it MUST be of 143 type 2048-bit MODP. If the initiator of the exchange includes a 144 Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and 145 it MUST of type 2048-bit MODP. 147 2.3 Lifetimes for IKEv1 149 IKEv1 has two security parameters that do not appear in IKEv2, namely 150 the lifetime of the Phase 1 and Phase 2 SAs. Systems that use IKEv1 with 151 either the VPN-A or VPN-B suites MUST use an SA lifetime of 86400 152 seconds (1 day) for Phase 1 and an SA lifetime of 28800 seconds (8 153 hours) for Phase 2. 155 3. Acknowledgements 157 Much of the text and ideas in this document came from earlier versions 158 of the IKEv2 document edited by Charlie Kaufman. Other text and ideas 159 were contributed by other members of the IPsec Working Group. 161 4. Security considerations 163 This document inherits all of the security considerations of the IPsec, 164 IKE, and IKEv2 documents. 166 Some of the security options specified in these suites may be found in 167 the future to have properties significantly weaker than those that were 168 believed at the time this document was produced. 170 5. References 172 5.1 Normative references 174 [AES-CBC] "The AES Cipher Algorithm and Its Use With IPsec", 175 draft-ietf-ipsec-ciph-aes-cbc, work in progress. 177 [AES-XCBC-MAC] "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", 178 draft-ietf-ipsec-ciph-aes-xcbc-mac, work in progress. 180 [AES-XCBC-PRF-128] "The AES-XCBC-PRF-128 algorithm for IKE", 181 draft-ietf-ipsec-aes-xcbc-prf, work in progress. 183 [IKEv2] "Internet Key Exchange (IKEv2) Protocol", 184 draft-ietf-ipsec-ikev2, work in progress. 186 [RFC2104] "HMAC: Keyed-Hashing for Message Authentication", RFC 2104. 188 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 189 RFC 2119. 191 [RFC2401] "Security Architecture for the Internet Protocol", RFC 2401. 193 [RFC2404] "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404. 195 [RFC2406] "IP Encapsulating Security Payload (ESP)", RFC 2406. 197 [RFC2409] "The Internet Key Exchange (IKE)", RFC 2409. 199 [RFC2451] "The ESP CBC-Mode Cipher Algorithms", RFC 2451. 201 [RFC3526] "More MODP Diffie-Hellman groups for IKE", RFC 3526. 203 6. IANA Considerations 205 IANA is asked to create and maintain a registry called "Cryptographic 206 Suites for IKEv1, IKEv2, and IPsec". The registry consists of a text 207 string and an RFC number that lists the associated transforms. New 208 entries can be added to the registry only after RFC publication and 209 approval by an expert designated by the IESG. 211 The initial values for the new registry are: 213 Identifier Defined in 214 VPN-A RFC [this document] 215 VPN-B RFC [this document] 217 7. Author's address 219 Paul Hoffman 220 VPN Consortium 221 127 Segre Place 222 Santa Cruz, CA 95060 USA 223 paul.hoffman@vpnc.org 225 A. Changes from the -05 draft 227 [[ To be removed when turned into an RFC ]] 229 Changed the IANA considerations to require expert review.