Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
RFC 7909
Internet Engineering Task Force (IETF) R. Kisteleki
Request for Comments: 7909 RIPE NCC
Updates: 2622, 4012 B. Haberman
Category: Standards Track JHU APL
ISSN: 2070-1721 June 2016
Securing Routing Policy Specification Language (RPSL) Objects
with Resource Public Key Infrastructure (RPKI) Signatures
Abstract
This document describes a method that allows parties to
electronically sign Routing Policy Specification Language objects and
validate such electronic signatures. This allows relying parties to
detect accidental or malicious modifications of such objects. It
also allows parties who run Internet Routing Registries or similar
databases, but do not yet have authentication (based on Routing
Policy System Security) of the maintainers of certain objects, to
verify that the additions or modifications of such database objects
are done by the legitimate holder(s) of the Internet resources
mentioned in those objects. This document updates RFCs 2622 and 4012
to add the signature attribute to supported RPSL objects.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7909.
Kisteleki & Haberman Standards Track [Page 1]
RFC 7909 Securing RPSL June 2016
Copyright Notice
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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
Kisteleki & Haberman Standards Track [Page 2]
RFC 7909 Securing RPSL June 2016
1. Introduction
Objects stored in resource databases, like the RIPE DB, are generally
protected by an authentication mechanism: anyone creating or
modifying an object in the database has to have proper authorization
to do so, and therefore has to go through an authentication procedure
(provide a password, certificate, email signature, etc.). However,
for objects transferred between resource databases, the
authentication is not guaranteed. This means that when a Routing
Policy Specification Language (RPSL) object is downloaded from a
database, the consumer can reasonably claim that the object is
authentic if it was locally created, but cannot make the same claim
for an object imported from a different database. Also, once such an
Show full document text