Internet Engineering Task Force S. Chen Internet-Draft Data61 Intended status: Informational T. Hardjono Expires: December 10, 2021 MIT June 8, 2021 Gateway Identification and Discovery for Decentralized Ledger Networks draft-chen-dlt-gateway-identification-00 Abstract Today there is a growth in the number of blockchain and decentralized ledger networks (DLN) around the world, and interoperability across different networks represents a challenge for the value proposition of these networks. One approach for blockchain interoperability to be achieved is to employ gateways that permit assets to flow across the relevant networks of blockchains. However, a core requirement for interoperability is the correct identification of computer systems that act as gateways and the correct validation of the ownership of the gateway. A secondary requirement is for a gateway to inquire as to the existence of an entity address (public key) within a given decentralized ledger network. This memo discusses options with regards gateway identification and verification strategies. It looks at addressing the problem from the application layer and from the network layer. It also discusses other options, such as relying on a third-party blockchain-registered identifiers and resolver services 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 https://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." Chen & Hardjono Expires December 10, 2021 [Page 1] Internet-Draft DLT Gateway Identification June 2021 This Internet-Draft will expire on December 10, 2021. Copyright Notice Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) in effect on the date of 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. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Gateway Registration, Discovery and Validation . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Gateway Declaration and Registration . . . . . . . . . . 5 4.3. Gateway Discovery and Validation . . . . . . . . . . . . 6 4.4. Verification of Identities and Addresses . . . . . . . . 6 5. Network Layer Gateway Discovery and Verification . . . . . . 7 5.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 7 5.2. DNS-based Gateway Discovery . . . . . . . . . . . . . . . 8 6. Application Layer Gateway Discovery and Verification . . . . 9 7. Security Consideration . . . . . . . . . . . . . . . . . . . 11 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Currently there is a growth in the number of blockchain and distributed ledger technology (DLT) systems being deployed worldwide for different areas of applications (e.g. finance, supply chains, IoT devices, etc.). One notable application is in the area of digital assets (or virtual assets) [FATF]. As independent autonomous systems, each decentralized ledger network (DLN) employs its own interior protocols (e.g. consensus protocols) Chen & Hardjono Expires December 10, 2021 [Page 2] Internet-Draft DLT Gateway Identification June 2021 that manages the resources (e.g. shared ledger) relevant to the assets and entities in that network. Key to the success of the blockchain and DLT paradigm is the interoperability between DLNs, permitting digital assets to be moved across DLNs in an efficient and secure manner. For the purposes of asset transfers across DLNs, one or more nodes within a DLN can take-on the role of a gateway that peers with other gateways belonging to other DLNs [ARCH]. As a node participating in a blockchain, a gateway has access to the resources (e.g. ledger) located in the interior of that blockchain. Facing outbound, the gateway has the ability to peer with matching gateways to facilitate asset transfers. A core requirement for the gateway-to-gateway protocol [ODAP] employed by peered gateways is the is the correct identification of the systems that act as gateways and the correct validation of the ownership of the gateway. Gateway ownership is notably important in cases where a digital asset bearing economic value is to be transferred cross-border (cross regulatory jurisdictions). (a) Application layer: At the application layer a gateway identification scheme is needed that permits an organization who participate in a given DLN to declare (advertise) one or more gateways into that DLN. This permits organizations to establish peering agreements (contracts) based on the asset type, DLN and jurisdictions, identifying (specifying) the gateways that will be used to connect to the DLN. (b) Network layer: In order for asset transfer services to scale-up, some degree of automation is needed for a gateway to discover peer gateways in remote DLN. This discovery must be efficient in order to minimize the time required for a digital asset from an originator in an origin DLN to be transferred cross-chain to the beneficiary in the destination DLN (see [ODAP]). 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. Chen & Hardjono Expires December 10, 2021 [Page 3] Internet-Draft DLT Gateway Identification June 2021 3. Terminology The following are some terminology used in the current document. Further terminology can be found in [NIST][OSI]. o Decentralized ledger network (DLN): A blockchain system or an implementation of a decentralized ledger technology (DLT) consisting nodes that shares a common set of resources. This term is used generically to refer to the collection of nodes as an autonomous system. o DLN identification number: This is the unique network identification for a DLN. This is akin to the AS-number issued by ARIN in North America for autonomous systems operated by Internet Service Providers. o Device identity: This is the unique public-private key pair that is bound to the device (e.g. hardware) of the gateway. Examples include the IEEE 802.1AR Secure Device Identity [DevID] and the TPM EK/AIK key pair [TPM]. The device identity public key may be represented using an X.509 certificate. o Gateway service endpoint: The URL or URI at the gateway device that provides gateway related services, such as asset transfer/ migration services. See [ODAP] for a definition of the ODAP protocol. o Service endpoint identity: This is the unique public-private key pair bound to the protocol service end-point of the gateway function. This key-pair is used in the establishment of a secure channel with a peer gateway (e.g. TLS). The endpoint identity public key should be represented using an X.509 certificate, which unambiguously states the purpose of the endpoint. o Owner identity: This is the unique public-private key pair of the entity who legally owns and operates the gateway. For clarity this entity is referred to as a virtual asset service provider (VASP). The VASP identity public key should be represented using an X.509 certificate, possibly including extended fields such as those found in Extended Validation (EV) X.509 certificates [CAB]. o Blockchain gateway service provider (BGSP): The virtual asset service provider that owns and operates the gateway service. The term provides distinction from a technical/protocol perspective, since a BGSP entity is a virtual asset service provider in the business and regulatory sense. Chen & Hardjono Expires December 10, 2021 [Page 4] Internet-Draft DLT Gateway Identification June 2021 4. Gateway Registration, Discovery and Validation 4.1. Overview In the context of a digital asset transfer, a gateway identification, discovery and verification solution consists of mechanisms that permit a local gateway to obtain assurance that a given remote device is a gateway with verifiable identity and ownership. That is, it need to obtain assurance that (a) the device is operating as a gateway for a designated blockchain or decentralized ledger network and (b) is owned by an entity operating under the relevant jurisdiction in the context of the digital asset in question. (i) gateway identity authentication: verification that the device with a given identification truly functions as a gateway (and not a rouge server masquerading as a gateway); (ii) gateway ownership validation: verification that a remote gateway is owned by the organization (e.g. VASP) that is operating within a given jurisdiction; (iii) asset type transferability: verification that a remote gateway for a destination DLN is mechanically capable to receive the type of asset and that legally permitted to receive the type of asset. 4.2. Gateway Declaration and Registration A given asset service provider may possesses multiple nodes within one or more DLNs globally. Depending on the specific technical constraints of a given DLN (e.g. consensus model), not every node within the DLN may be designated to be a gateway capable of participating in an asset transfer between two DLNs. As such, the service provider must nominate its nodes or systems specifically as gateways. As such, there must be some mechanism that permits the asset service provider to declare that a given device or system serves as a gateway into a given DLN. One possible approach is for the service provider to publish a signed list of the gateways and the endpoints that implement the cross-chain asset transfer protocol for a given asset type. Extending this notion, a directory of gateways may be established by a group or consortium of asset service providers as a means to share a common location where gateway information can be found. This directory approach is currently already being develop by some asset service providers in the context originator/beneficiary data for compliance to the Travel Rule regulations [FATF] dealing with anti-money laundering (AML). An example is the TRISA directory Chen & Hardjono Expires December 10, 2021 [Page 5] Internet-Draft DLT Gateway Identification June 2021 [TRISA], which lists business information of virtual asset service providers (VASP) claiming compliance to the AML regulations. Such a directory could be extended to include the gateways owned and operated by the VASPs. 4.3. Gateway Discovery and Validation When an originator (sender) in an origin DLN1 seeks to transfer digital assets to a beneficiary (recipient) located in a remote destination DLN2, a gateway G1 in DLN1 must be able locate and validate one (or more) gateways G2 serving DLN2. This discovery process must be automated as far as possible, and discovery should not require human intervention. If a directory of gateways is available, then it should be utilized by both gateways G1 and G2. Discovery, therefore, covers a number of layers and functions: o Gateway network device discovery: There must be a mechanism to discover the gateway at the IP network layer (e.g. IP address, port number) and obtain the device identity of the gateway (e.g. LDevID or device public key). o Gateway service endpoint discovery and validation: Following the device discovery, there must be a mechanism to discover and verify the endpoint at the gateway that provide services related to its role as a gateway. These include the endpoint for asset transfers and the endpoint for crash recovery [Crash]. 4.4. Verification of Identities and Addresses In many cases, an originator (sender) in an origin DLN1 may be in possession only of the beneficiary?s name and blockchain-address. This means that the gateway G1 in DLN1 must ensure that the beneficiary?s address exists in the DLN2 and that it is bound to the beneficiary entity or user in DLN2. Although out scope for the current work, it is perhaps worth noting that the responsibility of verifying the identity and legal status of originators and beneficiaries lies with the virtual asset service providers who employ technical mechanism (including gateways and nodes) to transact the digital assets [FATF]. Chen & Hardjono Expires December 10, 2021 [Page 6] Internet-Draft DLT Gateway Identification June 2021 5. Network Layer Gateway Discovery and Verification Gateway discovery and verification at the network layer takes a bottom-up strategy, where a gateway discovers a peer remote gateway and initiates verifications. This is part of Phase-1 of the gateway architecture [ARCH]. This approach mimics the client to MTA (Message Transfer Agent) interaction pattern in the classic SMTP mail transfer protocol [RFC2821]. 5.1. Prerequisites To ensure the safety of the transferred digital assets, blockchain gateway service providers (BGSP) must be trustworthy to clients who use the services. As a result, they must meet a high standard to ensure security and trust at different levels, ranging from business to networking, from hardware device to software protocol. In particular, the following basic prerequisites (but not limited to) must be met: o They must be a legal business entity registered with local authority. The registration should be certified in form of a verifiable digital certificate. o They must apply for an Autonomous System (AS) number [RFC6996] from ARIN, or other region networking authorities (such as RIPE NCC for Europe and APNIC for East and South Asia), dedicated to their gateway IP addresses, e.g., 888.10.10.10 o The IP address should be bound to a meaningful domain name by registering in DNS [RCF1034, RFC1035], e.g., G1.DLT1.com. o To be better discovered, a number of canonical names are registered in DNS as CNAME record as shown in Table 1. o In addition, BGSP(s) should also be issued with a license/ certificate as authorized approval to provide blockchain gateway services from the corresponding blockchain foundation/authority, and register their services with well-known business directories and publish on the Internet. Based on the above prerequisites, blockchain gateways can discover each other to establish trust step by step for digital asset transfer using either bottom-up or top-down approach. Chen & Hardjono Expires December 10, 2021 [Page 7] Internet-Draft DLT Gateway Identification June 2021 Domain/Name Type Host/Destination G1.DLT1.com A 888.10.10.10 DLT1 CNAME G1.DLT1.com G2.DLT2.com A 999.10.10.10 DLT2 CNAME G2.DLT1.com Figure 1 5.2. DNS-based Gateway Discovery This is a bottom-up approach to blockchain gateway discovery as shown in the Figure below. (Figure TBD - DNS-based Gateway Discovery) Figure 2 Client (Alice) wants to transfer a certain value of digital assets (v) from one blockchain (DLT1) to another client (Bob) on anther blockchain (DLT2), which can be represented in ERC20 as follows: transfer(Bob_PublicKey@DLT2, v) The following MTA-Style protocol is specified for gateway networking device discovery: o Alice can send the transfer request to G1 directly if Alice trusts G1 and G1 is pre-configured in Alice wallet; Or Alice can discover G1 and establish trust with G1 by following the same protocol as described below. o As a result of receiving Alice's request, G1 lookup a gateway for DLT2 via DNS and DNS returns G2's IP address, e.g., 999.10.10.10 o (Optional) G1 can verify the ownership of the received IP address with 3rd party service to ensure if G2 is trustworthy. o G1 sends a request for exchanging business certificate (BC) by embedding its business certificate in the request, which can be specified in the json format (see Figure). Chen & Hardjono Expires December 10, 2021 [Page 8] Internet-Draft DLT Gateway Identification June 2021 o If G1's certificate is valid, G2 will reply by sending its business certificate as specified (see Figure). o (Optional) G1 may request for verification of Bob's blockchain address (public key) and (optional) his living location (for tax purpose) with DLT2. { "Request": { "CMD": "ExchangeBC", "Certificate": { . . . } } } Figure 3 { "Response": { "Certificate": { . . . } } } Figure 4 Up to this point, G1 and G2 establish trust at both business and network levels enough and ready to start the transfer digital asset (v) via the asset transfer protocol [ODAP]. 6. Application Layer Gateway Discovery and Verification Another approach that is commonly adopted by a community of service providers is for the community to share information regarding standardized service endpoints (e.g. REST APIs). There are multiple ways for a community of consortium of entries to share endpoints information, including a centralized signed-list or database, a replicated distributed database and more recently listing mechanisms based on blockchains (e.g. DIDs). In the following, the term business directory is used generically to represent the list. An example of this approach is the TRISA directory currently being developed for Travel Rule sharing [TRISA]. Depending on the community of consortium, the information in the directory may be Chen & Hardjono Expires December 10, 2021 [Page 9] Internet-Draft DLT Gateway Identification June 2021 publicly readable or it may be accessible only to members of the community. Applying this approach to gateways, a business entities who participate in the directory must proactively register (publish) its gateways and the DLN for which each gateway speaks. The information must include minimally the following: (a) the gateway device identity, (b) one of more blockchains (DLNs) served by the gateway, (c) the identity of the business entity (e.g. asset service provider), (d) expiration of the information in the directory. This information must be source authentic (i.e. digitally signed) by entity registering it. (Figure TBD - Application Layer Gateway Discovery and Verification) Figure 5 Suppose that BGSP-1 and BGSP-2 provide blockchain gateway services for DLT1 and DLT2 with G1 and G2, respectively and both register with business directories and publish their services on the Internet. As a result, they should easily discover each other. o BGSP-1 finds BGSP-2 via one of global business directories (or even Google), or vice versa. Then, they negotiate each other with aim to establish a business collaboration via providing cross- chain asset transfer services between DLT1 and DLT2 offline. As a result of successful negotiation, BGSP-1 and BGSP-2 both signs a legal business contract for the collaboration, including agreements about (but not limited to) the network configuration, security setting, and transfer protocols to be used. o Up to the agreement signed, BGSP-1 and BGSP-2 can configure each network and gateway servers according to the agreed settings. o At runtime, when receiving a transfer request from a client (Alice), G1 can send a handshaking request to G2 directly for establishing secure channel for transferring digital asset (v) via the asset transfer protocol [ODAP]. Chen & Hardjono Expires December 10, 2021 [Page 10] Internet-Draft DLT Gateway Identification June 2021 7. Security Consideration In addition to the basic security setting mentioned above, the following technologies can also be considered as either enhancement or alternatives of security settings: HTTPS/TLS: Whenever using HTTP [RFC2616] for the protocol execution, HTTPS/TLS [RFC2821] must be enabled by default against eavesdropping attack. DNSSEC: is a set of extensions to DNS that uses asymmetric cryptography to provide origin authentication and integrity checking for DNS data [RFC 2535]. DNSSEC ensures not just the origin of the DNS record, but also its integrity, which thus enhances the security and trust of the blockchain gateway queries if adopting DNSSEC. Trusted hardware and attestations: Gateways may be implemented in computer systems possessing a secure processor (e.g. TPM)[ISO/IEC 11889] or secure enclave (e.g. SGX). For example, server machines can store security keys and conducts common security operations for hardware authentication and authorization. The use of device-unique public key pairs boiund to these types of trusted hardware, copled with their attestations capabilities, may significantly enhance the security and trust between the gateways to conduct blockchain asset transfer services collaboratively. 8. IANA Consideration (TBD) 9. References 9.1. Normative References [FATF] FATF, "International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation - FATF Revision of Recommendation 15", October 2018, . [ISO] ISO, "Blockchain and distributed ledger technologies- Vocabulary (ISO:22739:2020)", July 2020, . [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", October 2018, . Chen & Hardjono Expires December 10, 2021 [Page 11] Internet-Draft DLT Gateway Identification June 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . 9.2. Informative References [ARCH] Hardjono, T., Hargreaves, M., and N. Smith, "An Interoperability Architecture for Blockchain Gateways. draft-hardjono-blockchain-interop-arch-02", April 2021, . [BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway Crash Recovery Mechanism, IETF, draft-belchior-gateway- recovery-01.", March 2021, . [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset Protocol, IETF, draft-hargreaves-odap-01.", November 2020, . [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, September 2010, . [TRISA] TRISA, "Travel Rule Information Sharing Architecture for Virtual Asset Service Providers", August 2020, . Authors' Addresses Shiping Chen Data61 Email: shiping.chen@data61.csiro.au Chen & Hardjono Expires December 10, 2021 [Page 12] Internet-Draft DLT Gateway Identification June 2021 Thomas Hardjono MIT Email: hardjono@mit.edu Chen & Hardjono Expires December 10, 2021 [Page 13]