(2014/11/29 4:21), Paul Wouters 🔓 wrote:
On Tue, 25 Nov 2014, Paul Hoffman wrote:
Greetings again. There is a small emerging industry of crypto
solutions that transmit keys using Quantum Key Distribution (QKD),
and then use those keys for classical high-speed encryption. Several
such solutions are using IKE, and there is a perceived need to
standardize this usage. If so, that standardization should be done in
this Working Group.
If you agree with the need to standardize this usage, and believe
that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good
starting place for that standardization, and are willing to review
and contribute text to the document if it is adopted by the WG,
please say so on the list. This WG has a history of adopting
documents but then not having enough reviewers for us to feel
confident that we are making a good standard, so we need to see a
reasonable number of actively interested people before we adopt the
document. If it is not adopted, the authors can ask for it to be
published as an RFC through individual submission or by the
Independent Submissions Editor.
I'm in favor of adopting this document as I can see a real use for this
in the future and since it is making changes to the IKE core protocol,
it would be best that this group is involved in that discussion.
Some comments after a quick read:
Why is the fallback field/mode negotiation required? Typically, those
decisions would be determined by local policy, and the remote end is
informed of that local policy by a new incoming IKE request (or not)
that uses a QKD payload or a DH payload. If the peers disagree about
the fallback method, would that prevent initial establishment of IKE?
Though I replied that fallback mode might be treated as local policy and
not to be
negotiated at the beginning of IKE, now I notice a difference between
fallback mode
and other local policies, if my understanding is correct. In current
IKE, after establishing
the first SA, the success of rekeying is guaranteed at the configuration
level; any
difference of local policies which are not shared do not prevent
rekeying the SA.
If fallback mode isn't negotiated, when the system fallbacks, if no
fallback method is
enabled in both peers, rekeying gets blocked until QKD succeeds to generate
new key. If fallback mode is negotiated at the beginning, the system may
know
whether rekeying in fallback mode be blocked as such or not. Then, this
can be
warned to users/system admins before fallback mode is needed to be
operated.
So, now I think that fallback mode should be negotiated at the beginning and
it should not prevent initial establishment of IKE but should be warned.
Why not leave the DH in place and just ignore the SKEYSEED / prf and
use the QKD bits for the private keys (or OTP)? It's less changes
to the IKE protocol (and friendlier to implementers :)
Having an OTP mode, even without QKD would actually be neat, although it
would require a lot of kernel work too :)
My first idea is just replacing QKD-generated bits with SKEYSEED. QKD is
often argued with OTP to achieve provably secure and I know that just
replacing QKD-generated bits with SKEYSEED can be used for OTP, however,
I would like to target only IKE in this project.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
