idnits 2.17.1 draft-ietf-ipsec-dhless-enc-mode-00.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-03-28) 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. == There is 1 instance of lines with non-ascii characters in the document. == 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: ' 4. 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 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([MSST98], [BeCaKr], [Ble], [RSAlabs], [Pip96], [SKEME], [HC98]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1998) is 9388 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) -- Missing reference section? 'HC98' on line 183 looks like a reference -- Missing reference section? 'SKEME' on line 165 looks like a reference -- Missing reference section? 'MSST98' on line 183 looks like a reference -- Missing reference section? 'BeCaKr' on line 153 looks like a reference -- Missing reference section? 'Ble' on line 158 looks like a reference -- Missing reference section? 'RSAlabs' on line 176 looks like a reference -- Missing reference section? 'Pip96' on line 173 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 9 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-dhless-enc-mode-00.txt July 1998 4 Expire in six months 6 A DH-less encryption mode for IKE 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 view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 1. Abstract 30 The IKE document [HC98] describes a key exchange protocol for 31 obtaining 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 All the current modes for carrying out Phase 1 of the key exchange 36 in [HC98] incorporate a Diffie- Hellman exponentiation. While the DH 37 exponentiation enhances the security of the exchange (and in particular 38 provides perfect forward secrecy (PFS)), this enhanced secrecy comes 39 at a computational cost. In cases where PFS is not a requirement, most 40 notably in authentication only scenarios, less expensive solutions 41 are possible. 43 This draft describes a ``DH-less'' version of the (revised) public- 44 key encryption mode of [HC98]. This saves the DH exponentiation, 45 which may be significant (especially on low-end machines and busy servers). 46 The proposed mode is VERY similar to the existing modes and requires 47 only minimal modifications. In particular, it is straightforward 48 to implement as an addition to the existing modes. 50 Remark: This document is NOT self-contained. It uses notation and 51 definitions of [HC98]. It is best read in conjunction with [HC98]. 53 2. Introduction 55 The IKE protocol [HC98] defines four alternative modes of 56 carrying out Phase 1 of the key exchange. Three of these modes are 57 usable by parties that do not already share a secret key. These are 58 the Signature Mode and the (original and revised) Public Key 59 Encryption Modes. 61 All three public-key based modes involve a Diffie-Hellman 62 exponentiation. While this is essential in the Signature Mode, the 63 Public Key Encryption Mode can be easily modified to do without 64 the DH exponentiation (following [SKEME]). 66 The main advantage of the DH exponentiation is perfect forward secrecy 67 (PFS): an attacker that breaks the public key encryption at a later 68 time (either by cryptanalysis or by obtaining the private key) still 69 cannot compute g^xy from g^x and g^y, thus it cannot decipher messages 70 encrypted with a key that was computed using g^xy. 72 While PFS is very important for some applications, it is not 73 a requirement for others. Two important examples are security 74 associations that are used only for authentication, and associations 75 that need only "ephemeral secrecy" (for example, timely stock quotes). 76 See [SKEME] for further discussion. 78 This draft describes a "DH-less" variant of the (revised) Public Key 79 Encryption Mode. This variant does NOT provide PFS, and the security 80 of the key is based solely on the security of the public key encryption 81 algorithm in use. It avoids the DH exponentiations. This may be 82 a considerable saving, especially for low-end machines or busy servers 83 that authenticate all outgoing data. 84 We note that in order to learn an exchanged key the attacker needs to 85 find the secret private keys of BOTH Initiator AND Responder. 87 The modifications from the current (revised) public key encryption mode 88 are minimal. Simply delete the DH payloads (Ke_i and Ke_r) 89 and in the ensuing computations set g^x = g^y = g^xy = 0 (one octet). 91 The rest of this document is organized as follows. In Section 3 92 the DHless Encryption Mode is described. The description is 93 written in a way so that Section 3 can be read as an additional 94 subsection in Section 5 of [HC98]. Appendix A holds the authentication 95 mode value of the new mode (see ISAKMP [MSST98] and Appendix A 96 of [HC98]). 98 3. Phase 1 Authenticated With a DH-less Mode of Public Key Encryption 100 This mode is identical to the Revised PK Encryption Mode 101 (Section 5.3 in [HC98]), except for the omission of the DH payloads. 102 When using the DH-less encryption mode for authentication, Main Mode 103 is defined as follows. 105 Initiator Responder 106 ----------- ----------- 107 HDR, SA --> 108 <-- HDR, SA 109 HDR, [ HASH(1), ] 110 Pubkey_r, 111 Ke_i, 112 [<Ke_i] --> 113 HDR, PubKey_i, 114 <-- Ke_r, 115 HDR*, HASH_I --> 116 <-- HDR*, HASH_R 118 Aggressive Mode authenticated with the revised encryption mode is 119 described as follows: 121 Initiator Responder 122 ----------- ----------- 123 HDR, SA, [ HASH(1),] 124 Pubkey_r, 125 Ke_i 126 [, Ke_i ] --> 127 HDR, SA, PubKey_i, 128 Ke_r, 129 <-- HASH_R 130 HDR, HASH_I --> 132 where HASH(1) is identical to section 5.2 in [HC98]. For the purpose 133 of calculating HASH_I and HASH_R the values of g^xi and g^xr are 134 set to an octet of 0. For the purpose of calculating SKEYID_d, SKEYID_a, 135 and SKEYID_e, the value g^xy is set to an octet of 0. 137 4. Security Considerations 139 The public key encryption modes of authentication in IKE require 140 strong public key encryption. In particular, resistance to strong 141 attacks generally known as "chosen ciphertext attacks" (CCA) is 142 necessary. This is a practical need as well as the basis for a sound 143 analysis of these protocols [BeCaKr]. Recently, an explicit chosen 144 ciphertext attack on the PKCS #1 encryption standard was demonstrated 145 [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release 146 of PKCS #1 that will include the OAEP format of RSA encryption [RSAlabs]. 147 It is strongly recommended that IKE specifications and implementations 148 move to that format which was designed to resist CCA and other attacks. 150 References 151 ========== 153 [BeCaKr] Bellare, M., Canetti, R., and Krawczyk, H., 154 "A Modular Approach to the Design and Analysis of Authentication and 155 Key Exchange Protocols", Proceedings of the Thirtieth ACM Symposium on 156 the Theory of Computation, May 1998. 158 [Ble] Daniel Bleichenbacher, Chosen Ciphertext Attacks Against Protocols 159 Based on the RSA Encryption Standard PKCS #1, Proceedings of Crypto'98, 160 August 1998. To appear. 162 [HC98] Harkins, D. and D. Carrel, "The resolution of ISAKMP with 163 Oakley", draft-ietf-ipsec-isakmp-oakley-08.txt, June 1998. 165 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 166 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 167 on Network and Distributed Systems Security. 169 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 170 "Internet Security Association and Key Management Protocol (ISAKMP)", 171 version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. 173 [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation 174 for ISAKMP", version 2, draft-ietf-ipsec-ipsec-doi-02.txt. 176 [RSAlabs] http://www.rsa.com/rsalabs/pkcs1/oem_counter.html 178 Appendix A: XCHG attribute assigned number 179 ========================================= 181 This Appendix defines a new authentication mode value for the 182 Revised Encryption Mode. This value is to be negotiated in 183 Phase 1 (see [MSST98] and Appendix A in [HC98]). The value is: 185 authentication mode value 186 --------------------------- 188 DHless RSA Encryption 6 190 Authors' Addresses: 191 ==================== 193 Ran Canetti Pau-Chen Cheng 194 IBM TJ Watson Research Center IBM TJ Watson Research Center 195 POB. 704, Yorktown Heights, POB. 704, Yorktown Heights, 196 NY 10598 NY 10598 197 Tel. 1-914-784-7076 Tel. 1-914-784-7446 198 canetti@watson.ibm.com pau@watson.ibm.com 200 Hugo Krawczyk 201 IBM TJ Watson Research Center 202 POB. 704, Yorktown Heights, 203 NY 10598 204 hugo@ee.technion.ac.il 206