idnits 2.17.1 draft-farrell-ni-00.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 28, 2011) is 4776 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) == Unused Reference: 'RFC2119' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC5050' is defined on line 395, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Standards Track C. Dannewitz 5 Expires: September 29, 2011 University of Paderborn 6 B. Ohlman 7 Ericsson 8 D. Kutscher 9 NEC 10 March 28, 2011 12 URIs for Named Information 13 draft-farrell-ni-00 15 Abstract 17 This document defines a URI-based name form for objects intended to 18 be used for information-centric networking and more generally. The 19 name form defined here allows for the various forms of hash-based 20 binding between the name and the named-object, as well as supporting 21 human-readable and hierarchical names. 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 29, 2011. 40 Copyright Notice 42 Copyright (c) 2011 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. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Hash Strings . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 [[Text in double square brackets (like this) is commentary.]] 70 URIs [RFC3986] are used in various protocols for identifying 71 resources. In many deployments those URIs contain strings that are 72 hash function outputs in order to ensure uniqueness in terms of 73 mapping the URI to a specific resource, or to make URIs hard to guess 74 for security reasons. However, there is no standard way to interpret 75 those strings and so today in general only the creator of the URI 76 knows how to use the hash function output. 78 In the context of information-centric networking [ref.netinf-design] 79 [ref.ccn] and elsewhere there is value in being able to compare a 80 presented resource against the URI that was de-referenced in order to 81 access that resource. If a cryptographically-strong comparison 82 function can be used then this allows for many forms of in-network 83 storage, without requiring as much trust in the infrastructure used 84 to present the resource. The outputs of hash functions can be used 85 in this manner, if presented in a standard way. There are also many 86 other potential uses for these hash outputs, for example, in terms of 87 binding the URI to an owner via signatures and public keys, mapping 88 between names, handling versioning etc. Many such uses can be based 89 on "wrapping" the object with meta-data, e.g. including signatures, 90 public key certificates etc. 92 We therefore define the "ni" URI scheme that allows for, but does not 93 insist upon, checking of the integrity of the URI/resource mapping. 95 Hash-function outputs however are not human memorable, and cannot 96 easily be used to construct a hierarchical namespace, which some 97 protocols and applications may require. The URI scheme therefore 98 also allows for human-readable strings to be used with, or instead 99 of, the hash function output strings. 101 We expect it will be beneficial for applications to be able to map 102 between human-readable URIs and URIs that allow for validation of 103 integrity the URI/resource mapping. However, in order to keep our 104 scheme simple and more broadly applicable, all considerations for how 105 to map between URIs and for how to access resources using these URIs 106 are to be specified elsewhere. In this memo, we simply define a form 107 of URI that can be used hopefully in many different contexts. 109 The URI scheme defined here could be thought of as being similar to 110 URLs with the ability to verify the URL/resource mapping. However, 111 we envisage these URIs actually being of most use in applications 112 where the resource is not located at a particular place in a network 113 topology, but can rather be cached in many places. 115 Syntax definitions in this memo are specified according to ABNF 116 [RFC4648]. 118 2. Hash Strings 120 We start with specifying how the outputs from hash functions are 121 handled. 123 Hash outputs are binary values that MUST be base64 encoded with line- 124 feeds, spaces and terminating "=" characters removed. These values 125 MUST be immediately preceded with a hash algorithm identifier and a 126 separator character (":"). For example, the start of such a value 127 might look like: "sha256:NDc0NzgyMGVmOGQ3OGU0..." 129 Hash values MAY be followed by a function identifier, naming the 130 function to be used to verify that hash. If the function identifier 131 is omitted, then the application needs to know how to verify the URI/ 132 resource mapping if that is desired. 134 In many cases the input to the hash function will the actual resource 135 itself as presented by whatever protocol uses the name and this is 136 the default when the function identifier is omitted. This is what 137 would be in the body of a HTTP response, were the URI used in a HTTP 138 GET message and were the object returned in a 200 OK HTTP response 139 with no fragmentation. 141 The function identifier allows for cases where the resource is 142 actually presented with additional information (e.g. meta-data) or is 143 wrapped in other encoding. One way in which this is expected to be 144 used is when the resource is presented with an accompanying digital 145 signature. In that case the signature could be presented along with 146 the resource and the hash function could be calculated over some 147 combination of the resource and signature, or, just over the 148 signature bits. (Note that the signature bits themselves are not 149 part of the name in this example.) 151 Since we want to be able to verify the hash value against the 152 resource, and since sometimes this will involve the resource being 153 wrapped in some other format that allows inclusion of meta-data or 154 security data, it may be the case that the protocol that presents the 155 resource identifies it as having the "wrapped" type. In order to 156 support applications that require typing for the resource itself (as 157 opposed to its "wrapped" form) we also allow a hash value to be 158 accompanied with an "inner" type that identifies the type of the 159 resource, rather than the wrapper. We do this using MIME types 160 appended after the function identifier. 162 Note that the "/" character from the MIME type MUST be percent 163 encoded in order to conform to the ABNF below. That is "application/ 164 jpeg" will be presented as "application%2fjpeg". 166 [[Should or must we allow "%2F" as well?]] 168 The "default" function-identifier, which is the only one defined 169 here, is denoted with the string "id" and means that the resource 170 when returned can be directly fed into the hash function without any 171 canonicalization required, so this is the "identity" function. Of 172 course, the hash based comparison may fail if some middlebox or 173 access protocol has re-encoded the resource in some way. 175 The "id" function identifier can be used if an "inner" MIME type 176 should be added to the name. 178 [["id" may not be the best tag for this, since it may confuse, not 179 sure what else to use.]] 181 Hash algorithm identifiers and function identifiers are to be 182 registered, in an IANA registry (see the "IANA Considerations" 183 section below). 185 [[There may already be a usable hash function registry. But if we're 186 going to be interested in truncated hashes then we may need our 187 own.]] 189 Let's call a value encoded as above a "hash-string." We could define 190 it thusly: 192 hash-string = hashalg ":" b64value 193 [ ":" function-identifier [ ":" mime-type ] ] 195 hashalg = identifier 197 function-identifier = identifier 199 identifier = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 201 mime-type = type %2f subtype 203 b64value is a string based on the 64-character subset of US-ASCII as 204 defined in [RFC4648]. mime-type is based on the Content-Type header 205 field syntax as specified in [RFC2045], but using %2f as a delimiter 206 between type and subtype instead of "/", and without parameters. 208 [[Complete formal ABNF spec of b64value to be provided in a future 209 revision of this memo.]] 210 It is important to note that implementations are NOT REQUIRED to 211 support any cryptographic operations, that is, as necessary, they 212 need to be able to parse, route, log, and resolve names with any of 213 the above fields, but do not have to verify anything cryptographic. 215 Implementations that do support cryptographic operations MUST offer 216 applications a way (e.g. via an API) to compare an ni name with a 217 resource. The set of cryptographic operations to be supported (e.g. 218 the set of supported function identifiers), is an implementation 219 decision and is not further specified. Where an implementation does 220 not support the operation needed to verify a ni object, it MUST 221 return an error distinct from the case where the name-to-object 222 comparison failed, e.g. due to a hash mismatch. 224 Implementations that create names such as these MUST ensure that it 225 is possible to validate the mapping from the name to the resource, 226 should other implementations choose to do that validation. That is, 227 when creating a name like this, make sure that you do it right! 229 Note that not all protocols and applications making use of this URI 230 form will require strong integrity assurances when doing name/ 231 resource comparisons. For this reason, we expect it to be relatively 232 common to use truncated hashes in URIs. 234 3. URI Scheme 236 Our URIs consist of the scheme, an optional authority part and then a 237 "local" part which is a possibly empty sequence of either hash- 238 strings or any other string who's encoding is allowed. As with the 239 local part, the authority part may be either a hash-string or any 240 other string who's encoding is allowed. 242 The semantics of the authority part are not further defined here, but 243 MUST be specified by any protocol or application making use of these 244 URIs. 246 The "local" part is intended to contain an identifier for the 247 resource in question that is meaningful in the context of the 248 authority. 250 Note that where the authority part is omitted and where the local 251 part is not a hash-string, then this may be a significant probability 252 for accidental name collisions. Protocols and applications using 253 this URI scheme MUST take care of such collisions, if they matter. 254 Note that this is also true, even if the authority part is present, 255 unless there is some strict authority-part registration scheme in 256 force and where spoofing is hard. 258 One obvious thing to use for the authority part is a Fully Qualified 259 Domain Name (FQDN), possibly with a port number, in which case 260 applications using these URIs could make use of the Domain Name 261 System (DNS) and TCP. Again though - such uses are outside the scope 262 of this specification. In general, there will be no guarantee that 263 the resource can be accessed at that host:port even in that case. 265 [[ABNF to be fixed later. Note that the syntax below allows "ni:///" 266 as a valid name - whether that is good or bad, and if good, what 267 "ni:///" might mean is for future study.]] 269 ni-name = scheme ":" hier-part 270 hier-part = "//" [authority] "/" *(local-part "/") ["/"] 272 scheme = "ni" 274 authority = hash-string | other-string ;(delimiters %-encoded) 276 local-part = hash-string | other-string ;(delimiters %-encoded) 278 [[Formal ABNF of other-string to be specified in a future revision of 279 this memo.]] 281 4. Examples 283 The longer examples in this section flow over lines, but the meaning 284 should be clear enough. 286 1) ni://tcd.ie/cs8053-exam-2012 288 Example 1 is quite like a HTTP URL, and simply shows that "normal" 289 URI forms can be used with ni names. 291 2) ni:///weather-in-dublin-today 293 Example 2 shows an example of an "intentional" name, where the 294 resource returned will likely change from time to time. This example 295 has no authority part, which presumably would mean that the requester 296 doesn't really care much about the source of the weather information. 298 3) ni://tcd.ie/sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ5MjkyZ 299 DM0ZTg2ZDI5YzllMmU5OTFlNmE2Mjc3ZTFhN2JhNmE4ZjVmMwo 301 4) ni:///sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ5MjkyZDM0ZTg 302 2ZDI5YzllMmU5OTFlNmE2Mjc3ZTFhN2JhNmE4ZjVmMwo 304 Examples 3 and 4 are the same, one with, and one without, an 305 authority part. In both cases, we have no idea what was hashed if we 306 only know the ni name. Some higher layer protocol may of course be 307 able to understand what's going on. 309 It may be that the authority part of example 3 allows for more 310 scalable name-based routing of a request to get, or do something 311 with, that resource. 313 5) ni://sha256:NDc0NzgyMGVmOGQ3OGU0MmI2MWYwZjY3MDAzNDJmZTY 314 0NzhhMGY0OTBhMDRiNzA0YTY0MWY0MzVkODQzZWUxMAo:id:sshpk/thing 316 The authority for example 5 is a hash-string of a public key as 317 stored in a file by openssh. Though we know that from the URI, there 318 is no implication that we need to, or can, do anything special about 319 that fact. Some protocol making use of this name however, might 320 expect that the resource contain a signature verifiable with a public 321 key that matches that hash. 323 6) ni://tcd.ie/sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ 324 5MjkyZDM0ZTg2ZDI5YzllMmU5OTFlNmE2Mjc3ZTFhN2JhNmE4Z 325 jVmMwo:signeddata:application%2Fjpeg 327 Example 6 is a ni name for a jpeg file that contains a hash of the 328 file contents where we expect to receive the image in a CMS 329 SignedData wrapper. 331 Note that the function identifier signeddata could be defined to also 332 accept a PGP or XMLDSIG or other wrapper - what's identified is a 333 function, and not directly a format. The signeddata function is 334 something that would have to be defined elsewhere. That is, another 335 specification would need to be written for each such function. [[Or, 336 something basic might be included here, but not as a mandatory-to- 337 implement feature.]] 339 5. Security Considerations 341 [[More needed for sure.]] 343 Network elements that do attempt to verify the mapping from the name 344 to the resource are doing more work that those that don't, both in 345 terms of CPU, (for the hash and function identifier calculations) and 346 possibly also in terms of network access and/or storage, since they 347 need the resource, and possibly meta-data that might have to be 348 separately requested. An example of the latter kind of meta-data 349 might be a public key certificate or CRL. This additional load could 350 be leveraged in some kinds of DoS attack. Protocols that call for 351 validation of the name/resource mapping SHOULD specify how to handle 352 any such DoS that may be relevant. 354 6. IANA Considerations 356 Two registries will be required for this specification. The first 357 will be for function identifiers, with a FCFS update rule and one 358 initially registered value, the "id" function identifier. The second 359 registry will be for hash functions and may exist already. If not, 360 then, we will want a hash function registry with RFC required as the 361 update rule. Most likely the only reason a new hash function 362 registry would be required would be if we wanted a few relatively 363 weak truncated hash functions registered, but where that would be 364 wrong for the existing hash function registries. 366 7. Acknowledgements 368 This work has been supported by the EU FP7 project SAIL. The authors 369 would like to thank SAIL participants to our naming discussions, 370 especially Jean-Francois Peltier, for their input. 372 8. References 374 8.1. Normative References 376 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 377 Extensions (MIME) Part One: Format of Internet Message 378 Bodies", RFC 2045, November 1996. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 384 Resource Identifier (URI): Generic Syntax", STD 66, 385 RFC 3986, January 2005. 387 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 388 Encodings", RFC 4648, October 2006. 390 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 391 Specifications: ABNF", STD 68, RFC 5234, January 2008. 393 8.2. Informative References 395 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 396 Specification", RFC 5050, November 2007. 398 [ref.caw] Chapweske, "HTTP Extensions for a Content-Addressable 399 Web", October 2001. 401 http://lists.w3.org/Archives/Public/www-talk/2001NovDec/ 402 0090.html 404 [ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content", 405 CoNEXT 2009 , December 2009. 407 [ref.magnet] 408 Mohr, "MAGNET", June 2002. 410 http://magnet-uri.sourceforge.net/ 411 magnet-draft-overview.txt 413 [ref.netinf-design] 414 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 415 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 416 Considerations for a Network of Information", Re-Arch 2008 417 Workshop , December 2008. 419 Authors' Addresses 421 Stephen Farrell 422 Trinity College Dublin 423 Dublin, 2 424 Ireland 426 Phone: +353-1-896-2354 427 Email: stephen.farrell@cs.tcd.ie 429 Christian Dannewitz 430 University of Paderborn 431 Paderborn 432 Germany 434 Email: cdannewitz@upb.de 435 Borje Ohlman 436 Ericsson 437 Stockholm S-16480 438 Sweden 440 Email: Borje.Ohlman@ericsson.com 442 Dirk Kutscher 443 NEC 444 Kurfuersten-Anlage 36 445 Heidelberg, 446 Germany 448 Phone: 449 Email: kutscher@neclab.eu