idnits 2.17.1 draft-weis-sobgp-certificates-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2132. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP' is mentioned on line 102, but not defined == Missing Reference: 'RSA' is mentioned on line 321, but not defined == Missing Reference: 'RFC1421' is mentioned on line 1127, but not defined == Missing Reference: 'ORIG-EC-URL' is mentioned on line 1010, but not defined == Missing Reference: 'ORIG-AP-URL' is mentioned on line 1010, but not defined == Missing Reference: 'EC-CRL' is mentioned on line 1009, but not defined -- Looks like a reference, but probably isn't: '0' on line 2030 -- Looks like a reference, but probably isn't: '3' on line 1985 == Unused Reference: 'RFC3281' is defined on line 1869, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1872, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFN' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) == Outdated reference: A later version (-02) exists of draft-white-sobgp-architecture-01 -- Possible downref: Normative reference to a draft: ref. 'SOBGP-ARCH' -- No information found for draft-ng-sobgp-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SOBGP-BGP' -- Possible downref: Normative reference to a draft: ref. 'SOBGP-RADIUS' -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Weis, Editor 2 Internet-Draft Cisco Systems 3 Expires: August, 2006 4 February, 2006 6 Secure Origin BGP (soBGP) Certificates 7 draft-weis-sobgp-certificates-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). 36 Abstract 38 This document describes the format of digital certificates that are 39 used by the Secure Origin BGP (soBGP) extensions to BGP, as well as 40 acceptable use of those certificates. Included are certificates 41 providing authentication, authorization, and policy distribution. 43 Table of Contents 45 1.0 Introduction......................................................3 46 1.1 Key Words.......................................................3 47 1.2 Terminology.....................................................3 48 2.0 Overview..........................................................4 49 2.1 soBGP Certificate Certificates Overview.........................5 50 3.0 Authentication Certificate (Entitycert)...........................8 51 3.1 Format..........................................................8 52 3.2 Creation........................................................9 53 3.3 Distribution...................................................11 54 3.4 Validation.....................................................11 55 3.5 Revocation and Expiration......................................14 56 4.0 Authorization and Policy Certificates............................14 57 4.1 Authorization Certificates (Authcert)..........................15 58 4.2 Prefix Policy Certificates (PrefixPolicycert)..................18 59 4.3 AS Policy Certificates (ASPolicycert)..........................21 60 4.4 Common Processing..............................................24 61 5.0 Authorization and Policy Certificate Attributes..................24 62 5.1 Certificate Header (HDR).......................................24 63 5.2 The Originating Autonomous System (ORIG-AS)....................25 64 5.3 Authorized Autonomous System (AUTH-AS).........................25 65 5.4 The Serial Number (SN).........................................25 66 5.5 Originating AS Entitycert URL (ORIG-EC-URL)....................26 67 5.6 Originating AS ASPolicycert URL (ORIG-AP-URL)..................26 68 5.7 The Address Prefix (PREFIX)....................................27 69 5.8 Signature (SIG)................................................28 70 5.9 Authorization Certificate (AUTHCERT)...........................29 71 5.10 Prefix Policies (P-POLICY)....................................29 72 5.11 Attached Transit Autonomous Systems (TRANSIT).................31 73 5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT).........31 74 5.13 Revoked Entity Certificate List (EC-CRL)......................32 75 5.14 Authorization Certificate Validity List (AC-VALID)............33 76 5.15 Prefix Policy Certificate Validity List (PPC-VALID)...........34 77 6.0 Security Considerations..........................................35 78 6.1 Entitycerts....................................................35 79 6.2 Authcerts......................................................35 80 6.3 PrefixPolicycerts..............................................36 81 6.4 ASPolicycerts..................................................36 82 6.5 Entitycert Uniform Resource Locators...........................36 83 7.0 IANA Considerations..............................................37 84 7.1 soBGP Certificate Attribute Values.............................37 85 7.2 Signature Type.................................................37 86 7.3 Policies Type..................................................37 87 7.4 Validity Ranges................................................38 88 8.0 Acknowledgments..................................................38 89 9.0 References.......................................................38 90 9.1 Normative References...........................................38 91 Appendix A. Example Certificates.....................................40 92 A.1. Entitycert....................................................40 93 A.2. Authcert......................................................43 94 Editor's Address.....................................................44 95 Intellectual Property Statement......................................45 96 Copyright Statement..................................................45 98 1.0 Introduction 100 There is a great deal of concern over the security of routing systems 101 within the Internet. This is particularly true in relation to the 102 Border Gateway Protocol [BGP], the protocol used to provide routing 103 information between Autonomous Systems (ASes). Secure Origin BGP 104 (soBGP) provides a method that ASes can use to determine the 105 correctness of BGP messages received by their BGP routers. It also 106 provides a method for ASes to detect implausible routes reported in a 107 BGP Update AS_PATH, and acts as an aid in detecting misconfigured 108 routers advertising incorrect routes. 110 Secure Origin BGP does not define changes to BGP Updates. Rather, it 111 provides authorization and path policy "out-of-band" from the BGP 112 Updates. An AS compares the information claimed in BGP Updates to the 113 soBGP policy, and makes judgments to the fitness of the claim. 115 Secure Origin BGP distributes authorization and policy as digitally 116 signed objects, which can be distributed in many ways. To aid 117 interoperability, extensions have been defined in [SOBGP-BGP] that 118 support distribution of the digitally signed soBGP objects within BGP 119 itself. 121 The Secure Origin BGP architecture is discussed in [SOBGP-ARCH]. That 122 document describes the operation of soBGP, and various deployment 123 models. Extensions to RADIUS to support soBGP in some of those 124 deployment models are defined in [SOBGP-RADIUS]. 126 This document defines the format of the digitally signed objects used 127 by soBGP, as well as the operations to be performed on those objects. 128 Furthermore, a trust model under which the soBGP digitally signed 129 objects can be arranged is described. 131 1.1 Key Words 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 134 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 135 this document are to be interpreted as described in [RFC2119]. 137 1.2 Terminology 138 This document frequently uses the following terms: 140 AS Policy Certificate (ASPolicycert) 141 A digital certificate that asserts routing policy for an 142 Autonomous System. 144 Authorization Certificates (Authcerts) 145 A digital certificate that asserts that an Autonomous System is 146 authorized to advertise a particular prefix. 148 Entity 149 Institutional participants within soBGP. These include Regional 150 Internet Registry (RIR) authorities, Local Internet Registry 151 (LIR) authorities, Internet Service Providers (ISPs), Certificate 152 Authorities (CAs), and other organizations participating in 153 soBGP. Most Entities participate in the routing system. An soBGP 154 Entity must have an Autonomous System (AS) number assigned to it 155 as a unique identity, even if it does not source routes within 156 the routing system. 158 Entity Certificate (Entitycert) 159 An X.509 certificate that asserts a mapping between an Autonomous 160 System identifier and a public key. 162 Prefix Policy Certificate (Prefixpolicycert) 163 A digital certificate mapping usage policy to one or more 164 prefixes. 166 Regional Internet Registry (RIR) 167 An entity recognized by IANA and tasked with managing IP address 168 space within a wide geographical area. RIRs allocate address 169 space to Local Internet Registries and other entities. 171 Local Internet Registry (LIR) 172 An entity that allocates address space to the users of the 173 network services that it provides. 175 2.0 Overview 177 Secure Origin BGP (soBGP) uses digital certificates as a means of 178 attesting authentication, authorization, and policy for entities in 179 the routing system. All soBGP digital certificates contain an 180 identity of the entity to which the certificate applies, a set of 181 attributes, identification of the certificate issuer, and a digital 182 signature created by the issuer. 184 Depending on the purpose of the digital certificate, the identity to 185 which the certificate applies may or may not be the issuer of the 186 certificate. For example, some digital certificates provide a means 187 for one entity to attest authorization of some resource to another 188 entity. In this case, the attesting entity will issue the 189 certificate. In other cases, an entity attests some policy about 190 itself, and so issues the certificate itself. The detailed 191 descriptions of each soBGP certificates below define which case 192 applies to each certificate type. 194 Digital certificates involving entities from different 195 administrative domains are organized into a trust structure called a 196 Public Key Infrastructure (PKI). A PKI can be organized in a number 197 of ways: hierarchical, distributed, bridged, or in a "web of trust". 198 The soBGP certificates in this memo can be deployed in any of these 199 trust structures. However, one likely trust model is described more 200 fully below. 202 2.1 soBGP Certificate Certificates Overview 204 Secure Origin BGP refers to participants within the routing system 205 as entities. Entities may have one or more roles within soBGP. They 206 may act as a trusted signer of digital certificate, an authorizer of 207 address blocks, and/or as a route originator. 209 Each entity must have an Autonomous System (AS) number, issued from 210 an authorized entity (e.g., Regional Internet Registry), to 211 participate in soBGP. The AS number is the primary method of 212 identification with soBGP. All entities are known by their AS 213 number, even those that may not ordinarily advertise routes (e.g., a 214 Certificate Authority). 216 Each soBGP entity has an Entity Certificate (Entitycert). An 217 Entitycert provides an attestation that a particular cryptographic 218 public key can be used to verify signatures from the subject AS 219 identified in the Entitycert. In other words, the Entitycert 220 distributes the public key of an AS. The public key will be used by 221 other entities to verify that other soBGP certificates claiming to 222 be signed by the AS are genuine. Entitycerts are X.509 certificates 223 as specified by [RFC3280]. 225 Secure Origin BGP provides a method of verifying that an AS is 226 authorized to advertise certain prefixes. The authorization to 227 advertise prefixes or a given address space is validated through 228 Authorization Certificates (Authcerts). Authcerts are digitally 229 signed objects issued by entities (e.g., ISPs) that provide proof of 230 prefix allocation. 232 An AS given an Authcert (e.g., an ISP customer) may assign local 233 policy to be used with the prefixes listed in the Authcert. The AS 234 does this by issuing another type of digitally signed object, called 235 a Prefix Policy Certificate (PrefixPolicycert). 237 Policies specific to an Autonomous System are provided through AS 238 Policy Certificates (ASPolicycerts). This policy enables another 239 entity to develop a graph of plausible paths through the routing 240 system, and aids in detecting impossible and fraudulent paths. It 241 also provides a means for the AS to distribute Certificate 242 Revocation Lists for Entitycerts that it has signed, and Validation 243 Lists that describe which authorization and policy certificates are 244 valid for the AS. 246 Authcerts, PrefixPolicycerts, and ASPolicycerts are verified using 247 public keys embedded in Entitycerts. The receiver of a certificate 248 uses the issuing AS number to identify the appropriate Entitycert. 250 Figure 1 illustrates the relationship between soBGP certificates 251 associated with a single AS (AS 2). An arrow in this figure 252 indicates a signature operation. The public key contained in the 253 certificate at the tail of the arrow is used to verify the validity 254 of the certificate at the head of the arrow. 256 +------------+ 257 | AS 1 | 258 +-------| Entitycert | 259 / +------------+ 260 / | 261 + | 262 | | 263 v v 264 +----------+ +------------+ +------------------+ 265 | AS 2 | | AS 2 | | AS 2 | 266 | Authcert | | Entitycert |-------> | PrefixPolicycert | 267 +----------+ +------------+ +------------------+ 268 | 269 | +------------------+ 270 | | AS 2 | 271 +---------> | ASPolicycert | 272 +------------------+ 274 Figure 1. Relationship between soBGP certificates associated with a 275 single Entity (AS 2) 277 In Figure 1, AS 1 (e.g., an ISP) allocates a prefix to AS 2 (e.g., a 278 customer of the ISP). AS 1 also issues an Authcert to AS 2, thereby 279 proving that AS 2 may legitimately use that prefix. In this example, 280 AS 1 also acts as an Entitycert issuer for AS 2. AS 2 then creates 281 two policy certificates: one specifying particular policy for the 282 authorized prefix, and one specifying particular policy for the AS. 284 +------------+ +------------+ 285 | AS 1 | | AS 100 | 286 | Entitycert |<-----| Entitycert | 287 +------------+ +------------+ 288 | | 289 | | 290 | | 291 v v 292 +----------+ +------------+ +------------------+ 293 | AS 2 | | AS 2 | | AS 2 | 294 | Authcert | | Entitycert |-------> | PrefixPolicycert | 295 +----------+ +------------+ +------------------+ 296 | 297 | +------------------+ 298 | | AS 2 | 299 +---------> | ASPolicycert | 300 +------------------+ 302 Figure 2. Adding a Certificate Authority 304 Figure 2 illustrates another possible relationship between soBGP 305 certificates associated with a single AS (AS 2). In this case, both 306 AS1 and AS2 have agreed to trust a single certificate authority (AS 307 100). AS 100 has issued Entitycerts to AS1 and AS2, each which are 308 verified with the public key of AS 100. 310 Note that as before AS1 provides proof of prefix allocation in an 311 Authcert at the time it provides prefix to AS2. However, this is the 312 only relationship necessary between AS1 (and ISP) and AS2 (its 313 customer). This organization of certificates benefits ISPs that 314 choose against being a Certificate Authority for its customers. 316 Each of the soBGP certificates above are discussed in detail in 317 subsequent sections of this document. 319 2.1.1 Digital Signature Algorithms 321 The RSA Public Key Algorithm [RSA] is a widely deployed public key 322 algorithm commonly used for digital signatures. Compared to other 323 public key algorithms, signature verification is efficient. This 324 property is useful considering the large number of signature 325 verifications that will be done on soBGP certificates. The RSA 326 Algorithm is commonly supported in hardware, and is not encumbered by 327 any known intellectual property claims. 329 All soBGP implementations MUST support a digital signature of a SHA-1 330 digest encrypted with the RSA algorithm. An implementation MAY 331 support other signature methods (e.g., RSA/SHA-256), but until that 332 signature method becomes commonly deployed any AS using alternate 333 signature methods run the risk of their signatures not being 334 universally verifiable. 336 3.0 Authentication Certificate (Entitycert) 338 Entitycerts provide authentication, providing a binding of an 339 identity (i.e., autonomous system number) to a public key. The 340 authenticity of the binding is verified with a digital signature, 341 where the public key of the certificate issuer has been previously 342 accepted by an receiver as valid. Issuer public keys can either be 343 manually configured, or are verified through the use of another 344 issuer's trusted public key 346 Entitycerts are used to verify, through a trust model, the existence 347 of an entity within the routing system, and the value of that 348 entity's public key for use in the routing system. Various trust 349 models are possible, but a distributed trust model is preferred 350 because it lends itself to incremental deployment. For more 351 discussion of a distributed trust model, see Section 3.4.1. 353 Each entity within the routing system participating in soBGP MUST 354 generate a public/private key pair. The public key portion of this 355 pair is then signed, verifying that anyone using this public key is 356 actually the entity in question. This signature may be provided by 357 various other trusted parties within the routing system, including 358 (but not limited to): 360 - The authority that issued the autonomous system number. 362 - An external commercial authority that provides digital 363 certificates for other commercial transactions. 365 - Any other trusted party within the domain of Internet routing, 366 such as a well known Service Provider. 368 - Self-signed if the entity is well known within the routing system. 369 (See Section 3.4.2 for a discussion on the risk of self-signed 370 Entitycerts.) 372 A public key is used to verify the validity of other certificates 373 transmitted by this entity within the routing system. The public 374 key, along with other verifying information, is formatted into an 375 Entitycert, as described in the next section. 377 3.1 Format 378 An Entitycert MUST be formatted as an X.509 certificate, as defined 379 in [RFC3280]. The Entitycert MUST be generated with a signature of 380 type sha1withRSAEncryption [RFC3279]. 382 The primary identity in soBGP is the autonomous system number. 383 Because of this, each entity that issues Entitycerts MUST be 384 assigned an AS number, even if they do not originate routes into the 385 internetwork. In accordance with Section 4.2.1.7 of [RFC3280], 386 issuers MUST verify all parts of the subject alternative name, 387 including the AS number, before issuing the certificate. 389 An Entitycert MUST have a subjectAltname critical extension, which 390 MUST contain the AS number of the subject as an otherName choice. 391 The AS number is encoded with the OID defined in Section 3.2.1 of 392 [RFC3779]. 394 An Entitycert MUST have an issuerAltname critical extension, which 395 MUST contain the AS number of the issuer as an otherName choice. The 396 AS number is encoded with the OID defined in Section 3.2.1 of 397 [RFC3779]. 399 The X.509 Issuer and Subject distinguished names are not used by 400 soBGP. In accordance with Section 4.2.1.7 of [RFC3280], when 401 subjectAltName is required, the Subject field MAY be empty. 403 3.2 Creation 405 An Entitycert is usually created with the following steps: 407 - The entity requesting an Entitycert generates a signature key pair 408 - The entity forwards its identity (including its AS number) and the 409 public key to an Entitycert issuer using the certificate 410 registration mechanism supported by the issuer. 411 - The issuing autonomous system verifies that the identity of the 412 receiving autonomous system, generates an Entitycert including 413 that identity, and signs it with its own private key. 414 - The issuing autonomous system returns the Entitycert to the 415 receiving autonomous system. 417 When an Entitycert is created, care should be taken as to whether 418 the Entitycert is authorized to become a CA for other entities. If 419 the signer authorizes the Entity to become a Certificate Authority 420 for other entities, then the following X.509v3 Certificate 421 Extensions MUST be included in an Entitycert: 423 - Key Usage: The keyCertSign and cRLSign bits MUST be set. The 424 digitalSignature bit MUST be set, so that the public key in the 425 certificate may also be used for validating other soBGP 426 certificates. [Section 4.2.1.3, RFC3280] 427 - Basic Constraints: The cA Boolean MUST be set, and 428 pathLenConstraint MAY be set in order to restrict the length of 429 the certification path below this certificate. [Section 4.2.1.10, 430 RFC3280] 432 If the signer does NOT authorize the Entity to become a Certificate 433 Authority for other entities, then the following X.509v3 Certificate 434 Extensions MUST be included in an Entitycert: 436 - Key Usage: The keyCertSign and cRLSign bits MUST NOT be set. The 437 digitalSignature bit MUST be set, so that the public key in the 438 certificate may also be used for validating other soBGP 439 certificates. [Section 4.2.1.3, RFC3280] 440 - Basic Constraints: The cA Boolean MUST NOT be set. [Section 441 4.2.1.10, RFC3280] 443 3.2.1 Certificate Uniqueness 445 Digital certificates are created as uniquely named objects, which 446 allow them to be uniquely identified. For the purposes of soBGP, the 447 pair of CertificateSerialNumber and AS number in the IssuerAltName 448 values uniquely identifies Entity Certificates. Note that although 449 RFC 3280 contains an X.509v3 IssuerName, it is not used within 450 soBGP. 452 3.2.2 Certificate Encoding 454 Entitycerts distributed in [SOBGP-BGP] use their native DER [X.690] 455 form. If Entitycerts are manually distributed (e.g., through 456 electronic mail) they may need to be base64 encoded as described in 457 Section 4.3 of [RFC1421]. 459 3.2.3 Multiplicity of Entitycerts 461 An autonomous system MAY enroll with more than one issuer, which 462 results in multiple valid Entitycerts for that AS. There are several 463 advantages for an AS to obtain Entitycerts from different issues: 465 - A greater number of other autonomous systems in the distributed 466 PKI will accept their public key. 467 - In some cases, other autonomous systems will accept their public 468 key faster, which increases BGP convergence times. 469 - An AS can mitigate losing trust within the distributed PKI if one 470 issuer revokes its entity certificate. While an immediate and 471 complete revocation is usually desirable in a PKI, it is not 472 acceptable in a secure routing system. Immediate and complete 473 revocation by a single issuer would very likely remove access of the 474 revoked entity to the network. Such an event could be catastrophic 475 if the entity is an ISP and its customers. Furthermore, the sudden 476 exit of a major ISP due to revocation could negatively affect the 477 entire routing system. 479 If an entity detects that an autonomous system has valid Entitycerts 480 from different issuers, the entity SHOULD treat the various 481 Entitycerts as independent. Revocation from one issuer does not 482 necessarily imply that Entitycerts from other issuers are invalid. 483 An issuer may revoke a certificate for reasons other than private 484 key compromise or loss. 486 If an issuer revokes an entity certificate and states key compromise 487 as the reason for revocation, a receiving entity SHOULD also treat 488 this state as specific to the issuer. Note that if the state of one 489 issuer were instead considered transitive, the erroneous revocation 490 of a single issuer would result in a denial of service attack on the 491 victim autonomous system. 493 In the face of inconsistent state from different issuers, a receiver 494 MAY choose to trust one issuer over another. For example, a receiver 495 may choose to prefer the result of an issuer they directly trust to 496 an issuer that was verified further away in the distributed PKI. 498 3.3 Distribution 500 Entitycerts may be distributed using any number of methods, for 501 example: 503 - maintained in a directory maintained by the issuing autonomous 504 system, 505 - distributed via some out of band mechanism, and/or 506 - distributed within BGP using extensions defined in [SOBGP-BGP]. 508 To ensure interoperability, the receiving autonomous system SHOULD 509 distribute its Entitycert within BGP. 511 3.4 Validation 513 Validation rules for Entitycerts MUST follow those described in 514 [RFC3280]. Any device receiving an Entitycert can verify it by 515 validating the signature on the certificate, along with the 516 verifying information. Validation of the certificate may include 517 checking a CRL (see Section 3.5). If a Certificate Revocation List 518 (CRL) is available for that issuer, it MUST be consulted to verify 519 that this certificate has not been revoked. Local policy will 520 determine whether or not a CRL must be available in order to 521 complete validation of the certificate. 523 Once validation is complete, the public key contained in this 524 certificate may be used to verify messages purportedly sent by this 525 entity. 527 3.4.1 Distributed PKI Trust Model 529 Secure Origin BGP Entitycerts can be organized in various trust 530 models. A number or variables (e.g., economic factors, government 531 fiat, and entity deployment schedules) could cause different trust 532 models to be best suited. This document describes a Distributed PKI 533 trust model that is flexible and adaptable in many possible 534 deployment scenarios. 536 An soBGP entity uses the a distributed PKI paradigm for purposes of 537 Entitycert validation, where the entity learns the validity of 538 public keys over time. An entity follows the following procedure for 539 validating Entitycerts in the distributed PKI. 541 - A small number of Entitycerts are manually configured and copied 542 to a device's local configuration. These are implicitly trusted as 543 being previously verified and authenticated. 544 - When the entity receives a new Entitycert, it checks to see if it 545 has the public key of the issuing autonomous system in its 546 configuration. If so, it attempts to validate the Entitycert, 547 using the previously known public key, and any revocation material 548 that is available from the issuer. 549 - If the new Entitycert proves valid, it is added to the device's 550 local configuration and may be used to validate subsequently 551 received Entitycerts. 552 - If the new Entitycert cannot be validated because the issuer's 553 public key is not yet available, local policy dictates as to 554 whether or not the certificate is held awaiting the issuer's 555 certificate. 557 Figure 3 shows an example distributed PKI. In this example, 558 Entitycerts for AS 1 and AS 5 would be manually copied to the local 559 configuration on the box. Other Entitycerts would be validated using 560 the usual PKI path validation techniques. 562 As in Figure 1, an arrow in this figure indicates a signature 563 operation. The public key contained in the certificate at the tail 564 of the arrow is used to verify the validity of the certificate at 565 the head of the arrow. 567 +------------+ +------------+ 568 | AS 1 | | AS 5 | 569 | Entitycert | | Entitycert | 570 +-----+------+ +---+----+---+ 571 | / \ 572 | / \ 573 | + + 574 | | | 575 V V V 576 +------------+ +------------+ +------------+ 577 | AS 2 | | AS 6 | | AS 7 | 578 | Entitycert | | Entitycert | | Entitycert | 579 +---+----+---+ +------------+ +-----+------+ 580 / \ | 581 / \ V 582 + + +------------+ 583 | | | AS 8 | 584 V V | Entitycert | 585 +------------+ +------------+ +-----+------+ 586 | AS 3 | | AS 4 | | 587 | Entitycert | | Entitycert | V 588 +------------+ +------------+ +------------+ 589 | AS 9 | 590 | Entitycert | 591 +------------+ 593 Figure 3. Example Distributed PKI 595 An autonomous system may define local policy to restrict the scope 596 of the distributed trust. However it should be noted that any local 597 policy restricting the distributed trust reduces the value of soBGP 598 authorization and path validation. 600 One type of local policy would be to accept only a certain "depth" 601 of Entitycert issuers. For example, consider if AS 6 in Figure 3 602 only accepted two levels of issuers. AS 6 would only trust ASes 603 1,2,5,6 and 7 to issue Entitycerts. It would never validate the 604 Entitycert from ASes 3, 4, 8, and 9. 606 Note that if the top-level roots in the distributed PKI (AS1 and 607 AS5) trusted each other enough they could issue certificates for 608 each other, or "cross-certify". This could simplify the certificate 609 validation process for all ASes. However, a cross-certified 610 distributed PKI system is not always appropriate. For example, if 611 AS1 and AS5 have strikingly different certificate issuance policies 612 they may not be willing to cross-certify. 614 3.4.2 Self-signed Entitycerts 616 Entitycerts MAY be self-signed, but SHOULD only be accepted from 617 autonomous systems when a method exists of validating that the self- 618 signed certificate is genuine. Distribution out-of-band using a 619 trusted delivery procedure would be one method. An autonomous system 620 MUST have local policy describing the circumstances under which they 621 will access self-signed certificates. 623 Typical users of a self-signed Entitycert would be: 625 - A commercial authority in the business of providing digital 626 certificates for many types of commercial transactions 627 - An Entitycert issuer that is at the top of a hierarchy of issuers 628 - A well-known trusted party within the domain of Internet routing 630 3.5 Revocation and Expiration 632 As described in [RFC3280], any entity issuing an Entitycert may 633 later need to revoke it. The entity MAY use any available methods 634 for propagating that revocation list, but SHOULD send it as part of 635 an AS Policy Certificate (distributed using [SOBGP-BGP]). This 636 allows autonomous systems that cannot route to the issuing 637 autonomous system to verify that the Entitycert has not been 638 revoked. 640 If an Entitycert is discarded due to revocation, the Authcert and 641 Policy databases should be examined. Any Authcerts and Policy 642 certificates that were validated using the discarded certificate 643 should be removed from the database. 645 X.509 certificates contain expiration dates. Any device validating 646 Entitycerts MUST have a time of day clock that is set to real time 647 in order to properly deal with expired certificates 649 If an Entitycert is discarded due to expiration, Authcerts or Policy 650 certificates validated using the discarded certificate remain valid 651 if another valid Entitycert for the AS can be found containing the 652 same public key. 654 4.0 Authorization and Policy Certificates 656 soBGP defines a set of certificates that make authorization and 657 local policy claims regarding prefixes, and local policy claims 658 regarding Autonomous Systems. These certificates are not defined to 659 be in a X.509 format. Rather, they are defined in a more compact 660 Type/Length/Value (TLV) format that can be easily transferred 661 through BGP [SOBGP-BGP]. 663 The certificates share a common set of attributes, which are defined 664 in later section of this document. The following sections describe 665 which attributes are relevant to the various certificate types, as 666 well as the processing semantics for each certificate type. 668 Each certificates is formatted as a header block followed by a set 669 of Type/Length/Value attributes. All TLVs described in the following 670 sections are REQUIRED to be present in an Authcert unless they are 671 declared optional. 673 4.1 Authorization Certificates (Authcert) 675 Authcerts prove the right of an entity to advertise particular 676 prefixes. They are generated in a hierarchical manner following the 677 order of address space allocation (i.e., from RIR, to LIR or ISP, to 678 customer), and are distributed along with the address space 679 allocation. Receivers use the Authcert to validate announcements 680 received in BGP UPDATE messages. 682 The authorization certificate binds one or more prefix blocks to a 683 particular autonomous system. It is typically provided by an entity 684 issuing a prefix block to an autonomous system, and is digitally 685 signed by the issuing autonomous system. The Authcert can be thought 686 of as an "Attribute Certificate" in the spirit of RFC 3281, although 687 it does not follow the syntax of that document. 689 The authenticity of Authcerts is verified with a digital signature 690 provided by the issuing autonomous system. Authcerts do not contain 691 public keys. Rather, they bind an address space to a particular 692 identity (i.e., Autonomous System). 694 Including more than one prefix block in an Authcert can reduce the 695 number of Authcerts necessary. However, note that an Authcert is 696 bundled with policy as part of Prefix Policy Certificate (discussed 697 later in this document). If more than one prefix block is included 698 in the Authcert, then that policy will apply to all of the prefix 699 blocks. 701 Multiple entities (i.e., AS numbers) may be authorized to advertise 702 a prefix block. This is necessary when an organization without an AS 703 number is multi-homed. See Section 5.3 of [SOBGP-ARCH] for more 704 details. 706 4.1.1 Format 708 Figure 4 describes the format and order of an Authcert. Optional 709 attributes are represented within brackets. An asterisk following an 710 attribute indicates that more than one of the attribute may be 711 present. 713 HDR, ORIG-AS, AUTH-AS*, SN, PREFIX*, [ORIG-EC-URL], 714 [ORIG-AP-URL], SIG 716 Figure 4. Authcert Format 718 The ORIG-AS describes the entity that created the certificate. It 719 serves the same purpose as the issuerName and issuerAltName in an 720 X.509v3 certificate. The AUTH-AS describes the subject entity to 721 which the prefix has been allocated. This serves as the subjectName 722 and subjectAltName in an X.509v3 certificate. 724 The SN attribute provides a unique serial number for this 725 certificate. It serves the same purpose as an X.509v3 serialNumber. 727 The PREFIX attribute describes an address block that has been 728 assigned to the AS numbers declared in the AUTH-AS attributes. 730 The ORIG-EC-URL attribute contains a URL to an Entitycert containing 731 the public key that signed this certificate. The ORIG-AC-URL 732 attribute contains a URL to the most recent ASPolicycert, which 733 allows a receiver to verify that this Authcert is still considered 734 valid by the originating AS. 736 The SIG attribute contains a digital signature created by the 737 originating AS. 739 4.1.2 Creation 741 An Authcert is usually created by the authorizing Autonomous System 742 with the following steps: 744 - Allocate a prefix block to the receiving autonomous system. 745 - Build an Authcert by adding TLVs containing it's the authorizing 746 AS number, the receiving (authorized) AS number, the prefix block, 747 a unique sequence number, and any other information (e.g., URL 748 pointing to the Entitycert that signed this Authcert.). The 749 Signature TLV is also included, except for the signature bytes. 750 - Sign the Authcert by hashing and encrypting the Authcert bytes. 751 Append the signature to the Signature TLV to complete the 752 Authcert. 754 4.1.3 Distribution 756 Authcerts are distributed as part of a Prefix Policy Certificate, so 757 that an Autonomous System can reliably match distribution policy to 758 the prefix block. 760 4.1.4 Validation 762 The Authcert is validated using the following steps. 764 - Identify the Entitycert that signed the Authcert. The correct 765 Entitycert is uniquely identified with the Entity Certificate 766 Issuer Autonomous System and Entity Certificate Serial Number 767 contained in the Signature TLV. The Entity Certificate Issuer 768 Autonomous System is compared with the AS number in the Entitycert 769 IssuerAltName field. The Entity Certificate Serial Number is 770 compared with the Entitycert CertificateSerialNumber. 771 - Obtain the Entitycert that signed the Authcert, and validate it. 772 The Entitycert may be in a local cache (e.g., already received via 773 BGP extensions), retrieved using the URL in the Authcert, or 774 through other means. If an entity does not have the validating 775 public key it MUST NOT assume the Authcert is valid. 776 - Verify that the autonomous system identifier in SubjectAltName of 777 the Entitycert matches the Authorizing AS TLV value of the 778 Authcert. 779 - If an Authorization Certificate Validity List is available, 780 validate that the issuer of the Entitycert has not invalidated the 781 Authcert. Validity lists may be distributed in the signers 782 ASPolicycert, or a pointer to the list may be distributed in the 783 Authcert in an Originating AS ASPolicycert URL . If no 784 Authorization Certificate Validity List is available, an entity 785 MAY accept the certificate. However if a validity list is received 786 later, the entity MUST check the validity of all certificates that 787 had been previously accepted. 788 - Hash the Authcert bytes, excluding the signature itself. 789 - Extract the signature from the Authcert. 790 - Extract the public key from the Entitycert, and use it to decrypt 791 the signature. 792 - Verify that the computed hash matches the decrypted hash. If the 793 hashes do not match, the Authcert MUST be discarded. 794 - Verify that the Originating AS was authorized to distribute the 795 prefix to the subject AS. This is done by comparing the address 796 space allocated to the Originating AS to the prefix that the 797 Originating AS included in this Authcert. IF the Originating AS 798 was authorized to allocate the prefix in this Authcert, then the 799 Authcert is accepted as valid. 801 4.1.4.1 Self-signed Authcerts 803 Self-signed Authcerts are dangerous, because a responsible third 804 party does not assign the authorization contained within the 805 Authcert. Trusting an autonomous system to declare authorization of 806 its own address space negates the ability of any third party to 807 verify suitability of the authorization. 809 However, the autonomous systems at the highest level of prefix 810 allocation (e.g. Regional Internet Registries (RIRs) or Local 811 Internet Registries (LIRs)) may not be able to find a responsible 812 third party to sign their Authcerts. In this case, self-signed 813 Authcerts may be unavoidable. 815 Authcerts MAY be self-signed, but MUST only be accepted from 816 autonomous systems that have been locally configured as explicitly 817 authorized to do so. For example, a device may be configured to 818 accept Authcerts for the RIR autonomous systems. 820 4.1.5 Revocation 822 An entity issuing an Authcert MUST keep an Authcert revocation list. 823 The entity MAY use any form for propagating that revocation list. 825 Because BGP routers do not necessarily have synchronized clocks, 826 Authcerts do not carry expiration times, and thus do not expire. 827 Revocation is only method of invalidating an Authcert. 829 Revocation information may be represented as a "validation list". A 830 validation list includes lists of both valid and invalid (i.e., 831 revoked) certificates. Any number not appearing in the list MUST be 832 considered invalid. Validation list may be more efficient than a 833 pure revocation list for Authcerts in the case where a large number 834 of serial numbers have been revoked by an issuer. 836 An autonomous system MUST include an Authcert validation list in 837 their AS Policy Certificate (distributed using [SOBGP-BGP]). This 838 allows autonomous systems that cannot route to the issuing 839 autonomous system to verify that the Entitycert has not been 840 revoked. 842 4.2 Prefix Policy Certificates (PrefixPolicycert) 844 The PrefixPolicycert carries policy information sourced from route 845 originators. It provides a specific set of policy regarding one or 846 more prefix blocks. The owner of the prefix block creates it. There 847 is only one valid PrefixPolicycert for each prefix block at any 848 given time. 850 PrefixPolicycerts are verified with a digital signature provided by 851 the autonomous system generating the policy. It does not contain a 852 public key. Rather, it binds a particular policy to a particular 853 identity (i.e., autonomous system). 855 5.2.1 Format 857 Figure 5 describes the format and order of a PrefixPolicycert. 858 Optional attributes are represented within brackets. An asterisk 859 following an attribute indicates that more than one of the 860 attributes may be present. 862 HDR, ORIG-AS, SN, AUTHCERT*, P-POLICY, 863 [ORIG-EC-URL], [ORIG-AP-URL], SIG 865 Figure 5. PrefixPolicycert Format 867 The ORIG-AS describes the entity that created the certificate. It 868 serves the same purpose as the issuerName and issuerAltName in an 869 X.509v3 certificate. 871 The SN attribute provides a unique serial number for this 872 certificate. It serves the same purpose as an X.509v3 serialNumber. 874 The AUTHCERT attribute designates an Authorization Certificate that 875 is subject to the policies indicated in this certificate. If 876 multiple AUTHCERT attributes are present, they are all subject to 877 the same policy. 879 The P-POLICY attribute contains specific policy that the originator 880 is requesting other entities to honor regarding the prefixes 881 contained in the AUTHCERT attributes. 883 The ORIG-EC-URL attribute contains a URL to an Entitycert containing 884 the public key that signed this certificate. The ORIG-AC-URL 885 attribute contains a URL to the most recent ASpolicycerts, which 886 allows a receiver to verify that this is PrefixPolicycert is still 887 considered valid by the originating AS. 889 The SIG attribute contains a digital signature created by the 890 originating AS. 892 4.2.2 Creation 894 An PrefixPolicycert is created by an autonomous system for prefix 895 blocks that it owns. An autonomous system creates it with the 896 following steps: 898 - Build an PrefixPolicycert by adding TLVs containing its own AS 899 number, a unique sequence number, policy related to one or more 900 prefix blocks, and the Authcert or Authcerts defining the prefix 901 blocks to which this policy applies. The Signature TLV is also 902 included, except for the signature bytes. 903 - Sign the Authcert by hashing and encrypting the PrefixPolicycert 904 bytes. Append the signature to the Signature TLV to complete the 905 PrefixPolicycert. 907 4.2.3 Distribution 909 PrefixPolicycerts may be distributed using any number of methods, 910 for example: 912 - maintained in a directory maintained by the issuing autonomous 913 system, 914 - distributed via some out of band mechanism, or 915 - distributed within BGP using extensions defined in [SOBGP-BGP]. 917 To ensure interoperability, an autonomous system SHOULD distribute 918 its PrefixPolicycerts within BGP. 920 4.2.4 Validation 922 The Authcert included in the Authcert TLV MUST be validated as 923 correct before the Policy TLV can be accepted. Thus, the Authcert 924 should be extracted from the PrefixPolicycert and validated before 925 the PrefixPolicycert is validated. 927 The PrefixPolicycert is validated using the following steps. 929 - Identify the Entitycert that signed the PrefixPolicycert. The 930 correct Entitycert is uniquely identified with the Entity 931 Certificate Issuer Autonomous System and Entity Certificate Serial 932 Number contained in the Signature TLV. The Entity Certificate 933 Issuer Autonomous System is compared with the AS number in the 934 Entitycert IssuerAltName field. The Entity Certificate Serial 935 Number is compared with the Entitycert CertificateSerialNumber. 936 - Obtain the Entitycert that signed the PrefixPolicycert, and 937 validate it. The Entitycert may be in a local cache (e.g., already 938 received via BGP extensions), retrieved using the URL in the 939 Authcert, or through other means. If an entity does not have the 940 validating public key it MUST NOT assume the PrefixPolicycert is 941 valid. 942 - Verify that the autonomous system identifier in SubjectAltName of 943 the Entitycert matches the Originating Autonomous System TLV value 944 of the PrefixPolicycert. 945 - If an Prefix Policy Certificate Validity List is available, 946 validate that the issuer of the Entitycert has not invalidated the 947 Authcert. Validity lists may be distributed in the signers 948 ASPolicycert, or a pointer to the list may be distributed in the 949 Authcert in an Originating AS ASPolicycert URL. If no Prefix 950 Policy Certificate Validity List is available, an entity MAY 951 accept the certificate. However if a validity list is received 952 later, the entity MUST check the validity of all certificates that 953 had been previously accepted. 954 - Hash the PrefixPolicycert bytes, excluding the signature itself. 955 - Extract the signature from the PrefixPolicycert. 956 - Extract the public key from the Entitycert, and use it to decrypt 957 the signature. 958 - Validate that the computed hash matches the decrypted hash. If the 959 hashes do not match, the PrefixPolicycert MUST be discarded. 961 Once a PrefixPolicycert has been validated, any PrefixPolicycert 962 that matches the following criteria MUST be discarded: 963 - has a lower serial number from the same originating AS, and 964 - includes an Authcert with the same prefix block 966 4.2.5 Revocation 968 Any entity issuing an PrefixPolicycert MUST keep a revocation list. 969 The entity MAY use any form for propagating that revocation list. 971 Because BGP routers do not necessarily have synchronized clocks, 972 PrefixPolicycert do not carry expiration times, and thus do not 973 expire. Revocation is only method of invalidating a 974 PrefixPolicycert. 976 Revocation information may be represented as a "validation list". A 977 validation list includes lists of both valid and invalid (i.e., 978 revoked) certificates. Any number not appearing in the list MUST be 979 considered invalid. Validation list may be more efficient than a 980 pure revocation list for PrefixPolicycerts in the case where a large 981 number of serial numbers have been revoked by an issuer. 983 An autonomous system SHOULD include an PrefixPolicycert validation 984 list in their AS Policy Certificate (distributed using [SOBGP-BGP]). 985 This allows autonomous systems that cannot route to the issuing 986 autonomous system to verify that the Entitycert has not been 987 revoked. 989 4.3 AS Policy Certificates (ASPolicycert) 991 The ASPolicycert provides a specific set of policy relating to an 992 autonomous system. An administrative entity within the autonomous 993 system creates it. There is only one valid ASPolicycert for each 994 autonomous system at any given time. 996 ASPolicycerts are verified with a digital signature from the 997 autonomous system generating the policy. It does not contain a 998 public key. Rather, it binds a particular policy to a particular 999 identity (i.e., autonomous system). 1001 4.3.1 Format 1003 Figure 6 describes the format and order of a PrefixPolicycert. 1004 Optional attributes are represented within brackets. An asterisk 1005 following an attribute indicates that more than one of the 1006 attributes may be present. 1008 HDR, ORIG-AS, SN, TRANSIT, NON-TRANSIT, 1009 [EC-CRL], AC-VALID, PPC-VALID, 1010 [ORIG-EC-URL],[ORIG-AP-URL], SIG 1012 Figure 6. ASpolicycert Format 1014 The ORIG-AS describes the entity that created the certificate. It 1015 serves the same purpose as the issuerName and issuerAltName in an 1016 X.509v3 certificate. 1018 The SN attribute provides a unique serial number for this 1019 certificate. It serves the same purpose as an X.509v3 serialNumber. 1021 The TRANSIT attribute declares which entities are transit peers, 1022 through which the originating AS may route packets. The NON-TRANSIT 1023 attribute declares which entities are also peers, but through which 1024 the originating AS will not route packets. 1026 The EC-CRL attribute contains an X.509 CRL declaring which 1027 Entitycerts created by the originating AS have been revoked. 1029 The AC-VALID and PPC-VALID attributes contain validity lists 1030 describing what Authcerts and PrefixPolicycerts created by the 1031 originating AS are valid. Validity lists are more descriptive than 1032 CRLs. See Section 4.1.5 for the rationale of using Validity Lists 1033 rather than CRLs. 1035 The ORIG-EC-URL attribute contains a URL to an Entitycert containing 1036 the public key that signed this certificate. The ORIG-AC-URL 1037 attribute contains a URL to the most recent ASpolicycerts, which 1038 allows a receiver to verify that this is an Authcert still 1039 considered valid by the originating AS. 1041 The SIG attribute contains a digital signature created by the 1042 originating AS. 1044 4.3.2 Creation 1046 An ASPolicycert is created by an autonomous system in order to relay 1047 its own policy. An autonomous system creates it with the following 1048 steps: 1050 - Build an ASPolicycert by adding TLVs containing its own AS number, 1051 a unique sequence number, and policy related to the autonomous 1052 system. The Signature TLV is also included, except for the 1053 signature bytes. 1054 - Sign the Authcert by hashing and encrypting the ASPolicycert 1055 bytes. Append the signature to the Signature TLV to complete the 1056 ASPolicycert . 1058 4.3.3 Distribution 1060 ASPolicycert may be distributed using any number of methods, for 1061 example: 1063 - maintained in a directory maintained by the issuing autonomous 1064 system, 1065 - distributed via some out of band mechanism, or 1066 - distributed within BGP using extensions defined in [SOBGP-BGP]. 1068 To ensure interoperability, an autonomous system SHOULD distribute 1069 its ASPolicycert within BGP. 1071 4.3.4 Validation 1073 The ASPolicycert is validated using the following steps. 1075 - Identify the Entitycert that signed the ASPolicycert. The correct 1076 Entitycert is uniquely identified with the Entity Certificate 1077 Issuer Autonomous System and Entity Certificate Serial Number 1078 contained in the Signature TLV. The Entity Certificate Issuer 1079 Autonomous System is compared with the AS number in the Entitycert 1080 IssuerAltName field. The Entity Certificate Serial Number is 1081 compared with the Entitycert CertificateSerialNumber. 1082 - Obtain the Entitycert that signed the ASPolicycert, and validate 1083 it. The Entitycert may be in a local cache (already received via 1084 BGP extensions), retrieved using the URL in the Authcert, or 1085 through other means. If an entity does not have the validating 1086 public key it MUST NOT assume the ASPolicycert is valid. 1087 - Verify that the autonomous system identifier in SubjectAltName of 1088 the Entitycert matches the Originating Autonomous System TLV value 1089 of the ASPolicycert. 1090 - Hash the ASPolicycert bytes, excluding the signature itself. 1091 - Extract the signature from the ASPolicycert. 1092 - Extract the public key from the Entitycert, and use it to decrypt 1093 the signature. 1094 - Validate that the computed hash matches the decrypted hash. If the 1095 hashes do not match, the ASPolicycert MUST be discarded. 1097 Once an ASPolicycert has been validated, any ASPolicycert with a 1098 lower serial number from the same originating AS MUST be discarded. 1100 4.3.5 Revocation 1102 Each ASPolicycert issued by an autonomous system overrides any 1103 previously issued ASPolicycerts from this autonomous system. 1104 Therefore, revocation is not required. 1106 If present, a receiver has the opportunity of using the Most Recent 1107 AS Policy Certificate URL in the ASPolicycert to verify that they 1108 have the most recent policy certificate. 1110 4.4 Common Processing 1112 The following sections describe processing that is common to each of 1113 the soBGP TLV-based certificates. 1115 4.4.1 Certificate Uniqueness 1117 Digital certificates are created as uniquely named objects, which 1118 allows them to be uniquely identified. The pair of Authorized 1119 Originator and certificate Serial Number TLV values uniquely 1120 identifies each certificate. 1122 4.4.2 Certificate Encoding 1124 The soBGP TLV-based certificates are distributed through BGP [SOBGP- 1125 BGP] in the TLV form. However if they are manually distributed (e.g., 1126 through electronic mail) they may need to be base64 encoded as 1127 described in Section 4.3 of [RFC1421]. 1129 5.0 Authorization and Policy Certificate Attributes 1131 5.1 Certificate Header (HDR) 1133 Each soBGP certificate begins with a header: 1135 0 1 2 3 1136 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 1137 +---------------+---------------+-------------------------------+ 1138 | Cert. Marker | Type Id | Length | 1139 +---------------+---------------+-------------------------------+ 1141 The header fields are defined as follows: 1143 o Certificate Marker: "162(0xa2), identifying this as an soBGP 1144 certificate. 1146 o Type ID: Identifier denoting the soBGP certificate type. 1148 Type ID Value 1149 -------- ----- 1150 AuthCert 1 (0x01) 1151 PrefixPolicycert 2 (0x02) 1152 ASPolicycert 3 (0x03) 1154 o Length: Set to the number of bytes in the certificate, 1155 including the header. 1157 5.2 The Originating Autonomous System (ORIG-AS) 1159 0 1 2 3 1160 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 1161 +-------------------------------+-------------------------------+ 1162 | TLV Type | Length | 1163 +-------------------------------+-------------------------------+ 1164 | Originating Autonomous System | 1165 +---------------------------------------------------------------+ 1167 o TLV type: 1 (0x0001) 1169 o Length: Set to 4. 1171 o Originating Autonomous System: (4 octets), the autonomous 1172 system which originated this certificate. AS numbers containing 1173 only two octets should be placed in the least significant 1174 octets of this four-octet field (the two rightmost octets), the 1175 upper two rightmost bits set to zeros. 1177 Each soBGP certificate MUST include an originating Autonomous System 1178 number. This attribute declares which identity has created the 1179 certificate. 1181 5.3 Authorized Autonomous System (AUTH-AS) 1183 0 1 2 3 1184 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 1185 +-------------------------------+-------------------------------+ 1186 | TLV Type | Length | 1187 +-------------------------------+-------------------------------+ 1188 | Autonomous System | 1189 +---------------------------------------------------------------+ 1191 o TLV type: 2 (0x0002) 1193 o Length: Set to 4. 1195 o AS: (4 octets), the autonomous system of an entity authorized 1196 to advertise prefixes within this block. AS numbers containing 1197 only two octets should be placed in the least significant 1198 octets of this four-octet field (the two rightmost octets). 1200 Multiple authorized originator TLVs may be included in the Authcert. 1202 5.4 The Serial Number (SN) 1203 0 1 2 3 1204 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 1205 +-------------------------------+-------------------------------+ 1206 | TLV Type | Length | 1207 +-------------------------------+-------------------------------+ 1208 | Serial Number | 1209 +---------------------------------------------------------------+ 1211 o TLV type: 3 (0x0003) 1213 o Length: Denotes the length of the URL in octets. 1215 o Serial Number: (An unsigned integer taken from a number space 1216 maintained by the Authorizing AS indicating the serial number 1217 of this certificate. 1219 This attribute MUST be present in each TLV-based soBGP certificate. 1220 The Originating Autonomous System MUST manage the number space of 1221 each certificate type as a monotonically increasing value so that a 1222 relative ordering of certificates is maintained. 1224 5.5 Originating AS Entitycert URL (ORIG-EC-URL) 1226 0 1 2 3 1227 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 1228 +-------------------------------+-------------------------------+ 1229 | TLV Type | Length | 1230 +-------------------------------+-------------------------------+ 1231 | URL | 1232 +---------------- 1234 o TLV type: 4 (0x0004) 1236 o Length: Denotes the length of the URL in octets. 1238 o URL: A uniform resource locator indicating a location where the 1239 Originating Autonomous System Entitycert can be found. 1241 This attribute allows a receiver to validate that it has the most 1242 current Entitycert for the originator. This mitigates an attack 1243 where an adversary has been able to stop the propagation of new 1244 Entitycerts. 1246 A conforming implementation is REQUIRED to support this attribute. A 1247 receiving device MAY choose to ignore the URL TLV. 1249 5.6 Originating AS ASPolicycert URL (ORIG-AP-URL) 1250 0 1 2 3 1251 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 1252 +-------------------------------+-------------------------------+ 1253 | TLV Type | Length | 1254 +-------------------------------+-------------------------------+ 1255 | URL | 1256 +---------------- 1258 o TLV type: 5 (0x0005) 1260 o Length: Denotes the length of the URL in octets. 1262 o URL: A uniform resource locator indicating a location where the 1263 Originating Autonomous System ASPolicycert can be found. 1265 This attribute allows a receiver to validate that it has the most 1266 current policy for the originator. In particular, it allows a 1267 receiver to obtain the most recent Validation Lists generated by the 1268 Originating Autonomous System. Having the most recent Validation 1269 Lists allows a receiver to validate that the Authcerts and 1270 Prefixpolicycerts that they hold for that AS have not been replaced. 1271 This validation mitigates an attack where an adversary has been able 1272 to stop the propagation of ASPolicycerts. 1274 A conforming implementation is REQUIRED to support this attribute. A 1275 receiving device MAY choose to ignore the URL TLV. 1277 5.7 The Address Prefix (PREFIX) 1279 The address prefix TLV defines prefixes which the authorized AS (or 1280 ASes) are allowed to advertise. 1282 0 1 2 3 1283 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 1284 +-------------------------------+-------------------------------+ 1285 | TLV Type | Length | 1286 +-------------------------------+---------------+---------------+ 1287 | Address Family Identifier | RESERVED | Subsequent AFI| 1288 +-------------------------------+---------------+---------------+ 1289 | NLRI Data | 1290 +---------------- 1292 o TLV Type: 6 (0x0006) 1294 o Length (2 octets), set to 4 + the length of the NLRI Data. 1296 o Address Family Identifier: This field carries the identity of 1297 the Network Layer protocol associated with the Network Address 1298 that follows. Presently defined values for this field are 1299 assigned by IANA [IANA-AFN]). 1301 o RESERVED: Set to 0. 1303 o Subsequent AFI: This field provides additional information 1304 about the type of the Network Layer Reachability Information 1305 carried in the attribute. Values for this field are defined in 1306 Section 5 of [RFC2858]. 1308 o NLRI Data: An address prefix as described in Section 4 of 1309 [RFC2858]. 1311 5.8 Signature (SIG) 1313 0 1 2 3 1314 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 1315 +-------------------------------+-------------------------------+ 1316 | TLV Type | Length | 1317 +-------------------------------+-------------------------------+ 1318 | Signature Type | Number of Issuers | 1319 +-------------------------------+-------------------------------+ 1320 | Entity Certificate Issuer Autonomous System | 1321 +-------------------------------+-------------------------------+ 1322 | Entity Certificate Serial Number | 1323 +-------------------------------+-------------------------------+ 1324 | ... | 1325 +---------------------------------------------------------------+ 1326 | Signature | 1327 +------------------ 1329 o TLV type: 7 (0x0007) 1331 o Length: (2 octets), unsigned integer denoting the length of the 1332 payload bytes which follow. 1334 o Signature Type: (2 octets), unsigned integer denoting the type 1335 of signature (the algorithm used to build this signature). Each 1336 possible signing algorithm is assigned an integer from this 1337 field. Signature type 1 is defined as an RSA encryption of a 1338 SHA1 digest using PKCS#1.5 padding. 1340 o Number of Issuers (2 octets): The number of Entitycert 1341 references included in the signature payload. If more than one 1342 Entitycert reference follows, all Entitycerts MUST contain the 1343 same public key for the same authorizing autonomous system. 1345 o Entity Certificate Issuer Autonomous System: (4 octets), the 1346 autonomous system of the entity that provided the Entitycert to 1347 the Authorizing AS. AS numbers containing only two octets 1348 should be placed in the least significant octets of this four- 1349 octet field (the two rightmost octets). 1351 o Entity Certificate Serial Number: (4 octets), the Entitycert 1352 serial number containing the public key of the Authorizing AS. 1354 o Signature: The signature itself. 1356 The signature is calculated by hashing the bytes of the certificate, 1357 beginning with the certificate header and ending at the byte just 1358 before the signature. The hashed data includes the Signature payload 1359 fields just prior to the signature field in the Signature payload. 1360 The hash is then encrypted using the private key of the authorizing 1361 entity.. 1363 5.9 Authorization Certificate (AUTHCERT) 1365 0 1 2 3 1366 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 1367 +-------------------------------+-------------------------------+ 1368 | TLV Type | Length | 1369 +-------------------------------+-------------------------------+ 1370 | Authorization Certificate | 1371 +---------------- 1373 o TLV type: 8 (0x0008) 1375 o Length: Set to the length of the Authorization Certificate. 1377 o Authorization Certificate. . 1379 This attribute allows a PrefixPolicycert to bind particular policy 1380 to the prefix block contained in an Authorization Certificate. One 1381 or more Authcert TLVs MUST be included in the PrefixPolicycert. 1383 5.10 Prefix Policies (P-POLICY) 1385 0 1 2 3 1386 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 1387 +-------------------------------+-------------------------------+ 1388 | TLV Type | Length | 1389 +-------------------------------+-------------------------------+ 1390 | Options | SubTVs 1391 +-------------------------------+-------------- 1393 o TLV type: 9 (0x0009) 1395 o Length: Set to the sum of the Options size (2) and the length 1396 of the SubTVs. 1398 o Options: (2 octets), a bit field describing various policies 1399 which should be applied to prefixes . 1401 o SubTVs: (variable length), zero or more fields, the length of 1402 which is determined by the type, as described below. 1403 This attribute is included in a PrefixPolicycert to bind particular 1404 policy to the prefixes contained in an Authcert. 1406 5.10.1 Option bits 1408 The options bit field describes policies that should be applied 1409 to the address prefix described in the TLV. These options are: 1411 o Bit 0: Path Check. If this bit is set, the receiver should not 1412 accept any prefix for which the path cannot be verified as 1413 described in the section Verifying the Path, below. 1415 o Bit 1: Second Hop Check. If this bit is set, the receiver 1416 should not accept any prefix for which the second entry in the 1417 AS PATH cannot be verified as described in the section 1418 Verifying the Second Hop, below. 1420 o Bits 2-15: Reserved for future use. 1422 5.10.2 SubTVs 1424 The Authcert Policy subTVs provide optional policy information for 1425 the block of addresses included in the Authcert indicated; each 1426 subTV is of a fixed length, as determined by its type. 1428 0 1 2 3 1429 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 1430 +-------------------------------+------------------------------+ 1431 | TV Type | Data.... 1432 +-------------------------------+------------------------- 1434 o TV Type: (2 octets), An unsigned integer indicating the type of 1435 subTV 1437 Types defined within this specification are: 1439 - Type 1: Must Include AS, 4 octets of data, an AS which must be 1440 included in the AS path of any prefix falling within this block 1441 of addresses. 1443 - Type 2: OR Include AS, 4 octets of data, at least one of the 1444 included OR Include AS' must be included in the AS path of any 1445 prefix falling within this block of addresses. 1447 - Type 3: MUST NOT INCLUDE AS, 4 octets of data, an AS which must 1448 not be included in the AS path of any prefix falling within 1449 this block of addresses 1451 - Type 4: Maximum Prefix Length, 1 octet of data, the maximum 1452 length of any prefix allowed within this block of prefixes. 1454 5.11 Attached Transit Autonomous Systems (TRANSIT) 1456 0 1 2 3 1457 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 1458 +-------------------------------+-------------------------------+ 1459 | TLV Type | Length | 1460 +-------------------------------+---------------+---------------+ 1461 | Address Family Identifier | RESERVED | Subsequent AFI | 1462 +-------------------------------+---------------+---------------+ 1463 | Autonomous Systems | 1464 +----------------- 1466 o TLV type: 4 (0x0004) 1468 o Length: Set to 4 + 4 octets for each autonomous system in the 1469 list. 1471 o Address Family Identifier: This field carries the identity a 1472 the Network Layer protocol. Presently defined values for this 1473 field are specified in RFC 1700 (see the Address Family Numbers 1474 section). 1476 o RESERVED: Set to 0. 1478 o Subsequent AFI: This field provides additional information 1479 about the type of the Network Layer protocol. 1481 o Autonomous Systems: List of autonomous systems which are 1482 connected to the originating autonomous system through some 1483 form of peering arrangement and which may transit traffic from 1484 the origin AS. Each AS number takes four octets. AS number 1485 values containing only two octets should be placed in the least 1486 significant octets of this four-octet field (the two rightmost 1487 octets). 1489 One or more Attached Transit AS TLVs may be included in the 1490 ASPolicycert . Each type 4 TLV indicates an AS which is connected to 1491 the AS which originates this ASPolicycert through a BGP peering 1492 relationship. 1494 5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT) 1495 0 1 2 3 1496 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 1497 +-------------------------------+-------------------------------+ 1498 | TLV Type | Length | 1499 +-------------------------------+---------------+---------------+ 1500 | Address Family Identifier | RESERVED | Subsequent AFI| 1501 +-------------------------------+---------------+---------------+ 1502 | Autonomous Systems | 1503 +------------------ 1505 o TLV type: 5 (0x0005) 1507 o Length: Set to 4 + 4 octets for each autonomous system in the 1508 list. 1510 o Address Family Identifier: This field carries the identity a 1511 the Network Layer protocol. Presently defined values for this 1512 field are specified in RFC 1700 (see the Address Family Numbers 1513 section). 1515 o RESERVED: Set to 0. 1517 o Subsequent AFI: This field provides additional information 1518 about the type of the Network Layer protocol. 1520 o Autonomous Systems: List of autonomous systems which are 1521 connected to the originating autonomous system through some 1522 form of peering arrangement and which may not transit traffic 1523 from the origin AS. Each AS number takes four octets. AS number 1524 values containing only two octets should be placed in the least 1525 significant octets of this four-octet field (the two rightmost 1526 octets). 1528 One or more Attached Non-Transit AS TLVs may be included in the 1529 ASPolicycert. Each type 5 TLV indicates an AS which is connected to 1530 the AS which originates this ASPolicycert through a BGP peering 1531 relationship. 1533 5.13 Revoked Entity Certificate List (EC-CRL) 1535 0 1 2 3 1536 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 1537 +-------------------------------+-------------------------------+ 1538 | TLV Type | Length | 1539 +-------------------------------+-------------------------------+ 1540 | Entity Certificate Revocation List 1541 +---------------- 1543 o TLV type: 6 (0x0006) 1544 o Length: (2 octets), length of TLV data (the list of revoked 1545 Entity Certificates) in octets 1547 o Entity Certificate Revocation List: A revocation list created 1548 by the autonomous system, which includes a list of revoked 1549 Entity Certificates issued by this autonomous system. The 1550 format of the revocation list MUST be as defined in [RFC3280]. 1552 A single Revoked Entity Certificate List TLV MAY be included in an 1553 ASPolicycert, or it may be omitted. 1555 When an Entity Certificate Revocation List is received, all 1556 currently held Entitycerts from this issuer MUST be checked against 1557 the CRL. Entitycerts found to be invalid MUST be deleted. 1559 5.14 Authorization Certificate Validity List (AC-VALID) 1561 0 1 2 3 1562 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 1563 +-------------------------------+-------------------------------+ 1564 | TLV Type | Length | 1565 +-------------------------------+-------------------------------+ 1566 | Validity Ranges 1567 +---------------- 1569 o TLV type: 7 (0x0007) 1571 o Length: (2 octets), length of TLV data (the list of revoked 1572 Authorization Certificates) in octets 1574 o Validity Ranges: A list of validity subTVs defining which 1575 serial numbers are valid and invalid. Validity ranges are 1576 interpreted in order until a match is found. For more 1577 information on validity lists, see Section 4.1.5. 1579 A single TLV of this type MAY be included in an ASPolicycert, or it 1580 may be omitted. 1582 When an Authorization Certificate Validity List is received, all 1583 currently held Authcerts from this issuer MUST be checked against 1584 the validity list. Authcerts found to be invalid MUST be deleted. 1586 5.14.1 Validity Ranges 1587 0 1 2 3 1588 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 1589 +-------------------------------+-------------------------------+ 1590 | subTV Type | Size of Range | 1591 +-------------------------------+-------------------------------+ 1592 | Lowest Authorization Serial Number | 1593 +---------------------------------------------------------------+ 1595 o subTV type: (2 octets). 1597 SubTV type Value 1598 ---------- ----- 1599 VALID 0 1600 INVALID 1 1602 o Size of Range: (2 octets). Number of contiguous serial numbers 1603 defining a range. 1605 o Lowest Authorization Serial Number (4 octets). The lowest value 1606 in the range. 1608 5.15 Prefix Policy Certificate Validity List (PPC-VALID) 1610 0 1 2 3 1611 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 1612 +-------------------------------+-------------------------------+ 1613 | TLV Type | Length | 1614 +-------------------------------+-------------------------------+ 1615 | Validity Ranges 1616 +---------------- 1618 o TLV type: 8 (0x0008) 1620 o Length: (2 octets), length of TLV data (the list of revoked 1621 Authorization Certificates) in octets 1623 o Validity Ranges: A list of validity subTVs (as defined in the 1624 previous section) defining which PrefixPolicycert serial 1625 numbers are valid and invalid. Validity ranges are interpreted 1626 in order until a match is found. 1628 A single TLV of this type MAY be included in an ASPolicycert, or it 1629 may be omitted. 1631 When an Prefix Policy Validity List is received, all currently held 1632 PrefixPolicycerts from this issuer MUST be checked against the 1633 validity list. PrefixPolicycerts found to be invalid MUST be 1634 deleted. 1636 6.0 Security Considerations 1638 This document describes the format of authentication, authorization, 1639 and policy certificates used with [SOBGP-BGP]. Each certificate type 1640 is digitally signed, and therefore requires no external protection 1641 to ensure its integrity. There are no restrictions on how they may 1642 be distributed. Revocation schemes are defined for all certificate 1643 types. 1645 The following sections describe the security considerations of each 1646 of those objects. 1648 6.1 Entitycerts 1650 Entitycerts provide authentication, providing a binding of an 1651 identity (i.e., autonomous system number) to a public key. The 1652 authenticity of the binding is verified with a digital signature, 1653 where the public key of the certificate issuer has been previously 1654 accepted as valid. Issuer public keys can either be manually 1655 configured, or are verified through the use of another issuer's 1656 trusted public key in a PKI. 1658 Certificate issuers MUST maintain certificate revocation lists 1659 (CRLs). Entities verifying Entitycerts SHOULD reference the 1660 certificate revocation lists whenever possible. (Mandating the 1661 consultation of a CRL as part of the verification process is not 1662 possible, because the CRL may not be available at the time 1663 verification is performed. For example, if the issuer maintains the 1664 CRL on a directory server to which routing is not yet setup.) 1665 Issuers SHOULD distribute their CRLs within their AS Policy 1666 Certificates to increase the likelihood of a receiver having the CRL 1667 available. 1669 Self-signed Entitycerts may be necessary in order to start a chain 1670 of trust. However self-signed Entitycerts MUST be manually validated 1671 as accurate before the enclosed public key is used; else the trust 1672 structure becomes meaningless. The use of self-signed Entitycerts 1673 accepted in the distributed PKI should be limited in order to 1674 maintain an orderly system. 1676 6.2 Authcerts 1678 Authcerts provide authorization, where the issuer of a prefix block 1679 certifies that it has given that prefix block to a specific 1680 autonomous system. Receivers use the Authcert to validate 1681 announcements received in BGP UPDATE messages. 1683 The authenticity of Authcerts is verified with a digital signature, 1684 where the public key of the certificate issuer is distributed in an 1685 Entitycert. Before a receiver can verify the Authcert, they MUST 1686 first check that the verifying Entitycert is authentic. 1688 The Authcert issuer MUST keep an Authcert validation list describing 1689 which certificates are valid, and which are invalid. The receivers 1690 of an Authcert SHOULD consult the Authcert validation list to ensure 1691 that the authorization has not been revoked. 1693 Autonomous systems may need to authorize their own use of prefix 1694 blocks if the autonomous system that issued their prefix blocks does 1695 not issue them an Authcert. However, such self-signed Authcerts are 1696 dangerous, since unrestricted use of self-signed Authcerts defeats 1697 the goal of authorization. Thus an entity MUST accept self-signed 1698 Authcerts only from autonomous systems that have been explicitly 1699 configured as trusted to claim authorization without the 1700 confirmation of a third party. Examples of such entities are 1701 Regional Internet Registries. 1703 6.3 PrefixPolicycerts 1705 PrefixPolicycerts bind policy generated by an autonomous system for 1706 prefix blocks that they advertise. This policy is bound to a 1707 particular Authcert, which verifies that they are authorized to 1708 advertise those prefix blocks. 1710 PrefixPolicycerts are verified with a digital signature, where the 1711 public key of the certificate issuer is distributed in an 1712 Entitycert. Before a receiver can verify the PrefixPolicycert, they 1713 MUST first verify that the verifying Entitycert is authentic. 1715 6.4 ASPolicycerts 1717 ASPolicycerts contain policy generated by an autonomous system, and 1718 contain policy about the autonomous system itself. The policy 1719 includes its neighbor autonomous systems, which can be used by other 1720 entities to validate valid inter-connections. The policy can also 1721 include revocation and validation lists (Authcert, 1722 PrefixPolicycert). 1724 ASPolicycerts are verified with a digital signature, where the 1725 public key of the certificate issuer is distributed in an 1726 Entitycert. Before a receiver can verify the ASPolicycerts, they 1727 MUST first verify that the verifying Entitycert is authentic. 1729 6.5 Entitycert Uniform Resource Locators 1731 Authcerts, PrefixPolicycerts, and ASPolicycerts may contain a URL 1732 that references the Entitycert used to validate it. Care should be 1733 taken in evaluating the URL since it is not yet known to be valid 1734 and could be used to propagate a denial of service attack. 1736 7.0 IANA Considerations 1738 This document defines three certificate types, each of which contains 1739 a series of TLVs. IANA is expected to maintain a registry of all the 1740 values defined, according to the following sections. 1742 7.1 soBGP Certificate Attribute Values 1744 The following Type values in soBGP certificate TLVs are to be defines 1745 as follows: 1747 o Type values 1 through 4, 14 and 65535 are assigned in this 1748 document. 1750 o Type values 5 through 13 and 15 through 16575 MUST be assigned 1751 using the "IETF Consensus" policy defined in RFC 2434 1752 [RFC2434]. 1754 o Type values 16576 through 32895 SHOULD be assigned using the 1755 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1757 o Type values 32896 through 65534 are for "Private Use" as defined 1758 in RFC 2434 [RFC2434]. 1760 7.2 Signature Type 1762 The Signature TLV Signature Type field: 1764 o Type values 1 is assigned in this document. 1766 o Type values 2 through 16575 MUST be assigned using the "IETF 1767 Consensus" policy defined in RFC 2434 [RFC2434]. 1769 o Type values 16576 through 32895 SHOULD be assigned using the 1770 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1772 o Type values 32896 through 65534 are for "Private Use" as defined 1773 in RFC 2434 [RFC2434]. 1775 7.3 Policies Type 1777 The Policies Type has two name spaces: Options flags and SubTVs. 1779 The Options Field: 1781 o Bits 0 and 1 are assigned in this document. 1783 o Bits 2 thru 7 MUST be assigned using the "IETF Consensus" 1784 policy defined in RFC 2434 [RFC2434]. 1786 o Bits 8 thru 15 are for "Private Use" as defined in RFC 2434 1787 [RFC2434]. 1789 The subTV TV Type field: 1790 o TV Type values 1 through 3 are assigned in this document. 1792 o TV Type values 4 through 16575 MUST be assigned using the "IETF 1793 Consensus" policy defined in RFC 2434 [RFC2434]. 1795 o TV Type values 16576 through 32895 SHOULD be assigned using the 1796 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1798 o TV Type values 32896 through 65534 are for "Private Use" as 1799 defined in RFC 2434 [RFC2434]. 1801 7.4 Validity Ranges 1803 o Type values 1 through 2 are assigned in this document. 1805 o Type values 3 through 16575 MUST be assigned using the "IETF 1806 Consensus" policy defined in RFC 2434 [RFC2434]. 1808 o Type values 16576 through 32895 SHOULD be assigned using the 1809 "Specification Required" policy defined in RFC 2434 [RFC2434]. 1811 o Type values 32896 through 65534 are for "Private Use" as defined 1812 in RFC 2434 [RFC2434]. 1814 8.0 Acknowledgments 1816 A large number of people contributed to or provided valuable feedback 1817 on this document; we've tried to include all of them here (in no 1818 particular order), but might have missed a few: James Ng, Russ White, 1819 Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, 1820 Max Pritikin, Chris Lonvick, Tim Gage, Scott Fanning, Barry Friedman, 1821 Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, 1822 Ed Lewis, Bora Akyol, and Jonathan Natale. 1824 9.0 References 1826 9.1 Normative References 1828 [IANA-AFN] http://www.iana.org/assignments/address-family-numbers 1830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1831 Requirement Level", BCP 14, RFC 2119, March 1997. 1833 [RFC2434] Narten, T., and H. Alvestrand,, "Guidelines for Writing an 1834 IANA Considerations Section in RFCs", RFC 2434, October 1998. 1836 [RFC2858] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1837 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1839 [RFC3279] Polk, T., et. al., " Algorithms and Identifiers for the 1840 Internet X.509 Public Key Infrastructure Certificate and Certificate 1841 Revocation List (CRL) Profile", RFC 3279, April 2002. 1843 [RFC3280] Housley, R., et. al., "Internet X.509 Public Key 1844 Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. 1846 [RFC3779] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP 1847 Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn- 1848 03.txt, RFC 3779, June 2004. 1850 [SOBGP-ARCH] White, R. (editor), "Architecture and Deployment 1851 Considerations for Secure Origin BGP (soBGP)", draft-white-sobgp- 1852 architecture-01.txt, Work in Progress, February 11, 2005. 1854 [SOBGP-BGP] Ng, J. (editor), "Extensions to BGP to Support Secure 1855 Origin BGP (soBGP)", draft-ng-sobgp-extensions-02.txt, Work in 1856 Progress, April 2004. 1858 [SOBGP-RADIUS] Lonvick, C., "RADIUS Attributes for soBGP Support", 1859 draft-lonvick-sobgp-radius-04.txt, Work in Progress, February 13, 1860 2004. 1862 [X.690] International Telecommunication Union, "ITU-T Recommendation 1863 X.660 Information Technology - ASN.1 encoding rules: Specification 1864 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and 1865 Distinguished Encoding Rules (DER), 1997. 1867 9.2 Informative References 1869 [RFC3281] Farrell, S., and R. Housley, " An Internet Attribute 1870 Certificate Profile for Authorization", RFC 3281, April 2002. 1872 [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on 1873 Security Considerations", RFC 3552, July 2003. 1875 Appendix A. Example Certificates 1877 This section contains several examples of soBGP certificates. The 1878 first example is an Entitycert, followed by an Authcert. 1880 A.1. Entitycert 1882 This section contains an annotated hex dump of an 862 byte 1883 Entitycert. In this example, AS 100 is a large ISP that has created a 1884 self-signed certificate. Because it is self-signed, AS 100 has placed 1885 its own identity in both the subjectAltName and issuerAltName. AS 100 1886 can now act as a Certificate Server for its customers. 1888 This certificate was processed using Peter Gutman's dumpasn1 utility 1889 (invoked with -ail flags) to generate the output. The source for the 1890 dumpasn1 utility is available at 1891 http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c. 1893 0 870: SEQUENCE { 1894 4 590: SEQUENCE { 1895 8 3: [0] { 1896 10 1: INTEGER 2 1897 : } 1898 13 9: INTEGER 00 98 3A 42 D0 83 4C 30 55 1899 24 13: SEQUENCE { 1900 26 9: OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1901 1 1 5) 1902 : (PKCS #1) 1903 37 0: NULL 1904 : } 1905 39 62: SEQUENCE { 1906 41 11: SET { 1907 43 9: SEQUENCE { 1908 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1909 : (X.520 id-at (2 5 4)) 1910 50 2: PrintableString 'US' 1911 : } 1912 : } 1913 54 19: SET { 1914 56 17: SEQUENCE { 1915 58 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) 1916 : (X.520 id-at (2 5 4)) 1917 63 10: PrintableString 'California' 1918 : } 1919 : } 1920 75 26: SET { 1921 77 24: SEQUENCE { 1922 79 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 1923 : (X.520 id-at (2 5 4)) 1924 84 17: PrintableString 'Sample Tier 1 ISP' 1925 : } 1926 : } 1927 : } 1928 103 30: SEQUENCE { 1929 105 13: UTCTime 18/02/2005 07:10:18 GMT 1930 120 13: UTCTime 18/02/2006 07:10:18 GMT 1931 : } 1932 135 62: SEQUENCE { 1933 137 11: SET { 1934 139 9: SEQUENCE { 1935 141 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1936 : (X.520 id-at (2 5 4)) 1937 146 2: PrintableString 'US' 1938 : } 1939 : } 1940 150 19: SET { 1941 152 17: SEQUENCE { 1942 154 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) 1943 : (X.520 id-at (2 5 4)) 1944 159 10: PrintableString 'California' 1945 : } 1946 : } 1947 171 26: SET { 1948 173 24: SEQUENCE { 1949 175 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 1950 : (X.520 id-at (2 5 4)) 1951 180 17: PrintableString 'Sample Tier 1 ISP' 1952 : } 1953 : } 1954 : } 1955 199 290: SEQUENCE { 1956 203 13: SEQUENCE { 1957 205 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 1958 : (PKCS #1) 1959 216 0: NULL 1960 : } 1961 218 271: BIT STRING, encapsulates { 1962 223 266: SEQUENCE { 1963 227 257: INTEGER 1964 : 00 BD 51 5E D0 01 BD CC A1 46 49 A3 F8 FC 81 07 1965 : 60 68 A3 E1 9E E4 38 4D CC 8E D5 B0 C8 FC 27 4F 1966 : 1D 63 8B 69 61 61 45 53 63 95 85 29 5B 9D 33 F5 1967 : E2 22 CF 3E CA A4 64 3F B9 01 44 B6 09 9C 6E 75 1968 : BF 9E E1 D5 67 23 AC 2C C9 99 A5 A6 CB DA 0A CE 1969 : 4F 60 93 E9 FF 1F 56 26 B2 3D 53 2A AE B2 F1 9D 1970 : 9F 4A DF AB 60 01 2D 5A 30 A2 BA D4 1E 98 34 47 1971 : 35 3E A2 F9 36 19 8C BE 86 22 3A F1 EB 9F D0 90 1972 : 86 6D 3B F4 0A 51 56 3D 5B 95 A6 43 C6 9B 04 E3 1973 : 0B 66 C3 82 F8 17 A8 54 57 E0 0D A9 58 17 E9 1A 1974 : EA 7E FA E6 1B 6B 8A 2A E1 2D 5B 2A 24 3B D0 1D 1975 : 87 5B BF B9 CF 48 42 04 57 A9 E1 64 6C 0A 6E 00 1976 : A4 1C A6 EA B2 F9 39 F8 76 48 4B 3C F0 AA 14 A1 1977 : 1D 44 83 76 F7 BC 8F A5 0D A9 76 A4 8F 00 3C BC 1978 : 1B 7D AC EE 94 BD D4 A9 AE 2C 99 3C D2 4F 71 E1 1979 : A8 32 CF A9 27 90 F7 18 A9 D5 23 83 09 73 47 FE 1980 : 55 1981 488 3: INTEGER 65537 1982 : } 1983 : } 1984 : } 1985 493 103: [3] { 1986 495 101: SEQUENCE { 1987 497 29: SEQUENCE { 1988 499 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 1989 : (X.509 id-ce (2 5 29)) 1990 504 22: OCTET STRING, encapsulates { 1991 506 20: OCTET STRING 1992 : FC 2B 62 B0 F0 20 80 BB 66 2F D3 B9 59 8B 0F E7 1993 : 9E 2C BC C4 1994 : } 1995 : } 1996 528 12: SEQUENCE { 1997 530 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 1998 : (X.509 id-ce (2 5 29)) 1999 535 5: OCTET STRING, encapsulates { 2000 537 3: SEQUENCE { 2001 539 1: BOOLEAN TRUE 2002 : } 2003 : } 2004 : } 2005 542 26: SEQUENCE { 2006 544 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 2007 : (X.509 id-ce (2 5 29)) 2008 549 19: OCTET STRING, encapsulates { 2009 551 17: SEQUENCE { 2010 553 15: [0] { 2011 555 8: OBJECT IDENTIFIER 2012 : bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) 2013 : (PKIX private extension) 2014 565 3: [0] { 2015 567 1: INTEGER 100 2016 : } 2017 : } 2018 : } 2019 : } 2020 : } 2021 570 26: SEQUENCE { 2022 572 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 2023 : (X.509 id-ce (2 5 29)) 2024 577 19: OCTET STRING, encapsulates { 2025 579 17: SEQUENCE { 2026 581 15: [0] { 2027 583 8: OBJECT IDENTIFIER 2028 : bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) 2029 : (PKIX private extension) 2030 593 3: [0] { 2031 595 1: INTEGER 100 2032 : } 2033 : } 2034 : } 2035 : } 2036 : } 2037 : } 2038 : } 2039 : } 2040 598 13: SEQUENCE { 2041 600 9: OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 2042 1 1 5) 2043 : (PKCS #1) 2044 611 0: NULL 2045 : } 2046 613 257: BIT STRING 2047 : 43 6A 45 03 E4 B7 FD 6B 57 9F 75 A5 F4 1F 63 73 2048 : 6C 27 33 2B 05 9B 16 17 D0 3B 1C 71 9C C0 34 EF 2049 : 49 64 D2 31 50 0C 65 FF 75 92 D4 A9 6A 88 FD 97 2050 : 3A ED 84 A2 47 49 B9 06 B4 0F 72 D4 56 DA 56 94 2051 : D1 5B 0E AD C2 61 FE 67 CB 44 05 55 3E BC D4 3F 2052 : C6 8E 32 EF F5 00 17 8C CB 31 37 1C C0 F3 EA E8 2053 : BD 81 8B D2 B6 AB 64 A2 49 C3 10 AE 50 35 35 BD 2054 : E9 5D 53 87 98 13 91 DC 7B 03 ED FB 87 BF F3 D1 2055 : 98 18 B4 A5 56 F5 D3 5D 97 7D F1 C0 FC 8A 77 3C 2056 : 1F 6B 50 06 59 2C 4A 93 A2 C0 57 E7 A3 33 2B DC 2057 : 98 41 E0 90 4E 29 5A 15 60 6A 72 D7 A0 87 14 3A 2058 : AB CE D9 69 C7 67 0C 89 DA 27 00 2E FC 6D F4 E0 2059 : 10 B1 1B 3C DA CA 6D AF 88 23 0B 02 52 4C BD 22 2060 : 12 BA 77 8B B6 40 CB C2 FE F8 32 6D CC B3 2F 6D 2061 : FF 0D E4 55 E8 2C A6 EC 66 12 86 D5 6B 3D F8 95 2062 : 1F E3 0A AB B0 33 35 AB 79 0B 79 BF 8E D4 FA 7D 2063 : } 2065 A.2. Authcert 2067 This section contains an annotated hex dump of a 183 byte Authcert. 2068 In this example, AS 101 has authorized AS 200 to use the prefix 2069 12.1/16. 2071 This certificate was processed using a special purpose utility to 2072 generate the output. 2074 0 183 : HEADER 2075 : CERTIFICATE MARKER 162 2076 : TYPE_ID 1 2077 4 8 : ATTRIBUTE TYPE 1 (Originating Autonomous System) 2078 : AS NUMBER 101 2079 12 8 : ATTRIBUTE TYPE 2 (Authorized Autonomous System) 2080 : AS NUMBER 200 2081 20 8 : ATTRIBUTE TYPE 3 (Serial Number) 2082 : SERIAL NUMBER 43 2083 28 11 : ATTRIBUTE TYPE 6 (Address Prefix) 2084 : AFI 1 SAFI 1 2085 : PREFIX 12.1/16 2086 39 144 : ATTRIBUTE TYPE 7 (Signature) 2087 : SIGNATURE TYPE 1 2088 : ISSUERS 2089 : ISSUER AS 101 2090 : ENTITYCERT SERIAL NUMBER 17 2091 : SIGNATURE 2092 : 29 0A 72 67 92 33 C7 62 62 AD 36 4A 45 D6 F2 F5 2093 : D1 1E 31 31 22 7F 7B 79 9F E7 99 02 2F F5 1F 06 2094 : 64 3C 22 C9 C9 FB EB 3B D7 86 CC DB 56 32 1C 7E 2095 : 86 A6 CD 0A 09 50 E2 AD 5A D9 66 39 EE 3D 27 10 2096 : 14 C3 BA 04 29 0C D0 95 26 08 D9 E6 AF E9 0C 33 2097 : D8 D6 BD D6 83 0E C2 2B A4 A5 B4 89 8C CA BC A2 2098 : BB A4 40 87 AF 50 02 53 2C FD 9A 83 78 64 DE DB 2099 : D4 BC 91 5C AB E9 7D BF 17 84 C9 34 A5 6D 3D 0D 2101 Editor's Address 2103 Brian Weis 2104 Cisco Systems 2105 170 W. Tasman Drive, 2106 San Jose, CA 95134-1706, USA 2107 (408) 526-4796 2108 bew@cisco.com 2110 Intellectual Property Statement 2112 The IETF takes no position regarding the validity or scope of any 2113 Intellectual Property Rights or other rights that might be claimed 2114 to pertain to the implementation or use of the technology 2115 described in this document or the extent to which any license 2116 under such rights might or might not be available; nor does it 2117 represent that it has made any independent effort to identify any 2118 such rights. Information on the procedures with respect to rights 2119 in RFC documents can be found in BCP 78 and BCP 79. 2121 Copies of IPR disclosures made to the IETF Secretariat and any 2122 assurances of licenses to be made available, or the result of an 2123 attempt made to obtain a general license or permission for the use 2124 of such proprietary rights by implementers or users of this 2125 specification can be obtained from the IETF on-line IPR repository 2126 at http://www.ietf.org/ipr. 2128 The IETF invites any interested party to bring to its attention 2129 any copyrights, patents or patent applications, or other 2130 proprietary rights that may cover technology that may be required 2131 to implement this standard. Please address the information to the 2132 IETF at ietf-ipr@ietf.org. 2134 Disclaimer of Validity 2136 This document and the information contained herein are provided on 2137 an 2138 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2139 REPRESENTS 2140 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2141 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2142 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2143 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2144 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2146 Copyright Statement 2148 Copyright (C) The Internet Society (2006). This document is subject 2149 to the rights, licenses and restrictions contained in BCP 78, and 2150 except as set forth therein, the authors retain all their rights. 2152 Acknowledgement 2154 Funding for the RFC Editor function is currently provided by the 2155 Internet Society.