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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    > 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 agree.  All of the DoS (cookie, etc.) defense and switch to TCP, and
detection of NAT-T, etc. is in the IKE_SA_INIT, and so doing any kind of
framentation in IKE_SA_INIT is a bad idea.

    > 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

Agreed.

    > 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 initiator will know when it is done, won't it? Can't it just move to
IKE_AUTH when it knows it is done?

Is the size of QSKE blob that the responder has to return to initiator likely
to be either unknown to the initator or very different than the
initiator->responder direction?

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

Agreed.  I think it needs to be a new transform type.

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

How big are the blobs?  Your text seems to imply they might very big.

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

Why couldn't we include those octets in the AUTH phase?

BTW, I don't like the name "PRE_AUTH", I think it should be something like
"AUTH_OBJECTS" or "AUTH_ARTIFACTS".

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

I agree strongly.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-