idnits 2.17.1 draft-cheneau-csi-ecc-sig-agility-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 108: '...subjectPublicKey MUST be formatted as ...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2010) is 5056 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) == Unused Reference: 'RFC2460' is defined on line 196, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 203, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CGA & SEND maintenance T. Cheneau 3 Internet-Draft M. Laurent 4 Updates: RFC3971,RFC3972 TMSP 5 (if approved) S. Shen 6 Expires: December 18, 2010 Huawei 7 M. Vanderveen 8 Qualcomm 9 June 16, 2010 11 ECC public key and signature support in Cryptographically Generated 12 Addresses (CGA) and in the Secure Neighbor Discovery (SEND) 13 draft-cheneau-csi-ecc-sig-agility-02 15 Abstract 17 This draft describes a mechanism to deploy Elliptic Curve 18 Cryptography (ECC) alongside with Cryptographically Generated 19 Addresses (CGA) and the Secure Neighbor Discovery (SEND). This 20 document provides basic skeleton to integrate new signature 21 algorithms in CGA and SEND. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 18, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Choice of Elliptic Curve . . . . . . . . . . . . . . . . . . . 4 59 3. Using ECC in CGA . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Signature Type Identifier for ECC . . . . . . . . . . . . . . 6 61 5. Using ECDSA with Universal Signature Option . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Appendix A. On the number of Universal Signature Options 68 supported per CGA . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Note for future work . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The usage scenarios associated with neighbor discovery have recently 75 been extended to include environments with mobile or nomadic nodes. 76 Many of these nodes have limited battery power and computing 77 resources. Therefore, heavy public key signing algorithms like RSA 78 are not feasible to support on such constrained nodes. Fortunately, 79 more lightweight yet secure signing algorithms do exist and have been 80 standardized, e.g. Elliptic Curve based algorithms. 82 It is then a worthwhile goal to extend secure neighbor discovery to 83 support this signing algorithm. 85 The aim of this memo is to outline options for allowing Elliptic 86 Curve Digital Signature Algorithm for nodes configured to perform 87 secure neighbor discovery operations. The present document exposes 88 how to use and deploy Elliptic Curve Cryptography in [RFC3972] and 89 [cheneau-csi-send-sig-agility]. It should be noted that the latter 90 document has impacts on existing specification [RFC3971]. 92 2. Choice of Elliptic Curve 94 This document follows NIST's recommendation on the usage of various 95 Elliptic Curves as per [FIPS-186-3]. For the sake of simplicity, 96 this document only describes the use of three proposed curves, namely 97 curve P-256 (aka secp256r1), curve P-384 (aka secp384r1) and curve 98 P-521 (aka secp521r1). 100 3. Using ECC in CGA 102 The CGA generation and verification processes remain unmodified from 103 the processes described in [RFC3972]. However, we extend section 3 104 of [RFC3972], as it contains RSA specific text. We add that, when 105 ECDSA is used, the AlgorithmIdentifier, contained in ASN.1 structure 106 of type SubjectPublicKeyInfo, must be the (unrestricted) id- 107 ecPublicKey algorithm identifier, which is OID 1.2.840.10045.2.1, and 108 the subjectPublicKey MUST be formatted as an ECC Public Key, 109 specified in Section 2.2 of [RFC5480]. 111 Note that the ECC key lengths are determined by the namedCurves 112 parameter stored in ECParameters field of the AlgorithmIdentifier. 114 4. Signature Type Identifier for ECC 116 In the document [cheneau-csi-send-sig-agility], a field named 117 Signature Type Identifier is used by the Supported Signature 118 Algorithm Option and the Universal Signature Option (that replaces 119 the RSA Signature Option). This field indicates the Signature 120 Algorithm available on the node to generate or verify the Digital 121 Signature field of the Universal Signature Option. 123 This document describes new values for three different signature 124 algorithms. These values are extracted from the IANA-defined numbers 125 for the IKEv2 protocol, i.e. IANA registry named "IKEv2 126 Authentication Method" and are the following: 128 o Value 9 is ECDSA with SHA-256 on the P-256 curve 130 o Value 10 is ECDSA with SHA-384 on the P-384 curve 132 o Value 11 is ECDSA with SHA-512 on the P-521 curve 134 5. Using ECDSA with Universal Signature Option 136 The document [cheneau-csi-send-sig-agility] proposes the Universal 137 Signature Option (extended from the RSA Signature Option of 138 [RFC3971]). This option adds a new Signature Type Identifier field 139 that identifies the signature algorithm used during the generation of 140 the digital signature field. 142 When the value of the Signature Type Identifier field is 9, 10 or 11, 143 this Digital Signature field is computed and verified using the ECDSA 144 signature algorithm (as defined on [SEC1]) and hash function 145 corresponding to the Signature Type Identifier field. The data on 146 which the signature is performed are described in 147 [cheneau-csi-send-sig-agility]. 149 6. Security Considerations 151 This memo defines the usage of the ECC Public Key and Signature 152 Algorithm in CGA and SEND. Table 1 (from [SP800-57]), presents a 153 comparison between the length of the RSA keys and their equivalent 154 (security-wise) ECC keys. 156 +-----------------------+-----------------------+ 157 | RSA key length (bits) | ECC key length (bits) | 158 +-----------------------+-----------------------+ 159 | 3072 | 256 | 160 | | | 161 | 7680 | 384 | 162 | | | 163 | 15360 | 512 | 164 +-----------------------+-----------------------+ 166 Table 1: Strength equivalence between Elliptic Curve and RSA Public 167 Keys 169 7. IANA Considerations 171 This document does not request any new IANA allocations. 173 8. References 175 8.1. Normative References 177 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 178 RFC 3972, March 2005. 180 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 181 Neighbor Discovery (SEND)", RFC 3971, March 2005. 183 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 184 "Elliptic Curve Cryptography Subject Public Key 185 Information", RFC 5480, March 2009. 187 [cheneau-csi-send-sig-agility] 188 Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, 189 "Signature Algorithm Agility in the Secure Neighbor 190 Discovery (SEND) Protocol", 191 draft-cheneau-csi-send-sig-agility-02 (work in progress), 192 June 2010. 194 8.2. Informative References 196 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 197 (IPv6) Specification", RFC 2460, December 1998. 199 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 200 Discovery (ND) Trust Models and Threats", RFC 3756, 201 May 2004. 203 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 204 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 205 September 2007. 207 [FIPS.180-2] 208 National Institute of Standards and Technology, "Secure 209 Hash Standard", FIPS PUB 180-2, August 2002, . 212 [FIPS-186-3] 213 National Institute of Standards and Technology, "Digital 214 Signature Standard", FIPS PUB 186-3, June 2009. 216 [SP800-57] 217 National Institute of Standards and Technology (NIST), 218 "Special Publication 800-57: Recommendation for Key 219 Management - Part 1 (Revised)", SP SP 800-57, March 2007. 221 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 222 Elliptic Curve Cryptography", September 2000, 223 . 225 Appendix A. On the number of Universal Signature Options supported per 226 CGA 228 +--------------------------+----------------------------------------+ 229 | Name of the elliptic | Size of the DER-encoded Public Key | 230 | curve | (bytes) | 231 +--------------------------+----------------------------------------+ 232 | P-256 | 88 | 233 | | | 234 | P-384 | 120 | 235 | | | 236 | P-521 | 158 | 237 +--------------------------+----------------------------------------+ 239 Table 2: Common sizes for DER-encoded ECC Public Key 241 +-----------------------+-------------------------------------------+ 242 | Name of the elliptic | Size of the Digital Signature field | 243 | curve | (without padding) | 244 +-----------------------+-------------------------------------------+ 245 | P-256 | 71 | 246 | | | 247 | P-384 | 104 | 248 | | | 249 | P-521 | 139 | 250 +-----------------------+-------------------------------------------+ 252 Table 3: Common sizes of the Digital Signature field when using ECDSA 253 (+ DER encoding) 255 Appendix A of document [cheneau-csi-send-sig-agility] emphasises the 256 impact of the Public Key size and the number of Universal Signature 257 Options on size of the final message. This Appendix proposes to 258 extend previous document and to add values for ECC. Table 2 provides 259 size for the commonly used DER-encoded ECC Public Keys. Table 3 260 presents common sizes for Digital Signature field when using ECDSA. 262 Reusing the value computed in [cheneau-csi-send-sig-agility], we 263 deduce that a Router Advertisement carrying a Prefix Information 264 Option and a Source Link-Layer Option sent from a CGA formed with a 265 P-256 EC Public and protected by a corresponding ECDSA signature is 266 328 bytes long. This can be compared with the same message using a 267 CGA carrying a 1024 bits RSA whose length is 456 bytes. 269 Appendix B. Note for future work 271 When specifying a new type of Signature Algorithm, a new draft may 272 reuse the skeleton of this document by replacing ECC/ECDSA by the 273 appropriate terminology. In this case, the new draft should include 274 an appendix similar to Appendix A for a comparison with already 275 specified signature algorithms. 277 Authors' Addresses 279 Tony Cheneau 280 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 281 9 rue Charles Fourier 282 Evry 91011 283 France 285 Email: tony.cheneau@it-sudparis.eu 287 Maryline Laurent 288 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 289 9 rue Charles Fourier 290 Evry 91011 291 France 293 Email: maryline.laurent@it-sudparis.eu 295 Sean Shen 296 Huawei 297 4, South 4th Street, Zhongguancun 298 Beijing 100190 299 P.R. China 301 Email: sean.s.shen@gmail.com 303 Michaela Vanderveen 304 Qualcomm 306 Email: mvandervn@gmail.com