RFC 7909

Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures

📅 published June 2016, from ietf

RFC 7909: Securing RPSL Objects with RPKI Signatures 💖

Title: Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures 🎀

Authors: R. Kisteleki (RIPE NCC) and B. Haberman (JHU APL) 🧚

Category: Standards Track, which means it's an Internet Standards Track document ✨

Date: June 2016 📅

Stream: Internet Engineering Task Force (IETF) 🌈

ISSN: 2070-1721 🦋

Updates: RFC 2622 and RFC 4012. This one doesn't list any Obsoletes, so it isn't replacing anything, just adding to those two. 💅

Abstract 🌸

Okay so this document describes a way for people to electronically sign Routing Policy Specification Language objects and then check those signatures. That means relying parties can catch accidental or malicious changes to these objects 🙈. It's also super useful for folks who run Internet Routing Registries or similar databases but don't yet have authentication (based on Routing Policy System Security) for the maintainers of certain objects. They can verify that additions or changes to those database objects are done by the legitimate holder(s) of the Internet resources mentioned in them 🔥. And it updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects. Iconic. 👑

Status of This Memo 📝

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841. 💜

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7909. 🔗

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date this document was published. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. ⚠️

Table of Contents 📑

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Signature Syntax and Semantics  . . . . . . . . . . . . . . .   4
  2.1.  General Attributes and Meta Information . . . . . . . . .   4
  2.2.  Signed Attributes . . . . . . . . . . . . . . . . . . . .   5
  2.3.  Storage of the Signature Data . . . . . . . . . . . . . .   6
  2.4.  Number Resource Coverage  . . . . . . . . . . . . . . . .   6
  2.5.  Validity Time of the Signature  . . . . . . . . . . . . .   6
3.  Signature Creation and Validation Steps . . . . . . . . . . .   6
  3.1.  Canonicalization  . . . . . . . . . . . . . . . . . . . .   6
  3.2.  Signature Creation  . . . . . . . . . . . . . . . . . . .   8
  3.3.  Signature Validation  . . . . . . . . . . . . . . . . . .   9
4.  Signed Object Types and Set of Signed Attributes  . . . . . .   9
5.  Keys and Certificates Used for Signature and Verification . .  11
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction 🌷

Okay, bestie, so objects stored in resource databases (like the RIPE DB) are usually protected by an authentication mechanism. Anyone creating or changing an object has to be properly authorized, which means going through an authentication step like a password, certificate, email signature, etc. 🔐 But for objects that get transferred between resource databases, the authentication isn't guaranteed 😭. So when an RPSL object gets downloaded from a database, the consumer can reasonably claim it's authentic if it was created locally. They can't make that same claim for an object imported from a different database. Also, once the object is downloaded, it's just a simple (but still structured) text file with no integrity protection at all. Even more important, the authentication and integrity guarantees attached to these objects don't always confirm that whoever generated them is actually allowed to make the claims in their data 💀.

Here's the plot twist: resource certificates [RFC6487] can be used to secure both imported and downloaded database objects. You put a digital signature over the object contents, instead of using methods like Routing Policy System Security [RFC2725] 💅. The signer of these signed database objects MUST possess a relevant resource certificate, which shows them as the legitimate holder of an Internet number resource 👑. This lets users of the objects verify that the contents really were produced by the legitimate holder(s) of the Internet resources mentioned in them. It also lets the signatures cover whole RPSL objects, or just selected attributes of them 🦋. So a digital signature made with the private key tied to a resource certificate can offer object security on top of the channel security already present in most resource databases. And object security means those objects can be hosted in different databases and still be independently verifiable. Main character energy. ✨

Just a heads up: the approach in this document mandates the use of the Resource Public Key Infrastructure (RPKI) for certificate distribution. But it's not dependent on the RPKI to work correctly. You can get equivalent functionality with a more traditional Certification Authority (CA), using the extensions described in [RFC3779] within the certificates, plus the right trust anchor material to verify the digital signature 🧚.

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📚

2. Signature Syntax and Semantics 🎀

When you sign an RPSL object [RFC2622] [RFC4012], the input for the signature process gets transformed into a sequence of strings of ASCII data. This is kind of like what's used in Domain Key Identified Mail (DKIM) [RFC6376] 💌. With RPSL, the object to be signed looks a lot like an SMTP header, so it makes total sense to borrow DKIM's relevant features. Lowkey genius. 🫶

2.1. General Attributes and Meta Information 💖

The digital signature for an RPSL object is itself a new attribute called signature. It has mandatory and optional fields 🍓. These fields are structured as a sequence of name and value pairs, separated by a semicolon ; and whitespace. Put together, these fields make up the value of the new signature attribute. The "name" part of each component is always a single ASCII character that works as an identifier. The value is an ASCII string whose contents depend on the field type. Mandatory fields MUST appear exactly once, whereas optional fields MUST appear at most once. 🔥

Here are the mandatory fields of the signature attribute ✨:

  • Version of the signature (field v): This field MUST be set to rpkiv1, and it MAY be the first field of the signature attribute to make parsing the attribute's fields easier. The signature format described in this document applies when the version field is set to rpkiv1. Everything else about the signature attribute is defined by the value of the version field 🌸.
  • Reference to the certificate corresponding to the private key used to sign this object (field c): The value of this field MUST be a URL of type rsync [RFC5781] or http(s) [RFC7230] that points to a specific resource certificate in an RPKI repository [RFC6481]. Any non URL-safe characters (including semicolon ; and plus +) must be URL encoded [RFC3986] 🔗.
  • Signature method (field m): This says which hash and signature algorithms were used to create the signature. This specification follows the algorithms defined in RFC 6485 [RFC6485]. The algorithms are referenced within the signature attribute by their ASCII names 🧪.
  • Time of signing (field t): The format of this field's value MUST be the Internet Date/Time ABNF format [RFC3339]. All times MUST be converted to Universal Coordinated Time (UTC), so the ABNF time-offset is always Z 🕰️.
  • The signed attributes (field a): This is a list of attribute names, separated by an ASCII + character if more than one attribute is listed. The list must include any attribute at most once 📋.
  • The signature itself (field b): This MUST be the last field in the list. The signature is the output of the signature algorithm, using the appropriate private key and the calculated hash value of the object as inputs. The value of this field is the digital signature in base64 encoding (Section 4 of [RFC4648]) 💅.

Here are the optional fields of the signature attribute 🧁:

  • Signature expiration time (field x): The format of this field's value MUST be the Internet Date/Time format [RFC3339]. All times MUST be represented in UTC 🌙.

2.2. Signed Attributes 🦋

You can look at an RPSL object as an (ordered) set of attributes, where each one has a key: value syntax. Understanding this structure can help in developing more flexible methods for applying digital signatures 🧩.

Some of these attributes get added automatically by the database, some depend on the database, and others don't carry anything operationally important. This specification lets the maintainer of an object decide which attributes are important (signed) and which are not (unsigned), from among all the attributes of the object. In other words, it defines a way to include the important attributes while leaving out the irrelevant ones 🎯. Letting the maintainer pick which attributes the digital signature covers is how it meets the goals set out in Section 1. Iykyk. 💜

The type of the object determines the minimum set of attributes that MUST be signed. The signer MAY choose to sign additional attributes too, to give those attributes integrity protection as well 🫶.

When verifying an object's signature, the verifier has to check whether the signature itself is valid, and whether all the specified attributes are referenced in the signature. If they aren't, the verifier MUST reject the signature and treat the object as a regular, unsigned RPSL object 💀.

2.3. Storage of the Signature Data

Okay so, applying the signature mechanism once gives you exactly one new attribute on the object 💖 Here's what a signed RPSL object looks like, bestie:

     attribute1:  value1
     attribute2:  value2
     attribute3:  value3
     ...
     signature:   v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;
                  t=2014-12-31T23:59:60Z;
                  a=attribute1+attribute2+attribute3+...;
                  b=<base64 data>

2.4. Number Resource Coverage

Okay, this one is so important 😭 A signature can be totally valid and still be irrelevant to the object. It also has to actually cover the Internet number resources the object is about. Not me getting a perfectly valid signature that doesn't even match the thing it's stuck to 💀

So, the Internet number resources in the [RFC3779] extensions of the certificate named in the "c" field of the signature MUST cover the resources in the object's primary key. Think aut-num: for an aut-num object, inetnum: for an inetnum object, route: and origin: for a route object, and so on 🌸

2.5. Validity Time of the Signature

The validity time interval of a signature is where these overlap: the validity time of the certificate used to verify the signature, the "not before" time from the t field of the signature, and the optional "not after" time from the x field of the signature. Main character energy for time windows 🦋

When you're checking multiple signatures, each one gets these checks individually ✨

3. Signature Creation and Validation Steps 🎀

3.1. Canonicalization

Canonicalization is the bestie who makes sure everyone's version of the data looks the same before the signature check happens 💅 It's essential whenever the data's representation can change between the signer and one or more signature verifiers. It turns a representation of data into a series of bits for signing and verifying. Its whole job is to smooth out irrelevant differences in representations of the same object, because otherwise verification would fail for no good reason 🫶

Examples of those differences:

  • data transformations applied by the databases that host these objects (such as notational changes for IPv4/IPv6 prefixes, automatic addition/modification of "changed" attributes, etc.)
  • the difference of line terminators across different systems

So yeah, the destination database might change parts of the submitted data after it was signed, and that would make verification fail. This document specifies strict canonicalization rules to fix that 🔥

The following steps MUST be applied in order to get the canonicalized representation of an object, before the actual signature (verification) process can begin 👑

  1. Comments (anything beginning with a #) MUST be omitted.
  2. Any trailing whitespace MUST be omitted.
  3. A multi-line attribute MUST be converted into its single-line equivalent. Here's how:
    • Convert all line endings to a single blank space (ASCII code 32).
    • Concatenate all lines into a single line.
    • Replace the trailing blank space with a single new line ("\n", ASCII code 10).
  4. Numerical fields MUST be converted to canonical representations. That includes:
    • Date and time fields MUST be converted to UTC and MUST be represented in the Internet Date/Time format [RFC3339].
    • AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
    • IPv6 addresses MUST be canonicalized as defined in [RFC5952].
    • IPv4 addresses MUST be represented as the ipv4-address type defined by RPSL [RFC2622].
    • All IP prefixes (IPv4 and IPv6) MUST be represented in Classless Inter-Domain Routing (CIDR) notation [RFC4632].
  5. All ranges, lists, or sets of numerical fields are represented using the appropriate RPSL attribute, and each numerical element inside those attributes MUST conform to the canonicalization rules in this document. The ordering of values within such fields MUST be maintained during database transfers ✨
  6. The name of each attribute MUST be converted into lower case, and MUST be kept as part of the attribute line.
  7. Tab characters ("\t", ASCII code 09) MUST be converted into spaces.
  8. Multiple whitespaces MUST be collapsed into a single space (" ", ASCII code 32) character.
  9. All line endings MUST be converted into a single new line ("\n", ASCII code 10) character, which avoids CR vs. CRLF differences 🌈

3.2. Signature Creation

Okay, so you've got an RPSL object and its matching certificate, and you want to make the digital signature. The following steps MUST be performed 💜

  1. Create a list of attribute names for the attributes that will be signed (the contents of the "a" field). The minimum set of these is determined by the object type, and the signer MAY select additional attributes 🧚
  2. Arrange the selected attributes in the selection sequence given in the "a" field, omitting every attribute that won't be signed.
  3. Construct the new "signature" attribute with all its fields, leaving the value of the "b" field empty.
  4. Apply the canonicalization rules to the result, including the "signature" attribute.
  5. Create the signature over the results of canonicalization, using the signature and hash algorithms named in the "m" field of the signature attribute.
  6. Insert the base64-encoded value of the signature as the value of the "b" field.
  7. Append the resulting "signature" attribute to the original object 🍓

3.3. Signature Validation

To validate a signature over an object like this, the following steps MUST be performed 🔍

  1. Verify the syntax of the "signature" attribute. Check that it has the mandatory and optional components, and that the syntax of those fields matches the specification in Section 2.1.
  2. Fetch the certificate named in the "c" field of the "signature" attribute, and check its validity using the steps in [RFC6487].
  3. Extract the list of signed attributes from the "a" field of the "signature" attribute.
  4. Verify that the list of signed attributes includes the minimum set of attributes for that object type.
  5. Arrange the selected attributes in the selection sequence given in the value of the "a" field, omitting all unsigned attributes.
  6. Replace the value of the signature field "b" of the "signature" attribute with an empty string.
  7. Apply the canonicalization procedure to the selected attributes, including the "signature" attribute.
  8. Check the validity of the signature using the signature algorithm named in the "m" field of the signature attribute, the public key in the certificate named in the "c" field of the signature, the signature value in the "b" field of the signature attribute, and the output of the canonicalization process 💖

4. Signed Object Types and Set of Signed Attributes 🦋

This section lists the object types that MAY be signed using this approach. For each object type, it also enumerates the set of attributes that MUST be signed (the minimum set mentioned in Section 3.3) 🌸

This list mostly leaves out attributes used to keep referential integrity in the databases that carry these objects. Those usually only make sense inside that database, while the scope of a signature is just one specific object. Attributes in the referred object (like mnt-by, admin-c, tech-c, etc.) can change without touching the signed object at all. Signing them could give a false sense of security about the signed data, so including them should only happen to provide full integrity protection of the object itself 🙈

The newly constructed "signature" attribute is always included in the list. The signature under construction MUST NOT include signature attributes that are already present in the object 🔥

      as-block:

      *  as-block

      *  signature

      aut-num:

      *  aut-num
      *  as-name
      *  member-of
      *  import
      *  mp-import
      *  export
      *  mp-export
      *  default
      *  mp-default
      *  signature

      inet[6]num:

      *  inet[6]num
      *  netname
      *  country
      *  status
      *  signature
      route[6]:

      *  route[6]
      *  origin
      *  holes
      *  member-of
      *  signature

Heads up, though: this approach has a limitation with route[6] objects. This document only supports a single signature per object. That means you can't properly sign a route[6] object where one resource holder has the Autonomous System Number (ASN) and a different resource holder has the referenced prefix. A future version of this specification may resolve this limitation 😤

For each signature, the extension described in RFC 3779 that appears in the certificate used to verify the signature MUST include a resource entry that is equivalent to, or covers (i.e., is "less specific" than), the following resources mentioned in the object the signature is attached to:
  • For the as-block object type: the resource in the "as-block" attribute.
  • For the aut-num object type: the resource in the "aut-num" attribute.
  • For the inet[6]num object type: the resource in the "inet[6]num" attribute.
  • For the route[6] object type: the resource in the "route[6]" or "origin" (or both) attributes.

5. Keys and Certificates Used for Signature and Verification 🌈

The certificate referred to in the signature (in the "c" field) has to follow some strict rules, bestie 👑

  • It MUST be an end-entity (i.e., non-CA) certificate.
  • It MUST conform to the X.509 PKIX Resource Certificate profile [RFC6487].
  • It MUST have the extension described in RFC 3779 that covers the Internet number resource included in a signed attribute [RFC3779].

The certificate generated will leave out the Subject Information Access (SIA) extension that RFC 6487 mandates 💀 That's because that extension requires an rsync URI for the accessLocation form, and RPSL doesn't currently support database access via rsync 🫶

6. Security Considerations 🔒

okay bestie, let's talk security 💅 RPSL objects stored in the Internet Routing Registry (IRR) databases are public, so there's literally no need for confidentiality 🙈 Each signed RPSL object can have its integrity and authenticity checked using the supplied digital signature and the referenced certificate ✨

Since the RPSL signature approach leverages X.509 extensions, the security considerations in [RFC3779] apply here as well 🎀 Implementers MUST follow the certificate validation steps described in RFC 6487 🚨 no skipping, periodt 💀

The maintainer of an object can add attributes to the signature that aren't in the resource certificate used to create the signature 👀 That means a maintainer could potentially include attributes that reference resources they aren't authorized to use. Yikes 😬

It should be noted that this digital signature does not preclude monkey-in-the-middle attacks where the adversary either intercepts RPSL object transfers, deletes the signature attribute, modifies the contents, or intercepts the transfer and drops the objects destined for the requester 😭 The signature alone doesn't stop someone in the middle from messing with things, so keep that in mind 🫠

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors would like to acknowledge the valued contributions from Jos Boumans, Tom Harrison, Steve Kent, Sandra Murphy, Magnus Nystrom, Alvaro Retana, Sean Turner, Geoff Huston, and Stephen Farrell in preparation of this document 💖 Such a squad 👑

Authors' Addresses 💌

Robert Kisteleki
RIPE NCC

Email: robert@ripe.net
URI:   http://www.ripe.net


Brian Haberman
Johns Hopkins University Applied Physics Lab

Email: brian@innovationslab.net
📦 where this page comes from