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

[Tero Kivinen <[e-mail]>]

Bruckert, Leonie writes:
> Additionally, it would be nice to also protect the identities i.e.
> to make the AUTH exchange quantum resistant. Particularly with
> regard to the PPK draft which doesn’t assure this.

As we discussed earlier, some kind of pseudonym system might be better
for this, especially as it works also for traditional authentication
and Diffie-Hellman against active attacks (it does not work against
attackers who can break Diffie-Hellman for traditional DH).

I.e., in this case we do following exchange:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->
                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

   HDR, SK {IDi(ID_PSEUDONYM,PNi<n>),
       [CERT,] [CERTREQ,]
       AUTH, SAi2,
       TSi, TSr}  -->

                                <--  HDR, SK {IDr(ID_PSEUDONYM, PNr<m>),
                                         [CERT,] AUTH, 
                                         SAr2, TSi, TSr}


And after that we do pseudonym update exchange:

   HDR, SK {N(UPDATE_PSEUDONYM, PNi<n+1>)} ->

   	   			<-- HDR, SK {}

I.e., client will use completely random identity PNi<n> (for example
"SeDOELWhkvX03Xt1s9nh9g") and every time it suspects that identity
might have leaked (i.e., it gets authentication failure, or IKE_AUTH
times out, meaning there might have been active attacker on the link),
it will update the pseudonym to new one.

If we want to make it more complicated we could support multiple
pseudonyms for the client, i.e., make pseudonym update work as
follows:

   HDR, SK {N(CLEAR_PSEUDONUMS),
   	    N(ADD_PSEUDONYM, PNi<n+1>),
   	    N(ADD_PSEUDONYM, PNi<n+2>),
   	    N(ADD_PSEUDONYM, PNi<n+3>)} ->

   	   			<-- HDR, SK {}


And server will associate those new pseudonyms to the same client
until it does CLEAR_PSEUDONUMS again. 

> I’d like to draw the attention to another aspect associated to the
> NIST standardization efforts and the assignment of IDs for post
> quantum algorithms. At present people refuse to specify post quantum
> algorithms and assign IDs officially – and they’re justified in
> doing so, because these algorithms are not sufficiently analyzed. On
> the other hand we somehow need to address the PQ algorithms now. How
> can we break the vicious circle? Temporarily provide IDs and adjust
> them later? Or just let the user assign IDs individually in the
> range that is reserved for private use?  

It depends what IDs you need. Most of the IDs in the IKEv2 are expert
review, so you do not necessarely need any document to get one ID, but
as an expert, I will usually require some kind of stable reference.

On the other hand we do have interested people working on this in the
IPsecME WG, so I think we should just wait for that work to either
finish, or to die out because of lack of interest. 

> Just imagine, NIST standardizes a set of well-studied PQ algorithms
> at some day within the next 5 - 7 years. From that day forward there
> will be no need for a combined key exchange anymore and it should be
> possible to use PQ algorithms in IKEv2. But it’s likely that many
> implementations won’t be upgraded to perform a combined key exchange
> until then, so designing a post quantum IKEv2 while guaranteeing
> backwards compatibility to two former versions would be the new
> challenge.

Quite a lot of people are still using IKEv1, and IKEv2 RFC was
published 2005, and IKEv1 has been obsoleted since...

So it will take decade or two until people start updating their
implementations... :-(

> So I think we should modify IKEv2 in a way that not only offers a
> combined key exchange, but also allows the transition from combined
> modes to the solely use of PQ algorithms. I’m aware that this is a
> difficult task and might possibly not be solvable at all. However,
> the anticipated short period of use of a combined key exchange
> demands a fast solution. 

I think that is something we should aim for, and I do not think it is
impossible task to make. The tradeoffs are more in the case how badly
will broken old IKEv2 implementations break when we define that
extension... 

> I support Scott’s approach to dynamically assign unused IDs. I came
> up with a similar idea that makes use of (new) attributes but I
> think this one is simpler.  

I think that is hack and we should aim for more generic and cleaner
solution. Nobody will be adding support for the PQ algorithms without
heavily modifying the code, thus adding new exchanges or changing the
IKE_AUTH payloads is something we can do. We should try to keep
IKE_SA_INIT compatible as much as possible, and hopefully negotiate
the use of the new features there, so we can be backwards compatible
with old implementations.

I mean if we are going to transfer several tens of kilobytes or even
megabytes of keys inside IKE, adding one more round trip in that case
is no longer an issue... 

> As I understand the main drawback of introducing a new transform
> type and thus negotiating PQ algorithms in the SA payload is
> (besides compatibility issues) the fact that the key exchange is
> then limited to a combination of one classical method and one PQ
> method. Whereas Scott’s idea allows to combine multiple PQ
> algorithms.

Or we can just negotiate the traditional stuff in SA, and use notify
to tell that we support PQ, and if we do support PQ, we do the
intermediate exchange between IKE_SA_INIT and IKE_AUTH and exchange
our PQ stuff there, and do the negotiation of what kind of algorithms
we use there.

Making magic things with transform IDs might look like easy hack, but
usually that will just cause more issues in long run, and might
generate more code than making bigger, but cleaner change.
-- 
[e-mail]