[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-sidr-rpsl-sig

SIDR                                                        R. Kisteleki
Internet-Draft                                                  RIPE NCC
Intended status: Standards Track                              J. Boumans
Expires: April 30, 2009                                          RIPENCC
                                                        October 27, 2008


               Securing RPSL Objects with RPKI Signatures
                  draft-kisteleki-sidr-rpsl-sig-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 30, 2009.

Abstract

   This document describes a method to allow parties to electronically
   sign RPSL-like objects and validate such electronic signatures.  This
   allows relying parties to detect accidental or malicious
   modifications on such objects.  It also allows parties who run
   Internet Routing Registries or similar databases, but do not yet have
   RPSS-like authentication 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.





Kisteleki & Boumans      Expires April 30, 2009                 [Page 1]


Internet-Draft                Securing RPSL                 October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Meaning of a signature . . . . . . . . . . . . . . . . . . . .  3
   3.  Actual Implementation, Syntax of a Signature . . . . . . . . .  3
     3.1.  General Attributes, Meta Information of a Signature  . . .  4
     3.2.  Selecting attributes-to-be-signed  . . . . . . . . . . . .  5
     3.3.  Normalization  . . . . . . . . . . . . . . . . . . . . . .  6
       3.3.1.  Internal Normalizations in Databases . . . . . . . . .  6
       3.3.2.  Normalization in Terms of an Electronic Signature  . .  7
     3.4.  Storage of the Signature Data  . . . . . . . . . . . . . .  7
   4.  Signature creation and validation steps  . . . . . . . . . . .  8
   5.  Signed Object Types, Minimum Set of Signed Attributes  . . . .  9
   6.  Keys and Certificates used for Signature and Verification  . . 10
   7.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12































Kisteleki & Boumans      Expires April 30, 2009                 [Page 2]


Internet-Draft                Securing RPSL                 October 2008


1.  Introduction

   Objects issued by 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, therefore has to go through an authentication procedure
   (provide a password, certificate, e-mail signature, etc.)  However,
   for objects transferred between resource databases, like for example
   AS Numbers, the authentication is not guaranteed.  This means when
   one downloads an object issued from this database, one can reasonably
   safely claim that the object is valid, but for an imported object one
   can not.  Also, once such an object is downloaded from the database,
   it becomes a simple (but still structured) text file with no
   integrity protection.

   A potential usage for resource certificates could be to use them to
   secure such (both imported and downloaded) database objects, by
   applying a form of electronic signature over the object contents.
   Maintainers of such signed database objects should have their
   relevant resource certificate, which shows them as the legitimate
   holder of an Internet number resource.  This would allow for the
   users of such database objects to verify that the contents are in
   fact produced by the legitimate holder(s) of the legitimate holder(s)
   of the Internet resources mentioned in those objects.

   In other words, electronic signatures created using resource
   certificates can introduce object security in addition to the channel
   security already present in most of such databases.


2.  Meaning of a signature

   By signing an RPSL object, the signer of the object expresses that:
   o  they have the right to use the resource that the object refers to
      (ie. found as the primary key or in some other field of the
      object);
   o  they are responsible for the contents of the object; and
   o  they understand and agree with the contents of the object, up to
      the extend of the signed parts.


3.  Actual Implementation, Syntax of a Signature

   When signing an RPSL object, the input for the signature process is
   treated as a well-structured piece of information.  The approach is
   similar to the one used in DKIM (Domain Key Identified Mail)
   [RFC4871].  In RPSL's case, the object-to-be-signed closely resembles
   an SMTP header, so it seems reasonable to adapt DKIM's relevant



Kisteleki & Boumans      Expires April 30, 2009                 [Page 3]


Internet-Draft                Securing RPSL                 October 2008


   features.

3.1.  General Attributes, Meta Information of a Signature

   The actual signature over such an object is itself a new attribute.
   It has a proposed attribute name "signature" and its contents consist
   of mandatory and optional fields.  These fields are structured in a
   sequence of name=value pairs, separated by a semicolon ";" and a
   white space except for the last field, which is not followed by this.
   Collectively these fields make up the value for the new "signature"
   attribute.  The "name" part of such a component is always a single
   ASCII character identifier, whereas 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.

   Mandatory fields of the "signature" attribute:

   1.  Version number of the signature (field "v").  This field
       currently MUST be set to "1".

   2.  Reference to the certificate corresponding to the private key
       used by the signer to sign this object (field "c").  This is a
       URL of type "rsync" or "http(s)" that points to a specific
       resource certificate in an RPKI repository.  Inclusion of the
       certificate itself would have several drawbacks; the reference
       gives much more flexibility.  The value of this field MUST be an
       "rsync://..." or an "http[s]://..."  URL.

   3.  Signature method: what hash and signature and what crypto
       algorithm is/was used to create the signature (field "m").  The
       value of this field MUST be set to "rsa-sha1" or "rsa-sha256".
       Software for signature creation and/or validation must understand
       both algorithms.

   4.  Time of signing according to the signer's clock (field "t").  The
       format of the value of this 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 the decimal representation of an
       unsigned integer.

   5.  The signed attributes (field "a").  This is a list of attribute
       names, separated by an ASCII "+" character if there are more than
       one attributes mentioned.  The list must only include any
       attribute at most once.

   6.  The signature itself (field "b").  This MUST be the last field in
       the list.  The signature is the output of the signature algorithm
       used over the PKCS#1 version 1.5 (RFC3447) padded hash value over



Kisteleki & Boumans      Expires April 30, 2009                 [Page 4]


Internet-Draft                Securing RPSL                 October 2008


       the input.  The value of this field is the base64 encoded value
       of the signature.

   Optional fields of the "signature" attribute:

   1.  Signature expiration time (field "x").  The format of the value
       of this 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 the decimal representation of an unsigned integer.

   2.  [Yet to be decided] 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
       application for such a mechanism can be 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.

3.2.  Selecting attributes-to-be-signed

   One can look at an RPSL object as an (ordered) set of attributes,
   each having a "key: value" syntax.  Understanding this structure can
   help in developing more flexible methods for applying electronic
   signatures.

   Some of these attributes are automatically added by the database,
   some are database-dependent, yet others do not carry operationally
   important information.  Therefore it seems reasonable to define which
   attributes are actually signed and which are not; in other words, we
   define a way of including important attributes while excluding some
   irrelevant ones.  Selecting such attributes and creating an
   electronic signature exclusively over these attributes provides a
   reasonable approach for this.

   The signer can pick which attributes are signed and in which order.
   The selection of the attributes carries operational value, while the
   order is an important detail needed for consistent signature



Kisteleki & Boumans      Expires April 30, 2009                 [Page 5]


Internet-Draft                Securing RPSL                 October 2008


   verification.  This approach can accommodate local policies (e.g.
   some maintainers would want to sign 'remark' attributes too if they
   contain contact information, while others would not want this).
   Also, if there are new attributes added to an object type in the
   future, or even completely new object types are introduced, then the
   signature software components can easily be configured to deal with
   them.

   A drawback of this approach is that the verifier not only has to
   check whether the signature itself is valid, but also has to check if
   the signed attributes contain everything that the verifier deems
   important.  For example, the signer might have decided that the
   "origin" attribute is not signed, while the verifier's policy states
   that these attributes must be signed.  In this case the verifier
   would reject the signature, which would render object as such less
   trusted in the verifier's eyes.

3.3.  Normalization

3.3.1.  Internal Normalizations in Databases

   Normalization defines how one transforms an object-to-be-signed into
   a series of bits that can be signed (fed into a hash algorithm, the
   result into a signature algorithm, etc).  The task of normalization
   is to hide away differences over various representations of the same
   object, which would otherwise result in invalid signatures, even
   though the important bits do not differ in two different
   representations.  An example of this could be the difference of line
   terminators across different systems.

   Because of database consistency rules and database operational
   reasons several database use internal normalization techniques that
   can change the format and/or actual content of some of the signed
   fields.  Examples include:
   o  Representation of IPv6 addresses: always use the long form over
      the short form.
   o  Representation of IPv4 prefixes: use x.x.x.x-y.y.y.y notation, or
      x.x.x/y
   o  Key-cert objects have their fingerprint, method and owner lines
      auto-corrected if supplied incorrectly.
   o  "Changed" attribute is automatically corrected / filled in.

   This means that the destination database in fact can change parts of
   the submitted data after it was signed.  Then results in an invalid
   signature.  As a potential remedy, if the signer of an object is not
   fully aware of the transformations the database will do to the object
   upon submission, then:




Kisteleki & Boumans      Expires April 30, 2009                 [Page 6]


Internet-Draft                Securing RPSL                 October 2008


   o  the object should be first submitted to the destination database
   o  the database will apply the internal normalization rules
   o  the signer then downloads the object from the database and applies
      the signature to the resulting object.

   The drawback here is that if there happen to be two different
   databases with different such rules, then signed objects cannot
   'travel' between these without being re-signed in the appropriate
   format.

3.3.2.  Normalization in Terms of an Electronic Signature

   The following steps must be applied in order to achieve a normalized
   form of an object, before the actual signature process can begin:

   1.  Uppercase/lowercase conversion, except for the value of the to-
       be-created "signature" attribute.  We believe that this causes no
       risks, although some parts of the input can potentially be case
       sensitive.

   2.  Comments (anything beginning with a "#") must be dropped.

   3.  Any trailing white space must be dropped.

   4.  All multi-line attributes are converted into their single-line
       equivalent.

   5.  The attribute names must be kept as part of one the attribute
       lines.

   6.  Multiple whitespaces must be collapsed into a single space (" ")
       character.

   7.  Add line endings must be converted to a singe new line ("\n")
       character (thus avoiding CR vs. CRLF differences).

3.4.  Storage of the Signature Data

   The result of the signature mechanism is exactly one new attribute
   for the object.  As a summary of the method described above, the
   structure of this is as follows:


      attribute1:  value1
      attribute2:  value2
      attribute3:  value3
      ...
      signature:   v=1; c=rsync://.....; m=rsa-sha1; t=9999999999;



Kisteleki & Boumans      Expires April 30, 2009                 [Page 7]


Internet-Draft                Securing RPSL                 October 2008


                   a=attribute1+attribute2+attribute3+...;
                   b=<base64 data>


4.  Signature creation and validation steps

   Given an RPSL object, in order to create the actual signature, the
   following steps are needed:

   o  Potentially submit the object-to-be-signed to the destination
      database, and download the resulting database-normalized object.

   o  Potentially create a one-off key pair and certificate to be used
      for signing this object this time.  Alternatively, one can reuse
      the same key pair / certificate for multiple signatures.

   o  Based on the object type, the minimum set and the local policies,
      create a list of attribute names referring to the attributes that
      will be signed (contents of the "a" field).

   o  Arrange the selected attributes according to the selection
      sequence provided above, while filtering out the non-signed
      attributes.

   o  Construct the would-be "signature" attribute, with all its fields,
      leaving the "b" field empty (NULL value).

   o  Apply normalization procedure to the selected attributes
      (including the "signature" attribute).

   o  Create the signature over the results of the previous step (hash
      and sign).

   o  Attach the base64 encoded value of the signature to the "b" field.

   o  Append the resulting final "signature" attribute to the original
      object.

   In order to validate a signature over such an object, the following
   steps are necessary:

   o  Check proper syntax of the "signature" attribute.

   o  Fetch the certificate referred to in the "c" field of the
      "signature" attribute, and check its validity using the steps
      described in [ID.sidr-res-certs].





Kisteleki & Boumans      Expires April 30, 2009                 [Page 8]


Internet-Draft                Securing RPSL                 October 2008


   o  Check whether the signature (base64 decoded value of the "b"
      field) is correct when verified with the public key found in the
      certificate.

   o  Extract the list of attributes that were signed by the signer from
      the "a" field of the "signature" attribute".

   o  Verify that the list of signed attributes contains the minimum set
      of attributes for that object type.

   o  Potentially check local policy whether the list of the signed
      attributes conforms to it.

   o  Arrange the selected attributes according to the selection
      sequence provided above, while filtering out the non-signed
      attributes.

   o  Replace the value of the signature filed of the "signature"
      attribute with an empty string (NULL value).

   o  Apply normalization procedure to the selected attributes
      (including the "signature" attribute).

   o  Check whether the hash value of the so constructed input matches
      the one in the signature.


5.  Signed Object Types, Minimum Set of Signed Attributes

   This section describes a list of object types that could be signed
   using this approach, and a minimum set of attributes which MUST be
   signed for those object types.

   The signer MAY chose to sign other attributes in addition to the
   required minimum set.  In this case the additional attributes MUST be
   listed in the "a" field besides the minimum list.

   This list generally excludes attributes that are used to maintain
   referential integrity in the databases that carry these objects,
   since these usually only make sense within the context of such a
   database, whereas the scope of the signatures is only one specific
   object.  Since the attributes in the referred object (such as mnt-by,
   admin-c, tech-c, ...) can change without any modifications to the
   signed object, signing such attributes could lead to false sense of
   security in terms of the contents of the signed data.






Kisteleki & Boumans      Expires April 30, 2009                 [Page 9]


Internet-Draft                Securing RPSL                 October 2008


      as-block:
      *  as-block
      *  org

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

      inet[6]num:
      *  inet[6]num
      *  netname
      *  country
      *  org
      *  status

      route[6]:
      *  route[6]
      *  origin
      *  holes
      *  org
      *  member-of


6.  Keys and Certificates used for Signature and Verification

   The certificate that is referred to in the signature (in the "c"
   field):
   o  MUST be an end-entity (ie. non-CA) certificate
   o  MUST conform to the X.509 PKIX Resource Certificate profile
      [ID.sidr-res-certs]
   o  MUST have an [RFC3779] extension that contains or covers at least
      one Internet resource mentioned in a signed attribute
   o  SHOULD NOT be used to verify more than one signed object (ie.
      should be a "single-use" EE certificate, as defined in
      [ID.sidr-res-certs]).


7.  Open Issues

   Work still needs to be done for the following questions:




Kisteleki & Boumans      Expires April 30, 2009                [Page 10]


Internet-Draft                Securing RPSL                 October 2008


   o  Does character encoding pose a real problem?
   o  Is it feasible and does it provide value, if, while creating
      multiple signatures, those signatures refer to each other?


8.  Security Considerations

   [To be Completed.]


9.  IANA Considerations

   [Note to IANA, to be removed prior to publication: there are no IANA
   considerations stated in this version of the document.]


10.  Normative References

   [ID.sidr-res-certs]
              Huston, G., Michaleson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Internet
              Draft draft-ietf-sidr-res-certs, October 2008.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.


Authors' Addresses

   Robert Kisteleki

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


   Jos Boumans

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












Kisteleki & Boumans      Expires April 30, 2009                [Page 11]


Internet-Draft                Securing RPSL                 October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kisteleki & Boumans      Expires April 30, 2009                [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/