Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01
Paul Wouters writes: > On Mon, 12 Feb 2018, Valery Smyslov wrote: > > >> This is one particular implementation peculiarity, there > >> will be others that behaves oddly. The point is, if we introduce a new > >> Transform Type, it is very likely that backward compatibility can no > >> longer be achieved. > > > > Again, it depends. If the majority of implementations immediately crash > > once they > > receive unknown transform, then I agree that we need another mechanism... > > Most of other cases usually can be dealt with. Probably not all and probably > > not as elegant as we wish, but still I believe they can. > > We still have plenty of time to get the word out to those > implementations to fix their problem. By the time we have a > document ready for post quantum transforms, those implementations > should have been fixed. It's a little early now to deem this > an unsurmountable problem. Yes. Also there is big difference in requirements for draft-ietf-ipsecme-qr-ikev2 and requirements for proposal doing proper quantum safe algorithms. The draft-ietf-ipsecme-qr-ikev2 is intended to be deployed now, and should work with existing implementations without fatal interoperability errors with them. As quantum safe algorithms itself are so much in ongoing research now, I do not think we will be having implementations out there using any of the quantum safe algorithms now, and so there will be time for broken implementations to get fixes installed to them. I.e., if you still plan on running completely broken strongswan implementation which do not implement MUSTs in IKEv2 for example in year 2019, then you are not interested in security, thus you are not really going to be even try to use anything like quantum safe algorithms to talk to them... I mean, if you plan not to install security updates to your IPsec products for years to come, it does not matter what we do, you most likely have big security holes in your gateways anyways. Even RFC4306 said you "MUST contain exactly one transform of each type included in the proposal" in section 2.7, so what they are doing has never been allowed in the IKEv2. In the RFC5996 we did add text saying: If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. and if they have not updated IPsec implemenation since 2010, again there will most likely be so many holes in it that there is no point of talking about quantum safe algorithms... We have discussed several times of adding new transform types, and in most cases we have found better ways of doing that. On the other hand there is nothing that would make it impossible to add new transform types. IKEv2 has been designed so that new things can be added without breaking old implementations (provided old implementations actually follow what was written in the IKEv2 RFCs). In this case I think I agree with Valery that adding new transform types might be good option, and we should investigate that option too. > > I prefer to reuse existing code for this and I see no reason why > > it cannot be done. > I agree. Making IKE_SA_INIT more complicated than what is now, is something we do not really want to do. It is first exchange with the peer, it has all kind of denial of service properties which we should try to cope. We do not want to make it so big it will get larger than one kilobyte in size, so it will not get fragmented by the IP layer etc. Doing fragmentation on that layer is very hard if we want to protect that also against DoS. I am very much suprised that some of the vendors really said that they wanted to change the IKE_SA_INIT instead than add new exchange between IKE_SA_INIT and IKE_AUTH. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01
On Mon, 12 Feb 2018, Valery Smyslov wrote: This is one particular implementation peculiarity, there will be others that behaves oddly. The point is, if we introduce a new Transform Type, it is very likely that backward compatibility can no longer be achieved. Again, it depends. If the majority of implementations immediately crash once they receive unknown transform, then I agree that we need another mechanism... Most of other cases usually can be dealt with. Probably not all and probably not as elegant as we wish, but still I believe they can. We still have plenty of time to get the word out to those implementations to fix their problem. By the time we have a document ready for post quantum transforms, those implementations should have been fixed. It's a little early now to deem this an unsurmountable problem. I prefer to reuse existing code for this and I see no reason why it cannot be done. I agree. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01
Hi, thank you for the explanation. See my comments inline. > 1. Negotiation > > We are glad to see that you also appreciate the need to negotiate a > hybrid group. As you may remember, we introduced a new Transform Type > in our version 00 of our draft and it had not been well-received in > IETF 99 Prague. We accept this push-back and it makes sense; since the > introduction of IKEv2, there has not been any new Transform Type > introduced. In fact, after IETF 99 Prague, we found out that there > exists IKEv2 implementations out there that will error out if they > receive an unknown Transform Type. I'm not sure it justifies introducing yet another negotiation mechanism. I understand that we live in non-ideal world, however adding one more mechanism for solving exactly the same problem due to existence of buggy implementations looks far too expensive for me. Unless these buggy implementations dominate... > As you pointed out, according to RFC 7296, if a responder receives a > proposal with Transform Type that it doesn't understand, it MUST > reject the proposal. However, we found that this is not true in > practice. StrongSwan is a good example; consider you have two peers > running StrongSwan where the initiator introduces a proposal > containing a new Transform Type: > > SA: > Proposal 1: > Transform Type 1: ENCR_AES_CBC > Transform Type 2: PRF_HMAC_SHA2_256 > Transform Type 3: AUTH_HMAC_SHA2_256_128 > Transform Type 4: P-256 > Transform Type 6: New Transform Type > Proposal 2: > Transform Type 1: ENCR_AES_CBC > Transform Type 2: PRF_HMAC_SHA2_256 > Transform Type 3: AUTH_HMAC_SHA2_256_128 > Transform Type 4: MODP-3072 > > It is assumed that the responder runs StrongSwan implementing standard > RFC 7296, hence it does not understand Transform Type 6. Instead of > rejecting Proposal 1 and considering Proposal 2, the responder ignores > Transform Type 6 (i.e. selecting ENCR_AES_CBC, PRF_HMAC_SHA2_256, > AUTH_HMAC_SHA2_256_128, P-256). The initiator clearly does not propose > this proposal. This particular case would only be okay if Proposal 2 > offers P-256. This behavior is wrong, however I don't think it cannot be dealt with. Just always define your policies so that all PSKE proposals contain the same "classic" transforms, as "classic" proposal. This is an additional requirement for policy, but Is there any reason this is wrong from security point of view? > This is one particular implementation peculiarity, there > will be others that behaves oddly. The point is, if we introduce a new > Transform Type, it is very likely that backward compatibility can no > longer be achieved. Again, it depends. If the majority of implementations immediately crash once they receive unknown transform, then I agree that we need another mechanism... Most of other cases usually can be dealt with. Probably not all and probably not as elegant as we wish, but still I believe they can. > Hence, we pick a DH group that denotes a hybrid group and negotiate it > using the existing KE payload. Well, if you are so determined to deal with buggy implementations, then there are more natural alternatives. For example you may introduce a new SA-like payload, which would have the same syntax as SA payload, but different Payload Type, and put all PSQE stuff there. Since Critical Bit is not set in this payload, the existing implementations must ignore it. And if you find implementations that won't behave correctly even in this case, then put SA-like syntax in a new notify - I'm sure every existing implementation can handle this. So, my main concern is that with your proposal a new code is needed to parse, form, log etc. all the QSQE stuff, since it is presented in a completely new way. It is not a big deal if the amount of negotiation stuff is small (say, you define only one QSKE group). In your case, you want to express a complex combinations of different QSKE methods, which I, as implementer, would need to parse, form, log, match to policy etc. I prefer to reuse existing code for this and I see no reason why it cannot be done. > On your email, you also mentioned that in the future, we could use KE > payload to carry small PQ KE payload. Then, some logic is required to > distinguish what is carried in IKE_SA_INIT and what is carried in > IKE_AUX; it looks messy. It is easy. "Classic" KE is always done in the IKE_SA_INIT. All PQ KEs are done in the IKE_AUX. However, once one (or few) of the PQ KEs is considered cryptographically matured and this PQ KE has small enough public key, we'll add it as a new "classic" one, so that in done in the IKE_SA_INIT. No mess here. > 2. Fragmentation > > We remember that Tero did suggest to use an intermediary exchange > between IKE_SA_INIT and IKE_AUTH. However, after soliciting inputs > from a number of parties (both vendors and clients), it appeared that > the majority didn't like the idea of having this extra exchange as >
Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01
Hi Valery, Many thanks for your email and also your interest in our draft. As we explain in detail below, we don't agree with your conclusion that our proposal is overcomplicated, does not take into account what is out there, and insecure. Even if some of the features that we introduce deviate from standard operation, we did so after checking with clients and vendors. One of the features that they are keen on is the possibility of reusing KE payload to negotiate hybrid post-quantum groups or proposals. Please find below our response regarding the points you made. 1. Negotiation We are glad to see that you also appreciate the need to negotiate a hybrid group. As you may remember, we introduced a new Transform Type in our version 00 of our draft and it had not been well-received in IETF 99 Prague. We accept this push-back and it makes sense; since the introduction of IKEv2, there has not been any new Transform Type introduced. In fact, after IETF 99 Prague, we found out that there exists IKEv2 implementations out there that will error out if they receive an unknown Transform Type. As you pointed out, according to RFC 7296, if a responder receives a proposal with Transform Type that it doesn't understand, it MUST reject the proposal. However, we found that this is not true in practice. StrongSwan is a good example; consider you have two peers running StrongSwan where the initiator introduces a proposal containing a new Transform Type: SA: Proposal 1: Transform Type 1: ENCR_AES_CBC Transform Type 2: PRF_HMAC_SHA2_256 Transform Type 3: AUTH_HMAC_SHA2_256_128 Transform Type 4: P-256 Transform Type 6: New Transform Type Proposal 2: Transform Type 1: ENCR_AES_CBC Transform Type 2: PRF_HMAC_SHA2_256 Transform Type 3: AUTH_HMAC_SHA2_256_128 Transform Type 4: MODP-3072 It is assumed that the responder runs StrongSwan implementing standard RFC 7296, hence it does not understand Transform Type 6. Instead of rejecting Proposal 1 and considering Proposal 2, the responder ignores Transform Type 6 (i.e. selecting ENCR_AES_CBC, PRF_HMAC_SHA2_256, AUTH_HMAC_SHA2_256_128, P-256). The initiator clearly does not propose this proposal. This particular case would only be okay if Proposal 2 offers P-256. This is one particular implementation peculiarity, there will be others that behaves oddly. The point is, if we introduce a new Transform Type, it is very likely that backward compatibility can no longer be achieved. Hence, we pick a DH group that denotes a hybrid group and negotiate it using the existing KE payload. On your email, you also mentioned that in the future, we could use KE payload to carry small PQ KE payload. Then, some logic is required to distinguish what is carried in IKE_SA_INIT and what is carried in IKE_AUX; it looks messy. 2. Fragmentation We remember that Tero did suggest to use an intermediary exchange between IKE_SA_INIT and IKE_AUTH. However, after soliciting inputs from a number of parties (both vendors and clients), it appeared that the majority didn't like the idea of having this extra exchange as introduced a considerable deviation from standard IKEv2 flow and felt that we would just be introducing an IKE_SA_INIT fragmentation which could be achieved by other mechanisms. While IKE_AUX would be useful in environment where network is lossy, we also need to consider the requirements for applications such as VPN concentrator where connection rate is important, or peers that have a considerable route trip time. We acknowledge that we have not included any mechanisms to deal with loss packets in version 01 of our draft. This is intentional as we would like to get the WG input on which direction we should take our draft before going deeper. In terms of DoS attacks, we do not mandate the use of cookie mechanism, but when implemented, the responder can check that incoming messages corresponding to the second round of our protocol (note that this is the expensive round in which public-key operations are performed and space is allocated) have been agreed previously in a first round of the protocol. We also believe that your comment that what you propose is substantially more secure is not true. An attacker who can monitor exchange of messages and inject packets, can trivially DoS a connection (e.g. when the initiator sends the initial "HDR, SAi1, KEi, Ni", the attacker immediately responds with a "HDR, SAr1, KEr, Nr" of his choosing before the real responder does). An attacker who can modify the initial packets is not detected until later in the exchange. Of course, this could require a significant amount of resource allocation for post-quantum public data exchange. In our approach, we could detect it before IKE_AUTH phase. 3. Large payload We also hope that we don't end up having PQC ciphers with large public-key. We don't mandate our proposed draft to support payloads larger than 64KB. In fact, it is an added bonus of how we do fragmentation. Best
