idnits 2.17.00 (12 Aug 2021) /tmp/idnits60624/draft-ietf-sidr-rpsl-sig-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 3, 2016) is 2270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 495 ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR R. Kisteleki 3 Internet-Draft RIPE NCC 4 Intended status: Standards Track B. Haberman 5 Expires: September 4, 2016 JHU APL 6 March 3, 2016 8 Securing RPSL Objects with RPKI Signatures 9 draft-ietf-sidr-rpsl-sig-09.txt 11 Abstract 13 This document describes a method to allow parties to electronically 14 sign RPSL-like objects and validate such electronic signatures. This 15 allows relying parties to detect accidental or malicious 16 modifications on such objects. It also allows parties who run 17 Internet Routing Registries or similar databases, but do not yet have 18 RPSS-like authentication of the maintainers of certain objects, to 19 verify that the additions or modifications of such database objects 20 are done by the legitimate holder(s) of the Internet resources 21 mentioned in those objects. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 4, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3 59 2.1. General Attributes, Meta Information . . . . . . . . . . 3 60 2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5 62 2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5 63 2.5. Validity Time of the Signature . . . . . . . . . . . . . 6 64 3. Signature Creation and Validation Steps . . . . . . . . . . . 6 65 3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8 67 3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9 68 4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10 69 5. Keys and Certificates used for Signature and Verification . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Objects stored in resource databases, like the RIPE DB, are generally 79 protected by an authentication mechanism: anyone creating or 80 modifying an object in the database has to have proper authorization 81 to do so, and therefore has to go through an authentication procedure 82 (provide a password, certificate, e-mail signature, etc.) However, 83 for objects transferred between resource databases, the 84 authentication is not guaranteed. This means when downloading an 85 object stored in this database, one can reasonably safely claim that 86 the object is authentic, but for an imported object one cannot. 87 Also, once such an object is downloaded from the database, it becomes 88 a simple (but still structured) text file with no integrity 89 protection. More importantly, the authentication and integrity 90 guarantees associated with these objects do not always ensure that 91 the entity that generated them is authorized to make the assertions 92 implied by the data contained in the objects. 94 A potential use for resource certificates [RFC6487] is to use them to 95 secure such (both imported and downloaded) database objects, by 96 applying a form of digital signature over the object contents. A 97 maintainer of such signed database objects MUST possess a relevant 98 resource certificate, which shows him/her as the legitimate holder of 99 an Internet number resource. This mechanism allows the users of such 100 database objects to verify that the contents are in fact produced by 101 the legitimate holder(s) of the Internet resources mentioned in those 102 objects. It also allows the signatures to cover whole RPSL objects, 103 or just selected attributes of them. In other words, a digital 104 signature created using the private key associated with a resource 105 certificate can offer object security in addition to the channel 106 security already present in most of such databases. Object security 107 in turn allows such objects to be hosted in different databases and 108 still be independently verifiable. 110 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 111 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC2119]. 115 2. Signature Syntax and Semantics 117 When signing an RPSL object, the input for the signature process is 118 transformed into a sequence of strings of (ASCII) data. The approach 119 is similar to the one used in DKIM (Domain Key Identified Mail) 120 [RFC4871]. In the case of RPSL, the object-to-be-signed closely 121 resembles an SMTP header, so it seems reasonable to adapt DKIM's 122 relevant features. 124 2.1. General Attributes, Meta Information 126 The digital signature associated with an RPSL object is itself a new 127 attribute named "signature". It consists of mandatory and optional 128 fields. These fields are structured in a sequence of name and value 129 pairs, separated by a semicolon ";" and a white space. Collectively 130 these fields make up the value for the new "signature" attribute. 131 The "name" part of such a component is always a single ASCII 132 character that serves as an identifier; the value is an ASCII string 133 the contents of which depend on the field type. Mandatory fields 134 must appear exactly once, whereas optional fields MUST appear at most 135 once. 137 Mandatory fields of the "signature" attribute: 139 o Version of the signature (field "v"). This field MUST be set to 140 "rpkiv1". The signature format described in this document applies 141 when the version field is set to "rpkiv1". All the rest of the 142 signature attributes are defined by the value of version field. 144 o Reference to the certificate corresponding to the private key used 145 to sign this object (field "c"). The value of this field MUST be 146 a URL of type "rsync" or "http(s)" that points to a specific 147 resource certificate in an RPKI repository [RFC6481]. Any non 148 URL-safe characters (including semicolon ";" and plus "+") must be 149 URL encoded. 151 o Signature method (field "m"): what hash and signature algorithms 152 were used to create the signature. The allowed algorithms which 153 can be used for the signature are specified in Section 5 of RFC 154 4055 [RFC4055]. More specifically, this version of RPSL 155 signatures supports the following hash algorithms: 157 * sha224WithRSAEncryption 159 * sha256WithRSAEncryption 161 * sha384WithRSAEncryption 163 * sha512WithRSAEncryption 165 The algorithms are referenced witin the signature attribute by the 166 ASCII names of the algorithms. 168 o Time of signing (field "t"). The format of the value of this 169 field MUST be in the Internet Date/Time format [RFC3339]. All 170 times MUST be converted to Universal Coordinated Time (UTC) 172 o The signed attributes (field "a"). This is a list of attribute 173 names, separated by an ASCII "+" character (if more than one 174 attribute is enumerated). The list must include any attribute at 175 most once. 177 o The signature itself (field "b"). This MUST be the last field in 178 the list. The signature is the output of the signature algorithm 179 using the appropriate private key and the calculated hash value of 180 the object as inputs. The value of this field is the digital 181 signature in base64 encoding [RFC4648]. 183 Optional fields of the "signature" attribute: 185 o Signature expiration time (field "x"). The format of the value of 186 this field MUST be in the Internet Date/Time format [RFC3339]. 187 All times MUST be represented in UTC. 189 2.2. Signed Attributes 191 One can look at an RPSL object as an (ordered) set of attributes, 192 each having a "key: value" syntax. Understanding this structure can 193 help in developing more flexible methods for applying digital 194 signatures. 196 Some of these attributes are automatically added by the database, 197 some are database-dependent, yet others do not carry operationally 198 important information. This specification allows the maintainer of 199 such an object to decide which attributes are important (signed) and 200 which are not (not signed), from among all the attributes of the 201 object; in other words, we define a way of including important 202 attributes while excluding irrelevant ones. Allowing the maintainer 203 of an object to select the attributes that are covered by the digital 204 signature achieves the goals established in Section 1. 206 The type of the object determines the minimum set of attributes that 207 MUST be signed. The signer MAY choose to sign additional attributes, 208 in order to provide integrity protection for those attributes too. 210 When verifying the signature of an object, the verifier has to check 211 whether the signature itself is valid, and whether all the specified 212 attributes are referenced in the signature. If not, the verifier 213 MUST reject the signature and threat the object as a regular, non- 214 signed RPSL object. 216 2.3. Storage of the Signature Data 218 The result of applying the signature mechanism once is exactly one 219 new attribute for the object. As an illustration, the structure of a 220 signed RPSL object is as follows: 222 attribute1: value1 223 attribute2: value2 224 attribute3: value3 225 ... 226 signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption; 227 t=2014-12-31T23:59:60Z; 228 a=attribute1+attribute2+attribute3+...; 229 b= 231 2.4. Number Resource Coverage 233 Even if the signature(s) over the object are valid according to the 234 signature validation rules, they may not be relevant to the object; 235 they also need to cover the relevant Internet number resources 236 mentioned in the object. 238 Therefore the Internet number resources present in [RFC3779] 239 extensions of the certificate referred to in the "c" field of the 240 signature MUST cover the resources in the primary key of the object 241 (e.g., value of the "aut-num:" attribute of an aut-num object, value 242 of the "inetnum:" attribute of an inetnum object, values of "route:" 243 and "origin:" attributes of a route object, etc.). 245 2.5. Validity Time of the Signature 247 The validity time interval of a signature is the intersection of the 248 validity time of the certificate used to verify the signature, the 249 "not before" time specified by the "t" field of the signature, and 250 the optional "not after" time specified by the "x" field of the 251 signature. 253 When checking multiple signatures, these checks are applied to each 254 signature, individually. 256 3. Signature Creation and Validation Steps 258 3.1. Canonicalization 260 The notion of canonicalization is essential to digital signature 261 generation and validation whenever data representations may change 262 between a signer and one or more signature verifiers. 263 Canonicalization defines how one transforms a representation of data 264 into a series of bits for signature generation and verification. The 265 task of canonicalization is to make irrelevant differences in 266 representations of the same object, which would otherwise cause 267 signature verification to fail. Examples of this could be: 269 o data transformations applied by the databases that host these 270 objects (such as notational changes for IPv4/IPv6 prefixes, 271 automatic addition/modification of "changed" attributes, etc.) 273 o the difference of line terminators across different systems. 275 This means that the destination database might change parts of the 276 submitted data after it was signed, which would cause signature 277 verification to fail. This document specifies strict 278 canonicalization rules to overcome this problem. 280 The following steps MUST be applied in order to achieve canonicalized 281 representation of an object, before the actual signature 282 (verification) process can begin: 284 1. Comments (anything beginning with a "#") MUST be omitted. 286 2. Any trailing white space MUST be omitted. 288 3. A multi-line attribute MUST be converted into its single-line 289 equivalent. This is accomplished by: 291 * Converting all line endings to a single blank space. 293 * Concatenating all lines into a single line. 295 * Replacing the trailing blank space with a single new line 296 ("\n"). 298 4. Numerical fields MUST be converted to canonical representations. 299 These include: 301 * Date and time fields MUST be converted to UTC and MUST be 302 represented in the Internet Date/Time format [RFC3339]. 304 * AS numbers MUST be converted to ASPLAIN syntax [RFC5396]. 306 * IPv6 addresses MUST be canonicalized as defined in [RFC5952]. 308 * IPv4 addresses MUST be represented as the ipv4-address type 309 defined by RPSL [RFC2622] 311 * All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR 312 notation [RFC4632]. 314 5. All ranges, lists, or sets of numerical fields are represented 315 using the appropriate RPSL attribute and each numerical element 316 contained within those attributes MUST conform to the 317 canonicalization rules in this document. 319 6. The name of each attribute MUST be converted into lower case, and 320 MUST be kept as part of the attribute line. 322 7. Tab characters ("\t") MUST be converted to spaces. 324 8. Multiple whitespaces MUST be collapsed into a single space (" ") 325 character. 327 9. All line endings MUST be converted to a singe new line ("\n") 328 character (thus avoiding CR vs. CRLF differences). 330 3.2. Signature Creation 332 Given an RPSL object, in order to create the digital signature, the 333 following steps MUST be performed: 335 1. For each signature, a new public/private key pair and certificate 336 SHOULD be used. Therefore the signer SHOULD create a single-use 337 key pair and end-entity resource certificate (see [RFC6487]). 338 The private key is used for signing this object this time. 340 2. Create a list of attribute names referring to the attributes that 341 will be signed (contents of the "a" field). The minimum set of 342 these attributes is determined by the object type; the signer MAY 343 select additional attributes. 345 3. Arrange the selected attributes according to the selection 346 sequence specified in the "a" field as above, omitting all 347 attributes that will not be signed. 349 4. Construct the new "signature" attribute, with all its fields, 350 leaving the value of the "b" field empty. 352 5. Apply canonicalization rules to the result (including the 353 "signature" attribute). 355 6. Create the signature over the results of the canonicalization 356 process (according to the signature and hash algorithms specified 357 in the "m" field of the signature attribute). 359 7. Insert the base64 encoded value of the signature as the value of 360 the "b" field. 362 8. Append the resulting "signature" attribute to the original 363 object. 365 3.3. Signature Validation 367 In order to validate a signature over such an object, the following 368 steps MUST be performed: 370 1. Verify the syntax of the "signature" attribute (i.e., whether it 371 contains the mandatory and optional components and the syntax of 372 these fields matches the specification as described in section 373 2.1.) 375 2. Fetch the certificate referred to in the "c" field of the 376 "signature" attribute, and check its validity using the steps 377 described in [RFC6487]. 379 3. Extract the list of attributes that were signed using the signer 380 from the "a" field of the "signature" attribute. 382 4. Verify that the list of signed attributes includes the minimum 383 set of attributes for that object type. 385 5. Arrange the selected attributes according to the selection 386 sequence provided in the value of the "a" field, omitting all 387 non-signed attributes. 389 6. Replace the value of the signature field "b" of the "signature" 390 attribute with an empty string. 392 7. Apply the canonicalization procedure to the selected attributes 393 (including the "signature" attribute). 395 8. Check the validity of the signature using the signature algorithm 396 specified in the "m" field of the signature attribute, the public 397 key contained in the certificate mentioned in the "c" field of 398 the signature, the signature value specified in the "b" field of 399 the signature attribute, and the output of the canonicalization 400 process. 402 4. Signed Object Types, Set of Signed Attributes 404 This section describes a list of object types that MAY signed using 405 this approach. For each object type, the set of attributes that MUST 406 be signed for these object types (the minimum set noted in 407 Section Section 3.3 is enumerated. 409 This list generally excludes attributes that are used to maintain 410 referential integrity in the databases that carry these objects, 411 since these usually make sense only within the context of such a 412 database, whereas the scope of the signatures is only one specific 413 object. Since the attributes in the referred object (such as mnt-by, 414 admin-c, tech-c, ...) can change without any modifications to the 415 signed object, signing such attributes could lead to false sense of 416 security in terms of the contents of the signed data; therefore 417 including such attributes should only be done in order to provide 418 full integrity protection of the object itself. 420 The newly constructed "signature" attribute is always included in the 421 list. 423 as-block: 425 * as-block 427 * org 429 * signature 431 aut-num: 433 * aut-num 435 * as-name 437 * member-of 439 * import 441 * mp-import 442 * export 444 * mp-export 446 * default 448 * mp-default 450 * signature 452 inet[6]num: 454 * inet[6]num 456 * netname 458 * country 460 * org 462 * status 464 * signature 466 route[6]: 468 * route[6] 470 * origin 472 * holes 474 * org 476 * member-of 478 * signature 480 For each signature, the RFC3779 extension appearing in the 481 certificate used to verify the signature MUST include a resource 482 entry that is equivalent to, or covers ("less specific" than) the 483 following resources mentioned in the object the signature is attached 484 to: 486 o For the as-block object type: the resource in the "as-block" 487 attribute. 489 o For the aut-num object type: the resource in the "aut-num" 490 attribute. 492 o For the inet[6]num object type: the resource in the "inet[6]num" 493 attribute. 495 o For the route[6] object type: the resource in the "route[6]" or 496 "origin" (or both) attributes. 498 5. Keys and Certificates used for Signature and Verification 500 The certificate that is referred to in the signature (in the "c" 501 field): 503 o MUST be an end-entity (ie. non-CA) certificate 505 o MUST conform to the X.509 PKIX Resource Certificate profile 506 [RFC6487] 508 o MUST have an [RFC3779] extension that covers the Internet number 509 resource included in a signed attribute. 511 o SHOULD NOT be used to verify more than one signed object (ie. 512 should be a "single-use" EE certificate, as defined in [RFC6487]). 514 6. Security Considerations 516 RPSL objects stored in the IRR databases are public, and as such 517 there is no need for confidentiality. Each signed RPSL object can 518 have its integrity and authenticity verified using the supplied 519 digital signature and the referenced certificate. 521 Since the RPSL signature approach leverages X.509 extensions, the 522 security considerations in [RFC3779] apply here as well. 524 The maintainer of an object has the ability to include attributes in 525 the signature that are not included in the resource certificate used 526 to create the signature. Potentially, a maintainer may include 527 attributes that reference resources the maintainer is not authorized 528 to use. 530 7. IANA Considerations 532 [Note to IANA, to be removed prior to publication: there are no IANA 533 considerations stated in this version of the document.] 535 8. Acknowledgements 537 The authors would like to acknowledge the valued contributions from 538 Jos Boumans, Steve Kent, Sean Turner, Geoff Huston, and Stephen 539 Farrell in preparation of this document. 541 9. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 549 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 550 "Routing Policy Specification Language (RPSL)", RFC 2622, 551 DOI 10.17487/RFC2622, June 1999, 552 . 554 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 555 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 556 . 558 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 559 Addresses and AS Identifiers", RFC 3779, 560 DOI 10.17487/RFC3779, June 2004, 561 . 563 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 564 Algorithms and Identifiers for RSA Cryptography for use in 565 the Internet X.509 Public Key Infrastructure Certificate 566 and Certificate Revocation List (CRL) Profile", RFC 4055, 567 DOI 10.17487/RFC4055, June 2005, 568 . 570 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 571 (CIDR): The Internet Address Assignment and Aggregation 572 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 573 2006, . 575 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 576 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 577 . 579 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 580 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 581 Signatures", RFC 4871, DOI 10.17487/RFC4871, May 2007, 582 . 584 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 585 Autonomous System (AS) Numbers", RFC 5396, 586 DOI 10.17487/RFC5396, December 2008, 587 . 589 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 590 Address Text Representation", RFC 5952, 591 DOI 10.17487/RFC5952, August 2010, 592 . 594 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 595 Resource Certificate Repository Structure", RFC 6481, 596 DOI 10.17487/RFC6481, February 2012, 597 . 599 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 600 X.509 PKIX Resource Certificates", RFC 6487, 601 DOI 10.17487/RFC6487, February 2012, 602 . 604 Authors' Addresses 606 Robert Kisteleki 608 Email: robert@ripe.net 609 URI: http://www.ripe.net 611 Brian Haberman 612 Johns Hopkins University Applied Physics Lab 614 Email: brian@innovationslab.net