Re: [lisp] LISP crypto

Configured shared-keys is a non- starter for LISP. 

Imagine and ITR, just with 10K map-cache entries that point to dual-homed LISP sites. That is 20K keys that not only need to be configured but colocated with those 20K RLOCs. RLOCs that can change due to EID-prefix mobility. 

Dino

> On Nov 6, 2015, at 6:36 PM, Amjad Inamdar (amjads) <amjads@cisco.com> wrote:
> 
> Hi Dino,
> 
> The pre-shared key I mentioned about would need to be pre-configured on the peers/xTRs. DH shared secret is based on DH public values exchanged on the wire which QC can break.
> 
> Thanks,
> -Amjad
> 
> 
> -----Original Message-----
> From: Dino Farinacci [mailto:farinacci@gmail.com] 
> Sent: 06 November 2015 PM 12:15
> To: Amjad Inamdar (amjads)
> Cc: lisp@ietf.org
> Subject: Re: [lisp] LISP crypto
> 
> In the lisp-crypto design, the ECDH shared secret is input to the KDF that produces the encryption key and integrity-check key. 
> 
> Sounds like we may already be doing what you suggest. 
> 
> And not clear to me how much more QC-safe this actually is. 
> 
> Dino
> 
>> On Nov 6, 2015, at 1:47 PM, Amjad Inamdar (amjads) <amjads@cisco.com> wrote:
>> 
>> Hi Dino,
>> 
>> The thing being proposed with IKEv2 is to include a pre-shared key in the key derivation and with sufficient entropy in the pre-shared key, this would offer fair amount of protection. You can please refer draft-fluhrer-qr-ikev2 for further details.
>> 
>> Thanks,
>> -Amjad
>> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>> Sent: 06 November 2015 AM 05:34
>> To: Amjad Inamdar (amjads)
>> Cc: lisp@ietf.org
>> Subject: Re: [lisp] LISP crypto
>> 
>> Amjad, we are aware of the QC-safe work going on in CFRG. We are following it but it is very researchy at this point. We can add some text indicating that we’ll follow any CFRG/SAAG recommendations (or any security area working group’s recommendation) on using QC-safe technology.
>> 
>> If there is anything specific you want us to look at with IKE, please send some pointers. Thanks.
>> 
>> Dino
>> 
>>> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) <amjads@cisco.com> wrote:
>>> 
>>> Hi Brian/Dino,
>>> 
>>> The key material derivation proposed in draft-ietf-lisp-crypto is based on Diffie-Hellman which is not Quantum Computer resistant. There is some work underway to make IKE that uses DH for key derivation Quantum Computer safe. Might be a good idea to consider this for lisp-crypto as well.
>>> 
>>> Thanks,
>>> -Amjad
>>> 
>>> From: Amjad Inamdar (amjads)
>>> Sent: 03 November 2015 PM 12:33
>>> To: 'lisp@ietf.org'
>>> Subject: LISP NAT Traversal
>>> 
>>> Hi,
>>> 
>>> It will be useful if LISP NAT traversal draft
>>> (draft-ermagan-lisp-nat-traversal) can elaborate on the following
>>> 
>>> 1) Why LISP NAT traversal cannot be accomplished without RTR (another network entity) which has implications on deployability, complexity and latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T without the need for additional network entity.
>>> 
>>> 2) Some more details on RTR deployment
>>> - location of RTR in the LISP deployment like there are 
>>> recommendations on PITR/PETR deployments
>>> - is RTR shared across LISP sites behind NAT or each site needs a 
>>> dedicated RTR
>>> - what if RTR is behind another NAT (SP-NAT)
>>> 
>>> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT)
>>> 
>>> Thanks,
>>> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior 
>>> Technical Leader CSG PI Services Security - India
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 