Subject: [IPsec] Proposed text for the draft-fluhrer-qr-ikev2

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 27 Jul 2017 17:38:30 +0300

Hi,

at the ipsecme meeting in Prague I was asked to contribute a text
for the draft-fluhrer-qr-ikev2 about operational considerations.
Here is my try. I think the text should be placed into a new section,
"Operational Considerations". Any thoughts?

Regards,
Valery.

X. Operational Considerations

This document provides a solution that doesn't replace classical
public key cryptographic mechanisms used in IKEv2, like (EC)DH or digital signatures . 
Instead, the proposed solution extends these mechanisms by using 
an additional security credential, namely PPK, to make IKEv2 secure
against Quantum Computers. In practice it means, that each peer
must possess two security credentials to successfully complete authentication - 
a classic one (like certificate private key) and a PPK. 

The need to maintain several independent sets of security credentials 
can significantly complicate security administrators job, and can potentially 
slow down widespread adoption of this solution. It is anticipated, that 
administrators will try to simplify their job by decreasing the number of
credentials they need to maintain. Two possible approaches are given below. 

X.1 Group PPK

This document doesn't explicitly require that PPK is unique for each pair of peers.
If it is the case, then this solution provides full peer authentication, but it also
means that each host must have that many independent PPKs, how many peers
it is going to communicate with. As the number of hosts grows this will scale badly.

It is possible to use a single PPK for a group of users. Since each peer uses
classical public key cryptography in addition to PPK for key exchange and authentication, 
members of the group can neither impersonate each other nor read other's traffic, 
unless they use Quantum Computers to break public key operations. 

Although it's probably safe to use group PPK in short term, the fact, that 
the PPK is known to a (potentially large) group of users makes it more susceptible
to a theft. If an attacker equipped with a Quantum Computer 
get access to a group PPK, then all the communications inside the group 
are revealed.

X.2 PPK-only Authentication

If Quantum Computers become a reality, classical public key cryptography
will provide little security, so administrators may find it attractive
not to use it at all for authentication. This will reduce the number of credentials
they need to maintain to PPKs only.

PPK-only authentication can be achieved in IKEv2 if NULL Authentication method 
[RFC7619] is employed. Without PPK the NULL Authentication method provides 
no authentication of peers, however since PPK is stirred into SK_pi and SK_pr, 
the peers become authenticated if PPK is in use. Note, that using PPK MUST be mandatory 
for both Initiator and Responder if PPK-only authentication (i.e. the NULL Authentication 
method + PPK) is employed.

Combining group PPK and PPK-only authentication is NOT RECOMMENDED,
since in this case any member of the group can impersonate any other member 
even without help of Quantum Computers.