Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01

["Valery Smyslov" <[e-mail]>]

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
> 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.

I'm puzzled here... The whole idea of QSKE is a considerable deviation
from standard IKEv2. Comparing to the amount of needed changes
to the protocol, introducing a new exchange that follows standard IKEv2 
rules looks like a simple task. I believe it is easier than making all 
the modifications from the draft to the IKE_SA_INIT (that is already quite complex).

> 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. 

If you put all the QSKE payloads in a single IKE_AUX (and won't do them
one by one in a series of IKE_AUX), you'll have the same number of round trips 
as in your proposal. I see no advantage of your proposal here.
Am I missing something?

> 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. 

It won't help you against poisoning reassembly queue with a bogus packets,
since an attacker would know the correct cookie from the first round.
And this attack is not possible at all with IKE_AUX (unless an attacker breaks
classic DH in a real time). Please, see ipsecme mail archives from 2012-2013
where all these things concerning possible attacks on IKE fragmentation were 
discussed in detail.

> 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. 

This is a different kind of attack and your proposal is susceptible to it as well. 
Moreover, the attack is described in the RFC7296 (Section 2.4, page 29)
and some countermeasures are suggested.

> 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.

Please, elaborate. Unless you mandate requesting cookie, your 
proposal is no more secure against this attack than classic IKEv2 or IKE_AUX.
And mandating requesting cookie can be an option for all of them.

When I was talking about DoS attack on your proposal that are not 
possible in IKE_AUX approach, I meant an reassembly queue poisoning
attacks. Besides your proposal is more complex and less robust...

> 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.

Well, with IKE_AUX we have this bonus almost for free too.
However I agree that we'd better to avoid such huge KE payloads...

> Best regards,
> Authors of draft-tjhai-ipsecme-hybrid-qske-ikev2-01

Regards,
Valery.