idnits 2.17.1 draft-seedorf-icn-wot-selfcertifying-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.seedorf-icn-disaster' is defined on line 263, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) == Outdated reference: A later version (-05) exists of draft-seedorf-icn-disaster-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG J. Seedorf 3 Internet-Draft NEC 4 Intended status: Informational March 5, 2015 5 Expires: September 6, 2015 7 Binding Self-certifying Names to Real-World Identities with a Web-of- 8 Trust 9 draft-seedorf-icn-wot-selfcertifying-01 11 Abstract 13 Self-certifying names are one way of binding a given public key to a 14 certain name in Information Centric Networking. However, an 15 additional binding of a self-certifying name to a Real-World identity 16 is needed in most cases, so that a recipient of some information 17 cannot only verify that the publisher was in possession of the 18 correct corressponding private key for the requested name, but that 19 in addition the name itself is the intended one. This draft 20 specifies how such a binding of Real-World identities with self- 21 certifying ICN names can be done, taking existing IETF specifications 22 into account. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. High-Level Design . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Standardisation Considerations . . . . . . . . . . . . . . . 4 61 3.1. High-Level Considerations . . . . . . . . . . . . . . . . 4 62 3.2. Existing Information-Centric Naming Schemes in the IETF . 5 63 3.3. Existing Web-of-Trust Standards in the IETF . . . . . . . 5 64 3.4. Hash Extension Techniques . . . . . . . . . . . . . . . . 5 65 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 5.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Self-certifying names provide the useful property that any entity in 75 a distributed system can verify the binding between a corresponding 76 public key and the self-certifying name without relying on a trusted 77 third party [Aura2003]. Self-certifying names thus provide a 78 decentralized form of data origin authentication. This feature makes 79 self-certifying names a prime candidate for addressing the security 80 requirements in Information Centric Networking (ICN) (which are 81 inherently different from IP networks): a source can digitally sign 82 data associated with a self-certifying name, and any intermediate 83 entity (e.g. ICN-router/Cache) or receiving entity (i.e. issuer of a 84 request for the name) can verify the signature, without the need to 85 verify the identity of the host that caches the object, nor relying 86 on a trusted third party, or a Public Key Infrastructure (PKI). 87 However, as noted in [Ghodsi2011] and elsewhere, self-certifying 88 names lack a binding with a corresponding real-world identity (RWI): 89 the concept enables to verify that whoever signed some data was in 90 possession of the private key associated with the self-certifying 91 name, but it does not provide any means to verify what real-world 92 identity corresponds to the public key, i.e. who actually signed the 93 data [Ghodsi2011] [Nom2014]. 95 In principle, this binding between a public key and an RWI could be 96 provided by a PKI, or alternatively by a Web-of-Trust (WoT) 98 [Ghodsi2011]. Several ICN approaches use a PKI [Survey] . However, 99 until recently, there have not been concrete proposals for a WoT- 100 based approach for binding a public key (or a self-certifying name) 101 with an RWI in content-oriented architectures. A concrete approach 102 on how this can be done has been proposed in [Nom2014]. This 103 document has the objective of providing the corresponding necessary 104 standards specification to enable this approach (or similar ones) in 105 principle in an interoperable way. 107 2. High-Level Design 109 On a high level, binding of self-certifying names and a Web-of-Trust 110 can be achieved in the following way (see [Nom2014] for a detailed 111 example of such an approach): The WoT key-ID is equivalent to the 112 self-certifying name part used in the naming scheme. This ties the 113 self-certifying name with the ID of the corresponding public key in 114 the WoT. 116 For instance, in the existing PGP Web-of-Trust, the V4 key ID is the 117 lower 64 bits of the fingerprint of the public key, where the 118 fingerprint is essentially the 160-bit SHA-1 hash of the public key 119 [RFC2440]. So if a self-certifying name would be based on the same 120 lower 64-bits of the fingerprint of a given public key, this public 121 key would be tied to the self-certifying name and at the same time be 122 tied to the real-world identity used in the WoT, e.g. an email- 123 address or the real (i.e. non-self-certifying) name of a given ICN 124 publisher. 126 Thus, if a user requests the content for a self-certifying name in a 127 given ICN architecture, he/she would retrieve the content which 128 contains a digital signature and the corresponding public key for the 129 self-certifying name. The user can then verify that the content 130 retrieved indeed belongs to the name by first hashing the public key 131 and confirm that the hash (or part of it) matches the requested name, 132 and second using the public key to verify the signature over the 133 content. This is in principle the general way of using self- 134 certifying names for data origin authentication in distributed 135 systems. If, in addition, (part of) the self-certifying name is 136 equivalent to a WoT key-ID, the user can use any WoT infrastructure 137 (e.g. PGP keyservers) to retrieve certificates for the key ID that 138 contain/confirm the binding between the corresponding (to the WoT key 139 ID) public key with a real-world identity, such as an email address. 140 This binding provides the requesting user with assurance that the 141 self-certifying name indeed is owned by the intended publisher, i.e. 142 is the correct, intended name from the requestor's perpective. 144 The current PGP specification [RFC2440] considers only a bitlength of 145 64-bit for forming the key-ID, which is not very collision-resistant 146 (collision-resistance among different key-IDs was not a design goal 147 for PGP [RFC2440]). For securely binding a self-certifying name to a 148 WoT key-ID, collision-resistance is a design goal, because otherwise 149 attckaers could potentially forge a binding of their public key with 150 a given self-certifying name. Thus, either a longer bitlength of the 151 hash of the public key (or its fingerprint) must be used, or hash 152 extension techniques [Aura] must be used, which effectively make 153 collision attacks harder for constant bitlengths at the price of the 154 time needed to create a public/private key pair. Future versions of 155 this document will take these design considerations into account. 157 3. Standardisation Considerations 159 Future versions of this document will outline a concrete protocol 160 specification for binding self-certifying names to a Web-of-Trust as 161 outlined on a high level in the previous Section. Below some initial 162 standardisation considerations are highlighted, as well as an 163 assessment of existing IETF standards that could be used as building 164 blocks. Also, future versions of this document will look in more 165 detail into existing IETF specifications, e.g. regarding ICN naming 166 ([RFC6920]) and Web-of-Trust ([RFC2440]), and inspect to what extend 167 such existing specifications can be used directly or in a modified 168 form. 170 3.1. High-Level Considerations 172 An initial list of details that need to be specified is the 173 following: 175 o (List of) Asymmetric cryptography algorithm(s) and corresponding 176 bit-length(s) 178 o (List of) Hash algorithm(s) and corresponding bit-length(s) 180 o Rules that define what part of the hash is used for forming the 181 self-certifying part of the name, i.e. the Web-of-Trust Key-ID 183 o Rules for forming a self-certifying name based on a public key 185 o Semantics of a signature in the Web-of-Trust 187 o Defintion of how many bits are used in case of hash extension 188 techniques [Aura][RFC3972] 190 3.2. Existing Information-Centric Naming Schemes in the IETF 192 RFC 6920 'Naming Things with Hashes' defines a standard for correctly 193 identifying data 'using the output from a hash function' [RFC6920]. 194 In particular, it specifies a '(ni) URI Format' (see [RFC6920], 195 Section 3) and a 'Named Information Hash Algorithm Registry' (see 196 [RFC6920], Section 9.4). These building blocks allow to specify a 197 format for self-certifying names as hashes of WoT public keys, as 198 outlined above,. In particular, truncated hash formats are clearly 199 defined which can be used to form a self-certifying name from a Web- 200 of-Trust public key by defining what part of the hash is used for 201 forming the WoT key-ID self-certifying part of the name (e.g. 'sha- 202 256-64' for a truncated SHA-256 hash to 64 bits). 204 3.3. Existing Web-of-Trust Standards in the IETF 206 RFC 2440 asymmetric cryptography algorithms and corresponding bit- 207 length for usage in a Web-of-Trust [RFC2440]. Thus, there is an 208 existing IETF specification that provides this building block needed 209 for binding Self-certifying Names to Real-World Identities with a 210 Web-of-Trust. 212 3.4. Hash Extension Techniques 214 RFC 3972 discusses hash extension techniques, i.e. approaches that 215 'increase the cost of both address generation and brute-force attacks 216 by the same parameterized factor while keeping the cost of address 217 use and verification constant' [RFC3972]. This can be a building 218 block for using hash extension techniques for binding Self-certifying 219 Names to Real-World Identities with a Web-of-Trust. 221 4. Conclusion 223 One option for binding self-certifying names to real-world identities 224 is using a Web-of-Trust. This document aims at a concrete 225 specification for providing such a binding, taking existing IETF 226 specification into account. An inspection of existing Web-of-Trust 227 and Naming Scheme standards in the IETF reveal that the basic 228 building blocks for the intended specification for binding Self- 229 certifying Names to Real-World Identities with a Web-of-Trust are 230 already available as IETF standards. Future versions of this 231 document will provide a more detailed specification. 233 5. References 234 5.1. Normative References 236 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 237 "OpenPGP Message Format", RFC 2440, November 1998. 239 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 240 RFC 3972, March 2005. 242 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 243 Keranen, A., and P. Hallam-Baker, "Naming Things with 244 Hashes", RFC 6920, April 2013. 246 5.2. Informative References 248 [Aura] Aura, T. and M. Roe, "Strengthening Short Hash Values", 249 http://citeseerx.ist.psu.edu/viewdoc/ 250 summary?doi=10.1.1.145.7681, . 252 [Aura2003] 253 Aura, T., "Cryptographically Generated Addresses (CGA)", 254 6th International Conference on Information Security 255 (ISC), 2003, . 257 [Ghodsi2011] 258 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 259 S. Shenker, "Naming in Content-oriented Architectures", 260 ACM SIGCOMM Workshop on Information-centric Networking, 261 2011, . 263 [I-D.seedorf-icn-disaster] 264 Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, 265 K., and N. Blefari-Melazzi, "Using ICN in disaster 266 scenarios", draft-seedorf-icn-disaster-03 (work in 267 progress), March 2015. 269 [Nom2014] Seedorf, J., Kutscher, D., and F. Schneider, 270 "Decentralised Binding of Self-Certifying Names to Real- 271 World Identities for Assessment of Third-Party Messages in 272 Fragmented Mobile Networks", 2nd Workshop on Name Oriented 273 Mobility (NOM), 2014, . 275 [Survey] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 276 Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. 277 Polyzos, "A Survey of Information-Centric Networking 278 Research", IEEE Communications Surveys and Tutorials, Vol. 279 16, No. 2, pp 1024-1049, 2014, . 281 Appendix A. Acknowledgment 283 This document has been supported by the GreenICN project (GreenICN: 284 Architecture and Applications of Green Information Centric Networking 285 ), a research project supported jointly by the European Commission 286 under its 7th Framework Program (contract no. 608518) and the 287 National Institute of Information and Communications Technology 288 (NICT) in Japan (contract no. 167). The views and conclusions 289 contained herein are those of the authors and should not be 290 interpreted as necessarily representing the official policies or 291 endorsements, either expressed or implied, of the GreenICN project, 292 the European Commission, or NICT. 294 Author's Address 296 Jan Seedorf 297 NEC 298 Kurfuerstenanlage 36 299 Heidelberg 69115 300 Germany 302 Phone: +49 6221 4342 221 303 Fax: +49 6221 4342 155 304 Email: seedorf@neclab.eu