From 91674d6383695c0638cd60ada72d16492578c77b Mon Sep 17 00:00:00 2001 From: Joost Jager Date: Fri, 4 Feb 2022 10:28:32 +0100 Subject: [PATCH] add sender authentication --- blip-0002.md | 1 + blip-0014.md | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 blip-0014.md diff --git a/blip-0002.md b/blip-0002.md index 668744e..b97a790 100644 --- a/blip-0002.md +++ b/blip-0002.md @@ -85,6 +85,7 @@ The following table contains extension tlv fields for the `payment_onion_payload | Type | Name | Link | |-------------|-----------------------------|--------------------------------| +| 83231 | `sender_auth` | [bLIP 14](./blip-0014.md) | | 7629169 | `podcasting_2_0` | [bLIP 10](./blip-0010.md) | diff --git a/blip-0014.md b/blip-0014.md new file mode 100644 index 0000000..b951739 --- /dev/null +++ b/blip-0014.md @@ -0,0 +1,65 @@ +``` +bLIP: 14 +Title: Sender authentication +Status: Draft +Author: Joost Jager +Created: 2022-02-04 +License: CC0 +``` + +## Abstract + +By default, the lightning protocol protects the sender identity by means of +ephemeral keys and onion routing. There are however use cases that ask for +inclusion of the sender identity with a payment. + +This bLIP serves to document a way to authenticate the sender of a payment via a +custom TLV record. + +## Copyright + +This bLIP is licensed under the CC0 license. + +## Specification + +Sender: + +* MUST include a TLV record keyed by type `83231` with the following TLV value: + * [`33*byte`:`pubkey`] + * [`32*byte`:`hmac`] + + `pubkey` is set to the public key of the sender. Note that `pubkey` doesn't + need to be the sender's node public key. It can also be a more general + identity. + + `hmac` is calculated over `payment_secret`, using a shared secret as the key. + This shared secret is calculated using Elliptic-curve Diffie-Hellman between + sender private key and receiver public key. + +Receiver: + +* Derives the shared secret key using Elliptic-curve Diffie-Hellman between + `pubkey` and receiver private key. +* Verifies `hmac` using the shared secret. +* If verification fails, SHOULD error with + `PERM|15 incorrect_or_unknown_payment_details`. + +## Motivation + +There are many ways to authenticate the sender of a payment in Lightning. This +documentation is an attempt prevent the emergence of too many variants that all +do more or less the same thing. + +## Rationale + +* The TLV record key is an odd number, meaning that the record is ignored by + receivers that do not support sender authentication. No feature bit is needed. + +* The choice for Diffie-Hellman rather than a signature is to preserve the + privacy of the sender as much as possible. Senders are authenticating + themselves to receivers, but receivers cannot prove anything to a third party + because they could have made up the proof themselves. + +* `hmac` is calculated over `payment_secret` and not `payment_hash`. With + `payment_hash`, an intermediate node could possibly attempt to pay to the same + hash authenticated with their own identity key.