Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

[Valery Smyslov <[e-mail]>]

Hi Ben,

please see inline (I removed those parts of the message that seem to be resolved).

> > >    It is an open question whether or not it is feasible to build a
> > >    Quantum Computer (and if so, when one might be implemented), but if
> > >
> > > Feasibility of some quantum computer is becoming much less of an open
> > > question; perhaps we want some qualifiers about efficiency, scale,
> > > and/or general-purpose-nature.
> >
> > Do you have any data or pointers?
> 
> I'm mostly just thinking about press releases from D-WAVE and Google that
> get turned into articles in the technology press.  We see headlines about
> 60+ q-bit machines, that more likely than not are doing *something*.  So in
> my mind it becomes a question of whether what these machines (that exist and
> are being sold) are doing is useful for the problems relevant to a given
> technology, rather than whether a quantum computer exists.  (I'm not even
> sure that there's a generally accepted definition for what "quantum
> computer" means -- some people seem to use it for just annealing-based
> stuff.)

Probably, if we add a qualifier "full-scale Quantum Computer" then the text 
will become less questionable? Something like this:

     It is an open question whether or not it is feasible to build a large-scale Quantum Computer
      (and if so, when one might be implemented), but if it is, many of the cryptographic algorithms
      and protocols currently in use would be insecure.  

Or are you suggesting to rephrase the sentence completely? E.g.:

    Recent achievements in developing Quantum Computers (QC) demonstrate that 
    it is probably feasible to build a large scale QC. If such a QC is implemented,
    many of the cryptographic algorithms and protocols currently in use would be insecure.  

> > >    would be compromised.  IKEv1 [RFC2409], when used with strong
> > >    preshared keys, is not vulnerable to quantum attacks, because those
> > >    keys are one of the inputs to the key derivation function.  If the
> > >    preshared key has sufficient entropy and the PRF, encryption and
> > >    authentication transforms are postquantum secure, then the resulting
> > >    system is believed to be quantum resistant, that is, invulnerable to
> > >    an attacker with a Quantum Computer.
> > >
> > > Do we have a reference for this "it is believed", or is it just the
> > > outcome of the WG discussions?
> >
> > I'll let my co-authors comment on this, but I think it is meant
> > that according to our best current knowledge nothing
> > better than Grover's algorithm can be used to break symmetric
> > key cryptosystem with QC. And Grover's algorithm only
> > halves an effective key length, so if longer PSK is used, we're safe
> > (we believe we are).
> 
> To be clear: I share this belief! :)
> I am just asking if it is sufficiently well-known/widespread that no
> reference is needed; that may well be the case.

I believe it is, but I again prefer someone more knowledgeable in QC than myself to comment.

> > >    The general idea is that we add an additional secret that is shared
> > >    between the initiator and the responder; this secret is in addition
> > >    to the authentication method that is already provided within IKEv2.
> > >    We stir this secret into the SK_d value, which is used to generate
> > >    the key material (KEYMAT) and the SKEYSEED for the child SAs; this
> > >    secret provides quantum resistance to the IPsec SAs (and any child
> > >    IKE SAs).  We also stir the secret into the SK_pi, SK_pr values; this
> > >    allows both sides to detect a secret mismatch cleanly.
> > >
> > > With apologies for the pedanticism, let's be careful what wording we
> > > use, as just mixing into SK_d is not necessarily enough to get quantum
> > > resitsance for the parent IPsec SA.
> > > [need to check this some more]
> >
> > Well, there is no "parent IPsec SA" in IKEv2, all the IPsec SAs
> > are children of an IKE SA. They are created using SK_d as a key,
> > so if PPK is mixed into SK_d, then all Child IIPsec) SAs are protected.
> > Moreover, the SK_d is used when IKE SA is rekeyed as one of the inputs
> > for computation of new keys, so once IKE SA is rekeyed, the new
> > IKE SA will be QC-resistant too.
> 
> Oh, this is probably the key part of my confusion/misunderstanding with the
> terminology (which also shows up later on, IIRC).
> Namely, that the initial exchange generates an IKE SA, and the other SAs
> ("children" for ESP/AH usage) are called IPsec SAs (not IKE SAs).
> In that case this text is fine as-is and there's nothing to change, so
> sorry for the noise.

Almost true. The initial pair of exchanges (IKE_SA_INIT & IKE_AUTH)
generate an IKE SA and a single (to be exact - a single pair of) IPsec SA,
which in RFC7296 is called Child SA. This initial IKE SA can be used 
later to create as many additional IPsec (Child) SAs, as peers want (with 
CREATE_CHILD_SA exchange). At some point of time the initial IKE SA can be 
rekeyed (again with CREATE_CHILD_SA) and after this point is deleted.
The newly created IKE SA replaces it and is used for creating additional
IPsec (Child) SAs.

With QR draft all these SAs (both IKE SAs and Child SAs) except for
the initial IKE SA are protected with PPK. The initial IKE SA (those
created with IKE_SA_INIT and IKE_AUTH) doesn't have this protection.

> > > Section 2
> > >
> > >    We assume that each IKE peer has a list of Postquantum Preshared Keys
> > >    (PPK) along with their identifiers (PPK_ID), and any potential IKE
> > >    initiator has a selection of which PPK to use with any specific
> > >    responder.  In addition, implementations have a configurable flag
> > >
> > > nit: I'm not sure what "has a selection of" is intended to mean.  Is it
> > > more about making a choice of which PPK to use or about having a list to
> > > choose from?
> >
> > The former - making a choice of which PPK to use with any
> > specific responder. Do you think it should be rephrased?
> 
> I'd suggest "any potential IKE initiator selects which PPK to use with any
> specific responder".  (The other case involves the word "selection" in the
> sense of "this restaurant has a large selection of wines", but we want the
> verb form of "selection".)

OK, thanks.

> > >    If the responder did not include the USE_PPK notification and using a
> > >    PPK for this particular responder is optional, then the initiator
> > >    continues with the IKEv2 protocol as normal, without using PPKs.
> > >
> > > Do we want to say anything about logging or notifications for this case,
> > > in case someone is concerned about the level of quantum-resistance in
> > > use?
> >
> > Hmmm. I think that we follow RFC 7296 tradition that leaves
> > all logging (and the like) up to implementations...
> 
> If we do that, I'd suggest a little more exposition in the security
> considerations about how operational misconfiguration or similar could
> result in PPKs not being used, unless the "PPK is mandatory" knob is
> switched on.

OK.

> > >    That is, we use the standard IKEv2 key derivation process except that
> > >    the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again,
> > >    this time using the PPK as the key.  Using prf+ construction ensures
> > >
> > > Do we want to say anything about why only these three values need the
> > > PPK mixed in to them?  (I guess the idea is that the parent SA is
> > > "short-lived" on the timescale of a quantum computer and the messages
> > > protected directly by it are not of interest to an attacker years in the
> > > future.  This does mean that this scheme does not provide much value
> > > when a quantum computer is available at the time of the exchange,
> > > though, right?
> >
> > No, the reason is different. The PPK_ID is sent in the IKE_AUTH,
> > that is protected by the SK_ei/er/ai/ar keys. If these keys were
> > dependent on PPK, then in case of PPK mismatch the responder
> > would not be able to decrypt the message and thus cannot handle
> > this situation properly. We ran into this problem with IKEv1,
> > when PSK was stirred into key computation and in case of PSK mismatch
> > the responder received garbage, and wasn't able to recover gracefully.

I must correct myself here - one more (and even more important) reason
not to stir PPK into SK_ei/er keys is that the PPK identity is sent
in IKE_AUTH request that is encrypted using SK_ei. If we mix PPK
into it, then the responder must select the right PPK to decrypt the message
without knowing its ID, that it gets only after decryption. Chicken and eggs problem.

> > For this reason it was decided by the WG to only mix PPK into SK_d
> > and SK_pi/pr, leaving it out from SK_ei/er/ai/ar. This leaves
> > initial IKE SA not protected against QC, but allows the protocol to
> > handle PPK mismatch gracefully.
> 
> Ah, okay.  (I think this is discussed adequately later on in the document,
> so don't feel obligated to add any new text here if you don't want to.)

OK.

> > > Section 5.2.1
> > >
> > > I'm kind of confused by the PSKC reference, especially the implication
> > > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the
> > > PIN") that a fixed string is to be used as a PIN.  (I also think it's
> > > better to discuss what it does as "key transport" than "key exchange",
> > > noting that the latter string does not appear in RFC 6030.)
> >
> > I recall it was requested by somebody during discussion in the WG...
> 
> To be clear, unless someone can explain to me how I'm misunderstanding the
> current text (and thus that the current text makes sense), I object to the
> current description.  It doesn't give me a clear picture of what I'd need
> to do to use it, and what it seems to describe sounds insecure based on my
> preconceptions of the terminology used.  (I have no prior experience with
> PSKC, to be clear.)

I tend to agree with you here, but I hope someone in the WG who asked
for this text will chime in :-)

Thank you,
Valery.

> Thanks,
> 
> Ben