idnits 2.17.1 draft-cheneau-send-sig-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 182: '... A node MUST select and settle on...' RFC 2119 keyword, line 293: '...A. Local policy MAY disable this beha...' RFC 2119 keyword, line 367: '...his 16-bit field MUST be set to zero b...' RFC 2119 keyword, line 368: '... the sender, and MUST be ignored by th...' RFC 2119 keyword, line 399: '...thm combinations SHOULD be included in...' (41 more instances...) == 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A SSA option MAY be built to respect a Local Policy. However, the SSA option MUST not indicate Signature Algorithm(s) that the emitting node's CGA does not support and MUST contain at least one Signature Algorithm with the first bit on (i.e. this Signature Algorithm is available for signature generation). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The Digital Signature field MUST have correct encoding and MUST not exceed the length of the Universal Signature option minus the Padding. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: SEND secured packet is the packet that the node was not able to verify on his own, subject of the verification. Note that the encapsulated packet MUST not make the whole Signature Check Request message exceed the MTU (as no fragmentation support is available). -- 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: 'RFC4982' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC4581' is defined on line 1145, but no explicit reference was found in the text == Unused Reference: 'FIPS-186-3' is defined on line 1163, 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 (~~), 9 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. Maknavicius 4 Updates: RFC3971 TMSP 5 (if approved) S. Shen 6 Expires: December 7, 2009 Huawei 7 M. Vanderveen 8 Qualcomm 9 June 5, 2009 11 Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) 12 Protocol 13 draft-cheneau-send-sig-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 draft describes a mechanism to enable the Secure Neighbor 52 Discovery (SEND) protocol to select between different signature 53 algorithms to use with Cryptographically Generated Addresses (CGA). 54 It also provides optional support for interoperability between nodes 55 that do not share any common signature algorithms. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Compatibility with existing specifications . . . . . . . . 4 62 2.1.1. Classification of SEND nodes . . . . . . . . . . . . . 4 63 2.1.2. Principal Scenarios . . . . . . . . . . . . . . . . . 6 64 2.2. Agility Requirements . . . . . . . . . . . . . . . . . . . 7 65 2.3. Mechanism for Agility Support of CGA and SEND . . . . . . 8 66 3. Supported Signature Algorithm Option . . . . . . . . . . . . . 9 67 3.1. Neighbor Cache interactions . . . . . . . . . . . . . . . 10 68 3.2. Processing Rules for Senders . . . . . . . . . . . . . . . 10 69 3.3. Processing Rules for Receivers . . . . . . . . . . . . . . 10 70 4. SEND Universal Signature Option . . . . . . . . . . . . . . . 12 71 4.1. Processing Rules for Senders . . . . . . . . . . . . . . . 14 72 4.2. Processing Rules for Receivers . . . . . . . . . . . . . . 15 73 5. Basic negotiation . . . . . . . . . . . . . . . . . . . . . . 17 74 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.2. Sending Unsolicited Messages . . . . . . . . . . . . . . . 20 76 6. Router-as-a-notary function . . . . . . . . . . . . . . . . . 21 77 6.1. Signature Check Request Message . . . . . . . . . . . . . 21 78 6.2. Signature Status Message . . . . . . . . . . . . . . . . . 23 79 6.3. Using notary for DAD procedure . . . . . . . . . . . . . . 25 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 86 Appendix A. On the number of Public Keys supported per CGA . . . 32 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 89 1. Introduction 91 The usage scenarios associated with neighbor discovery have recently 92 been extended to include environments with mobile or nomadic nodes. 93 Many of these nodes have limited battery power and computing 94 resources. Therefore, heavy public key signing algorithms like RSA 95 are not feasible to support on such constrained nodes. Fortunately, 96 more lightweight yet secure signing algorithms do exist and have been 97 standardized, e.g. Elliptic Curve based algorithms. 99 It is then a worthwhile goal to extend secure neighbor discovery to 100 support signing and corresponding hashing algorithm agility. Besides 101 accommodating power-constrained nodes, signing and hashing algorithm 102 agility is also desired as a safety measure over time, to offer 103 alternatives when cryptanalysis of one type of algorithm makes 104 significant progress. 106 The aim of this memo is to outline options for allowing public key 107 signing algorithm and hashing algorithm agility for nodes configured 108 to perform secure neighbor discovery operations. The extent to which 109 these options impact existing specifications [RFC3971] and [RFC3972] 110 is also addressed. 112 2. Overview 114 2.1. Compatibility with existing specifications 116 The current SEND protocol specification, [RFC3971], mandates the use 117 of the RSA signature algorithm. Since the time of its writing, 118 different signature algorithms have been shown to be secure and have 119 been adopted by other protocols in an effort to reduce key length, 120 signature generation and verification time, and increase security 121 level. This shift in signature algorithm adoption particularly 122 benefits lightweight devices, which are power and memory-limited but 123 in need of secure signing algorithms support. For these reasons, we 124 feel that the restriction on the signature algorithm for SEND is no 125 longer warranted. 127 2.1.1. Classification of SEND nodes 129 At the time of this writing, there are no known large-scale or even 130 small-scale deployments of [RFC3971]-compatible devices. However, in 131 the interest of caution, we assume that there exist nodes that 132 support only the RSA algorithm and that are configured to perform 133 secure neighbor discovery. Such nodes may not be updated in the near 134 term or for the foreseeable future. On the other hand, it appears 135 that there will be deployments of nodes that support only Elliptic 136 Curve Cryptography as their public key algorithm, i.e. ECDSA as a 137 signature algorithm, rather than traditional RSA. 139 To ensure that all possible network/link configurations are 140 considered when designing a signature agility solution, we categorize 141 nodes (hosts and routers) according to their support for different 142 signature algorithms, as follows: 144 Type H1 host: 146 A host that only supports one type of signature algorithm and has 147 a CGA generated with the public key of this algorithm. 149 Examples of this type of hosts: an old host that does not support 150 signature agility, i.e. only supports RSA signature algorithm; or, 151 a host that only supports ECDSA signature. 153 Type H2 host: 155 A host that supports multiple signature algorithms and has a CGA 156 generated with only one key selected from among its supported 157 algorithms. 159 Examples of this type of hosts: (1) a host that supports RSA and 160 ECDSA signature algorithms, but only has a CGA derived with an RSA 161 public key; (2) a host that supports RSA and ECDSA signature 162 algorithms, but only has a CGA derived with an ECC public key. 164 Type H3 host: 166 A host that supports multiple signature algorithms and has a CGA 167 generated with multiple keys of different supported algorithms. 169 Such CGA generation is made possible by the introduction of a new 170 CGA extension (see companion draft [cheneau-cga-pk-agility]). 171 Such hosts can be compatible with hosts of other types for secure 172 neighbor discovery. 174 Type H4 host: 176 A host that supports multiple signature algorithms and has 177 multiple CGAs, each of which is associated with a single key of 178 one supported algorithm. For simplicity, we do not consider hosts 179 that have multiple CGAs, one or more of which are generated from 180 multiple public keys. 182 A node MUST select and settle on one CGA when building a trust 183 relationship with another device via SeND (more below). In such 184 cases, a destination node may be reached at a CGA associated with 185 a signature algorithm that the originating node cannot verify. 186 The destination node will need to securely redirect the 187 originating node to one of its other CGA(s) (presumably with a 188 common signature algorithm). The need for a method to secure the 189 binding between the two CGAs of the destination node is still an 190 open problem. 192 Based on this reasoning, consideration of H4 type nodes is left 193 for future work. 195 Routers are more likely to possess the resources necessary to support 196 multiple signature and hashing algorithms. It is also more feasible 197 that routers employ certificates. However, for a basic signature 198 agility solution, we do not mandate that routers support multiple 199 signature and hashing algorithms. 201 Possible router devices with different signature algorithm support 202 ability are: 204 Type R1 router: 206 A router that only supports one type of signature algorithm and 207 has a CGA and Certificate with a public key of this algorithm. 209 Such routers are expected to be commonplace, as compliance with 210 [RFC3971] suffices for them. 212 Type R2 router: 214 A router that supports multiple types of signature algorithms and 215 has one CGA and Certificate with a public key of one of the 216 algorithm types. 218 This type of router can sign and verify signatures of the type of 219 certificate it owns, and additionally, it can verify signatures of 220 other algorithm types. 222 Type R3 router: 224 A router that supports multiple types of signature algorithms and 225 has one CGA composed of multiple Publics Keys and multiple 226 certificates containing each a Public Key. 228 Type R4 router: 230 A router that supports multiple types of signature algorithms and 231 has multiple CGAs and Certificates with public key of several 232 different algorithm types. 234 This type of router can sign and verify signatures of multiple 235 types. Such routers may not be attractive to build and deploy due 236 to increased requirements on its resources. Moreover using 237 multiple CGAs (with no bindings) may make that routers appear as 238 having multiple identities. 240 Note that all types of router presented above can be configured to 241 use SEND over multiple interfaces or to have multiple addresses on 242 the same interface. In this case, the router will use separate CGAs. 243 Such configuration is treated in this draft as if the different 244 addresses refer to separate entities. 246 2.1.2. Principal Scenarios 248 Based on the discussion above, a SEND agility solution should at 249 least properly deal with the communication between devices of type 250 H1, H2, H3, R1, R2 and R3. 252 An H1 or R1 node interacting with an H2 or R2 node: i.e., a node 253 supporting only RSA (for example, an old non-agility node which 254 only supports RFC3971) and a node supporting both RSA and ECDSA 255 (or other new algorithms). These two nodes may be able to perform 256 secure neighbor discovery. 258 An H1 or R1 node interacting with another H1 or R1 node, but their 259 algorithms differ: e.g., a node supporting only RSA (for example, 260 an old non-agility node which only supports RFC3971) and a node 261 supporting only ECDSA (or other new algorithms). In this case, 262 implementations supporting SEND signature agility solution may 263 likely realize the incompatibility, while older implementations 264 may not. 266 A node of any type (H1, H2, H3, R1, R2, R3) interacting with 267 another node, their algorithms differ but there is a 3rd party 268 willing/able to help: this is an optional solution applicable to 269 the previous scenario, where two nodes that support SEND but do 270 not have any signature algorithms in common can talk through a 271 third party (router). In this case they should be able to perform 272 facilitated secure neighbor discovery. 274 An H2, H3 or R2 node interacting with another H2, H3, or R2 node: 275 e.g., two nodes that support at least one signature algorithms in 276 common will be able to perform secure neighbor discovery. 278 An additional rule for H2, H3 or R2, R3 node interacting with 279 another H2, H3, or R2, R3 node applies: two nodes that support two 280 or more signature algorithms in common (one of which is likely 281 preferred over the other), will be able to perform secure neighbor 282 discovery with any of these signature algorithms. 284 2.2. Agility Requirements 286 We hold the following to be requirements on a signing algorithm 287 agility solution for SEND: 289 o A Signature-Algorithm-Agility-Node should be able to communicate 290 with a Non-Signature-Algorithm-Agility-Node, but not necessarily 291 employ SEND. Traditional ND should suffice, to accommodate nodes 292 that only support one type of Signature Algorithm, which may not 293 be RSA. Local policy MAY disable this behavior, namely the use of 294 unsecured ND messages when communicating with a node that does not 295 share any common signature algorithm. 297 o Two Signature-Algorithm-Agility nodes that support a common 298 Signature Algorithm and hashing algorithm should be able to 299 communicate using SEND and sign messages using the common 300 Signature Algorithm and hash algorithm. 302 o The current SEND/CGA specifications should incur as few changes as 303 possible. 305 2.3. Mechanism for Agility Support of CGA and SEND 307 To achieve signature agility for SEND, it must be possible for a CGA 308 to be generated from and to be securely associated with multiple 309 public keys corresponding to different signature algorithms. This 310 capability is described in the companion draft 311 [cheneau-cga-pk-agility]. 313 This document proposes an update to [RFC3971] to allow two SEND nodes 314 to choose an appropriate signature algorithm. This solution 315 encompasses the following: 317 o A "Supported Signature Algorithm" Neighbor Discovery Protocol 318 option which contains a list of signing and hashing algorithms 319 that the sender node supports for SEND purposes and its 320 interaction with the Neighbor Cache; 322 o A modification of the "RSA Signature" option defined in the SEND 323 specification; 325 o An optional solution to support secure communication through a 326 router acting as a third party when nodes don't share any common 327 Signature Algorithm. 329 We define the aforementioned options format and provide processing 330 rules for both senders and receivers of SEND messages employing the 331 new options, as well as example negotiation message flows. 333 3. Supported Signature Algorithm Option 335 The Supported Signature Algorithm NDP option contains a list of 336 signing and hashing algorithm pairs that the sender node supports. 337 The format of this option is described in Figure 1: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length | Reserved | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Sig. Alg. 1 | Sig. Alg. 2 | Sig. Alg 3. | Sig. Alg 4. | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 ~ ~ 347 | ... | 348 ~ ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ... | Sig. Alg. N | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 1: Supported Signature Algorithm option 355 Type 357 NDP option type, TBA. See Section 8. 359 Length 361 The length of the option (including the Type, Length fields), in 362 octets. 8-bit unsigned integer, the values lower that 2 are 363 invalid. 365 Reserved 367 Reserved for future use. This 16-bit field MUST be set to zero by 368 the sender, and MUST be ignored by the receiver. 370 Signature Algorithm 372 A one-octet long field indicating a signature algorithm and the 373 corresponding hash algorithm that this node supports; this support 374 implies at least ability to verify signatures of this PK 375 algorithm. 377 The first leftmost bit, bit 0, if set to 0, indicates that the 378 emitter is able to perform signature checks only (i.e. no 379 signature generation with this type of signature algorithm). If 380 this bit is set to 1, it indicates that the emitter has a public 381 key of this type and can generate signatures. Bit 1 and 2 are 382 reserved. Bit 3 to 7 are named Signature Type Identifier subfield 383 and encode an identifier for the signature algorithm and 384 corresponding hash algorithm. Default values for the Signature 385 Type Identifier subfield defined in this document are taken in 386 part from the IANA-defined numbers for the IKEv2 protocol, i.e. 387 IANA registry named "IKEv2 Authentication Method": 389 * Value 0 is RSA/SHA-1 391 * Value 1 is RSA/SHA-256 393 * Value 9 is ECDSA with SHA-256 on the P-256 curve 395 * Value 10 is ECDSA with SHA-384 on the P-384 curve 397 * Value 11 is ECDSA with SHA-512 on the P-521 curve 399 The Signature/hash Algorithm combinations SHOULD be included in 400 order of preference. 402 A SSA option MAY be built to respect a Local Policy. However, the 403 SSA option MUST not indicate Signature Algorithm(s) that the 404 emitting node's CGA does not support and MUST contain at least one 405 Signature Algorithm with the first bit on (i.e. this Signature 406 Algorithm is available for signature generation). 408 3.1. Neighbor Cache interactions 410 Neighbor Cache MUST have the ability to store Supported Signature 411 Algorithm information for each entry (i.e. IPv6 address). Supported 412 Signature Algorithm information for an entry MAY be empty (e.g. entry 413 created by a RFC 3971 node or an unverifiable message). 415 3.2. Processing Rules for Senders 417 If a node has been configured to use SEND, then all Neighbor 418 Solicitation, Neighbor Advertisement, Router Solicitation, Router 419 Advertisement, and Redirect messages it sends MUST contain the 420 Supported Signature Algorithm option. This option MUST contain in 421 the Signing Algorithm field all the signature algorithms it is 422 willing to use in signature generation and verification. 424 3.3. Processing Rules for Receivers 426 Upon receiving a SEND packet with a Supported Signature Algorithm 427 Option, a receiver performs the following operations: 429 o when the message is a Neighbor Solicitation or a Router 430 Solicitation, the receiving node computes the intersection between 431 the set of Supported Signature Algorithm indicated by the option 432 and its own. If the set is empty, this means the node will not be 433 able to use a Signature Algorithm that the initiating node can 434 check. Given the local policy, a receiver node MAY still respond 435 to the received message using its "preferred" Signature Algorithm 436 (even if the node knows the receiver will not be able to verify 437 the Signature Algorithm). If the set is not empty, the receiving 438 node will choose among the set one of the algorithms in order to 439 generate a Universal Signature Option. 441 o If the message pass the SEND verifications (CGA verification, 442 Timestamp, Nonce, Universal Signature Option verification) and 443 contains a Supported Signature Algorithm Option, the information 444 of the Supported Signature Algorithm in the Neighbor Cache is 445 updated by the information contained in the Supported Signature 446 Option attached to the message. 448 o If the message does not pass the SEND verifications because of a 449 unverifiable RSA Signature Option or Universal Signature Option, 450 if it contains a Supported Signature Algorithm Option, and the 451 Neighbor Cache entry associated to that node does not contain any 452 information about the Supported Signature Algorithm, the Neighbor 453 Cache entry SHOULD be updated with the information contained in 454 the Supported Signature Algorithm Option. 456 4. SEND Universal Signature Option 458 We propose replacing the RSA Signature Option by a new algorithm- 459 independent signature option. The "Universal Signature Option" is an 460 updated version of the RSA Signature Option, that allows a node to 461 specify which of its potential multiple keys it is using. To achieve 462 this, we use the 16-bit reserved field of the RSA Signature Option, 463 and define a new 8-bit field that contains the position of the Public 464 Key associated with the signature and a new 5-bit Signature Type 465 Identifier field that details the type of algorithms used to generate 466 the Digital Signature. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | Length | Key Position | Res.| Sig ID | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 | Key Hash | 475 | | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 . . 480 . Digital Signature . 481 . . 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 . . 486 . Padding . 487 . . 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 2: Universal Signature Option format 493 Type 495 Same value as in [RFC3971]: 12. 497 Length 499 The length of the option (including the Type, Length, Reserved, 500 Key Hash, Digital Signature, and Padding fields) in units of 8 501 octets. 503 Key Position 505 An 8-bit field indicating which Public Key in the CGA parameter 506 structure (carried in the CGA option) has been used to compute the 507 Digital Signature. The index starts at 0, meaning the key is the 508 one in the Public Key field. Values greater than 1 refer to 509 Public Key found in the CGA Extension field (as defined in the 510 companion document [cheneau-cga-pk-agility]]). Value 255 is a 511 reserved value that indicates no CGA option in the message 512 contains the Public Key. 514 Reserved 516 A 3-bit field reserved for future use. The value MUST be set to 517 zero by the sender and MUST be ignored by the receiver. 519 Signature Type Identifier 521 Signature Type Identifier is a 5-bit field. It corresponds to the 522 Signature Type Identifier subfield (bits 3 to 7 of the Signature 523 Algorithm field) in the Supported Signature Algorithm option . It 524 indicates the type of signature contained in the Digital Signature 525 field. 527 Key Hash 529 A 128-bit field containing the most significant (leftmost) 128 530 bits of a hash of the public key used for constructing the 531 signature. It is computed using the same hash function as used in 532 generating digital signature (indicated in Signature Type 533 Identifier). The hash value is computed over the presentation 534 used in the Public Key field of the CGA Parameters data structure 535 carried in the CGA option. Its purpose is to associate the 536 signature with a particular key known by the receiver. Such a key 537 can either be stored in the certificate cache of the receiver or 538 be received in the CGA option in the same message. 540 Digital Signature 542 A variable-length field containing a signature constructed by 543 using the sender's private key associated to the public key 544 pointed by the Key Position field. The signature type is 545 determined from the value of the Signature Type Identifier field. 546 If the value of the Signature Type Identifier field is 0, then the 547 Key Position field must be set to 0 and this Digital Signature 548 field is computed the same way as the Digital Signature field of 549 the RSA Signature Option described in [RFC3971]. If the value of 550 the Signature Type Identifier field is 1, then this Digital 551 Signature field is computed the same way as the Digital Signature 552 field of the RSA Signature Option described in [RFC3971] except 553 that the signature is computed with the RSASSA-PKCS1-v1_5 554 algorithm as defined in [PKCS1] and hash function is SHA-256. If 555 the value of the Signature Type Identifier field is 9, 10 or 11, 556 then this Digital Signature field is computed using the ECDSA 557 signature algorithm (as defined on [SEC1]) and hash function 558 defined in Signature Type Identifier on the following data: 560 1. The 128-bit CGA Message Type tag [RFC3972] value for SEND, 561 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has 562 been generated randomly by the editor of the [RFC3971] 563 specification.). 565 2. The 128-bit Source Address field from the IP header. 567 3. The 128-bit Destination Address field from the IP header. 569 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 570 the ICMP header. 572 5. The NDP message header, starting from the octet after the ICMP 573 Checksum field and continuing up to but not including NDP 574 options. 576 6. All NDP options preceding, but not including, any of the 577 Universal Signature options. 579 This field starts after the Key Hash field. The length of the 580 Digital Signature field is determined by the length of the 581 Universal Signature option minus the length of the other fields 582 (including the variable length Pad field). 584 Padding This variable-length field contains padding, as many bytes 585 long as remain after the end of the signature. 587 A Neighbor Solicitation/Advertisement, Router Solicitation/ 588 Advertisement and Redirect message MAY contain more than one 589 Universal Signature Option, as long as it does not exceed the MTU. 590 This is particularly useful for routers operating in heterogeneous 591 networks, where hosts have a disjoint set of supported signature 592 algorithms. For information on how to compute the message size, see 593 Appendix A. 595 4.1. Processing Rules for Senders 597 When sending a SEND message spontaneously, an emitter node CAN choose 598 a signature algorithm of its preference (defined by its local policy) 599 among the corresponding Public Keys carried in the CGA option. Using 600 this signature algorithm, the node computes the Digital Signature and 601 fills the Key Position field with the position of the key in the CGA 602 parameter data structure. 604 If the node has been configured to use SEND, then all Neighbor 605 Solicitation, Neighbor Advertisement, Router Advertisement, and 606 Redirect messages MUST contain at least one Universal Signature 607 option. Router Solicitation messages not sent with the unspecified 608 source address MUST contain the Universal Signature option. 610 A node sending a message with one or more Universal Signature 611 option(s) MUST construct the message as follows: 613 o If the node has previously received hints (e.g. a NDP message with 614 a Supported Signature Algorithm option or an entry in the Neighbor 615 Cache) on the type of Signature Algorithm it should use, it MUST 616 restrict its choice on those Signature Algorithms. 618 o The message is then constructed in its entirety, without any of 619 the Universal Signature options. 621 o The Universal Signature option(s) is (are) added as the last 622 option in the message. 624 o The data to be signed is constructed as explained in [RFC3971], 625 under the description of the Digital Signature field. 627 o The message, in the form defined above, is signed by using the 628 configured private key associated to the selected Signature 629 Algorithm, and the result signature is is encapsulated into the 630 Digital Signature field. 632 4.2. Processing Rules for Receivers 634 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, 635 and Redirect messages without any Universal Signature option or with 636 an unverifiable Universal Signature option MUST be treated as 637 unsecured (i.e., processed in the same way as NDP messages sent by a 638 non-SEND node). See Section 8 of [RFC3971]. 640 Router Solicitation messages without any Universal Signature option 641 MUST also be treated as unsecured, unless the source address of the 642 message is the unspecified address. 644 Redirect, Neighbor Solicitation, Neighbor Advertisement, Router 645 Solicitation, and Router Advertisement messages containing one or 646 more Universal Signature option MUST be checked as follows: 648 o The receiver MUST ignore any options that come after the first 649 Universal Signature option. (The options are ignored for both 650 signature verification and NDP processing purposes.) 652 o The Key Hash field MUST correspond to a known public key, either 653 one learned from the CGA option in the same message by the 654 position indicated in the Key Position field message, or one known 655 by other means. 657 o The Digital Signature field MUST have correct encoding and MUST 658 not exceed the length of the Universal Signature option minus the 659 Padding. 661 o The Digital Signature verification MUST show that the signature 662 has been calculated as specified in the previous section. 664 o If the use of a trust anchor has been configured, a valid 665 certification path (see Section 6.3 of [RFC3971]) between the 666 receiver's trust anchor and the sender's public key MUST be known. 668 Messages that do not pass all the above tests MUST be silently 669 discarded if the host has been configured to accept only secured ND 670 messages. The messages MAY be accepted if the host has been 671 configured to accept both secured and unsecured messages but MUST be 672 treated as unsecured messages. The receiver MAY also otherwise 673 silently discard packets (e.g., as a response to an apparent CPU 674 exhausting DoS attack). 676 5. Basic negotiation 678 5.1. Overview 680 This section describes different configuration of SEND-enabled nodes 681 with varying signing capabilities and their interaction during the 682 negotiation phase. 684 Case 1: when both nodes support the same two Signature Algorithms, 685 they can pick the Signature Algorithm they prefer for signing and are 686 able to verify each others signature. Figure 3 is an example of such 687 a message flow. 689 Node A Node B 691 NS 692 {CGA option, 693 RSA Signature option. 694 Supported-Signature-Algo option 695 (RSA sign & verif, ECC sign & verif)} 696 --------> 697 NA 698 {CGA option, 699 ECC Signature option 700 Supported-Signature-Algo option 701 (ECC sign & verif, RSA sign & verif)} 702 <-------- 704 IPv6 traffic <-------> IPv6 traffic 706 Figure 3: Basic negotiation - Case 1 708 Case 2: two nodes sharing at least one common Signing Algorithm must 709 be able to securely communicate. Figure 4 is an example of such a 710 message flow. 712 Node A Node B 714 NS 715 {CGA option, 716 RSA Signature option. 717 Supported-Signature-Algo option 718 (RSA sign & verif, ECC sign & verif)} 719 --------> 720 NA 721 {CGA option, 722 ECC Signature option 723 Supported-Signature-Algo option 724 (ECC sign & verif)} 725 <-------- 726 (At this point, Node B could not 727 authenticate Node A's Neighbor 728 Solicitation) 730 --------> (unidirectionnal) IPv6 traffic 732 NS 733 {CGA option, 734 ECC Signature option 735 Supported-Signature-Algo option 736 (ECC sign & verif)} 737 <-------- 738 NA 739 {CGA option, 740 ECC Signature option. 741 Supported-Signature-Algo option 742 (RSA sign & verif, ECC sign & verif)} 743 --------> 745 IPv6 traffic <-------> IPv6 traffic 747 Figure 4: Basic negotiation - Case 2 749 Case 3: when two nodes have a disjoint set of Signature Algorithm 750 support for signing, but the two nodes are able to verify each 751 others, a full negotiation is possible. Figure 5 is an example of 752 such a message flow. 754 Node A Node B 756 NS 757 {CGA option, 758 RSA Signature option. 759 Supported-Signature-Algo option 760 (RSA sign & verif, ECC verif only)} 761 --------> 762 NA 763 {CGA option, 764 ECC Signature option 765 Supported-Signature-Algo option 766 (ECC sign & verif, RSA verif only)} 767 <-------- 769 IPv6 traffic <-------> IPv6 traffic 771 Figure 5: Basic negotiation - Case 3 773 Case 4: when two nodes have a disjoint set of Signature Algorithm 774 support for signing, but one node is able to verify, a partial 775 negotiation is possible. Figure 6 is an example of such a message 776 flow. 778 Node A Node B 780 NS 781 {CGA option, 782 RSA Signature option. 783 Supported-Signature-Algo option 784 (RSA sign & verif)} 785 --------> 786 NA 787 {CGA option, 788 ECC Signature option 789 Supported-Signature-Algo option 790 (ECC sign & verif, RSA verif only)} 791 <-------- 793 (...depending on local policies...) 794 IPv6 traffic <-------> IPv6 traffic 796 Figure 6: Basic negotiation - Case 4 798 Section 6 describes an optional functionality that allow nodes in 799 Case 4 to perform a trustful complete negotiation. 801 5.2. Sending Unsolicited Messages 803 When sending unsolicited message, a node MAY have to rely on the 804 entries of its Neighbor Cache. The Neighbor Cache will provide hints 805 concerning the Signature Algorithm supported by the neighbors. 806 Neighbor Cache can assist the node in the Signature Algorithm 807 selection process when: 809 o A router advertises unsolicited Router Advertisement message to 810 the All-Nodes multicast address (e.g. to indicate a prefix 811 lifetime is going down to 0). The router needs to know which 812 signature algorithm(s) to use in order to send verifiable messages 813 to hosts. To do so, the router MAY rely on the Neighbor Cache and 814 compute an intersection of the set of all Supported Signature 815 Algorithms. The router will then be able to advertise a Router 816 Advertisement signed multiple times with the resulting subset of 817 Supported Signature Algorithms or advertise multiple Router 818 Advertisements, each signed with a single Signature Algorithm part 819 of the intersection. 821 o A node sends unsolicited Neighbor Advertisement (e.g. when 822 changing its Link-Layer address). This is similar to the previous 823 problem and can also be solved using the Neighbor Cache the same 824 way. 826 o A router sends a Redirect message to a host. Choosing a supported 827 signature algorithm without probing the node can be difficult. 828 However, Neighbor Cache will most likely contain an entry for the 829 host, prior to the decision to send a Redirect message, because of 830 the Address Resolution process. This entry should contain 831 information on the Supported Signature Algorithm(s) and thus 832 provide hints concerning the Signature Algorithm to choose to sign 833 the Redirect messages. 835 Note that the information on the neighbors with which a communication 836 has occurred recently or is ongoing are in the Neighbor Cache and are 837 maintained up to date through the Neighbor Unreachability Detection 838 procedure. 840 6. Router-as-a-notary function 842 This optional functionality enhances backward compatibility by 843 introducing a new entity. This new entity, named "notary", certifies 844 the authenticity of a node's message. This improves communication 845 when, for example, two nodes have a disjoint set of supported 846 Signature Algorithm types and still require secure neighbor 847 discovery. 849 In this specification, the notary function is offered by routers, 850 although other nodes may offer this capability in the future 851 specification. Authorization for the router to act as a notary is 852 shown through router's certificate in a KeyPurposeID as defined in 853 [krishnan-cgaext-send-cert-eku] and provided by the trust anchor. 855 The notary function requires the two specific ICMP messages: 856 signature check request message and signature status message. 858 6.1. Signature Check Request Message 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Type | Code | Packet Length | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Checksum | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Request ID. | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 + + 870 | SEND secured packet | 871 ~ (NDP packets should fit completely) ~ 872 | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Options ... 875 +-+-+-+-+-+-+-+-+-+- 877 Signature Check Request Message format 879 Type 881 TBA. 883 Code 885 TBA. 887 Packet Length 889 Packet length is the size of the SEND secured packet 891 Checksum 893 Checksum is a CRC-16 of the whole packet. During the CRC-16 894 computation, this field is set to 0. The purpose of this field is 895 to quickly invalidate transmission errors. 897 Reserved 899 This 16-bit field is reserved. MUST be set to 0 by senders and 900 ignored by receivers. 902 Request Identifier 904 Request Identifier helps matching a signature check request and 905 the signature status (response) messages. Request Identifier 906 field is randomly generated. 908 SEND secured packet 910 SEND secured packet is the packet that the node was not able to 911 verify on his own, subject of the verification. Note that the 912 encapsulated packet MUST not make the whole Signature Check 913 Request message exceed the MTU (as no fragmentation support is 914 available). 916 Options 918 This field contains one or more NDP options. Currently, only one 919 option is mandatory in this field. It is the Supported Signature 920 Algorithm option, that allows the notary to choose a correct 921 signature algorithm to sign the Signature Status message. 923 Note that this message MAY be protected by usual SEND NDP options 924 (CGA option, Timestamp, Nonce, Universal Signature Option). In this 925 case, the Universal Signature Option contains the whole packet that 926 the node wants to be checked on the router (so packet may not be 927 tampered with). 929 A router acting as a notary processes the packet as follows: 931 if the packet is protected with SEND options, the notary: 933 * Verifies the CGA of the emitter 934 * Verifies the Universal Signature Option of the message (linked 935 to CGA of the source address). If more than one Universal 936 Signature Options are in the message, the notary can decide to 937 check any of them. 939 * Verifies the CGA and signature of the SEND secured packet 940 (inner packet). 942 * Responds with a Signature status message (defined in the 943 following section) indicating the status of the SEND secured 944 packet Universal Signature Option. 946 if the packet is not protected, the notary: 948 * verifies the CGA and signature of the SEND secured packet 949 (inner packet). If more than one Universal Signature Option 950 are in the message, the notary can decide to check any of them. 952 * Responds with a Signature status message (defined in the 953 following section) indicating the status of the SEND secured 954 packet Universal Signature Option. 956 6.2. Signature Status Message 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Type | Code | Status | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Request ID. | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Hash | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Options ... 968 +-+-+-+-+-+-+-+-+-+- 970 Signature Status Message format 972 Type 974 TBA. 976 Code 978 TBA. 980 Status 982 The 16-bit status field can be set to any of the following values: 984 0: all validation checks passed 986 1: Signature Check Request message checksum failed 988 2: inner packet CGA verification check failed 990 3: inner packet signature verification check failed 992 4: unsupported hash algorithm (to compute Hash1/Hash2) 994 5: unsupported Public Key algorithm 996 6: ask later (router is busy) 998 Request Identifier 1000 The Request Identifier helps matching a signature check request 1001 and the signature status (response) message. The Request 1002 Identifier is copied from the Signature Check Request message. 1004 Hash 1006 The Hash field contains the result of a hash function applied on 1007 the Request ID field and on the Send Secured Packet field of the 1008 Signature Check Request message. The hash function is the same as 1009 the one in the Key Hash field of the Universal Signature Option 1010 that will protect this message. 1012 Options 1014 This field contains one or more NDP options. Mandatory options 1015 are CGA Option, Timestamp Option and Universal Signature Option. 1016 Universal Signature Option MUST be the last option. 1018 This message is a response to a Signature Check Request message and 1019 is protected by SEND options generated using a public key contained 1020 in a certificate of the router authorized to act as notary. If the 1021 Signature Check Request message is protected by the Nonce option, 1022 this option MUST be copied in the Signature Status message. 1024 On reception of this message, a requesting node performs CGA 1025 verification, Nonce (if included in the initial request) and 1026 Timestamp checks, and Universal Signature Option check. If any of 1027 those test fails, the packet is dropped and an error MAY be logged. 1029 Then, if the status message is 0, that node can treat the original 1030 packet that created the need for a Notary Signature Check Request 1031 message as a secured packet. On a status value different from 0, the 1032 packet will be considered as unsecure and be treated as such. Status 1033 value MAY be loged for further diagnosis. 1035 6.3. Using notary for DAD procedure 1037 When performing the DAD procedure, a node can receive Neighbor 1038 Solicitation or Neighbor Advertisement that are protected by a 1039 Universal Signature Option the node can not check. In this specific 1040 case, the node can ask the notary to check the signature for him. 1042 However, the node, while performing DAD, MUST send the Signature 1043 Check Request message using the unspecified address as source 1044 address. The notary MUST respond with a Signature Status message 1045 directed to the All-Node multicast address. 1047 7. Security Considerations 1049 +-----------------------+-----------------------+ 1050 | RSA key length (bits) | ECC key length (bits) | 1051 +-----------------------+-----------------------+ 1052 | 3072 | 256 | 1053 | | | 1054 | 7680 | 384 | 1055 | | | 1056 | 15380 | 512 | 1057 +-----------------------+-----------------------+ 1059 Equivalence between Elliptic Curves and RSA security levels 1061 Table 1: Security level equivalence between ECC and RSA 1063 Section 4 presents a new Universal Signature Option. A recommended 1064 use of this option is to allow signatures of equivalent security 1065 level (i.e. Public Keys with equivalent key lengths) as shown in 1066 Table 1. See also section 4 of the companion draft 1067 [cheneau-cga-pk-agility]. 1069 Usage of SHA-1 for signature is strongly NOT RECOMMENDED, and when 1070 available should be preferred by the usage of SHA-256. SHA-1 1071 security is been proved to be flawed in the light of recent attacks 1072 [Recent SHA-1 Attack] [NIST-st]. 1074 The Universal Signature Option is vulnerable to downgrade attacks. 1075 That is, given that a node can employ multiple signature types, an 1076 attacker may choose to use a flawed one. To mitigate this issue, 1077 nodes are allowed, on a local policy, to refuse to check certain 1078 types of signature (i.e. those which are know to be flawed) and will 1079 treat the associated messages as unsecured. When trying to 1080 completely mitigate downgrade attacks, an administrator MAY deploy 1081 SEND-secured nodes only authorizing a single signature algorithm 1082 scheme. This comes at a price of a reduced interoperability. 1084 Section 6 introduces an optional notary functionality that offers to 1085 nodes to check messages on their behalf, involving heavy 1086 cryptographic computation. This can lead to flooding attacks and 1087 Denial of Services. However, Neighbor Discovery Protocol [RFC4861] 1088 and Secure Neighbor Discovery Protocol [RFC3971] are already prone to 1089 flooding attacks. One possible solution is to use rate limiting on 1090 Signature Check Request messages. 1092 Notary functionality is also vulnerable to "Good Router Goes Bad" 1093 attacks (as described in [RFC3756]). Notary can make node trust 1094 unsecured packets and drop valid ones. This issue can be mitigated 1095 when multiple notaries are present on a link. The node can use a 1096 round-robin algorithm to load-balance the Signature Check Request 1097 message, thus reducing the risk of cache poisoning by a compromised 1098 notary. 1100 8. IANA Considerations 1102 This document requests IANA to allocate types for the two new notary 1103 ICMP messages. 1105 Section 3 defines a Signature Type Identifier subfield containing new 1106 values corresponding to different Signature Algorithm. This document 1107 requests creation of a new registry to the IANA. 1109 9. Acknowledgments 1111 The authors gratefully acknowledge the contributions of Marcelo 1112 Bagnulo, Gabriel Montenegro, Greg Daley, Dave Thaler, Steve Kent, 1113 Jari Arko, and Francis Dupont for their helpful feedback. 1115 10. References 1117 10.1. Normative References 1119 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1120 RFC 3972, March 2005. 1122 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1123 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1125 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 1126 Algorithms in Cryptographically Generated Addresses 1127 (CGAs)", RFC 4982, July 2007. 1129 [cheneau-cga-pk-agility] 1130 Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. 1131 Vanderveen, "Support for Multiple Signature Algorithms in 1132 Cryptographically Generated Addresses (CGAs)", 1133 draft-cheneau-cga-pk-agility-01 (work in progress), 1134 June 2009. 1136 10.2. Informative References 1138 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1139 (IPv6) Specification", RFC 2460, December 1998. 1141 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1142 Discovery (ND) Trust Models and Threats", RFC 3756, 1143 May 2004. 1145 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 1146 Addresses (CGA) Extension Field Format", RFC 4581, 1147 October 2006. 1149 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1150 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1151 September 2007. 1153 [NIST-st] National Institute of Standards and Technology, "NIST 1154 Comments on Cryptanalytic Attacks on SHA-1", 1155 . 1157 [krishnan-cgaext-send-cert-eku] 1158 Krishnan, S., Kukec, A., and K. Ahmed, "Certificate 1159 profile and certificate management for SEND", 1160 draft-krishnan-cgaext-send-cert-eku-03 (work in progress), 1161 March 2009. 1163 [FIPS-186-3] 1164 National Institute of Standards and Technology, "Draft 1165 Digital Signature Standard", FIPS PUB 186-3, March 2006. 1167 [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 1168 PKCS 1, November 2002. 1170 [FIPS.180-2] 1171 National Institute of Standards and Technology, "Secure 1172 Hash Standard", FIPS PUB 180-2, August 2002, . 1175 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 1176 Elliptic Curve Cryptography", September 2000, 1177 . 1179 [Recent SHA-1 Attack] 1180 McDonald, C., Haukes, P., and J. Pieprzyk, "SHA-1 1181 collisions now 2^52", May 2009, . 1185 Appendix A. On the number of Public Keys supported per CGA 1187 +------------------+--------------+---------------------------------+ 1188 | RSA key length | Public | Size of the DER-encoded Public | 1189 | (bits) | exponent | Key (bytes) | 1190 +------------------+--------------+---------------------------------+ 1191 | 384 | 3 or 17 | 76 | 1192 | | | | 1193 | 384 | 65537 | 78 | 1194 | | | | 1195 | 512 | 3 or 17 | 92 | 1196 | | | | 1197 | 512 | 65537 | 94 | 1198 | | | | 1199 | 1024 | 3 or 17 | 160 | 1200 | | | | 1201 | 1024 | 65537 | 162 | 1202 | | | | 1203 | 2048 | 3 or 17 | 292 | 1204 | | | | 1205 | 2048 | 65537 | 294 | 1206 | | | | 1207 | 3072 | 3 or 17 | 420 | 1208 | | | | 1209 | 3072 | 65537 | 422 | 1210 | | | | 1211 | 7680 | 3 or 17 | 996 | 1212 | | | | 1213 | 7680 | 65537 | 998 | 1214 | | | | 1215 | 15360 | 3 or 17 | 1956 | 1216 | | | | 1217 | 15360 | 65537 | 1958 | 1218 +------------------+--------------+---------------------------------+ 1220 Table 2: Common sizes for DER-encoded RSA Public Key 1222 +----------------------+--------------------------------------------+ 1223 | RSA Key Length (in | Size of the Digital Signature field | 1224 | bits) | without padding | 1225 +----------------------+--------------------------------------------+ 1226 | 384 | 48 | 1227 | | | 1228 | 512 | 64 | 1229 | | | 1230 | 1024 | 128 | 1231 | | | 1232 | 2048 | 256 | 1233 | | | 1234 | 3072 | 384 | 1235 | | | 1236 | 7680 | 960 | 1237 | | | 1238 | 15360 | 1920 | 1239 +----------------------+--------------------------------------------+ 1241 Table 3: Common sizes of the Digital Signature field when using RSA 1243 +--------------------------+----------------------------------------+ 1244 | Name of the elliptic | Size of the DER-encoded Public Key | 1245 | curve | (bytes) | 1246 +--------------------------+----------------------------------------+ 1247 | P-256 | 88 | 1248 | | | 1249 | P-384 | 120 | 1250 | | | 1251 | P-521 | 158 | 1252 +--------------------------+----------------------------------------+ 1254 Table 4: Common sizes for DER-encoded ECC Public Key 1256 +-----------------------+-------------------------------------------+ 1257 | Name of the elliptic | Size of the Digital Signature field | 1258 | curve | (without padding) | 1259 +-----------------------+-------------------------------------------+ 1260 | P-256 | 71 | 1261 | | | 1262 | P-384 | 104 | 1263 | | | 1264 | P-521 | 139 | 1265 +-----------------------+-------------------------------------------+ 1267 Table 5: Common sizes of the Digital Signature field when using ECDSA 1268 (+ DER encoding) 1270 When using multiple public keys to form a CGA, one may reach the 1271 maximum number of possible public keys before each Neighbor Discovery 1272 Message exceed the Maximum Transfer Unit (which must be at least 1280 1273 octets according to [RFC2460]). This section aims to approximate 1274 this limit. 1276 Numerous factors (presence and number of option, size of public keys, 1277 etc) influence the size of the Neighbor Discovery message. For 1278 example, when sending a SEND-secured Router Advertisement message: 1280 o The IPv6 header is 40 bytes long. Described in [RFC2460]. 1282 o The bare Router Advertisement message (without any option) is 16 1283 bytes long. Described in [RFC4861]. 1285 o A Prefix Information Option (can appear more than once) is 32 1286 bytes long. Described in [RFC4861]. 1288 o A Source Link-Layer Option, when a IEEE 802 address is used, is 8 1289 bytes long. Described in [RFC4861]. 1291 o A MTU Option is 8 bytes long. Described in [RFC4861]. 1293 o The CGA Option is the size of the CGA Parameter Data Structure 1294 plus 4 bytes rounded up to the closest multiple of 8 value. This 1295 option is defined in [RFC3971]. The CGA Parameter Data Structure 1296 (defined in [RFC3972] size depends on the following fields: 1298 * Modifier: 16 bytes long. 1300 * Subnet Prefix: 8 bytes long. 1302 * Collision Count: 1 byte long. 1304 * Public Key: variable size. Table 2 provides size of the 1305 commonly used DER-encoded RSA Public Keys. Table 4 provides 1306 size for the commonly used DER-encoded ECC Public Keys. 1308 * Extension(s): variable size. Public Key Extension field 1309 defined in [cheneau-cga-pk-agility] is 4 bytes plus the size of 1310 the Public Key long. Public Key size are defined in Table 2 1311 and Table 4. 1313 o The Timestamp Option is 16 bytes long. Defined in [RFC3971]. 1315 o The Nonce Option minimum size is 8 bytes long. Defined in 1316 [RFC3971]. 1318 o The Universal Signature Option depends on the size of the Digital 1319 Signature. The fixed part of the option is 20 bytes long. This 1320 option is updated in this document. Table 3 presents common sizes 1321 for usual Digital Signature field when using RSA. Table 5 1322 presents common sizes for Digital Signature field when using 1323 ECDSA. This option size must be a multiple of 8 bytes. 1325 A Router Advertisement message, carrying a Prefix Information Option 1326 and a Source Link-Layer Option, without Nonce, with one 1024-bits 1327 long RSA Public Key and a Public Exponent of 3 in the CGA Option is 1328 456 bytes long. Using the same RSA Public Key, adding one ECC P-521 1329 key to CGA Option, the same message, signed with a Universal 1330 Signature option generated by RSA and a Universal Signature Option 1331 signed by ECDSA, is 768 bytes long. Note that EC P-521 and 1024-bits 1332 RSA keys should not be used together because they do not present the 1333 same security level (see Section 7) and are shown here to indicate 1334 sizes of messages with "big" keys. 1336 Authors' Addresses 1338 Tony Cheneau 1339 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 1340 9 rue Charles Fourier 1341 Evry 91011 1342 France 1344 Email: tony.cheneau@it-sudparis.eu 1346 Maryline Laurent-Maknavicius 1347 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 1348 9 rue Charles Fourier 1349 Evry 91011 1350 France 1352 Email: maryline.maknavicius@it-sudparis.eu 1354 Sean Shen 1355 Huawei 1356 No. 9 Xinxi Road 1357 Beijing 100085 1358 China 1360 Email: sshen@huawei.com 1362 Michaela Vanderveen 1363 Qualcomm 1365 Email: mvandervn@gmail.com