idnits 2.17.00 (12 Aug 2021) /tmp/idnits57144/draft-ietf-ipsec-ike-auth-ecdsa-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 134 has weird spacing: '...ules as speci...' -- 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 (March 15, 2001) is 7736 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSIX962' == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-ike-ecc-groups-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-ike-ecc-groups (ref. 'ECC-GR') -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEEP1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYS' == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 == Outdated reference: draft-ietf-pkix-new-part1 has been published as RFC 3280 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSec Working Group S. Blake-Wilson and P. Fahn 3 INTERNET-DRAFT Certicom Corp. 4 Expires: September 14, 2001 March 15, 2001 6 IKE Authentication Using ECDSA 7 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. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes how the Elliptic Curve Digital Signature 31 Algorithm (ECDSA) may be used as the authentication method within 32 the Internet Key Exchange (IKE) protocol. ECDSA may provide 33 benefits including computational efficiency, small signature sizes, 34 and minimal bandwidth, compared to other available digital signature 35 methods. This document adds ECDSA capability to IKE without 36 introducing any changes to existing IKE operation. 38 Table of Contents 40 1. Introduction ................................................. 2 41 2. ECDSA ........................................................ 2 42 3. Specifying ECDSA within IKE .................................. 3 43 4. Security Considerations ...................................... 4 44 5. Intellectual Property Rights ................................. 4 45 6. Acknowledgments .............................................. 4 46 7. References ................................................... 5 47 8. Authors' Addresses ........................................... 6 48 9. Full Copyright Statement ..................................... 6 50 1. Introduction 52 The Internet Key Exchange, or IKE [RFC2409], is a key agreement 53 and security negotiation protocol; it is used for key establishment in 54 IPSec. In Phase 1 of IKE, both parties must authenticate each other 55 using a negotiated authentication method. One option for the 56 authentication method is digital signatures using public key 57 cryptography. Currently, there are two digital signature methods 58 defined for use within Phase 1: RSA signatures and DSA (DSS) 59 signatures. This document introduces ECDSA signatures as a third 60 method. 62 For any given level of security against the best attacks known, ECDSA 63 signatures are smaller than RSA signatures and ECDSA keys require less 64 bandwidth than DSA keys; there are also advantages of computational 65 speed and efficiency in many settings. Additional efficiency may be 66 gained by simultaneously using ECDSA for IKE authentication and using 67 elliptic curve groups for the IKE key exchange. Implementers of IPSec 68 and IKE may therefore find it desirable to use ECDSA as the Phase 1 69 authentication method. 71 2. ECDSA 73 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 74 curve analogue of the DSA (also called DSS) signature method 75 [FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is 76 defined in the ANSI X9.62 standard [ANSIX962]; compatible 77 specifications include FIPS 186-2 [FIPS186-2], IEEE P1363 [IEEEP1363], 78 and SEC 1 [SEC1]. The use of ECDSA in X.509 certificates is described 79 in IETF PKIX [PKIX-ALG]. 81 ECDSA signatures are smaller than RSA signatures of similar 82 cryptographic strength; see [KEYS] for a security analysis of key 83 sizes across public key algorithms. ECDSA public keys (and 84 certificates) are smaller than similar strength DSA keys, resulting in 85 improved communications efficiency. Furthermore, on many platforms 86 ECDSA operations can be computed faster than similar strength RSA or 87 DSA operations. These advantages of signature size, bandwidth, and 88 computational efficiency make ECDSA an attractive choice for many IKE 89 implementions. 91 Recommended elliptic curve domain parameters for use with ECDSA are 92 given in FIPS 186-2 [FIPS186-2] and SEC 2 [SEC2]. A subset of these 93 parameters are recommended in [ECC-GR] for use in the IKE key exchange. 95 Like DSA, ECDSA incorporates the use of a hash function; currently, 96 the only hash function defined for use with ECDSA is the SHA-1 message 97 digest algorithm [FIPS180-1]. 99 3. Specifying ECDSA within IKE 101 The IKE key negotiation protocol consists of two phases, Phase 1 and 102 Phase 2. Within Phase 1, the two negotiating parties authenticate each 103 other, using either pre-shared keys, digital signatures, or public-key 104 encryption. For digital signatures and public-key encryption methods, 105 there are multiple options. The authentication method is specified as 106 an attribute in the negotiated Phase 1 Security Association (SA). 108 Until now, there have been a total of seven specific authentication 109 methods in Phase 1. We now add an eighth option: ECDSA signatures, 110 specified by attribute value 8 in the SA. The new list of 111 IANA-assigned attribute numbers for Phase 1 authentication is: 113 - Authentication Method 114 pre-shared key 1 115 DSS signatures 2 116 RSA signatures 3 117 Encryption with RSA 4 118 Revised encryption with RSA 5 119 Encryption with El-Gamal 6 120 Revised encryption with El-Gamal 7 121 ECDSA signatures 8 123 values 9-65000 are reserved to IANA. Values 65001-65535 are for 124 private use among mutually consenting parties. 126 Phase 1 can be either Main Mode or Agressive Mode. The use and 127 specification of ECDSA signatures as the authentication method applies 128 to both modes. The sequence of Phase 1 message payloads is the same 129 with ECDSA signatures as with DSS or RSA signatures. 131 When ECDSA is used in IKE, the signature payload shall contain an 132 encoding of the computed signature, consisting of a pair of integers r 133 and s, encoded as a byte string using the ASN.1 syntax 134 "ECDSA-Sig-Value" with DER encoding rules as specified in 135 ANSI X9.62 [ANSIX962]. 137 Note also that, like the other digital signature methods, ECDSA 138 authentication requires the parties to know and trust each other's 139 public key. This can be done by exchanging certificates, possibly 140 within the Phase 1 negotiation, if the public keys of the parties are 141 not already known to each other. The use of Internet X.509 public key 142 infrastructure certificates [PKIX-CERT] is recommended; the 143 representation of ECDSA keys in X.509 certificates is specified in 144 [PKIX-ALG]. 146 Since ECDSA requires the use of the SHA-1 hash function, 147 implemententers may find it convenient to specify SHA-1 as the value 148 of the hash algorithm attribute when using ECDSA as the authentication 149 method. Implementers may also find it convenient to use ECDSA 150 authentication in conjunction with an elliptic curve group for the IKE 151 Diffie-Hellman key agreement; see [ECC-GR] for specific curves for the 152 key agreement. 154 4. Security Considerations 156 Implementors should ensure that appropriate security measures are in 157 place when they deploy ECDSA within IKE. In particular, the security 158 of ECDSA requires the careful selection of both key sizes and elliptic 159 curve domain parameters. Selection guidelines for these parameters and 160 some specific recommended curves that are considered safe are provided 161 in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2]. 163 5. Intellectual Property Rights 165 The IETF has been notified of intellectual property rights claimed in 166 regard to the specification contained in this document. For more 167 information, consult the online list of claimed rights 168 (http://www.ietf.org/ipr.html). 170 The IETF takes no position regarding the validity or scope of any 171 intellectual property or other rights that might be claimed to pertain 172 to the implementation or use of the technology described in this 173 document or the extent to which any license under such rights might or 174 might not be available; neither does it represent that it has made any 175 effort to identify any such rights. Information on the IETF's 176 procedures with respect to rights in standards-track and 177 standards-related documentation can be found in BCP-11. Copies of 178 claims of rights made available for publication and any assurances of 179 licenses to be made available, or the result of an attempt made to 180 obtain a general license or permission for the use of such proprietary 181 rights by implementors or users of this specification can be obtained 182 from the IETF Secretariat. 184 6. Acknowledgments 186 The authors would like to thank Paul Lambert and Prakash Panjwani for 187 their comments and suggestions. 189 7. References 191 [ANSIX962] ANSI X9.62-1999, "Public Key Cryptography For The Financial 192 Services Industry: The Elliptic Curve Digital Signature 193 Algorithm (ECDSA)", Americal National Standards Institute, 194 1998. 196 [ECC-GR] S. Blake-Wilson, M. Salter, and Y. Poeluev, "Additional 197 ECC Groups for IKE", IPSEC Working Group Internet-Draft 198 draft-ietf-ipsec-ike-ecc-groups-03.txt. September 1999. 200 [FIPS180-1] FIPS 180-1, "Secure Hash Standard", National Institute of 201 Standards and Technology, 1995. 203 [FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute 204 of Standards and Technology, 2000. 206 [IEEEP1363] IEEE P1363, "Standard Specifications for Public Key 207 Cryptography", Institute of Electrical and Electronics 208 Engineers, 2000. 210 [KEYS] A. Lenstra and E. Verheul, "Selecting Cryptographic Key 211 Sizes", October 1999. Presented at Public Key Cryptography 212 Conference, Melbourne, Australia, January 2000. Available 213 at . 215 [PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and 216 Identifiers for the Internet X.509 Public Key 217 Infrastructure Certificate and CRL Profile", PKIX Working 218 Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt, 219 March 2001. 221 [PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 222 Public Key Infrastructure Certificate and CRL Profile", PKIX 223 Working Group Internet-Draft, 224 draft-ietf-pkix-new-part1-05.txt, March 2001. 226 [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange", 227 IETF RFC 2409, November 1998. 229 [SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient 230 Cryptography Group, 2000. 232 [SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters", 233 Standards for Efficient Cryptography Group, 2000. 235 8. Author's Address 237 Simon Blake-Wilson 238 Certicom Corp. 239 sblake-wilson@certicom.com 241 Paul Fahn 242 Certicom Corp. 243 pfahn@certicom.com 245 9. Full Copyright Statement 247 Copyright (C) The Internet Society (1999). All Rights Reserved. 249 This document and translations of it may be copied and furnished to 250 others, and derivative works that comment on or otherwise explain it 251 or assist in its implementation may be prepared, copied, published 252 and distributed, in whole or in part, without restriction of any 253 kind, provided that the above copyright notice and this paragraph are 254 included on all such copies and derivative works. However, this 255 document itself may not be modified in any way, such as by removing 256 the copyright notice or references to the Internet Society or other 257 Internet organizations, except as needed for the purpose of 258 developing Internet standards in which case the procedures for 259 copyrights defined in the Internet Standards process must be 260 followed, or as required to translate it into languages other than 261 English. 263 The limited permissions granted above are perpetual and will not be 264 revoked by the Internet Society or its successors or assigns. 266 This document and the information contained herein is provided on an 267 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 268 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 269 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 270 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 271 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.