Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

2016-01-06 Thread Paul Wouters

On Wed, 6 Jan 2016, Perlner, Ray wrote:


NIST is investigating quantum-resistant alternatives to presently standardized 
public-key algorithms. We are
reaching out to the IPSec working group to determine if there are any unique 
needs associated with trying to
add quantum-resistance to IKEv2, which currently only uses variants of the 
Diffie-Hellman key exchange.


There is:

https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01

It was thrown out of the working group before. I think it is time to
reconsider with everyone focusing on post-quantum worlds.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[IPsec] NIST question concerning IKEv2 and quantum resistance

2016-01-06 Thread Perlner, Ray
Hi all.

NIST is investigating quantum-resistant alternatives to presently standardized 
public-key algorithms. We are reaching out to the IPSec working group to 
determine if there are any unique needs associated with trying to add 
quantum-resistance to IKEv2, which currently only uses variants of the 
Diffie-Hellman key exchange.

We believe a number of the properties of the Diffie-Hellman construction (such 
as perfect forward secrecy) can be met using generic constructions based on 
standard cryptographic primitives and security models (such as IND-CCA2 
encryption and EUF-CMA signature) as long as key generation times are fast. If 
IKEv2 can accommodate such generic constructions, there are likely to be many 
proposals to choose from. However, there are some additional properties of the 
Diffie-Hellman exchange which may be difficult to duplicate (such as the 
property that the responder can compute his key exchange message without seeing 
the initiator's key-exchange message) and it's not as clear to us what the 
security model for a key exchange replacing DH should be.

So in summary, we would like to answers to the following questions:

1)  Can IKEv2 can be modified to replace the Diffie-Hellman exchange with a 
generic construction based on standard encryption, signature, and PRF 
primitives?

2)   If not, what specific security and correctness requirements should we 
target to meet the need?

Thanks,
Ray





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec