idnits 2.17.00 (12 Aug 2021) /tmp/idnits53289/draft-ietf-ipsec-ike-auth-ecdsa-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 222. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- The document date (March 31, 2005) is 6259 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: 'RFC2119' is mentioned on line 64, but not defined ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Duplicate reference: RFC3279, mentioned in 'RFC-3280', was also mentioned in 'RFC-3279'. == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-ike-ecc-groups-05 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSec Working Group J. Solinas, NSA 2 INTERNET-DRAFT 3 Expires October 2, 2005 March 31, 2005 5 IKE Authentication Using ECDSA 6 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document describes how the Elliptic Curve Digital Signature 33 Algorithm (ECDSA) may be used as the authentication method within 34 the Internet Key Exchange (IKE) protocol. ECDSA may provide benefits 35 including computational efficiency, small signature sizes, and 36 minimal bandwidth compared to other available digital signature 37 methods. This document adds ECDSA capability to IKE without 38 introducing any changes to existing IKE operation. 40 1. Introduction 42 The Internet Key Exchange, or IKE [IKE], is a key agreement and 43 security negotiation protocol; it is used for key establishment in 44 IPSec. In Phase 1 of IKE, both parties must authenticate each other 45 using a negotiated authentication method. One option for the 46 authentication method is digital signatures using public key 47 cryptography. Currently, there are two digital signature methods 48 defined for use within Phase 1: RSA signatures and DSA (DSS) 49 signatures. This document introduces ECDSA signatures as a third 50 method. 52 For any given level of security against the best attacks known, ECDSA 53 signatures are smaller than RSA signatures and ECDSA keys require 54 less bandwidth than DSA keys; there are also advantages of 55 computational speed and efficiency in many settings. Additional 56 efficiency may be gained by simultaneously using ECDSA for IKE 57 authentication and using elliptic curve groups for the IKE key 58 exchange. Implementers of IPSec and IKE may therefore find it 59 desirable to use ECDSA as the Phase 1 authentication method. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. ECDSA 67 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 68 elliptic curve analogue of the DSA (DSS) signature method [DSS]. It 69 is defined in the ANSI X9.62 standard [X9.62]. Other compatible 70 specifications include FIPS 186-2 [DSS], IEEE 1363 [IEEE-1363], IEEE 71 1363A [IEEE-1363A], and SEC1 [SEC1]. 73 Like DSA, ECDSA incorporates the use of a hash function. [SHS] 74 specifies hash functions that are appropriate for use with ECDSA. 75 Implementations of IKE using ECDSA SHOULD use one of these hash 76 functions. 78 ECDSA signatures are smaller than RSA signatures of similar 79 cryptographic strength. ECDSA public keys (and certificates) are 80 smaller than similar strength DSA keys, resulting in improved 81 communications efficiency. Furthermore, on many platforms ECDSA 82 operations can be computed more quickly than similar strength RSA or 83 DSA operations (see [LV] for a security analysis of key sizes across 84 public key algorithms). These advantages of signature size, 85 bandwidth, and computational efficiency may make ECDSA an attractive 86 choice for many IKE implementations. 88 Recommended elliptic curve domain parameters for use with ECDSA are 89 given in FIPS 186-2 [DSS], ANSI X9.62 [X9.62], and SEC 2 [SEC2]. 91 Implementations of IKE using ECDSA MAY use one of these domain 92 parameters. A subset of these parameters are recommended in 93 [IKE-ECP] for use in the IKE key exchange. These parameters MAY 94 be used for ECDSA as well. 96 3. Specifying ECDSA within IKE 98 The IKE key negotiation protocol consists of two phases, Phase 1 and 99 Phase 2. Within Phase 1, the two negotiating parties authenticate 100 each other, using either pre-shared keys, digital signatures, or 101 public-key encryption. For digital signatures and public-key 102 encryption methods, there are multiple options. The IANA-assigned 103 attribute number for Phase 1 authentication using ECDSA is 8 (see 104 [IANA]). 106 Phase 1 can be either Main Mode or Aggressive Mode. The use and 107 specification of ECDSA signatures as the authentication method 108 applies to both modes. The sequence of Phase 1 message payloads is 109 the same with ECDSA signatures as with DSS or RSA signatures. 111 When ECDSA is used in IKE, the signature payload SHALL contain an 112 encoding of the computed signature, consisting of a pair of integers 113 r and s, encoded as a byte string using the ASN.1 syntax 114 "ECDSA-Sig-Value" with DER encoding rules as specified in ANSI X9.62 115 [X9.62]. 117 As with the other digital signature methods, ECDSA authentication 118 requires the parties to know and trust each other's public key. This 119 can be done by exchanging certificates, possibly within the Phase 1 120 negotiation, if the public keys of the parties are not already known 121 to each other. The use of Internet X.509 public key infrastructure 122 certificates [RFC-3280] is recommended; the representation of ECDSA 123 keys in X.509 certificates is specified in [RFC-3279]. This 124 representation SHOULD be used if X.509 certificates are used. 126 Implemententers may find it convenient, when using ECDSA as the 127 authentication method, to specify the hash used by ECDSA as the 128 value of the hash algorithm attribute. Implementers may also find 129 it convenient to use ECDSA authentication in conjunction with an 130 elliptic curve group for the IKE Diffie-Hellman key agreement; see 131 [IKE-ECP] for some specific curves for the key agreement. 133 4. Security Considerations 135 Implementors should ensure that appropriate security measures are in 136 place when they deploy ECDSA within IKE. In particular, the security 137 of ECDSA requires the careful selection of both key sizes and 138 elliptic curve domain parameters. Selection guidelines for these 139 parameters and some specific recommended curves that are considered 140 safe are provided in ANSI X9.62 [X9.62], FIPS 186-2 [DSS], and SEC 2 141 [SEC2]. 143 5. IANA Considerations 145 This document has no actions for IANA. 147 6. References 149 6.1 Normative 151 [IKE] D. Harkins and D. Carrel, The Internet Key Exchange, RFC 2409, 152 November 1998. 154 [RFC-3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, 155 Algorithms and Identifiers for the Internet X.509 Public Key 156 Infrastructure Certificate and Certificate Revocation List (CRL) 157 Profile, 2002. (http://www.ietf.org/rfc/rfc3279.txt) 159 [RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, RFC 3280, 160 Internet X.509 Public Key Infrastructure Certificate and 161 Certificate Revocation List (CRL) Profile, 2002. 162 (http://www.ietf.org/rfc/rfc3279.txt) 164 [X9.62] American National Standards Institute, ANS X9.62-1998: 165 Public Key Cryptography for the Financial Services Industry: The 166 Elliptic Curve Digital Signature Algorithm. January 1999. 168 6.2 Informative 170 [DSS] U.S. Department of Commerce/National Institute of Standards 171 and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2, 172 January 2000. (http://csrc.nist.gov/publications/fips/index.html) 174 [IANA] Internet Assigned Numbers Authority, Internet Key Exchange 175 (IKE) Attributes. (http://www.iana.org/assignments/ipsec-registry) 177 [IEEE-1363] Institute of Electrical and Electronics Engineers. 178 IEEE 1363-2000, Standard for Public Key Cryptography. 179 (http://grouper.ieee.org/groups/1363/index.html) 181 [IEEE-1363A] Institute of Electrical and Electronics Engineers. 182 IEEE 1363A-2004, Standard for Public Key Cryptography - 183 Amendment 1: Additional Techniques. 184 (http://grouper.ieee.org/groups/1363/index.html) 186 [IKE-ECP] J. Solinas, ECP Groups For IKE, 2005. 187 (draft-ietf-ipsec-ike-ecc-groups-05.txt) 189 [LV] A. Lenstra and E. Verheul, "Selecting Cryptographic Key 190 Sizes", Journal of Cryptology 14 (2001), pp. 255-293. 192 [SEC1] Standards for Efficient Cryptography Group. SEC 1 - Elliptic 193 Curve Cryptography, v. 1.0, 2000. (http://www.secg.org) 195 [SEC2] Standards for Efficient Cryptography Group. SEC 2 - 196 Recommended Elliptic Curve Domain Parameters, v. 1.0, 2000. 197 (http://www.secg.org) 199 [SHS] FIPS 180-2, "Secure Hash Standard", National Institute of 200 Standards and Technology, 2002. 202 7. Author's Address 204 Jerome A. Solinas 205 National Security Agency 206 jsolinas@orion.ncsc.mil 208 Comments are solicited and should be addressed to the author. 210 Copyright (C) The Internet Society (2005). 212 This document is subject to the rights, licenses and restrictions 213 contained in BCP 78, and except as set forth therein, the authors 214 retain all their rights. 216 This document and the information contained herein are provided on an 217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 224 Expires October 2, 2005