Internet DRAFT - draft-chen-dlt-gateway-identification
draft-chen-dlt-gateway-identification
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, <https://www.w3.org/TR/did-core/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", 1 March 2021,
<https://datatracker.ietf.org/doc/rfc2181/>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <https://www.rfc-editor.org/info/rfc2234>.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1
March 2005,
<https://datatracker.ietf.org/doc/html/rfc2535>.
[RFC2616] Fielding, R., Mogul, J., MMasinter, L., and T. Berners-
Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1 June
1999, <https://www.ietf.org/rfc/rfc2616.txt>.
[RFC2660] Rescorla, E. and A. Schiffman, "Clarifications to the DNS
Specification", 1 August 1999,
<https://datatracker.ietf.org/doc/html/rfc2660>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", 1
March 2005,
<https://datatracker.ietf.org/doc/html/rfc4033>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
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,
<https://www.oasis-open.org/committees/uddi-spec/doc/
tcspecs.htm#uddiv3>.
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,
<https://datatracker.ietf.org/doc/draft-hardjono-
blockchain-interop-arch/>.
[BTCR] Duffy, K.H., Grant, R., and C. Allen, "BTCR DIDs and
DDOs", 1 May 2022, <https://github.com/WebOfTrustInfo/
rwot5-boston/blob/master/topics-and-advance-readings/btcr-
dids-ddos.md>.
[FATF] FATF, "International Standards on Combating Money
Laundering and the Financing of Terrorism and
Proliferation - The FATF Recommendations", March 2022,
<http://www.fatf-
gafi.org/publications/fatfrecommendations/documents/fatf-
recommendations.html>.
[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,
<https://doi.org/10.3389/fbloc.2019.00024>.
[NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
Blockchain Technology Overview (NISTR-8202)", October
2018, <https://doi.org/10.6028/NIST.IR.8202>.
[SATP] Hargreaves, Q., Hardjono, T., and R. Belchior, "Secure
Asset Transfer Protocol", 2 May 2022,
<https://datatracker.ietf.org/doc/draft-hargreaves-sat-
core/>.
[SOVRIN] Lodder, M. and D. Hardman, "Clarifications to the DNS
Specification", 1 May 2022, <https://sovrin-
foundation.github.io/sovrin/spec/did-method-spec-
template.html>.
[TVDR] Compellio.io, "Tezos Verifiable Data Registry", 1 July
2022, <https://github.com/compellio/tz-verifiable-data-
registry/tree/testnet>.
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]
