Subject: Re: [IPsec] Quantum Resistant IKEv2

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 13 Feb 2017 14:20:33 +0000

Ok, I held this informal poll, and here are the results:

-          For the first question ("how do we stir in the PPK"), there were no strong opinions; some people did express a preference for the third option (Valery's suggestion to modify only the initial SK_d).  I'll update the draft to reflect that.

-          For the second question ("how important is anonymity"), it would appear that the majority opinion is that this could be handled in a follow-up draft.

Michael Richards also suggested we attempt to address how to distribute the PPKs.  However, I would agree with Valery Smyslov; this is out of scope for this document; for example, the current IKE RFC allows preshared secrets, and does not address how to distribute them.

I'll be published an updated draft shortly; are there any other issues people feel need to be addressed?

From: IPsec [mailto:[email-masked]] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, December 06, 2016 4:32 PM
To: IPsecme WG ([email-masked])
Subject: [IPsec] Quantum Resistant IKEv2

In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) as work item.

During the discussion, two items were raised, and I would like to hear how the wider WG feels about these two items:

-          The first item is "how exactly do we stir in the preshared key (PPK) into the keying material".  By my count, three options were on the table:

o   There is the option listed in the draft, where we modify both the KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies that the IPsec SAs are generated with QR-resistant keying material, while stirring it into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other than the initial one) also has QR-resistant keying material.  This latter was done specifically so that an implementation can have protected IKE SAs (by negotiating a child SA immediately)

o   Dan Harkins suggested that we modify only the KEYMAT.  This is a simpler option, and will continue to protect the IPsec SAs; however this implies that any data protected by the IKE SA could potentially be recovered by a Quantum Computer.

o   Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial SK_d; as all keying material is generated based on that, this would also mean that IPsec SAs and any child IKE SAs are also protected.  This also means that an implementation would not need to remember the PPK after the initial negotiation.  The only downside I can see is that we would have to be a bit careful about when we update the SK_d (obviously, before we actually use it).
To me, all three strike me as reasonable ideas (unless we decide that we will need to protect the real identity data encrypted via the IKE SA; in that case, Dan's idea doesn't protect that).  Can I get opinions as to which strikes the group as the best?  Are there any fourth options that people would want to put on the table?

-          The second item is anonymity; some people were interested in preserving anonymity (however, not at the expense of excessive complexity).  One idea that was brought up was that the initial exchange would be done using pseudonyms (which would be sufficient for the responder to identity the PPK), and then once initial IKE SAs have been established (in a QR form), exchange the real identities.  My questions:

o   Would this idea of pseudonyms actually give any real identity protection?  Wouldn't that assume that several initiators use the same PPK (so they could use the same pseudonym)?  Is that the sort of thing we should be encouraging?

o   Should this be addressed in this draft, or could it be addressed in a follow-up draft?

o   If it would be addressed in a follow-up, would any hooks be required?  For example, would we want to introduce an opaque bit in a notify message to indicate this?

o   Would we be happy with always negotiating a child SA (as none of the three proposals for stirring in the PPK attempt to protect the initial IKE SA)?
My opinion is that this could be placed in a follow-up draft.

Thoughts???

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2017 10:56:22 -0500 (EST)

> Ok, I held this informal poll, and here are the results:

The IETF is about forming a consensus. Asking for an opinion is good,
but quantifying them should really be avoided as much as possibe.

So while I think it is a good thing that you are asking (polling) the
group with questions, I'm a little nervous when it appears that
decisions are made in the draft based on the count of responses,
especially seeing the turn out of responses is around 5 people.

> -          For the first question (“how do we stir in the PPK”), there were no strong opinions; some people did express a preference for
> the third option (Valery’s suggestion to modify only the initial SK_d).  I’ll update the draft to reflect that.

I'm not convinced there is consensus on this topic yet. I've seen good
arguments for different approaches.

> -          For the second question (“how important is anonymity”), it would appear that the majority opinion is that this could be handled
> in a follow-up draft.

That indeed seemed to be the case, and importantly also aligns with the
approach of the ID sending in the base IKEv2 document. And people
pointed out no protocol changes are needed for implementations to use
ephemeral IDs - as long we provide for that option as a NOTIFY in the
IKE_INIT exchange. So perhaps this does need to be specified in the
draft as an optional payload with value.

> Michael Richards also suggested we attempt to address how to distribute the PPKs.  However, I would agree with Valery Smyslov; this is out
> of scope for this document; for example, the current IKE RFC allows preshared secrets, and does not address how to distribute them.

I agree. If we address how to distribute PPK's we would have basically
created META-IKE.

> o   There is the option listed in the draft, where we modify both the KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies
> that the IPsec SAs are generated with QR-resistant keying material, while stirring it into the SKEYSEED implies that any child IKE SAs
> implies that any IKE SA (other than the initial one) also has QR-resistant keying material.  This latter was done specifically so that an
> implementation can have protected IKE SAs (by negotiating a child SA immediately)

[...]

> o   Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial SK_d; as all keying material is generated based on
> that, this would also mean that IPsec SAs and any child IKE SAs are also protected.  This also means that an implementation would not need
> to remember the PPK after the initial negotiation.  The only downside I can see is that we would have to be a bit careful about when we
> update the SK_d (obviously, before we actually use it).

This and the "optionally immediately perform a IKE rekey" could use more
discussion in my view.

> o   Should this be addressed in this draft, or could it be addressed in a follow-up draft?

[this] being ID protection, I do think that since IDs and PPK
identifiers are closely related, it belongs in this document.

> My opinion is that this could be placed in a follow-up draft.

I think this needs further discussion, as the optimal outcome would be
for the WG to agree on one approach and avoid another bell and whistle
to pick from.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Feb 2017 14:06:27 -0500

Paul Wouters <[email-masked]> wrote:
    >> Michael Richards also suggested we attempt to address how to
    >> distribute the PPKs.  However, I would agree with Valery Smyslov; this
    >> is out
    >> of scope for this document; for example, the current IKE RFC allows
    >> preshared secrets, and does not address how to distribute them.

    > I agree. If we address how to distribute PPK's we would have basically

I'm specifically asking that we agree on some simple things.
Like that they be written in hex, or bubble-babble, or base64, etc.
Simple stuff so that we can get a PPK from one machine (via sneaker-net) to
another machine without needing to write some perl to convert.

--

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dan Harkins <[email-masked]>
Date: Tue, 14 Feb 2017 17:06:47 -0800

Hi Michael,

> another machine without needing to write some perl to convert.
   Think of whom you're trying to protect against. The first to have a 
QC are
most likely nation-states that you really aren't too happy with today 
and will
most likely be less happy with in 20 years. If we have some specification on
using sneaker-net with hex or bubble-babble or base64, etc that's what's 
gonna
be deployed and it's gonna be the weakest link in this scheme. I dare 
say that
your sneaker-net would need to be protected by men with guns that you trust
implicitly driving armored cars to come close to the security you think 
you're
getting by mixing the PSK into the keying material.

   On top of that, I think it would be good to try and make sharing the PSK
as difficult as possible. If there are > 1 people running around with a 
group
PSK then successfully breaking into the computer of one of them will void
the security the I-D is providing for the entire group. If we make it easy
to share that will be the first thing that will be done. A sneaker-net
compatible flat file would encourage the laziest and least secure behavior.

   PKIX defined a symmetric key package and it has many options to securely
wrap an arbitrary symmetric key, or many symmetric keys in a package. It can
also include a key id to use when describing the symmetric key. We 
should look
at something like that. It's ASN.1 and everyone hates ASN.1 but an 
alternative
could be defined with JSON or something like that. The symmetric key package
can be deployed using the EST extensions that Sean Turner has proposed-- you
authenticate EST using a certificate, the EST server uses your authenticated
identity to locate your package and sends it to you. Yes it requires you to
implement a whole bunch of other stuff but I think it's worth the price 
we're
placing on the PSK.

   If you hate my idea then at least take this as an argument for declaring
the matter out of scope for the QC-resistant I-D and tackling it later.

   regards,

   Dan.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Feb 2017 11:56:04 -0500

Dan Harkins <[email-masked]> wrote:
    > QC are most likely nation-states that you really aren't too happy with
    > today and will most likely be less happy with in 20 years. If we have
    > some specification on using sneaker-net with hex or bubble-babble or
    > base64, etc that's what's gonna be deployed and it's gonna be the
    > weakest link in this scheme. I dare say that your sneaker-net would
    > need to be protected by men with guns that you trust implicitly driving
    > armored cars to come close to the security you think you're getting by
    > mixing the PSK into the keying material.

I don't think your model (protected by men with guns) is necessarily wrong.
I am imagining Brinks trucks myself, but we can also consider a staring role
for Keanu Reeves... or Agent 86, as you wish.

    >   On top of that, I think it would be good to try and make sharing the
    > PSK as difficult as possible. If there are > 1 people running around

Hmm. My concern is more along the lines of: getting this PSK entered
correctly is difficult, so when the boss is breathing down your neck, you
simply turn off the mechanism.

    >   PKIX defined a symmetric key package and it has many options to
    > securely wrap an arbitrary symmetric key, or many symmetric keys in a
    > package. It can also include a key id to use when describing the
    > symmetric key. We should look at something like that. It's ASN.1 and
    > everyone hates ASN.1 but an alternative could be defined with JSON or
    > something like that. The symmetric key package can be deployed using
    > the EST extensions that Sean Turner has proposed-- you authenticate EST
    > using a certificate, the EST server uses your authenticated identity to
    > locate your package and sends it to you. Yes it requires you to
    > we're placing on the PSK.

This sounds like a great idea.  I will even agree to eat the pre-established
ASN.1 here.  I had no preconceived notion as to the format, just that we have
a specific way to get the stuff in.

(I don't think, in a post-QM world, we can authenticate the EST with a
certificate though, but that's a detail. I think it's still an armored Brinks
truck with a thumb drive or whatever)