idnits 2.17.1 draft-cheneau-csi-ecc-sig-agility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 114: '...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 (November 22, 2009) is 5267 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 202, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 209, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 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: May 26, 2010 Huawei 7 M. Vanderveen 8 Qualcomm 9 November 22, 2009 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-01 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 to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 26, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Choice of Elliptic Curve . . . . . . . . . . . . . . . . . . . 4 65 3. Using ECC in CGA . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Signature Type Identifier for ECC . . . . . . . . . . . . . . 6 67 5. Using ECDSA with Universal Signature Option . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Appendix A. On the number of Universal Signature Options 74 supported per CGA . . . . . . . . . . . . . . . . . . 12 75 Appendix B. Note for future work . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The usage scenarios associated with neighbor discovery have recently 81 been extended to include environments with mobile or nomadic nodes. 82 Many of these nodes have limited battery power and computing 83 resources. Therefore, heavy public key signing algorithms like RSA 84 are not feasible to support on such constrained nodes. Fortunately, 85 more lightweight yet secure signing algorithms do exist and have been 86 standardized, e.g. Elliptic Curve based algorithms. 88 It is then a worthwhile goal to extend secure neighbor discovery to 89 support this signing algorithm. 91 The aim of this memo is to outline options for allowing Elliptic 92 Curve Digital Signature Algorithm for nodes configured to perform 93 secure neighbor discovery operations. The present document exposes 94 how to use and deploy Elliptic Curve Cryptography in [RFC3972] and 95 [cheneau-csi-send-sig-agility]. It should be noted that the latter 96 document has impacts on existing specification [RFC3971]. 98 2. Choice of Elliptic Curve 100 This document follows NIST's recommendation on the usage of various 101 Elliptic Curves as per [FIPS-186-3]. For the sake of simplicity, 102 this document only describes the use of three proposed curves, namely 103 curve P-256 (aka secp256r1), curve P-384 (aka secp384r1) and curve 104 P-521 (aka secp521r1). 106 3. Using ECC in CGA 108 The CGA generation and verification processes remain unmodified from 109 the processes described in [RFC3972]. However, we extend section 3 110 of [RFC3972], as it contains RSA specific text. We add that, when 111 ECDSA is used, the AlgorithmIdentifier, contained in ASN.1 structure 112 of type SubjectPublicKeyInfo, must be the (unrestricted) id- 113 ecPublicKey algorithm identifier, which is OID 1.2.840.10045.2.1, and 114 the subjectPublicKey MUST be formatted as an ECC Public Key, 115 specified in Section 2.2 of [RFC5480]. 117 Note that the ECC key lengths are determined by the namedCurves 118 parameter stored in ECParameters field of the AlgorithmIdentifier. 120 4. Signature Type Identifier for ECC 122 In the document [cheneau-csi-send-sig-agility], a field named 123 Signature Type Identifier is used by the Supported Signature 124 Algorithm Option and the Universal Signature Option (that replaces 125 the RSA Signature Option). This field indicates the Signature 126 Algorithm available on the node to generate or verify the Digital 127 Signature field of the Universal Signature Option. 129 This document describes new values for three different signature 130 algorithms. These values are extracted from the IANA-defined numbers 131 for the IKEv2 protocol, i.e. IANA registry named "IKEv2 132 Authentication Method" and are the following: 134 o Value 9 is ECDSA with SHA-256 on the P-256 curve 136 o Value 10 is ECDSA with SHA-384 on the P-384 curve 138 o Value 11 is ECDSA with SHA-512 on the P-521 curve 140 5. Using ECDSA with Universal Signature Option 142 The document [cheneau-csi-send-sig-agility] proposes the Universal 143 Signature Option (extended from the RSA Signature Option of 144 [RFC3971]). This option adds a new Signature Type Identifier field 145 that identifies the signature algorithm used during the generation of 146 the digital signature field. 148 When the value of the Signature Type Identifier field is 9, 10 or 11, 149 this Digital Signature field is computed and verified using the ECDSA 150 signature algorithm (as defined on [SEC1]) and hash function 151 corresponding to the Signature Type Identifier field. The data on 152 which the signature is performed are described in 153 [cheneau-csi-send-sig-agility]. 155 6. Security Considerations 157 This memo defines the usage of the ECC Public Key and Signature 158 Algorithm in CGA and SEND. Table 1 (from [SP800-57]), presents a 159 comparison between the length of the RSA keys and their equivalent 160 (security-wise) ECC keys. 162 +-----------------------+-----------------------+ 163 | RSA key length (bits) | ECC key length (bits) | 164 +-----------------------+-----------------------+ 165 | 3072 | 256 | 166 | | | 167 | 7680 | 384 | 168 | | | 169 | 15360 | 512 | 170 +-----------------------+-----------------------+ 172 Table 1: Strength equivalence between Elliptic Curve and RSA Public 173 Keys 175 7. IANA Considerations 177 This document does not request any new IANA allocations. 179 8. References 181 8.1. Normative References 183 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 184 RFC 3972, March 2005. 186 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 187 Neighbor Discovery (SEND)", RFC 3971, March 2005. 189 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 190 "Elliptic Curve Cryptography Subject Public Key 191 Information", RFC 5480, March 2009. 193 [cheneau-csi-send-sig-agility] 194 Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, 195 "Signature Algorithm Agility in the Secure Neighbor 196 Discovery (SEND) Protocol", 197 draft-cheneau-csi-send-sig-agility-01 (work in progress), 198 November 2009. 200 8.2. Informative References 202 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 203 (IPv6) Specification", RFC 2460, December 1998. 205 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 206 Discovery (ND) Trust Models and Threats", RFC 3756, 207 May 2004. 209 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 210 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 211 September 2007. 213 [FIPS.180-2] 214 National Institute of Standards and Technology, "Secure 215 Hash Standard", FIPS PUB 180-2, August 2002, . 218 [FIPS-186-3] 219 National Institute of Standards and Technology, "Digital 220 Signature Standard", FIPS PUB 186-3, June 2009. 222 [SP800-57] 223 National Institute of Standards and Technology (NIST), 224 "Special Publication 800-57: Recommendation for Key 225 Management - Part 1 (Revised)", SP SP 800-57, March 2007. 227 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 228 Elliptic Curve Cryptography", September 2000, 229 . 231 Appendix A. On the number of Universal Signature Options supported per 232 CGA 234 +--------------------------+----------------------------------------+ 235 | Name of the elliptic | Size of the DER-encoded Public Key | 236 | curve | (bytes) | 237 +--------------------------+----------------------------------------+ 238 | P-256 | 88 | 239 | | | 240 | P-384 | 120 | 241 | | | 242 | P-521 | 158 | 243 +--------------------------+----------------------------------------+ 245 Table 2: Common sizes for DER-encoded ECC Public Key 247 +-----------------------+-------------------------------------------+ 248 | Name of the elliptic | Size of the Digital Signature field | 249 | curve | (without padding) | 250 +-----------------------+-------------------------------------------+ 251 | P-256 | 71 | 252 | | | 253 | P-384 | 104 | 254 | | | 255 | P-521 | 139 | 256 +-----------------------+-------------------------------------------+ 258 Table 3: Common sizes of the Digital Signature field when using ECDSA 259 (+ DER encoding) 261 Appendix A of document [cheneau-csi-send-sig-agility] emphasises the 262 impact of the Public Key size and the number of Universal Signature 263 Options on size of the final message. This Appendix proposes to 264 extend previous document and to add values for ECC. Table 2 provides 265 size for the commonly used DER-encoded ECC Public Keys. Table 3 266 presents common sizes for Digital Signature field when using ECDSA. 268 Reusing the value computed in [cheneau-csi-send-sig-agility], we 269 deduce that a Router Advertisement carrying a Prefix Information 270 Option and a Source Link-Layer Option sent from a CGA formed with a 271 P-256 EC Public and protected by a corresponding ECDSA signature is 272 328 bytes long. This can be compared with the same message using a 273 CGA carrying a 1024 bits RSA whose length is 456 bytes. 275 Appendix B. Note for future work 277 When specifying a new type of Signature Algorithm, a new draft may 278 reuse the skeleton of this document by replacing ECC/ECDSA by the 279 appropriate terminology. In this case, the new draft should include 280 an appendix similar to Appendix A for a comparison with already 281 specified signature algorithms. 283 Authors' Addresses 285 Tony Cheneau 286 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 287 9 rue Charles Fourier 288 Evry 91011 289 France 291 Email: tony.cheneau@it-sudparis.eu 293 Maryline Laurent 294 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 295 9 rue Charles Fourier 296 Evry 91011 297 France 299 Email: maryline.laurent@it-sudparis.eu 301 Sean Shen 302 Huawei 303 4, South 4th Street, Zhongguancun 304 Beijing 100190 305 P.R. China 307 Email: sean.s.shen@gmail.com 309 Michaela Vanderveen 310 Qualcomm 312 Email: mvandervn@gmail.com