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

[Tero Kivinen <[e-mail]>]

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. 

> 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.

> 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.

In this case I do not think there will be too many new registrations
to this registry and in many cases vendors might be using just private
use numbers for their internal cases. Some vendor might defined
something like PPK_ID_FILE_AND_INDEX where there is first 32-bit index
and then filename indicating which one time pad file is used and the
index tells you which key inside the file is used. To be able to
transmit that file from one device to another both ends needs to
understand the file format etc, and if that file format is proprietary
then there is no point of using standard PPK_ID type either. 
-- 
[e-mail]