rfc-8208

BGPsec Algorithms, Key Formats, and Signature Formats

S. Turner, O. Borchert
date2017-09 streamIETF areartg wgsidr statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc8208 doi10.17487/RFC8208
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure"). This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

obsoleted by

updates

Extracted elements (20)

design-rationale §1

BGPsec uses ECDSA P-256 rather than the RSA algorithm used in the rest of RPKI specifically to minimize the size of the protocol data exchanged between routers, since BGPsec signatures appear in every BGP UPDATE message propagated through the path.

bgp, routing, crypto, security

design-rationale §2

Hash algorithms are not identified independently in BGPsec certificates or UPDATE messages; they are represented by a combined OID (ecdsa-with-SHA256) or a single algorithm suite identifier byte, reducing overhead and simplifying negotiation.

bgp, routing, crypto

interoperability-note §1

This document updates RFC 7935 to add support for a different algorithm (ECDSA P-256) for BGPsec certificate requests, a different Subject Public Key Info format for BGPsec certificates, and different signature formats — all needed specifically for BGPsec speakers, while non-BGPsec RPKI components continue to use the RFC 7935 algorithms.

bgp, routing, crypto, pkix

normative-requirement §5 SHOULD

BGPsec profiles should be updated to specify future key sizes and algorithm requirements when appropriate to maintain acceptable cryptographic security. The recommended transition procedures are specified in RFC 6916.

bgp, routing, crypto, security

normative-requirement §3.1 MUST

ECPoint MUST be used to encode the certificate's subjectPublicKey field as specified in Section 2.2 of RFC 5480.

bgp, routing, crypto, pkix

normative-requirement §2 MUST

In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite identifier value 0x1 is included in the Signature_Block List's Algorithm Suite Identifier field.

bgp, routing, crypto

normative-requirement §3 MUST

The ECDSA private keys used to compute signatures for certificate requests and BGPsec UPDATE messages MUST come from the P-256 curve. The public key pair MUST use the uncompressed form.

bgp, routing, crypto, pkix

normative-requirement §2 MUST

The ecdsa-with-SHA256 OID MUST appear in the PKCS #10 signatureAlgorithm field or in the CRMF POPOSigningKey algorithm field, depending on the certificate request format generated.

bgp, routing, crypto, pkix

normative-requirement §2 MUST

The hash algorithm used in BGPsec MUST be SHA-256. Hash algorithms are not identified independently but are combined with the digital signature algorithm via OID.

bgp, routing, crypto, security

normative-requirement §3.1 MUST

The id-ecPublicKey OID MUST be used in the algorithm field of subjectPublicKeyInfo, with associated parameters value secp256r1, as specified in RFC 5480.

bgp, routing, crypto, pkix

normative-requirement §2 MUST

The signature algorithm used in BGPsec MUST be ECDSA with curve P-256. This applies to BGPsec routers requesting certificates, generating BGPsec UPDATE messages, and verifying BGPsec UPDATE messages.

bgp, routing, crypto, security

normative-requirement §4 MUST

The structure for the certification request's and BGPsec UPDATE message's signature field MUST be as specified in Section 2.2.3 of RFC 3279.

bgp, routing, crypto

protocol-element §1

BGPsec uses a different algorithm (ECDSA P-256) compared to the rest of the RPKI (which uses RSA), specifically to minimize the size of the protocol exchanged between routers. BGPsec certificates are differentiated from other RPKI certificates by the BGPsec Extended Key Usage defined in RFC 8209.

bgp, routing, crypto, pkix

protocol-element §3.2

Private key format for BGPsec Router Certificates is determined by local policy; this document does not mandate a specific format.

bgp, routing, crypto

protocol-element §3.1

The BGPsec Router Certificate subjectPublicKeyInfo contains two sub-fields: algorithm (AlgorithmIdentifier with id-ecPublicKey OID and secp256r1 parameters) and subjectPublicKey (ECPoint encoding of the uncompressed public key).

bgp, routing, crypto, pkix

registry §7

IANA created the 'BGPsec Algorithm Suite Registry' in the RPKI group. The one-octet identifier maps to a digest algorithm and signature algorithm pair. Value 0x1 is assigned to SHA-256/ECDSA P-256; 0x0 and 0xFF are reserved; 0x2-0xEF are unassigned. Future assignments require Standards Action.

bgp, routing, registry, crypto

security-consideration §6

The security considerations of RFC 3279, RFC 5480, RFC 6090, RFC 7935, and RFC 8209 apply to BGPsec certificates and certification requests. The security considerations of RFC 3279, RFC 6090, and RFC 8205 apply to BGPsec UPDATE messages. No new security considerations are introduced by this specification.

bgp, routing, security, crypto

wire-format §A.3

Each Signature Segment in a BGPsec Signature Block contains an SKI (Subject Key Identifier, 20 bytes), a two-octet Length field, and a DER-encoded ECDSA signature. In the examples, signatures are 72 bytes (DER-encoded ECDSA P-256).

bgp, routing, crypto

wire-format §7

The BGPsec Path Attribute Signature Block contains a one-octet Algorithm Suite Identifier field. Value 0x1 designates SHA-256 digest with ECDSA P-256 signature; 0x0 and 0xFF are reserved; 0x2-0xEF are unassigned.

bgp, routing, crypto

wire-format §A.3

The BGPsec Path Attribute uses type code 30 with flags 0x90 (Optional, Complete, Extended Length). The Secure Path segment is 6 bytes per AS, containing pCount (1 byte), Flags (1 byte), and AS number (4 bytes).

bgp, routing