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

[Benjamin Kaduk <[e-mail]>]

Hi Tero,

On Fri, Nov 08, 2019 at 03:00:37AM +0200, Tero Kivinen wrote:
> Benjamin Kaduk writes:
> > Section 3
> > 
> >    N(USE_PPK) is a status notification payload with the type 16435; it
> >    has a protocol ID of 0, no SPI and no notification data associated
> >    with it.
> > 
> > [check the IANA status of the value]
> 
> As others already commented I as an IANA Expert for those registries
> did do an assignment for those notification values, as they were
> stable enough already in 2018 February...
> 
> Creating new registry could not be done as expert review, so that
> creation PPK_ID type registry was left to this document. Of course
> there was no problem with using the numbers, as there is nobody else
> who can allocate things from that registry as that registry does not
> yet exists. 
> 
> >       value.  Not all implementations are able to configure arbitrary
> >       octet strings; to improve the potential interoperability, it is
> >       recommended that, in the PPK_ID_FIXED case, both the PPK and the
> >       PPK_ID strings be limited to the base64 character set, namely the
> >       64 characters 0-9, A-Z, a-z, + and /.
> > 
> > I don't have much experience with the conventions in this space; does it
> > make sense to distinguish between the PPK representation as configured
> > (which would use the base64 alphabet) and the "actual PPK" that could be
> > binary after, e.g., a base64-decoding step?  I guess it could be
> > reasonable to rely on the ability of the PRF to take an arbitrary-length
> > input and just have sufficient entropy even while limiting the PPK value
> > to the base64 alphabet.
> 
> We had long discussion this in one of the meetings some time ago, and
> I think the problem is that some implementations use configuration
> files where they write the keys directly, some use config files
> pointing to the file on the disk, and some use some database backend,
> and then there are the ones that use GUI to enter the key.
> 
> When you have key "makemetastygoat" that is easy. When you have key
> which contains NULs, newlines, 8-bit characters etc., there are
> several cases where you cannot enter such key to configuration of
> implementation.
> 
> We decided that base64 is good enough, i.e., the keys do not get too
> much longer, but every single system should be able to configure key
> using that charset.
> 
> As the keys are feed in to the PRF anyways there is no need to require
> them to be binary, only thing that should matter is how much entropy
> there is in the key, and with base64 it is easy to calculate. 

That's roughly where I ended up after thinking about it, so I'm glad we're
all on the same page.  (And my apologies for having everyone spend more
words on it.)

> > Section 6
> > 
> > We should document the privacy considerations of the PPK_ID both in the
> > face of an attacker with a quantum computer (now or in the future) and
> > in the face of a classical attacker.  The latter would, IIUC, need to be
> > an active MITM in order to see anything other than N(USE_PPK), and who
> > would also get IDi along with the PPK_ID value, so there's not much of a
> > change in the privacy stance.
> 
> We did discuss this and decided that it would be possible to protect
> the identity (IDi, and IDr) using pseudonyms if such thing is needed.
> I.e., instead of using real IDi and IDr, we use some random identity
> string. After the IKE SA creation we can do IKE SA rekey to gain QR
> protection for the IKE SA traffic too, and after that we can agree on
> the next ID to be used for next connection. This way the identities
> will be always different and completely random.
> 
> The PPK_ID does not need to have meaning outside the fact that it
> identifies the PPK we are going to be using. So it can be random from
> the beginning, and you can either use similar agreeing on next PPK_IDs
> after rekey than for IDi/IDr, or you can simply use each PPK only once
> and generate lots of them before you even start.
> 
> None of this is written in the draft, as we kept the focus on making
> IKEv2 quantum resistant and keeping the original properties of the
> IKEv2 intact otherwise. Adding better identity protection is something
> that can be done separately and can also be used with or without QR.

Okay.

> > Section 7
> > 
> > We should have a registration template for what information new
> > registration requests should include.  (In particular, since we allow
> > changing entries, a "change controller" and contact information will be
> > needed.)  I suggest including a column for "reference to specification
> > (if available)", even though the "Expert Review" policy does not
> > strictly require one.  We could also provide some guidance to the DEs as
> > to what criteria they may or may not want to apply in deciding whether
> > to approve or reject a registration request.
> 
> As an IANA expert and most likely a candidate for expert for this
> registry too, I do not think such templates or rules for expert are
> needed. I hope people will trust experts enough to make smart
> decisions.

Okay, I'll put that down as "we considered providing guidance but decided
not to", which is fine.

> In this case I do not think there will be too many new registrations

Indeed, I cannot think of many possibilities there.

Thanks,

Ben