On Wed, 30 Nov 2022, Valery Smyslov wrote:
Yes I meant the abstract :)
I'm a bit reluctant to add all this information to the abstract. It is already
a bit too long
(since Éric and Warren suggested to augment it with the explanation text of how
this design helps in situation when PQ algorithms are less trusted). So
currently
the abstract is:
This document describes how to extend the Internet Key Exchange Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place
while computing a shared secret during a Security Association (SA) setup.
The primary application of this feature in IKEv2 is the ability to
perform one or more
post-quantum key exchanges in conjunction with the classical (Elliptic
Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer
attacks.
Since there is currently no post-quantum key exchange that is trusted at
the level that (EC)DH is trusted for against conventional (non-quantum)
adversaries, performing multiple key exchanges with different
post-quantum algorithms along
with the well-established classical key exchange algorithms addresses
this concern, since the
overall security is at least as strong as each individual primitive.
Another possible application for this extension is the ability to
combine several key exchanges
in situations when no single key exchange algorithm is trusted by both
initiator and responder.
This document updates RFC7296 by renaming a transform type 4 from
"Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload
from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this
transform type
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
"Transform Type 4 - Key Exchange Method Transform IDs". These changes
generalize
key exchange algorithms that can be used in IKEv2.
Do you *really* want to make it longer? I'm not sure that if we just mention
the names of the added exchange and notifies, that will help readers of the
abstract
to understand what this document is about...
This document updates RFC7296. It introduces the IKE_FOLLOWUP_KE Exchange. It
renames [...]
[update]
I've just noticed your message sent in response to Warren. So, since you insist
:-),
I suggest adding the following text before "This document updates...":
This document utilizes the IKE_INTERMEDIATE exchange to perform multiple key
exchanges when
an IKE SA is being established and introduces a new IKEv2 exchange
IKE_FOLLOWUP_KE to perform
them when IKE SA is up (during rekeys or creating additional Child SAs).
is it now OK?
Also fine :)
I don't think it would hurt pointing to Section 2.4 of RFC 7296. I see
this as a likely possible implemention mistake.
My problem with your proposal here is that this situation is not
specific to this document. In other words, whether the initiator
proposes any additional key exchanges or not, if an attacker
manages to send a response before the genuine responder
and the initiator continues establishing IKE SA using this response,
then it will fail. There is nothing specific to the multiple key exchanges.
And we implicitly assume that implementations follow RFC 7296.
I want to prevent code like:
if (AKE-required && !AKE-received)
return STF_FATAL // kills state
I know it is a "reminder", but I think an important one.
So it is not clear that a large part of this paragraph does not in fact
involve "state lost due to reboot". So please split the paragraph a bit
into pieces to make this more clear.
Actually, it is already split in two paras. I've added some clarification text
into the
beginning of the second para, now they look like:
(maybe it was unclear because there was a page break there)
It is possible that due to some unexpected events (e.g. reboot)
the initiator may lose its state and forget that it is in the process of
performing
additional key exchanges and thus never start the remaining IKE_FOLLOWUP_KE
exchanges.
The responder MUST handle this situation gracefully and delete
the associated state if it does not receive the next expected
IKE_FOLLOWUP_KE request after some reasonable period of time.
Note that due to various factors such as computational resource and
key exchange algorithm used, it is not possible to give a normative
guidance on how long this timeout period should be. In general, 5-20
seconds of waiting time should be appropriate in most cases.
It is also possible that it takes too long for the initiator to
prepare and send the next IKE_FOLLOWUP_KE request or due to the network
conditions it is retransmitted. In this case the request may reach the
responder
when it may have already deleted the associated state following the advice
above.
If the responder receives IKE_FOLLOWUP_KE and the content of this notify
does not correspond
to any active key exchange state the responder has, it MUST send back a new
error type notification
STATE_NOT_FOUND ...
Does this resolve your concern?
Yes.
Just a one sentence somewhere would be nice yes.
OK, if you insist :-)
I've created a new section "Interaction with IKEv2 Extensions" with a single
para:
It is believed that this specification requires no modification to the IKEv2
extensions defined so far.
In particular, IKE SA resumption mechanism defined in [RFC5723] can be used
to resume
IKE SAs created using this specification.
and I also put the section "Interaction with Childless IKE SA" as a subsection
in this section.
Awesome!
Just give it some thought, but if we leave it as is that is fine too.
As I'm lazy, I prefer to do nothing here (unless you or my co-authors strongly
disagree :-))
Fine with me. Can't get worse than CREATE_CHILD_SA I guess :P
Related to this is text in the Security Considerations:
```
In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
algorithms.
```
This text is also incorrect as RFC 7427 allows us to use post-quantum
authentication
algorithms that have a SubjectPublicKeyInfo (SPKI) definition. There might not
be any
now, but there will presumbly be some in the future.
Do you want to augment this text? Any suggestions?
How about:
In particular, the authenticity of the SAs established under IKEv2
are not protected with post-quantum algorithms.
This is not accurate, using PSK for authentication provides defense against QCs
(which is described in the following sentence).
How about
In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key or digital signature
algorithms.
and note, that at the end of this para the possibility of using
post-quantum digital signature algorithms in IKEv2 is already mentioned
(I guess it was your concern).
Okay.
Well, when reading I was wondering if this had to be childless, so I
think it would be good to remove that confusion. But whatever you decide
is fine. This is just my comment.
The I'd leave the text as is unless my co-authors disagree.
Okay.
I also think that is only a reason to ignore the CREATE_CHILD_SA, and
not a reason to destroy the existing IKE SA (and thus any existing Child
SA)
Well, generally invalid response means that there is something wrong
with the peer thus we cannot be sure that it follows spec.
Yeah but stabbing them in the heart in case they might be dying is a bit
drastic :P
Put it in another way, I would violate the RFC on this point and keep
the existing IKE SA until its lifetime has been reached.
I think that the text may be clarified a bit. How about?
I guess first we need to agree on what to do.....
OK, let me clarify our point.
First, there is nothing specific to the multiple key exchanges here. The
situation is that
the responder sends a message that is inappropriate from the protocol point of
view.
There may be many reasons to consider it inappropriate - missing mandatory
payload, incorrect choice of algorithms etc., this specification just adds one
more reason - duplicated algorithms.
What should the initiator do in this situation? It generally cannot send
INVALID_SYNTAX,
since RFC 7296 discourages doing so (section 2.21.3):
Because sending such
error messages as an INFORMATIONAL exchange might lead to further
errors that could cause loops, such errors SHOULD NOT be sent.
The initiator generally cannot continue using this SA, because of possible
the states on the peers are now out of sync (the responder thinks the exchange
completed successfully).
So the safe way is to delete the problem SA. If it is not yet created, then
just stop creating it,
otherwise send a Delete payload.
Note, that the text you proposed
the initiator should log the error and MUST abort the exchange with a
permanent error
actually has the same consequence. Since the responder sent a response with no
error notify,
it thinks that the exchange is completed successfully. On the other hand, your
text suggests
that the initiator treat this exchange as failed. So, the states on the
initiator and the responder
are now out of sync. RFC 7296 states (2.21.3):
If errors are seen that indicate that the peers do not have the same
state, it might be good to delete the IKE SA to clean up state and
start over.
"might" :-)
Again, I agree on killing the newly failed SA. But let's say you have an
IKE SA up and a Child SA up (might even be a child using classic algo
only), I don't see why adding a new Child SA that fails should kill the
existing functional Child SA and IKE SA.
Sure there should be a loop detection and exponential back-off on
failures to prevent a DoS of trying to get this post-quantum Child SA
up. But tearing down the existing Child SA and IKE SA will presumbly
just cause a more complicated loop anyway. These working SA's will come
back up again and then get torn down again when the post-quantum Child
SA fails. So I don't think your suggestion is better.
### Section 3.2.2
```
The other keying materials SK_d, SK_ai, SK_ar, SK_ei,
SK_er, SK_pi, SK_pr are updated as:
[...]
```
Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, SK_pr are generated from the SKEYSEED(n) as per RFC 7296.
No objection.
Just to clarify, where I wrote [...] I meant to cover the illustration
under the text as well. The point of this change was to not repeat a
stock 7296 exchange (which might confuse implementers in believeing this
is different from stock 7296)
I'd rather to keep the illustration. There is a subtle difference from RFC 7296
-
while keys have "generation", the SPIs and nonces are used from the IKE_SA_INIT.
The illustration makes this difference more clear, in my opinion.
If you want to keep the illustration, then just ignore this entire
change I proposed or it becomes duplicative.
My problem is that I don't understand what it means to "dwarf" an
attack. My brain thinks of throwing Gimli,Dwalin, Balin and Thorin
into the attack.
:-)
This text has been already changed to
Simply increasing the key length can mitigate this attack.
by request from Sean.
:-)
The updated PR is available at:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22
If you get a new draft before tomorrow 10am EST, I can update my DISCUSS
to a YES ballot :)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
