Hi John,
thank you for your comments, please see inline.
Hi Valery,
Some quick commments.
- If the G-IKEv2 engine is not trusted to access information inside the
messages,
it should probably not be trusted to modify the keys. Chaning the keys would
get however is in control of the G-IKEv2 engine access to information
encrypted with the keys. (The G-IKEv2 can force key reuse as Natanael writes).
G-IKEv2 engine is trusted to the extent that it will not
voluntarily do any bad thing.
There are basically two reasons to not expose keys in clear to the
G-IKEv2 engine.
First, despite the fact that we trust it, generally the engine may
be more vulnerable
to some side-channel attacks compared to crypto engine. For example,
its memory may not be as protected as crypto engine's memory,
there may be some electromagnetic emission issues, not existent
in crypto engine which may be a specially designed HSM, and the like.
Second, usually all the keys reside in crypto engine and never
leave it in clear, only in wrapped (encrypted) form
(I think that most crypto API don't even allow to export keys in
clear, but I may be wrong).
So, you can imagine the situation that we have two crypto engines -
one on a Group Controller and the other on a Group Member and
we want to transfer a key from the former to the latter.
In this situation we usually wrap the key, transfer it (even via a
protected channel)
and unwrap on receiver. The idea was to use IKEv2 encryption
transforms
(which in many cases are in fact AEAD transforms these days) to also
wrap/unwrap the keys, but since we know that the channel is
protected,
only use an encryption/decryption service of these transforms.
Maybe sending two UDP datagrams is the solution? Or sending less keys and use
a KDF to derive some of the keys?
Sending multiple UDP datagrams is possible, but would complicate
the protocol.
Currently it is assumed that rekey is done with a single UDP
datagram.
Using KDF looks less desirable, it is assumed that all keys are
independent
and there is no correlation between them.
- I don't think "pure encryption algorithms" is a good term. Authenticated
encryption is "pure encryption" for IND-CCA confidentiality. I.e.,
confidentiality
against active attackers.
It was an "ad hoc" term, I'm sure it is far from perfect.
- I think is it very good to have a discussion on IND-CPA encryption and APIs
for that.
While AEAD has a standardized interface C = E(K, N, P, A) in RFC 5116, IND-CPA
encryption do not. The lack of IND-CPA encryption without message expansion and
the lack of a common API are problems. We discussed this in a paper we just
submitted to the NIST LWC workshop.
https://github.com/emanjon/Publications/blob/main/Proposals%20for%20Standardization%20of%20the%20Ascon%20Family.pdf
The DTLS 1.3 and QUIC specifications use AES-ECB which is secure in their case
as the plaintext is a single block, but
I have met people believing that AES-ECB is now ok in general as DTLS and QUIC
use it. It would have been easier if each AEAD algorithm had an IND-CPA mode.
But people using IND-CPA when they should not are also a big problem…
I understand.
How should a general interface for IND-CPA look like? Should it be
C = E(K, N, P)
or should it be a special case of the AEAD interface with a zero length tag and
A = ""?
C = E(K, N, P, "")
Or with a NULL (if we map this to C++)?
C = E(K, N, P, NULL)
Regards,
Valery.
Cheers,
John
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
