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

[Michael Richardson <[e-mail]>]

Daniel Van Geest <[e-mail]> wrote:
    > transform *attributes*, but not about transforms). My point here is
    > that if a responder may chose any of the proposed transforms then for
    > the first proposal to be QS it must not contain any quantum-insecure
    > transforms, or the responder must be modified to understand which
    > ENCR/PRF transforms are QS and to pick them when creating a QS
    > connection (and to fail if no QS algorithms are proposed).

I don't see this an issue.  Perhaps it needs to be well explained, but
generally in IKEv2 we use (UI) suites to configure things.

    > Then if an
    > initiator wants to create QS SAs, but also wants to interoperate with
    > (very?) old responders who don’t support AES-256 or PRF_HMAC_SHA2_384+
    > then they will need a second non-QS proposal in their SA list.

Sure, that's exactly what they will do during the transition time (which may
be a few years... some entities stupidly refuse to even patch systems, preferring to
just replace them with new hardware every three years.)
They will propose a set of things that is compatible to the future and to the
past, and over time the old stuff gets removed from the policy.

    > I don’t find the re-use of transform 4 in this proposal, and the
    > implicit combination of QS + non-QS algorithms, to be the most elegant,
    > though I can understand it in the context of not wanting to add a new
    > transform type.

So you are suggesting that the QR mechanism be a new transform type then?
I could live with that actually since it make the combinatorics easier to manage.

    > The idea is to add the new transform type 6 (Q-S-Group) like CJ’s
    > proposal, but don’t include it in the SA payload. Rather, introduce a
    > new QS_SA payload which would be identical in structure to the SA
    > payload except that it would also include the Q-S-Group transform
    > type. An endpoint could configure the proposals in this payload to

I don't think we need to do this.
I think that unknown transform types will be ignored by compliant
implementations.

    > Something to keep in mind is that many QS key agreement algorithms
    > don’t have exactly the same message flow as Diffie Hellman. With DH,
    > each endpoint’s public/private keys can be generated independently of
    > each other. But many QS algorithms have an initiator-responder flow, so
    > the responder can only generate its public key once it has processed
    > the initiator’s public key. We just need to keep this in mind when
    > designing the flow of the PRE_AUTH messages. An initiator can’t send
    > the first chunk of a public key, and the responder reply with the first
    > chunk of their public key, the responder would need to process all
    > initiator chunks for that key first. This means the initiator would
    > have to send a special acknowledgement response for chunks that don’t
    > complete a public key rather than responding with a partial key when
    > receiving a partial key.

Would the initiator know how much data to expect from the responder?
If so, the initiator can just keep sending query messages to get new blocks
of data back.

    > Also note that StrongSwan’s code assumes that IKE_AUTH will always have
    > a message ID of 1, but this won’t hold if there are one or more

That's a bug, we both agree.

    > 4) That was long

:-)

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