Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

[Tobias Brunner <[e-mail]>]

Hi Paul,

>> * maybe add "incompatible proposal" as a reason for initiating a
>>   regular Child SA rekeying of the first SA (if the KE method used
>>   for IKE is not in the Child SA proposal).
>>
>>   However, I'd honestly prefer if that was just the standardized
>>   behavior for the Child SA created with IKE_AUTH as we really don't
>>   know what KE methods the responder has in its Child SA proposal.
> 
> I would really like to avoid requiring the regular rekey method in the
> protocol. That way, some time in the far future, this could perhaps
> become the only rekey method used. If this draft has a requirement
> for the old method in it, we will never be able to get rid of the older
> one.

It already states in section 3:  "Non-optimized, regular rekey requests
MUST always be accepted."

So e.g. strongSwan always doing a regular rekeying for the first Child
SA as initiator is perfectly in line with the draft.  It's currently
just not described explicitly or the recommended or mandatory behavior.

Which could pose a problem as responder of an optimized rekeying of the
first Child SA.  It works fine in the single KE case if the method in
the KE payload is in the responder's Child SA proposal, but if not, or
if there are multiple key exchanges involved, there could be issues (see
below).

> Additionally, having a different KE for the initial Child that comes
> from the IKE KE and its Child SA rekey is already a questionable/bad
> configuration, since you are not rekeying the child under the same
> level of protection.

Not sure if that's necessarily true for the multi-KE/PQC use case.  One
might want to just protect the IKE SA with multiple big and costly key
exchanges and then only use a single, classic KE to create fresh keys
for the Child SAs (whose KE payloads are exchanged under the protection
of the quantum secure IKE SA).  That the first Child SA will have key
material derived from the "stronger" IKE keys is just an accidental
by-product of how IKEv2 is designed.

A different aspect of the multi-KE/PQC case is that only the IKE SA
requires a classic KE method (to avoid fragmentation during
IKE_SA_INIT), Child SAs could just be rekeyed/created using a single PQC
key exchange.  So the Child SA proposal might not contain the same
number of key exchanges or any classic KE methods but only PQC methods
that were used as additional KEs for the IKE_SA.

Another way to avoid that would be to make childless IKE SA creation
mandatory for implementations of this extension, so the first Child SA
would always have to be created with a separate CREATE_CHILD_SA
exchange.  But since the creation of a new Child SA is pretty much the
same as a classic rekeying, we could also just make the latter mandatory
for the first Child SA if it was created with IKE_AUTH and only rely on
stuff that's already specified in RFC 7296 ;)

> I dont mind doing extra work for those who want
> such questionable/bad configurations, but would not want to add it to
> proper/good configurations that do not need it.

So you're saying some configs, that are valid for regular IKEv2, will
just not work with this extension?  And we'll only know once there is
some kind of failure during the optimized rekeying?  Which can,
admittedly, already happen with regular IKEv2 with mismatched PFS
settings because we don't exchange KE methods during IKE_AUTH.  But then
at least we get a relatively clear NO_PROPOSAL_CHOSEN error immediately.
 In addition to that situation, which could occur here too (i.e.
initiator sends KE payload, responder has no KE methods in its Child SA
proposal and replies with NO_PROPOSAL_CHOSEN), we have multiple
additional ones:

 * Initiator sends a KE payload with a method that the responder has
   not in its Child SA proposal.  So it sends back an INVALID_KE_PAYLAOD
   notify (it doesn't really know what KE methods the initiator
   supports, so it has to guess the method it encodes in the notify from
   its own proposal and maybe the first KE method of the IKE_SA).  What
   is the initiator to do then?  Retry an optimized rekeying with the
   requested method (what if it's not in its proposal)?  Retry with a
   regular rekeying (preferring the requested method, but again it could
   be an unsupported method)?  Abort the rekeying?

 * Initiator has optional additional KE methods (i.e. with NONE) in its
   Child SA proposal while the responder does only have a single KE
   method configured.  Then the initiator might expect multiple key
   exchanges, because that's what the IKE proposal says and it follows
   the draft's SHOULD.  But the responder does not return an
   ADDITIONAL_KEY_EXCHANGE because it adheres to its Child SA proposal.
   What is the initiator to do then?

 * Same as above but reversed.  So the responder expects an additional
   key exchange but the initiator just follows its Child SA proposal and
   is happy with the completed single key exchange, ignores the
   ADDITIONAL_KEY_EXCHANGE notify in the response and does not initiate
   an IKE_FOLLOWUP_KE exchange.  The initiator ends up with a
   successfully rekeyed Child SA, while the responder waits and may only
   abort the incomplete rekeying after a timeout.  The initiator will
   also attempt to delete the old Child SA, which the responder might
   not be able to handle in its "waiting for IKE_FOLLOWUP_KE" state.

>>   So just blindly assuming the IKE's KE methods will be accepted seems
>>   risky (in particular if multiple key exchanges were involved in
>>   creating the IKE SA).  That IKE SA's first KE method can still be
>>   preferred in the Child SA rekeying request if it's in the initiator's
>>   proposal (i.e. use it for the KE payload and list it as first
>>   method in the SA payload).  But if there is a mismatch, it seems
>>   easier to recover during a regular rekeying than blindly trying the
>>   IKE KE method, receiving an INVALID_KE_PAYLOAD and then having to
>>   initiate a regular rekeying all over anyway (if that's even an
>>   option, the draft currently doesn't explicitly say).
> 
> I think a mismatch really means a bad configuration. You are allowing
> a single Child SA to have different KE level protections between REKEYs,
> which is definitely violating the spirit of rekey.

The only way to avoid that would be the extension either making
childless IKE SAs mandatory, or strictly prohibiting inconsistent KE
configs between IKE and Child SAs, taking away quite a bit of
flexibility IKEv2 offers.

>> * I'm still wondering why the critical bit has to be set for the
>>   OPTIMIZED_REKEY notify.  It's a regular Notify payload, so it MUST be
>>   understood by all IKEv2 implementations and setting the bit is
>>   basically redundant (the critical bit only concerns the payload type,
>>   not the contents such as the notify message type - it's also only
>>   allowed to be set in requests so making it an unconditional MUST like
>>   that violates RFC 7296 anyway).
> 
> This is a good point. It might be an argument for OPTIMIZED_REKEY not
> being a NOTIFY payload but its own new payload type. You are right that
> notify payloads cannot have the critical bit set. So if we keep this
> as notify that has to be removed. Although we will end up with a weird
> situation where we get a successfull IKE message exchange, but the
> rekey actually failed. Let's discuss at IETF-117.

Why would there be a problem with the OPTIMIZED_REKEY notify after
successfully exchanging OPTIMIZED_REKEY_SUPPORTED notifies in the
IKE_AUTH exchange?

Regards,
Tobias