BGPsec Router Certs: A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
The certificate that lets a router prove it may sign route advertisements on behalf of its network.
Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
@misc{rfc8209,
series = {Request for Comments},
number = 8209,
howpublished = {RFC 8209},
publisher = {RFC Editor},
doi = {10.17487/RFC8209},
url = {https://www.rfc-editor.org/info/rfc8209},
author = {M. Reynolds and S. Turner and S. Kent},
title = {{A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests}},
pagetotal = 15,
year = 2017,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Reynolds
Request for Comments: 8209 IPSw
Updates: 6487 S. Turner
Category: Standards Track sn3rd
ISSN: 2070-1721 S. Kent
BBN
September 2017
A Profile for BGPsec Router Certificates,
Certificate Revocation Lists, and Certification Requests
Abstract
This document defines a standard profile for X.509 certificates used
to enable validation of Autonomous System (AS) paths in the Border
Gateway Protocol (BGP), as part of an extension to that protocol
known as BGPsec. BGP is the standard for inter-domain routing in the
Internet; it is the "glue" that holds the Internet together. BGPsec
is being developed as one component of a solution that addresses the
requirement to provide security for BGP. The goal of BGPsec is to
provide full AS path validation based on the use of strong
cryptographic primitives. The end entity (EE) certificates specified
by this profile are issued to routers within an AS. Each of these
certificates is issued under a Resource Public Key Infrastructure
(RPKI) Certification Authority (CA) certificate. These CA
certificates and EE certificates both contain the AS Resource
extension. An EE certificate of this type asserts that the router or
routers holding the corresponding private key are authorized to emit
secure route advertisements on behalf of the AS(es) specified in the
certificate. This document also profiles the format of certification
requests and specifies Relying Party (RP) certificate path validation
procedures for these EE certificates. This document extends the
RPKI; therefore, this document updates the RPKI Resource Certificates
Profile (RFC 6487).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8209.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Describing Resources in Certificates ............................4
3. Updates to RFC 6487 .............................................6
3.1. BGPsec Router Certificate Fields ...........................6
3.1.1. Subject .............................................6
3.1.2. Subject Public Key Info .............................6
3.1.3. BGPsec Router Certificate Version 3
Extension Fields ....................................6
3.1.3.1. Basic Constraints ..........................6
3.1.3.2. Extended Key Usage .........................6
3.1.3.3. Subject Information Access .................7
3.1.3.4. IP Resources ...............................7
3.1.3.5. AS Resources ...............................7
3.2. BGPsec Router Certificate Request Profile ..................7
3.3. BGPsec Router Certificate Validation .......................8
3.4. Router Certificates and Signing Functions in the RPKI ......8
4. Design Notes ....................................................9
5. Implementation Considerations ...................................9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Appendix A. ASN.1 Module ..........................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
1. Introduction
This document defines a profile for X.509 end entity (EE)
certificates [RFC5280] for use in the context of certification of
Autonomous System (AS) paths in the BGPsec protocol. Such
certificates are termed "BGPsec Router Certificates". The holder of
the private key associated with a BGPsec Router Certificate is
authorized to send secure route advertisements (BGPsec UPDATEs) on
behalf of the AS(es) named in the certificate. A router holding the
private key is authorized to send route advertisements (to its peers)
identifying the router's AS number (ASN) as the source of the
advertisements. A key property provided by BGPsec is that every AS
along the AS path can verify that the other ASes along the path have
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
[RFC5280]; thus, this document updates [RFC6487]. It establishes
requirements imposed on a Resource Certificate that is used as a
BGPsec Router Certificate, i.e., it defines constraints for
certificate fields and extensions for the certificate to be valid in
this context. This document also profiles the certification requests
used to acquire BGPsec Router Certificates. Finally, this document
specifies the Relying Party (RP) certificate path validation
procedures for these certificates.
1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts
described in "A Profile for X.509 PKIX Resource Certificates"
[RFC6487], "BGPsec Protocol Specification" [RFC8205], "A Border
Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Vulnerabilities
Analysis" [RFC4272], "Considerations in Validating the Path in BGP"
[RFC5123], and "Capabilities Advertisement with BGP-4" [RFC5492].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Describing Resources in Certificates
Figure 1 depicts some of the entities in the Resource Public Key
Infrastructure (RPKI) and some of the products generated by RPKI
entities. IANA issues a Certification Authority (CA) certificate to
each Regional Internet Registry (RIR). The RIR in turn issues a
CA certificate to an Internet Service Provider (ISP). The ISP
in turn issues EE certificates to itself to enable verification of
signatures on RPKI signed objects. The CA also generates Certificate
Revocation Lists (CRLs). These CA and EE certificates are referred
to as "Resource Certificates" and are profiled in [RFC6487].
[RFC6480] envisioned using Resource Certificates to enable
verification of manifests [RFC6486] and Route Origin Authorizations
(ROAs) [RFC6482]. ROAs and manifests include the Resource
Certificates used to verify them.
+---------+ +------+
| CA Cert |---| IANA |
+---------+ +------+
\
+---------+ +-----+
| CA Cert |---| RIR |
+---------+ +-----+
\
+---------+ +-----+
| CA Cert |---| ISP |
+---------+ +-----+
/ | | |
+-----+ / | | | +-----+
| CRL |--+ | | +---| ROA |
+-----+ | | +-----+
| | +----------+
+----+ | +---| Manifest |
+-| EE |---+ +----------+
| +----+
+-----+
Figure 1
This document defines another type of Resource Certificate, which is
referred to as a "BGPsec Router Certificate". The purpose of this
certificate is explained in Section 1 and falls within the scope of
appropriate uses defined within [RFC6484]. The issuance of BGPsec
Router Certificates has minimal impact on RPKI CAs because the RPKI
CA certificate and CRL profile remain unchanged (i.e., they are as
specified in [RFC6487]). Further, the algorithms used to generate
RPKI CA certificates that issue the BGPsec Router Certificates and
the CRLs necessary to check the validity of the BGPsec Router
Certificates remain unchanged (i.e., they are as specified in
[RFC7935]). The only impact is that RPKI CAs will need to be able to
process a profiled certificate request (see Section 3.2) signed with
algorithms found in [RFC8208]. BGPsec Router Certificates are used
only to verify the signature on the BGPsec certificate request (only
CAs process these) and the signature on a BGPsec UPDATE message
[RFC8205] (only BGPsec routers process these); BGPsec Router
Certificates are not used to process manifests and ROAs or verify
signatures on Certificates or CRLs.
This document enumerates only the differences between this profile
and the profile in [RFC6487]. Note that BGPsec Router Certificates
are EE certificates, and as such there is no impact on the algorithm
agility procedure described in [RFC6916].
3. Updates to RFC 6487
3.1. BGPsec Router Certificate Fields
A BGPsec Router Certificate is consistent with the profile in
[RFC6487] as modified by the specifications in this section. As
such, it is a valid X.509 public key certificate and consistent with
the PKIX profile [RFC5280]. The differences between this profile and
the profile in [RFC6487] are specified in this section.
3.1.1. Subject
Encoding options for the common name that are supported are
printableString and UTF8String. For BGPsec Router Certificates, it
is RECOMMENDED that the common name attribute contain the literal
string "ROUTER-" followed by the 32-bit ASN [RFC3779] encoded as
eight hexadecimal digits and that the serial number attribute contain
the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as
eight hexadecimal digits. If there is more than one ASN, the choice
of which to include in the common name is at the discretion of the
Issuer. If the same certificate is issued to more than one router
(and hence the private key is shared among these routers), the choice
of the router ID used in this name is at the discretion of the
Issuer.
3.1.2. Subject Public Key Info
Refer to Section 3.1 of [RFC8208].
3.1.3. BGPsec Router Certificate Version 3 Extension Fields
3.1.3.1. Basic Constraints
BGPsec speakers are EEs; therefore, the Basic Constraints extension
must not be present, as per [RFC6487].
3.1.3.2. Extended Key Usage
BGPsec Router Certificates MUST include the Extended Key Usage (EKU)
extension. As specified in [RFC6487], this extension must not be
marked critical. This document defines one EKU for BGPsec Router
Certificates:
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
A BGPsec router MUST require the EKU extension be present in a BGPsec
Router Certificate it receives. If multiple KeyPurposeId values are
included, the BGPsec routers need not recognize all of them, as long
as the required KeyPurposeId value is present. BGPsec routers MUST
reject certificates that do not contain the BGPsec Router EKU even if
they include the anyExtendedKeyUsage OID defined in [RFC5280].
3.1.3.3. Subject Information Access
This extension is not used in BGPsec Router Certificates. It MUST be
omitted.
3.1.3.4. IP Resources
This extension is not used in BGPsec Router Certificates. It MUST be
omitted.
3.1.3.5. AS Resources
Each BGPsec Router Certificate MUST include the AS Resources
extension, as specified in Section 4.8.11 of [RFC6487]. The
AS Resources extension MUST include one or more ASNs, and the
"inherit" element MUST NOT be specified.
3.2. BGPsec Router Certificate Request Profile
Refer to Section 6 of [RFC6487]. The only differences between this
profile and the profile in [RFC6487] are as follows:
o The Basic Constraints extension:
If included, the CA MUST NOT honor the cA boolean if set to TRUE.
o The EKU extension:
If included, id-kp-bgpsec-router MUST be present (see
Section 3.1.3.2). If included, the CA MUST honor the request for
id-kp-bgpsec-router.
o The Subject Information Access (SIA) extension:
If included, the CA MUST NOT honor the request to include the
extension.
o The SubjectPublicKeyInfo field is specified in [RFC8208].
o The request is signed with the algorithms specified in [RFC8208].
3.3. BGPsec Router Certificate Validation
The validation procedure used for BGPsec Router Certificates is
identical to the validation procedure described in Section 7 of
[RFC6487] (and any RFC that updates that procedure), as modified
below. For example, in step 3 (of the criteria listed in Section 7.2
of [RFC6487]), "The certificate contains all fields that MUST be
present" refers to the fields that are required by this
specification.
The differences are as follows:
o BGPsec Router Certificates MUST include the BGPsec Router EKU
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 IP Resources
extension.
o BGPsec Router Certificates MUST include the AS Resources
extension.
o BGPsec Router Certificates MUST include the subjectPublicKeyInfo
field described in [RFC8208].
NOTE: BGPsec RPs will need to support the algorithms in [RFC8208],
which are used to validate BGPsec signatures, as well as the
algorithms in [RFC7935], which are needed to validate signatures on
BGPsec certificates, RPKI CA certificates, and RPKI CRLs.
3.4. Router Certificates and Signing Functions in the RPKI
As described in Section 1, the primary function of BGPsec Router
Certificates in the RPKI is for use in the context of certification
of AS paths in the BGPsec protocol.
The private key associated with a router EE certificate may be used
multiple times in generating signatures in multiple instances of the
BGPsec_PATH attribute Signature Segments [RFC8205]. That is, the
BGPsec Router Certificate is used to validate multiple signatures.
BGPsec Router Certificates are stored in the issuing CA's repository,
where a repository following [RFC6481] MUST use a .cer filename
extension for the certificate file.
4. Design Notes
The BGPsec Router Certificate profile is based on the Resource
Certificate profile as specified in [RFC6487]. As a result, many of
the design choices herein are a reflection of the design choices that
were taken in that prior work. The reader is referred to [RFC6484]
for a fuller discussion of those choices.
CAs are required by the Certificate Policy (CP) [RFC6484] to issue
properly formed BGPsec Router Certificates regardless of what is
present in the certificate request, so there is some flexibility
permitted in the certificate requests:
o BGPsec Router Certificates are always EE certificates; therefore,
requests to issue a CA certificate result in EE certificates;
o BGPsec Router Certificates are always EE certificates; therefore,
requests for Key Usage extension values keyCertSign and cRLSign
result in certificates with neither of these values;
o BGPsec Router Certificates always include the BGPsec Router EKU
value; therefore, requests without the value result in
certificates with the value; and,
o BGPsec Router Certificates never include the SIA extension;
therefore, requests with this extension result in certificates
without the extension.
Note that this behavior is similar to the CA including the
AS Resources extension in issued BGPsec Router Certificates, despite
the fact that it is not present in the request.
5. Implementation Considerations
This document permits the operator to include a list of ASNs in a
BGPsec Router Certificate. In that case, the router certificate
would become invalid if any one of the ASNs is removed from any
superior CA certificate along the path to a trust anchor. Operators
could choose to avoid this possibility by issuing a separate BGPsec
Router Certificate for each distinct ASN, so that the router
certificates for ASNs that are retained in the superior CA
certificate would remain valid.
6. Security Considerations
The security considerations of [RFC6487] apply.
A BGPsec Router Certificate will fail RPKI validation as defined in
[RFC6487] because the cryptographic algorithms used are different.
Consequently, an RP needs to identify the EKU to determine the
appropriate Validation constraint.
A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to
encompass routers. It is a building block of BGPsec and is used to
validate signatures on BGPsec Signature Segment origination of
signed path segments [RFC8205]. Thus, its essential security
function is the secure binding of one or more ASNs to a public key,
consistent with the RPKI allocation/assignment hierarchy.
Hash functions [RFC8208] are used when generating the two key
identifier extensions (i.e., Subject Key Identifier and Issuer Key
Identifier) included in BGPsec certificates. However, as noted in
[RFC6818], collision resistance is not a required property of one-way
hash functions when used to generate key identifiers. Regardless,
hash collisions are unlikely, but they are possible, and if detected
an operator should be alerted. A Subject Key Identifier collision
might cause the incorrect certificate to be selected from the cache,
resulting in a failed signature validation.
7. IANA Considerations
This document makes use of two OIDs in the SMI registry for PKIX.
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-mod-bgpsec-eku). The other is for the BGPsec Router EKU defined
in Section 3.1.3.2 and Appendix A, and it comes from the "SMI
Security for PKIX Extended Key Purpose" IANA registry
(id-kp-bgpsec-router). These OIDs were assigned before management of
the PKIX Arc was handed to IANA. The references in those registries
have been updated to point to this document.
8. References
8.1. Normative 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>.
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<https://www.rfc-editor.org/info/rfc6486>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205,
September 2017,
<https://www.rfc-editor.org/info/rfc8205>.
[RFC8208] Turner, S. and O. Borchert, "BGP Algorithms, Key Formats,
and Signature Formats", RFC 8208, DOI 10.17487/RFC8208,
September 2017,
<https://www.rfc-editor.org/info/rfc8208>.
[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>.
[X690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
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>.
8.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC5123] White, R. and B. Akyol, "Considerations in Validating the
Path in BGP", RFC 5123, DOI 10.17487/RFC5123,
February 2008, <https://www.rfc-editor.org/info/rfc5123>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492,
February 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource Public Key Infrastructure
(RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484,
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
BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- OID Arc --
id-kp OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
-- BGPsec Router Extended Key Usage --
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
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
Mark Reynolds
Island Peak Software
328 Virginia Road
Concord, MA 01742
United States of America
Email: mcr@islandpeaksoftware.com
Sean Turner
sn3rd
Email: sean@sn3rd.com
Stephen Kent
Raytheon BBN Technologies
10 Moulton St.
Cambridge, MA 02138
United States of America
Email: kent@alum.mit.edu
ISO Plain Language
On this page
§1What a BGPsec Router Certificate Is For
The RFC defines a profile for X.509 end-entity certificates used in the context of certifying Autonomous System paths in the BGPsec protocol. These are called BGPsec Router Certificates. The holder of the private key associated with such a certificate is authorized to send secure route advertisements, BGPsec UPDATEs, on behalf of the autonomous systems named in the certificate.
A router holding the private key is authorized to send route advertisements to its peers identifying the router's AS number as the source. The key property BGPsec provides is that every autonomous system along the AS path can verify that the other autonomous systems along the path have authorised the advertisement of the given route to the next one along the path.
The document is a profile of RFC 6487, which is itself a profile of RFC 5280, so it updates RFC 6487. It establishes requirements imposed on a Resource Certificate used as a BGPsec Router Certificate, meaning it defines constraints on certificate fields and extensions for the certificate to be valid in this context. It also profiles the certification requests used to acquire such certificates, and specifies the relying party certificate path validation procedures for them.
BGPsec signs a route so that each network in the path can check that its neighbour really did agree to pass the traffic on. For that, each router needs a certificate saying which networks it is allowed to speak for. This RFC says what that certificate must look like.
§2Where the Certificate Comes From
IANA issues a certification authority certificate to each Regional Internet Registry. The RIR in turn issues a CA certificate to an Internet Service Provider. The ISP in turn issues end-entity certificates to itself, to enable verification of signatures on RPKI signed objects, and the CA also generates certificate revocation lists. These CA and end-entity certificates are called Resource Certificates and are profiled in RFC 6487. RFC 6480 originally envisioned using Resource Certificates for manifests and Route Origin Authorizations.
This document defines another type of Resource Certificate. The issuance of BGPsec Router Certificates has minimal impact on RPKI certification authorities, because the RPKI CA certificate and CRL profile remain unchanged, and the algorithms used to generate RPKI CA certificates and the CRLs needed to check the validity of the certificates remain as specified in RFC 7935. The only impact is that RPKI CAs need to be able to process a profiled certificate request signed with the algorithms found in RFC 8208.
BGPsec Router Certificates are used only to verify the signature on a BGPsec certificate request, which only CAs process, and the signature on a BGPsec UPDATE message, which only BGPsec routers process. They are not used to process manifests and ROAs, or to verify signatures on certificates or CRLs.
The certificate comes from the same chain that issues the rest of the RPKI certificates: IANA at the top, then a regional registry, then the network operator. Nothing else in the RPKI changes, apart from the authorities having to handle a slightly different request format.
- IANA Issues a CA certificate to each RIR
- RIR Issues a CA certificate to an ISP
- ISP Issues end-entity certificates and CRLs
- BGPsec Router Certificate Issued to a router for BGPsec UPDATE signatures
- ISP Issues end-entity certificates and CRLs
- RIR Issues a CA certificate to an ISP
§3.1The Certificate Fields
A BGPsec Router Certificate is consistent with the RFC 6487 profile as modified by this document, so it is a valid X.509 public key certificate. This section lists only the differences from RFC 6487.
The subject is recommended to carry the literal string 'ROUTER-' followed by the 32-bit ASN, encoded as eight hexadecimal digits, with the serial number attribute holding the 32-bit BGP Identifier, the router ID, also as eight hexadecimal digits. When a certificate is issued to more than one router, so that the private key is shared, the choice of router ID is at the discretion of the issuer. The subjectPublicKeyInfo field is as specified in RFC 8208.
The Basic Constraints extension must not be present, because BGPsec speakers are end entities.
The Extended Key Usage extension must be included and must not be marked critical. This document defines one key purpose, id-kp-bgpsec-router, whose object identifier is { id-kp 30 }. A BGPsec router must require the extension to be present in a certificate it receives, and must reject a certificate that does not contain the BGPsec Router EKU even if it carries the anyExtendedKeyUsage object identifier. When several key purpose values are included, the router need not recognise all of them as long as the required one is present.
The Subject Information Access and IP Resources extensions are not used and must be omitted. The AS Resources extension must be included, must contain one or more ASNs, and the 'inherit' element must not be specified.
The certificate names the router and the networks it speaks for. It carries one new marker, the BGPsec Router key usage, which a router insists on seeing before it will trust the certificate. It must not claim to be a certificate authority, and it must not carry the extensions that point at other resources.
| Extension | Rule | Reason |
|---|---|---|
| Basic Constraints | Must be absent | BGPsec speakers are end entities |
| Extended Key Usage | Must be present | Must carry id-kp-bgpsec-router |
| Subject Information Access | Must be omitted | Not used in these certificates |
| IP Resources | Must be omitted | Not used in these certificates |
| AS Resources | Must be present | One or more ASNs, and no inherit element |
§3.2Requesting and Validating the Certificate
The certificate request profile is the one in Section 6 of RFC 6487 with four differences. If the Basic Constraints extension is included, the CA must not honour the cA boolean if it is set to TRUE. If the Extended Key Usage extension is included, id-kp-bgpsec-router must be present and the CA must honour the request for it. If the Subject Information Access extension is included, the CA must not honour the request to include it. The SubjectPublicKeyInfo field and the algorithms used to sign the request are those of RFC 8208.
Validation follows the procedure in Section 7 of RFC 6487 as modified by five rules: the certificate must include the BGPsec Router EKU, must not include the Subject Information Access extension, must not include the IP Resources extension, must include the AS Resources extension, and must include the subjectPublicKeyInfo field described in RFC 8208. A relying party needs to support the algorithms of RFC 8208, used to validate BGPsec signatures, as well as those of RFC 7935, needed to validate signatures on BGPsec certificates, RPKI CA certificates and RPKI CRLs.
The design notes explain the resulting behaviour. Because certification authorities are required by the certificate policy to issue properly formed BGPsec Router Certificates regardless of what the request contains, a request to issue a CA certificate still results in an end-entity certificate; a request for the key usage values keyCertSign and cRLSign results in a certificate with neither of them; a request without the BGPsec Router EKU still results in a certificate that has it; and a request with the Subject Information Access extension results in a certificate without it. The same applies to the AS Resources extension, which is always present even though it is not in the request.
The request a router sends is only a suggestion. The authority issues the certificate it says is correct, adding the key usage and the list of networks if they are missing and removing the parts that do not belong. A router then checks the certificate against the same list of rules before using it.
- A request for a CA certificateResults in an end-entity certificate, because these certificates are always end-entity certificates.
- A request for keyCertSign or cRLSignResults in a certificate with neither value.
- A request without the BGPsec Router EKUResults in a certificate that still carries the BGPsec Router EKU value.
- A request with Subject Information AccessResults in a certificate without that extension.
§5Implementation Considerations
The document permits an operator to include a list of ASNs in a BGPsec Router Certificate. In that case the certificate would become invalid if any one of the ASNs were removed from any superior CA certificate along the path to a trust anchor. Operators could avoid this possibility by issuing a separate BGPsec Router Certificate for each distinct ASN, so that the certificates for the ASNs that are retained in the superior CA certificate would remain valid.
Certificates are stored in the issuing CA's repository, where a repository following RFC 6481 must use the .cer filename extension for the certificate file. The private key associated with a router end-entity certificate may be used multiple times, to generate signatures in multiple instances of the BGPsec PATH attribute Signature Segments, so one certificate validates multiple signatures.
One practical choice is whether to list one network in a certificate or several. Listing several is more convenient, but if a higher authority later withdraws one of them, every certificate that listed it becomes invalid. Issuing one certificate per network avoids that coupling.
§6Security Considerations
The security considerations of RFC 6487 apply.
A BGPsec Router Certificate will fail RPKI validation as defined in RFC 6487, because the cryptographic algorithms used are different. A relying party therefore needs to identify the EKU to determine the appropriate validation constraint.
The certificate is an extension of the RPKI to encompass routers, a building block of BGPsec used to validate signatures on BGPsec signature segment origination of signed path segments. Its essential security function is the secure binding of one or more ASNs to a public key, consistent with the RPKI allocation and assignment hierarchy.
Hash functions from RFC 8208 are used to generate the two key identifier extensions, the Subject Key Identifier and the Issuer Key Identifier. Collision resistance is not a required property of one-way hash functions when used to generate key identifiers, but hash collisions are unlikely and possible. If one is detected an operator should be alerted: a Subject Key Identifier collision might cause the incorrect certificate to be selected from the cache, resulting in a failed signature validation.
The certificate exists to bind a public key to a set of network numbers in a way that matches who was allowed to allocate those numbers in the first place. Because it uses different algorithms from ordinary RPKI certificates, a relying party has to look at the key usage to know which validation rules to apply.
§7IANA Considerations
The RFC makes use of two object identifiers in the SMI registry for PKIX. One is for the ASN.1 module in Appendix A and comes from the SMI Security for PKIX Module Identifier registry, with the name id-mod-bgpsec-eku. The other is for the BGPsec Router EKU defined in Section 3.1.3.2 and Appendix A and comes from the SMI Security for PKIX Extended Key Purpose registry, with the name id-kp-bgpsec-router. These object identifiers were assigned before management of the PKIX arc was handed to IANA, and the references in those registries have been updated to point to this document.
Two names are registered: one for the module that defines the key usage, and one for the key usage itself, whose value is 30 under the standard list of key purposes.