RFC-11 : Add key identifier to ITP Header

[adrianhopebailie]

It's possible that a receiver may wish to maintain multiple secrets/keys for use in generating the pre-image for ITP payments.

This may be because the receiver wishes to have different keys per sender or just keep old keys alive for a short period after rotating to a new key.

It's common practice for entities like the receiver to store these keys securely index by some unique identifier (even just a numeric counter/index).

The receiver then uses this index to look up the key so it can recreate the the fulfillment after receiving a payment.

To do this, it must provide the key identifier to the sender in the original payment request (Interledger Packet) and the sender must send this in the subsequent payment.

PROPOSAL:

Add a new field to the ITP header

Field	Type	Short Description
keyIdentifer	OCTET STRING	Identifier used by the receiver to identify the HMAC key it used in generating this condition

[emschwartz]

I think this idea could be rolled together with the
receiverRequestPurpose field. The uniqueId must be unique and that
other field (maybe could be renamed) includes everything the receiver needs
to associate the request on their end, with keys, sender IDs or something
else. What do you think?
On Jul 14, 2016 2:48 PM, "Adrian Hope-Bailie" notifications@github.com
wrote:

It's possible that a receiver may wish to maintain multiple secrets/keys
for use in generating the pre-image for ITP payments.

This may be because the receiver wishes to have different keys per sender
or just keep old keys alive for a short period after rotating to a new key.

It's common practice for entities like the receiver to store these keys
securely index by some unique identifier (even just a numeric
counter/index).

The receiver then uses this index to look up the key so it can recreate the
the fulfillment after receiving a payment.

To do this, it must provide the key identifier to the sender in the
original payment request (Interledger Packet) and the sender must send this
in the subsequent payment.
PROPOSAL:

Add a new field to the ITP header
Field Type Short Description
keyIdentifer OCTET STRING Identifier used by the receiver to identify the
HMAC key it used in generating this condition

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#54, or mute the thread
https://github.com/notifications/unsubscribe/ADHIkujSDzckbZR2dn0Hl0D8I2BKKzplks5qVjAqgaJpZM4JMZhM
.

[adrianhopebailie]

think this idea could be rolled together with the receiverRequestPurpose field. The uniqueId must be unique and that other field (maybe could be renamed) includes everything the receiver needs to associate the request on their end, with keys, sender IDs or something else. What do you think?

Yep, that would do it. I'd call that something like noteToSelf or echoData to be consistent with where we've done similar stuff in other places.

By the way, would we consider these fields as "additions" to the core ILP Header fields? i.e. Are they siblings. This matters in terms of consistent normalization for the sake of getting a canonical version of the data for signing.

Also, maybe rename requestUniqueId to just requestId (personal pref)?

[emschwartz]

It's a bit confusing to call it noteToSelf because the sender will also see this and it isn't a note to them...

The ILP Packet needs a way to attach other headers, which would include this one. We should probably have a way to indicate which headers may change en route (maybe taking some inspiration from how it's done in IPv6) so that they are left out when hashing.

I don't have a super strong preference between requestUniqueId and requestId

[adrianhopebailie]

It's a bit confusing to call it noteToSelf because the sender will also see this and it isn't a note to them...

It's not clear to me how we will do the "combine" step with the ITP header and the ILP Header which may be the issue. Will all the fields be namespaced somehow? i.e. Wouldn't it be easy to tell which data comes from the receiver?

[emschwartz]

They wouldn't be combined, you would have an ILP Header, and ITP Header, and some others. The packet just needs a way for these different headers to be packed next to one another.

[MatthewPhinney]

This may be because the receiver wishes to have different keys per sender

Could you please explain the motivation for this?

Also, maybe rename requestUniqueId to just requestId

👍

[adrianhopebailie]

They wouldn't be combined, you would have an ILP Header, and ITP Header, and some others. The packet just needs a way for these different headers to be packed next to one another.

Right, where is that "way for these different headers to be packed next to one another" defined because for the following steps to be repeated consistently that tneeds to be a well defined process

1. The receiver attaches the ITP header to the Interledger Packet.
2. The receiver encodes the complete Interledger Packet in the Canonical OER format.
3. The receiver creates an HMAC of the encoded packet using the SHA-256 hash function and the receiver's secret as the HMAC key.

I think it used to be defined in RFC 3 but is not longer there.

[adrianhopebailie]

Could you please explain the motivation for this?

It's common in payments systems for symmetric keys like this to be partitioned. Usually by intended use (PIN encryption, vs MACing etc) and then by partner system or terminal.

This means that if the key gets compromised the damage is limited.

Even if the receiver always uses the same key they may want to change this at some point but will want to keep the old key "alive" for a short time to ensure any payments in flight can still be processed. To do this they need to know, when they receive a payment, which key was used to generate the condition.

[emschwartz]

With #68 (implemented in #76) you could use a part of the ILP Address for this purpose.