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

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 1 Aug 2017 15:45:03 +0000

Thank you for the text Valery. We appreciate it.
We might reorganize it in a section that basically talks about PPKs, PPK Distribution and PPK operations. The changes will go in the next iteration. As discussed in Prague we will try to have normative language to make clear that null auth is not recommended and that the caveats of using group PPKs. 
Panos

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]] 
Sent: Thursday, July 27, 2017 10:39 AM
To: Scott Fluhrer (sfluhrer) <[email-masked]>; David McGrew (mcgrew) <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]
Subject: Proposed text for the draft-fluhrer-qr-ikev2

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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 1 Aug 2017 22:09:09 +0300

Hi Panos,

I don't think we should make NULl Auth NOT RECOMMENDED. If PPK is in use it becomes
non-NULL, since authentication is provided by PPK. I think it is a valid option -
it just relies on PPK only and doesn't use any conventional authentication, like certificates.
Just make sure that Identity Payload is not of type ID_NULL...

On the other hand, using group PPK must be discouraged, especially in conjunction
with NULL auth, so I think NOT RECOMMENDED is a right choice here.

Regards,
Valery.

-----Original Message----- 
From: Panos Kampanakis (pkampana)
Date: 1 августа 2017 г. 18:45
To: Valery Smyslov ; Scott Fluhrer (sfluhrer) ; David McGrew (mcgrew)
Cc: [email-masked]
Subject: RE: Proposed text for the draft-fluhrer-qr-ikev2

Thank you for the text Valery. We appreciate it.
We might reorganize it in a section that basically talks about PPKs, PPK Distribution and PPK operations. The changes 
will go in the next iteration. As discussed in Prague we will try to have normative language to make clear that null 
auth is not recommended and that the caveats of using group PPKs.
Panos

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]]
Sent: Thursday, July 27, 2017 10:39 AM
To: Scott Fluhrer (sfluhrer) <[email-masked]>; David McGrew (mcgrew) <[email-masked]>; Panos Kampanakis (pkampana) 
<[email-masked]>
Cc: [email-masked]

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.

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.

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.