idnits 2.17.00 (12 Aug 2021) /tmp/idnits52703/draft-ietf-ipsec-ike-auth-ecdsa-00.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 257 lines 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. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SEC1' is defined on line 194, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'IKE' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-ECC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-ike-ecc-groups-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-ike-ecc-groups (ref. 'ECC-GR') ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) -- Possible downref: Normative reference to a draft: ref. 'EPKIX' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul N. Fahn 2 draft-ietf-ipsec-ike-auth-ecdsa-00.txt Certicom Corp. 3 8 March, 2000 4 Expires: 8 September 2000 6 IKE Authentication Using ECDSA 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its 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 material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document describes how the Elliptic Curve Digital Signature 30 Algorithm (ECDSA) may be used as the authentication method within 31 the Internet Key Exchange (IKE) protocol. ECDSA provides 32 authentication and non-repudiation with benefits of computational 33 efficiency, small signature sizes, and minimal bandwidth, compared 34 to other available digital signature methods. This document adds 35 ECDSA capability to IKE without introducing any changes to existing 36 IKE operation. 38 1. Introduction 40 The Internet Key Exchange, or IKE [RFC2409, IKE], is a key agreement 41 and security negotiation protocol; it is used for key establishment in 42 IPSec. In Phase 1 of IKE, both parties must authenticate each other 43 using a negotiated authentication method. One option for the 44 authentication method is digital signatures using public key 45 cryptography. Currently, there are two digital signature methods 46 defined for use within Phase 1: RSA signatures and DSA (DSS) 47 signatures. This document introduces ECDSA signatures as a third 48 method. 50 For any given level of security, ECDSA signatures are smaller than RSA 51 signatures and ECDSA keys require less bandwidth than DSA keys; there 52 are also advantages of computational speed and efficiency in many 53 settings. Additional efficiency may be gained by simultaneously using 54 ECDSA for IKE authentication and using elliptic curve groups for the 55 IKE key exchange. Implementers of IPSec and IKE may therefore find it 56 desirable to use ECDSA as the Phase 1 authentication method. 58 2. ECDSA 60 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic 61 curve analogue of the DSA (also called DSS) signature method 62 [FIPS-186]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is 63 defined in the ANSI X9.62 standard [X9.62]; a compatible 64 specification, along with test vectors, can be found in the documents 65 of the Standards for Efficient Cryptography Group at 66 . A profile for the use of ECDSA in X.509 67 certificates [EPKIX] describes the means to carry ECDSA keys in X.509 68 certificates. 70 ECDSA signatures are smaller than RSA signatures of similar 71 cryptographic strength; see [KEYS] for a security analysis of key 72 sizes across public key algorithms. ECDSA public keys (and 73 certificates) are smaller than similar strength DSA keys, resulting in 74 improved communications efficiency. Furthermore, on many platforms 75 ECDSA operations can be computed faster than similar strength RSA or 76 DSA operations. These advantages of signature size, bandwidth, and 77 computational efficiency make ECDSA an attractive choice for many IKE 78 implementions. 80 Recommended elliptic curve domain parameters for use with ECDSA are 81 given in [SEC2]. A subset of these are recommended in [ECC-GR] for use 82 in the IKE key exchange. 84 Like DSA, ECDSA incorporates the use of a hash function; currently, 85 the only hash function defined for use with ECDSA is the SHA-1 message 86 digest algorithm [FIPS-180]. 88 3. Specifying ECDSA within IKE 90 The IKE key negotiation protocol consists of two phases, Phase 1 and 91 Phase 2. Within Phase 1, the two negotiating parties authenticate each 92 other, using either pre-shared keys, digital signatures, or public-key 93 encryption. For digital signatures and public-key encryption methods, 94 there are multiple options. The authentication method is specified as 95 an attribute in the negotiated Phase 1 Security Association (SA). 97 Until now, there have been a total of seven specific authentication 98 methods in Phase 1. We now add an eighth option: ECDSA signatures, 99 specified by attribute value 8 in the SA. The new list of 100 IANA-assigned attribute numbers for Phase 1 authentication is: 102 - Authentication Method 103 pre-shared key 1 104 DSS signatures 2 105 RSA signatures 3 106 Encryption with RSA 4 107 Revised encryption with RSA 5 108 Encryption with El-Gamal 6 109 Revised encryption with El-Gamal 7 110 ECDSA signatures 8 112 values 9-65000 are reserved to IANA. Values 65001-65535 are for 113 private use among mutually consenting parties. 115 Phase 1 can be either Main Mode or Agressive Mode. The use and 116 specification of ECDSA signatures as the authentication method applies 117 to both modes. The sequence of Phase 1 message payloads is the same 118 with ECDSA signatures as with DSS or RSA signatures. 120 When ECDSA is used in IKE, the signature payload shall contain an 121 encoding of the computed signature, consisting of a pair of integers r 122 and s, encoded using the ASN.1 syntax "ECDSA-Sig-Value" as specified 123 in ANSI X9.62 [X9.62] and PKIX [EPKIX]. 125 Note also that, like the other digital signature methods, ECDSA 126 authentication requires the parties to know and trust each other's 127 public key. This can be done by exchanging certificates, possibly 128 within the Phase 1 negotiation, if the public keys of the parties are 129 not already known to each other. The use of Internet X.509 public key 130 infrastructure certificates [RFC 2459] is recommended; the 131 representation of ECDSA keys in X.509 certificates is specified in 132 [EPKIX]. 134 Since ECDSA requires the use of the SHA-1 hash function, 135 implemententers may find it convenient to specify SHA-1 as the value 136 of the hash algorithm attribute when using ECDSA as the authentication 137 method. Implementers may also find it convenient to use ECDSA 138 authentication in conjunction with an elliptic curve group for the IKE 139 Diffie-Hellman key agreement; see [ECC-GR] for specific curves for the 140 key agreement. 142 Security Considerations 144 Implementors should ensure that appropriate security measures are in 145 place when they deploy ECDSA within IKE. In particular, the security 146 of ECDSA requires the careful selection of both key sizes and elliptic 147 curve domain parameters. Selection guidelines for these parameters and 148 some specific recommended curves that are considered safe are provided 149 in [X9.62], [NIST-ECC], and [SEC2]. 151 Intellectual Property Rights 153 To be provided. 155 [NOTE: The readers should be aware of the possibility that 156 implementation of this draft may require use of inventions covered by 157 patent rights.] 159 Acknowledgments 161 The author would like to thank Simon Blake-Wilson, Prakash Panjwani, 162 and Paul Lambert for their comments and suggestions. 164 References 166 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange", 167 draft-ietf-ipsec-ike-01.txt, May 1999. 169 [RFC2409] Harkins, D. and Carrel, D., "The Internet Key Exchange" 170 (RFC 2409). November, 1998. 172 [X9.62] American National Standards Institute. ANSI X9.62-1998, 173 "Public Key Cryptography for the Financial Services 174 Industry: The Elliptic Curve Digital Signature 175 Algorithm". January, 1999. 177 [KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic 178 Key Sizes", October 1999. Presented at Public Key 179 Cryptography Conference, Melbourne, Australia, January, 180 2000. Available at . 182 [FIPS-180] Federal Information Processing Standards Publication 183 (FIPS PUB) 180-1, "Secure Hash Standard", April 17, 184 1995. 186 [FIPS-186] Federal Information Processing Standards Publication 187 (FIPS PUB) 186, "Digital Signature Standard", May 19, 188 1994. 190 [NIST-ECC] National Institute for Standards and Technology, 191 "Recommended Elliptic Curves for Federal Government Use", 192 July 1999, 194 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 195 Elliptic Curve Cryptography", Version 0.5, September, 196 1999. 198 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 199 Recommended Elliptic Curve Domain Parameters", 200 Version 0.6, October, 1999. 202 [ECC-GR] Panjwani, P. and Poeluev, Y., "Additional ECC Groups for 203 IKE", draft-ietf-ipsec-ike-ecc-groups-01.txt. September, 204 1999. 206 [RFC 2459] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 207 Public Key Infrastructure: Certificate and CRL Profile", 208 January, 1999. 210 [EPKIX] Bassham, L., Johnson, D., and Polk, W., "Representation of 211 Elliptic Curve Digital Signature Algorithm (ECDSA) Keys 212 and Signatures in Internet X.509 Public Key Infrastructure 213 Certificates", draft-ietf-pkix-ipki-ecdsa-02.txt. October, 214 1999. 216 Author's Address 218 Paul Fahn 219 Certicom Corp. 220 25801 Industrial Blvd. 221 Hayward, CA 94545 223 e-mail: pfahn@certicom.com 225 Full Copyright Statement 227 Copyright (C) The Internet Society (1999). All Rights Reserved. 229 This document and translations of it may be copied and furnished to 230 others, and derivative works that comment on or otherwise explain it 231 or assist in its implementation may be prepared, copied, published 232 and distributed, in whole or in part, without restriction of any 233 kind, provided that the above copyright notice and this paragraph are 234 included on all such copies and derivative works. However, this 235 document itself may not be modified in any way, such as by removing 236 the copyright notice or references to the Internet Society or other 237 Internet organizations, except as needed for the purpose of 238 developing Internet standards in which case the procedures for 239 copyrights defined in the Internet Standards process must be 240 followed, or as required to translate it into languages other than 241 English. 243 The limited permissions granted above are perpetual and will not be 244 revoked by the Internet Society or its successors or assigns. 246 This document and the information contained herein is provided on an 247 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 248 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 249 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 250 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 251 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.