draft-ietf-sidr-bgpsec-pki-profiles-21.txt   rfc8209.txt 
Secure Inter-Domain Routing Working Group M. Reynolds Internet Engineering Task Force (IETF) M. Reynolds
Internet-Draft IPSw Request for Comments: 8209 IPSw
Updates: 6487 (if approved) S. Turner Updates: 6487 S. Turner
Intended status: Standard Track sn3rd Category: Standards Track sn3rd
Expires: July 9, 2017 S. Kent ISSN: 2070-1721 S. Kent
BBN BBN
January 5, 2017 September 2017
A Profile for BGPsec Router Certificates, A Profile for BGPsec Router Certificates,
Certificate Revocation Lists, and Certification Requests Certificate Revocation Lists, and Certification Requests
draft-ietf-sidr-bgpsec-pki-profiles-21
Abstract Abstract
This document defines a standard profile for X.509 certificates used This document defines a standard profile for X.509 certificates used
to enable validation of Autonomous System (AS) paths in the Border to enable validation of Autonomous System (AS) paths in the Border
Gateway Protocol (BGP), as part of an extension to that protocol Gateway Protocol (BGP), as part of an extension to that protocol
known as BGPsec. BGP is the standard for inter-domain routing in the known as BGPsec. BGP is the standard for inter-domain routing in the
Internet; it is the "glue" that holds the Internet together. BGPsec Internet; it is the "glue" that holds the Internet together. BGPsec
is being developed as one component of a solution that addresses the is being developed as one component of a solution that addresses the
requirement to provide security for BGP. The goal of BGPsec is to requirement to provide security for BGP. The goal of BGPsec is to
provide full AS path validation based on the use of strong provide full AS path validation based on the use of strong
cryptographic primitives. The end-entity (EE) certificates specified cryptographic primitives. The end entity (EE) certificates specified
by this profile are issued to routers within an Autonomous System. by this profile are issued to routers within an AS. Each of these
Each of these certificates is issued under a Resource Public Key certificates is issued under a Resource Public Key Infrastructure
Infrastructure (RPKI) Certification Authority (CA) certificate. (RPKI) Certification Authority (CA) certificate. These CA
These CA certificates and EE certificates both contain the AS certificates and EE certificates both contain the AS Resource
Identifier Delegation extension. An EE certificate of this type extension. An EE certificate of this type asserts that the router or
asserts that the router(s) holding the corresponding private key are routers holding the corresponding private key are authorized to emit
authorized to emit secure route advertisements on behalf of the secure route advertisements on behalf of the AS(es) specified in the
AS(es) specified in the certificate. This document also profiles the certificate. This document also profiles the format of certification
format of certification requests, and specifies Relying Party (RP) requests and specifies Relying Party (RP) certificate path validation
certificate path validation procedures for these EE certificates. procedures for these EE certificates. This document extends the
This document extends the RPKI; therefore, this documents updates the RPKI; therefore, this document updates the RPKI Resource Certificates
RPKI Resource Certificates Profile (RFC 6487). Profile (RFC 6487).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8209.
material or to cite them other than as "work in progress."
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................4
2. Describing Resources in Certificates . . . . . . . . . . . . . 3 2. Describing Resources in Certificates ............................4
3. Updates to [RFC6487] . . . . . . . . . . . . . . . . . . . . . 5 3. Updates to RFC 6487 .............................................6
3.1 BGPsec Router Certificate Fields . . . . . . . . . . . . . 5 3.1. BGPsec Router Certificate Fields ...........................6
3.1.1. Subject . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Subject .............................................6
3.1.2. Subject Public Key Info . . . . . . . . . . . . . . . 5 3.1.2. Subject Public Key Info .............................6
3.1.3. BGPsec Router Certificate Version 3 Extension Fields . 5 3.1.3. BGPsec Router Certificate Version 3
3.1.3.1. Basic Constraints . . . . . . . . . . . . . . . . 5 Extension Fields ....................................6
3.1.3.2. Extended Key Usage . . . . . . . . . . . . . . . . 5 3.1.3.1. Basic Constraints ..........................6
3.1.3.3. Subject Information Access . . . . . . . . . . . . 6 3.1.3.2. Extended Key Usage .........................6
3.1.3.4. IP Resources . . . . . . . . . . . . . . . . . . . 6 3.1.3.3. Subject Information Access .................7
3.1.3.5. AS Resources . . . . . . . . . . . . . . . . . . . 6 3.1.3.4. IP Resources ...............................7
3.2. BGPsec Router Certificate Request Profile . . . . . . . . 6 3.1.3.5. AS Resources ...............................7
3.3. BGPsec Router Certificate Validation . . . . . . . . . . . 7 3.2. BGPsec Router Certificate Request Profile ..................7
3.4. Router Certificates and Signing Functions in the RPKI . . 7 3.3. BGPsec Router Certificate Validation .......................8
4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Router Certificates and Signing Functions in the RPKI ......8
5. Implementation Considerations . . . . . . . . . . . . . . . . . 8 4. Design Notes ....................................................9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Implementation Considerations ...................................9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations ........................................10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations ............................................10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References .....................................................11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References ......................................11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References ....................................12
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module ..........................................14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements ..................................................15
Authors' Addresses ................................................15
1. Introduction 1. Introduction
This document defines a profile for X.509 end-entity (EE) This document defines a profile for X.509 end entity (EE)
certificates [RFC5280] for use in the context of certification of certificates [RFC5280] for use in the context of certification of
Autonomous System (AS) paths in the BGPsec. Such certificates are Autonomous System (AS) paths in the BGPsec protocol. Such
termed "BGPsec Router Certificates". The holder of the private key certificates are termed "BGPsec Router Certificates". The holder of
associated with a BGPsec Router Certificate is authorized to send the private key associated with a BGPsec Router Certificate is
secure route advertisements (BGPsec UPDATEs) on behalf of the AS(es) authorized to send secure route advertisements (BGPsec UPDATEs) on
named in the certificate. A router holding the private key is behalf of the AS(es) named in the certificate. A router holding the
authorized to send route advertisements (to its peers) identifying private key is authorized to send route advertisements (to its peers)
the router's ASN as the source of the advertisements. A key property identifying the router's AS number (ASN) as the source of the
provided by BGPsec is that every AS along the AS PATH can verify that advertisements. A key property provided by BGPsec is that every AS
the other ASes along the path have authorized the advertisement of along the AS path can verify that the other ASes along the path have
the given route (to the next AS along the AS PATH). authorized the advertisement of the given route (to the next AS along
the AS path).
This document is a profile of [RFC6487], which is a profile of This document is a profile of [RFC6487], which is a profile of
[RFC5280]; thus this document updates [RFC6487]. It establishes [RFC5280]; thus, this document updates [RFC6487]. It establishes
requirements imposed on a Resource Certificate that is used as a requirements imposed on a Resource Certificate that is used as a
BGPsec Router Certificate, i.e., it defines constraints for BGPsec Router Certificate, i.e., it defines constraints for
certificate fields and extensions for the certificate to be valid in certificate fields and extensions for the certificate to be valid in
this context. This document also profiles the certification requests this context. This document also profiles the certification requests
used to acquire BGPsec Router Certificates. Finally, this document used to acquire BGPsec Router Certificates. Finally, this document
specifies the Relying Party (RP) certificate path validation specifies the Relying Party (RP) certificate path validation
procedures for these certificates. procedures for these certificates.
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 "A Profile for X.509 PKIX Resource Certificates" described in "A Profile for X.509 PKIX Resource Certificates"
[RFC6487], "BGPsec Protocol Specification" [ID.sidr-bgpsec-protocol], [RFC6487], "BGPsec Protocol Specification" [RFC8205], "A Border
"A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Vulnerabilities
Vulnerabilities Analysis" [RFC4272], "Considerations in Validating Analysis" [RFC4272], "Considerations in Validating the Path in BGP"
the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" [RFC5123], and "Capabilities Advertisement with BGP-4" [RFC5492].
[RFC5492].
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Describing Resources in Certificates 2. Describing Resources in Certificates
Figure 1 depicts some of the entities in the RPKI and some of the Figure 1 depicts some of the entities in the Resource Public Key
products generated by RPKI entities. IANA issues a Certification Infrastructure (RPKI) and some of the products generated by RPKI
Authority (CA) certificate to each Regional Internet Registry (RIR). entities. IANA issues a Certification Authority (CA) certificate to
The RIR, in turn, issues a CA certificate to an Internet Service each Regional Internet Registry (RIR). The RIR in turn issues a
Provider (ISP). The ISP in turn issues EE Certificates to itself to CA certificate to an Internet Service Provider (ISP). The ISP
enable verification of signatures on RPKI signed objects. The CA in turn issues EE certificates to itself to enable verification of
also generates Certificate Revocation Lists (CRLs). These CA and EE signatures on RPKI signed objects. The CA also generates Certificate
certificates are referred to as "Resource Certificates", and are Revocation Lists (CRLs). These CA and EE certificates are referred
profiled in [RFC6487]. [RFC6480] envisioned using Resource to as "Resource Certificates" and are profiled in [RFC6487].
Certificates to enable verification of Manifests [RFC6486] and Route [RFC6480] envisioned using Resource Certificates to enable
Origin Authorizations (ROAs) [RFC6482]. ROAs and Manifests include verification of manifests [RFC6486] and Route Origin Authorizations
the Resource Certificates used to verify them. (ROAs) [RFC6482]. ROAs and manifests include the Resource
Certificates used to verify them.
+---------+ +------+ +---------+ +------+
| CA Cert |---| IANA | | CA Cert |---| IANA |
+---------+ +------+ +---------+ +------+
\ \
+---------+ +-----+ +---------+ +-----+
| CA Cert |---| RIR | | CA Cert |---| RIR |
+---------+ +-----+ +---------+ +-----+
\ \
+---------+ +-----+ +---------+ +-----+
skipping to change at page 4, line 31 skipping to change at page 5, line 25
+---------+ +-----+ +---------+ +-----+
/ | | | / | | |
+-----+ / | | | +-----+ +-----+ / | | | +-----+
| CRL |--+ | | +---| ROA | | CRL |--+ | | +---| ROA |
+-----+ | | +-----+ +-----+ | | +-----+
| | +----------+ | | +----------+
+----+ | +---| Manifest | +----+ | +---| Manifest |
+-| EE |---+ +----------+ +-| EE |---+ +----------+
| +----+ | +----+
+-----+ +-----+
Figure 1
Figure 1
This document defines another type of Resource Certificate, which is This document defines another type of Resource Certificate, which is
referred to as a "BGPsec Router Certificate". The purpose of this referred to as a "BGPsec Router Certificate". The purpose of this
certificate is explained in Section 1 and falls within the scope of certificate is explained in Section 1 and falls within the scope of
appropriate uses defined within [RFC6484]. The issuance of BGPsec appropriate uses defined within [RFC6484]. The issuance of BGPsec
Router Certificates has minimal impact on RPKI CAs because the RPKI Router Certificates has minimal impact on RPKI CAs because the RPKI
CA certificate and CRL profile remain unchanged (i.e., they are as CA certificate and CRL profile remain unchanged (i.e., they are as
specified in [RFC6487]). Further, the algorithms used to generate specified in [RFC6487]). Further, the algorithms used to generate
RPKI CA certificates that issue the BGPsec Router Certificates and RPKI CA certificates that issue the BGPsec Router Certificates and
the CRLs necessary to check the validity of the BGPsec Router the CRLs necessary to check the validity of the BGPsec Router
Certificates remain unchanged (i.e., they are as specified in Certificates remain unchanged (i.e., they are as specified in
[RFC7935]). The only impact is that RPKI CAs will need to be able to [RFC7935]). The only impact is that RPKI CAs will need to be able to
process a profiled certificate request (see Section 5) signed with process a profiled certificate request (see Section 3.2) signed with
algorithms found in [ID.sidr-bgpsec-algs]. BGPsec Router algorithms found in [RFC8208]. BGPsec Router Certificates are used
Certificates are used only to verify the signature on the BGPsec only to verify the signature on the BGPsec certificate request (only
certificate request (only CAs process these) and the signature on a CAs process these) and the signature on a BGPsec UPDATE message
BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers [RFC8205] (only BGPsec routers process these); BGPsec Router
process these); BGPsec Router Certificates are not used to process Certificates are not used to process manifests and ROAs or verify
Manifests and ROAs or verify signatures on Certificates or CRLs. signatures on Certificates or CRLs.
This document enumerates only the differences between this profile This document enumerates only the differences between this profile
and the profile in [RFC6487]. Note that BGPsec Router Certificates and the profile in [RFC6487]. Note that BGPsec Router Certificates
are EE certificates and as such there is no impact on process are EE certificates, and as such there is no impact on the algorithm
described in [RFC6916]. agility procedure described in [RFC6916].
3. Updates to [RFC6487] 3. Updates to RFC 6487
3.1 BGPsec Router Certificate Fields 3.1. BGPsec Router Certificate Fields
A BGPsec Router Certificate is consistent with the profile in A BGPsec Router Certificate is consistent with the profile in
[RFC6487] as modified by the specifications in this section. As [RFC6487] as modified by the specifications in this section. As
such, it is a valid X.509 public key certificate and consistent with such, it is a valid X.509 public key certificate and consistent with
the PKIX profile [RFC5280]. The differences between this profile and the PKIX profile [RFC5280]. The differences between this profile and
the profile in [RFC6487] are specified in this section. the profile in [RFC6487] are specified in this section.
3.1.1. Subject 3.1.1. Subject
Common name encoding options that are supported are printableString Encoding options for the common name that are supported are
and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED printableString and UTF8String. For BGPsec Router Certificates, it
that the common name attribute contain the literal string "ROUTER-" is RECOMMENDED that the common name attribute contain the literal
followed by the 32-bit AS Number [RFC3779] encoded as eight string "ROUTER-" followed by the 32-bit ASN [RFC3779] encoded as
hexadecimal digits and that the serial number attribute contain the eight hexadecimal digits and that the serial number attribute contain
32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as
eight hexadecimal digits. If there is more than one AS number, the eight hexadecimal digits. If there is more than one ASN, the choice
choice of which to include in the common name is at the discretion of of which to include in the common name is at the discretion of the
the Issuer. If the same certificate is issued to more than one router Issuer. If the same certificate is issued to more than one router
(hence the private key is shared among these routers), the choice of (and hence the private key is shared among these routers), the choice
the router ID used in this name is at the discretion of the Issuer. of the router ID used in this name is at the discretion of the
Issuer.
3.1.2. Subject Public Key Info 3.1.2. Subject Public Key Info
Refer to section 3.1 of [ID.sidr-bgpsec-algs]. Refer to Section 3.1 of [RFC8208].
3.1.3. BGPsec Router Certificate Version 3 Extension Fields 3.1.3. BGPsec Router Certificate Version 3 Extension Fields
3.1.3.1. Basic Constraints 3.1.3.1. Basic Constraints
BGPsec speakers are EEs; therefore, the Basic Constraints extension BGPsec speakers are EEs; therefore, the Basic Constraints extension
must not be present, as per [RFC6487]. must not be present, as per [RFC6487].
3.1.3.2. Extended Key Usage 3.1.3.2. Extended Key Usage
BGPsec Router Certificates MUST include the Extended Key Usage (EKU) BGPsec Router Certificates MUST include the Extended Key Usage (EKU)
extension. As specified in [RFC6487] this extension must be marked extension. As specified in [RFC6487], this extension must not be
as non-critical. This document defines one EKU for BGPsec Router marked critical. This document defines one EKU for BGPsec Router
Certificates: Certificates:
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) } security(5) mechanisms(5) pkix(7) kp(3) }
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
A BGPsec router MUST require the extended key usage extension to be A BGPsec router MUST require the EKU extension be present in a BGPsec
present in a BGPsec Router Certificate it receives. If multiple Router Certificate it receives. If multiple KeyPurposeId values are
KeyPurposeId values are included, the BGPsec routers need not included, the BGPsec routers need not recognize all of them, as long
recognize all of them, as long as the required KeyPurposeId value is as the required KeyPurposeId value is present. BGPsec routers MUST
present. BGPsec routers MUST reject certificates that do not contain reject certificates that do not contain the BGPsec Router EKU even if
the BGPsec Router EKU even if they include the anyExtendedKeyUsage they include the anyExtendedKeyUsage OID defined in [RFC5280].
OID defined in [RFC5280].
3.1.3.3. Subject Information Access 3.1.3.3. Subject Information Access
This extension is not used in BGPsec Router Certificates. It MUST be This extension is not used in BGPsec Router Certificates. It MUST be
omitted. omitted.
3.1.3.4. IP Resources 3.1.3.4. IP Resources
This extension is not used in BGPsec Router Certificates. It MUST be This extension is not used in BGPsec Router Certificates. It MUST be
omitted. omitted.
3.1.3.5. AS Resources 3.1.3.5. AS Resources
Each BGPsec Router Certificate MUST include the AS Resource Each BGPsec Router Certificate MUST include the AS Resources
Identifier Delegation extension, as specified in section 4.8.11 of extension, as specified in Section 4.8.11 of [RFC6487]. The
[RFC6487]. The AS Resource Identifier Delegation extension MUST AS Resources extension MUST include one or more ASNs, and the
include one or more AS numbers, and the "inherit" element MUST NOT be "inherit" element MUST NOT be specified.
specified.
3.2. BGPsec Router Certificate Request Profile 3.2. BGPsec Router Certificate Request Profile
Refer to section 6 of [RFC6487]. The only differences between this Refer to Section 6 of [RFC6487]. The only differences between this
profile and the profile in [RFC6487] are: profile and the profile in [RFC6487] are as follows:
o The Basic Constraints extension: o The Basic Constraints extension:
If included, the CA MUST NOT honor the cA boolean if set to TRUE. If included, the CA MUST NOT honor the cA boolean if set to TRUE.
o The Extended Key Usage extension: o The EKU extension:
If included, id-kp-bgpsec-router MUST be present (see Section If included, id-kp-bgpsec-router MUST be present (see
3.1). If included, the CA MUST honor the request for id-kp- Section 3.1.3.2). If included, the CA MUST honor the request for
bgpsec-router. id-kp-bgpsec-router.
o The Subject Information Access extension: o The Subject Information Access (SIA) extension:
If included, the CA MUST NOT honor the request to include the If included, the CA MUST NOT honor the request to include the
extension. extension.
o The SubjectPublicKeyInfo field is specified in [ID.sidr-bgpsec- o The SubjectPublicKeyInfo field is specified in [RFC8208].
algs].
o The request is signed with the algorithms specified in [ID.sidr- o The request is signed with the algorithms specified in [RFC8208].
bgpsec-algs].
3.3. BGPsec Router Certificate Validation 3.3. BGPsec Router Certificate Validation
The validation procedure used for BGPsec Router Certificates is The validation procedure used for BGPsec Router Certificates is
identical to the validation procedure described in Section 7 of identical to the validation procedure described in Section 7 of
[RFC6487] (and any RFC that updates that procedure), as modified [RFC6487] (and any RFC that updates that procedure), as modified
below. For example, in step 3: "The certificate contains all fields below. For example, in step 3 (of the criteria listed in Section 7.2
that MUST be present" - refers to the fields that are required by of [RFC6487]), "The certificate contains all fields that MUST be
this specification. present" refers to the fields that are required by this
specification.
The differences are as follows: The differences are as follows:
o BGPsec Router Certificates MUST include the BGPsec Router EKU o BGPsec Router Certificates MUST include the BGPsec Router EKU
defined in Section 3.1.3.2. defined in Section 3.1.3.2.
o BGPsec Router Certificates MUST NOT include the SIA extension. o BGPsec Router Certificates MUST NOT include the SIA extension.
o BGPsec Router Certificates MUST NOT include the IP Resource o BGPsec Router Certificates MUST NOT include the IP Resources
extension. extension.
o BGPsec Router Certificates MUST include the AS Resource Identifier o BGPsec Router Certificates MUST include the AS Resources
Delegation extension. extension.
o BGPsec Router Certificate MUST include the subjectPublicKeyInfo o BGPsec Router Certificates MUST include the subjectPublicKeyInfo
described in [ID.sidr-bgpsec-algs]. field described in [RFC8208].
NOTE: BGPsec RPs will need to support the algorithms in [ID.sidr- NOTE: BGPsec RPs will need to support the algorithms in [RFC8208],
bgpsec-algs], which are used to validate BGPsec signatures, as well which are used to validate BGPsec signatures, as well as the
as the algorithms in [RFC7935], which are needed to validate algorithms in [RFC7935], which are needed to validate signatures on
signatures on BGPsec certificates, RPKI CA certificates, and RPKI BGPsec certificates, RPKI CA certificates, and RPKI CRLs.
CRLs.
3.4. Router Certificates and Signing Functions in the RPKI 3.4. Router Certificates and Signing Functions in the RPKI
As described in Section 1, the primary function of BGPsec route As described in Section 1, the primary function of BGPsec Router
certificates in the RPKI is for use in the context of certification Certificates in the RPKI is for use in the context of certification
of Autonomous System (AS) paths in the BGPsec protocol. of AS paths in the BGPsec protocol.
The private key associated with a router EE certificate may be used The private key associated with a router EE certificate may be used
multiple times in generating signatures in multiple instances of the multiple times in generating signatures in multiple instances of the
BGPsec_Path Attribute Signature Segments [ID.sidr-bgpsec-protocol]. BGPsec_PATH attribute Signature Segments [RFC8205]. That is, the
I.e., the BGPsec router certificate is used to validate multiple BGPsec Router Certificate is used to validate multiple signatures.
signatures.
BGPsec router certificates are stored in the issuing CA's repository, BGPsec Router Certificates are stored in the issuing CA's repository,
where a repository following RFC6481 MUST use a .cer filename where a repository following [RFC6481] MUST use a .cer filename
extension for the certificate file. extension for the certificate file.
4. Design Notes 4. Design Notes
The BGPsec Router Certificate profile is based on the Resource The BGPsec Router Certificate profile is based on the Resource
Certificate profile as specified in [RFC7935]. As a result, many of Certificate profile as specified in [RFC6487]. As a result, many of
the design choices herein are a reflection of the design choices that the design choices herein are a reflection of the design choices that
were taken in that prior work. The reader is referred to [RFC6484] were taken in that prior work. The reader is referred to [RFC6484]
for a fuller discussion of those choices. for a fuller discussion of those choices.
CAs are required by the Certificate Policy (CP) [RFC6484] to issue CAs are required by the Certificate Policy (CP) [RFC6484] to issue
properly formed BGPsec Router Certificates regardless of what is properly formed BGPsec Router Certificates regardless of what is
present in the certification request so there is some flexibility present in the certificate request, so there is some flexibility
permitted in the certificate requests: permitted in the certificate requests:
o BGPsec Router Certificates are always EE certificates; therefore, o BGPsec Router Certificates are always EE certificates; therefore,
requests to issue a CA certificate result in EE certificates; requests to issue a CA certificate result in EE certificates;
o BGPsec Router Certificates are always EE certificates; therefore, o BGPsec Router Certificates are always EE certificates; therefore,
requests for Key Usage extension values keyCertSign and cRLSign requests for Key Usage extension values keyCertSign and cRLSign
result in certificates with neither of these values; result in certificates with neither of these values;
o BGPsec Router Certificates always include the BGPsec Rouer EKU o BGPsec Router Certificates always include the BGPsec Router EKU
value; therefore, request without the value result in certificates value; therefore, requests without the value result in
with the value; and, certificates with the value; and,
o BGPsec Router Certificates never include the Subject Information o BGPsec Router Certificates never include the SIA extension;
Access extension; therefore, request with this extension result in therefore, requests with this extension result in certificates
certificates without the extension. without the extension.
Note that this behavior is similar to the CA including the AS Note that this behavior is similar to the CA including the
Resource Identifier Delegation extension in issued BGPsec Router AS Resources extension in issued BGPsec Router Certificates, despite
Certificates despite the fact it is not present in the request. the fact that it is not present in the request.
5. Implementation Considerations 5. Implementation Considerations
This document permits the operator to include a list of ASNs in a This document permits the operator to include a list of ASNs in a
BGPsec Router Certificate. In that case, the router certificate would BGPsec Router Certificate. In that case, the router certificate
become invalid if any one of the ASNs is removed from any superior CA would become invalid if any one of the ASNs is removed from any
certificate along the path to a trust anchor. Operators could choose superior CA certificate along the path to a trust anchor. Operators
to avoid this possibility by issuing a separate BGPsec Router could choose to avoid this possibility by issuing a separate BGPsec
Certificate for each distinct ASN, so that the router certificates Router Certificate for each distinct ASN, so that the router
for ASNs that are retained in the superior CA certificate would certificates for ASNs that are retained in the superior CA
remain valid. certificate would remain valid.
6. Security Considerations 6. Security Considerations
The Security Considerations of [RFC6487] apply. The security considerations of [RFC6487] apply.
A BGPsec Router Certificate will fail RPKI validation, as defined in A BGPsec Router Certificate will fail RPKI validation as defined in
[RFC6487], because the cryptographic algorithms used are different. [RFC6487] because the cryptographic algorithms used are different.
Consequently, a RP needs to identify the EKU to determine the Consequently, an RP needs to identify the EKU to determine the
appropriate Validation constraint. appropriate Validation constraint.
A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to
encompass routers. It is a building block BGPsec and is used to encompass routers. It is a building block of BGPsec and is used to
validate signatures on BGPsec Signature-Segment origination of validate signatures on BGPsec Signature Segment origination of
Signed-Path segments [ID.sidr-bgpsec-protocol]. Thus its essential signed path segments [RFC8205]. Thus, its essential security
security function is the secure binding of one or more AS numbers to function is the secure binding of one or more ASNs to a public key,
a public key, consistent with the RPKI allocation/assignment consistent with the RPKI allocation/assignment hierarchy.
hierarchy.
Hash functions [ID.sidr-bgpsec-algs] are used when generating the two Hash functions [RFC8208] are used when generating the two key
key identifier extensions (i.e., Subject Key Identifier and Issuer identifier extensions (i.e., Subject Key Identifier and Issuer Key
Key Identifier) included in BGPsec certificates. However as noted in Identifier) included in BGPsec certificates. However, as noted in
[RFC6818], collision resistance is not a required property of one-way [RFC6818], collision resistance is not a required property of one-way
hash functions when used to generate key identifiers. Regardless, hash functions when used to generate key identifiers. Regardless,
hash collisions are unlikely, but they are possible and if detected hash collisions are unlikely, but they are possible, and if detected
an operator should be alerted. A subject key identifier collision an operator should be alerted. A Subject Key Identifier collision
might cause the incorrect certificate to be selected from the cache, might cause the incorrect certificate to be selected from the cache,
resulting in a failed signature validation. resulting in a failed signature validation.
7. IANA Considerations 7. IANA Considerations
This document makes use of two object identifiers in the SMI Registry This document makes use of two OIDs in the SMI registry for PKIX.
for PKIX. One is for the ASN.1 module in Appendix A and it comes One is for the ASN.1 module [X680] [X690] in Appendix A, and it comes
from the SMI Security for PKIX Module Identifier IANA registry (id- from the "SMI Security for PKIX Module Identifier" IANA registry
mod-bgpsec-eku). The other is for the BGPsec router EKU defined in (id-mod-bgpsec-eku). The other is for the BGPsec Router EKU defined
Section 3.1.3.2 and Appendix A and it comes from the SMI Security for in Section 3.1.3.2 and Appendix A, and it comes from the "SMI
PKIX Extended Key Purpose IANA registry. These OIDs were assigned Security for PKIX Extended Key Purpose" IANA registry
before management of the PKIX Arc was handed to IANA. No IANA (id-kp-bgpsec-router). These OIDs were assigned before management of
allocations are request of IANA, but please update the references in the PKIX Arc was handed to IANA. The references in those registries
those registries when this document is published by the RFC editor. have been updated to point to this document.
8. Acknowledgements 8. References
We would like to thank Geoff Huston, George Michaelson, and Robert 8.1. Normative References
Loomans for their work on [RFC6487], which this work is based on. In
addition, the efforts of Matt Lepinski were instrumental in preparing
this work. Additionally, we'd like to thank Rob Austein, Roque
Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra
Murphy, and Sam Weiller for their reviews and comments.
9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.1. Normative References [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for
IP Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Requirement Levels", BCP 14, RFC 2119, DOI Border Gateway Protocol 4 (BGP-4)", RFC 4271,
10.17487/RFC2119, March 1997, <http://www.rfc- DOI 10.17487/RFC4271, January 2006,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Addresses and AS Identifiers", RFC 3779, DOI Housley, R., and W. Polk, "Internet X.509 Public Key
10.17487/RFC3779, June 2004, <http://www.rfc- Infrastructure Certificate and Certificate Revocation List
editor.org/info/rfc3779>. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Gateway Protocol 4 (BGP-4)", RFC 4271, DOI Resource Certificate Repository Structure", RFC 6481,
10.17487/RFC4271, January 2006, <http://www.rfc- DOI 10.17487/RFC6481, February 2012,
editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
Housley, R., and W. Polk, "Internet X.509 Public Key "Manifests for the Resource Public Key Infrastructure
Infrastructure Certificate and Certificate Revocation List (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc6486>.
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
"Manifests for the Resource Public Key Infrastructure X.509 PKIX Resource Certificates", RFC 6487,
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6486>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
X.509 PKIX Resource Certificates", RFC 6487, DOI Algorithms and Key Sizes for Use in the Resource Public
10.17487/RFC6487, February 2012, <http://www.rfc- Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
editor.org/info/rfc6487>. August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
Algorithms and Key Sizes for Use in the Resource Public Key RFC 2119 Key Words", BCP 14, RFC 8174,
Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August DOI 10.17487/RFC8174, May 2017,
2016, <http://www.rfc-editor.org/info/rfc7935>. <https://www.rfc-editor.org/info/rfc8174>.
[ID.sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol
Protocol Specification", draft-ietf-sidr-bgpsec-protocol, Specification", RFC 8205, DOI 10.17487/RFC8205,
work-in-progress. September 2017,
<https://www.rfc-editor.org/info/rfc8205>.
[ID.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & [RFC8208] Turner, S. and O. Borchert, "BGP Algorithms, Key Formats,
Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in- and Signature Formats", RFC 8208, DOI 10.17487/RFC8208,
progress. September 2017,
<https://www.rfc-editor.org/info/rfc8208>.
9.2. Informative References [X680] ITU-T, "Information technology - Abstract Syntax
Notation One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015,
<https://www.itu.int/rec/T-REC-X.680/en>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [X690] ITU-T, "Information technology - ASN.1 encoding rules:
RFC 4272, DOI 10.17487/RFC4272, January 2006, Specification of Basic Encoding Rules (BER), Canonical
<http://www.rfc-editor.org/info/rfc4272>. Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,
August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[RFC5123] White, R. and B. Akyol, "Considerations in Validating the 8.2. Informative References
Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February
2008, <http://www.rfc-editor.org/info/rfc5123>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc5492>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC5123] White, R. and B. Akyol, "Considerations in Validating the
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Path in BGP", RFC 5123, DOI 10.17487/RFC5123,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2008, <https://www.rfc-editor.org/info/rfc5123>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
Origin Authorizations (ROAs)", RFC 6482, DOI with BGP-4", RFC 5492, DOI 10.17487/RFC5492,
10.17487/RFC6482, February 2012, <http://www.rfc- February 2009, <https://www.rfc-editor.org/info/rfc5492>.
editor.org/info/rfc6482>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Policy (CP) for the Resource Public Key Infrastructure Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
(RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February February 2012, <https://www.rfc-editor.org/info/rfc6480>.
2012, <http://www.rfc-editor.org/info/rfc6484>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
"Manifests for the Resource Public Key Infrastructure Origin Authorizations (ROAs)", RFC 6482,
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, DOI 10.17487/RFC6482, February 2012,
<http://www.rfc-editor.org/info/rfc6486>. <https://www.rfc-editor.org/info/rfc6482>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Procedure for the Resource Public Key Infrastructure Policy (CP) for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484,
2013, <http://www.rfc-editor.org/info/rfc6916>. February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818,
January 2013, <https://www.rfc-editor.org/info/rfc6818>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916,
April 2013, <https://www.rfc-editor.org/info/rfc6916>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 12, line 30 skipping to change at page 15, line 5
id-kp OBJECT IDENTIFIER ::= { id-kp OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) } security(5) mechanisms(5) pkix(7) kp(3) }
-- BGPsec Router Extended Key Usage -- -- BGPsec Router Extended Key Usage --
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
END END
Acknowledgements
We would like to thank Geoff Huston, George Michaelson, and Robert
Loomans for their work on [RFC6487], which this work is based on. In
addition, the efforts of Matt Lepinski were instrumental in preparing
this work. Additionally, we'd like to thank Rob Austein, Roque
Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra
Murphy, and Sam Weiler for their reviews and comments.
Authors' Addresses Authors' Addresses
Mark Reynolds Mark Reynolds
Island Peak Software Island Peak Software
328 Virginia Road 328 Virginia Road
Concord, MA 01742 Concord, MA 01742
United States of America
Email: mcr@islandpeaksoftware.com Email: mcr@islandpeaksoftware.com
Sean Turner Sean Turner
sn3rd sn3rd
EMail: sean@sn3rd.com Email: sean@sn3rd.com
Stephen Kent Stephen Kent
Raytheon BBN Technologies Raytheon BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
United States of America
Email: kent@bbn.com Email: kent@alum.mit.edu
 End of changes. 88 change blocks. 
285 lines changed or deleted 307 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/