| < draft-ietf-sidr-arch-12.txt | draft-ietf-sidr-arch-13.txt > | |||
|---|---|---|---|---|
| Secure Inter-Domain Routing M. Lepinski | Secure Inter-Domain Routing M. Lepinski | |||
| Working Group S. Kent | Working Group S. Kent | |||
| Internet Draft BBN Technologies | Internet Draft BBN Technologies | |||
| Intended status: Informational February 16, 2011 | Intended status: Informational May 23, 2011 | |||
| Expires: August 16, 2011 | Expires: November 23, 2011 | |||
| An Infrastructure to Support Secure Internet Routing | An Infrastructure to Support Secure Internet Routing | |||
| draft-ietf-sidr-arch-12.txt | draft-ietf-sidr-arch-13.txt | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 32 ¶ | skipping to change at page 1, line 32 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on August 16, 2011. | This Internet-Draft will expire on November 23, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Abstract | Abstract | |||
| This document describes an architecture for an infrastructure to | This document describes an architecture for an infrastructure to | |||
| support improved security of Internet routing. The foundation of this | support improved security of Internet routing. The foundation of this | |||
| architecture is a public key infrastructure (PKI) that represents the | architecture is a resource public key infrastructure (RPKI) that | |||
| allocation hierarchy of IP address space and Autonomous System (AS) | represents the allocation hierarchy of IP address space and | |||
| Numbers; and a distributed repository system for storing and | Autonomous System (AS) Numbers; and a distributed repository system | |||
| disseminating the data objects that comprise the PKI, as well as | for storing and disseminating the data objects that comprise the | |||
| other signed objects necessary for improved routing security. As an | RPKI, as well as other signed objects necessary for improved routing | |||
| initial application of this architecture, the document describes how | security. As an initial application of this architecture, the | |||
| a legitimate holder of IP address space can explicitly and verifiably | document describes how a legitimate holder of IP address space can | |||
| authorize one or more ASes to originate routes to that address space. | explicitly and verifiably authorize one or more ASes to originate | |||
| Such verifiable authorizations could be used, for example, to more | routes to that address space. Such verifiable authorizations could be | |||
| securely construct BGP route filters. | used, for example, to more securely construct BGP route filters. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction ............................................. 3 | 1. Introduction...................................................3 | |||
| 1.1. Terminology ......................................... 4 | 1.1. Terminology...............................................4 | |||
| 2. PKI for Internet Number Resources ........................ 5 | 2. PKI for Internet Number Resources..............................5 | |||
| 2.1. Role in the overall architecture .................... 5 | 2.1. Role in the overall architecture..........................5 | |||
| 2.2. CA Certificates ..................................... 6 | 2.2. CA Certificates...........................................6 | |||
| 2.3. End-Entity (EE) Certificates ........................ 7 | 2.3. End-Entity (EE) Certificates..............................7 | |||
| 2.4. Trust Anchors ....................................... 8 | 2.4. Trust Anchors.............................................8 | |||
| 3. Route Origination Authorizations ......................... 9 | 3. Route Origination Authorizations...............................9 | |||
| 3.1. Role in the overall architecture .................... 9 | 3.1. Role in the overall architecture..........................9 | |||
| 3.2. Syntax and semantics ................................ 10 | 3.2. Syntax and semantics.....................................10 | |||
| 4. Repositories ............................................. 11 | 4. Repositories..................................................11 | |||
| 4.1. Role in the overall architecture .................... 12 | 4.1. Role in the overall architecture.........................12 | |||
| 4.2. Contents and structure .............................. 12 | 4.2. Contents and structure...................................12 | |||
| 4.3. Access protocols .................................... 14 | 4.3. Access protocols.........................................14 | |||
| 4.4. Access control ...................................... 15 | 4.4. Access control...........................................15 | |||
| 5. Manifests ................................................ 15 | 5. Manifests.....................................................15 | |||
| 5.1. Syntax and semantics ................................ 15 | 5.1. Syntax and semantics.....................................16 | |||
| 6. Local Cache Maintenance .................................. 16 | 6. Local Cache Maintenance.......................................16 | |||
| 7. Common Operations ........................................ 17 | 7. Common Operations.............................................17 | |||
| 7.1. Certificate issuance ................................ 17 | 7.1. Certificate issuance.....................................17 | |||
| 7.2. CA Key Rollover ..................................... 18 | 7.2. CA Key Rollover..........................................18 | |||
| 7.3. ROA management ...................................... 19 | 7.3. ROA management...........................................19 | |||
| 7.3.1. Single-homed subscribers ....................... 20 | 7.3.1. Single-homed subscribers............................20 | |||
| 7.3.2. Multi-homed subscribers ........................ 20 | 7.3.2. Multi-homed subscribers.............................20 | |||
| 7.3.3. Provider-Independent Address Space ............. 21 | 7.3.3. Provider-Independent Address Space..................21 | |||
| 8. Security Considerations .................................. 21 | 8. Security Considerations.......................................21 | |||
| 9. IANA Considerations ...................................... 21 | 9. IANA Considerations...........................................22 | |||
| 10. Acknowledgments ......................................... 22 | 10. Acknowledgments..............................................22 | |||
| 11. References .............................................. 23 | 11. References...................................................23 | |||
| 11.1. Normative References ............................... 23 | 11.1. Normative References....................................23 | |||
| 11.2. Informative References ............................ 23 | 11.2. Informative References..................................24 | |||
| Authors' Addresses ......................................... 24 | Authors' Addresses...............................................24 | |||
| 1. Introduction | 1. Introduction | |||
| This document describes an architecture for an infrastructure to | This document describes an architecture for an infrastructure to | |||
| support improved security for BGP routing [RFC 4271] for the | support improved security for BGP routing [RFC 4271] for the | |||
| Internet. The architecture encompasses three principle elements: | Internet. The architecture encompasses three principle elements: | |||
| . a public key infrastructure (PKI) | . a resource public key infrastructure (RPKI) | |||
| . digitally-signed routing objects to support routing security | . digitally-signed routing objects to support routing security | |||
| . a distributed repository system to hold the PKI objects and the | . a distributed repository system to hold the PKI objects and the | |||
| signed routing objects | signed routing objects | |||
| The architecture described by this document enables an entity to | The architecture described by this document enables an entity to | |||
| verifiably assert that it is the legitimate holder of a set of IP | verifiably assert that it is the legitimate holder of a set of IP | |||
| addresses or a set of Autonomous System (AS) numbers. As an initial | addresses or a set of Autonomous System (AS) numbers. As an initial | |||
| application of this architecture, the document describes how a | application of this architecture, the document describes how a | |||
| skipping to change at page 4, line 16 ¶ | skipping to change at page 4, line 16 ¶ | |||
| possible; for example, extensive use is made of the X.509 certificate | possible; for example, extensive use is made of the X.509 certificate | |||
| profile defined by the Public Key Infrastructure using X.509 (PKIX) | profile defined by the Public Key Infrastructure using X.509 (PKIX) | |||
| working group [RFC 5280] and the extensions for IP Addresses and AS | working group [RFC 5280] and the extensions for IP Addresses and AS | |||
| numbers representation defined in RFC 3779 [RFC 3779]. Also | numbers representation defined in RFC 3779 [RFC 3779]. Also | |||
| Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax | Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax | |||
| for the newly-defined signed objects [SIGN-OBJ] required by this | for the newly-defined signed objects [SIGN-OBJ] required by this | |||
| infrastructure. | infrastructure. | |||
| As noted above, the architecture is comprised of three main | As noted above, the architecture is comprised of three main | |||
| components: an X.509 PKI in which certificates attest to holdings of | components: an X.509 PKI in which certificates attest to holdings of | |||
| IP address space and AS numbers; non-certificate/CRL signed objects | IP address space and AS numbers; non-certificate signed objects | |||
| (including route origination authorizations and manifests) used by | (including route origination authorizations and manifests) used by | |||
| the infrastructure; and a distributed repository system that makes | the infrastructure; and a distributed repository system that makes | |||
| all of these signed objects available for use by ISPs in making | all of these signed objects available for use by ISPs in making | |||
| routing decisions. These three basic components enable several | routing decisions. These three basic components enable several | |||
| security functions; this document describes how they can be used to | security functions; most notably the cryptographic validation that an | |||
| improve route filter generation, and to perform several other common | autonomous system is authorized to originate routes to a given prefix | |||
| operations in such a way as to make them cryptographically | [ROA-VALID]. | |||
| verifiable. | ||||
| 1.1. Terminology | 1.1. Terminology | |||
| It is assumed that the reader is familiar with the terms and concepts | It is assumed that the reader is familiar with the terms and concepts | |||
| described in "Internet X.509 Public Key Infrastructure Certificate | described in "Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509 | and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509 | |||
| Extensions for IP Addresses and AS Identifiers" [RFC 3779]. | Extensions for IP Addresses and AS Identifiers" [RFC 3779]. | |||
| Throughout this document we use the terms "address space holder" or | Throughout this document we use the terms "address space holder" or | |||
| "holder of IP address space" interchangeably to refer to a legitimate | "holder of IP address space" interchangeably to refer to a legitimate | |||
| skipping to change at page 5, line 5 ¶ | skipping to change at page 5, line 5 ¶ | |||
| Throughout this document we use the terms "registry" and ISP to refer | Throughout this document we use the terms "registry" and ISP to refer | |||
| to an entity that has an IP address space and/or AS number allocation | to an entity that has an IP address space and/or AS number allocation | |||
| that it is permitted to sub-allocate. | that it is permitted to sub-allocate. | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in RFC | "OPTIONAL" in this document are to be interpreted as described in RFC | |||
| 2119 [RFC 2119]. | 2119 [RFC 2119]. | |||
| 2. PKI for Internet Number Resources | 2. Public Key Infrastructure for Internet Number Resources | |||
| Because the holder of a block of IP address space is entitled to | Because the holder of a block of IP address space is entitled to | |||
| define the topological destination of IP datagrams whose destinations | define the topological destination of IP datagrams whose destinations | |||
| fall within that block, decisions about inter-domain routing are | fall within that block, decisions about inter-domain routing are | |||
| inherently based on knowledge of the allocation of the IP address | inherently based on knowledge of the allocation of the IP address | |||
| space. Thus, a basic function of this architecture is to provide | space. Thus, a basic function of this architecture is to provide | |||
| cryptographically verifiable attestations as to these allocations. In | cryptographically verifiable attestations as to these allocations. In | |||
| current practice, the allocation of IP addresses is hierarchical. The | current practice, the allocation of IP addresses is hierarchical. The | |||
| root of the hierarchy is IANA. Below IANA are five Regional Internet | root of the hierarchy is IANA. Below IANA are five Regional Internet | |||
| Registries (RIRs), each of which manages address and AS number | Registries (RIRs), each of which manages address and AS number | |||
| skipping to change at page 5, line 38 ¶ | skipping to change at page 5, line 38 ¶ | |||
| particular unit of the same organization), or to another | particular unit of the same organization), or to another | |||
| organization, subject to contractual constraints established by the | organization, subject to contractual constraints established by the | |||
| registries. Because of this structure, IP address allocations can be | registries. Because of this structure, IP address allocations can be | |||
| described naturally by a hierarchic public-key infrastructure, in | described naturally by a hierarchic public-key infrastructure, in | |||
| which each certificate attests to an allocation of IP addresses, and | which each certificate attests to an allocation of IP addresses, and | |||
| issuance of subordinate certificates corresponds to sub-allocation of | issuance of subordinate certificates corresponds to sub-allocation of | |||
| IP addresses. The above reasoning holds true for AS number resources | IP addresses. The above reasoning holds true for AS number resources | |||
| as well, with the difference that, by convention, AS numbers may not | as well, with the difference that, by convention, AS numbers may not | |||
| be sub-allocated except by RIRs or NIRs. Thus allocations of both IP | be sub-allocated except by RIRs or NIRs. Thus allocations of both IP | |||
| addresses and AS numbers can be expressed by the same PKI. Such a | addresses and AS numbers can be expressed by the same PKI. Such a | |||
| PKI is a central component of this architecture. | PKI, which is henceforth referred to as the Resource Public Key | |||
| Infrastructure (RPKI), is a central component of this architecture. | ||||
| 2.1. Role in the overall architecture | 2.1. Role in the overall architecture | |||
| Certificates in this PKI are called Resource Certificates, and | Certificates in this PKI are called Resource Certificates, and | |||
| conform to the certificate profile for such certificates [RES-CERT]. | conform to the certificate profile for such certificates [RES-CERT]. | |||
| Resource certificates attest to the allocation by the (certificate) | Resource certificates attest to the allocation by the (certificate) | |||
| issuer of IP addresses or AS numbers to the subject. They do this by | issuer of IP addresses or AS numbers to the subject. They do this by | |||
| binding the public key contained in the Resource Certificate to the | binding the public key contained in the Resource Certificate to the | |||
| IP addresses or AS numbers included in the certificate's IP Address | IP addresses or AS numbers included in the certificate's IP Address | |||
| Delegation or AS Identifier Delegation Extensions, respectively, as | Delegation or AS Identifier Delegation Extensions, respectively, as | |||
| skipping to change at page 11, line 30 ¶ | skipping to change at page 11, line 30 ¶ | |||
| | ISP | | ISP | | ISP | | | ISP | | ISP | | ISP | | |||
| | EE 1a | | EE 1b | | EE 2 | | | EE 1a | | EE 1b | | EE 2 | | |||
| ---------- ---------- ---------- | ---------- ---------- ---------- | |||
| | | | | | | | | |||
| | | | | | | | | |||
| | | | | | | | | |||
| ---------- ---------- ---------- | ---------- ---------- ---------- | |||
| | ROA 1a | | ROA 1b | | ROA 2 | | | ROA 1a | | ROA 1b | | ROA 2 | | |||
| ---------- ---------- ---------- | ---------- ---------- ---------- | |||
| FIGURE 2: This figure illustrates an ISP with allocations from two | FIGURE 1: This figure illustrates an ISP with allocations from two | |||
| sources (an RIR and an NIR). It needs two CA certificates due to RFC | sources (an RIR and an NIR). It needs two CA certificates due to RFC | |||
| 3779 rules. | 3779 rules. | |||
| Because each ROA is associated with a single end-entity certificate, | Because each ROA is associated with a single end-entity certificate, | |||
| the set of IP prefixes contained in a ROA must be drawn from an | the set of IP prefixes contained in a ROA must be drawn from an | |||
| allocation by a single source, i.e., a ROA cannot combine allocations | allocation by a single source, i.e., a ROA cannot combine allocations | |||
| from multiple sources. Address space holders who have allocations | from multiple sources. Address space holders who have allocations | |||
| from multiple sources, and who wish to authorize an AS to originate | from multiple sources, and who wish to authorize an AS to originate | |||
| routes for these allocations, must issue multiple ROAs to the AS. | routes for these allocations, must issue multiple ROAs to the AS. | |||
| skipping to change at page 12, line 26 ¶ | skipping to change at page 12, line 26 ¶ | |||
| records related to an allocation of resources can be manipulated only | records related to an allocation of resources can be manipulated only | |||
| by authorized parties. The use of access controls prevents denial of | by authorized parties. The use of access controls prevents denial of | |||
| service attacks based on deletion of or tampering to repository | service attacks based on deletion of or tampering to repository | |||
| objects. Indeed, although relying parties can detect tampering with | objects. Indeed, although relying parties can detect tampering with | |||
| objects in the repository, it is preferable that the repository | objects in the repository, it is preferable that the repository | |||
| system prevent such unauthorized modifications to the greatest extent | system prevent such unauthorized modifications to the greatest extent | |||
| possible. | possible. | |||
| 4.1. Role in the overall architecture | 4.1. Role in the overall architecture | |||
| The repository system is the central clearing-house for all signed | The repository system is the untrusted clearing-house for all signed | |||
| objects that must be globally accessible to relying parties. When | objects that must be globally accessible to relying parties. When | |||
| certificates and CRLs are created, they are uploaded to this | certificates and CRLs are created, they are uploaded to this | |||
| repository, and then downloaded for use by relying parties (primarily | repository, and then downloaded for use by relying parties (primarily | |||
| LIRs/ISPs). ROAs and manifests are additional examples of such | LIRs/ISPs). ROAs and manifests are additional examples of such | |||
| objects, but other types of signed objects may be added to this | objects, but other types of signed objects may be added to this | |||
| architecture in the future. This document briefly describes the way | architecture in the future. This document briefly describes the way | |||
| signed objects (certificates, CRLs, ROAs and manifests) are managed | signed objects (certificates, CRLs, ROAs and manifests) are managed | |||
| in the repository system. As other types of signed objects are added | in the repository system. As other types of signed objects are added | |||
| to the repository system it will be necessary to modify the | to the repository system it will be necessary to modify the | |||
| description, but it is anticipated that most of the design principles | description, but it is anticipated that most of the design principles | |||
| skipping to change at page 13, line 11 ¶ | skipping to change at page 13, line 11 ¶ | |||
| LIRs/ISPs also will contain ROAs. Registries are encouraged to | LIRs/ISPs also will contain ROAs. Registries are encouraged to | |||
| maintain copies of repository data from their customers, and their | maintain copies of repository data from their customers, and their | |||
| customer's customers (etc.), to facilitate retrieval of the whole | customer's customers (etc.), to facilitate retrieval of the whole | |||
| repository contents by relying parties. Ideally, each RIR will hold | repository contents by relying parties. Ideally, each RIR will hold | |||
| PKI data from all entities within its geopolitical scope. | PKI data from all entities within its geopolitical scope. | |||
| For every certificate in the PKI, there will be a corresponding file | For every certificate in the PKI, there will be a corresponding file | |||
| system directory in the repository that is the authoritative | system directory in the repository that is the authoritative | |||
| publication point for all objects (certificates, CRLs, ROAs and | publication point for all objects (certificates, CRLs, ROAs and | |||
| manifests) verifiable via this certificate. A certificate's Subject | manifests) verifiable via this certificate. A certificate's Subject | |||
| Information Authority (SIA) extension provides a URI that references | Information Authority (SIA) extension [RFC 5280] contains a URI that | |||
| this directory. Additionally, a certificate's Authority Information | references this directory. Additionally, a certificate's Authority | |||
| Authority (AIA) extension contains a URI that references the | Information Authority (AIA) extension [RFC 5280] contains a URI that | |||
| authoritative location for the CA certificate under which the given | references the authoritative location for the CA certificate under | |||
| certificate was issued. That is, if certificate A is used to verify | which the given certificate was issued. That is, if certificate A is | |||
| certificate B, then the AIA extension of certificate B points to | used to verify certificate B, then the AIA extension of certificate B | |||
| certificate A, and the SIA extension of certificate A points to a | points to certificate A, and the SIA extension of certificate A | |||
| directory containing certificate B (see Figure 2). | points to a directory containing certificate B (see Figure 2). | |||
| +--------+ | +--------+ | |||
| +--------->| Cert A |<----+ | +--------->| Cert A |<----+ | |||
| | | CRLDP | | | | | CRLDP | | | |||
| | | AIA | | | | | AIA | | | |||
| | +--------- SIA | | | | +--------- SIA | | | |||
| | | +--------+ | | | | +--------+ | | |||
| | | | | | | | | |||
| | | | | | | | | |||
| | | | | | | | | |||
| skipping to change at page 13, line 44 ¶ | skipping to change at page 13, line 44 ¶ | |||
| +----------- AIA | | +----- AIA | | | | +----------- AIA | | +----- AIA | | | | |||
| | | SIA | | | SIA | | | | | | SIA | | | SIA | | | | |||
| | +--------+ | +--------+ | | | | +--------+ | +--------+ | | | |||
| | V | | | | V | | | |||
| | +---------+ | | | | +---------+ | | | |||
| | | A's CRL |<-----------+ | | | | A's CRL |<-----------+ | | |||
| | +---------+ | | | +---------+ | | |||
| | A's Repository Publication Directory | | | A's Repository Publication Directory | | |||
| +--------------------------------------+ | +--------------------------------------+ | |||
| FIGURE 3: In this example, certificates B and C are issued by | FIGURE 2: Use of SIA and AIA extensions in the RPKI | |||
| certification authority A. Therefore, the AIA extensions of | ||||
| certificates B and C point to the publication point where Certificate | In Figure 2, certificates B and C are issued by (CA) A. Therefore, | |||
| A is published, and the SIA extension of certificate A points to the | the AIA extensions of certificates B and C point to (certificate) A, | |||
| repository publication point where the objects issued under authority | and the SIA extension of certificate A points to the repository | |||
| A, including certificates B and C and A's CRL, are published. | publication point of CA A's subordinate products, which includes | |||
| certificates B and C, as well as the CRL issued by A. The CRL | ||||
| Distribution Points (CRLDP) extension in certificates B and C both | ||||
| point to the Certificate Revocation List (CRL) issued by A. | ||||
| If a CA certificate is reissued with the same public key, it should | If a CA certificate is reissued with the same public key, it should | |||
| not be necessary to reissue (with an updated AIA URI) all | not be necessary to reissue (with an updated AIA URI) all | |||
| certificates signed by the certificate being reissued. Therefore, a | certificates signed by the certificate being reissued. Therefore, a | |||
| certification authority SHOULD use a persistent URI naming scheme for | certification authority SHOULD use a persistent URI naming scheme for | |||
| issued certificates. That is, reissued certificates should use the | issued certificates. That is, reissued certificates should use the | |||
| same publication point as previously issued certificates having the | same publication point as previously issued certificates having the | |||
| same subject and public key, and should overwrite such certificates. | same subject and public key, and should overwrite such certificates. | |||
| 4.3. Access protocols | 4.3. Access protocols | |||
| Repository operators will choose one or more access protocols that | Repository operators will choose one or more access protocols that | |||
| relying parties can use to access the repository system. These | relying parties can use to access the repository system. These | |||
| protocols will be used by numerous participants in the infrastructure | protocols will be used by numerous participants in the infrastructure | |||
| (e.g., all registries, ISPs, and multi-homed subscribers) to maintain | (e.g., all registries, ISPs, and multi-homed subscribers) to maintain | |||
| their respective portions of it. In order to support these | their respective portions of it. In order to support these | |||
| activities, certain basic functionality is required of the suite of | activities, certain basic functionality is required of the suite of | |||
| access protocols, as described below. No single access protocol need | access protocols, as described below. No single access protocol need | |||
| implement all of these functions (although this may be the case), but | implement all of these functions (although this may be the case), but | |||
| each function must be implemented by at least one access protocol. | each function MUST be implemented by at least one access protocol | |||
| deployed by a repository operator. | ||||
| Download: Access protocols MUST support the bulk download of | Download: Access protocols must support the bulk download of | |||
| repository contents and subsequent download of changes to the | repository contents and subsequent download of changes to the | |||
| downloaded contents, since this will be the most common way in which | downloaded contents, since this will be the most common way in which | |||
| relying parties interact with the repository system. Other types of | relying parties interact with the repository system. Other types of | |||
| download interactions (e.g., download of a single object) MAY also be | download interactions (e.g., download of a single object) may also be | |||
| supported. | supported. | |||
| Upload/change/delete: Access protocols MUST also support mechanisms | Upload/change/delete: Access protocols must also support mechanisms | |||
| for the issuers of certificates, CRLs, and other signed objects to | for the issuers of certificates, CRLs, and other signed objects to | |||
| add them to the repository, and to remove them. Mechanisms for | add them to the repository, and to remove them. Mechanisms for | |||
| modifying objects in the repository MAY also be provided. All access | modifying objects in the repository may also be provided. All access | |||
| protocols that allow modification to the repository (through | protocols that allow modification to the repository (through | |||
| addition, deletion, or modification of its contents) MUST support | addition, deletion, or modification of its contents) must support | |||
| verification of the authorization of the entity performing the | verification of the authorization of the entity performing the | |||
| modification, so that appropriate access controls can be applied (see | modification, so that appropriate access controls can be applied (see | |||
| Section 4.4). | Section 4.4). | |||
| To ensure all relying parties are able to acquire all RPKI signed | To ensure all relying parties are able to acquire all RPKI signed | |||
| objects, all publication points MUST be accessible via RSYNC (see | objects, all publication points MUST be accessible via RSYNC (see | |||
| [RFC 5781] and [RSYNC]), although other download protocols also be | [RFC 5781] and [RSYNC]), although other download protocols MAY also | |||
| supported. A repository publication point may provide | be supported. A repository publication point may provide | |||
| update/change/delete functionality via (set of) access protocols that | update/change/delete functionality via (set of) access protocols that | |||
| it desires, provided that the supported protocols are clearly | it desires, provided that the supported protocols are clearly | |||
| communicated to all certification authorities publishing data at a | communicated to all certification authorities publishing data at a | |||
| given publication point. | given publication point. | |||
| 4.4. Access control | 4.4. Access control | |||
| In order to maintain the integrity of information in the repository, | In order to maintain the integrity of information in the repository, | |||
| controls must be put in place to prevent addition, deletion, or | controls must be put in place to prevent addition, deletion, or | |||
| modification of objects in the repository by unauthorized parties. | modification of objects in the repository by unauthorized parties. | |||
| skipping to change at page 15, line 23 ¶ | skipping to change at page 15, line 26 ¶ | |||
| repository operators, it is RECOMMENDED that repositories allow only | repository operators, it is RECOMMENDED that repositories allow only | |||
| the issuers of signed objects to add, delete, or modify them. | the issuers of signed objects to add, delete, or modify them. | |||
| Alternatively, it may be advantageous in the future to define a | Alternatively, it may be advantageous in the future to define a | |||
| formal delegation mechanism to allow resource holders to authorize | formal delegation mechanism to allow resource holders to authorize | |||
| other parties to act on their behalf, as suggested in Section 2.3 | other parties to act on their behalf, as suggested in Section 2.3 | |||
| above. | above. | |||
| 5. Manifests | 5. Manifests | |||
| A manifest is a signed object listing of all of the signed objects | A manifest is a signed object listing of all of the signed objects | |||
| issued by an authority responsible for a publication in the | (except for the manifest itself) issued by an authority responsible | |||
| repository system. For each unexpired certificate, CRL, or ROA issued | for a publication in the repository system. For each unexpired | |||
| by the authority, the manifest contains both the name of the file | certificate, CRL, or ROA issued by the authority, the manifest | |||
| containing the object, and a hash of the file content. | contains both the name of the file containing the object, and a hash | |||
| of the file content. | ||||
| As with ROAs, a manifest is signed by a private key, for which the | As with ROAs, a manifest is signed by a private key, for which the | |||
| corresponding public key appears in an end-entity certificate. This | corresponding public key appears in an end-entity certificate. This | |||
| EE certificate, in turn, is signed by the CA in question. Since the | EE certificate, in turn, is signed by the CA in question. Since the | |||
| private key in an EE certificate is used to sign only a single | private key in an EE certificate is used to sign only a single | |||
| manifest, then the manifest can be revoked by revoking the EE | manifest, then the manifest can be revoked by revoking the EE | |||
| certificate. In such a case, to avoid needless CRL growth, the EE | certificate. In such a case, to avoid needless CRL growth, the EE | |||
| certificate used to validate a manifest SHOULD expire at the same | certificate used to validate a manifest SHOULD expire at the same | |||
| time that the manifest expires. | time that the manifest expires. | |||
| skipping to change at page 16, line 6 ¶ | skipping to change at page 16, line 15 ¶ | |||
| 5.1. Syntax and semantics | 5.1. Syntax and semantics | |||
| A manifest constitutes a list of (the hashes of) all the files in a | A manifest constitutes a list of (the hashes of) all the files in a | |||
| repository point at a particular point in time. A detailed | repository point at a particular point in time. A detailed | |||
| specification of the manifest's content is provided in [MANIFEST] | specification of the manifest's content is provided in [MANIFEST] | |||
| but, at a high level, a manifest consists of (1) a manifest number; | but, at a high level, a manifest consists of (1) a manifest number; | |||
| (2) the time the manifest was issued; (3) the time of the next | (2) the time the manifest was issued; (3) the time of the next | |||
| planned update; and (4) a list of filename and hash value pairs. | planned update; and (4) a list of filename and hash value pairs. | |||
| The manifest number is a sequence number that is incremented each | The manifest number is a sequence number that is incremented each | |||
| time a manifest is issued by the authority. An authority is required | time a manifest is issued by the authority. An authority is REQUIRED | |||
| to issue a new manifest any time it alters any of its items in the | to issue a new manifest any time it alters any of its items in the | |||
| repository, or when the specified time of the next update is reached. | repository, or when the specified time of the next update is reached. | |||
| A manifest is thus valid until the specified time of the next update | A manifest is thus valid until the specified time of the next update | |||
| or until a manifest is issued with a greater manifest number, | or until a manifest is issued with a greater manifest number, | |||
| whichever comes first. (Note that when an EE certificate is used to | whichever comes first. (Note that when an EE certificate is used to | |||
| sign only a single manifest, whenever the authority issues the new | sign only a single manifest, whenever the authority issues the new | |||
| manifest, the CA MUST also issue a new CRL which includes the EE | manifest, the CA MUST also issue a new CRL which includes the EE | |||
| certificate corresponding to the old manifest. The revoked EE | certificate corresponding to the old manifest. The revoked EE | |||
| certificate for the old manifest will be removed from the CRL when it | certificate for the old manifest will be removed from the CRL when it | |||
| expires, thus this procedure ought not to result in significant CRLs | expires, thus this procedure ought not to result in significant CRLs | |||
| growth.) | growth.) | |||
| 6. Local Cache Maintenance | 6. Local Cache Maintenance | |||
| In order to utilize signed objects issued under this PKI, a relying | In order to utilize signed objects issued under this PKI, a relying | |||
| party must first obtain a local copy of the valid EE certificates for | party must first obtain a local copy of the valid EE certificates for | |||
| the PKI. To do so, the relying party performs the following steps: | the PKI. To do so, the relying party performs the following steps: | |||
| 1. Query the registry system to obtain a copy of all certificates, | 1. Query the repository system to obtain a copy of all | |||
| manifests and CRLs issued under the PKI. | certificates, manifests and CRLs issued under the PKI. | |||
| 2. For each CA certificate in the PKI, verify the signature on the | 2. For each CA certificate in the PKI, verify the signature on the | |||
| corresponding manifest. Additionally, verify that the current | corresponding manifest. Additionally, verify that the current | |||
| time is earlier than the time indicated in the nextUpdate field | time is earlier than the time indicated in the nextUpdate field | |||
| of the manifest. | of the manifest. | |||
| 3. For each manifest, verify that certificates and CRLs issued | 3. For each manifest, verify that certificates and CRLs issued | |||
| under the corresponding CA certificate match the hash values | under the corresponding CA certificate match the hash values | |||
| contained in the manifest. Additionally, verify that no | contained in the manifest. Additionally, verify that no | |||
| certificate or manifest listed on the manifest is missing from | certificate or manifest listed on the manifest is missing from | |||
| skipping to change at page 18, line 26 ¶ | skipping to change at page 18, line 36 ¶ | |||
| certificates that are issued by the same or differing authorities, as | certificates that are issued by the same or differing authorities, as | |||
| reuse of a key pair complicates path construction. Note that since | reuse of a key pair complicates path construction. Note that since | |||
| the subject's distinguished name is chosen by the issuer, a subject | the subject's distinguished name is chosen by the issuer, a subject | |||
| who receives allocations from two sources generally will receive | who receives allocations from two sources generally will receive | |||
| certificates with different subject names. | certificates with different subject names. | |||
| 7.2. CA Key Rollover | 7.2. CA Key Rollover | |||
| Whenever a certification authority wishes to change the public key | Whenever a certification authority wishes to change the public key | |||
| (and corresponding private key) associated with its RPKI CA | (and corresponding private key) associated with its RPKI CA | |||
| certificate, it must perform a key rollover procedure. Key rollover | certificate, it MUST perform a key rollover procedure. Key rollover | |||
| is typically performed on a periodic basis, where the frequency of | is typically performed on a periodic basis, where the frequency of | |||
| key rollovers is specified in the certification practice statement of | key rollovers is specified in the certification practice statement of | |||
| the given CA. Additionally, unscheduled rollovers may be required in | the given CA. Additionally, unscheduled rollovers may be required in | |||
| the event of suspected key compromises. | the event of suspected key compromises. | |||
| Note that rollover is only required when the CA's key actually | Note that rollover is only required when the CA's key actually | |||
| changes, it is not required in cases where a new CA certificate is | changes, it is not required in cases where a new CA certificate is | |||
| issued with the same key as the previous certificate for this CA. For | issued with the same key as the previous certificate for this CA. For | |||
| example, a new CA certificate must be issued if the CA gains or | example, a new CA certificate must be issued if the CA gains or | |||
| relinquishes resource, or if the validity period of the resource | relinquishes resource, or if the validity period of the resource | |||
| skipping to change at page 21, line 46 ¶ | skipping to change at page 22, line 10 ¶ | |||
| ensured by appropriate controls on the repository system, as | ensured by appropriate controls on the repository system, as | |||
| described in Section 4.4. Likewise, because the repository system is | described in Section 4.4. Likewise, because the repository system is | |||
| structured as a distributed database, it should be inherently | structured as a distributed database, it should be inherently | |||
| resistant to denial of service attacks; nonetheless, appropriate | resistant to denial of service attacks; nonetheless, appropriate | |||
| precautions should also be taken, both through replication and backup | precautions should also be taken, both through replication and backup | |||
| of the constituent databases and through the physical security of | of the constituent databases and through the physical security of | |||
| database servers. | database servers. | |||
| 9. IANA Considerations | 9. IANA Considerations | |||
| This document requests that the IANA issue RPKI Certificates for the | Instructions for IANA's participation in the RPKI are provided in | |||
| resources for which it is authoritative, i.e., reserved IPv4 | [IANA-OBJ]. | |||
| addresses, IPv6 Unique Local Addresses (ULAs), and address space not | ||||
| yet allocated by IANA to the RIRs. IANA SHOULD make available trust | ||||
| anchor material in the format defined in [SIDR-TA] in support of | ||||
| these functions. | ||||
| 10. Acknowledgments | 10. Acknowledgments | |||
| The architecture described in this draft is derived from the | The architecture described in this draft is derived from the | |||
| collective ideas and work of a large group of individuals. This work | collective ideas and work of a large group of individuals. This work | |||
| would not have been possible without the intellectual contributions | would not have been possible without the intellectual contributions | |||
| of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of | of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of | |||
| APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim | APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim | |||
| Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy | Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy | |||
| Bush of IIJ. | Bush of IIJ. | |||
| skipping to change at page 23, line 26 ¶ | skipping to change at page 23, line 26 ¶ | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation | Infrastructure Certificate and Certificate Revocation | |||
| List (CRL) Profile", RFC 5280, May 2008. | List (CRL) Profile", RFC 5280, May 2008. | |||
| [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, | [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, | |||
| September 2009. | September 2009. | |||
| [RFC 3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP | [RFC 3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP | |||
| Addresses and AS Identifiers", RFC 3779, June 2004. | Addresses and AS Identifiers", RFC 3779, June 2004. | |||
| [RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile | [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI | |||
| Scheme", RFC 5781, February 2010. | ||||
| [RES-CERT] Huston, G., Michaelson, G., and R. Loomans, "A Profile | ||||
| for X.509 PKIX Resource Certificates", draft-ietf-sidr- | for X.509 PKIX Resource Certificates", draft-ietf-sidr- | |||
| res-certs, December 2010. | res-certs, May 2011. | |||
| [ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for | [ROA-FORM] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route | |||
| Route Origin Authorizations (ROA)", draft-ietf-sidr-roa- | Origin Authorizations (ROA)", draft-ietf-sidr-roa-format, | |||
| format, February 2011. | February 2011. | |||
| [SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object | [SIGN-OBJ] Chi, A., Kent, S., and M. Lepinski, "Signed Object | |||
| Template for the Resource Public Key Infrastructure", | Template for the Resource Public Key Infrastructure", | |||
| draft-ietf-sidr-signed-object, February 2010. | draft-ietf-sidr-signed-object, May 2011. | |||
| [MANIFEST] Austein, R., et al., "Manifests for the Resource Public | [MANIFEST] Austein, R., et al., "Manifests for the Resource Public | |||
| Key Infrastructure", draft-ietf-sidr-rpki-manifests, | Key Infrastructure", draft-ietf-sidr-rpki-manifests, May | |||
| November 2010. | 2011. | |||
| [REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile | [REPOS] Huston, G., Michaelson, G., and R. Loomans, "A Profile | |||
| for Resource Certificate Repository Structure", draft- | for Resource Certificate Repository Structure", draft- | |||
| ietf-sidr-repos-struct, November 2010. | ietf-sidr-repos-struct, February 2011. | |||
| 11.2. Informative References | [IANA-OBJ] Manderson, T., Vegoda, L. and S. Kent, "RPKI Objects | |||
| issued by IANA", draft-ietf-sidr-iana-objects, May 2011. | ||||
| [KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key | 11.2. Informative References | |||
| Rollover in the RPKI", draft-huston-sidr-keyroll, | ||||
| December 2010. | ||||
| [ROA-VALID] Huston, G., Michaelson, G., "Validation of Route | [KEY-ROLL] Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover | |||
| Origination in BGP using the Resource Certificate PKI", | in the RPKI", draft-huston-sidr-keyroll, February 2011. | |||
| draft-ietf-sidr-roa-validation, November 2010. | ||||
| [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI | [ROA-VALID] Huston, G., et al., "Validation of Route Origination in | |||
| Scheme", RFC 5781, February 2010. | BGP using the Resource Certificate PKI", draft-ietf-sidr- | |||
| roa-validation, April 2011. | ||||
| [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for | [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for | |||
| Trust Anchor Material for the Resource Certificate PKI", | Trust Anchor Material for the Resource Certificate PKI", | |||
| draft-ietf-sidr-ta, May 2010. | draft-ietf-sidr-ta, April 2011. | |||
| [S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway | [S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway | |||
| Protocol (Secure-BGP)", IEEE Journal on Selected Areas in | Protocol (Secure-BGP)", IEEE Journal on Selected Areas in | |||
| Communications Vol. 18, No. 4, April 2000. | Communications Vol. 18, No. 4, April 2000. | |||
| [soBGP] White, R., "soBGP", May 2005, <ftp://ftp- | [soBGP] White, R., "soBGP", May 2005, <ftp://ftp- | |||
| eng.cisco.com/sobgp/index.html> | eng.cisco.com/sobgp/index.html> | |||
| [RSYNC] Tridgell, A., "rsync", March 2008, < | [RSYNC] Tridgell, A., "rsync", March 2008, | |||
| http://rsync.samba.org/> | <http://rsync.samba.org/> | |||
| Authors' Addresses | Authors' Addresses | |||
| Matt Lepinski | Matt Lepinski | |||
| BBN Technologies | BBN Technologies | |||
| 10 Moulton St. | 10 Moulton St. | |||
| Cambridge, MA 02138 | Cambridge, MA 02138 | |||
| Email: mlepinski@bbn.com | Email: mlepinski@bbn.com | |||
| End of changes. 40 change blocks. | ||||
| 115 lines changed or deleted | 118 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||