idnits 2.17.1 draft-cheneau-send-sig-agility-00.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 187: '... A node MUST select and settle on...' RFC 2119 keyword, line 288: '...A. Local policy MAY disable this beha...' RFC 2119 keyword, line 363: '... [request] packet) MUST leave this bit...' RFC 2119 keyword, line 368: '...his 15-bit field MUST be set to zero b...' RFC 2119 keyword, line 369: '... the sender, and MUST be ignored by th...' (27 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: 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 (February 21, 2009) is 5543 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 905, but no explicit reference was found in the text == Unused Reference: 'RFC4581' is defined on line 918, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 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 Updates: RFC3971 TMSP 5 (if approved) S. Shen 6 Expires: August 25, 2009 Huawei 7 M. Vanderveen 8 Qualcomm 9 February 21, 2009 11 Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) 12 Protocol 13 draft-cheneau-send-sig-agility-00 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 August 25, 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 This draft describes a mechanism to enable the Secure Neighbor 53 Discovery (SEND) protocol to select between different signature 54 algorithms to use with Cryptographically Generated Addresses (CGA). 55 It also provides optional support for interoperability between nodes 56 that do not share any common signature algorithms. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Compatibility with existing specifications . . . . . . . . 4 63 2.1.1. Classification of SEND nodes . . . . . . . . . . . . . 4 64 2.1.2. Principal Scenarios . . . . . . . . . . . . . . . . . 6 65 2.2. Agility Requirements . . . . . . . . . . . . . . . . . . . 7 66 2.3. Mechanism for Agility Support of CGA and SeND . . . . . . 7 67 3. Supported Signature Algorithm Option . . . . . . . . . . . . . 9 68 3.1. Processing Rules for Senders . . . . . . . . . . . . . . . 10 69 3.2. Processing Rules for Receivers . . . . . . . . . . . . . . 10 70 4. SEND Universal Signature Option . . . . . . . . . . . . . . . 12 71 4.1. Processing Rules for Senders . . . . . . . . . . . . . . . 15 72 4.2. Processing Rules for Receivers . . . . . . . . . . . . . . 16 73 5. Basic negotiation . . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 6. Router-as-a-notary function . . . . . . . . . . . . . . . . . 19 76 6.1. Signature check request message . . . . . . . . . . . . . 19 77 6.2. Signature status message . . . . . . . . . . . . . . . . . 21 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 86 1. Introduction 88 Cryptographically Generated Addresses (CGA) [RFC3972] have been 89 designed primarily for securing Neighbor Discovery [RFC3971]. At the 90 time when they were specified, CGAs allowed only one signing 91 algorithm, namely RSA. While mandating a single public key signing 92 algorithm does help with interoperability, it does not address the 93 issue of computational efficiency. It is well known that the RSA 94 signature generation and verification is computationally expensive. 96 The usage scenarios associated with neighbor discovery have recently 97 been extended to include environments with mobile or nomadic nodes. 98 Many of these nodes have limited battery power and computing 99 resources. Therefore, heavy public key signing algorithms like RSA 100 are not feasible to support on such constrained nodes. Fortunately, 101 more lightweight yet secure signing algorithms do exist and have been 102 standardized, e.g. Elliptic Curve based algorithms. 104 It is then a worthwhile goal to extend secure neighbor discovery to 105 support signing algorithm agility. Besides accommodating power- 106 constrained nodes, signing algorithm agility is also desired as a 107 safety measure over time, to offer alternatives when cryptanalysis of 108 one type of algorithm makes significant progress. 110 The aim of this memo is to outline options for allowing public key 111 signing algorithm agility for nodes configured to perform secure 112 neighbor discovery operations when attaching to a new link. The 113 extent to which these options impact existing specifications 114 [RFC3971] and [RFC3972] is also addressed. 116 2. Overview 118 2.1. Compatibility with existing specifications 120 The current SEND protocol specification, [RFC3971], mandates the use 121 of the RSA signature algorithm. Since the time of its writing, 122 different signature algorithms have been shown to be secure and have 123 been adopted by other protocols in an effort to reduce key length, 124 signature generation and verification time, and increase security 125 level. This shift in signature algorithm adoption particularly 126 benefits lightweight devices, which are power and memory-limited but 127 in need of secure signing algorithms support. For these reasons, we 128 feel that the restriction on the signature algorithm for SEND is no 129 longer warranted. 131 2.1.1. Classification of SEND nodes 133 At the time of this writing, there are no known large-scale or even 134 small-scale deployments of [RFC3971]-compatible devices. However, in 135 the interest of caution, we assume that there exist nodes that 136 support only the RSA algorithm and that are configured to perform 137 secure neighbor discovery when attaching to a new link. Such nodes 138 may not be updated in the near term or for the foreseeable future. 139 On the other hand, it appears that there will be deployments of nodes 140 that support only Elliptic Curve Cryptography as their public key 141 algorithm, i.e. ECDSA as a signature algorithm, rather than 142 traditional RSA. 144 To ensure that all possible network/link configurations are 145 considered when designing a signature agility solution, we categorize 146 nodes (hosts and routers) according to their support for different 147 signature algorithms, as follows: 149 Type H1 host: 151 A host that only supports one type of signature algorithm and has 152 a CGA generated with the public key of this algorithm. 154 Examples of this type of hosts: an old host that does not support 155 signature agility, i.e. only supports RSA signature algorithm; or, 156 a host that only supports ECDSA signature. 158 Type H2 host: 160 A host that supports multiple signature algorithms and has a CGA 161 generated with only one key selected from among its supported 162 algorithms. 164 Examples of this type of hosts: (1) a host that supports RSA and 165 ECDSA signature algorithms, but only has a CGA derived with an RSA 166 public key; (2) a host that supports RSA and ECDSA signature 167 algorithms, but only has a CGA derived with an ECC public key. 169 Type H3 host: 171 A host that supports multiple signature algorithms and has a CGA 172 generated with multiple keys of different supported algorithms. 174 Such CGA generation is made possible by the introduction of a new 175 CGA extension (see companion draft [cheneau-cga-pk-agility]). 176 Such hosts can be compatible with hosts of other types for secure 177 neighbor discovery. 179 Type H4 host: 181 A host that supports multiple signature algorithms and has 182 multiple CGAs, each of which is associated with a single key of 183 one supported algorithm. For simplicity, we do not consider hosts 184 that have multiple CGAs, one or more of which are generated from 185 multiple public keys. 187 A node MUST select and settle on one CGA when building a trust 188 relationship with another device via SeND (more below). In such 189 cases, a destination node may be reached at a CGA associated with 190 a signature algorithm that the originating node cannot verify. 191 The destination node will need to securely redirect the 192 originating node to one of its other CGA(s) (presumably with a 193 common signature algorithm). The need for and method to secure 194 the binding between the two CGAs of the destination node is still 195 an open problem. 197 Based on this reasoning, consideration of H4 type nodes is left 198 for future work. 200 Routers are more likely to possess the resources necessary to support 201 multiple signature algorithms. It is also more feasible that routers 202 employ certificates. However, for a basic signature agility 203 solution, we do not mandate that routers support multiple signature 204 algorithms. 206 Possible router devices with different signature algorithm support 207 ability are: 209 Type R1 router: 211 A router that only supports one type of signature algorithm and 212 has a CGA and Certificate with a public key of this algorithm. 214 Such routers are expected to be commonplace, as compliance with 215 [RFC3971] suffices for them. 217 Type R2 router: 219 A router that supports multiple types of signature algorithms and 220 has one CGA and Certificate with a public key of one of the 221 algorithm types. 223 This type of router can sign and verify signatures of the type of 224 certificate it owns, and additionally, it can verify signatures of 225 other algorithm types. 227 Type R3 router: 229 A router that supports multiple types of signature algorithms and 230 has multiple CGAs and Certificates with public key of several 231 different algorithm types. 233 This type of router can sign and verify signatures of multiple 234 types. Such routers may not be attractive to build and deploy due 235 to increased requirements on its resources. Moreover using 236 multiple CGAs (with no bindings) may make that router appear as 237 having multiple identities. 239 Type R4 router: 241 A router that supports multiple types of signature algorithms and 242 has one CGA composed of multiple Publics Keys and multiple 243 certificates containing each a Public Key. 245 2.1.2. Principal Scenarios 247 Based on the discussion above, a SEND agility solution should at 248 least properly deal with the communication between devices of type 249 H1, H2, H3, R1 and R2. 251 An H1 or R1 node interacting with an H2 or R2 node: i.e., a node 252 supporting only RSA (for example, an old non-agility node which 253 only supports RFC3971) and a node supporting both RSA and ECDSA 254 (or other new algorithms). These two nodes must be able to 255 perform secure neighbor discovery. 257 An H1 or R1 node interacting with another H1 or R1 node, but their 258 algorithms differ: e.g., a node supporting only RSA (for example, 259 an old non-agility node which only supports RFC3971) and a node 260 supporting only ECDSA (or other new algorithms). In this case, 261 implementations supporting SEND signature agility solution may 262 likely realize the incompatibility, while older implementations 263 may not. 265 A node of any type (H1, H2, H3, R1, R2, R3 or R4) interacting with 266 another node, their algorithms differ but there is a 3rd party 267 willing/able to help: this is an optional solution applicable to 268 the previous scenario, where two nodes that support SEND but do 269 not have any signature algorithms in common can talk through a 270 third party (router). In this case they should be able to perform 271 facilitated secure neighbor discovery. 273 An H2, H3 or R2 node interacting with another H2, H3, or R2 node: 274 e.g., two nodes that support at least two signature algorithms in 275 common (one of which is likely preferred over the other), will be 276 able to perform secure neighbor discovery with any of the two 277 algorithms. 279 2.2. Agility Requirements 281 We hold the following to be requirements on a signing algorithm 282 agility solution for SEND: 284 o A Signature-Algorithm-Agility-Node should be able to communicate 285 with a Non-Signature-Algorithm-Agility-Node, but not necessarily 286 employ SEND. Traditional ND should suffice, to accommodate nodes 287 that only support one type of Signature Algorithm, which may not 288 be RSA. Local policy MAY disable this behavior, namely the use of 289 unsecured ND messages when communicating with a node that does not 290 share any common signature algorithm. 292 o Two Signature-Algorithm-Agility nodes that support a common 293 Signature Algorithm should be able to communicate using SEND and 294 sign messages using the common Signature Algorithm. 296 o The current SEND/CGA specifications should incur as few changes as 297 possible. 299 2.3. Mechanism for Agility Support of CGA and SeND 301 To achieve signature agility for SeND, it must be possible for a CGA 302 to be generated from and to be securely associated with multiple 303 public keys corresponding to different signature algorithms. This 304 capability is described in the companion draft 306 [cheneau-cga-pk-agility]. 308 This document proposes an update to [RFC3971] to allow two SEND nodes 309 to chose an appropriate signature algorithm. This solution 310 encompasses the following: 312 o A "Supported Signature Algorithm" NDP option which contains a list 313 of signing algorithms that the sender node supports for SEND 314 purposes; 316 o A modification of the "RSA Signature" option defined in the SEND 317 specification; 319 o An optional solution to support secure communication through a 320 router acting as a third party when nodes don't share any common 321 Signature Algorithm. 323 We define the aforementioned options format and provide processing 324 rules for both senders and receivers of SEND messages employing the 325 new options, as well as example negotiation message flows. 327 3. Supported Signature Algorithm Option 329 The Supported Signature Algorithm NDP option contains a list of 330 signing algorithms that the sender nodes supports. The format of 331 this option is described in Figure 1: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length |R| Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Sig. Alg. 1 | Sig. Alg. 2 | Sig. Alg 3. | Sig. Alg 4. | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 ~ ~ 341 | ... | 342 ~ ~ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | ... | Sig. Alg. N | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 1: Supported Signature Algorithm option 349 Type 351 NDP option type, TBA. See Section 8. 353 Length 355 The length of the option (including the Type, Length fields), in 356 octets. 8-bit unsigned integer, the value 0 is invalid. 358 R 360 "Resend" flag. If this bit is set, it indicates that the sender 361 of this packet was not able to validate the packet that this 362 packet was sent in response to. Spontaneous packets (i.e. those 363 not sent in response to a [request] packet) MUST leave this bit 364 cleared. 366 Reserved 368 Reserved for future use. This 15-bit field MUST be set to zero by 369 the sender, and MUST be ignored by the receiver. 371 Signature Algorithm 373 A one-octet long field indicating a signature algorithm that is 374 supported by the node, this support implies at least ability to 375 verify signatures of this PK 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 on 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 the signature algorithm identifier. This signature 384 algorithm identifier binds a Public Key algorithm with an hash 385 algorithm. Default values for the Signature Type Identifier 386 subfield defined in this document are: 388 * Value 1 is RSA/SHA-256 390 * Value 2 is ECDSA/SHA-256 392 * Value 0 is reserved for future use. 394 The Signature Algorithms SHOULD be included in order of 395 preference. 397 3.1. Processing Rules for Senders 399 If a node has been configured to use SEND, then all Neighbor 400 Solicitation, Neighbor Advertisement, Router Solicitation, Router 401 Advertisement, and Redirect messages it sends MUST contain the 402 Supported Signature Algorithm option. This option MUST contain in 403 the Signing Algorithm field all signature algorithms it is willing to 404 use in signature verification. 406 3.2. Processing Rules for Receivers 408 Upon receiving a SEND packet with a Supported Signature Algorithm 409 Option, a receiver checks the 'R' flag: 411 o when the 'R' flag is not set and the message is a Neighbor 412 Advertisement or Router Advertisement, a host need not parse this 413 option any further. A router MAY choose not to parse this option. 415 o when the 'R' flag is not set and the message is a Neighbor 416 Solicitation, the receiving node computes the intersection between 417 the set of Supported Signature Algorithms indicated by the option 418 and its own. If the set is empty, this means the node will not be 419 able to use a Signature Algorithm that the initiating node can 420 check. Given the local policy, a receiver node will still respond 421 to the received message using its "preferred" Signature Algorithm 422 (even if the node knows the receiver will not be able to verify 423 the Signature Algorithm). If the set is not empty, the receiving 424 node will choose among the set one of the algorithms in order to 425 generate a Universal Signature Option. 427 o when the 'R' flag is set, the receiver checks if it supports any 428 of sender's supported signature algorithms. If more than one 429 signature algorithms is found to be mutually supported, the 430 receiver MAY decide to use the sender's most preferred one 431 according to the order of appearance in the aforementioned NDP 432 option. In any case, if at least one mutually supported signature 433 algorithm exists, the receiver uses one of these algorithms to 434 generate a Universal Signature Option for protection of the resent 435 packet. This resent packet contains the same information that the 436 other node couldn't verify (except for the signature). If the 'R' 437 flag is set, and if no matching signature algorithm is found, the 438 receiver processes the packet as if the 'R' flag was not set. 440 4. SEND Universal Signature Option 442 We propose replacing the RSA Signature Option by a new algorithm- 443 independent signature option. The "Universal Signature Option" is an 444 updated version of the RSA Signature Option, that allows a node to 445 specify which of its potential multiple keys it is using. To achieve 446 this, we use the 16-bits reserved field of the RSA Signature Option, 447 and define a new 8-bit field that contains the position of the Public 448 Key associated with the signature and a new 5-bit Signature Type 449 Identifier field that details the type of algorithms used to generate 450 the Digital Signature. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | Key Position | Res.| Sig ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 | Key Hash | 459 | | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 . . 464 . Digital Signature . 465 . . 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 . . 470 . Padding . 471 . . 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 2: Signature Option format 477 Type 479 Same value as in [RFC3971]: 12. 481 Length 483 The length of the option (including the Type, Length, Reserved, 484 Key Hash, Digital Signature, and Padding fields) in units of 8 485 octets. 487 Key Position 489 An 8-bit field indicating which Public Key in the CGA parameter 490 structure (carried in the CGA option) has been used to compute the 491 Digital Signature. The index starts at 0, meaning the key is the 492 one in the Public Key field. Values over 1 refer to Public Key 493 found in the CGA Extension field (as defined in the companion 494 document [cheneau-cga-pk-agility]]). 496 Reserved 498 A 3-bit field reserved for future use. The value MUST be set to 499 zero by the sender and MUST be ignored by the receiver. 501 Signature Type Identifier 503 Signature Type Identifier is a 5-bit field. It corresponds to the 504 Signature Algorithm field in the Supported Signature Algorithm 505 option. It indicates the type of Signature contained in the 506 Digital Signature field. 508 Key Hash 510 The Key Hash field is a 128-bit field containing the most 511 significant (leftmost) 128 bits of a hash function of the public 512 key used. If the Signature Type Identifier value is 0 then this 513 field is a is computed using SHA-1 value of the public key used 514 for constructing the signature. This Key Hash is computed the 515 same way as the Key Hash in RSA Signature Option described 516 [RFC3971]. If the Signature Type Identifier value is different 517 than 0 then this field is computed using SHA-256 [FIPS.180-2] 518 value of the public key used for constructing the signature. The 519 SHA-256 hash is computed over the presentation used in the Public 520 Key field of the CGA Parameters data structure carried in the CGA 521 option. Its purpose is to associate the signature with a 522 particular key known by the receiver. Such a key can either be 523 stored in the certificate cache of the receiver or be received in 524 the CGA option in the same message. 526 Digital Signature 528 A variable-length field containing a signature constructed by 529 using the sender's private key associated to the public key 530 pointed by the Key Position field. The signature type is 531 determined from the value of the Signature Type Identifier field. 532 If the value of the Signature Type Identifier field is 0, then the 533 Key Position field must be set to 0 and this Digital Signature 534 field is computed the same way as the Digital Signature field of 535 the RSA Signature Option described in [RFC3971]. If the value of 536 the Signature Type Identifier field is 1, then this Digital 537 Signature field is computed the same way as the Digital Signature 538 field of the RSA Signature Option described in [RFC3971] except 539 that the signature is computed with the RSASSA-PKCS1-v1_5 540 algorithm and the SHA-256 hash, as defined in [PKCS1]. If the 541 value of the Signature Type Identifier field is 2, then this 542 Digital Signature field is computed using the ECDSA signature 543 algorithm (as defined on [SEC1]) and SHA-256 on the following 544 datas: 546 1. The 128-bit CGA Message Type tag [RFC3972] value for SEND, 547 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has 548 been generated randomly by the editor of the [RFC3971] 549 specification.). 551 2. The 128-bit Source Address field from the IP header. 553 3. The 128-bit Destination Address field from the IP header. 555 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 556 the ICMP header. 558 5. The NDP message header, starting from the octet after the ICMP 559 Checksum field and continuing up to but not including NDP 560 options. 562 6. All NDP options preceding, but not including, any of the 563 Universal Signature options. 565 This field starts after the Key Hash field. The length of the 566 Digital Signature field is determined by the length of the 567 Universal Signature option minus the length of the other fields 568 (including the variable length Pad field). 570 Padding This variable-length field contains padding, as many bytes 571 long as remain after the end of the signature. 573 A Neighbor Solicitation/Advertisement, Router Solicitation/ 574 Advertisement and Redirect message MAY contain more than one 575 Universal Signature Option, as long as it does not exceed the MTU. 576 This is particularly useful for routers operating in heterogeneous 577 networks, where hosts have a disjoint set of supported signature 578 algorithms. 580 4.1. Processing Rules for Senders 582 When sending a SEND message spontaneously or in response to message 583 with the 'R' flag cleared in the Supported Signature Algorithm 584 Option, an emitter node CAN choose a signature algorithm of its 585 preference (defined by local policy) among the corresponding Public 586 Keys carried in the CGA option. Using this signature algorithm, the 587 node computes the Digital Signature and fills the Key Position field 588 with the position of the key in the CGA parameter data structure. 590 If the node has been configured to use SEND, then all Neighbor 591 Solicitation, Neighbor Advertisement, Router Advertisement, and 592 Redirect messages MUST contain at least one Universal Signature 593 option. Router Solicitation messages not sent with the unspecified 594 source address MUST contain the Universal Signature option. 596 A node sending a message with one or more Universal Signature option 597 MUST construct the message as follows: 599 o If the node as previously received hints (e.g. an NDP message with 600 a Supported Signature Algorithm option and the 'R' flag on) on the 601 type of Signature Algorithm it should use, it MUST restrain its 602 choice on those Signature Algorithm. its choice on those Signature 603 Algorithm. 605 o The message is constructed in its entirety, without any of the 606 Universal Signature options. 608 o The Universal Signature option(s) is (are) added as the last 609 option in the message. 611 o The data to be signed is constructed as explained in Figure 2, 612 under the description of the Digital Signature field. 614 o The message, in the form defined above, is signed by using the 615 configured private key associated to the selected Signature 616 Algorithm, and the resulting signature is put in the Digital 617 Signature field. When using RSA, this signature is a PKCS#1 v1.5 618 signature. When using ECDSA, the signature value is as defined in 619 [FIPS-186-3]. The length of the Digital Signature field is 620 determined by the length of the Universal Signature option minus 621 the length of the other fields (including the variable length 622 Padding field). 624 4.2. Processing Rules for Receivers 626 Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, 627 and Redirect messages without any Universal Signature option MUST be 628 treated as unsecured (i.e., processed in the same way as NDP messages 629 sent by a non-SEND node). See Section 8 of [RFC3971]. 631 Router Solicitation messages without any Universal Signature option 632 MUST also be treated as unsecured, unless the source address of the 633 message is the unspecified address. 635 Redirect, Neighbor Solicitation, Neighbor Advertisement, Router 636 Solicitation, and Router Advertisement messages containing one or 637 more Universal Signature option MUST be checked as follows: 639 o The receiver MUST ignore any options that come after the first 640 Universal Signature option. (The options are ignored for both 641 signature verification and NDP processing purposes.) 643 o The Key Hash field MUST correspond to a known public key, either 644 one learned from the CGA option in the same message by the 645 position indicated in the Key Position field message, or one known 646 by other means. 648 o The Digital Signature field MUST have correct encoding and MUST 649 not exceed the length of the Universal Signature option minus the 650 Padding. 652 o The Digital Signature verification MUST show that the signature 653 has been calculated as specified in the previous section . 655 o If the use of a trust anchor has been configured, a valid 656 certification path (see Section 6.3 of [RFC3971]) between the 657 receiver's trust anchor and the sender's public key MUST be known. 659 When checks fail due to an unsupported signature algorithm type, and 660 if the Supported Signature Algorithm Option of the message shows that 661 a common Signature Algorithm is available, the node MUST send back a 662 packet to indicate to the emitter that the packet needs to be resent. 663 Depending on the received packet, the node will have to send: 665 o A Router Solicitation if the message was a Router Advertisement or 666 Redirect message; or 668 o A Neighbor Solicitation is the message was a Neighbor 669 Advertisement or a Neighbor Solicitation (e.g. during the DAD 670 procedure) 672 Messages that do not pass all the above tests MUST be silently 673 discarded if the host has been configured to accept only secured ND 674 messages. The messages MAY be accepted if the host has been 675 configured to accept both secured and unsecured messages but MUST be 676 treated as unsecured messages. The receiver MAY also otherwise 677 silently discard packets (e.g., as a response to an apparent CPU 678 exhausting DoS attack). 680 5. Basic negotiation 682 5.1. Overview 684 Two nodes sharing a common Signing Algorithm must be able to securely 685 communicate. Below is an example of such a message flow. 687 Node A Node B 689 NS 690 {CGA option, 691 RSA Signature option. 692 Supported-Signature-Algo option 693 (RSA, ECC, R=0)} --------> 694 NA 695 {CGA option, 696 ECC Signature option 697 Supported-Signature-Algo option 698 <-------- (ECC, R=1)} 699 NA 700 {CGA option, 701 ECC Signature option. 702 Supported-Signature-Algo option 703 (RSA, ECC, R=0)} --------> 705 IPv6 traffic <-------> IPv6 traffic 707 Basic Negotiation- Case 1 709 When both nodes support the same two algorithms, then we have the 710 following case: 712 Node A Node B 714 NS 715 {CGA option, 716 RSA Signature option. 717 Supported-Signature-Algo option 718 (RSA, ECC, R=0)} --------> 719 NA 720 {CGA option, 721 ECC Signature option 722 Supported-Signature-Algo option 723 <-------- (ECC, RSA, R=0)} 725 IPv6 traffic <-------> IPv6 traffic 727 Basic Negotiation- Case 2 729 6. Router-as-a-notary function 731 This optional functionality enhances backward compatibility by 732 introducing a new entity. Here, the entity named "notary" serves to 733 certify the authenticity of a node's message. This improves 734 communication when two nodes have a disjoint set of supported 735 Signature Algorithm types and still require secure neighbor 736 discovery. 738 In this specification, the notary function is offered by routers, 739 although other nodes may offer this capability in the future. 740 Authorization for the router to act as a notary is provided through 741 router's certificate (could be store in a KeyPurposeID as defined in 742 [krishnan-cgaext-send-cert-eku]) provided by the trust anchor. 744 The notary function requires the two specific messages: Signature 745 check request and signature status. 747 6.1. Signature check request message 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Code | Packet Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Checksum | Reserved | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Request ID. | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 + SEND secured packet + 759 | (NDP packets should fit completely) | 761 Signature check request message format 763 Type 765 TBA. 767 Code 769 TBA. 771 Packet Length 773 Packet length is the size of the SEND secured packet 775 Checksum 777 Checksum is a CRC-16 of the whole packet. During the CRC-16 778 computation, this field is set to 0. The purpose of this field is 779 to quickly invalidate transmission errors. 781 Reserved 783 This 16-bit field is reserved. MUST be set to 0 by senders and 784 ignored by receivers. 786 Request Identifier 788 Request Identifier helps matching a signature check request and 789 the signature status (response) messages. Request Identifier 790 field is randomly generated. 792 SEND secured packet 794 SEND secured packet is the packet that the node was not able to 795 verify on his own, subject of the verification. Note that the 796 encapsulated packet MUST not make the whole Signature Check 797 Request message exceed the MTU (as no fragmentation support is 798 available). 800 This message is protected by usual SEND NDP options (TS, Nonce, 801 Signature). It contains the whole packet that the node wants to be 802 checked on the router (so packet may not be tampered with). 804 A router acting as notary processes the packet this way: 806 o Verifies the CGA of the emitter 808 o Verifies the signature of the message (linked to CGA of the source 809 address) 811 o Verifies the CGA and signature of the inner packet 813 o Responds with a Signature status message (defined in the following 814 section) 816 6.2. Signature status message 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Type | Code | Status | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Request ID. | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Signature status message format 828 Type 830 TBA. 832 Code 834 TBA. 836 Status 838 The 16-bit status field can be set to any of the following values: 840 0: all validation checks passed 842 1: inner packet CGA verification check failed 844 2: inner packet signature verification check failed 846 3: unsupported hash algorithm (to compute Hash1/Hash2) 848 4: unsupported Public Key algorithm 850 5: ask later (router is busy) 852 Request Identifier 854 The Request Identifier helps match a signature check request and 855 the signature status (response) message. The Request Identifier 856 is copied from the Signature Check Request message. 858 This message is a response to a Notary signature check request 859 message and is protected by SEND options generated using the public 860 key contained in the certificate of the router authorized to act as 861 notary. On reception of this message, a node performs CGA check and 862 Universal Signature option check . Then, if the status message is 0, 863 that node can now trust the original packet that created the need for 864 a Notary signature check request message. This amounts to resuming 865 the SEND protocol using secure packets. On a status value different 866 from 0, the packet will be considered as unsecure and be treated as 867 such. 869 7. Security Considerations 871 Section 4 presents a new Universal Signature Option. A recommended 872 use of this option is to allow signatures of equivalent security 873 level (i.e. Public Keys with equivalent key lengths, see section 4 874 of the companion draft [cheneau-cga-pk-agility]). 876 The Universal Signature Option is vulnerable to downgrade attacks. 877 That is, given that a node can employ multiple signature types, an 878 attacker may choose to use a flawed one. To mitigate this issue, 879 nodes are allowed, on a local policy, to refuse to check certain 880 types of signature (i.e. those which are know to be flawed) and will 881 treat the associated messages as unsecured. 883 To be completed. 885 8. IANA Considerations 887 This document requests IANA to allocate types for the two new notary 888 ICMP messages. 890 9. Acknowledgments 892 The authors gratefully acknowledge the contributions of Marcello 893 Bagnulo-Braun, and other participants of the SEND working group. 895 10. References 897 10.1. Normative References 899 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 900 RFC 3972, March 2005. 902 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 903 Neighbor Discovery (SEND)", RFC 3971, March 2005. 905 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 906 Algorithms in Cryptographically Generated Addresses 907 (CGAs)", RFC 4982, July 2007. 909 [cheneau-cga-pk-agility] 910 Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. 911 Vanderveen, "Support for Multiple Signature Algorithms in 912 Cryptographically Generated Addresses (CGAs)", 913 draft-cheneau-cga-pk-agility-00 (work in progress), 914 Feb 2009. 916 10.2. Informative References 918 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 919 Addresses (CGA) Extension Field Format", RFC 4581, 920 October 2006. 922 [krishnan-cgaext-send-cert-eku] 923 Krishnan, S., Kukec, A., and K. Ahmed, "Certificate 924 profile and certificate management for SEND", 925 draft-krishnan-cgaext-send-cert-eku-02 (work in progress), 926 November 2008. 928 [FIPS-186-3] 929 National Institute of Standards and Technology, "Draft 930 Digital Signature Standard", FIPS PUB 186-3, March 2006. 932 [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 933 PKCS 1, November 2002. 935 [FIPS.180-2] 936 National Institute of Standards and Technology, "Secure 937 Hash Standard", FIPS PUB 180-2, August 2002, . 940 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 941 Elliptic Curve Cryptography", September 2000, 942 . 944 Authors' Addresses 946 Tony Cheneau 947 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 948 9 rue Charles Fourier 949 Evry 91011 950 France 952 Email: tony.cheneau@it-sudparis.eu 954 Maryline Laurent-Maknavicius 955 Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157 956 9 rue Charles Fourier 957 Evry 91011 958 France 960 Email: maryline.maknavicius@it-sudparis.eu 962 Sean Shen 963 Huawei 964 No. 9 Xinxi Road 965 Beijing 100085 966 China 968 Email: sshen@huawei.com 970 Michaela Vanderveen 971 Qualcomm 973 Email: mvandervn@gmail.com