Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

[Tero Kivinen <[e-mail]>]

Cen Jung Tjhai writes:
>>And I think if the IKE_SA_INIT messages grow too large with QSKE,
>>then it’s better to develop generic fragmentation mechanism for
>>IKE_SA_INIT, rather than making it specific for fragmenting QSKE
>>blobs. Generic mechanism would allow to reuse it in case we’ll have
>>to include other large payloads in initial messages.
>
> Yes, while a generic mechanism would allow it to be reused, it
> sounds like a different draft all together. It could result in a
> very complex change in the protocol. Furthermore, we would like to
> support QSKE blob that is larger than 64KB in size, hence we
> fragment it in that way. 

Actually I think it would be better NOT to change IKE_SA_INIT at all,
but instead add new exchange between the IKE_SA_INIT and IKE_AUTH.

I.e., lets have following exchange:

Initiator                         Responder
   -------------------------------------------------------------------
   HDR(IKE_SA_INIT, MID=0), SAi1, KEi,
       Ni, N(IKEV2_FRAGMENTATION_SUPPORTED),
       N(PRE_AUTH_SUPPORTED)  -->

                                <--  HDR(IKE_SA_INIT, MID=0), SAr1, KEr, Nr,
				         N(IKEV2_FRAGMENTATION_SUPPORTED)
                                     	 N(PRE_AUTH_NEEDED), [CERTREQ]

   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=PLD1, Frag#=1, TotalFrags=m)
       {...} -->
   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=0, Frag#=2, TotalFrags=m)
       {...} -->
   ...
   HDR(PRE_AUTH, MID=1),
       SKF(NextPld=0, Frag#=m, TotalFrags=m)
       {...} -->

				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=PLD1, Frag#=1,
					    TotalFrags=m)
			                {...}
				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=0, Frag#=2,
					    TotalFrags=m)
			                {...}
                            ...
				<-- HDR(PRE_AUTH, MID=1),
				        SKF(NextPld=0, Frag#=m,
					    TotalFrags=m)
			                {...}

   HDR(IKE_AUTH, MID=2),
       SK {IDi, [CERT,] [CERTREQ,]
           [IDr,] AUTH, SAi2,
           TSi, TSr}  -->

                                <--  HDR(IKE_AUTH, MID=2),
				         SK {IDr, [CERT,] AUTH,
                                             SAr2, TSi, TSr}

I.e., we run normal IKE_SA_INIT with message ID of 0. It negotiates
the fragmentation (IKEV2_FRAGMENTATION_SUPPORTED), so all further
exchanges after IKE_SA_INIT can use fragmentation.

Then we do another exchange before the IKE_AUTH, i.e. we do PRE_AUTH
exchange before IKE_AUTH using message id 1 (or even message ids 2, 3,
4, etc, as many as are needed). This step does the large blob exchange
neede for the IKE_AUTH. As these are normal fragmented IKEv2 message,
i.e. there is request and there is reply. What goes in there is
most likely using some new payload number to transfer the QSKE data in
both directions.

Note, that IKEv2 messages are limited to 4GB in size, and one payload
inside IKEv2 message is limited to 64kB in size, so if larger than 64k
objects need to be transmitted, it can be transmitted using exactly
one IKEv2 message, having multiple payloads in it. On the other hand
as fragments are not individually acknowledged, we do not want to
transfer too big messages using it, so it might be better to allow
multiple PRE_AUTH message exchanges before moving to the IKE_AUTH.
This means that the PRE_AUTH exchange most likely needs to have some
way of telling the other end when it is done, and when to move to
IKE_AUTH.

IKE_AUTH then would be just normal IKE_AUTH.

The fact whether we need the PRE_AUTH exchange can be negotiated in
the IKE_SA_INIT, either using transform types in SA payload, or using
the notify payloads.

Also if we split data to less than 64k chunks anyways, it might also
be better not to use IKEv2 fragmentation, but instead just send
several PRE_AUTH exchanges instead.

Note, that the PRE_AUTH happening between IKE_SA_INIT and IKE_AUTH
would be encrypted, and MACed, but it WILL NOT be authenticated, i.e.,
we have not yet authenticated the other peer, and we will not include
those octets to the AUTH payload calculations, so they will not be
authenticated in AUTH phase, like the IKE_SA_INIT contents will be
authenticated.

I think this kind of step between IKE_SA_INIT and IKE_AUTH might be
easiest and most generic way of transferring the QSKE data. We will be
transferring large amount of data anyways, so trying to put it part of
IKE_SA_INIT is not useful, and trying to play around with cookies, and
IKE_SA_INIT modifications is just adding complexity. 
-- 
[e-mail]