add sender authentication

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)      |
 
 

blip-0014.md

@@ -0,0 +1,65 @@
+```
+bLIP: 14
+Title: Sender authentication
+Status: Draft
+Author: Joost Jager <[email protected]>
+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.