< draft-ietf-sidr-rpsl-sig-06.txt   draft-ietf-sidr-rpsl-sig-07.txt >
SIDR R. Kisteleki SIDR R. Kisteleki
Internet-Draft RIPE NCC Internet-Draft RIPE NCC
Intended status: Standards Track B. Haberman Intended status: Standards Track B. Haberman
Expires: May 30, 2015 JHU APL Expires: November 12, 2015 JHU APL
November 26, 2014 May 11, 2015
Securing RPSL Objects with RPKI Signatures Securing RPSL Objects with RPKI Signatures
draft-ietf-sidr-rpsl-sig-06.txt draft-ietf-sidr-rpsl-sig-07.txt
Abstract Abstract
This document describes a method to allow parties to electronically This document describes a method to allow parties to electronically
sign RPSL-like objects and validate such electronic signatures. This sign RPSL-like objects and validate such electronic signatures. This
allows relying parties to detect accidental or malicious allows relying parties to detect accidental or malicious
modifications on such objects. It also allows parties who run modifications on such objects. It also allows parties who run
Internet Routing Registries or similar databases, but do not yet have Internet Routing Registries or similar databases, but do not yet have
RPSS-like authentication of the maintainers of certain objects, to RPSS-like authentication of the maintainers of certain objects, to
verify that the additions or modifications of such database objects verify that the additions or modifications of such database objects
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3 2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3
2.1. General Attributes, Meta Information . . . . . . . . . . 3 2.1. General Attributes, Meta Information . . . . . . . . . . 3
2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5 2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 4
2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5 2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5
2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 6 2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5
2.5. Validity Time of the Signature . . . . . . . . . . . . . 6 2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
3. Signature Creation and Validation Steps . . . . . . . . . . . 6 3. Signature Creation and Validation Steps . . . . . . . . . . . 6
3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6 3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8 3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9 3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10 4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10
5. Keys and Certificates used for Signature and Verification . . 12 5. Keys and Certificates used for Signature and Verification . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Objects stored in resource databases, like the RIPE DB, are generally Objects stored in resource databases, like the RIPE DB, are generally
protected by an authentication mechanism: anyone creating or protected by an authentication mechanism: anyone creating or
modifying an object in the database has to have proper authorization modifying an object in the database has to have proper authorization
to do so, and therefore has to go through an authentication procedure to do so, and therefore has to go through an authentication procedure
(provide a password, certificate, e-mail signature, etc.) However, (provide a password, certificate, e-mail signature, etc.) However,
for objects transferred between resource databases, the for objects transferred between resource databases, the
authentication is not guaranteed. This means when downloading an authentication is not guaranteed. This means when downloading an
skipping to change at page 3, line 46 skipping to change at page 3, line 46
pairs, separated by a semicolon ";" and a white space. Collectively pairs, separated by a semicolon ";" and a white space. Collectively
these fields make up the value for the new "signature" attribute. these fields make up the value for the new "signature" attribute.
The "name" part of such a component is always a single ASCII The "name" part of such a component is always a single ASCII
character that serves as an identifier; the value is an ASCII string character that serves as an identifier; the value is an ASCII string
the contents of which depend on the field type. Mandatory fields the contents of which depend on the field type. Mandatory fields
must appear exactly once, whereas optional fields MUST appear at most must appear exactly once, whereas optional fields MUST appear at most
once. once.
Mandatory fields of the "signature" attribute: Mandatory fields of the "signature" attribute:
1. Version number of the signature (field "v"). This field MUST be o Version number of the signature (field "v"). This field MUST be
set to "1". set to "1".
2. Reference to the certificate corresponding to the private key o Reference to the certificate corresponding to the private key used
used to sign this object (field "c"). This is a URL of type to sign this object (field "c"). This is a URL of type "rsync" or
"rsync" or "http(s)" that points to a specific resource "http(s)" that points to a specific resource certificate in an
certificate in an RPKI repository. The value of this field MUST RPKI repository [RFC6481]. The value of this field MUST be an
be an "rsync://..." or an "http[s]://..." URL. Any non URL-safe "rsync://..." or an "http[s]://..." URL. Any non URL-safe
characters (including semicolon ";" and plus "+") must be URL characters (including semicolon ";" and plus "+") must be URL
encoded. encoded.
3. Signature method (field "m"): what hash and signature algorithms o Signature method (field "m"): what hash and signature algorithms
were used to create the signature. The allowed algorithms which were used to create the signature. The allowed algorithms which
can be used for the signature are specified in [RFC6485]. can be used for the signature are specified in [RFC6485].
4. Time of signing (field "t"). The format of the value of this o Time of signing (field "t"). The format of the value of this
field is the number of seconds since Unix EPOCH (00:00:00 on field is the number of seconds since Unix EPOCH (00:00:00 on
January 1, 1970 in the UTC time zone). The value is expressed as January 1, 1970 in the UTC time zone). The value is expressed as
the decimal representation of an unsigned integer. the decimal representation of an unsigned integer.
5. The signed attributes (field "a"). This is a list of attribute o The signed attributes (field "a"). This is a list of attribute
names, separated by an ASCII "+" character (if more than one names, separated by an ASCII "+" character (if more than one
attribute is enumerated). The list must include any attribute at attribute is enumerated). The list must include any attribute at
most once. most once.
6. The signature itself (field "b"). This MUST be the last field in o The signature itself (field "b"). This MUST be the last field in
the list. The signature is the output of the signature algorithm the list. The signature is the output of the signature algorithm
using the appropriate private key and the calculated hash value using the appropriate private key and the calculated hash value of
of the object as inputs. The value of this field is the digital the object as inputs. The value of this field is the digital
signature in base64 encoding [RFC4648]. signature in base64 encoding [RFC4648].
Optional fields of the "signature" attribute: Optional fields of the "signature" attribute:
1. Signature expiration time (field "x"). The format of the value o Signature expiration time (field "x"). The format of the value of
of this field is the number of seconds since Unix EPOCH (00:00:00 this field is the number of seconds since Unix EPOCH (00:00:00 on
on January 1, 1970 in the UTC time zone). The value is expressed January 1, 1970 in the UTC time zone). The value is expressed as
as the decimal representation of an unsigned integer. the decimal representation of an unsigned integer.
2. Reference(s) to other party's certificate(s) (field "o"). If
such certificates are mentioned (referred to) in any signature,
then this signature should be considered valid only in case when
there are other signatures over this current object, and these
other signatures refer to, and can be verified with, the
certificates mentioned in this field. This mechanism allows
having multiple signatures over an object in such a way that all
of these signatures have to be present and valid for the whole
signature to be considered valid. This would allow
interdependent multi-party signatures over an object. One
applications for such a mechanism include the case of a route[6]
object, where both the prefix owner's and the AS owner's
signature is expected (if they are different parties). The value
of this field MUST be a list of "rsync://..." or "http[s]://..."
URLs. If there are more such reference URLs, then they must be
separated with a plus "+" sign. Any non URL-safe characters
(including semicolon ";" and plus "+") must be URL encoded in all
such URLs.
2.2. Signed Attributes 2.2. Signed Attributes
One can look at an RPSL object as an (ordered) set of attributes, One can look at an RPSL object as an (ordered) set of attributes,
each having a "key: value" syntax. Understanding this structure can each having a "key: value" syntax. Understanding this structure can
help in developing more flexible methods for applying digital help in developing more flexible methods for applying digital
signatures. signatures.
Some of these attributes are automatically added by the database, Some of these attributes are automatically added by the database,
some are database-dependent, yet others do not carry operationally some are database-dependent, yet others do not carry operationally
skipping to change at page 7, line 5 skipping to change at page 6, line 32
The notion of canonicalization is essential to digital signature The notion of canonicalization is essential to digital signature
generation and validation whenever data representations may change generation and validation whenever data representations may change
between a signer and one or more signature verifiers. between a signer and one or more signature verifiers.
Canonicalization defines how one transforms an a representation of Canonicalization defines how one transforms an a representation of
data into a series of bits for signature generation and verification. data into a series of bits for signature generation and verification.
The task of canonicalization is to make irrelevant differences in The task of canonicalization is to make irrelevant differences in
representations of the same object, which would otherwise cause representations of the same object, which would otherwise cause
signature verification to fail. Examples of this could be: signature verification to fail. Examples of this could be:
1. data transformations applied by the databases that host these o data transformations applied by the databases that host these
objects (such as notational changes for IPv4/IPv6 prefixes, objects (such as notational changes for IPv4/IPv6 prefixes,
automatic addition/modification of "changed" attributes, etc.) automatic addition/modification of "changed" attributes, etc.)
2. the difference of line terminators across different systems. o the difference of line terminators across different systems.
This means that the destination database might change parts of the This means that the destination database might change parts of the
submitted data after it was signed, which would cause signature submitted data after it was signed, which would cause signature
verification to fail. This document specifies strict verification to fail. This document specifies strict
canonicalization rules to overcome this problem. canonicalization rules to overcome this problem.
The following steps MUST be applied in order to achieve canonicalized The following steps MUST be applied in order to achieve canonicalized
representation of an object, before the actual signature representation of an object, before the actual signature
(verification) process can begin: (verification) process can begin:
skipping to change at page 13, line 45 skipping to change at page 13, line 26
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
Autonomous System (AS) Numbers", RFC 5396, December 2008. Autonomous System (AS) Numbers", RFC 5396, December 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
February 2012.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)", RFC Use in the Resource Public Key Infrastructure (RPKI)", RFC
6485, February 2012. 6485, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February X.509 PKIX Resource Certificates", RFC 6487, February
2012. 2012.
Authors' Addresses Authors' Addresses
 End of changes. 17 change blocks. 
63 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/