Hi,
before progressing G-IKEv2 draft further, we have to resolve an issue described
below.
Current spec defines a format for wrapped keys (Section 4.5.1) in such a way,
that
only confidentiality of the wrapped keys is achieved. The format deliberately
omits
the integrity protection of the wrapped keys, because they are inside G-IKEv2
message, which is authenticated and integrity protected. The only reason
to encrypt the keys inside G-IKEv2 message is to hide them from IKE protocol
level code (it may be less protected then crypto engine). On the other hand,
omitting the ICV from a key bag makes it smaller, so in case when multiple
keys need to be included into a single message (in situation member
is excluded from the group using LKH) there is less chance of fragmentation.
And to simplify implementation the algorithm used for wrapping keys is
the same as the algorithm for protecting G-IKEv2 messages.
In case this is an AEAD algorithm the specification currently
instructs to only use encryption part of the AEAD algorithm and
not the authentication part. It's easy to do for encryption
(just drop produced ICV), but harder to do on decryption -
you have to tell crypto library that you only want to decrypt
the blob using AEAD algorithm and you don't have ICV for this blob,
and you don't care about this.
The problem is that, as it turned out in mail exchange [1],
most (all?) current crypto libraries don't support this behavior.
In particular - they cannot perform decryption without also checking ICV
and in case the check fails the decryption process doesn't complete.
I can see two possible resolutions of the issue:
1) return back ICV to the wrapping format and continue to re-use
encryption transform for G_IKEv2 messages.
2) add a new registry "Key Wrapping Mechanisms", so that wrapping
format (and the way keys are secured) is determined by
entries from this registry (e.g. for AES keys it can use RFC 3394).
I slightly prefer option 1, because it seems to be simpler and
doesn't create yet another registry.
Regards,
Valery.
P.S. The issue is also documented at [2]
[1] https://mailarchive.ietf.org/arch/msg/ipsec/-UvEpBRlMeGih8hzXqVGvg5f-RA/
[2] https://github.com/smyslov/G-IKEv2/issues/18
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
