Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize the > issue of DoS attacks during intermediate exchanges. The new version does > address it by mentioning the > option of simply avoiding intermediate exchanges altogether but still require > additional key exchanges. Yet, > this protects only against record-and-harvest attacks but not against an > attacker with a strong quantum > computer at the time of the handshake, regardless of quantum-resistant > authentication (since they can break > the initial shared secret and therefore recalculate the MAC which > authenticates the followup exchanges, fully > establishing a man-in-the-middle). We doubt that an attacker, even with a > strong quantum computer, is able > to break a key exchange in such a short time period. Still, this assumption > is too theoretical to rely on. This, > together with the fact that Group-IKE is incompatible with key exchanges > during followup exchanges, makes > the option seem inferior to just sticking to intermediate exchanges during > the handshake. However, we must > also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting seven > additional maximum size McEliece > key exchanges, can force a gateway to accept and process 1.4MB of data per > McEliece KEM.
Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perform (including additional key exchanges), and you can limit the types and the number additional key exchanges the responder will accept via its local policy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA initially > unprotected and being vulnerable to > an attacker with a quantum computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another > solution which sees one new > transform type, e.g., SNTRUP761X25519, which then defines a combination of > one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which defines a new key exchange algorithm which is a combination of SNTRUP761 and X25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into IKE_SA_INIT > without fragmentation (like > sntruprime761). The two secrets get concatinated and then fed to a hash > function. The resulting hash is used > as the shared secret for further key derivation. This mechanism is low effort > in terms of implementation and > does not affect the state machine at all, but already offers a high level of > protection against all attacks as long > as there is no major break-through in cryptanalysis. Furthermore, it is the > accepted approach for most of the > applications of post-quantum key exchanges. For higher long-term security, it > can be combined with other, > more conventional algorithms which follow either in intermediate or followup > exchanges. I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in terms of consuming responder's resources. The responder still needs to perform both X25519 and SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the context of > option 3, which removes the risk > of the described DoS attacks. Yet, to prevent the insecurities of plain > option 3, we also propose to make it > mandatory to combine it with the new hybrid transform type, i.e., > SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible with > the McEliece exchange. However, > the fact that G-IKE exchanges sensitive information before authentication > makes it impossible to be not > vulnerable against the discussed DoS attack and, at the same time, support > the McEliece algorithm. Thus, we > see that as a decision to be made in the G-IKE standardization track, not in > IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
