Hi Michael,
On 2/13/17 11:06 AM, Michael Richardson wrote:
Paul Wouters <[email protected]> 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
> created META-IKE.
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.
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
