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:sva...@gmail.com] Sent: Thursday, July 27, 2017 10:39 AM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; David McGrew (mcgrew) <mcg...@cisco.com>; Panos Kampanakis (pkampana) <pkamp...@cisco.com> Cc: ipsec@ietf.org 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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
