|
19
|
1 https://datatracker.ietf.org/doc/draft-ietf-satp-core/
|
|
|
2 Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html
|
|
|
3 Title: Secure Asset Transfer Protocol (SATP) Core
|
|
|
4 Reviewer: Henry S. Thompson
|
|
|
5 Review Date: Mon Oct 19 13:48:49 2026
|
|
|
6
|
|
|
7 *Summary*
|
|
|
8
|
|
|
9 As far as I can tell as a non-specialist, the ... is in good shape.
|
|
|
10 There are ... below.
|
|
|
11
|
|
|
12 This draft is part of a package of at least three parts, including
|
|
|
13 also _Secure Asset Transfer (SAT) Interoperability Architecture_ and
|
|
|
14 _Secure Asset Transfer (SAT) Use Cases_.
|
|
|
15
|
|
|
16 *Minor points*
|
|
|
17
|
|
|
18 1.
|
|
|
19
|
|
|
20 The restriction to just HTTPS with TLS1.3 is almost certainly not
|
|
|
21 what you want. The use of HTTP/2 or QUIC, which requires use of
|
|
|
22 TLS1.3, should be allowed.
|
|
|
23
|
|
|
24 In the Introduction, all that's needed is something along these lines:
|
|
|
25
|
|
|
26 Secure transfer mechanisms such as HTTPS with TLS no less than 1.3
|
|
|
27 must be used.
|
|
|
28
|
|
|
29 5.3.9 and 5.4 can actually be simplified by switching to language
|
|
|
30 which allows for successor messaging systems which offer the same or
|
|
|
31 better security than HTTPS with TLS1.3.
|
|
|
32
|
|
|
33 There might be an argument for a SHOULD support HTTPS with TLS 1.3,
|
|
20
|
34 but only if there is a strong case for encouraging interop between
|
|
|
35 different gateway implementations.
|
|
|
36
|
|
|
37 5.3
|
|
|
38
|
|
|
39 The use of the word 'client' here and and client/server terminology
|
|
|
40 in 5.4 is unnecessarily confusing with respect to the use of
|
|
|
41 'client' as defined in section 3 and used in section 4 (the SATP
|
|
|
42 model) and 5.3.8.
|
|
|
43
|
|
|
44 The fact that 'client' is used with two different meanings in the
|
|
|
45 section headings of 5.3.8 and 5.3.10 illustrates this unnecessary
|
|
|
46 confusion.
|
|
|
47
|
|
|
48 ARCH uses 'client' only in the 'client application' sense, and
|
|
|
49 'server' not at all, and it would be a good idea to stick with that.
|
|
|
50 Following ARCH, Section 3 defines "sender gateway" and "recipient
|
|
|
51 gateway" and I would very much encourage their use throughout, as
|
|
|
52 already done in 5.3.2.
|
|
|
53
|
|
|
54 For example, 5.3 para 1 could read
|
|
|
55
|
|
|
56 SATP messages are exchanged between peer gateways, where depending
|
|
|
57 on the message type one is the sender gateway and the other the
|
|
|
58 recipient gateway.
|
|
|
59
|
|
|
60 and in 5.3.9
|
|
|
61
|
|
|
62 If the sender gateway transmits a list of supported credential
|
|
|
63 schemes, the recipient gateway selects one acceptable credential
|
|
|
64 scheme from the offered schemes.
|
|
|
65
|
|
|
66 and in 5.3.10
|
|
19
|
67
|
|
20
|
68 *5.3.10. Sender Gateway Offers Other Supported TLS Schemes*
|
|
|
69
|
|
|
70 If a sender gateway wishes to use TLS schemes other than the basic
|
|
|
71 scheme (AES-128 in GCM mode with SHA-256), then the gateway may
|
|
|
72 may choose to send a JSON object listing the client's supported
|
|
|
73 TLS schemes.
|
|
|
74
|
|
|
75 Also, later on the terminology used changes from 'recipient gateway'
|
|
|
76 to 'receiver gateway' -- this should be reverted throughout.
|
|
|
77
|
|
|
78 I've listed all this as 'minor' only because it is a matter of
|
|
|
79 terminology, but I think it's important to fix it.
|
|
|
80
|
|
|
81 5.4.1
|
|
|
82
|
|
|
83 See above. Here's a simpler version of this whole section:
|
|
|
84
|
|
|
85 5.4.1. Protocol requirements
|
|
|
86
|
|
|
87 Gateways MUST use a secure protocol, HTTPS or successors, in this stage.
|
|
|
88
|
|
|
89 Gateways MUST use the HTTPS POST method or equivalent idempotent
|
|
|
90 [RFC 9110] method in this stage.
|
|
|
91
|
|
|
92 7.
|
|
|
93
|
|
|
94 remove ' (client)' and ' (sender)'
|
|
|
95
|
|
|
96 8., 9., 10.
|
|
|
97
|
|
|
98 remove and/or replace 'client', 'server' and 'receiver' so that all
|
|
21
|
99 and only 'sender gateway' and 'recipient gateway' are used.
|
|
|
100
|
|
|
101 8.3. and others
|
|
|
102
|
|
|
103 Starting here there are many sentences of the form
|
|
20
|
104
|
|
21
|
105 "This message is sent from ... to the ... Endpoint at ... ."
|
|
|
106
|
|
|
107 The typography implies that these are formal properties of SATP, but
|
|
|
108 as far as I can see there is no definition of 'endpoint' or how the
|
|
|
109 many different ... Endpoints are to be identified between the two
|
|
|
110 gateways. Is this information meant to be included in the 'transfer
|
|
|
111 context' as defined in 5.3.6?
|
|
19
|
112
|
|
22
|
113 8.4. and others
|
|
|
114
|
|
|
115 8.3. and 8.4. define the *Transfer Proposal Message* and *Transfer
|
|
|
116 Proposal Receipt Message*. There are a number of message pairs with
|
|
|
117 similar pairs of names, with the second part being variously named
|
|
|
118 ... Receipt Message or ... Response Message.
|
|
|
119
|
|
|
120 Language along the lines of "The message is sent from the [recipient
|
|
|
121 gateway] to the ... EndPoint at the [sender gateway]" appears in
|
|
|
122 many if not all of them
|
|
|
123
|
|
|
124 It's never made clear if this just e.g. requires *Transfer Proposal
|
|
|
125 Receipt Message* as the form which the HTTPS response body should
|
|
|
126 adopt when responding to an HTTPS POST request in the *Transfer
|
|
|
127 Proposal Message* form or, as I read it at first, actually means a
|
|
|
128 _seperate_ HTTPS POST request in the *Transfer Proposal Receipt
|
|
|
129 Message* format is sent from the recipient gateway.
|
|
|
130
|
|
|
131 That is, are we being told about a single HTTPS exchange, or two?
|
|
|
132 Or is the intent to allow for either? I think either at the
|
|
|
133 beginning of section 8, or somewhere earlier, perhaps section 6,
|
|
|
134 this should be explained. Indeed Figure 2 in section 6 might
|
|
|
135 encourage one to think that the Transfer Proposal exchange requires
|
|
|
136 one HTTPS exchange, whereas the Lock Assertion exchange involves
|
|
|
137 two.
|
|
|
138
|
|
|
139 11.
|
|
|
140
|
|
|
141 The discussion of time-outs and aborts leaves it unclear whether a
|
|
|
142 gateway which times out waiting at some point in a session should
|
|
|
143 send a session-abort-msg or not, but I would think it should.
|
|
|
144
|
|
|
145 Note that the phrase "time-outs due to gateway crashes" doesn't make
|
|
|
146 any sense: from the point-of-view of a gateway (G1) which times out
|
|
|
147 waiting for a response, there is no way to detect the _reason_ for
|
|
|
148 the timeout. In case a timeout is _not_ because of a crash on the
|
|
|
149 part of the other gateway (G2), surely notification that the session
|
|
|
150 is being terminated by G1 should be sent, to enable an orderly
|
|
|
151 close-down by G2, instead of it having to time-out itself.
|
|
|
152
|
|
19
|
153 *Nits*
|
|
|
154
|
|
20
|
155 3.
|
|
|
156
|
|
|
157 Since you use them both, I suggest including the ARCH definitions of
|
|
|
158 'originator' and 'beneficiary' here.
|
|
|
159
|
|
|
160 5.3.15
|
|
22
|
161 immobile => immobilize [twice]
|
|
20
|
162
|
|
|
163 'uses Hashed Time-lock' => 'use Hashed Time-lock'
|
|
|
164
|
|
21
|
165 8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4.
|
|
|
166
|
|
|
167 must => MUST [throughout]
|
|
|
168
|
|
|
169 8.4., 8.6. and 9 others
|
|
|
170
|
|
|
171 The example JSON ends with a comma, which is strictly speaking not
|
|
|
172 allowed, and may cause errors in some tools (e.g. jq). It would be
|
|
|
173 best to remove them.
|
|
|
174
|
|
|
175 11.3.
|
|
|
176
|
|
|
177 The example JSON is missing a comma after
|
|
|
178 "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"
|
|
|
179
|
|
22
|
180 11.3.
|
|
|
181
|
|
|
182 errror => error
|
|
|
183
|
|
|
184 11.4.
|
|
|
185
|
|
|
186 I think *Protocol Error Codes* would be better...
|
|
|
187
|
|
|
188 11.5.
|
|
|
189
|
|
|
190 'maybe' => 'may be'
|
|
|
191
|
|
|
192 12.
|
|
21
|
193
|
|
|
194 'such a' => 'such as'
|
|
|
195
|
|
19
|
196 15.1
|
|
|
197
|
|
|
198 RFC 8446 is obsolete, should refer to 9846.
|
|
|
199
|
|
|
200
|
|
|
201
|
