Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

[Tobias Heider <[e-mail]>]

Hi,

little update on the nonces:
Stefan and I have been asking around the CFRG people what they think
about omitting
additional nonces and the consensus seems to be that this is not an easy
question
and that this could probably only be resolved doing formal verification.

Also we were strongly advised to get formal verification for the whole
protocol
including the INTERMEDIATE, and to seek help at CFRG at some point.

We're trying to bring people together who are interested in helping with
this,
If anyone has previous experience with formal verification of secure
network
protocols and wants to join, feel free to contact me.

Regards,
Tobias

On 3/27/19 6:29 PM, Tobias Heider wrote:
> Hi,
>
> we had a side meeting today where some of us shared our experiences
> implementing this
> draft and we had the chance to discuss the future of this draft with
> the authors.
> Here's what we have talked about and our results:
>
> #1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:
>
> The current draft proposes to send a pair of new nonces in every
> subsequent IKE_INTERMEDIATE exchange.
> We agreed that none of us sees any obvious security problems with only
> using the nonces exchanged in
> IKE_SA_INIT, but we should try to get this confirmed by cryptologists
> (maybe CFRG can help).
>
> #2 Using a single IKE_INTERMEDIATE to transport all additional keys
>
> One single big IKE_INTERMEDIATE message that transports all additional
> key exchanges would be enough to
> allow big keys to be fragmented. The main problem of this approach is
> that fragmentation handles lost
> fragments by resending all fragments. There is no way of requesting
> retransmission of a single fragment.
> This may turn out to be a problem, which is why each new key is sent
> in a separate IKE_INTERMEDIATE.
> Another solution might be to change fragmentation to allow
> retransmission of single fragments.
>
> #3 Using a reserved field to avoid 7 new transform types
>
> It was discussed whether it makes sense to use a reserved field in the
> transform substructure header
> to combine transforms of the same transform type (e.g. Diffie-Hellman
> group) with logical AND instead of OR.
> We agreed that the current solution is less work to implement and
> using the reserved field offers no
> functional benefit.
>
> #4 Big Keys (e.G. Classic McEliece)
>
> In general there was consensus that we should find a way to enable the
> use of McEliece keys.
> The problem is that McEliece keys are >1MB in size and thus can not
> fit into the KE payload
> (which has a 16 bit size field).
>
> The solution we came up with is fragmenting a single key over several
> KE payloads which are transmitted
> in a single IKE_INTERMEDIATE message that can be fragmented over
> several udp datagrams using
> IKEv2 fragmentation:
> HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} -->
> 	<-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)}
>
> This approach is only limited by the size field of the IKEv2 header,
> which is 32 bit.
>
> #5 Rekeying and CREATE_CHILD_SA
>
> Nonces should be handled as said in #1.
> The draft does not yet specify how the new SKEYSEED is generated.
> We agreed that the best way would be to do this in a single prf
> (different than in the INTERMEDIATE
> exchanges which are "rekeying" incrementally), e.G. :
>
>     SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr)
>
> The use of INFORMATIONAL exchange for the additional key exchanges was
> criticized.
> Several alternative designs were discussed, here's the most important
> ones:
>
> Design 1: Sending all in a single exchange:
>
> HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->
>     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4}
>
> Problems include that the initiator might generate keys that are then
> not accepted by the responder.
> Also the message would probably be very big, so the same problems as
> in #2 apply here.
> It was discussed what happens if the responder does not accept the
> proposal.
> As in normal IKEv2 the INVALID_KE notify can be sent by the responder
> and that CREATE_CHILD_SA
> has to be redone with the new knowledge of what the responder supports.
>
> Design 2: Single additional INFORMATIONAL
>
> HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
>     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)}
>
> HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->
>     <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4}
>
> Implementers might have problems with the complexity of using the
> (link1) cookie
> values as well as with the use of INFORMATIONAL for yet another thing.
>
> Feel free to correct us or comment if we made a mistake or missed
> something important!
> Thanks to everyone for joining the conversation!
>
> Regards,
> Tobias and Stefan
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec