Subject: Re: [IPsec] Quantum Resistant IKEv2

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Jan 2017 15:03:58 +0200

Michael Richardson writes:
> 
> Tero Kivinen <[email-masked]> wrote:
>     > That is why I think it is important that we do detect the failures
>     > correctly.
> 
>     >> > SK_d provides quantum resistance for the IPsec SAs and Child IKE
>     >> SAs.  > The SK_pi and SK_pr provides key verification, meaning that
>     >> incorrect > PPKs will result AUTHENTICATION_FAILURE notification,
>     >> instead of just > wrong keys.
>     >> 
>     >> Would it be reasonable to create some token/nonce from something
>     >> before the PPK is mixed in such that we could recognize the different
>     >> AUTH FAILUREs, or does that create too much of an oracle for testing
>     >> PPKs?
> 
>     > I think it is better to keep the AUTHENTICATION_FAILURE to mean both,
>     > i.e., not provide an oracle.
> 
> okay, but can we determine the mismatch enough to log it?

Depends how we do it. If we change the SK_pi and SK_pr keys, then no.
The key we use for MACedIDFor* is different, and output of that will
get to be part of *SignedOctets, thus when responder verifies the
signature or the MAC of with secret key it will simply get failure, so
there is no way of knowing whether it was PPK failure or whether it
was some other failure.

This also means there is no way of the attacker to use the timing to
find out whether it was PPK failure or other authentication failure,
making it safe...

If we do some other kind of verification for PPK (for example
calculate some separate hash that we send out), then most likely the
attacker will also know which kind of authentication failure it was...
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 10 Jan 2017 21:36:26 +0000

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: Thursday, December 29, 2016 11:51 AM
> To: Tero Kivinen
> Cc: Scott Fluhrer (sfluhrer); IETF IPsec
> Subject: Re: [IPsec] Quantum Resistant IKEv2
> 
> 
>     >> 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.
> 
>     > This has the issue that differences in the PPK will not be detected,
>     > i.e., if PPKs are mismatched because of configuration error, we do get
>     > IKEv2 SA up and running, and we create IPsec Child SAs without errors,
>     > but then all traffic in IPsec SA will simply be dropped as the keying
>     > material is wrong.
> 
> I think that this is a *HUGE* user configuration issue.
> It means that the QM resistance will be turned off first thing whenever there
> is a problem.
> 
>     > SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs.
>     > The SK_pi and SK_pr provides key verification, meaning that incorrect
>     > PPKs will result AUTHENTICATION_FAILURE notification, instead of just
>     > wrong keys.
> 
> Would it be reasonable to create some token/nonce from something before
> the PPK is mixed in such that we could recognize the different AUTH
> FAILUREs, or does that create too much of an oracle for testing PPKs?

I believe that would be reasonable.  We already exchange notifies between the two sides (to allow both sides to know whether or not we're using a PPK); the obvious mention would be if the notifies included PRF( PPK, "fixed value" ).

As for an Oracle, I don't believe that would present a problem; the general assumption is that PPKs have enough entropy to be completely unguessable (and if that's assumption is wrong, this doesn’t make it any worse).  In any case:
	- With the current protocol, an active attacker can already determine whether a guess of the PPK is correct (assuming they're the side that first receives an encrypted message after we stir in the PPK, it can obviously try different PPKs to see which one allows a plausible decryption).
	- With this protocol extension, a passive attacker could plausibly determine whether the connection failed due to a PPK mismatch or something else (presumably, the implementation will react differently due to the two error modes).  It's not at clear whether that leaks any interesting information; the only way that an attacker could induce a PPK mismatch on properly configured systems is by messing with the ID payloads (PPKs are selected based on the ID payloads), and one would hope such a modification would cause a failure earlier.

So, what does the WG think?  Would doing something like this (to allow both sides to determine a PPK mismatch vs. some other failure) be important?  Would the informational leakage be a concern?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Jan 2017 21:52:35 -0500 (EST)

> I believe that would be reasonable.  We already exchange notifies between the two sides (to allow both sides to know whether or not we're using a PPK); the obvious mention would be if the notifies…

I would prefer that we do not signal different AUTH failures in a way
that tells them which part of the AUTH process they got wrong.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Jan 2017 09:06:23 -0500

>> I believe that would be reasonable.  We already exchange notifies
    >> between the two sides (to allow both sides to know whether or not
    >> we're using a PPK); the obvious mention would be if the notifies
    >> included PRF( PPK, "fixed value" ).

    > that tells them which part of the AUTH process they got wrong.

The use of PRF(PPK,"X") does not place that signal on the wire, but permits
that signal to be in the log.

Scott: how do you think PPKs will get entered initially (i.e. until we have
some quantum-resistant mechanism to distribute them)?   Humans typing them
in, QR codes scanned, USB keys sent via Fedex?   If we are serious about
this, then it matters.

If Humans is the answer, then I would like to suggest the document suggest a
standard humen presentation format, such as bubble-babble [first hit:
http://www.wisegeek.com/what-is-bubble-babble.htm. Maybe there is a better
reference].

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Jan 2017 09:07:51 -0500

I found this:
  http://wiki.yak.net/589/Bubble_Babble_Encoding.txt

probably never progressed into the IETF?  Or maybe it's an RFC already :-)

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 09:50:14 +0300

Hi Tero,

as far as I understand, this proposal is not tied up with QR problem
and can be used independently. So I suggest not to mix it with
the proposed QR solution in one document.

Regards,
Valery.

> > Then what is the content of IDi and IDr in IKE_AUTH in this case?
> 
> As I said the IDi would be ID_KEY_D with value of
> \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the
> normal server side identity, as hiding server identity is usually not
> useful as server must have static IP so clients can know where to
> connect.
> 
> If server side identity protection is also needed, then server side
> IDr would also be similar pseudonym, but that would require server to
> keep track of which IDr was given to which client, and pick suitable
> IDr based on the IDi coming in.
> 
> > > ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from its
> > > table and finds a mapping from there to [email-masked]. From then on
> > > it uses [email-masked] as authenticated identifier, and verifies that
> > > the raw public key, or shared key used to authenticate the user
> > > actually matches the one configured to the [email-masked].
> > >
> > > Using certificates in this case would leak out the identity anyways,
> > > so they cannot be used, or at least transmitted over wire. Even if
> > > using raw public keys, the actual public keys must not be sent over
> > > wire, it needs to be taken from the configuration.
> > >
> > > > And the peers must also somehow prove their real identities, so AUTH
> > > > payloads must also be included, and we end up with something like
> > > > full IKE_AUTH exchange...
> > >
> > > This all is done in the server, i.e. instead of using the ID sent over
> > > the wire, the server uses the ID sent over wire as handle to the
> > > table, and fetches the real ID to be used for policy decisions and
> > > authentication from the that table.
> >
> > Again, what role the usual authentication (in IKE_AUTH) and
> > usual IKE Identities play in this scenario?
> 
> They would play their normal role, i.e. they would be used to
> authenticate the connection. The only difference is that the IDi on
> the wire would not be the real identity but the a random pseudonym,
> and that pseudonym is then used by the server to fetch the real
> identity which would then be used for policy purposes. To provide full
> identity protection, even the server should not use any long term
> identity like [email-masked], but instead just use some kind of user
> id and map that user id to the actual policy.
> 
> I.e., the lookup would go like follows:
> 
> IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54
> 
>   -> In server look that id from the known pseudonyms, find entry
>      saying:
> 
>      Pseudonym_ID = \x1c747c060d209a223d1f9f51b0351b54
>      User_ID = KeyId(\x1234)
> 
>   -> Use User_ID to search PAD for entry to verify authentication and
>      find the related SPD
> 
> Then when the user changes their pseudonym using the protocol defined
> later the first list of known pseudonyms would be updated to say:
> 
>      Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af
>      User_ID = KeyId(\x1234)
> 
> where the Pseudonym_ID is new random pseudonym to be used after that
> for future exchanges. The User_ID stays same, but it is just internal
> information inside the server, and is never transmitted over the wire.
> Of course the User_ID could also be RFC822([email-masked]) instead of
> that kind of random number, but then hacking in to the server could
> reveal the real user identities for the clients and their next
> pseudonyms, so that would be bad idea if full protection is needed.
> 
> Server does not really need to know who is in the other end, he just
> needs to know how the other end is going to authenticate himself
> (i.e., which PAD entry to use), and what kind of policy is allowed for
> that user (i.e., which SPD entries are used).
> --
> [email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 10:01:21 +0300

Hi again,

> I would propose that we add PPK to both SK_d and SK_pi and SK_pr.
> 
> SK_pi and SK_pr as used to MAC the ID payloads of the peers, and if we
> mix PPK in there that might also provide some resistance against
> quantum computers even when the attackers can break RSA. I.e., it does
> not matter that they can generate valid signatures if they do not know
> what they are supposed to sign.

That will work. However, I'm not sure that a single AUTHENTICATION_FAILURE
notification is a good thing from operational point of view. A separate 
notification indicated that PPKs are mismatched could be more preferred
to quickly trace back and fix configuration errors.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 10:44:10 +0300

Hi Scott,

> I believe that would be reasonable.  We already exchange notifies between the two sides (to allow both
> sides to know whether or not we're using a PPK); the obvious mention would be if the notifies included
> PRF( PPK, "fixed value" ).

That's similar to what I suggested in  https://www.ietf.org/mail-archive/web/ipsec/current/msg11058.html
(my proposal only used nonces instead of "fixed value" to decrease traceability of PPK, if it is ever important).

> As for an Oracle, I don't believe that would present a problem; the general assumption is that PPKs have
> enough entropy to be completely unguessable (and if that's assumption is wrong, this doesn’t make it any
> worse).  In any case:
> 	- With the current protocol, an active attacker can already determine whether a guess of the PPK is
> correct (assuming they're the side that first receives an encrypted message after we stir in the PPK, it can
> obviously try different PPKs to see which one allows a plausible decryption).
> 	- With this protocol extension, a passive attacker could plausibly determine whether the connection
> failed due to a PPK mismatch or something else (presumably, the implementation will react differently due
> to the two error modes).  It's not at clear whether that leaks any interesting information; the only way that
> an attacker could induce a PPK mismatch on properly configured systems is by messing with the ID
> payloads (PPKs are selected based on the ID payloads), and one would hope such a modification would
> cause a failure earlier.
> 
> So, what does the WG think?  Would doing something like this (to allow both sides to determine a PPK
> mismatch vs. some other failure) be important?  Would the informational leakage be a concern?

Yes, it is important. 

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 10:48:04 +0300

Hi Michael,

> http://www.wisegeek.com/what-is-bubble-babble.htm. Maybe there is a better

I think that the way PPKs are entered is out of scope of the protocol.
Some suggestions could be listed in the document for informational purposes.

Regards,
Valery.