One document matched: draft-seedorf-icn-wot-selfcertifying-00.txt
ICNRG J. Seedorf
Internet-Draft NEC
Intended status: Informational June 25, 2014
Expires: December 27, 2014
Binding Self-certifying Names to Real-World Identities with a Web-of-
Trust
draft-seedorf-icn-wot-selfcertifying-00
Abstract
Self-certifying names are one way of binding a given public key to a
certain name in Information Centric Networking. However, an
additional binding of a self-certifying name to a Real-World identity
is needed in most cases, so that a recipient of some information
cannot only verify that the publisher was in possession of the
correct corressponding private key for the requested name, but that
in addition the name itself is the intended one. This draft
specifies how such a binding of Real-World identities with self-
certifying ICN names can be done, taking existing IETF specifications
into account.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 27, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Seedorf Expires December 27, 2014 [Page 1]
Internet-Draft ICN WOT June 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. High-Level Design . . . . . . . . . . . . . . . . . . . . . . 3
3. Standardisation Considerations . . . . . . . . . . . . . . . 4
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Self-certifying names provide the useful property that any entity in
a distributed system can verify the binding between a corresponding
public key and the self-certifying name without relying on a trusted
third party [Aura2003]. Self-certifying names thus provide a
decentralized form of data origin authentication. This feature makes
self-certifying names a prime candidate for addressing the security
requirements in Information Centric Networking (ICN) (which are
inherently different from IP networks): a source can digitally sign
data associated with a self-certifying name, and any intermediate
entity (e.g. ICN-router/Cache) or receiving entity (i.e. issuer of a
request for the name) can verify the signature, without the need to
verify the identity of the host that caches the object, nor relying
on a trusted third party, or a Public Key Infrastructure (PKI).
However, as noted in [Ghodsi2011] and elsewhere, self-certifying
names lack a binding with a corresponding real-world identity (RWI):
the concept enables to verify that whoever signed some data was in
possession of the private key associated with the self-certifying
name, but it does not provide any means to verify what real-world
identity corresponds to the public key, i.e. who actually signed the
data [Ghodsi2011] [Nom2014].
In principle, this binding between a public key and an RWI could be
provided by a PKI, or alternatively by a Web-of-Trust (WoT)
[Ghodsi2011]. Several ICN approaches use a PKI [Survey] . However,
until recently, there have not been concrete proposals for a WoT-
based approach for binding a public key (or a self-certifying name)
with an RWI in content-oriented architectures. A concrete approach
Seedorf Expires December 27, 2014 [Page 2]
Internet-Draft ICN WOT June 2014
on how this can be done has been proposed in [Nom2014]. This
document has the objective of providing the corresponding necessary
standards specification to enable this approach (or similar ones) in
principle in an interoperable way.
2. High-Level Design
On a high level, binding of self-certifying names and a Web-of-Trust
can be achieved in the following way (see [Nom2014] for a detailed
example of such an approach): The WoT key-ID is equivalent to the
self-certifying name part used in the naming scheme. This ties the
self-certifying name with the ID of the corresponding public key in
the WoT.
For instance, in the existing PGP Web-of-Trust, the V4 key ID is the
lower 64 bits of the fingerprint of the public key, where the
fingerprint is essentially the 160-bit SHA-1 hash of the public key
[RFC2440]. So if a self-certifying name would be based on the same
lower 64-bits of the fingerprint of a given public key, this public
key would be tied to the self-certifying name and at the same time be
tied to the real-world identity used in the WoT, e.g. an email-
address or the real (i.e. non-self-certifying) name of a given ICN
publisher.
Thus, if a user requests the content for a self-certifying name in a
given ICN architecture, he/she would retrieve the content which
contains a digital signature and the corresponding public key for the
self-certifying name. The user can then verify that the content
retrieved indeed belongs to the name by first hashing the public key
and confirm that the hash (or part of it) matches the requested name,
and second using the public key to verify the signature over the
content. This is in principle the general way of using self-
certifying names for data origin authentication in distributed
systems. If, in addition, (part of) the self-certifying name is
equivalent to a WoT key-ID, the user can use any WoT infrastructure
(e.g. PGP keyservers) to retrieve certificates for the key ID that
contain/confirm the binding between the corresponding (to the WoT key
ID) public key with a real-world identity, such as an email address.
This binding provides the requesting user with assurance that the
self-certifying name indeed is owned by the intended publisher, i.e.
is the correct, intended name from the requestor's perpective.
The current PGP specification [RFC2440] considers only a bitlength of
64-bit for forming the key-ID, which is not very collision-resistant
(collision-resistance among different key-IDs was not a design goal
for PGP [RFC2440]). For securely binding a self-certifying name to a
WoT key-ID, collision-resistance is a design goal, because otherwise
attckaers could potentially forge a binding of their public key with
Seedorf Expires December 27, 2014 [Page 3]
Internet-Draft ICN WOT June 2014
a given self-certifying name. Thus, either a longer bitlength of the
hash of the public key (or its fingerprint) must be used, or hash
extension techniques [Aura] must be used, which effectively make
collision attacks harder for constant bitlengths at the price of the
time needed to create a public/private key pair. Future versions of
this document will take these design considerations into account.
3. Standardisation Considerations
Future versions of this document will outline a concrete protocol
specification for binding self-certifying names to a Web-of-Trust as
outlined on a high level in the previous Section. Below some initial
standardisation considerations are highlighted. Also, future
versions of this document will look in more detail into existing IETF
specifications, e.g. regarding ICN naming ([RFC6920]) and Web-of-
Trust ([RFC2440]), and inspect to what extend such existing
specifications can be used directly or in a modified form.
An initial list of details that need to be specified is the
following:
o (List of) Asymmetric cryptography algorithm(s) and corresponding
bit-length(s)
o (List of) Hash algorithm(s) and corresponding bit-length(s)
o Rules that define what part of the hash is used for forming the
self-certifying part of the name
o Rules for forming a self-certifying name based on a public key
o Semantics of a signature in the Web-of-Trust
o Defintion of the web-of-trust key-ID and how it relates to the
self-certifying name
o Defintion of how many bits are used in case of hash extension
techniques [Aura]
4. Conclusion
One option for binding self-certifying names to real-world identities
is using a Web-of-Trust. This document aims at a concrete
specification for providing such a binding, taking existing IETF
specification into account. Future versions of this document will
provide a more detailed specification.
Seedorf Expires December 27, 2014 [Page 4]
Internet-Draft ICN WOT June 2014
5. References
5.1. Normative References
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, April 2013.
5.2. Informative References
[Aura] Aura, T. and M. Roe, "Strengthening Short Hash Values",
http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.145.7681, .
[Aura2003]
Aura, T., "Cryptographically Generated Addresses (CGA)",
6th International Conference on Information Security
(ISC), 2003, .
[Ghodsi2011]
Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and
S. Shenker, "Naming in Content-oriented Architectures",
ACM SIGCOMM Workshop on Information-centric Networking,
2011, .
[I-D.seedorf-icn-disaster]
Arumaithurai, M., Seedorf, J., Tagami, A., Ramakrishnan,
K., and N. Blefari-Melazzi, "Using ICN in disaster
scenarios", draft-seedorf-icn-disaster-01 (work in
progress), October 2013.
[Nom2014] Seedorf, J., Kutscher, D., and F. Schneider,
"Decentralised Binding of Self-Certifying Names to Real-
World Identities for Assessment of Third-Party Messages in
Fragmented Mobile Networks", 2nd Workshop on Name Oriented
Mobility (NOM), 2014, .
[Survey] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N.,
Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G.
Polyzos, "A Survey of Information-Centric Networking
Research", IEEE Communications Surveys and Tutorials, Vol.
16, No. 2, pp 1024-1049, 2014, .
Seedorf Expires December 27, 2014 [Page 5]
Internet-Draft ICN WOT June 2014
Appendix A. Acknowledgment
This document has been supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Networking
), a research project supported jointly by the European Commission
under its 7th Framework Program (contract no. 608518) and the
National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project,
the European Commission, or NICT.
Author's Address
Jan Seedorf
NEC
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 221
Fax: +49 6221 4342 155
Email: seedorf@neclab.eu
Seedorf Expires December 27, 2014 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 09:04:34 |