Internet Engineering Task Force S. Chen Internet-Draft CSIRO Data61 Intended status: Informational T. Hardjono Expires: 16 February 2023 MIT Q. Wang CSIRO Data61 15 August 2022 Gateway Identification and Discovery draft-chen-dlt-gateway-identification-01 Abstract [SATP] is a secure asset transfer protocol that operates between two gateways. This memo describes requirements, standards and architectural options that can be considered to identify, discover and verify gateways before transferring secure digital assets via SATP. 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." This Internet-Draft will expire on 16 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires 16 February 2023 [Page 1] Internet-Draft SATP Gateway August 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Gateway Identification . . . . . . . . . . . . . . . . . . . 4 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 4.2. DiD for Gateway Identification . . . . . . . . . . . . . 5 5. Gateway Registration and Discovery . . . . . . . . . . . . . 7 5.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Gateway DiD Repository Implementation . . . . . . . . . . 8 6. Gateway Verification . . . . . . . . . . . . . . . . . . . . 10 7. Security Consideration . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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) 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. Chen, et al. Expires 16 February 2023 [Page 2] Internet-Draft SATP Gateway August 2022 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 [SATP] employed by peered gateways is the correct identification of the systems that act as gateways, the efficient look-up/discovery of the required gateway on demand, and the correct validation of the ownership of the discovered gateway. This memo is to identify the key security requirements for a trustworthy gateway. Based on the requirements, decentralised identification description [DiD] standard is selected to describe a gateway as its identifier. Then, architectural options are presented to showcase how to use the decentralised gateway identifier for gateway discovery and verification. 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. 3. Terminology The following are some terminology used in the current document. Further terminology can be found in [Arch]. * 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 (AS). * 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 (ISP). Chen, et al. Expires 16 February 2023 [Page 3] Internet-Draft SATP Gateway August 2022 * 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. * Gateway service endpoint: The URL or URI at the gateway device that provides gateway related services, such as asset transfer/ migration services. See [SATP] for details about secure asset transfer protocol. * 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. * 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]. * Organization identity: This is a Legal Entity Identifier [LEI] or other identifier linking resource ownership to real world entity. Any schema for identifying DLT Gateway owners may be implemented , such as LEI Directory, closed group memberships, SWIFT BIC, etc. * Decentralised identifiers (DiD): is a type of identifier that enables a verifiable, decentralized digital identity. DiD consists of an unique identifier string associated with a identifier documents, in which all required properties can be described in a key-value style. 4. Gateway Identification 4.1. Requirements 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 a verifiable identity and ownership. That is, it needs to obtain assurance that (a) the device is a genesis and trusted computer system with proper security settings; (b) is operating as a gateway for a designated blockchain or decentralized ledger network (DLN) and (c) is owned by an entity operating under Chen, et al. Expires 16 February 2023 [Page 4] Internet-Draft SATP Gateway August 2022 the relevant jurisdiction in the context of the digital asset in question. In the other word, the gateway identification should provide enough information to enable the above assurance verification at both application and network layers: * Application layer: At the application layer a gateway identification scheme is needed that permits a legal organization who participates 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. * 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 [SATP]). 4.2. DiD for Gateway Identification Since the gateways are used to transfer digital assets across DLNs, they must have an unique identifier, which is discoverable globally or within a specific consortium, e.g. [SWIFT]. In addition, They also must provide enough verifiable business and security settings at both application and network level for them to verify and trust each other to ensure the security and legal compliance of the asset transfer. According to the above requirement analysis, there is a need for a data container used to host a collection of identification and security settings at both application and network (device) layers. DiD is a natural technology to meet the requirement. Applying DiD for gateway identification and verification is shown in Figure 1. +--------------+ | DiD Doc |------------------>did:Gateway:123xyz +--------------+ | ^ | | | | | | V +---------------+ +-----------+ | Gateway Owner |----------------->| Gateway | +---------------+ +-----------+ Chen, et al. Expires 16 February 2023 [Page 5] Internet-Draft SATP Gateway August 2022 Figure 1 The gateway identification must include (but not limited) the following verifiable identification information for authentication and secure channel establishment for secure asset transfer: * Authentication: The gateway must be owned/operated by a legal business entity registered with the local authority. The registration should be verifiable via 3rd-party services and/or trustworthy decentralized business directories, using standard identification schema, such as [LEI]. * Authorization: The gateway owner must be issued with a license/ certificate as authorized approval to provide virtual assets transfer services as a gateway from the corresponding blockchain foundation/authority, and register the services with well-known business directories (e.g., VASP). * Service: DiD document must include a complete service endpoint URI, or the necessary information used to construct such a URI, like SATP URI. In addition, the service endpoint identity public key should be represented using an X.509 certificate for establishing a secure channel between the two gateway peers (e.g., TLS). Optionally, some service-specific settings may be included here, such as a storage URI for SATP logging. * Device: Optionally, a gateway may be implemented in computer systems with a secure processor (TPM) [ISO/IEC 11889] or secure enclave (e.g., SGX) for assurance of device-level security. The Did document may include such information for remote attestation of the device security setting. Chen, et al. Expires 16 February 2023 [Page 6] Internet-Draft SATP Gateway August 2022 did:Gateway:123xyz { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:GatewayExample:123xyz "authentication": [{ "id": "5493-00-84UKLVMY22DS-16", "type": "LEI", ...... }] "Authorization": [{ "id": "abc-123", "type": "VASP", ...... }] "Service": [{ "end-point": "satres://..........", "type": "SATP" ...... }] } Figure 2 5. Gateway Registration and Discovery In this section, an overall architecture is proposed to support the gateway registration and discovery. Three implementation options are discussed. The basic CURD operations that a DiD repository must implement are provided. 5.1. Architecture A given asset service provider may possess multiple nodes within one or more DLNs. No matter what consensus model is applied in a DLN, it is desirable that the DLN has one or more gateways capable of participating in an asset transfer between two DLNs. As such, there must be some mechanism that permits these gateway owners to declare their DiD as a gateway into a given DLN. Chen, et al. Expires 16 February 2023 [Page 7] Internet-Draft SATP Gateway August 2022 To make a gateway widely discoverable, the gateway owner should follow the common Publish/Lookup design pattern [UDDI] by registering the gateway's DiD with a public DiD repository for other gateways or applications to look up. The process is shown in Figure 3. +----------------+ 2. Lookup +------>| DiD Repository |<------+ 1. Register | +----------------+ | | | | | +------+ +-----+ 3. Mutual Verify +-----+ +------+ | DLN1 |--->| GW1 |<------------------------>| GW2 |--->| DLN2 | +------+ +-----+ 4. SATP Transfer +-----+ +------+ Figure 3 First of all, GW2 registers its DiD with the DiD Repository as shown Step 1 in Figure 3. When another gateway (GW1) wants to transfer digital assets from DLN1 to DLN2, GW1 can discover GW2 by querying its DiD from the DiD repository as shown Step 2 in Figure 3. With the resolved DiD of GW2, GW1 can request a mutual verification with GW2 by sending its DiD string as shown Step 3 in Figure 3. Once GW1 and GW2 establish a trusted channel after passing all verification, they can start a SATP asset transfer as shown Step 4 in Figure 3. This discovery and verification processes 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 GW1 and GW2. 5.2. Gateway DiD Repository Implementation A public DiD repository can be implemented using one of the following system architectures: * Centralized client/server architecture: It is a mature system architecture and can be easily implemented. The disadvantage of this architecture is that all users have to trust the centralized server, which violates the design principle of DiD. * Decentralized Ledger: A nature implementation is to use blockchain/DLN directly. There have already such implementations under development, such as [SOVRIN] and [BTCR]. Chen, et al. Expires 16 February 2023 [Page 8] Internet-Draft SATP Gateway August 2022 * DNS - Domain Naming Service [RFC2181]: can be leveraged and/or extended to support DiD registration and discovery. These gateways can even form a DNS-like distributed DiD repository system to enable gateway registration and discovery by themselves. No matter which above architecture to be adopted, the DiD repository service must support the basic CRUD operations via standard API or SDK as follows: * Create (Register): The DiD repository system must specify how a client creates a DID record in the repository. - Input: A DiD string with its associated document - Output: A DiD record created in the repository if successful To do so, the DiD repository system must conduct all cryptographic and non-cryptographic operations to ensure the correctness and ownership of the DiD to register. In addition, DiD repository may design and add specific metadata attached to a DiD record to help a particular class of clients easily to query a particular gateway, such as "Gateways for Bitcoin" or "ateways for Bitcoin for clients in Asia-Pacific". * Read (Resolver): Given a DiD string, the DiD repository must be able to resolve the DiD string by returning a valid DiD document if the DiD string is valid. - Input: A DiD string - Output: its corresponding DiD document if successful Due to the verity of the ways to obtain a DiD string, how to look up a DiD string is beyond of this memo. * Update (Reversion): From time to time, a gateway owner may want to update its gateway, e.g. add a new service. As a result, the DiD repository system should allow the gateway owner to update its existing DiD, subject to passing the required security verification: - Input: A DiD string with a new DiD document or a set of attributes to update - Output: The existing DiD record is updated or a reversion is created Chen, et al. Expires 16 February 2023 [Page 9] Internet-Draft SATP Gateway August 2022 Note that due to the immutability of blockchain/DLT, a reversion of the DiD to be updated may be created, instead of updating, for a decentralized implementation. * Delete (Revoke): a DiD repository must also allow a gateway owner to delete/revoke its existing DiD. While implementations may be different for different architectures, the DiD repository must ensure the DiD will never be used once being deleted although the record cannot be deleted persistently. There are a few on-going projects in developing such decentralised DiD repository systems, e.g., [TVDR] 6. Gateway Verification Once a gateway (DW1) obtains another gateway (DW2)'s DiD, it can initialize a session with its gateway peer for mutual verification. The high-level process/protocol is presented in Figure 4. +------+ +-----+ +----------------+ +-----+ +------+ | DLN1 | | GW1 | | DiD Repository | | GW2 | | DLN2 | +---+--+ +--+--+ +--------+-------+ +--+--+ +---+--+ |-----1--->| | | | | +---------2----->| | | | |<--------3------+ | | | | | | | | |----------------4-------------->| | | | |<-------5------+ | | | +--------6----->| | | | | | | | |<-------7-----------------------| | | |-------------------------8----->| | | | ...... | | | | +----9---->| | |<-------10----------------------+ | Figure 4 1. DLN1: request to transfer an asset to an address with DLN2 2. DW1: request for DLN2's DiD Doc from the DiD Repository 3. DiD Repository: resolve and return DLN2's DiD Doc 4. DW1: after passing DLN2's DiD verification, request for a mutual verification by sending itself DiD string 5. DW2: request for DLN2's DiD Doc from the DiD Repository Chen, et al. Expires 16 February 2023 [Page 10] Internet-Draft SATP Gateway August 2022 6. DiD Repository: resolve and return DLN1's DiD Doc 7. DW2: Send ACK if passing DLN1's DiD verification 8. DW1: start a SATP tranfer 9. DW2: If everything is OK, write/mint the transferred asset to DLN2 10. DW2: send ACK to notify DW1 Note that the above protocol has been simplified. The actual verification process may involve one or more the trusted 3rd-part to help verify some of the business qualifications and security capabilities defined in the DiD docs. And there are more than one interactions between DW1 and DW2 according to the transfer type and SATP protocol. 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 [RFC2660] 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 [RFC2535]. 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 bound to these types of trusted hardware, coupled with their attestation capabilities, may significantly enhance the security and trust between the gateways to conduct blockchain asset transfer services collaboratively. * Given the important roles that the DLNs? gateways will play, their IP address should be regarded as ASN (Autonomous System Number) and assigned by IANA's RIRs (Regional Internet Registries), such Chen, et al. Expires 16 February 2023 [Page 11] Internet-Draft SATP Gateway August 2022 as ARIN (the American Registry for Internet Numbers) and dedicated to DLN gateway servers. This will greatly enhance the security and trust of the BGSP's services, due to the high bar to secure an ASN. 8. References 8.1. Normative References [DiD] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0", 19 July 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 1 March 2021, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1 March 2005, . [RFC2616] Fielding, R., Mogul, J., MMasinter, L., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1 June 1999, . [RFC2660] Rescorla, E. and A. Schiffman, "Clarifications to the DNS Specification", 1 August 1999, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", 1 March 2005, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Chen, et al. Expires 16 February 2023 [Page 12] Internet-Draft SATP Gateway August 2022 [UDDI] Clement, L., Hately, A., Riegen, C., and T. Rogers, "UDDI Version 3.0.2, published by OASIS", 19 October 2004, . 8.2. Informative References [ARCH] Hardjono, T., Hargreaves, M., and N. Smith, "An Interoperability Architecture for Blockchain Gateways. draft-hardjono-blockchain-interop-arch-02", 21 April 2021, . [BTCR] Duffy, K.H., Grant, R., and C. Allen, "BTCR DIDs and DDOs", 1 May 2022, . [FATF] FATF, "International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation - The FATF Recommendations", March 2022, . [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted Computing Base for Blockchain Infrastructure Security, Frontiers Journal, Sepcial Issue on Blockchain Technology, Vol. 2, No. 24", December 2019, . [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", October 2018, . [SATP] Hargreaves, Q., Hardjono, T., and R. Belchior, "Secure Asset Transfer Protocol", 2 May 2022, . [SOVRIN] Lodder, M. and D. Hardman, "Clarifications to the DNS Specification", 1 May 2022, . [TVDR] Compellio.io, "Tezos Verifiable Data Registry", 1 July 2022, . Chen, et al. Expires 16 February 2023 [Page 13] Internet-Draft SATP Gateway August 2022 Authors' Addresses Shiping Chen CSIRO Data61 Email: shiping.chen@data61.csiro.au Thomas Hardjono MIT Email: hardjono@mit.edu Qin Wang CSIRO Data61 Email: qin.Wang@data61.csiro.au Chen, et al. Expires 16 February 2023 [Page 14]