idnits 2.17.1 draft-ietf-ipsec-revised-enc-mode-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([CH97], [Kra96], [HC97], [Pip96], [MSST96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 219: '...ption Method, it MUST be encrypted in ...' RFC 2119 keyword, line 236: '... RSA encryption MUST be encoded in PK...' RFC 2119 keyword, line 243: '... Implementations SHOULD support RSA en...' RFC 2119 keyword, line 244: '...authentication method value), and MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 54 has weird spacing: '.../Oakley proto...' == Line 183 has weird spacing: '...ail the proce...' == Line 255 has weird spacing: '...is used to se...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'HC97' on line 302 looks like a reference -- Missing reference section? 'MSST96' on line 302 looks like a reference -- Missing reference section? 'CH97' on line 107 looks like a reference -- Missing reference section? 'Kra96' on line 286 looks like a reference -- Missing reference section? 'Pip96' on line 294 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group R. Canetti, P. Cheng, H. Krawczyk 2 INTERNET-DRAFT IBM Research and the Technion 3 draft-ietf-ipsec-revised-enc-mode-01.txt July 1997 4 Expire in six months 6 A revised encryption mode for ISAKMP/Oakley 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 1. Abstract 29 The ISAKMP/Oakley document [HC97] describes a proposed standard for 30 using the Oakley Key Exchange Protocol in conjunction with ISAKMP to 31 obtain authenticated and secret keying material for use with ISAKMP, 32 and for other security associations such as AH and ESP for the IETF 33 IPsec DOI. 35 The public-key encryption method of carrying out Phase 1 of the key 36 exchange in the ISAKMP/Oakley document provides significant security 37 advantages over the other alternatives and should be the method of 38 choice in many implementations. Unfortunately, as currently 39 described in [HC97] the method requires two public key 40 encryption and decryption operations from both the Initiator and 41 the Responder. The present document describes a small modification 42 to this method. The resulting scheme requires only one public key 43 encryption and decryption operation from each party, while maintaining 44 (and even improving on) the strong security properties of the 45 ISAKMP/Oakley public-key encryption mode. 47 Remark: This document is NOT self-contained, it is intended as an 48 addendum to the authentication methods defined in [HC97]. 49 In particular, it uses notation and definitions of [HC97]. 50 Thus, it is best read in conjunction with [HC97]. 52 2. Introduction 54 The ISAKMP/Oakley protocol [HC97] defines three alternative methods 55 of carrying out Phase 1 of the key exchange. Two of these methods 56 are usable by parties that do not already share a secret key. 57 These are the Signature Method (Section 5.1 in [HC97]) and the 58 Encryption Method (Section 5.2 in [HC97]). 60 The Encryption Method enjoys several significant advantages over the 61 Signature Method. These advantages are sketched in Section 5. 62 However, in the ISAKMP/Oakley draft the Encryption Method requires 63 TWO public key encryption and decryption operations for each party. 64 This is unnecessarily expensive. (In overloaded or weak processors 65 the extra exponentiation may have a significantly adverse effect in 66 performance.) 68 This document describes a simple modification of the ISAKMP/Oakley 69 Encryption Method. The resulting method enjoys the same security 70 advantages, and requires only ONE public key encryption and decryption 71 operation for each party. This method, called the Revised Encryption 72 Method, is presented as an alternative method to the ISAKMP/Oakley 73 Encryption Method. In fact, the revised method enjoys even additional 74 security advantages on top of the ISAKMP/Oakley Encryption Method, 75 as elaborated below. The required changes are minimal. 77 The change from the ISAKMP/Oakley Encryption Method is basically as 78 follows. There, each party's identity and nonce are encrypted via 79 TWO separate applications of the public-key encryption algorithm. 80 (In fact, if the party's identity is long then this may require 81 additional applications of the public-key encryption algorithm.) 83 In the Revised Encryption Method the nonce is still encrypted 84 using the public-key encryption algorithm. However, the sending 85 party's identity (and also the certificate, if it is sent) is 86 encrypted via symmetric encryption (e.g. DES), with a key derived 87 from the nonce. This solution adds no significant complexity to the 88 implementation and saves a costly long (RSA or other) exponentiation. 89 In addition, the Key Exchange payload (ie. the DH challenges) is also 90 encrypted using the same derived key. This provides additional 91 protection against cryptanalysis of the DH exchange. 93 The Revised Encryption mode has another advantage. The (optional) 94 Certificate payload is also encrypted using the same derived key. 95 Consequently anonymity is preserved even if the certificate is sent 96 as part of the exchange. 98 The rest of this document is organized as follows. In Section 3 99 the Revised Encryption Method is described. The description is 100 written in a way so that Section 3 can be read as a replacement to 101 Section 5.2 in [HC97]. Section 4 specifies default algorithms. 103 Section 5 discusses some security advantages of the Encryption 104 Method relative to the Signature method. (These advantages are 105 shared by the Revised Encryption Method.) Appendix A holds the 106 authentication method value of the new method (see ISAKMP [MSST96] 107 and Appendix A of [CH97]). 109 3. The new method: Revised Encryption Method of Oakley Phase 1 111 Using public key encryption to authenticate the exchange, the 112 ancillary information exchanged is encrypted nonces. Each party's 113 ability to reconstruct a hash (proving that the other party decrypted 114 the nonce) authenticates the exchange. 116 In order to perform the public key encryption, the initiator must 117 already have the responder's public key. In the case where a party 118 has multiple public keys, a hash of the certificate of the initiator 119 used to encrypt the ancillary information is passed as part of the 120 third message. In this way the responder can determine which 121 corresponding private key to use to decrypt the encrypted payloads 122 and identity protection is retained. 124 The nonces are encrypted with the other party's public key. 125 The Key Exchange payloads (KE) and the identities 126 of the parties (IDii and IDir) are encrypted with the negotiated 127 symmetric encryption algorithm (e.g DES), using a key derived from 128 the nonce. If the Initiator's certificate is passed from Initiator 129 to Responder then, for anonymity, the certificate is also encrypted 130 under the same key. In all these cases only the body of the payload 131 is encrypted, the payload header is left in the clear; and the length 132 field in the payload header is the length of the ciphertext (including 133 any pre-pended information and padding) plus the size of the payload 134 header. 136 That is, Phase 1 (Main Mode) is defined as follows. 138 Initiator Responder 139 ----------- ----------- 140 HDR, SA --> 141 <-- HDR, SA 142 HDR, [ HASH(1), ] 143 PubKey_r --> 144 Ke_i 145 Ke_i 146 [Ke_i] 147 <-- HDR, PubKey_i 148 Ke_r 149 Ke_r 150 HDR*, HASH_I --> 151 <-- HDR*, HASH_R 153 HASH(1) is a hash (using the negotiated hash function) of the 154 responder's certificate which the initiator is using to encrypt 155 the nonce. 157 The values of HASH_I and HASH_R are as defined in [HC97], namely, 159 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) 160 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) 162 with SKEYID (also defined in [HC97]) being: 164 SKEYID = prf(Ni | Nr, CKY-I | CKY-R) 166 The notation <...>PubKey refers to public key encryption 167 (e.g. using the RSA algorithm) while the notation <...>Ke 168 refers to encryption under the negotiated symmetric cipher. 169 The keys for the symmetric cipher are derived as follows. 170 First, compute the values Ne_i and Ne_r: 172 Ne_i = prf(Ni, CKY-I) 173 Ne_r = prf(Nr, CKY-R) 175 Next, the keys Ke_i and Ke_r are derived from Ne_i and Ne_r, 176 respectively, in the way described in Appendix B of [HC97]. 177 That is, to derive Ke_i run the procedure described in Appendix B of 178 [HC97] for deriving encryption keys used to protect the ISAKMP SA, 179 but replacing SKEYID_e with Ne_i. To derive Ke_r run the 180 procedure described in Appendix B of [HC97], where SKEYID_e is 181 replaced by Ne_r. 183 For completeness, we detail the procedure for deriving Ke_i. 184 Ke_r is derived analogously. If the desired length of Ke_i is 185 at most the length of Ne_i then Ke_i is the sufficient number 186 of most significant bits of Ne_i. If the desired length of Ke_i 187 exceeds the length of Ne_i then more bits are generated by applying 188 the prf with Ne_i as the key and a byte of 0 as the input. 189 The output of the prf is fed back into itself until sufficient 190 number of bits are generated. For example, if the output of prf 191 is 128-bit long and Ne_i needs to be 320-bit long, then Ne_i is 192 the most significant 320 bits of K, where K = K1 | K2 | K3 and 194 K1 = prf(Ne_i, 0) 195 K2 = prf(Ne_i, K1) 196 K3 = prf(Ne_i, K2) 198 Note that the values of Ke_i and Ke_r are ephemeral and discarded 199 after this use. 201 If CBC mode is used for the symmetric encryption then the 202 initialization vectors (IV) are set as follows. The IV for 203 encrypting KE is set to 0. The IV for encrypting IDii (resp., IDir) 204 is the last ciphertext block of Ke_i (resp., Ke_r). 205 The IV for encrypting the certificate 206 is the last ciphertext block of Ke_i (resp., Ke_r). 207 Encrypted payloads are padded up to the nearest block 208 size. All padding bytes, except for the last one, contain 0x00. 209 The last byte of the padding contains the number of the padding 210 bytes used, excluding the last one. 211 Note that this means that there will always be padding. 212 Note also that the IV chaining method used here implies that KE, 213 the ID and the certificate have to be encrypted in that order. 214 (We stress that this encryption order does not require that these 215 payloads appear in that same order in the ISAKMP message; indeed 216 [MSST96] does allow for arbitrary ordering of these payloads). 218 When a Certificate payload is sent in the context of the Revised 219 Encryption Method, it MUST be encrypted in the manner described above. 221 Oakley Aggressive Mode in conjunction with the Revised Encryption 222 Method is described as follows (using the same notation as above): 224 Initiator Responder 225 ----------- ----------- 226 HDR, SA, [ HASH(1),] 227 Pubkey_r, 228 Ke_i 229 Ke_i --> 230 [Ke_i] 231 HDR, SA, PubKey_i, 232 Ke_r 233 <-- Ke_r, HASH_R 234 HDR, HASH_I --> 236 RSA encryption MUST be encoded in PKCS #1 format. The PKCS 237 #1 encoding allows for determination of the actual length of the 238 cleartext payload upon decryption. 240 4. Algorithms 242 The above mode can use any public key encryption algorithm. 243 Implementations SHOULD support RSA encryption (see Appendix A 244 for the corresponding authentication method value), and MUST 245 support DES-CBC as specified in [HC97] for payload encryption. 247 5. Security Considerations 249 In this section we sketch the advantages of authentication by 250 public-key encryption, as opposed to authentication by signature. 251 First, in the Encryption mode an attacker has to break BOTH the 252 the public key encryption in use (e.g. RSA) and DH exchange 253 in order to learn the agreed key. In the Signature Mode breaking the 254 DH exchange is sufficient. This is a substantial security advantage 255 in a scenario where the same prime is used to secure a large number 256 of exchanges: such a prime will become an attractive 257 target for cryptanalysis, thus it may provide only weak security. 258 It also adds protection against a party that chooses weak parameters 259 in the DH exchange, such as a weak prime or short exponents. 260 This aspect of security is further enhanced by the encryption of the 261 KE payload. 263 Next, using encryption for authentication provides for a plausibly 264 deniable exchange. There is no proof (in contrast to the use of 265 digital signatures) that the conversation ever took place since each 266 party could have generated both sides of the exchange. 268 Furthermore, unlike other authentication methods, authentication with 269 public key encryption allows for identity protection even in 270 Aggressive Mode (even certificates are protected in this case). 272 We remark that both the ISAKMP/Oakley Encryption Method and the 273 Revised Encryption method described here are based on a similar 274 mode in [Kra96] where a more extensive discussion on the above issues 275 and analysis of security can be found. 277 6. Acknowledgments 279 We thank Dan Harkins for helpful discussions and suggestions. 281 7. References 283 [HC97] Harkins, D. and D. Carrel, "The resolution of ISAKMP with 284 Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt, July 1997. 286 [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 287 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 288 on Network and Distributed Systems Security. 290 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 291 "Internet Security Association and Key Management Protocol (ISAKMP)", 292 version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. 294 [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation 295 for ISAKMP", version 3, draft-ietf-ipsec-ipsec-doi-03.txt. 297 Appendix A: XCHG attribute assigned number 298 ========================================= 300 This Appendix defines a new authentication method value for the 301 Revised Encryption Method. This value is to be negotiated in 302 Phase 1 (see [MSST96] and Appendix A in [HC97]). The value is: 304 authentication method value 305 --------------------------- 307 Revised RSA Encryption 5 309 Authors' Addresses: 310 ==================== 312 Ran Canetti Pau-Chen Cheng 313 IBM TJ Watson Research Center IBM TJ Watson Research Center 314 POB. 704, Yorktown Heights, POB. 704, Yorktown Heights, 315 NY 10598 NY 10598 316 Tel. 1-914-784-7076 Tel. 1-914-784-7446 317 canetti@watson.ibm.com pau@watson.ibm.com 319 Hugo Krawczyk 320 IBM TJ Watson Research Center 321 POB. 704, Yorktown Heights, 322 NY 10598 323 hugo@ee.technion.ac.il