idnits 2.17.1 draft-dong-savi-cga-header-03.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5036 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: 'RFC3704' is defined on line 776, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft P. Nallur 4 Intended status: Standards Track Huawei Symantec 5 Expires: January 13, 2011 M. Wasserman 6 Painless Security 7 July 12, 2010 9 Cryptographically Generated Address (CGA) Extension Header for Internet 10 Protocol version 6 (IPv6) 11 draft-dong-savi-cga-header-03.txt 13 Abstract 15 This document specifies an IPv6 extension header called the 16 Cryptographically Generated Address (CGA) Extension Header. The CGA 17 Extension Header holds the CGA parameters associated with the source 18 CGA of an IPv6 packet. This information can be used to validate that 19 a particular packet was sent by the node associated with a specific 20 CGA, enabling secure IPv6 address-based access control mechanisms. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 70 3. Secure Node-Based Access Control . . . . . . . . . . . . . . . 4 71 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Issues with the CGA Extension Header . . . . . . . . . . . . . 6 73 5. CGA Extension Header Definition . . . . . . . . . . . . . . . 6 74 6. CGA Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. CGA Request . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.2. CGA Params . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.3. CGA Signature . . . . . . . . . . . . . . . . . . . . . . 9 78 7. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Sending a CGA Request . . . . . . . . . . . . . . . . . . 10 80 7.2. Receiving a CGA Request . . . . . . . . . . . . . . . . . 10 81 7.3. Sending CGA Params . . . . . . . . . . . . . . . . . . . . 11 82 7.4. Sending a CGA Signature . . . . . . . . . . . . . . . . . 11 83 7.5. Receiving CGA Params and CGA Signature . . . . . . . . . . 11 84 8. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.1. Verification Failure . . . . . . . . . . . . . . . . . . . 12 86 8.2. Option Errors . . . . . . . . . . . . . . . . . . . . . . 13 87 9. Source Address Verification . . . . . . . . . . . . . . . . . 13 88 9.1. Initiator Verifying Responder's Address . . . . . . . . . 13 89 9.2. Responder Verifying Initiator's Address . . . . . . . . . 13 90 9.3. Bidirectional Verification . . . . . . . . . . . . . . . . 14 91 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . . 15 93 10.2. Strength of Security . . . . . . . . . . . . . . . . . . . 15 94 10.3. Costs of Verification . . . . . . . . . . . . . . . . . . 15 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 14.2. Informative References . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 A Cryptographically Generated Address (CGA) is an IPv6 address that 105 has been generated using a cryptographic key [RFC3972]. CGAs were 106 originally designed for use in the SEcure Neighbor Discovery (SEND) 107 protocol [RFC3971], where they are used to verify that SEND messages 108 have been signed by their source CGA owners without the need for any 109 additional security infrastructure. The SEND verification mechanism 110 depends on a set of CGA parameters that are associated with each CGA 111 and included in every SEND packet. 113 This document specifies a method to carry CGA parameters in an IPv6 114 extension header to allow similar verification of IPv6 source CGAs 115 across the Internet. This document specifies the details of an IPv6 116 CGA Extension Header containing the CGA parameters and ICMP message 117 to report related errors. The CGA parameters can be used by any host 118 along the path to verify that an IPv6 packet was sent by the owner of 119 the source CGA. 121 2. Requirements Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Secure Node-Based Access Control 129 A node-based (or IP address-based) access control list (ACL) 130 conceptually consists of a list of nodes, specified by IP addresses 131 or fully-qualified domain names (FQDNs). The ACL indicates which 132 nodes are authorized to access a resource or perform a task. The 133 IETF discourages the use of node-based ACLs, because they are 134 inherently insecure -- it is trivial, in many cases, to send a packet 135 from one node that uses the IP source address of another node. 136 However, ACLs are still widely used in networks today, because of 137 their conceptual simplicity and their ease of configuration. 139 By using the IPv6 CGA Extension header to verify that an IPv6 packet 140 was sent by the node that owns the source IP address in use, it is 141 possible to greatly improve the security of a traditional ACL. 142 Without any additional security infrastructure or configuration, it 143 is possible to securely verify that a packet was sent by the node 144 that owns the authorized IPv6 source address. 146 Given the ability to verify that a particular packet was sent by the 147 owner of its source CGA, it may also be possible to simplify or 148 improve other types of access control mechanisms. 150 3.1. Use Cases 152 Some example use cases for the CGA Extension Header include: 154 o Printer access control lists (ACLs), or similar ACLs, could be 155 configured with a list of IP addresses. Access from a specific 156 node would be authorized by placing a CGA owned by that node into 157 the ACL. Nodes that wish to gain access would use their 158 authorized CGA as the source address of a packet containing the 159 CGA Extension Header, and the mechanism described in this document 160 would be used to verify that each access attempt originated with 161 the owner of the source CGA, before that CGA is checked against 162 the ACL, and appropriate access is granted. This would 163 substantially improve the security of simple ACLs, without 164 requiring additional configuration, and without requiring any 165 additional security infrastructure. 167 o Multicast replicators could be configured with a set of authorized 168 CGA addresses. Packets would not be replicated unless the source 169 address was verified, thus preventing the flooding of unauthorized 170 flows. 172 o In cellular or wireless networks with limited radio bandwidth, the 173 edge node that interfaces between the radio network and the 174 wireline network could verify the signature in each packet. 175 Unverified packets could be dropped, conserving valuable 176 bandwidth. 178 o This mechanism could be used to validate that syslog messages or 179 SNMP traps have been received from an authorized sender before 180 logging them to disk or taking any corresponding action. 182 o RADIUS configuration for infrastructure nodes (routers, switches, 183 etc.) could be substantially simplified. There are no individual 184 users on most of these devices, and today many RADIUS servers are 185 configured to share a password between a set of devices, thus 186 compromising security. Instead, configuration could be reduced to 187 configuring a list of CGA addresses for which access should be 188 allowed. 190 o Dynamic DNS updates could be substantially simplified for CGA 191 addresses, as it should be possible to allow the verified owner of 192 a CGA to update the corresponding entry directly. 194 All of the examples above would require implementation changes in 195 order to take effect. In some cases, such as the RADIUS and DDNS 196 cases, protocol changes would also be required. 198 4. Issues with the CGA Extension Header 200 The CGA Extension Header mechanism does have a few limitations that 201 affect its applicability in some cases. Specifically: 203 o CGA addresses only offer limited security. The cryptographic 204 strength of CGA addresses makes it 2**59 times harder to forge an 205 address than to generate a new address. This mechanism should 206 only be used in cases where that level of security is acceptable 207 and/or represents a considerable improvement over current 208 practice. 210 o Using CGAs, it is necessary to specify each CGA separately in an 211 access control list, as opposed to assigning address ranges. It 212 doesn't work to assign address ranges because the prefix portion 213 of a CGA is not cryptographically generated, and CGA IIDs are 214 randomly distributed across the IID space. 216 o CGA verification is a costly process. There is a substantial cost 217 on the sender side to generate the per-packet signature, and a 218 similar cost on the receiving side to perform the verification. 219 The utility of this mechanism is limited to cases where those 220 costs are justified and/or acceptable. 222 Some ideas about how to address the above issues are discussed in the 223 "Discussion" section below. 225 5. CGA Extension Header Definition 227 The base IPv6 specification [RFC2460] defines several extension 228 headers and makes recommendations about how future extension headers 229 should be defined. It also makes recommendations about the order in 230 which extension headers should appear in IPv6 packets. 232 An IPv6 node that implements the CGA Extension Header defined in this 233 document would be expected to implement, at minimum, the following 234 IPv6 Extension Headers: 236 Hop-by-Hop Options Header 238 Destination Options Header 240 Routing Header 242 Fragment Header 243 CGA Extension Header 245 Authentication Header 247 Encapsulating Security Payload Header 249 Destination Options Header 251 Upper-Layer Header 253 When more than one extension header appears in an IPv6 packet, it is 254 recommended that they appear in the order indicated above. Note that 255 the CGA Extension header is currently defined to appear inside the 256 Fragment Header. This has the implication that intermediate nodes 257 cannot count on receiving a full CGA Extension Header in an IPv6 258 fragment. The trade-offs related to this choice are discussed in the 259 "Discussion" section below. 261 The CGA Extension Header MUST NOT be displayed in the extension 262 header of a packet more than once. 264 The CGA Extension Header is comprised of the following fields: 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Next Header | Hdr Ext Len | Reserved | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 . . 273 . Options . 274 . . 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Next Header 8-bit selector. Identifies the type of the header 278 immediately following the CGA Extension Header. 279 Hdr Ext Len 8-bit unsigned integer. Length of the header 280 in 8-octet units, excluding the first 8 octets. 281 When the value of Hdr Ext Len is zero, it means 282 that this information is for CGA initialization. 283 Reserved A 16-bit field reserved for future use. The value 284 MUST be initialized to zero by the sender and MUST 285 be ignored by the receiver. 286 Options Variable-length field. The length of this field, 287 in octets, is determined by multiplying the value 288 of the "Hdr Ext Len" field by 8 and adding 4. 289 Contains one or more TLV-encoded options, as described 290 in section 4.2 of [RFC2460]. 292 The Options field contains three types of options: a CGA Request, CGA 293 Params and/or a CGA Signature. A CGA Request is used to ask the 294 counterpart for CGA Params; the CGA Params option carries a CGA 295 parameters data structure; and a CGA Signature contains the signature 296 produced by the host using its private key. CGA Params MUST be 297 accompanied with a CGA Signature, otherwise the receiver SHOULD 298 respond with an ICMP error message. A packet MAY include CGA 299 Signature only when CGA Params is sent. How the node handles the CGA 300 Params in the packet before receiving CGA Request depends on the 301 host's policy. 303 6. CGA Options 305 6.1. CGA Request 307 Any node can ask its peer for CGA Params by sending a CGA Request in 308 the packet. The node that receives a packet containing a CGA 309 Request, MAY respond with its own CGA Params and CGA Signature. A 310 CGA Request has the following format: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Type 8-bit unsigned integer. Type code for CGA Request. 320 The value is TBD2. 321 Length The length of the option (including the Type, 322 Length, Reserved and Sequence Number) in units of 323 byte. 324 Reserved An 24-bit field reserved for future use. The value 325 MUST be initialized to zero when sending, and 326 SHOULD be ignored on receipt. 327 Sequence Number 32-bit unsigned integer containing a counter value 328 that is initialized to a random number and increases 329 by one for each packet sent. It may enable an 330 anti-replay service. 332 6.2. CGA Params 334 The CGA Params option carries CGA parameters that the receiver can 335 use to validate the source CGA. The format of the CGA Params is 336 described in the following diagram: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | Pad Length | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Sequence Number | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 . . 347 . CGA Parameters . 348 . . 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 . Padding . 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Type 8-bit unsigned integer. Type code for CGA Params. 356 The value is TBD3. 357 Length 8-bit unsigned integer. The length of the option 358 (including the Type, Length, Pad Length, Reserved, 359 Sequence Number, CGA Parameters, and Padding 360 fields) in 8-octet units. 361 Pad Length 8-bit unsigned integer. The number of padding 362 octets beyond the end of the CGA Parameters field 363 but within the length specified by the Length 364 field. 365 Reserved An 8-bit field reserved for future use. The value 366 MUST be initialized to zero by the sender and MUST 367 be ignored by the receiver. 368 Sequence Number 32-bit unsigned integer. If the CGA Params 369 option was sent in response to a CGA Request, 370 this field matches he sequence number in the 371 request. Otherwise, it SHOULD be set to zero. 372 CGA Parameters A variable-length field containing the CGA 373 Parameters data structure described in Section 2 374 of [RFC3972]. 375 Padding A variable-length field making the option length a 376 multiple of 8, containing as many octets as 377 specified in the Pad Length field. The contents of 378 padding MUST be set to zero on sending and 379 ignored on receipt. 381 6.3. CGA Signature 383 The CGA Signature option contains the digital signature calculated by 384 he sender. It is formatted as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Pad Length | Reserved | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 . . 393 . Signature . 394 . . 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 . Padding . 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Type 8-bit unsigned integer. Type code for CGA 402 Signature. The value is TBD4. 403 Length The length of the option (including the Type, 404 Length, Pad Length, Reserved, Sequence Number, CGA 405 Signature, and Padding fields) in units of 8-octets. 406 Pad Length 8-bit unsigned integer. The number of padding 407 octets beyond the end of the CGA Signature field 408 but within the length specified by the Length field. 409 Reserved 8-bit unsigned integer. An 8-bit field reserved for 410 future use. The value MUST be initialized to zero 411 by the sender and MUST be ignored by the receiver. 412 Signature A variable-length field containing the signature 413 which is produced by the private-key. 414 Padding A variable-length field making the option length a 415 multiple of 8, containing as many octets as 416 specified in the Pad Length field. The contents 417 MUST be set to zero when sending and MUST be 418 ignored on receipt. 420 7. Packet Processing 422 This section describes how CGA Extension Headers are generated and 423 processed. 425 7.1. Sending a CGA Request 427 To send a CGA Request packet, the host generates a new Sequence 428 Number, and formats the packet as described in section 3.1. 430 7.2. Receiving a CGA Request 432 When a host receives a packet containing a CGA Request, it MAY send 433 CGA Params and CGA Signature to its peer as a response. Whether or 434 not to send a response is determined by local policy or 435 configuration. 437 If the host responds to the CGA Request, it must set the Sequence 438 Number of the CGA Params option to the Sequence Number received in 439 the CGA Request. 441 7.3. Sending CGA Params 443 The CGA parameters should be generated using the procedure defined in 444 Section 4 of [RFC3972]. The public key carried in the CGA Params 445 must correspond to the private key used to generate the digital 446 signature. 448 7.4. Sending a CGA Signature 450 When sending a CGA Signature, the host must calculate the digital 451 signature value using the procedure described here. 453 The contents to be signed contain the following parts concatenated 454 from left to right: 456 1. The CGA Extension Header signature type tag (128-bits); 458 2. The 128-bit source address in the IP header; 460 3. The 128-bit destination address in the IP header; 462 4. All parts of CGA Extension Header except the CGA Signature; 464 5. The payload of the packet (transport and higher layers). 466 The resulting data is signed using an RSA signature, and the 467 signature is placed in the Signature field. The signature is 468 generated largely as described in [RFC3971] section 5.2. TBD: Need 469 to describe the procedure in detail and specify a signature type tag 470 for the CGA Extension Header here. Pick up algorithm agility work 471 from CSI? 473 7.5. Receiving CGA Params and CGA Signature 475 After the host receives the packet with CGA Params and CGA Signature, 476 it MAY verify the signature, thus authenticating the source CGA. 477 Whether or not the host performs the verification procedure on a 478 specific packet is based on policy and/or configuration. The 479 verification procedure consists of the following steps: 481 1. If a host receives a packet corresponding to an outstanding CGA 482 Request, it checks if the Sequence Number is zero (meaning this 483 is not a response). If so, it continues to the next step. If 484 the Sequence number is non-zero, it compares the received 485 Sequence Number with the Sequence Numbers of recently sent CGA 486 Requests. If the Sequence Number matches a previous request, go 487 to the next step. Otherwise, the host MUST drop the packet and 488 send an ICMP message. 490 2. The host MAY use the CGA parameters and signature to verify the 491 source CGA of the packet. The verification procedure is given in 492 Section 5 of [RFC3972]. If the verification succeeds, go to the 493 next step. Otherwise, the host MUST drop the packet, which leads 494 to the generation of an ICMP message. 496 3. The inputs of the signature verification operation are the public 497 key, which is a part of the CGA parameters data structure, the 498 concatenation created in Section 3.1 and the signature. If the 499 signature verification succeeds, the host should continue to 500 process the packet as usual. If it fails, the host MUST drop the 501 packet and send an ICMP message. 503 Certain errors MAY result in dropping the packet and sending ICMP 504 messages: 506 1. The CGA header contains only CGA Params rather than CGA 507 Signature; 509 2. The CGA header contains only CGA Signature rather than CGA 510 Params; 512 3. The host sends the CGA Request, however, the returned packet does 513 not contain CGA Params and CGA Signature. 515 8. ICMP Messages 517 TBD: ICMP errors and related behavior will need to be defined in more 518 detail. 520 When the CGA header of IPv6 is deployed and certain errors occur, 521 ICMP messages are required to report errors to the source host. In 522 addition to the problems described in [RFC4443], CGA header has 523 following types of errors. 525 8.1. Verification Failure 527 Verification failure MAY be caused by the following: 529 1. Sequence Number error; 531 2. CGA verification error; 533 3. Signature verification error. 535 8.2. Option Errors 537 The three type option errors described at the end of Section 4.2 also 538 MAY generate ICMP messages. 540 9. Source Address Verification 542 This mechanism supports both one-way and bi-directional verification. 543 In this section, we denote the two ends of the verification process 544 as the Initiator and the Responder, and we present all three 545 verification scenarios. 547 9.1. Initiator Verifying Responder's Address 549 The following picture shows a typical exchange when the initiator 550 verifies the address of the responder. 552 Initiator Responder 554 CGA Request 555 --------------------------> 557 CGA Params, CGA Sig 558 <------------------------- 560 The initiator sends CGA Request in the message to require the CGA 561 parameters of the responder. After receiving the request, the 562 responder returns its own CGA Params and CGA Signature to the 563 initiator. The processing rules and verification process are given 564 in Section 4.1 and Section 4.2 respectively. 566 9.2. Responder Verifying Initiator's Address 568 The responder can also verify the address of the initiator. 569 Conceptually, the process can be represented by the following message 570 sequence. 572 Initiator Responder 574 NULL CGA HEADER 575 --------------------------> 577 CGA Request 578 <------------------------- 580 CGA Params, CGA Sig 581 --------------------------> 583 A packet with a NULL CGA Extension Header coming from the initiator 584 implies that the initiator may support CGA verification. After 585 receiving the null CGA Extension Header, the responder sends a CGA 586 Request to the initiator. Then the initiator sends its CGA Params 587 and CGA Signature in a response, which is used to verify the 588 initiator's address by the responder. 590 9.3. Bidirectional Verification 592 In certain cases, the hosts need to verify the address of each other. 593 The figure below illustrates the basic exchange. 595 Initiator Responder 597 NULL CGA HEADER 598 --------------------------> 600 CGA Request 601 <------------------------- 603 CGA Params, CGA Sig, CGA Request 604 --------------------------> 606 CGA Params, CGA Sig, 607 <------------------------- 609 A packet with null CGA Extension Header coming from the initiator 610 implies that the sender may support CGA verification. After 611 receiving the NULL CGA Extension Header in the message, the responder 612 sends CGA Request to the initiator. Then the initiator transfers the 613 message containing its CGA Params, CGA Signature and CGA Request. 614 The last message with CGA Params and CGA Signature of the responder 615 is to allow the initiator to verify the responder's address. 617 10. Discussion 619 There are a number of architectural issues and tradeoffs in the 620 design of this mechanism that might benefit from further discussion 621 and consideration. This section attempt to outline those issues at a 622 fairly high level in the hope of generating discussion within the 623 IETF on these topics: 625 10.1. MTU and Fragmentation Issues 627 As this document is currently written, the CGA Fragmentation Header 628 appears after the IPv6 Fragment Header. This allows us to avoid MTU 629 issues, because a long CGA Extension Header would be fragmented, as 630 necessary, to fit on the link. However, it means that intermediate 631 nodes are not guaranteed to see a full CGA Extension Header, 632 potentially limiting the use cases of this mechanism. If there is 633 interest in this approach, we should further discuss these tradeoffs. 635 10.2. Strength of Security 637 As discussed in Section 7.2 of RFC 3972, an attacker has to do 2**59 638 times as much work as the holder of a CGA in order to forge a given 639 CGA. This may provide inadequate security for many potential uses of 640 this mechanism. 642 There are some approaches that could be used to increase the security 643 strength of CGAs. For instance, it might be possible to increase the 644 length of the cryptographically-generated portion of the CGA, in 645 cases where the prefix length allow sufficient room to do so. It 646 might also be possible for higher-level protocols to introduce 647 additional bits of security into the algorithm. Work on these, or 648 other, approaches to increase the security of this mechanism could be 649 considered if there is interest in the general approach. 651 10.3. Costs of Verification 653 Generating and verifying the digital signatures are both high cost 654 operations. The costs of generating and/or verifying the source CGA 655 of every packet would make this mechanism too costly for many 656 applications. The mechanism includes the a method to explicitly 657 request this information, but there is no guidance on when/how to use 658 it. 660 It might be possible to use this mechanism in concert with another, 661 lower costs security mechanism. For example, the CGA Extension 662 Header could be used to verify that the remote node owns a particular 663 CGA before using that CGA to determine and IPsec SA that will be used 664 to protect the rest of the session. 666 The ability for a remote host to prompt a costly operation in a local 667 host by sending a single packet represents a potential DoS attack. 668 We might want to consider a preliminary challenge/response operation 669 or some other mechanism to ensure that prompting this operation in a 670 local host requires at least as much processing by the remote host. 672 11. Security Considerations 674 This specification defines a mechanism to use CGAs for access 675 control. The RSA signature in a packet can be used to confirm that 676 the packet is generated by the holder of the private key associated 677 with the CGA. If a resource is authorized to a CGA and the signature 678 is checked, then the node providing the resource has confidence that 679 the resource is being accessed by the holder of the CGA. 680 Implementations MUST provide a mechanism for indicating which 681 addresses require signatures and signature verification. The 682 security of authorization depends critically on the correct usage of 683 this mechanism. If an address is added to an access-control list but 684 not to the list of addresses requiring signature verification, then 685 an attacker may gain access to the protected resource by spoofing 686 this address. 688 Unlike a traditional IP-based access-control list, this mechanism 689 does not permit ranges of IP addresses. An attacker could 690 potentially generate an address within a given range and legitimate 691 users are unlikely to have addresses in any given range. For this 692 reason, security depends on authorizing each address separately. 694 As discussed in Section 7.2 of RFC 3972, an attacker has to do 2**59 695 times as much work as the holder of a CGA in order to forge a given 696 CGA. The work can be increased for an attacker at the expense of 697 making address generation harder for legitimate users. For some 698 applications, the work factor of 2**59 address generations to forge a 699 given address may provide insufficient security. The CGA extension 700 header is not a good approach for these applications. 702 Section 7.4 of RFC 3972 discusses security concerns when CGAs are 703 used for protocols other than SEND. Of particular note, RSA keys of 704 384-bits are inappropriate for the CGA extension header. Keys of at 705 least 2048-bits in length SHOULD be used. 707 This mechanism only secures access-control based on IP address. If 708 another insecure mechanism is used to determine authorized source 709 addresses, then attacks on that mechanism result in attacks on the 710 authorization. For example if DNS is used to lookup the addresses of 711 nodes to populate an access-control list, then attacks on the 712 integrity of DNS will result in attacks of the security of this 713 mechanism used along-side DNS. 715 CGA extension header signatures can be expensive to verify. 716 Understanding how to prevent denial of service attacks against the 717 CGA header mechanism is ongoing work. 719 12. IANA Considerations 721 This document specifies a new type of IPv6 extension header, whose 722 value is to be allocated: 724 Value Next Header Name Reference 725 ------ ------------------------------- --------- 726 TBD1 CGA Header [this doc] 728 This document defines three new options in the CGA Header. A new 729 namespace is required to be assigned by IANA and the values of these 730 options are to be allocated: 732 Value Option Name Reference 733 ------ ------------------------------- --------- 734 TBD2 CGA Request [this doc] 735 TBD3 CGA Params [this doc] 736 TBD4 CGA Signature [this doc] 738 The above assignation of the three CGA options SHOULD also be used in 739 destination extension header and identified by the any host. 741 This document also defines two new types of ICMP messages whose 742 values are to be allocated from the namespace of ICMP Type Numbers: 744 Value Name Reference 745 ------ ------------------------------- --------- 746 TBD5 Verification Failure [this doc] 747 TBD6 Option Errors [this doc] 749 13. Acknowledgements 751 The authors would like to thank the following people for their 752 contributions to this document: Sam Hartman. 754 Margaret Wasserman's contributions to this document were funded by 755 Huawei Symantec. 757 14. References 759 14.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 765 (IPv6) Specification", RFC 2460, December 1998. 767 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 768 RFC 3972, March 2005. 770 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 771 Message Protocol (ICMPv6) for the Internet Protocol 772 Version 6 (IPv6) Specification", RFC 4443, March 2006. 774 14.2. Informative References 776 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 777 Networks", BCP 84, RFC 3704, March 2004. 779 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 780 Neighbor Discovery (SEND)", RFC 3971, March 2005. 782 Authors' Addresses 784 Dong Zhang 785 Huawei Symantec 786 3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi 787 HaiDian district, Beijing 788 China 790 Phone: +86-10-62721287 791 EMail: zhangdong_rh@huaweisymantec.com 793 Padmanabha Nallur 794 Huawei Symantec 795 20245 Stevens Creek Blvd., Suite 100 796 Cupertino, California 797 USA 799 EMail: paddy@huaweisymantec.com 801 Margaret Wasserman 802 Painless Security 803 356 Abbott Street 804 North Andover, MA 805 USA 807 Phone: +1-781-405-7464 808 EMail: mrw@painless-security.com