One document matched: draft-weis-sobgp-certificates-00.txt
Internet Engineering Task Force Brian Weis, Editor
INTERNET-DRAFT Cisco Systems
draft-weis-sobgp-certificates-00.txt
Expires: December, 2003 June, 2003
Secure Origin BGP (soBGP) Certificates
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the format of digital certificates that are
used by the Secure Origin BGP (soBGP) extensions to BGP, as well as
acceptable use of those certificates. Included are certificates
providing authentication, authorization, and policy distribution.
Weis Expires December, 2003 1
Secure Origin BGP (soBGP) Certificates June, 2003
Table of Contents
1.0 Introduction......................................................4
1.1 Key Words.......................................................4
2.0 Overview..........................................................4
2.1 Entitycert Overview.............................................5
2.2 Authcert Overview...............................................5
2.3 Policy Certificates Overview....................................6
2.4 Digital Signature Algorithms....................................6
3.0 Entity Certificate (Entitycert)...................................6
3.1 Format..........................................................7
3.1.1 Using the Autonomous System as an Identifier................7
3.2 Creation........................................................8
3.2.1 Certificate Uniqueness......................................8
3.2.2 Certificate Encoding........................................8
3.2.3 Multiplicity of Entitycerts.................................8
3.3 Distribution....................................................9
3.4 Validation......................................................9
3.4.1 Web of Trust................................................9
3.4.2 Self-signed Entitycerts....................................10
3.5 Revocation and Expiration......................................10
4.0 Authorization Certificates (Authcert)............................11
4.1 Format.........................................................11
4.1.1 Authcert Header............................................11
4.1.2 The Authorizing AS.........................................11
4.1.3 Authorized Originator......................................12
4.1.4 The Serial Number TLV......................................12
4.1.5 Authorizing AS Entitycert Uniform Resource Locator.........13
4.1.6 Authorizing AS Validation List Uniform Resource Locator....13
4.1.7 The Address Block TLV......................................14
4.1.8 Signature..................................................14
4.2 Creation.......................................................15
4.2.1 Certificate Uniqueness.....................................15
4.2.2 Certificate Encoding.......................................16
4.3 Distribution...................................................16
4.4 Validation.....................................................16
4.4.1 Self-generated Authcerts...................................17
4.5 Revocation.....................................................17
5.0 Prefix Policy Certificates (PrefixPolicycert)....................17
5.1 Format.........................................................18
5.1.1 PrefixPolicycert Header....................................18
5.1.2 The Originating Autonomous System..........................18
5.1.3 The Serial Number..........................................18
5.1.4 Authorizing AS Entitycert Uniform Resource Locator.........19
5.1.5 Authcert...................................................19
5.1.6 Policies...................................................20
5.1.7 Signature..................................................21
Weis Expires December, 2003 2
Secure Origin BGP (soBGP) Certificates June, 2003
5.2 Creation.......................................................22
5.2.1 Certificate Uniqueness.....................................22
5.2.2 Certificate Encoding.......................................22
5.3 Distribution...................................................23
5.4 Validation.....................................................23
5.5 Revocation.....................................................24
6.0 AS Policy Certificates (ASPolicycert)............................24
6.1 Format.........................................................24
6.1.1 ASPolicycert Header........................................24
6.1.2 The Originating Autonomous System..........................25
6.1.3 The Serial Number..........................................25
6.1.4 Authorizing AS Entitycert Uniform Resource Locator.........26
6.1.5 Attached Transit Autonomous Systems........................26
6.1.6 Attached Non-transit Autonomous Systems....................27
6.1.7 Revoked Entity Certificate List............................27
6.1.8 Authorization Certificate Validity List....................28
6.1.9 Prefix Policy Certificate Validity List....................29
6.1.10 Most Recent AS Policy Certificate Uniform Resource Locator29
6.1.11 Signature.................................................30
6.2 Creation.......................................................31
6.2.1 Certificate Uniqueness.....................................31
6.2.2 Certificate Encoding.......................................31
6.3 Distribution...................................................31
6.4 Validation.....................................................31
6.5 Revocation.....................................................32
7.0 Security Considerations..........................................32
7.1 Entitycerts....................................................32
7.2 Authcerts......................................................33
7.3 PrefixPolicycerts..............................................33
7.4 ASPolicycerts..................................................34
7.5 Entitycert Uniform Resource Locators...........................34
8.0 IANA Considerations..............................................34
8.1 Authorization Certificate......................................34
8.1.1 Signature Type.............................................34
8.2 Prefix Policy Certificate......................................35
8.2.1 Policies Type..............................................35
8.2.2 Signature Type.............................................36
8.3 AS Policy Certificate..........................................36
8.3.1 Validity Ranges............................................36
8.3.2 Signature Type.............................................36
9.0 Acknowledgments..................................................37
10.0 References......................................................37
10.1 Normative References..........................................37
10.2 Informative References........................................37
Editor's Address.....................................................38
Weis Expires December, 2003 3
Secure Origin BGP (soBGP) Certificates June, 2003
1.0 Introduction
There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. Extensions to BGP supporting distribution of
digitally signed authentication, authorization, and policy objects
have been defined in [SOBGP-BGP]. This document defines the format of
those objects, as well as how they are to be used.
1.1 Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2.0 Overview
Participants within the routing system are called entities, and they
are identified through the use of Entity Certificates (Entitycerts).
Each entity must have an Autonomous System (AS) number, issued from
some centralized authority, such as a Regional Internet Routing
(RIR) authority, to participate in soBGP, either to act as a trusted
signer, an authorizer of address blocks, or a route originator.
The authorization to advertise prefixes or routes within a block of
address (within a given address space) is validated through
Authorization Certificates (Authcerts). These certificates are
issued by the entity that authorized any other entity to advertise
reachability to a given set of addresses.
Policies about routes, and the information required to build a list
of known valid paths in the routing system, are provided through
Prefix Policy Certificates (PrefixPolicycerts). Policies specific to
Autonomous System are provided through AS Policy Certificates
(ASPolicycerts).
The following figure illustrates the relationship between these
certificates. In the figure, an Entitycert at the head of an arrow
is used to validate the certificate at the end of the arrow. Note
that certificates are issued in the reverse direction of the arrows.
That is, after an Entitycert is issued, it can be used to create the
certificates that point to it.
Weis Expires December, 2003 4
Secure Origin BGP (soBGP) Certificates June, 2003
(Manually Configured Entitycerts)
^
|
validated by
|
+-----+------+
+------>| Entitycert |
/ +------------+
/ ^
/ |
+------+---+ +-----+------+ +------------------+
| Authcert | +-->| Entitycert |<------- | PrefixPolicycert |
+----------+ / +------------+ +------------------+
/ ^ ^
/ | | +------------------+
/ | +---------- | ASPolicycert |
/ | +------------------+
/ |
+-------+--+ +-----+------+ +------------------+
| Authcert | | Entitycert |<------- | PrefixPolicycert |
+----------+ +------------+ +------------------+
^
| +------------------+
+---------- | ASPolicycert |
+------------------+
Figure 1. Certificate validation paths
Each of the soBGP certificates is discussed below, and also in more
detail in subsequent sections of this document.
2.1 Entitycert Overview
Entitycerts provide authentication, providing a binding of an
identity (i.e., autonomous system number) to a public key. The
authenticity of the binding is verified with a digital signature,
where the public key of the certificate issuer has been previously
accepted by an receiver as valid. Issuer public keys can either be
manually configured, or are verified through the use of another
issuer's trusted public key in a "web of trust" built by the
receiver.
When Entitycerts form a web of trust, well-known trusted members of
the routing system sign the Entitycerts of other members of the
routing system.
2.2 Authcert Overview
Entitycerts validate the contents of Authcerts. Authcerts authorize
an entity to advertise particular address spaces. They are generated
in a hierarchical manner following the order of address space
allocation (i.e., from RIR, to ISP, to ISP customer), and are
distributed along with the address space allocation. Receivers use
Weis Expires December, 2003 5
Secure Origin BGP (soBGP) Certificates June, 2003
the Authcert to validate announcements received in BGP UPDATE
messages.
The authenticity of Authcerts is verified with a digital signature
from the issuing autonomous system. Authcerts do not contain public
keys. Rather, they bind an address space to a particular identity
(i.e., autonomous system), which are then distributed by route
originators within PrefixPolicycerts.
2.3 Policy Certificates Overview
Entitycerts also validate the contents of PrefixPolicycerts, which
carry policy information sourced from route originators, and
ASPolicycerts, which carryautonomous system topology information .
These certificates are generated and distributed from route
originators.
PrefixPolicycerts and ASPolicycerts are verified with a digital
signature from the autonomous system generating the policy. These
policy certificates do not contain public keys. Rather, they bind a
particular policy to a particular identity (i.e., autonomous
system).
2.4 Digital Signature Algorithms
The RSA Public Key Algorithm [RSA] is a widely deployed public key
algorithm commonly used for digital signatures. Compared to other
public key algorithms, signature verification is relatively quick.
This property is useful considering the large number of signature
verifications that will be done on soBGP certificates. The RSA
Algorithm is commonly supported in hardware, and is no longer
encumbered by intellectual property claims. All soBGP implementations
MUST support a digital signature of a SHA1 digest encrypted with the
RSA algorithm.
3.0 Entity Certificate (Entitycert)
Entitycerts are used to verify, through a trust model, the existence
of an entity within the routing system, and the value of that
entity's public key for use in the routing system. Each entity
within the routing system MUST generate a public/private key pair.
The public key portion of this pair is then signed, verifying that
anyone using this public key is actually the entity in question.
This signature may be provided by various other trusted parties
within the routing system, including (but not limited to):
” The authority that issued the autonomous system number.
” An external commercial authority that provides authentication
certificates for other commercial transactions.
Weis Expires December, 2003 6
Secure Origin BGP (soBGP) Certificates June, 2003
” Any other trusted party within the domain of Internet routing,
such as a well known Service Provider.
” Self-signed if the entity is well known within the routing system.
This public key is used to verify the validity of other messages
transmitted by this entity within the routing system.
The public key, along with other verifying information, is formatted
into an Entitycert, as described in the next section.
3.1 Format
An Entitycert MUST be formatted as an X.509 authentication
certificate, as defined in [RFC3280]. The Entitycert MUST be
generated with a signature of type sha1withRSAEncryption [RFC3279].
The primary identity in soBGP is the autonomous system number. An
extension to RFC 3280 allowing this identity is proposed in Section
3.1.1. Each entity that signs Entitycerts MUST be assigned an AS
number, even if they do not originate routes into the internetwork.
In order for an X.509 certificate to be used as an Entitycert, the
following fields MUST be present and defined as Critical. Other
fields are also necessary for the purposes of creating an X.509
certificate. The following fields are mentioned either because there
are special requirements, or for clarification of later text.
” SubjectAltName. The autonomous system number of the entity owning
the public key MUST be included in the SubjectAltName.
” IssuerAltName. The autonomous system number of the issuer MUST be
included in the IssuerAltName.
” CertificateSerialNumber. This is a unique identifier for a
particular issuer.
” SubjectPublickeyInfo. This is the actual public key of the
subject, as vouched for by the issuer.
” SignatureValue. This is the signature of the authenticating
autonomous system.
3.1.1 Using the Autonomous System as an Identifier
The autonomous system of an entity MUST be defined in the
GeneralName namespace as defined in RFC 3280, section 4.2.1.7. This
document adds the "autonomousSystemID" identifier to the
GeneralNames list. The GeneralNames list is used by a number of
fields defined in RFC 3280, including SubjectAltName and
issuerAltName.
Weis Expires December, 2003 7
Secure Origin BGP (soBGP) Certificates June, 2003
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
.
.
.
autonomousSystemID [9] INTEGER}
3.2 Creation
An Entitycert is usually created with the following steps:
” The receiving autonomous system generates a signature key pair
” The receiving autonomous system forwards its identity (including
its AS number) and the public key to an issuing autonomous system
using a trusted certificate registration mechanism that is
outside the scope of this document.
” The issuing autonomous system verifies that the identity of the
receiving autonomous system, generates an Entitycert including
that identity, and signs it with its own private key.
” The issuing autonomous system returns the Entitycert to the
receiving autonomous system.
3.2.1 Certificate Uniqueness
Digital certificates are created as uniquely named objects, which
allows them to be uniquely identified. The pair of
CertificateSerialNumber and IssuerAltName values uniquely identifies
entity Certificates.
3.2.2 Certificate Encoding
Entitycerts distributed in [SOBGP-BGP] use their native DER [X.690]
form. If Entitycerts are manually distributed (e.g., through
electronic mail) they may need to be base64 encoded into ASCII.
Authcerts SHOULD be encoded as PEM objects (described in [RFC1421]).
There are times that Entitycerts are referred to by name (e.g., the
target of a URL). In this case, the extension on the name MUST
define the format of the Entitycert. A suffix of ".der" defines DER
encoding. A suffix of ".pem" defines base64 encoding.
3.2.3 Multiplicity of Entitycerts
An autonomous system MAY acquire more than one Entitycert. Acquiring
certificates from different well-known entities within the routing
system may increase the probability of other autonomous systems
accepting their public key. Or, it may simply result in other
autonomous systems accepting their public key faster, which
increases BGP convergence times.
Weis Expires December, 2003 8
Secure Origin BGP (soBGP) Certificates June, 2003
If an entity detects that an autonomous system has valid Entitycerts
from different issuers, the entity SHOULD treat the various
Entitycerts as independent. Revocation from one issuer does not
necessarily imply that Entitycerts from other issuers are invalid.
An issuer may revoke a certificate for reasons other than key
comprimise.
However, even if an issuer states key compromise as the reason for
revocation, a receiving entity SHOULD treat this state as specific
to the issuer. Note that if the state of one issuer were instead
considered transitive, the erroneous revocation of a single issuer
would result in a Denial of Service attack on the victim autonomous
system.
In the face of inconsistent state from different issuers, a receiver
MAY choose to trust one issuer over another. For example, a receiver
may choose to prefer the result of an issuer they directly trust
over an issuer that was verified further away in the "web of trust".
.
3.3 Distribution
Entitycerts may be distributed using any number of methods, for
example:
” maintained in a directory maintained by the issuing autonomous
system,
” distributed via some out of band mechanism, or
” distributed within BGP using extensions defined in [SOBGP-BGP].
To ensure interoperability, the receiving autonomous system SHOULD
distribute its Entitycert within BGP.
3.4 Validation
Any device receiving an Entitycert can verify it by validating the
signature on the certificate, along with the verifying information.
If a Certificate Revocation List (CRL) is available for that issuer,
it MUST be consulted to verify that this certificate has not been
revoked. Once validation is complete, the public key contained in
this certificate may be used to verify messages purportedly sent by
this entity.
3.4.1 Web of Trust
An soBGP entity uses the "web of trust" paradigm for purposes of
Entitycert validation, where the entity learns the validity of
public keys over time. An entity usually follows the following
procedure.
Weis Expires December, 2003 9
Secure Origin BGP (soBGP) Certificates June, 2003
” A small number of Entitycerts are manually configured and copied
to a device's local configuration. These are implicitly trusted as
being previously verified and authenticated.
” When the entity receives a new Entitycert, it checks to see if it
has the public key of the issuing autonomous system in its
configuration. If so, it attempts to validate the Entitycert,
using the previously known public key, and any revocation material
that is available from the issuer.
” If the new Entitycert proves valid, it is added to the device's
local configuration and may be used to validate subsequently
received Entitycerts.
An autonomous system may define local policy that restricts the
scope of the web of trust. For example, they may choose to only
accept only a certain "depth" of signatures, trusting second party
signatures, but not third party signatures. However it should be
noted that any local policy restricting the web of trust reduces the
value of soBGP authorization and path validation.
3.4.2 Self-signed Entitycerts
Entitycerts MAY be self-signed, but MUST only be accepted from
autonomous systems when an alternative method exists of validating
that the self-signed certificate is genuine. For example,
distribution out-of-band using a trusted delivery procedure would be
acceptable.
Typical users of a self-signed Entitycert would be:
” A commercial authority in the business of provides authentication
certificates for many types of commercial transactions
” An Entitycert issuer that is at the top of a hierarchy of issuers
” A well-known trusted party within the domain of Internet routing
3.5 Revocation and Expiration
Any entity issuing an Entitycert may have need to revoke it. The
entity MAY use any form for propagating that revocation list, but
SHOULD also send it as part of an AS Policy Certificate (distributed
using [SOBGP-BGP]). This allows autonomous systems that cannot route
to the issuing autonomous system to verify that the Entitycert has
not been revoked.
X.509 certificates contain expiration dates. Any device validating
Entitycerts MUST have a time of day clock that is close to real time
in order to properly deal with expired certificates. It is
RECOMMENDED that Entitycerts do not expire before the expected life
of their RSA key pair (e.g., current recommendations on the life of
a key pair generated with a particularly sized modulus).
If an Entitycert is discarded due to either expiration or
revocation, the Authcert and Policy databases shall be examined, and
Weis Expires December, 2003 10
Secure Origin BGP (soBGP) Certificates June, 2003
any Authcerts and Policy certificates that were validated using the
discarded certificate should be removed from the database.
4.0 Authorization Certificates (Authcert)
The authorization certificate binds one or more prefix blocks to a
particular autonomous system. It is typically provided by an entity
issuing a prefix block to an autonomous system, and is digitally
signed by the issuing autonomous system. The Authcert can be thought
of as an "Attribute Certificate" in the spirit of RFC 3281, although
it does not follow the syntax of that document.
4.1 Format
The Authcert is defined as a header block followed by a set of
Type/Length/Value attributes, as identified in the following
sections. Each Authcert TLV includes a type, which is treated as a
16 bit (two octet) unsigned integer. The TLVs described must be
placed within the Authcert in type order; every Authcert should
begin with a TLV type 1 (Autonomous System and Options). All TLVs
are REQUIRED to be in an Authcert unless otherwise noted.
4.1.1 Authcert Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Cert. Marker | Type Id | Length |
+---------------+---------------+-------------------------------+
| TLVs
+----------------
o Certificate Marker: "162(0xa2), identifying this as an soBGP
certificate.
o Type ID: "1(0x01), identifying this as an Authcert.
o Length: Set to the length of the TLVs.
o TLVs: The Type/Length/Value attributes making up an Authcert.
4.1.2 The Authorizing AS
Weis Expires December, 2003 11
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Autonomous System |
+---------------------------------------------------------------+
o TLV type: 1 (0x0001)
o Length: Set to 4.
o AS: (4 octets), the autonomous system authorizing other
entities to advertise prefixes within this block. AS numbers
containing only two octets should be placed in the least
significant octets of this four-octet field (the two rightmost
octets).
Each authorizing entity MUST have an autonomous system number, used
as a unique identifier, even though they may not advertise prefixes
into the routing system.
4.1.3 Authorized Originator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Autonomous System |
+---------------------------------------------------------------+
o TLV type: 2 (0x0002)
o Length: Set to 4.
o AS: (4 octets), the autonomous system of an entity authorized
to advertise prefixes within this block. AS numbers containing
only two octets should be placed in the least significant
octets of this four-octet field (the two rightmost octets).
Multiple authorized originator TLVs may be included in the Authcert.
4.1.4 The Serial Number TLV
Weis Expires December, 2003 12
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Serial Number |
+---------------------------------------------------------------+
o TLV type: 3 (0x0003)
o Length: Set to 4.
o Serial Number: (4 octets), unsigned integer taken from a number
space maintained by the Authorizing AS indicating the serial
number of this Authorization certificate. The Authorizing AS
MUST manage the number space as a monotonically increasing
value so that a relative ordering of Authcerts is maintained.
4.1.5 Authorizing AS Entitycert Uniform Resource Locator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| URL |
+----------------
o TLV type: 4 (0x0004)
o Length: Denotes the length of the URL in octets.
o URL: A uniform resource locator indicating a location where the
Authorizing ASĘs Entitycert can be found.
An Authcert may omit this TLV. However, an implementation is
REQUIRED to correctly parse them if they are present. A receiving
device MAY choose to ignore the URL TLV.
4.1.6 Authorizing AS Validation List Uniform Resource Locator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| URL |
+----------------
o TLV type: 5 (0x0005)
o Length: Denotes the length of the URL in octets.
Weis Expires December, 2003 13
Secure Origin BGP (soBGP) Certificates June, 2003
o URL: A uniform resource locator indicating a location where the
Authorizing ASĘs Validation List can be found.
An Authcert may omit this TLV. However, an implementation is
REQUIRED to correctly parse them if they are present. A receiving
device MAY choose to ignore the URL TLV.
4.1.7 The Address Block TLV
The address block TLV shall define blocks of address within which
the authorized AS' are allowed to advertise prefixes (or routes).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| NLRI Data |
+----------------
o TLV Type: 14 (0x000D)
o Length (2 octets), set to the length of the NLRI Data.
o NLRI Data: An address block as described in [RFC2858].
4.1.8 Signature
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Signature Type | Number of Issuers |
+-------------------------------+-------------------------------+
| Entity Certificate Issuer Autonomous System |
+-------------------------------+-------------------------------+
| Entity Certificate Serial Number |
+-------------------------------+-------------------------------+
| ... |
+---------------------------------------------------------------+
| Signature |
+------------------
o TLV type: 65535 (0xFFFF)
o Length: (2 octets), unsigned integer denoting the length of the
payload bytes which follow.
Weis Expires December, 2003 14
Secure Origin BGP (soBGP) Certificates June, 2003
o Signature Type: (2 octets), unsigned integer denoting the type
of signature (the algorithm used to build this signature). Each
possible signing algorithm is assigned an integer from this
field. Signature type 1 is defined as an RSA encryption of a
SHA1 digest.
o Number of Issuers (2 octets): The number of Entitycert
references included in the signature payload. If more than one
Entitycert reference follows, all Entitycerts MUST contain the
same public key for the same authorizing autonomous system.
o Entity Certificate Issuer Autonomous System: (4 octets), the
autonomous system of the entity that provided the Entitycert to
the Authorizing AS. AS numbers containing only two octets
should be placed in the least significant octets of this four-
octet field (the two rightmost octets).
o Entity Certificate Serial Number: (4 octets), the Entitycert
serial number containing the public key of the Authorizing AS.
o Signature: The signature itself.
The signature is calculated using the private key of the authorizing
entity across all the TLVs within the Authcert. The Signature TLV
MUST be appended as the last TLV in the Authcert after the signature
has been computed.
4.2 Creation
An Authcert is usually created by the authorizing autonomous system
with the following steps:
” Allocate a prefix block to the receiving autonomous system.
” Build an Authcert by adding TLVs containing its own AS number, the
receiving (authorized) AS number, the prefix block, a unique
sequence number, and any other information (e.g., URL pointing to
the Entitycert that signed this Authcert.).
” Sign the Authcert by hashing and encrypting the Authcert TLVs.
Place the signature (and other required) information in a
Signature TLV, and append it to the Authcert.
4.2.1 Certificate Uniqueness
Digital certificates are created as uniquely named objects, which
allows them to be uniquely identified. An Authcert is uniquely
identified by the pair of Authorized Originator and Serial Number
TLV values.
4.2.2 Certificate Encoding
Weis Expires December, 2003 15
Secure Origin BGP (soBGP) Certificates June, 2003
Authcerts distributed in [SOBGP-BGP] are distributed in TLV form.
However if they are manually distributed (e.g., through electronic
mail) they may need to be base64 encoded into ASCII. Authcerts SHOULD
be encoded as described in Section 4.3 of [RFC1421].
There are times that Authcerts are referred to by name (e.g., the
target of a URL). In this case, the extension on the name MUST
define the format of the Authcert. A suffix of ".tlv" defines the
raw TLV encoding. A suffix of ".pem" defines base64 encoding.
4.3 Distribution
Authcerts are distributed as part of a Prefix Policy Certificate, so
that an autonomous system can reliably match distribution policy to
the prefix block.
4.4 Validation
The Authcert is validated using the following steps.
” Identify the Entitycert that signed the Authcert. The correct
Entitycert is uniquely identified with the Entity Certificate
Issuer Autonomous System and Entity Certificate Serial Number
contained in the Signature TLV. The Entity Certificate Issuer
Autonomous System is compared with the AS number in the Entitycert
IssuerAltName field. The Entity Certificate Serial Number is
compared with the Entitycert CertificateSerialNumber.
” Obtain the Entitycert that signed the Authcert, and validate it.
The Entitycert may be in a local cache (already received via BGP
extensions), retrieved using the URL in the Authcert, or through
other means. If an entity does not have the validating public key
it MUST NOT assume the Authcert is valid.
” Verify that the autonomous system identifier in SubjectAltname
matches the Authorized Originator TLV value of the Authcert.
” If an Authorization Certificate Validity List is available,
validate that the issuer of the Entitycert has not invalidated the
Authcert. Validity lists may be distributed in the signers
ASPolicycert, or a pointer to the list may be distributed in the
Authcert in an Authorizing AS Validation List URL. If no
Authorization Certificate Validity List is available, an entity
MAY accept the certificate. However if a validation list is
received later, the entity MUST check the validity of all
certificates that had been previously accepted.
” Hash the Authcert TLVs.
” Extract the signature from the Authcert.
” Extract the public key from the Entitycert, and use it to decrypt
the signature.
” Accept the Authcert as valid if the computed hash matches the
decrypted hash.
Weis Expires December, 2003 16
Secure Origin BGP (soBGP) Certificates June, 2003
4.4.1 Self-generated Authcerts
Self-generated Authcerts are dangerous, because a responsible third
party does not assign the authorization. Trusting an autonomous
system to declare its own address space nullifies most of the
protections outlined in this document.
However, the autonomous systems at the highest level of allocation
(e.g. Regional Internet Registries (RIRs) or Tier-1 Internet Service
Providers (ISPs)) may not be able to find a responsible third party
to sign their Authcerts. In this case, self-generated Authcerts may
be unavoidable.
Authcerts MAY be self-generated, but MUST only be accepted from
autonomous systems that have been explicitly authorized and locally
configured. For example, a device may be configured to accept
Authcerts for the RIR autonomous systems.
4.5 Revocation
Any entity issuing an Authcert MUST keep an Authcert revocation
list. The entity MAY use any form for propagating that revocation
list.
Because BGP routers do not necessarily have synchronized clocks,
Authcerts do not carry expiration times, and thus do not expire.
Revocation is only method of invalidating an Authcert.
Revocation information may be represented as a "validation list". A
validation list includes lists of both valid and invalid (i.e.,
revoked) certificates. Any number not appearing in the list MUST be
considered invalid. Validation list may be more efficient than a
pure revocation list for Authcerts in the case where a large number
of serial numbers have been revoked by an issuer.
An autonomous system SHOULD include an Authcert validation list in
their AS Policy Certificate (distributed using [SOBGP-BGP]). This
allows autonomous systems that cannot route to the issuing
autonomous system to verify that the Entitycert has not been
revoked.
5.0 Prefix Policy Certificates (PrefixPolicycert)
The PrefixPolicycert provides a specific set of policy regarding one
or more prefix blocks. The owner of the prefix block creates it.
There is only one valid PrefixPolicycert for each prefix block at
any given time.
5.1 Format
Weis Expires December, 2003 17
Secure Origin BGP (soBGP) Certificates June, 2003
This certificate is formatted as a series of TLVs. Each TLV will
include a type, which is treated as a 16 bit (two octet) unsigned
integer, a length, which is also two octets, and a variable length
data field. TLVs MUST be placed in the PrefixPolicycert in type
order.
5.1.1 PrefixPolicycert Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Cert. Marker | Type Id | Length |
+---------------+---------------+-------------------------------+
| TLVs
+----------------
o Certificate Marker: "162(0xa2), identifying this as an soBGP
certificate.
o Type ID: "2(0x02), identifying this as an PrefixPolicycert.
o Length: Set to the length of the TLVs.
o TLVs: The Type/Length/Value attributes making up an
PrefixPolicycert.
5.1.2 The Originating Autonomous System
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Originating Autonomous System |
+---------------------------------------------------------------+
o TLV type: 1 (0x0001)
o Length: Set to 4.
o Originating Autonomous System: (4 octets), the autonomous
system which originated this certificate. AS numbers containing
only two octets should be placed in the least significant
octets of this four-octet field (the two rightmost octets).
5.1.3 The Serial Number
Weis Expires December, 2003 18
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Serial Number |
+---------------------------------------------------------------+
o TLV type: 2 (0x0002)
o Length: Set to 4.
o Serial Number: (4 octets), A serial number which identifies
this PrefixPolicycert, taken from a 32 bit number space.
5.1.4 Authorizing AS Entitycert Uniform Resource Locator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| URL |
+----------------
o TLV type: 3 (0x0003)
o Length: Denotes the length of the URL in octets.
o URL: A uniform resource locator indicating a location where the
Authorizing ASĘs Entitycert can be found.
An PrefixPolicycert may omit this TLV. However, an implementation is
REQUIRED to correctly parse them if they are present. A receiving
device MAY choose to ignore the URL TLV.
5.1.5 Authcert
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Authentication Certificate |
+----------------
o TLV type: 4 (0x0004)
o Length: Set to the length of the Authentication Certificate.
o Authentication Certificate containing a prefix block for which
the PrefixPolicycert applies.
Weis Expires December, 2003 19
Secure Origin BGP (soBGP) Certificates June, 2003
One or more Authcert TLVs MUST be included in the PrefixPolicycert.
5.1.6 Policies
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Options | SubTVs
+-------------------------------+--------------
o TLV type: 5 (0x0005)
o Length: Set to the sum of the Options size (2) and the length
of the SubTVs.
o Options: (2 octets), a bit field describing various policies
which should be applied to the prefixes indicated.
o SubTVs: (variable length), zero or more fields, the length of
which is determined by the type, as described below.
5.1.6.1 Option bits
The options bit field describes policies that should be applied
to the address block described in the TLV. These options are:
o Bit 0: Path Check. If this bit is set, the receiver should not
accept any prefix for which the path cannot be verified as
described in the section Verifying the Path, below.
o Bit 1: Second Hop Check. If this bit is set, the receiver
should not accept any prefix for which the second entry in the
AS PATH cannot be verified as described in the section
Verifying the Second Hop, below.
o Bits 2-15: Reserved for future use.
5.1.6.2 SubTVs
The Authcert Policy subTVs provide optional policy information for
the block of addresses included in the Authcert indicated; each
subTV is of a fixed length, as determined by its type.
Weis Expires December, 2003 20
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+------------------------------+
| TV Type | Data....
+-------------------------------+-------------------------
o TV Type: (2 octets), An unsigned integer indicating the type of
subTV
Types defined within this specification are:
- Type 1: Must Include AS, 4 octets of data, an AS which must be
included in the AS path of any prefix falling within this block
of addresses.
- Type 2: OR Include AS, 4 octets of data, at least one of the
included OR Include AS' must be included in the AS path of any
prefix falling within this block of addresses.
- Type 3: Maximum Prefix Length, 1 octet of data, the maximum
length of any prefix allowed within this block of prefixes.
5.1.7 Signature
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Signature Type | Number of Issuers |
+-------------------------------+-------------------------------+
| Entity Certificate Issuer Autonomous System |
+-------------------------------+-------------------------------+
| Entity Certificate Serial Number |
+-------------------------------+-------------------------------+
| ... |
+---------------------------------------------------------------+
| Signature |
+------------------
o TLV type: 65535 (0xFFFF)
o Length: (2 octets), unsigned integer denoting the length of the
payload bytes which follow.
o Signature Type: (2 octets), unsigned integer denoting the type
of signature (the algorithm used to build this signature). Each
possible signing algorithm is assigned an integer from this
field. Signature type 1 is defined as an RSA encryption of a
SHA1 digest.
Weis Expires December, 2003 21
Secure Origin BGP (soBGP) Certificates June, 2003
o Number of Issuers (2 octets): The number of Entitycert
references included in the signature payload. If more than one
Entitycert reference follows, all Entitycerts MUST contain the
same public key for the same authorizing autonomous system.
o Entity Certificate Issuer Autonomous System: (4 octets), the
autonomous system of the entity that provided the Entitycert to
the AS issuing the PrefixPolicycert. AS numbers containing only
two octets should be placed in the least significant octets of
this four-octet field (the two rightmost octets).
o Entity Certificate Serial Number: (4 octets), the Entitycert
serial number containing the public key of the AS issuing the
PrefixPolicycert.
o Signature: The signature itself.
The signature is calculated using the private key of the authorizing
entity across all the TLVs within the PrefixPolicycert. The
Signature TLV MUST be appended as the last TLV in the
PrefixPolicycert after the signature has been computed.
5.2 Creation
An PrefixPolicycert is created by an autonomous system for prefix
blocks that it owns. An autonomous system creates it with the
following steps:
” Build an PrefixPolicycert by adding TLVs containing its own AS
number, a unique sequence number, policy related to one or more
prefix blocks, and the Authcert or Authcerts defining the prefix
blocks to which this policy applies.
” Sign the PrefixPolicycert by hashing and encrypting the
PrefixPolicycert TLVs. Place the signature (and other required)
information in a Signature TLV, and append it to the
PrefixPolicycert.
5.2.1 Certificate Uniqueness
Digital certificates are created as uniquely named objects, which
allows them to be uniquely identified. A PrefixPolicycert is
uniquely identified by the pair of Authorized Originator and Serial
Number TLV values.
5.2.2 Certificate Encoding
PrefixPolicycert distributed in [SOBGP-BGP] are distributed in TLV
form. However if they are manually distributed (e.g., through
electronic mail) they may need to be encoded into ASCII.
PrefixPolicycert SHOULD be base64 encoded as described in Section
4.3 of [RFC1421].
Weis Expires December, 2003 22
Secure Origin BGP (soBGP) Certificates June, 2003
There are times that PrefixPolicycert are referred to by name (e.g.,
the target of a URL). In this case, the extension on the name MUST
define the format of the PrefixPolicycert . A suffix of ".tlv"
defines the raw TLV encoding. A suffix of ".pem" defines base64
encoding.
5.3 Distribution
PrefixPolicycerts may be distributed using any number of methods,
for example:
” maintained in a directory maintained by the issuing autonomous
system,
” distributed via some out of band mechanism, or
” distributed within BGP using extensions defined in [SOBGP-BGP].
To ensure interoperability, an autonomous system SHOULD distribute
its PrefixPolicycerts within BGP.
5.4 Validation
The Authcert included in the Authcert TLV MUST be validated as
correct before the Policy TLV can be accepted. Thus, the Authcert
should be extracted from the PrefixPolicycert and validated before
the PrefixPolicycert is validated.
The PrefixPolicycert is validated using the following steps.
” Identify the Entitycert that signed the PrefixPolicycert. The
correct Entitycert is uniquely identified with the Entity
Certificate Issuer Autonomous System and Entity Certificate Serial
Number contained in the Signature TLV. The Entity Certificate
Issuer Autonomous System is compared with the AS number in the
Entitycert IssuerAltName field. The Entity Certificate Serial
Number is compared with the Entitycert CertificateSerialNumber.
” Obtain the Entitycert that signed the Authcert, and validate it.
The Entitycert may be in a local cache (already received via BGP
extensions), retrieved using the URL in the Authcert, or through
other means. If an entity does not have the validating public key
it MUST NOT assume the PrefixPolicycert is valid.
” Verify that the autonomous system identifier in SubjectAltname
matches the Authorized Originator TLV value of the
PrefixPolicycert.
” Hash the PrefixPolicycert TLVs.
” Extract the signature from the PrefixPolicycert.
” Extract the public key from the Entitycert, and use it to decrypt
the signature.
” Validate that the computed hash matches the decrypted hash.
Once a PrefixPolicycert has been validated, any PrefixPolicycert
that matches the following criteria MUST be discarded:
” has a lower serial number from the same originating AS, and
Weis Expires December, 2003 23
Secure Origin BGP (soBGP) Certificates June, 2003
” includes an Authcert with the same prefix block
5.5 Revocation
Any entity issuing an PrefixPolicycert MUST keep a revocation list.
The entity MAY use any form for propagating that revocation list.
Because BGP routers do not necessarily have synchronized clocks,
PrefixPolicycert do not carry expiration times, and thus do not
expire. Revocation is only method of invalidating an
PrefixPolicycert.
Revocation information may be represented as a "validation list". A
validation list includes lists of both valid and invalid (i.e.,
revoked) certificates. Any number not appearing in the list MUST be
considered invalid. Validation list may be more efficient than a
pure revocation list for PrefixPolicycerts in the case where a large
number of serial numbers have been revoked by an issuer.
An autonomous system SHOULD include an PrefixPolicycert validation
list in their AS Policy Certificate (distributed using [SOBGP-BGP]).
This allows autonomous systems that cannot route to the issuing
autonomous system to verify that the Entitycert has not been
revoked.
6.0 AS Policy Certificates (ASPolicycert)
The ASPolicycert provides a specific set of policy relating to an
autonomous system. An administrative entity within the autonomous
system creates it. There is only one valid ASPolicycert for each
autonomous system at any given time.
6.1 Format
This certificate is formatted as a series of TLVs. Each TLV will
include a type, which is treated as a 16 bit (two octet) unsigned
integer, a length, which is also two octets, and a variable length
data field. TLVs MUST be placed in the ASPolicycert in type order.
6.1.1 ASPolicycert Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Cert. Marker | Type Id | Length |
+---------------+---------------+-------------------------------+
| TLVs
+----------------
o Certificate Marker: "162(0xa2), identifying this as an soBGP
certificate.
Weis Expires December, 2003 24
Secure Origin BGP (soBGP) Certificates June, 2003
o Type ID: "3(0x03), identifying this as an ASPolicycert.
o Length: Set to the length of the TLVs.
o TLVs: The Type/Length/Value attributes making up an
ASPolicycert.
6.1.2 The Originating Autonomous System
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Originating Autonomous System |
+---------------------------------------------------------------+
o TLV type: 1 (0x0001)
o Length: Set to 4.
o Originating Autonomous System: (4 octets), the autonomous
system which originated this certificate. AS numbers containing
only two octets should be placed in the least significant
octets of this four-octet field (the two rightmost octets).
6.1.3 The Serial Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Serial Number |
+---------------------------------------------------------------+
o TLV type: 2 (0x0002)
o Length: Set to 4.
o Serial Number: (4 octets), A serial number which identifies
this ASPolicycert, taken from a 32 bit number space.
6.1.4 Authorizing AS Entitycert Uniform Resource Locator
Weis Expires December, 2003 25
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| URL |
+----------------
o TLV type: 3 (0x0003)
o Length: Denotes the length of the URL in octets.
o URL: A uniform resource locator indicating a location where the
Authorizing ASĘs Entitycert can be found.
An PrefixPolicycert may omit this TLV. However, an implementation is
REQUIRED to correctly parse them if they are present. A receiving
device MAY choose to ignore the URL TLV.
6.1.5 Attached Transit Autonomous Systems
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Autonomous System |
+---------------------------------------------------------------+
o TLV type: 4 (0x0004)
o Length: Set to 4.
o Autonomous System: (4 octets), autonomous systems which are
connected to the originating autonomous system through some
form of peering arrangement and which may transit traffic from
the origin AS. AS numbers containing only two octets should be
placed in the least significant octets of this four-octet field
(the two rightmost octets).
One or more Attached Transit AS TLVs may be included in the Policy
Certificate. Each type 4 TLV indicates an AS which is connected to
the AS which originates this ASPolicycert through a BGP peering
relationship.
6.1.6 Attached Non-transit Autonomous Systems
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
Weis Expires December, 2003 26
Secure Origin BGP (soBGP) Certificates June, 2003
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Autonomous System |
+---------------------------------------------------------------+
o TLV type: 5 (0x0005)
o Length: Set to 4.
o Autonomous System: (4 octets), autonomous systems which are
connected to the originating autonomous system through some
form of peering arrangement and which may not transit traffic
from the origin AS. AS numbers containing only two octets
should be placed in the least significant octets of this four-
octet field (the two rightmost octets).
One or more Attached Non-Transit AS TLVs may be included in the
ASPolicycert. Each type 5 TLV indicates an AS which is connected to
the AS which originates this ASPolicycert through a BGP peering
relationship.
6.1.7 Revoked Entity Certificate List
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Entity Certificate Revocation List
+----------------
o TLV type: 6 (0x0006)
o Length: (2 octets), length of TLV data (the list of revoked
Entity Certificates) in octets
o Entity Certificate Revocation List: A revocation list created
by the autonomous system, which includes a list of revoked
Entity Certificates issued by this autonomous system. The
format of the revocation list MUST be as defined in [RFC3280].
A single Revoked Entity Certificate List TLV MAY be included in an
ASPolicycert, or it may be omitted.
When an Entity Certificate Revocation List is received, all
currently held Entitycerts from this issuer MUST be checked against
the validity list. Entitycerts found to be invalid MUST be deleted.
6.1.8 Authorization Certificate Validity List
Weis Expires December, 2003 27
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Validity Ranges
+----------------
o TLV type: 7 (0x0007)
o Length: (2 octets), length of TLV data (the list of revoked
Authorization Certificates) in octets
o Validity Ranges: A list of validity subTVs defining which
serial numbers are valid and invalid. Validity ranges are
interpreted in order until a match is found. For more
information on validity lists, see Section 4.5.
A single TLV of this type MAY be included in an ASPolicycert, or it
may be omitted.
When an Authorization Certificate Validity List is received, all
currently held Authcerts from this issuer MUST be checked against
the validity list. Authcerts found to be invalid MUST be deleted.
6.1.8.1 Validity Ranges
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| subTV Type | Size of Range |
+-------------------------------+-------------------------------+
| Lowest Authorization Serial Number |
+---------------------------------------------------------------+
o subTV type: (2 octets).
SubTV type Value
---------- -----
VALID 0
INVALID 1
o Size of Range: (2 octets). Number of contiguous serial numbers
defining a range.
o Lowest Authorization Serial Number (4 octets). The lowest value
in the range.
6.1.9 Prefix Policy Certificate Validity List
Weis Expires December, 2003 28
Secure Origin BGP (soBGP) Certificates June, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Validity Ranges
+----------------
o TLV type: 8 (0x0008)
o Length: (2 octets), length of TLV data (the list of revoked
Authorization Certificates) in octets
o Validity Ranges: A list of validity subTVs (as defined in the
previous section) defining which PrefixPolicycert serial
numbers are valid and invalid. Validity ranges are interpreted
in order until a match is found.. For more information on
validity lists, see Section 5.5.
A single TLV of this type MAY be included in an ASPolicycert, or it
may be omitted.
When an Prefix Policy Validity List is received, all currently held
PrefixPolicycerts from this issuer MUST be checked against the
validity list. PrefixPolicycerts found to be invalid MUST be
deleted.
6.1.10 Most Recent AS Policy Certificate Uniform Resource Locator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| URL |
+----------------
o TLV type: 9 (0x0009)
o Length: Denotes the length of the URL in octets.
o URL: A uniform resource locator indicating a location where the
most recent AS Policy Certificate can be found. This is useful
for a receiver to verify that they have the most recent AS
Policy Certificate for an AS.
An PrefixPolicycert may omit this TLV. However, an implementation is
REQUIRED to correctly parse them if they are present. A receiving
device MAY choose to ignore the URL TLV.
Weis Expires December, 2003 29
Secure Origin BGP (soBGP) Certificates June, 2003
6.1.11 Signature
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Signature Type | Number of Issuers |
+-------------------------------+-------------------------------+
| Entity Certificate Issuer Autonomous System |
+-------------------------------+-------------------------------+
| Entity Certificate Serial Number |
+-------------------------------+-------------------------------+
| ... |
+---------------------------------------------------------------+
| Signature |
+------------------
o TLV type: 65535 (0xFFFF)
o Length: (2 octets), unsigned integer denoting the length of the
payload bytes which follow.
o Signature Type: (2 octets), unsigned integer denoting the type
of signature (the algorithm used to build this signature). Each
possible signing algorithm is assigned an integer from this
field. Signature type 1 is defined as an RSA encryption of a
SHA1 digest.
o Number of Issuers (2 octets): The number of Entitycert
references included in the signature payload. If more than one
Entitycert reference follows, all Entitycerts MUST contain the
same public key for the same authorizing autonomous system.
o Entity Certificate Issuer Autonomous System: (4 octets), the
autonomous system of the entity that provided the Entitycert to
the AS issuing the PrefixPolicycert. AS numbers containing only
two octets should be placed in the least significant octets of
this four-octet field (the two rightmost octets).
o Entity Certificate Serial Number: (4 octets), the Entitycert
serial number containing the public key of the AS issuing the
PrefixPolicycert.
o Signature: The signature itself.
The signature is calculated using the private key of the authorizing
entity across all the TLVs within the ASPolicycert. The Signature
TLV MUST be appended as the last TLV in the ASPolicycert after the
signature has been computed.
Weis Expires December, 2003 30
Secure Origin BGP (soBGP) Certificates June, 2003
6.2 Creation
An ASPolicycert is created by an autonomous system in order to relay
its own policy. An autonomous system creates it with the following
steps:
” Build an ASPolicycert by adding TLVs containing its own AS number,
a unique sequence number, and policy related to the autonomous
system.
” Sign the ASPolicycert by hashing and encrypting the ASPolicycert
TLVs. Place the signature (and other required) information in a
Signature TLV, and append it to the ASPolicycert.
6.2.1 Certificate Uniqueness
Digital certificates are created as uniquely named objects, which
allows them to be uniquely identified. An ASPolicycert is uniquely
identified by the pair of Authorized Originator and Serial Number
TLV values.
6.2.2 Certificate Encoding
ASPolicycert distributed in [SOBGP-BGP] are distributed in TLV form.
However if they are manually distributed (e.g., through electronic
mail) they may need to be encoded into ASCII. ASPolicycert SHOULD be
base64 encoded following Section 4.3 of [RFC1421].
There are times that ASPolicycerts are referred to by name (e.g.,
the target of a URL). In this case, the extension on the name MUST
define the format of the ASPolicycert. A suffix of ".tlv" defines
the raw TLV encoding. A suffix of ".pem" defines base64 encoding.
6.3 Distribution
ASPolicycert may be distributed using any number of methods, for
example:
” maintained in a directory maintained by the issuing autonomous
system,
” distributed via some out of band mechanism, or
” distributed within BGP using extensions defined in [SOBGP-BGP].
To ensure interoperability, an autonomous system SHOULD distribute
its ASPolicycert within BGP.
6.4 Validation
The ASPolicycert is validated using the following steps.
Weis Expires December, 2003 31
Secure Origin BGP (soBGP) Certificates June, 2003
” Identify the Entitycert that signed the ASPolicycert. The correct
Entitycert is uniquely identified with the Entity Certificate
Issuer Autonomous System and Entity Certificate Serial Number
contained in the Signature TLV. The Entity Certificate Issuer
Autonomous System is compared with the AS number in the Entitycert
IssuerAltName field. The Entity Certificate Serial Number is
compared with the Entitycert CertificateSerialNumber.
” Obtain the Entitycert that signed the ASPolicycert, and validate
it. The Entitycert may be in a local cache (already received via
BGP extensions), retrieved using the URL in the Authcert, or
through other means. If an entity does not have the validating
public key it MUST NOT assume the ASPolicycert is valid.
” Verify that the autonomous system identifier in SubjectAltname
matches the Authorized Originator TLV value of the ASPolicycert.
” Hash the ASPolicycert TLVs.
” Extract the signature from the ASPolicycert.
” Extract the public key from the Entitycert, and use it to decrypt
the signature.
” Validate that the computed hash matches the decrypted hash.
Once an ASPolicycert has been validated, any ASPolicycert with a
lower serial number from the same originating AS MUST be discarded.
6.5 Revocation
Each ASPolicycert issued by an autonomous system overrides any
previously issued ASPolicycerts from this autonomous system.
Therefore, revocation is not required.
If present, a receiver has the opportunity of using the Most Recent
AS Policy Certificate URL in the ASPolicycert to verify that they
have the most recent policy certificate.
7.0 Security Considerations
This document describes the format of authentication, authorization,
and policy certificates used to with [SOBGP-BGP]. Each certificate
type is digitally signed, and therefore requires no external
protection to ensure its integrity. There are no restrictions on how
they may be distributed. Revocation schemes are defined for all
certificate types.
The following sections describe the security considerations of each
of those objects.
7.1 Entitycerts
Entitycerts provide authentication, providing a binding of an
identity (i.e., autonomous system number) to a public key. The
authenticity of the binding is verified with a digital signature,
where the public key of the certificate issuer has been previously
accepted as valid. Issuer public keys can either be manually
configured, or are verified through the use of another issuer's
trusted public key in a "web of trust" built by the receiver.
Weis Expires December, 2003 32
Secure Origin BGP (soBGP) Certificates June, 2003
Certificate issuers MUST maintain certificate revocation lists
(CRLs). Entities verifying Entitycerts SHOULD reference the
certificate revocation lists whenever possible. (Mandating the
consultation of a CRL as part of the verification process is not
possible, because the CRL may not be available at the time
verification is performed. For example, if the issuer maintains the
CRL on a directory server to which routing is not yet setup.)
Issuers SHOULD distribute their CRLs within their AS Policy
Certificates to increase the likelihood of a receiver having the CRL
available.
Self-signed Entitycerts may be necessary in order to start a chain
of trust. However self-signed Entitycerts MUST be manually validated
as accurate before the enclosed public key is used, else the "web of
trust" breaks down.
7.2 Authcerts
Authcerts provide authorization, where the issuer of a prefix block
certifies that it has given that prefix block to a specific
autonomous system. Receivers use the Authcert to validate
announcements received in BGP UPDATE messages.
The authenticity of Authcerts is verified with a digital signature,
where the public key of the certificate issuer is distributed in an
Entitycert. Before a receiver can verify the Authcert, they MUST
first check that the verifying Entitycert is authentic.
The Authcert issuer MUST keep an Authcert validation list describing
which certificates are valid, and which are invalid. The receivers
of an Authcert SHOULD consult the Authcert validation list to ensure
that the authorization has not been revoked.
Autonomous systems may need to authorize their own use of prefix
blocks if the autonomous system that issued their prefix blocks does
not issue them an Authcert. However, such self-generated Authcerts
are dangerous, since unrestricted use of self-signed Authcerts
defeats the goal of authorization. Thus an entity MUST accept self-
generated Authcerts only from autonomous systems that have been
explicitly configured as trusted to claim authorization without the
confirmation of a third party.
7.3 PrefixPolicycerts
PrefixPolicycerts bind policy generated by an autonomous system for
prefix blocks that they advertise. This policy is bound to a
particular Authcert, which verifies that they are authorized to
advertise those prefix blocks.
PrefixPolicycerts are verified with a digital signature, where the
public key of the certificate issuer is distributed in an
Weis Expires December, 2003 33
Secure Origin BGP (soBGP) Certificates June, 2003
Entitycert. Before a receiver can verify the PrefixPolicycert, they
MUST first verify that the verifying Entitycert is authentic.
7.4 ASPolicycerts
ASPolicycerts contain policy generated by an autonomous system, and
contain policy about the autonomous system itself. The policy
includes its neighbor autonomous systems, which can be used by other
entities to validate valid inter-connections. The policy can also
include revocation and validation lists (Authcert, PrefixPolicycert)
.
ASPolicycerts are verified with a digital signature, where the
public key of the certificate issuer is distributed in an
Entitycert. Before a receiver can verify the ASPolicycerts, they
MUST first verify that the verifying Entitycert is authentic.
7.5 Entitycert Uniform Resource Locators
Authcerts, PrefixPolicycerts, and ASPolicycerts may contain a URL
that references the Entitycert used to validate it. Care should be
taken in evaluating the URL since it is not yet known to be valid
and could be used to propagate a denial of service attack.
8.0 IANA Considerations
This document defines three certificate types, each of which contains
a series of TLVs. IANA is expected to maintain a registry of all the
values defined, according to the following sections.
8.1 Authorization Certificate
The Authorization Certificate Type Field:
o Type values 1 through 4, 14 and 65535 are assigned in this
document.
o Type values 5 through 13 and 15 through 16575 MUST be assigned
using the "IETF Consensus" policy defined in RFC 2434
[RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.1.1 Signature Type
The Signature TLV Signature Type field:
o Type values 1 is assigned in this document.
Weis Expires December, 2003 34
Secure Origin BGP (soBGP) Certificates June, 2003
o Type values 2 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.2 Prefix Policy Certificate
o Type values 1 through 5, 14 and 65535 are assigned in this
document.
o Type values 6 through 13 and 15 through 16575 MUST be assigned
using the "IETF Consensus" policy defined in RFC 2434
[RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.2.1 Policies Type
The Policies Type has two name spaces: Options flags and SubTVs.
The Options Field:
o Bits 0 and 1 are assigned in this document.
o Bits 2 thru 7 MUST be assigned using the "IETF Consensus"
policy defined in RFC 2434 [RFC2434].
o Bits 8 thru 15 are for "Private Use" as defined in RFC 2434
[RFC2434].
The subTV TV Type field:
o TV Type values 1 through 3 are assigned in this document.
o TV Type values 4 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
o TV Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o TV Type values 32896 through 65534 are for "Private Use" as
defined in RFC 2434 [RFC2434].
Weis Expires December, 2003 35
Secure Origin BGP (soBGP) Certificates June, 2003
8.2.2 Signature Type
The Signature TLV Signature Type field:
o Type values 1 is assigned in this document.
o Type values 2 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.3 AS Policy Certificate
o Type values 1 through 9, 14 and 65535 are assigned in this
document.
o Type values 10 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.3.1 Validity Ranges
o Type values 1 through 2 are assigned in this document.
o Type values 3 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
8.3.2 Signature Type
The Signature TLV Signature Type field:
o Type values 1 is assigned in this document.
o Type values 2 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC 2434 [RFC2434].
Weis Expires December, 2003 36
Secure Origin BGP (soBGP) Certificates June, 2003
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC 2434 [RFC2434].
o Type values 32896 through 65534 are for "Private Use" as defined
in RFC 2434 [RFC2434].
9.0 Acknowledgments
A large number of people contributed to or provided valuable feedback
on this document; we've tried to include all of them here (in no
particular order), but might have missed a few: James Ng, Russ White,
Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes,
Max Pritikin, Chris Lonvick, Tim Gage, Scott Fanning, Barry Friedman,
Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum,
and Jonathan Natale.
10.0 References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2858] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3279] Polk, T., et. al., " Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., et. al., "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 3280, April 2002.
[SOBGP-BGP] Ng J. (editor), "Extensions to BGP to Support Secure
Origin BGP (soBGP)", draft-ng-sobgp-deployment-01.doc, November 2002
[X.690] International Telecommunication Union, "ITU-T Recommendation
X.660 Information Technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
10.2 Informative References
Weis Expires December, 2003 37
Secure Origin BGP (soBGP) Certificates June, 2003
[IAB-SC] Rescorla, E., B. Korver, and the Internet Architecture
Board, "Guidelines for Writing RFC Text on Security Considerations",
http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt, Work
in progress, 2003.
[RFC3281] Farrell, S., and R. Housley, " An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April 2002.
Editor's Address
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com
Weis Expires December, 2003 38 | PAFTECH AB 2003-2026 | 2026-04-22 22:16:13 |