Security Early Review of 
      Secure Asset Transfer (SAT) Interoperability Architecture
		     draft-ietf-satp-architecture

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Document editors and WG chairs should treat these
comments just like any other early review comments.

This document addresses an architecture for securely transferring
digital artifacts between systems.  The transfers must be atomic.  An
owner of a digital artifact initiates a transfer to an entity that has
agreed to accept the artifact have it registered in another system.

The architecture seems to be part of an effort to standardize banking
protocols (if not all financial transactions) that are based on
blockchains.  The document itself does not make such an assertion, but
some press releases make this clear.  I'm not qualified to comment on
the suitability of the proposed architecture for this or any other
financial purpose.  The described architecture is meant to be "secure"
within its own definition of security.  Again, I cannot determine if
those requirements (if they exist) are necessary or sufficient for
finance.

The two entities that carry out a secure three-phase commit protocol
for these transfers are called gateways.  Each one is supposed to be a
member of a network.  The document frequently uses the term "network
(ledger)" although there is no requirement for a ledger-based system.
Nor is there are need that I can see for the gateway to be a member of
any particular Internet communication network (ASN).  If the gateway
is able to authenticate itself to a digital asset system and has the
credentials that authorize it to participate in transfers, then the IP
address and network membership seem irrelevant.  The document implies
otherwise ("Overall this approach ensures a high degree of
interoperability across these networks, where each network can operate
as a true autonomous system.").

One might argue that this is an application-based protocol.

The heart of the document is the description of the authenticated and
secure three phase commit protocol that the gateways must carry out.
Is it secure for the purposes describe in the document?  What are the
security requirements?

Suppose a system has suffered a ransomware attack and has been
restored from an older version, and suppose it tries to initiate
a transfer that it completed just before it was disabled.  It
contacts a receiver in the other system and proposes the transfer.
The receiver is happy to oblige.  The first system is certain that
it owns the asset and will sign all assertions of ownership
positively.  The asset is then transferred (again) to the second
system.  Can the second system mint a copy of the asset?  I don't
think the draft specifies that as a risk, but perhaps the
authors feel that the reference draft-belchior-gateway-recovery-05
covers this case?

The relevant verbiage is:
"
 the fact that an asset has been locked in NW1 must be
   communicated via an assertion to G2 (as the 3PC participant) in an
   indisputable manner.

   Similarly, G2 must return a signed assertion to G1 that the asset has
   been regenerated (minted) in NW2.

   These signed assertions must be verifiable by an authorized third
   party, in the case that disputes occur (post event) or where legal
   audit is required on the asset transfer.
"

Perhaps a later audit will detect the double transfer and hold
the owners of the transferring system accountable for the error.
Is this secure?  It depends on the security requirements.  For
this an similar reasons, I cannot say anything about the
architecture being suitably secure for any purpose.

Much of the document is concerned with practices and procedures that
are important for financial transactions.  The documents mentions
these things for informational purposes, and they are not
requirements.  Some stakeholders might find this useful, but I think
it is out of place in an IETF architecture document.  At any rate, I
find it distracting.

Questions about networks and addresses: Are the participants in this
transaction, i.e. the originator and the beneficiary, required to have
addresses in the same ASN as their respective gateways?  I'd guess
not, but I'd like to know.  Is the gateway required to have an address
in the same ASN as the rest of transaction processing network?  Why?
Is the proof of transfer available through the ASN of the gateways?
How requirements ensure that an "authorized third party" can carry out
a verification of the transfer?

The document states "The mechanisms used to provide cryptographic
proofs that an asset has been burned or minted in a given network is
also out of scope."  Are these proofs implicitly required?  The
document focuses on legally binding assertions in the protocol and
third-party verification of the creation of the asset in the receiving
network, but they don't seem to have any independent cryptographic
proofs.

Minor things:

The term ACID is used before it is defined.  It is used as an acronym
for the "desirable properties" of asset transfer, but those properties
actually include two more: liveness and third-party verification.  ACIDLV?

The Herlihy publication is never referenced.