idnits 2.17.1 draft-ietf-ipsec-ikev2-auth-ecdsa-01.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 218. ** 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 (May 27, 2005) is 6909 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 70, but not defined == Unused Reference: 'IANA' is defined on line 160, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2' -- Duplicate reference: RFC3279, mentioned in 'RFC-3280', was also mentioned in 'RFC-3279'. Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 November 27, 2005 May 27, 2005 5 IKEv2 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 protocol, version 2 (IKEv2). ECDSA may 35 provide benefits including computational efficiency, small signature 36 sizes, and minimal bandwidth, compared to other available digital 37 signature methods. This document adds ECDSA capability to IKEv2 38 without introducing any changes to existing IKEv2 operation. 40 1. Introduction 42 The Internet Key Exchange version 2, or IKEv2 [IKEv2], is a key 43 agreement and security negotiation protocol; it is used for key 44 establishment in IPSec. In the authentication exchange IKE_AUTH of 45 IKEv2, both parties must authenticate each other using a negotiated 46 authentication method. The defined methods are as follows: 48 RSA Digital Signature 1 49 Shared Key Message Integrity Code 2 50 DSS Digital Signature 3 52 The numbers corresponding to each method are used to identify the 53 method in the authentication payload ([IKEv2], sect. 3.8). This 54 draft defines a fourth option: 56 ECDSA Digital Signature 4 58 For any given level of security against the best attacks known, ECDSA 59 signatures are smaller than RSA signatures and ECDSA keys require 60 less bandwidth than DSA keys; there are also advantages of 61 computational speed and efficiency in many settings. Additional 62 efficiency may be gained by simultaneously using ECDSA for IKEv2 63 authentication and using elliptic curve groups for the IKEv2 key 64 exchange. Implementers of IPSec and IKEv2 may therefore find it 65 desirable to use ECDSA as the IKE_AUTH authentication method. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. ECDSA 73 The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 74 elliptic curve analogue of the DSA (DSS) signature method [DSS]. 75 It is defined in the ANSI X9.62 standard [X9.62]. Other compatible 76 specifications include FIPS 186-2 [DSS], IEEE 1363 [IEEE-1363], 77 IEEE 1363A [IEEE-1363A], and SEC1 [SEC1]. 79 Like DSA, ECDSA incorporates the use of a hash function. [SHS] 80 specifies hash functions that are appropriate for use with ECDSA. 81 Implementations of IKEv2 using ECDSA SHOULD use one of these hash 82 functions. 84 ECDSA signatures are smaller than RSA signatures of similar 85 cryptographic strength. ECDSA public keys (and certificates) are 86 smaller than similar strength DSA keys, resulting in improved 87 communications efficiency. Furthermore, on many platforms ECDSA 88 operations can be computed more quickly than similar strength RSA 89 or DSA operations (see [LV] for a security analysis of key sizes 90 across public key algorithms). These advantages of signature size, 91 bandwidth, and computational efficiency may make ECDSA an 92 attractive choice for many IKE implementations. 94 Recommended elliptic curve domain parameters for use with ECDSA are 95 given in FIPS 186-2 [DSS], ANSI X9.62 [X9.62], and SEC 2 [SEC2]. 96 Implementations of IKEv2 using ECDSA MAY use one of these domain 97 parameters. A subset of these parameters are recommended in 98 [IKEv2-ECC] for use in the IKEv2 key exchange. These parameters 99 MAY be used for ECDSA as well. 101 3. Specifying ECDSA within IKEv2 103 The sequence of IKE_AUTH message payloads is the same with ECDSA 104 signatures as with DSS or RSA signatures. 106 When ECDSA is used in IKEv2, the signature payload SHALL contain an 107 encoding of the computed signature, consisting of a pair of integers 108 r and s, encoded as a byte string using the ASN.1 syntax 109 "ECDSA-Sig-Value" with DER encoding rules as specified in ANSI X9.62 110 [X9.62]. 112 As with the other digital signature methods, ECDSA authentication 113 requires the parties to know and trust each other's public key. 114 This can be done by exchanging certificates if the public keys of 115 the parties are not already known to each other. The use of 116 Internet X.509 public key infrastructure certificates [RFC-3280] is 117 recommended; the representation of ECDSA keys in X.509 certificates 118 is specified in [RFC-3279]. This representation SHOULD be used if 119 X.509 certificates are used. The certificates MAY be exchanged as 120 part of the IKE_AUTH exchange (see [IKEv2], sect. 2.15). 122 Implemententers may find it convenient, when using ECDSA as the 123 authentication method, to specify the hash used by ECDSA as the value 124 of the hash algorithm attribute. Implementers may also find it 125 convenient to use ECDSA authentication in conjunction with an 126 elliptic curve group for the IKEv2 Diffie-Hellman key agreement; see 127 [IKEv2-ECC] for some specific curves for the key agreement. 129 4. Security Considerations 131 Implementors should ensure that appropriate security measures are in 132 place when they deploy ECDSA within IKEv2. In particular, the 133 security of ECDSA requires the careful selection of both key sizes 134 and elliptic curve domain parameters. Selection guidelines for these 135 parameters and some specific recommended curves that are considered 136 safe are provided in ANSI X9.62 [X9.62], FIPS 186-2 [DSS], and SEC 2 137 [SEC2]. 139 5. IANA Considerations 141 This document has no actions for IANA. 143 6. References 145 6.1 Normative 147 [IKEv2] C. Kaufman, Internet Key Exchange (IKEv2) Protocol, 2004, 148 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-17.txt 150 [X9.62] American National Standards Institute, ANS X9.62-1998: 151 Public Key Cryptography for the Financial Services Industry: The 152 Elliptic Curve Digital Signature Algorithm. January 1999. 154 6.2 Informative 156 [DSS] U.S. Department of Commerce/National Institute of Standards 157 and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2, 158 January 2000. (http://csrc.nist.gov/publications/fips/index.html) 160 [IANA] Internet Assigned Numbers Authority, Internet Key Exchange 161 (IKE) Attributes. (http://www.iana.org/assignments/ipsec-registry) 163 [IEEE-1363] Institute of Electrical and Electronics Engineers. 164 IEEE 1363-2000, Standard for Public Key Cryptography. 165 (http://grouper.ieee.org/groups/1363/index.html) 167 [IEEE-1363A] Institute of Electrical and Electronics Engineers. 168 IEEE 1363A-2004, Standard for Public Key Cryptography - 169 Amendment 1: Additional Techniques. 170 (http://grouper.ieee.org/groups/1363/index.html) 172 [IKEv2-ECC] J. Solinas, ECC Groups For IKEv2, 2005. 173 (draft-ietf-ipsec-ikev2-ecc-groups-01.txt) 175 [LV] A. Lenstra and E. Verheul, "Selecting Cryptographic Key 176 Sizes", Journal of Cryptology 14 (2001), pp. 255-293. 178 [RFC-3279] Bassham, L., Housley, R., and Polk, W., RFC 3279, 179 Algorithms and Identifiers for the Internet X.509 Public Key 180 Infrastructure Certificate and Certificate Revocation List (CRL) 181 Profile, 2002. (http://www.ietf.org/rfc/rfc3279.txt) 183 [RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, RFC 3280, 184 Internet X.509 Public Key Infrastructure Certificate and 185 Certificate Revocation List (CRL) Profile, 2002. 186 (http://www.ietf.org/rfc/rfc3279.txt) 188 [SEC1] Standards for Efficient Cryptography Group. SEC 1 - Elliptic 189 Curve Cryptography, v. 1.0, 2000. (http://www.secg.org) 191 [SEC2] Standards for Efficient Cryptography Group. SEC 2 - 192 Recommended Elliptic Curve Domain Parameters, v. 1.0, 2000. 193 (http://www.secg.org) 195 [SHS] FIPS 180-2, "Secure Hash Standard", National Institute of 196 Standards and Technology, 2002. 198 7. Author's Address 200 Jerome A. Solinas 201 National Security Agency 202 jasolin@orion.ncsc.mil 204 Comments are solicited and should be addressed to the author. 206 Copyright (C) The Internet Society (2005). 208 This document is subject to the rights, licenses and restrictions 209 contained in BCP 78, and except as set forth therein, the authors 210 retain all their rights. 212 This document and the information contained herein are provided on an 213 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 214 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 215 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 216 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 217 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 220 Expires November 27, 2005