[This replies to emails other people also sent to list, but I just picked the last email to list some points, and I am talking here as an implementor not as a chair].
David McGrew writes: > Yes; that draft is a good starting point. The goal should be to > develop an RFC that updates RFC 7383 and specifies how Postquantum > Preshared Keys (PPKs) can be used, in a manner that is operationally > similar to IKE preshared keys, to achieve postquantum security. > The WG should decide whether identity protection is needed, or > whether it can be traded for simplicity. One note you should remember that IKEv1 does not have any identity protection when using shared keys with main mode. The responder MUST know from the IP address alone who the other end is, thus the whole world will know that this identity is same identity than the last one coming from the same IP... I.e. as the shared key is used to derive the encryption key for the IKE message protecting the ID payload you need to know the shared key before you can decrypt the message containing ID to find who the other is, thus the ID you get is useless for you as you must have already picked up one shared key before getting that far. People who say that IKEv1 is quantum computing resistant because it does exactly this (i.e. the pre shared key is used to derive keys) clearly do not care about identity protection. Because of that I think the limited identity protection should be ok, i.e., identity protection for the initiator can be broken by active attacker (like in IKEv2 now), and it should be ok even if it broken for both parties if Diffie-Hellman done in the IKE is broken. The identity protection against the responder has always been bit vague, as normally responders identity is always known because he has fixed ip-address or that ip-address is advertised somewhere etc. We had long discussions about these when we were doing IKEv2, and we ended up with the current compromise, i.e. IKEv2 identity protection protects identities against passive attacker provided attacker cannot break Diffie-Hellman, but does not protect identity protection against active attacker. Also note that the way shared keys were used in the IKEv1 also caused the fact that main mode with pre shared keys cannot really be used for mobile users, or devices coming from behind nat, etc. This has really limited the identity protection offered by IKEv1 in real use as users use aggressive mode which do not have identity protection at all. Also even if the IP-numbers are static it caused all kind of wierd errors, as mistyped shared key caused decryption errors in the IKE packet handling, causing the detecting such situation hard (usually when you have decryption error you simply silently ignore the message, but for authentication failures, it would be nicer to return the error saying authentication failed so the user experience would be better, IKEv1 cannot do that). Because of this I think it is better to just stick with the current identity protection method, i.e., do not derive IKE SA encryption keys from the shared secret, i.e., active attacker can still get the IDi... > Other approaches, such as QKD or using a long stream of shared > secret key material obtained from an arbitrary source, should be > addressed through separate documents, because they are not needed to > address the above problem, and because they do not meet the > requirement of operational similarity with current practice. A > sequence of key material intended for one-time use is not the same > as a PPK, and the logic needed to handle indexing and sequencing > should not be imposed on the RFC that addresses the immediate need. Earlier I have proposed very simple method where the IKE_SA_INIT contains just some kind of notification messages identifying the "oob-key" to be use. This identification information is completely opaque, and fully depends on the implementation. It could be fixed random string, which would immediately leak out the identity of the users, just like IKEv1 IP-address did. It could just random identifier, which identifies the one-time-use shared secret from big table (which is shared between the end nodes), it could be some kind of encrypted blob, which is encrypted with some kind of system wide group shared key (i.e., everybody in the group know it, but outsiders do not, so it protects identities for outsiders, but not for insiders), or it could be something more complicated like what current draft proposes. For the IKEv2 protocol point of view it is just opaque binary object which is given to the subsystem which will then return a shared key to be used for him. In all cases both ends must share the same shared key or table of shared keys or access to the QKD subsystem, so this code that knows how this blob is interpreted can be left to the implementations. We do not need to standardize it, we can leave it open, just like we leave cookie or the IKEv2 session resumption ticket format. We could include some proposals in the appendix, and we might want to add 16-bit "format identifier" in the beginning just in case people want mix multiple methods in same implementations. This means that the level of shared key identity protection is left to implementation and to it depends on the policy settings. When IKEv2 then has the shared secret then it needs to mix that to some parts of the cryptographic protection to provide quantum resistant IKEv2. There are multiple levels on that: 1) Include it only in KEYMAT. This will protect all IPsec SAs, i.e. the actual traffic transmitted over IPsec is protected from attackers able to break the Diffie-Hellman of the IKEv2. I.e., replace SK_d in there with (SK_d | OOB_secret). Note, this have also the side effect that after the first IKEv2 rekey also the IKEv2 SA traffic is protected, as new keying material after the IKEv2 rekey depends on the SK_d. 2) In addition to the 1, include it also in the SK_pi and SK_pr. This will mean that even if the attacker is able to break Diffie-Hellman and the Signature method, he will not be able to authenticate as user, as he cannot calculate the MACedIDforI/MACedIDforR for authentication. I.e. replace SK_pi and SK_pr with (SK_pi | OOB_secret) and (SK_pr | OOB_secret). 3) Include it in the SKEYSEED calculation. This will has the side effect that we are no longer able to get meaningfull error messages in case something goes wrong in the OOB key identification process, i.e., in case the OOB_secrets do not matchi, we just drop the frame and wait for next one, thus we cause timeout if OOB_secret is wrong. This is bad for user experience, but this will also protect the IKEv2 SA traffic with the OOB_secret. And, no please do not propose that we make this negotiated... Lets pick one and use it. I am in favor of 2, because it offers most, but does not cause problems. And if someone wants to protect traffic selectors and future traffic in IKEv2, they can simply do IKE_SA_INIT + IKE_AUTH with childless initiation, and then immediately do IKE SA rekey, and then CREATE_CHILD_SA to create Child SAs. > Going a little further off topic, with any technology (like QKD or a > one-time pad) that is predicated on the idea that computational > cryptography cannot be fully trusted, there should be a detailed > security analysis of how it is integrated into IPsec/IKE, which > shows how to use the technology along with other IPSec mechanisms in > a way that is consistent with its security assumptions. In short, > the usage of technologies that are only interesting in scenarios > that include major advances in cryptanalysis should be specifically > crafted to minimize the risk of those advances. No such analysis has > yet been put forward. The analysis of key renewal rates in the > SECOQC White Paper on Quantum Key Distribution and Cryptography > [Section 3.2 of > http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance, > neglects to consider the risk of a key collision attack, and does > not attempt any formal/provable security framework. The IPSec WG > should expect this analysis before any standards are developed that > support these new technologies, and those standards should clearly > state what advantages the new technologies have, and in what > scenarios they should be used, and what sort of other IPSec > algorithms and options are consistent with good security. Please > note that I am not objecting to the IPSec WG taking up this work; I > am pointing out that there is a lot of work involved, which > underscores the importance of dealing with it in a way that is > separate from the immediate need of parity between IKE versions. I do not think that is reasonable for the IPsecME WG. We do not have security analysis on the use of ChaCha20/Poly1305 on IPsec/IKE. We do not have security analysis on most of the other things either. We should simply provide requirements for the OOB_secret provided by the subsystem and that should be enough. I.e., it should be enough to say that OOB_secret MUST be longer than 16 octets, and MUST NOT be longer than 64 octets, and to provide protection against attackers able to break Diffe-Hellman in IKEv2 it must be something that attackers cannot guess or know... That should be enough to make it secure for IKEv2 use. That was one of the reasons why I was so much against the QKD draft originally getting rid of the whole Diffie-Hellman in IKEv2, and only using the OOB_secret. I want the failure model of the OOB_secret to be so that the IKEv2 still as safe as it is now (yes, there might be some leak on the ID part in the OOB key identification process, but the IPsec traffic is still safe). Anyways, either one of those draft is good starting point for this work. It does not really matter which one we pick, we then just need to change it to what WG things is approriate for this protocol (i.e., which compromizes we take, and which we do not take). Ps. And now back to my vacation, so I most likely will not reply back until I get back from my last week of vacation. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
