idnits 2.17.00 (12 Aug 2021) /tmp/idnits11931/draft-chen-dlt-gateway-identification-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 8, 2021) is 340 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'OSI' is mentioned on line 146, but not defined == Missing Reference: 'DevID' is mentioned on line 161, but not defined == Missing Reference: 'TPM' is mentioned on line 162, but not defined == Missing Reference: 'CAB' is mentioned on line 182, but not defined == Missing Reference: 'Crash' is mentioned on line 267, but not defined == Missing Reference: 'RFC2821' is mentioned on line 460, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC6996' is mentioned on line 306, but not defined == Missing Reference: 'RCF1034' is mentioned on line 312, but not defined == Missing Reference: 'RFC1035' is mentioned on line 312, but not defined == Missing Reference: 'RFC2616' is mentioned on line 459, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC 2535' is mentioned on line 465, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Unused Reference: 'ISO' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'BCH21' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC5939' is defined on line 533, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-03) exists of draft-hardjono-blockchain-interop-arch-02 == Outdated reference: A later version (-03) exists of draft-belchior-gateway-recovery-01 == Outdated reference: A later version (-03) exists of draft-hargreaves-odap-01 Summary: 4 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Chen 3 Internet-Draft Data61 4 Intended status: Informational T. Hardjono 5 Expires: December 10, 2021 MIT 6 June 8, 2021 8 Gateway Identification and Discovery for Decentralized Ledger Networks 9 draft-chen-dlt-gateway-identification-00 11 Abstract 13 Today there is a growth in the number of blockchain and decentralized 14 ledger networks (DLN) around the world, and interoperability across 15 different networks represents a challenge for the value proposition 16 of these networks. 18 One approach for blockchain interoperability to be achieved is to 19 employ gateways that permit assets to flow across the relevant 20 networks of blockchains. 22 However, a core requirement for interoperability is the correct 23 identification of computer systems that act as gateways and the 24 correct validation of the ownership of the gateway. A secondary 25 requirement is for a gateway to inquire as to the existence of an 26 entity address (public key) within a given decentralized ledger 27 network. 29 This memo discusses options with regards gateway identification and 30 verification strategies. It looks at addressing the problem from the 31 application layer and from the network layer. It also discusses 32 other options, such as relying on a third-party blockchain-registered 33 identifiers and resolver services 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 10, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Conventions used in this document . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Gateway Registration, Discovery and Validation . . . . . . . 5 72 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Gateway Declaration and Registration . . . . . . . . . . 5 74 4.3. Gateway Discovery and Validation . . . . . . . . . . . . 6 75 4.4. Verification of Identities and Addresses . . . . . . . . 6 76 5. Network Layer Gateway Discovery and Verification . . . . . . 7 77 5.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 7 78 5.2. DNS-based Gateway Discovery . . . . . . . . . . . . . . . 8 79 6. Application Layer Gateway Discovery and Verification . . . . 9 80 7. Security Consideration . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Currently there is a growth in the number of blockchain and 90 distributed ledger technology (DLT) systems being deployed worldwide 91 for different areas of applications (e.g. finance, supply chains, IoT 92 devices, etc.). One notable application is in the area of digital 93 assets (or virtual assets) [FATF]. 95 As independent autonomous systems, each decentralized ledger network 96 (DLN) employs its own interior protocols (e.g. consensus protocols) 97 that manages the resources (e.g. shared ledger) relevant to the 98 assets and entities in that network. Key to the success of the 99 blockchain and DLT paradigm is the interoperability between DLNs, 100 permitting digital assets to be moved across DLNs in an efficient and 101 secure manner. 103 For the purposes of asset transfers across DLNs, one or more nodes 104 within a DLN can take-on the role of a gateway that peers with other 105 gateways belonging to other DLNs [ARCH]. As a node participating in 106 a blockchain, a gateway has access to the resources (e.g. ledger) 107 located in the interior of that blockchain. Facing outbound, the 108 gateway has the ability to peer with matching gateways to facilitate 109 asset transfers. 111 A core requirement for the gateway-to-gateway protocol [ODAP] 112 employed by peered gateways is the is the correct identification of 113 the systems that act as gateways and the correct validation of the 114 ownership of the gateway. Gateway ownership is notably important in 115 cases where a digital asset bearing economic value is to be 116 transferred cross-border (cross regulatory jurisdictions). 118 (a) Application layer: At the application layer a gateway 119 identification scheme is needed that permits an organization who 120 participate in a given DLN to declare (advertise) one or more 121 gateways into that DLN. This permits organizations to establish 122 peering agreements (contracts) based on the asset type, DLN and 123 jurisdictions, identifying (specifying) the gateways that will be 124 used to connect to the DLN. 126 (b) Network layer: In order for asset transfer services to scale-up, 127 some degree of automation is needed for a gateway to discover peer 128 gateways in remote DLN. This discovery must be efficient in order to 129 minimize the time required for a digital asset from an originator in 130 an origin DLN to be transferred cross-chain to the beneficiary in the 131 destination DLN (see [ODAP]). 133 2. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 In this document, these words will appear with that interpretation 140 only when in ALL CAPS. Lower case uses of these words are not to be 141 interpreted as carrying significance described in RFC 2119. 143 3. Terminology 145 The following are some terminology used in the current document. 146 Further terminology can be found in [NIST][OSI]. 148 o Decentralized ledger network (DLN): A blockchain system or an 149 implementation of a decentralized ledger technology (DLT) 150 consisting nodes that shares a common set of resources. This term 151 is used generically to refer to the collection of nodes as an 152 autonomous system. 154 o DLN identification number: This is the unique network 155 identification for a DLN. This is akin to the AS-number issued by 156 ARIN in North America for autonomous systems operated by Internet 157 Service Providers. 159 o Device identity: This is the unique public-private key pair that 160 is bound to the device (e.g. hardware) of the gateway. Examples 161 include the IEEE 802.1AR Secure Device Identity [DevID] and the 162 TPM EK/AIK key pair [TPM]. The device identity public key may be 163 represented using an X.509 certificate. 165 o Gateway service endpoint: The URL or URI at the gateway device 166 that provides gateway related services, such as asset transfer/ 167 migration services. See [ODAP] for a definition of the ODAP 168 protocol. 170 o Service endpoint identity: This is the unique public-private key 171 pair bound to the protocol service end-point of the gateway 172 function. This key-pair is used in the establishment of a secure 173 channel with a peer gateway (e.g. TLS). The endpoint identity 174 public key should be represented using an X.509 certificate, which 175 unambiguously states the purpose of the endpoint. 177 o Owner identity: This is the unique public-private key pair of the 178 entity who legally owns and operates the gateway. For clarity 179 this entity is referred to as a virtual asset service provider 180 (VASP). The VASP identity public key should be represented using 181 an X.509 certificate, possibly including extended fields such as 182 those found in Extended Validation (EV) X.509 certificates [CAB]. 184 o Blockchain gateway service provider (BGSP): The virtual asset 185 service provider that owns and operates the gateway service. The 186 term provides distinction from a technical/protocol perspective, 187 since a BGSP entity is a virtual asset service provider in the 188 business and regulatory sense. 190 4. Gateway Registration, Discovery and Validation 192 4.1. Overview 194 In the context of a digital asset transfer, a gateway identification, 195 discovery and verification solution consists of mechanisms that 196 permit a local gateway to obtain assurance that a given remote device 197 is a gateway with verifiable identity and ownership. That is, it 198 need to obtain assurance that (a) the device is operating as a 199 gateway for a designated blockchain or decentralized ledger network 200 and (b) is owned by an entity operating under the relevant 201 jurisdiction in the context of the digital asset in question. 203 (i) gateway identity authentication: verification that the device 204 with a given identification truly functions as a gateway (and not a 205 rouge server masquerading as a gateway); 207 (ii) gateway ownership validation: verification that a remote gateway 208 is owned by the organization (e.g. VASP) that is operating within a 209 given jurisdiction; 211 (iii) asset type transferability: verification that a remote gateway 212 for a destination DLN is mechanically capable to receive the type of 213 asset and that legally permitted to receive the type of asset. 215 4.2. Gateway Declaration and Registration 217 A given asset service provider may possesses multiple nodes within 218 one or more DLNs globally. Depending on the specific technical 219 constraints of a given DLN (e.g. consensus model), not every node 220 within the DLN may be designated to be a gateway capable of 221 participating in an asset transfer between two DLNs. As such, the 222 service provider must nominate its nodes or systems specifically as 223 gateways. As such, there must be some mechanism that permits the 224 asset service provider to declare that a given device or system 225 serves as a gateway into a given DLN. 227 One possible approach is for the service provider to publish a signed 228 list of the gateways and the endpoints that implement the cross-chain 229 asset transfer protocol for a given asset type. Extending this 230 notion, a directory of gateways may be established by a group or 231 consortium of asset service providers as a means to share a common 232 location where gateway information can be found. 234 This directory approach is currently already being develop by some 235 asset service providers in the context originator/beneficiary data 236 for compliance to the Travel Rule regulations [FATF] dealing with 237 anti-money laundering (AML). An example is the TRISA directory 239 [TRISA], which lists business information of virtual asset service 240 providers (VASP) claiming compliance to the AML regulations. Such a 241 directory could be extended to include the gateways owned and 242 operated by the VASPs. 244 4.3. Gateway Discovery and Validation 246 When an originator (sender) in an origin DLN1 seeks to transfer 247 digital assets to a beneficiary (recipient) located in a remote 248 destination DLN2, a gateway G1 in DLN1 must be able locate and 249 validate one (or more) gateways G2 serving DLN2. 251 This discovery process must be automated as far as possible, and 252 discovery should not require human intervention. If a directory of 253 gateways is available, then it should be utilized by both gateways G1 254 and G2. 256 Discovery, therefore, covers a number of layers and functions: 258 o Gateway network device discovery: There must be a mechanism to 259 discover the gateway at the IP network layer (e.g. IP address, 260 port number) and obtain the device identity of the gateway (e.g. 261 LDevID or device public key). 263 o Gateway service endpoint discovery and validation: Following the 264 device discovery, there must be a mechanism to discover and verify 265 the endpoint at the gateway that provide services related to its 266 role as a gateway. These include the endpoint for asset transfers 267 and the endpoint for crash recovery [Crash]. 269 4.4. Verification of Identities and Addresses 271 In many cases, an originator (sender) in an origin DLN1 may be in 272 possession only of the beneficiary?s name and blockchain-address. 273 This means that the gateway G1 in DLN1 must ensure that the 274 beneficiary?s address exists in the DLN2 and that it is bound to the 275 beneficiary entity or user in DLN2. 277 Although out scope for the current work, it is perhaps worth noting 278 that the responsibility of verifying the identity and legal status of 279 originators and beneficiaries lies with the virtual asset service 280 providers who employ technical mechanism (including gateways and 281 nodes) to transact the digital assets [FATF]. 283 5. Network Layer Gateway Discovery and Verification 285 Gateway discovery and verification at the network layer takes a 286 bottom-up strategy, where a gateway discovers a peer remote gateway 287 and initiates verifications. This is part of Phase-1 of the gateway 288 architecture [ARCH]. This approach mimics the client to MTA (Message 289 Transfer Agent) interaction pattern in the classic SMTP mail transfer 290 protocol [RFC2821]. 292 5.1. Prerequisites 294 To ensure the safety of the transferred digital assets, blockchain 295 gateway service providers (BGSP) must be trustworthy to clients who 296 use the services. As a result, they must meet a high standard to 297 ensure security and trust at different levels, ranging from business 298 to networking, from hardware device to software protocol. In 299 particular, the following basic prerequisites (but not limited to) 300 must be met: 302 o They must be a legal business entity registered with local 303 authority. The registration should be certified in form of a 304 verifiable digital certificate. 306 o They must apply for an Autonomous System (AS) number [RFC6996] 307 from ARIN, or other region networking authorities (such as RIPE 308 NCC for Europe and APNIC for East and South Asia), dedicated to 309 their gateway IP addresses, e.g., 888.10.10.10 311 o The IP address should be bound to a meaningful domain name by 312 registering in DNS [RCF1034, RFC1035], e.g., G1.DLT1.com. 314 o To be better discovered, a number of canonical names are 315 registered in DNS as CNAME record as shown in Table 1. 317 o In addition, BGSP(s) should also be issued with a license/ 318 certificate as authorized approval to provide blockchain gateway 319 services from the corresponding blockchain foundation/authority, 320 and register their services with well-known business directories 321 and publish on the Internet. 323 Based on the above prerequisites, blockchain gateways can discover 324 each other to establish trust step by step for digital asset transfer 325 using either bottom-up or top-down approach. 327 Domain/Name Type Host/Destination 329 G1.DLT1.com A 888.10.10.10 330 DLT1 CNAME G1.DLT1.com 331 G2.DLT2.com A 999.10.10.10 332 DLT2 CNAME G2.DLT1.com 334 Figure 1 336 5.2. DNS-based Gateway Discovery 338 This is a bottom-up approach to blockchain gateway discovery as shown 339 in the Figure below. 341 (Figure TBD - DNS-based Gateway Discovery) 343 Figure 2 345 Client (Alice) wants to transfer a certain value of digital assets 346 (v) from one blockchain (DLT1) to another client (Bob) on anther 347 blockchain (DLT2), which can be represented in ERC20 as follows: 349 transfer(Bob_PublicKey@DLT2, v) 351 The following MTA-Style protocol is specified for gateway networking 352 device discovery: 354 o Alice can send the transfer request to G1 directly if Alice trusts 355 G1 and G1 is pre-configured in Alice wallet; Or Alice can discover 356 G1 and establish trust with G1 by following the same protocol as 357 described below. 359 o As a result of receiving Alice's request, G1 lookup a gateway for 360 DLT2 via DNS and DNS returns G2's IP address, e.g., 999.10.10.10 362 o (Optional) G1 can verify the ownership of the received IP address 363 with 3rd party service to ensure if G2 is trustworthy. 365 o G1 sends a request for exchanging business certificate (BC) by 366 embedding its business certificate in the request, which can be 367 specified in the json format (see Figure). 369 o If G1's certificate is valid, G2 will reply by sending its 370 business certificate as specified (see Figure). 372 o (Optional) G1 may request for verification of Bob's blockchain 373 address (public key) and (optional) his living location (for tax 374 purpose) with DLT2. 376 { 377 "Request": { 378 "CMD": "ExchangeBC", 379 "Certificate": { 380 . . . 381 } 382 } 383 } 385 Figure 3 387 { 388 "Response": { 389 "Certificate": { 390 . . . 391 } 392 } 393 } 395 Figure 4 397 Up to this point, G1 and G2 establish trust at both business and 398 network levels enough and ready to start the transfer digital asset 399 (v) via the asset transfer protocol [ODAP]. 401 6. Application Layer Gateway Discovery and Verification 403 Another approach that is commonly adopted by a community of service 404 providers is for the community to share information regarding 405 standardized service endpoints (e.g. REST APIs). There are multiple 406 ways for a community of consortium of entries to share endpoints 407 information, including a centralized signed-list or database, a 408 replicated distributed database and more recently listing mechanisms 409 based on blockchains (e.g. DIDs). In the following, the term 410 business directory is used generically to represent the list. An 411 example of this approach is the TRISA directory currently being 412 developed for Travel Rule sharing [TRISA]. Depending on the 413 community of consortium, the information in the directory may be 414 publicly readable or it may be accessible only to members of the 415 community. 417 Applying this approach to gateways, a business entities who 418 participate in the directory must proactively register (publish) its 419 gateways and the DLN for which each gateway speaks. The information 420 must include minimally the following: (a) the gateway device 421 identity, (b) one of more blockchains (DLNs) served by the gateway, 422 (c) the identity of the business entity (e.g. asset service 423 provider), (d) expiration of the information in the directory. This 424 information must be source authentic (i.e. digitally signed) by 425 entity registering it. 427 (Figure TBD - Application Layer Gateway Discovery and Verification) 429 Figure 5 431 Suppose that BGSP-1 and BGSP-2 provide blockchain gateway services 432 for DLT1 and DLT2 with G1 and G2, respectively and both register with 433 business directories and publish their services on the Internet. As 434 a result, they should easily discover each other. 436 o BGSP-1 finds BGSP-2 via one of global business directories (or 437 even Google), or vice versa. Then, they negotiate each other with 438 aim to establish a business collaboration via providing cross- 439 chain asset transfer services between DLT1 and DLT2 offline. As a 440 result of successful negotiation, BGSP-1 and BGSP-2 both signs a 441 legal business contract for the collaboration, including 442 agreements about (but not limited to) the network configuration, 443 security setting, and transfer protocols to be used. 445 o Up to the agreement signed, BGSP-1 and BGSP-2 can configure each 446 network and gateway servers according to the agreed settings. 448 o At runtime, when receiving a transfer request from a client 449 (Alice), G1 can send a handshaking request to G2 directly for 450 establishing secure channel for transferring digital asset (v) via 451 the asset transfer protocol [ODAP]. 453 7. Security Consideration 455 In addition to the basic security setting mentioned above, the 456 following technologies can also be considered as either enhancement 457 or alternatives of security settings: 459 HTTPS/TLS: Whenever using HTTP [RFC2616] for the protocol execution, 460 HTTPS/TLS [RFC2821] must be enabled by default against eavesdropping 461 attack. 463 DNSSEC: is a set of extensions to DNS that uses asymmetric 464 cryptography to provide origin authentication and integrity checking 465 for DNS data [RFC 2535]. DNSSEC ensures not just the origin of the 466 DNS record, but also its integrity, which thus enhances the security 467 and trust of the blockchain gateway queries if adopting DNSSEC. 469 Trusted hardware and attestations: Gateways may be implemented in 470 computer systems possessing a secure processor (e.g. TPM)[ISO/IEC 471 11889] or secure enclave (e.g. SGX). For example, server machines 472 can store security keys and conducts common security operations for 473 hardware authentication and authorization. The use of device-unique 474 public key pairs boiund to these types of trusted hardware, copled 475 with their attestations capabilities, may significantly enhance the 476 security and trust between the gateways to conduct blockchain asset 477 transfer services collaboratively. 479 8. IANA Consideration 481 (TBD) 483 9. References 485 9.1. Normative References 487 [FATF] FATF, "International Standards on Combating Money 488 Laundering and the Financing of Terrorism and 489 Proliferation - FATF Revision of Recommendation 15", 490 October 2018, . 494 [ISO] ISO, "Blockchain and distributed ledger technologies- 495 Vocabulary (ISO:22739:2020)", July 2020, 496 . 498 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST 499 Blockchain Technology Overview (NISTR-8202)", October 500 2018, . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 508 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 509 November 1997, . 511 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 512 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 513 . 515 9.2. Informative References 517 [ARCH] Hardjono, T., Hargreaves, M., and N. Smith, "An 518 Interoperability Architecture for Blockchain Gateways. 519 draft-hardjono-blockchain-interop-arch-02", April 2021, 520 . 523 [BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway 524 Crash Recovery Mechanism, IETF, draft-belchior-gateway- 525 recovery-01.", March 2021, 526 . 529 [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset 530 Protocol, IETF, draft-hargreaves-odap-01.", November 2020, 531 . 533 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 534 Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, 535 September 2010, . 537 [TRISA] TRISA, "Travel Rule Information Sharing Architecture for 538 Virtual Asset Service Providers", August 2020, 539 . 541 Authors' Addresses 543 Shiping Chen 544 Data61 546 Email: shiping.chen@data61.csiro.au 547 Thomas Hardjono 548 MIT 550 Email: hardjono@mit.edu