Subject: [lisp] Authentication for LISP-OE

From: Rene Bartsch <[email-masked]>
Date: Tue, 02 Sep 2014 19:11:41 +0200

Hi,

Opportunistic Encryption for the Locator/ID Separation Protocol (LISP) 
(draft-lopez-lisp-oe-00) suggests Diffie-Hellman key-exchange without 
authorization which allows man-in-the-middle attacks as there is no 
security context between EID and PxTR/EID-host.

Some month ago I proposed the idea of cryptographically generated 
endpoint identifiers (CGEID). If we use a 4096-bit RSA key-pair, hash a 
96-bit interface-identifier from the RSA public-key and prefix it with a 
32-bit IPv6 network-prefix we get an IPv6-compatible EID which is bound 
to the RSA key-pair. Combined with IPSEC-ESP AES-encryption and 
perfect-forward-secrecy we get a strong authentication/encryption 
mechanism for LISP. If the target is a CGEID we force encryption 
otherwise we can use opportunistic encryption.

What do you think?

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2014 10:22:04 -0700

> Some month ago I proposed the idea of cryptographically generated endpoint identifiers (CGEID). If we use a 4096-bit RSA key-pair, hash a 96-bit interface-identifier from the RSA public-key and prefix it with a 32-bit IPv6 network-prefix we get an IPv6-compatible EID which is bound to the RSA key-pair. Combined with IPSEC-ESP AES-encryption and perfect-forward-secrecy we get a strong authentication/encryption mechanism for LISP. If the target is a CGEID we force encryption otherwise we can use opportunistic encryption.
> 
> What do you think?

And where are you suggesting we store public keys?

Dino

---

From: Rene Bartsch <[email-masked]>
Date: Tue, 02 Sep 2014 19:58:46 +0200

Am 2014-09-02 19:22, schrieb Dino Farinacci:
>> endpoint identifiers (CGEID). If we use a 4096-bit RSA key-pair, hash 
>> a 96-bit interface-identifier from the RSA public-key and prefix it 
>> with a 32-bit IPv6 network-prefix we get an IPv6-compatible EID which 
>> is bound to the RSA key-pair. Combined with IPSEC-ESP AES-encryption 
>> and perfect-forward-secrecy we get a strong authentication/encryption 

Nowhere ;-)

1. The sender sends it's public key to the recipient.
2. The recipient compares public key and 96-bit interface-identifier of 
the sender and returns his public-key and a random stream-cipher-key 
encrypted with the public key of the sender and signed with the private 
key of the recipient.
3. The sender checks if 96-bit interface-identifier, public-key and 
signature of the recipient match and uses the received random 
stream-cipher-key for symmetric payload encryption.

Caching the public key in the DHT might speed up repeated lookups if a 
client uses the DHT directly without a resolver. But I'm not sure if the 
lookup acceleration is worth the increased protocol/DHT complexity.

-- 
Best regards,

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2014 11:14:20 -0700

> 1. The sender sends it's public key to the recipient.

How? New protocol, existing mechanisms? You need to give us more detail.

> 2. The recipient compares public key and 96-bit interface-identifier of the sender and returns his public-key and a random stream-cipher-key encrypted with the public key of the sender and signed with the private key of the recipient.
> 3. The sender checks if 96-bit interface-identifier, public-key and signature of the recipient match and uses the received random stream-cipher-key for symmetric payload encryption.
> 
> Caching the public key in the DHT might speed up repeated lookups if a client uses the DHT directly without a resolver. But I'm not sure if the lookup acceleration is worth the increased protocol/DHT complexity.

What DHT? You requiring new infrastructure and mechanisms then?

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 2 Sep 2014 18:36:42 +0000

We have a distributed resolver ( MR as a DHT function) implementation option.
So still lisp compliant, but single hop, no extra lookup overhead.
It's for when the overlay nodes (XTR+DHT or NVE/NVA) trust each other just do not trust the Underlay.

--szb

> On Sep 2, 2014, at 10:59, "Rene Bartsch" <[email-masked]> wrote:
>

---

From: Rene Bartsch <[email-masked]>
Date: Tue, 02 Sep 2014 22:20:14 +0200

Am 2014-09-02 20:14, schrieb Dino Farinacci:
>>>> endpoint identifiers (CGEID). If we use a 4096-bit RSA key-pair, 
>>>> hash a 96-bit interface-identifier from the RSA public-key and 
>>>> prefix it with a 32-bit IPv6 network-prefix we get an 
>>>> IPv6-compatible EID which is bound to the RSA key-pair. Combined 
>>>> with IPSEC-ESP AES-encryption and perfect-forward-secrecy we get a 
>>>> strong authentication/encryption mechanism for LISP. If the target 
>>>> is a CGEID we force encryption otherwise we can use opportunistic 
>>>> encryption.
>>>> What do you think?

I just had a quick look into IPSec and it doesn't seem to be suitable 
for exchanging RSA-keys. So I suggest to use an extra header on first 
packets referenced by the LISP header which contains the public 
keys/stream cipher keys/signature. xTRs can store the received 
public-keys/stream-ciphers in a cache for following packets. 
Stream-cipher-keys should have a Time-To-Live for 
Perfect-Forward-Secrecy.

I also suggest we seek advice from encryption specialists which 
asymmetric key/hash-/stream-cipher algorithms are most secure. My first 
thought is to use 4096-bit RSA-keys as asymmetric keys, 96-bit Keccak 
hash of the public asymmetric key as interface-identifier and a variant 
of AES-256 as stream-cipher for the payload.

On encryption setup the source sends the following header to the 
destination:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Key Type   |           Key Length          | Stream-Cipher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
.                                                               .
.                     Source EID Public Key                     .
.                                                               .
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Answer from the destination to the source:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Key Type   |           Key Length          | Stream-Cipher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Stream-Cipher Length     |        Signature Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SignatureType |                 Reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
.                                                               .
.                Destination EID Public Key                     .
.                                                               .
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
.                  Random Stream-Cipher Key                     .
.                      encrypted with                           .
.                     Source EID Public Key                     .
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
.                     Stream-Cipher Key                         .
.                   Destination Signature                       .
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stream-Cipher update:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Key Type   |           Key Length          | Stream-Cipher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
.                  Random Stream-Cipher Key                     .
.                      encrypted with                           .
.                 previous Stream-Cipher Key                    .
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>> 2. The recipient compares public key and 96-bit interface-identifier 
>> of the sender and returns his public-key and a random 
>> stream-cipher-key encrypted with the public key of the sender and 
>> signed with the private key of the recipient.
>> client uses the DHT directly without a resolver. But I'm not sure if 
>> the lookup acceleration is worth the increased protocol/DHT 
>> complexity.
> 

Sorry, meant DDT.

-- 
Best regards,

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2014 13:34:43 -0700

Have you read draft-farinacci-lisp-crypto-01 and seen the following slide-sets that have been presented at previous IETFs?

Dino

On Sep 2, 2014, at 1:20 PM, Rene Bartsch <[email-masked]> wrote:

> I just had a quick look into IPSec and it doesn't seem to be suitable for exchanging RSA-keys. So I suggest to use an extra header on first packets referenced by the LISP header which contains the public keys/stream cipher keys/signature. xTRs can store the received public-keys/stream-ciphers in a cache for following packets. Stream-cipher-keys should have a Time-To-Live for Perfect-Forward-Secrecy.
> 
> I also suggest we seek advice from encryption specialists which asymmetric key/hash-/stream-cipher algorithms are most secure. My first thought is to use 4096-bit RSA-keys as asymmetric keys, 96-bit Keccak hash of the public asymmetric key as interface-identifier and a variant of AES-256 as stream-cipher for the payload.
> 
> On encryption setup the source sends the following header to the destination:
> 
> 0                   1                   2                   3

---

From: Rene Bartsch <[email-masked]>
Date: Tue, 02 Sep 2014 22:57:08 +0200

Not yet, but tommorrow seems to be a good time to read it. ;-)

Renne

Am 2014-09-02 22:34, schrieb Dino Farinacci:
> Have you read draft-farinacci-lisp-crypto-01 and seen the following
> slide-sets that have been presented at previous IETFs?
> 
> Dino
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> asymmetric key/hash-/stream-cipher algorithms are most secure. My 
>> first thought is to use 4096-bit RSA-keys as asymmetric keys, 96-bit 
>> Keccak hash of the public asymmetric key as interface-identifier and a 
>> variant of AES-256 as stream-cipher for the payload.
>> 
>>>> Caching the public key in the DHT might speed up repeated lookups if 
>>>> a client uses the DHT directly without a resolver. But I'm not sure 
>>>> if the lookup acceleration is worth the increased protocol/DHT 
>>>> complexity.

-- 
Best regards,

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Sep 2014 14:25:00 -0700

You may see that many of your questions have been answered.

Dino