idnits 2.17.1 draft-popoviciu-dhc-certificate-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([4], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5905 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) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (ref. '3') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Popoviciu 3 Internet-Draft R. Droms 4 Expires: August 28, 2008 E. Levy-Abegnoli 5 Cisco Systems 6 February 25, 2008 8 DHCPv6 Delegation of Certificates Option 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Certificate options for DHCP-PD RFC3633 [4] provide a mechanism 43 to deliver, along with the IPv6 prefix, the certificate or the 44 information needed to obtain a certificate entitling the client 45 router to advertise the prefix delegated to it. This information is 46 neccesary if Secure Neighbor Discovery RFC3971 [6] is used by the 47 devices connected to the DHCP-PD client router. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Model and Applicability . . . . . . . . . . . . . . . . . . . 4 55 5. Identity Association for Prefix Delegation . . . . . . . . . . 7 56 6. Mode of Operation Overview . . . . . . . . . . . . . . . . . . 8 57 7. Delegating Server Solicitation . . . . . . . . . . . . . . . . 9 58 7.1. Requesting Router Behavior . . . . . . . . . . . . . . . . 9 59 7.2. Delegating Server Behavior . . . . . . . . . . . . . . . . 9 60 8. Requesting Router Initiated Prefix and Certificate 61 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 8.1. Requesting Router Behavior . . . . . . . . . . . . . . . . 10 63 8.2. Delegating Server Behavior . . . . . . . . . . . . . . . . 12 64 9. Delegating Server Triggered Reconfiguration . . . . . . . . . 12 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 The Prefix Delegation capabilities of Dynamic Host Configuration 76 Protocol (DHCP) offer a convenient mechanism to dynamically provision 77 a router and enable it to, in turn, provision the devices connected 78 to it. In the context of Secure Neighbor Discovery however, a router 79 must posses a digital certificate provided by a Certificate Authority 80 for the prefixes it advertises through Router Advertisements. In 81 this scenario, a receiving router needs to acquire the certificate 82 for the prefixes received via DHCP-PD. 84 This document describes new options for DHCP which enable or 85 facilitate the dynamic acquisition and management of certificates by 86 DHCP-PD clients for the prefixes delegated to them. In one use case 87 example, these options will be used by a Customer Premises 88 Equipment(CPE) router acting as the gateway between a subscriber's 89 network and the service provider network. The protocol extensions 90 proposed in this document can be leveraged in any environment where 91 dynamicaly provisioned routers must support SEND. 93 The mechanisms described in this document leverage DHCP which 94 operates under the authentication and security considerations 95 described in the DHCPv6 specification RFC3315 [3] and the DHCP-PD 96 specification RFC3633. In the context of SEND deployments however, 97 these considerations might not be sufficient and additional 98 functionality might be neccesary to ensure that certficates are 99 provided to the right router. In deployments, DHCP leverages various 100 mechanisms (DHCP snooping, anti-spoofing tools) to secure its 101 operation. These mechanisms should be taken into consideration as 102 well when analysing the security requirements of deploying the 103 enhancements proposed by this document. 105 2. Definitions and Terminology 107 For a complete specification of the options defined, this document 108 should be read in conjunction with the DHCPv6 (RFC3315) and DHCP-PD 109 (RFC3633) specifications. Definitions for terms and acronyms not 110 explicitly detailed in this document can be found in RFC3315. 112 This document uses the terminology defined in RFC2460 [2], RFC3315 113 and RFC3971. 115 This document also relies on the terminology and concepts defined in 116 RFC3779 [5] and RFC4211 [8], as well as the framework defined in 117 RFC4210 [7]. 119 3. Requirements 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 124 RFC 2119 defines the use of these key words to help make the intent 125 of standards track documents as clear as possible. While this 126 document uses these keywords, this document is not a standards track 127 document. 129 4. Model and Applicability 131 The environment in which the certificate DHCP options can be used is 132 similar to the typical DHCP-PD deployment environment and is shown in 133 Figure 1. A DHCP Delegating Server (DS) which can be located on the 134 aggregation device, in which case we have a Delegating Router (DR), 135 or somewhere in the network, provides a prefix to the Requesting 136 Router (RR). The requesting router subnets the prefix into /64 137 prefixes which it assigns to its own, subscriber facing interfaces. 138 It then advertises the /64 prefixes through RAs to enable hosts to 139 autoprovisioning themselves. 141 If the subscriber hosts are implementing SEND (RFC3971 and RFC3872), 142 the RR will have to use CryptoGraphic Addresses (CGA) to peer with 143 them. These addresses will be derived from an RSA key pair public/ 144 private. Before accepting the /64 prefix advertised by the RR, the 145 hosts will require a certificate from the RR, for the advertised 146 prefix. The RR will have to acquire a certificate corresponding to 147 its public key, including the prefix delegated to it, using X.509 148 extensions for IP addresses (RFC3779) A Certificate Authority (CA) 149 will provide the certificate which the RR can use to confirm that it 150 is allowed to advertise the /64 subnets over its subscriber facing 151 interface via router advertisements. 153 Figure 1 illustrates a deployment scenario which benefits form the 154 certificate options of DHCP. 156 ________ ______________________ ________ \ 157 | CA | / \ | DHCP | \ 158 |Server|----| ISP network |---|Server| \ 159 |______| \__________ ___________/ |______| | 160 | | 161 +-------+-------+ | 162 | Aggregation | | ISP 163 | device | | network 164 +-------+-------+ | 165 | / 166 |Access to subscriber / 167 |premises / 168 | 169 +------+------+ \ 170 | Requesting | \ 171 | Router | \ 172 +----+---+----+ \ | 173 | | | | Subscriber 174 ---+-------------+-----+- -+-----+-------------+--- | SEND | network 175 | | | | | | 176 +----+-----+ +-----+----+ +----+-----+ +-----+----+ / | 177 |Subscriber| |Subscriber| |Subscriber| |Subscriber| / 178 | PC | | PC | | PC | | PC | / 179 +----------+ +----------+ +----------+ +----------+ / 181 Figure 1 183 In the environment described in Figure 1, the delegating server can 184 be either the aggregating device (the gateway for the requesting 185 router) or a DHCP server located somewhere within its network. 187 While there are several mechanisms by which the RR can acquire the 188 certificate (manual provisioning, using a File System, SCEP, PKCS12, 189 HTTP or using Self-Signed certificates), their use would imply a less 190 dynamic CPE provisioning mechanism and additional control plane or 191 operational functions needed for the CA to learn and maintain the 192 state of prefixes allocated by the DHCP-PD server. Alternatively, 193 the distribution of the certificate can be facilitated by the DHCP-PD 194 server along with the process of delegating the prefix which has to 195 be certified. 197 With the DHCP certificate options, the DHCP-PD server can offer, upon 198 request, to intermediate the process of acquiring a certificate or to 199 provide the information needed by the RR to acquire the certificate 200 through an alternative mechanism. Since RR's clients can require 201 certificates originated in various certificate authorities, the 202 services requested and offered through this option must be related to 203 a certification chain trust anchor as described in RFC4210 [7]. 205 A DHCP server which ends up facilitating the certificate acquisition 206 (and not just providing a pointer) can be seen to be similar to the 207 Registration Authority (RA) entity described in RFC4210. Figure 2 208 shows the relationship between the subscriber PC, the Requesting 209 Router (RR), the Delegating Router (DR) and the Certificate Authority 210 (CA). Figure 2 also describes conceptually the message exchanges 211 that, along with the prefix delegation facilitate the acquisition of 212 a certificate. 214 +--+ C_provision(CA-cert) +--+ 215 | |<----------------------------------------------------------+ | 216 | | +---+ +--+ | | 217 |PC| |RR | |DS| |CA| 218 | | | |D_request(ID) | | | | 219 | | | +---------------->| | | | 220 | | | |D_reply(Pfx) | | | | 221 | | | |<----------------+ | | | 222 | | | |D_request(ID,key)| | | | 223 | | | +---------------->| |C_request(ID,key,Pfx) | | 224 | | | | | +--------------------->| | 225 | | | | | |C_reply(cert) | | 226 | | | |D_reply(cert) | |<---------------------+ | 227 | | | |<----------------+ | | | 228 | | RA(key) | | | | | | 229 | |<----------+ | | | | | 230 | | CPS(key) | | | | | | 231 | +---------->| | | | | | 232 | | CPA(cert) | | | | | | 233 | |<----------+ | | | | | 234 | | | | | | | | 235 | | | | | | | | 236 | | | | | | | | 237 | | | | | | | | 238 +--+ +- -+ +--+ +--+ 240 Figure 2 242 The Delegating Server acts as a Registration Authority between the 243 Requesting Router (RR) and the Certification Authority (CA). It 244 receives the RR public key and identity ID, thru DHCP flows, then 245 builds a certificate request that it sends to the CA. 247 The certificate request is built with the syntax specified in [8], 248 Section 5. The subject is filled with the DUID of the RR. The 249 publicKey is the one provided by the Requesting Router in the DHCP 250 request. It is under the responsability of the DS (or other devices 251 leveraged by the DHCP deployment for this purpose) to verify the RR 252 identity, so no Proof Of Possession is provided by the DS in the 253 certificate request. 255 5. Identity Association for Prefix Delegation 257 In the context of DHCP facilitated certificate distribution, the 258 requesting router and the delegating server use the Identity 259 Association for Prefix Delegation (IA_PD) described in RFC3633 to 260 identify, group and manage the delegated prefixes. The IA_PD option 261 code is 25, the IAID is 4 octets and the T1, T2 timers are used to 262 manage the communication between the requesting router and the 263 delegating server as described in section 9 of RFC3633. Operational 264 status information is exchanged via Status Code options. 266 The certificate is related to a delegated prefix or to all delegated 267 prefixes. The new option called "Certificate Option" (CO) is defined 268 for the IA_PD to enable the requesting router and the delegating 269 server to identify and manage the certificates corresponding to 270 delegated prefixes. 272 The option can appear multiple times in the DHCP messages. It must 273 provide the resources to indicate what type of assistance is needed 274 or can be provided in the process of acquiring a certificate. In 275 certain circumstances a full certificate is requested from the DHCP 276 server while in other a pointer (IP address of FQDN) to the 277 certificate server is sufficient. 279 The process of facilitating the acquisition of a certificate requires 280 the CO option to carry various information types between the DHCP 281 client and the DHCP server. The option can be used to inform the 282 client or the server of a preferred Trust Anchor for the certificate 283 chain. It can be used by the client to provide its public key to the 284 DHCP server which in turn uses it to obtain the certificate. The 285 server uses the option to deliver a certificate to the client or to 286 provide a pointer (IP address or FQDN) to a Certificate server. 288 Note: In the case where the DHCP server provides a certificate to the 289 client, one certificate can be built for each prefix under the IA_PD 290 or a single certificate can be built for all prefixes under the 291 IA_PD. 293 The format of the CO option is shown in Figure 2. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | OPTION-CO | option-length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |C|C|P|P| | 301 +-+-+-+-+ + 302 . Option CO data . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 2 308 OPTION_CO: Certificate option 310 CO option-length: Length of the CO-option 312 C Flag: Two bits field indicating the capabilities requested 313 or offered. The C flag values are: 314 00 - Any capability 315 01 - Pointer to Certificate Server 316 10 - Certificate 317 11 - Both pointer and certificate 319 P Flag: Two bits field indicating the type of data present in 320 the CO option payload. The P flag values are: 321 00 - Certificate chain trust anchor 322 01 - Public key 323 10 - Pointer to certificate server 324 11 - Certificate 326 Option data: The CO option can contain various types of data as 327 indicated through the P flag: Public Key, Certificate 328 pointer, certificate chain trust anchor. 330 The usage of the CO option is described in Section 7. 332 6. Mode of Operation Overview 334 The mode of operation described in Sections 11, 12 and 13 of RFC3633 335 remain unchanged in the context of certificate management. 336 Additional information however will be exchanged between the 337 requesting router and the delegating server to indicate interest in a 338 certificate, to advertise the ability to facilitate the acquisition 339 of a certificate and to exchange certificate related information. 341 Sections 11, 12 and 13 of RFC3633 should be read in conjunction with 342 the subsequent sections of this document for a complete understanding 343 of DHCP's mode of operation in the context of managing certificates. 345 7. Delegating Server Solicitation 347 In the process of discovering a prefix delegating router, the 348 requesting router can choose to indicate interest in a server with 349 the capability to facilitate the acquisition of a certificate and it 350 can select a server based on its level of support for managing 351 certificates. 353 7.1. Requesting Router Behavior 355 The requesting router creates and transmits a Solicit message with a 356 IA_PD option as described in section 11.1 of RFC3633. To indicate 357 interest in certificate related information, the requesting router 358 includes a CO-option which can contain the following information: 359 o It sets the C flag bits to indicate the level of assistance it 360 wants: any, pointer, certificate or both pointer and certificate 361 o In the payload it can include the certificate chain trust anchor 362 of interest in which case the P flag bits are set to 00. 363 Otherwise the payload is set to all zeros 365 The requesting router processes any received Advertise messages as 366 described in Section 11.1 of RFC3633. The requesting router selects 367 an advertising server based on the level of service offered for 368 certificate management and the provisioning requirements of the 369 requesting router. Since the delegating server is required to 370 advertise its full capabilities related to certificate management, 371 the requesting router must select a server which will be able to 372 provide the information requested through the follow up Request 373 message described in Section 8.1. 375 Should a requesting router receive no Advertisements from servers 376 with the certificate management capabilities needed, the requesting 377 router SHOULD default to the lowest level of support which might be 378 simple prefix delegation with no certificate management assistance. 379 In this situation, the requesting router will rely on other 380 mechanisms to acquire its certificates should they be needed. 382 7.2. Delegating Server Behavior 384 In response to a Solicit message containing an IA_PD option, the 385 delegating server MUST include in its Advertise message described in 386 section 11.2 of RFC3633 the CO-option to indicate its capabilities of 387 supporting the certificate management process for the prefixes it 388 delegates. 390 The certificate management services offered by the delegating server 391 can be advertised for each certificate chain trust anchor for which 392 the server can facilitate the process of acquiring a certificate. 393 One CO option will be included for each certificate trust anchor with 394 the following settings: 395 o The C flag bits are set to indicate servers capabilities for a 396 given certificate trust anchor: any, pointer, certificate or both 397 pointer and certificate 398 o P flag is set to 00 and the payload contains the identifier for 399 the certificate chain trust anchor 401 8. Requesting Router Initiated Prefix and Certificate Delegation 403 A requesting router uses the same messages described in Section 12 of 404 RFC3633 to populate the IA_PD with prefixes. Additionally, it can 405 acquire a certificate for the delegated prefixes or a locator for a 406 certificate authority which it can later contact via other mechanisms 407 to acquire a certificate. 409 This section addresses environments similar to the one described in 410 Figure 1 where the DHCP-PD requesting router requires a certificate 411 for the delegated prefix. The requesting router selected from 412 received advertisements a delegating server which has the desired 413 capabilities to support certificate management. 415 8.1. Requesting Router Behavior 417 To acquire the certificates, the requesting router uses the private 418 key of a pair of RSA keys it previously generated independently of 419 the provisioning mechanism described in this document. After 420 identifying a delegating server which has the capability to assist 421 with the process of acquiring a certificate for the delegated 422 prefixes and possibly a trust anchor of interest, the requesting 423 router creates and transmits a Request message as described in 424 section 11.2 of RFC3633. The message is sent to the selected 425 delegating sever and it contains one or more CO-options formatted in 426 accordance with the capabilities of the selected server. 428 If assistance can be provided in relation to multiple trust anchors, 429 the Request indicates, with the help of a CO option, which is the 430 trust anchor of interest. This CO option proceeds subsequent CO 431 options that might carry additional, certificate related information 432 as described in the following two cases. 434 The server can provide a pointer to a certificate authority for a 435 given trust anchor: 436 o The C flag is set to 01 (pointer) 437 o The P flag can be set to 00 (certificate trust anchor) and the 438 payload contains the ID of the trust anchor of interest. If the 439 trust anchor is not important, the payload field can be set to all 440 zeros. 442 The server can provide a complete certificate for a given trust 443 anchor: 444 First CO option 445 * The C flag is set to 10 (certificate) 446 * The P field is set to 00 (certificate trust anchor) and the 447 payload contains the ID of the trust anchor of interest. 448 Second CO option 449 * The C flag is set to 10 450 * The P field is set to 01 (public key) and the payload contains 451 the public key of the requesting router 452 If the trust anchor is not important, then only the second CO option 453 if included in the Request message. 455 As described in section 12.1 of RFC3633, the requesting router might 456 need verification of the information bound to the IA_PD. The 457 requesting router includes the IA_PD options in the Renew and Rebind 458 messages where, along with the prefix information, it MUST include 459 certificate related information according to the capabilities of the 460 delegating server and optionally the trust anchor of interest. 462 In the Renew/Rebind messages, the CO option has the following 463 settings: 464 o The C flag is set to indicates the level of certificate assistance 465 support needed 466 o The P flag is set to 00 with the payload including the trust 467 anchor of interest or the payload set to all zeros should the 468 trust anchor not be relevant. 470 Upon the receipt of a valid Reply message for each IA_PD, a reply 471 that can include either a pointer or a certificate, the requesting 472 router will manage the delegated prefix as described in section 12.1. 473 If a full certificate is provided, the requesting router will store 474 it and use it in accordance with the recommendations of RFC3971 or 475 any other related processes. If the delegating server provided only 476 the pointer to the certificate authority, the requesting router will 477 use an alternative mechanism to request a certificate. 479 Note that it is assumed that the requesting router does not require a 480 certificate to authenticate the recommended certificate authority or 481 the certificate authority which provided the certificate. It is 482 assumed that the requesting router trusts the DHCP delegating server 483 the same way it trusts the server in providing the delegated prefix. 485 8.2. Delegating Server Behavior 487 In response to a Request message containing an IA_PD option with CO 488 options, the delegating server MUST include in its Reply, along with 489 the information described in section 12.2 of RFC3633, the CO-option 490 containing the relevant information according to its advertised 491 capabilities. 493 The server can provide a pointer to a certificate server or a 494 complete certificate for a given trust anchor: 495 First CO option 496 * The C flag is set to the service being offered: 01 (pointer) or 497 10 (certificate) 498 * The P field is set to 00 (certificate trust anchor) and the 499 payload contains the ID of the trust anchor of interest. 500 Second CO option 501 * The C flag is set to the service being offered: 01 (pointer) or 502 10 (certificate) 503 * The P field is set to 10 (pointer) or 11 (certificate) 504 depending on the service offered 505 If the trust anchor is not important, then only the second CO option 506 is included in the Request message. 508 If the delegating server can provide a complete certificate, upon the 509 receipt of the Request with the public key of the requesting router, 510 the delegating server contacts a pre-provisioned certificate 511 authority (which can provide certificates chained to a trust anchor 512 of interest) through a mechanism outside the scope of this document. 513 The server submits to the CA the certificate request tuple (ID, 514 public key, delegated prefix) along with the relevant state 515 maintenance timers for the delegated prefix. The CA generates a 516 certificate and sends it back to the delegating server. 518 Handling of Renew and Rebind messages is dictated by the procedures 519 defined in section 12.2 of RFC3633. From the certificate maintenance 520 perspective, if the delegating server identifies an active IA_PD 521 binding, it will resubmit in response the location of the certificate 522 authority (stateless information) or would acquire a new certificate 523 and send it in response. 525 9. Delegating Server Triggered Reconfiguration 527 The CO option can be included in a Reconfigure message as described 528 in RFC3315. This enables the server to request a client to renew its 529 certificates for an IA_PD for which it has an active biniding. The 530 triggered reconfiguration can be in relation to a given trust anchor. 532 The Co option in the Reconfigure message can have the following 533 format: 534 First CO option 535 * The C flag is set to the service being offered: 01 (pointer) or 536 10 (certificate) 537 * The P field is set to 00 (certificate trust anchor) and the 538 payload contains the ID of the trust anchor of interest. 539 Second CO option 540 * The C flag is set to the service being offered: 01 (pointer) or 541 10 (certificate) 542 * The P field is set to 11 (certificate) and the payload set to 543 all zeros 544 If the trust anchor is not important, then only the second CO option 545 is included in the Reconfigure message. 547 10. Security Considerations 549 The mechanism described in this document is subject to the same 550 security considerations as the ones described in section 15 of 551 RFC3633. No additional security considerations are necessary. 553 Note: Through its binding to the IA_PD, the certificate acquisition 554 process described adopts the trust model of the DHCP-PD process. If 555 the information used to build an IA_PD binding is sufficient for the 556 server to delegate a prefix to a CPE, it is considered sufficient to 557 have the server facilitate the process of acquiring a certificate. 558 When the server provides a certificate to the client, it acts similar 559 to a Registration Authority [8] and contacts the certificate 560 authority for the certificate. In that process, the server might 561 need to provide, along with the other relevant information (ID, 562 public key, prefix) a client's proof-of-possession. This scenario is 563 not addressed in this document. 565 11. IANA Considerations 567 This document does not define any new namespaces or other constants 568 for which IANA must maintain a registry.. 570 12. References 571 12.1. Normative References 573 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 574 Levels", BCP 14, RFC 2119, March 1997. 576 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 577 Specification", RFC 2460, December 1998. 579 [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 580 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 581 RFC 3315, July 2003. 583 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 584 Configuration Protocol (DHCP) version 6", RFC 3633, 585 December 2003. 587 [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 588 Addresses and AS Identifiers", RFC 3779, June 2004. 590 [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 591 Neighbor Discovery (SEND)", RFC 3971, March 2005. 593 [7] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet 594 X.509 Public Key Infrastructure Certificate Management Protocol 595 (CMP)", RFC 4210, September 2005. 597 [8] Schaad, J., "Internet X.509 Public Key Infrastructure 598 Certificate Request Message Format (CRMF)", RFC 4211, 599 September 2005. 601 12.2. Informative References 603 Authors' Addresses 605 Ciprian Popoviciu 606 Cisco Systems 607 Kit Creek Road 608 RTP, North Carolina 27709 609 USA 611 Phone: 919 787 8162 612 Email: cpopovic@cisco.com 613 Ralph Droms 614 Cisco Systems 615 1414 Massachusetts Avenue 616 Boxborough MA 01719 617 USA 619 Phone: +1 978.936.1674 620 Email: rdroms@cisco.com 622 Eric Levy-Abegnoli 623 Cisco Systems 624 Village d'Entreprises Green Side - 400, Avenue Roumanille Batiment T 3 625 Biot - Sophia Antipolis PROVENCE-ALPES-COTE D'AZUR 06410 626 France 628 Phone: +33 49 723 2620 629 Email: elevyabe@cisco.com 631 Full Copyright Statement 633 Copyright (C) The IETF Trust (2008). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 643 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at 669 ietf-ipr@ietf.org. 671 Acknowledgment 673 Funding for the RFC Editor function is provided by the IETF 674 Administrative Support Activity (IASA).