Subject: Suggestion for clarification of IOTP spec wording.

From: "Michie, Alan" <[email-masked]>
Date: Wed, 05 Apr 2000 18:36:05 +1000

Hello Donald,

It was good to meet you at IETF 47.  Sorry I couldn't stay past Tuesday and
be present for the IOTP session. 

To Donald or anyone else who knows the answer

Since getting back from IETF 47, I have been investigating IOTP in more
detail and have come across a potential security hole (or a potentially
embarrassing question because I haven't been involved for long enough).

It involves the general case where the delivery handler and the merchant are
separate entities.  What is to stop a consumer from issuing multiple
delivery requests in response to a single payment response from the
merchant?  I don't think it is reasonable to expect the delivery handler to
keep track of all previous delivery requests.  Section 9.1.4 of the IOTP
spec refers.

What do you think?

Regards,
Alan

Alan Michie
Project Leader
Telstra Research Laboratories.
+61 2 8255 3085

---

From: "Smith, Chris " <[email-masked]>
Date: Wed, 05 Apr 2000 10:37:38 -0400

First it is worth noting that IOTP will not usually
'deliver' the final goods/service/product. The
delivery note specifies how this is to be accomplished,
and the low-level package details in the note should
provide all the needed information. However, looking
at the response may be one step too far, at least initially.

The Delivery Request should be signed over over the
transaction and message IDs involved, especially if
the delivery handler and merchant are separate. This
means that you cannot create a Delivery Request to refer
to anything but the transaction you are working on. The
Delivery Handler can therefore identify duplicate
requests because they refer to the same transaction id
and message id, and include the appropriate signatures
from the payment exchange.

First, given that the Delivery Handler can identify the
duplicate requests, there is no security hole. What is
required is that the Delivery Handler appropriately reply
to the duplicate requests. In many cases, it should be
sufficient to send the original Delivery Response. This
is also wise, because the Delivery Handler **does not
know the state of the customer**. The customer may have
never received the original reply, and is resending the
Delivery Request.

The remaining question is how to handle the duplicates
at a business level. For digital delivery, this could
be accomplished using the MIME typing features, in order
to trigger a browser, or other equivalent client
software. In such a case, it is not clear to me that
there is a problem with multiple Delivery Requests,
since they will only trigger a restart of a process
that was valid that first time it was started. For
real-world delivery, I would suggest there is even
less of a problem, since you can return the same
information (the Delivery Note details may include
shipping information, for example), but the Delivery
Handler, having noted the duplicate already, does not
start a second shipping process.

Now, I realize this violates your constraint of not
being "reasonable to expect the delivery handler to
keep track of all previous delivery requests". However,
this is already a requirement for a Delivery Handler
who wishes to reasonably take part in any IOTP exchange.
Also, the Delivery Handler will also be keeping track
of the requests anyway in order to be paid by the merchant.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

> -----Original Message-----
> From: Michie, Alan [mailto:[email-masked]]
> Subject: Suggestion for clarification of IOTP spec wording.
...
> Since getting back from IETF 47, I have been investigating
> IOTP in more detail and have come across a potential security
> hole (or a potentially embarrassing question because I haven't
> been involved for long enough).
> 
> It involves the general case where the delivery handler and
> the merchant are separate entities.  What is to stop a
> consumer from issuing multiple delivery requests in
> response to a single payment response from the merchant?
...
> I don't think it is reasonable to expect the  delivery
> handler to keep track of all previous delivery requests.
> Section 9.1.4 of the IOTP spec refers.
>

---

From: "Michie, Alan" <[email-masked]>
Date: Thu, 06 Apr 2000 10:15:17 +1000

Chris,

Thanks for the detailed and insightful reply.  It was your very last
sentence:

"

"

that settled the matter for me.

Regards

Alan

> From:	Smith, Chris  [SMTP:[email-masked]]
> Sent:	Thursday, 6 April 2000 12:38 am
> To:	'Michie, Alan'; 'Donald E. Eastlake 3rd'
> Cc:	[email-masked]; Chauhan, Ankush; Booker, Graeme; Chard,
> Jamie
> Subject:	RE: Suggestion for clarification of IOTP spec wording.
> 
> 
> keep track of all previous delivery requests" However, 
> > From: Michie, Alan [ <mailto:[email-masked]>]

---

From: David Burdett <[email-masked]>
Date: Wed, 05 Apr 2000 23:09:11 -0700

There is another feature as well that helps to provide security in that the
Delivery Data element also contains OkFrom and OkTo date/times. If the
request is received outside of these times then it is invalid and shouldn't
be processed. It also means that, once the delivery handler has been paide
and the OkTo date/time is passed, then the original request can be safely
deleted, if the Delivery Handler has no other reason to keep it.

Regards

David

-----Original Message-----
From: Michie, Alan [mailto:[email-masked]]
Sent: Wednesday, April 05, 2000 5:15 PM
To: 'Smith, Chris '
Cc: [email-masked]; Chauhan, Ankush; Booker, Graeme; Chard,
Jamie

Chris,

"

"

Regards

Alan