idnits 2.17.1 draft-cheneau-cga-pk-agility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 147: '... The public key MUST be formatted as ...' RFC 2119 keyword, line 150: '...rithm identifier MUST be rsaEncryption...' RFC 2119 keyword, line 151: '...d the RSA public key MUST be formatted...' RFC 2119 keyword, line 154: '... [RFC3279]. The RSA key length SHOULD be at least 384 bits....' RFC 2119 keyword, line 156: '...gorithm identifier MUST be of type id-...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2009) is 5433 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: 'RFC3971' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC4982' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC4866' is defined on line 300, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CGA & Send maintenance T. Cheneau 3 Internet-Draft M. Maknavicius 4 Expires: December 7, 2009 TMSP 5 S. Sean 6 Huawei 7 M. Vanderveen 8 Qualcomm 9 June 5, 2009 11 Support for Multiple Signature Algorithms in Cryptographically Generated 12 Addresses (CGAs) 13 draft-cheneau-cga-pk-agility-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 7, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document defines an extension field for the CGA Parameters data 52 structure specified in RFC 3972. This extension field carries a 53 Public Key that is used in Cryptographically Generated Address (CGA) 54 generation. This extension enables protocols using CGAs, such as 55 SEND, to use multiple Public Key signing algorithms and/or multiple 56 Public Keys. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Public Key extension . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Public Key extension format . . . . . . . . . . . . . . . 4 63 3. CGA Generation Process . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Consideration . . . . . . . . . . . . . . . . . . . . 9 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Cryptographically Generated Addresses (CGA) [RFC3972] have been 74 designed to provide a binding of an internet address (IPv6) to a 75 public key. A node who claims to own a particular IPv6 address, can 76 prove so in the messages (e.g. ICMP) it sends by using a digital 77 signature for authentication and integrity protection. Since the 78 IPv6 address was generated from the public key, verification of the 79 respective signature is tantamount to verification of ownership of 80 the claimed IPv6 address. 82 CGAs [RFC3972] were defined to only use RSA as the associated 83 signature algorithm. Only one RSA public key is associated with a 84 CGA and this public key is carried in the Public Key field of the CGA 85 Parameters data structure. 87 Due to the expected variations in cryptographic ability of IPv6 88 nodes, support for signature algorithm agility in CGA is desired. 89 However, since the CGA specification [RFC3972] states that SEND 90 "SHOULD" use an RSA public/private key pair, backward compatibility 91 is preserved herein. 93 A logical place for extending the CGA Parameters data structure to 94 include other types of public keys is its "extension fields". Some 95 guidance on the format of these extensions is provided in [RFC4581]. 96 One type of CGA Parameters data structure extension is defined in 97 Section 2 and this type of extension is able to carry public keys, in 98 addition to the RSA public key defined in the Public Key field of CGA 99 Parameters data structure. 101 These extensions allow new functionnalities on CGA based protocols, 102 such as the Signature Algorithm Agility in SEND 103 [cheneau-send-sig-agility]. 105 2. Public Key extension 107 This section describes an extension field that conforms to the 108 guidelines of [RFC4581]. 110 This extension allows a CGA Parameters data structure to carry public 111 keys in addition to the key in the Public Key field. This approach 112 paves the way for one CGA to possibly be associated with multiple 113 public keys. 115 This extension allows a node to select a Public Key value that is 116 different from the one in the Public Key field of the CGA Parameters 117 data structure option. This Public Key is placed in an extension 118 embedded in the Extension field of the CGA Parameters data structure, 119 described in [RFC3972]. 121 2.1. Public Key extension format 123 0 1 2 3 124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Extension Type | Extension Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | | 129 ~ Public Key ~ 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 1: Public Key extension format 135 Extension Type 137 TBA. (16-bit unsigned integer. See Section 5.) 139 Extension Length 141 The length of the Public Key field to follow, in octets. 16-bit 142 unsigned integer. 144 Public Key 146 This is a variable-length field containing the public key of the 147 sender. The public key MUST be formatted as a DER-encoded 148 [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo, 149 defined in the Internet X.509 certificate profile [RFC5280]. When 150 RSA is used, the algorithm identifier MUST be rsaEncryption, which 151 is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted 152 by using the RSAPublicKey type as specified in Section 2.3.1 of 154 [RFC3279]. The RSA key length SHOULD be at least 384 bits. 156 When ECC is used, the algorithm identifier MUST be of type id- 157 ecPublicKey (OID 1.2.840.10045.2.1), as defined in [RFC5480]. ECC 158 public key encoding is specified in this reference. Note that the 159 ECC key lengths are determined by the ECParameters field named 160 namedCurves (curves implying key length). 162 3. CGA Generation Process 164 When a node supports two or more types of signing algorithms, and is 165 able to generate two or more corresponding public keys, then it can 166 derive a single CGA using all these keys. The derivation is done 167 exactly as in [RFC3972]; one key is placed in the CGA Parameters data 168 structure "Public Key" field while the rest of the keys are placed in 169 separate extension fields. This is illustrated in Figure 2. 171 It should be noted that the type of the public key (RSA, ECC, etc.) 172 is already encoded into the "Public Key" field itself, and thus there 173 is no need to identify the public key type separately. This is due 174 to the fact that the "Public Key" field, according to [RFC3972] is a 175 DER-encoded ASN.1 structure of the type "SubjectPublicKeyInfo", and 176 therefore includes a subfield called "AlgorithmIdentifier". 178 List of keys CGA Parameters data structure 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 + Modifier | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 + Subnet Prefix + 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |Col Count| | 190 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+ 191 | | | Public Key | 192 ~ Public Key 1 ~ -> ~ ~ 193 | | | (variable length) | 194 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 +-+-+-+-+-+-+-+-+ | Extension | 196 | | ~ Public Key 2 ~ 197 ~ Public Key 2 ~ -> | (variable length) | 198 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 +-+-+-+-+-+-+-+-+ | | 200 ~ ... ~ 201 | | 202 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | | Extension | 204 ~ Public Key N ~ -> ~ Public Key N ~ 205 | | | (variable length) | 206 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Extension Fields | 208 ~ ~ 209 | (optional, variable length) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: CGA Parameters structure with multiple keys 214 Note that an implementation should choose the number of simultaneous 215 Public Key Extension fields used so as the total length of the 216 extension fields does not exceed a threshold that requires 217 fragmentation support at the SEND or other upper-layer protocol. 219 Support for RSA Public Keys and signature algorithm is only 220 RECOMMENDED for backward compatibility. This specification does not 221 mandate support for any particular public key signature algorithm. 222 Therefore, nodes can be configured to choose/support only a single 223 additional signature algorithm besides RSA. However, a node is also 224 free to not support RSA and still claim compatibility with this 225 specification. 227 Since [RFC3972] mandates the use of RSA keys in the Public Key field, 228 a node compatible with [RFC3972] only will extract the RSA public key 229 from the Public Key field and ignore the extension fields. 230 Therefore, in order to achieve backward compatibility, if a node uses 231 a CGA associated with multiple public keys (through the use of the 232 Public Key extension), the following procedures are in place: if one 233 of the public keys is of RSA type, then that key SHOULD be placed in 234 the Public Key field of the CGA Parameters data structure, while the 235 other key(s) SHOULD be placed in the Extension field(s). 237 4. Security Consideration 239 The document specifies a CGA extension field format. No additional 240 vulnerabilities appear besides those described in section 7 of 241 [RFC3972] 243 However, it should be noted that the resulting security level of a 244 multiple-key CGA, that this document made possible to use, is only 245 that of the weakest key. Therefore, as the document [RFC3972] state, 246 when RSA is used, the RSA key length SHOULD be at least 384 bits. In 247 this document, we state that every key in use SHOULD have a security 248 level matching or exceeding that of a 384-bit RSA key. 250 Whenever protocols negotiate signature algorithms, downgrade attacks 251 are considered. This document only provides the ability for CGA 252 options to carry multiple public keys; negotiations of signature 253 algorithms or public keys are out of the scope of this document. 255 5. IANA Considerations 257 This document defines one new CGA Extension Type [RFC4581] option, 258 which must be assigned by IANA: 260 Name: Public Key Extension Type; 262 Value: TBA. 264 Description: see Section 2. 266 6. References 268 6.1. Normative References 270 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 271 Housley, R., and W. Polk, "Internet X.509 Public Key 272 Infrastructure Certificate and Certificate Revocation List 273 (CRL) Profile", RFC 5280, May 2008. 275 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 276 RFC 3972, March 2005. 278 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 279 Neighbor Discovery (SEND)", RFC 3971, March 2005. 281 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 282 Algorithms in Cryptographically Generated Addresses 283 (CGAs)", RFC 4982, July 2007. 285 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 286 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 287 September 2007. 289 6.2. Informative References 291 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 292 Addresses (CGA) Extension Field Format", RFC 4581, 293 October 2006. 295 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 296 Identifiers for the Internet X.509 Public Key 297 Infrastructure Certificate and Certificate Revocation List 298 (CRL) Profile", RFC 3279, April 2002. 300 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 301 Optimization for Mobile IPv6", RFC 4866, May 2007. 303 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 304 "Elliptic Curve Cryptography Subject Public Key 305 Information", RFC 5480, March 2009. 307 [ITU.X690.2002] 308 International Telecommunication Union, "Information 309 Technology - ASN.1 encoding rules: Specification of Basic 310 Encoding Rules (BER), Canonical Encoding Rules (CER) and 311 Distinguished Encoding Rules (DER)", ITU-T 312 Recommandation X.690, July 2002. 314 [cheneau-send-sig-agility] 315 Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. 316 Vanderveen, "Signature Algorithm Agility in the Secure 317 Neighbor Discovery (SEND) Protocol", 318 draft-cheneau-send-sig-agility-01 (work in progress), 319 June 2009. 321 Authors' Addresses 323 Tony Cheneau 324 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 325 9 rue Charles Fourier 326 Evry 91011 327 France 329 Email: tony.cheneau@it-sudparis.eu 331 Maryline Laurent-Maknavicius 332 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 333 9 rue Charles Fourier 334 Evry 91011 335 France 337 Email: maryline.maknavicius@it-sudparis.eu 339 Sean Shen 340 Huawei 342 Email: sshen@huawei.com 344 Michaela Vanderveen 345 Qualcomm 347 Email: mvandervn@gmail.com