While reading the draft-ietf-ipsecme-g-ikev2-04 draft I started to
thinking whether we should get rid of the GSA_AUTH completely?
We have several extensions or enhancements that change the way
IKE_SA_INIT and IKE_AUTH are done, and porting those changes to the
GSA_AUTH is going to require extra work, and looking how little
interest this draft has been receiving, I am wondering if we have
enough people to do that work. Those things include Intermediate
Exchange, Multiple Key Exchanges, Announcing Supported Authentication
Methods, EAP-Only Authentication (RFC5998), Signature Authentication
in IKEv2 (RFC7427), NULL authentication method (RFC7619), Mixing
Preshared keys for Post-Quantum security (RFC8784), etc..
My understanding is that we could simply remove the GSA_AUTH
completely, and say that g-ikev2 always uses normal IKE_SA_INIT, and
IKE_AUTH (with CHILDLESS_IKEV2_SUPPORTED from RFC6023) and then do
GSA_REGISTRATION as separate step. This would allow us to reuse all of
the extensions and enhancements we are working on for IKE_AUTH with
this g-ikev2 protocol for free, with cost of one extra round trip.
Another option is to rewrite section 1.4.1 in such way that it is
clear that GSA_AUTH and IKE_AUTH are identical except that GSA_AUTH
does not include payloads for creating Child SA for unicast traffic
(SA*, TS*), but do include payloads for group keying (IDg, SAg, N,
GSA, KD, D). If it is clear that GSA_AUTH and IKE_AUTH use exactly
same processing from the authentication point of view, all the work
above should work without changes.
The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is
more vague about it.
--
We should add following terms to the terminology section:
GM, GCKS, KEK, TEK, Rekey SA, Data-Security SA, LKH, GSA_a, GSA_e,
Group SA, registration SA,
and add bit more explansion what they are than just expanding the
acronym, i.e., explain that Rekey SA is equivalent of IKE SA of the
IKEv2, but over the multicast GSA_REKEY operations and is keyed by the
KEKs sent from the GCKS etc. The Rekey SA uses the current KEK that
provides the GSA_a and GSA_e used to protect GSA_REKEY.
(and I have no idea what is some of the SAs are supposed to mean)
--
In section 1.4.5.1. GSA_REKEY the text:
G-IKEv2 rekeying MUST NOT support IKE SA windowing.
is wrong, the implementations might support IKE SA windowing, but MUST
NOT use it...
--
I assume that in section 1.4.5.1. GSA_REKEY the text:
If implicit authentication is used, then AUTH_KEY MUST
NOT be sent to GMs.
is trying to say that AUTH_KEY MUST NOT be sent to the GMs using
GSA_REKEY, it was sent during the GSA_AUTH or GSA_REGISTRATION to each
member separately, and will not be changed during the lifetime of the
multicast flow.
--
In section 1.4.5.1.1 it says:
the content of the Encrypted payload is
encrypted and the ICV is computed using the current SKe/SKa keys.
which is confusing as SKe and SKa keys are never defined. The RFC7296
defines SK_a* and SK_e* keys, but those cannot be used for GSA_REKEY,
as GSA_REKEY is multicast message, and SK_a* and SK_e* from the
RFC7296 are generated per peer.
I assume those SKe and SKa are keys transmitted from the GCKS to GM
inside KD payloads or something.
On the other hand section 2.4 defines SK_e and SK_a, which are really
bad names, as they might get confused with RFC7296 SK_ei, SK_er,
SK_ai, and SK_ar. It we are supposed to use those SK_e and SK_a keys
here, then they needs to be renamed to something more distinct, like
GSK_e and GSK_a or something.
The sections 1.4.5.1.2 and 1.4.5.1.3 talk about the "new KEK", and the
"current KEK", i.e., it does not talk about SKa/SK_a/SKe/SK_e, so it
is not clear how those are supposed to match.
--
In section 1.4.5.1.3 there is text:
When a group member receives the Rekey Message from the GCKS it
decrypts the message using the current KEK, validates its
authenticity using the key retrieved in a previous G-IKEv2 exchange
if AUTH payload is present, verifies the Message ID, and processes
the GSA and KD payloads.
The text "if AUTH payload is present" in the middle is bit funny, I
would assume we need to validate the authenticaty of the message
regardless whether the AUTH payload is present by checking the ICV
value. When we check the ICV value we do know that the message is from
someone who knows the current KEK, i.e., at least someone in the
group, so that somewhat authenticates the message. Of course having
digital signature AUTH payload authenticates the message originating
from the GCKS. On the other having AUTH payload PSK does not provide
any new information over the ICV, anybody who knows the PSK (i.e.,
everybody in the group) and generate AUTH payloads using shared keys.
I would actually explictly forbid using shared key authentication in
the AUTH payload of the GSA_REKEY, and only allow digital signature
methods.
--
In section 1.4.6.1. text says:
5. When the SID-counter maintained by the GCKS reaches its final SID
value, no more SID values can be distributed. Before
distributing any new SID values, the GCKS MUST delete the Data-
Security SAs for the group, followed by creation of new Data-
Security SAs, and resetting the SID-counter to its initial
value.
but earlied in the section it said:
The group
member uses the same SID for each Data-Security SA specifying the use
of a counter-based mode of operation.
I.e., the deteing the Data-Security SA does not reset SID, as the
group member will simply use same sid for newly created Data-Security
SA. Yes, the newly created Data-Security SA does have different key,
and there will not be nonce overlap with the previously used
Data-Security SA, but the GCKS does not get any SIDs it can give out.
I think only way to reset SIDs is to remove all KEKs, i.e., forcing
everybody to do IKE_SA_INIT and GSA_AUTH/GSA_REGISTRATION again.
In bullet 6 this is explained but only by with SHOULD. I think the
text should be rewritten to say that GCKS MUST delete the Rekey SA to
force all members to register.
--
Section 1.4.6.2 should explictly mention that all SIDs are reset when
the Rekey SA is deleted. And also that deleting the IKE SA does NOT
remove SIDs, i.e., even when using GSA_INBAND_REKEY the GCKS need to
explictly delete Rekey SA using Delete payload having protocol ID of
GIKE_REKEY.
--
In section 1.4.5.3 the text talks about the SPI value equal to zero,
but I think it is trying to say that the SPI Size field is zero and
SPI field is empty.
--
In section 2.1.1 we could add note that if the RFC8784 is used then
the SK_d used is the one was already PRFed with PPK, thus the
generated SK_w will be quantum resistant.
--
Section 2.1.1. says that
SK_w = prf+(SK_d, "Key Wrap for G-IKEv2")
but then section 2.4 says:
SK_e | SK_a | SK_w = KEYMAT
I do not understand when section 2.4 is used? What is the KEYMAT in
that formula? Which SK_w is used for the GSA_AUTH or GSA_REGISTRATION
for encrypting keys with key wrap key of 0?
--
In section 3.4.2 the SPI size and SPI fields for the GIKE_REKEY is set
to include the IKEv2 SPIs? Why is this? In RFC7296 we usually use SPI
size of 0, and empty SPI when we are talking about the IKE SA, and I
would have assumed that GIKE_REKEY protocol number is identically
identifying the Rekey SA.
Ah, now I understand this is supposed to match the GSA_REKEY pseudo
exchange message SPIs. I think this text should be clarified about
this, and perhaps we need to add more text to the Rekey SA terminology
definition saying that where the IKE SPIs for that SA comes from.
Btw, can we have multiple GSA_REKEY pseudo exchange SAs? I.e., can
GCSK send multiple Group Security Association Policy substructures,
and send out multiple SPIs for those GSA_REKEY messages, so it can use
use different GSA_REKEY SPIs to send key updated to only some of the
SAs etc?
I.e., one of those could use the Digital signatures and another one
could use NULL authentication?
--
In section 3.4.2.1.1 I have no idea what is security difference
between the Shared Key Message Integrity Code and NULL authentication?
Both of them are using group keys that are distributed to everybody in
the group, so what is the security benefits from the Shared Key
Message Integrity Code?
--
I do not like the GAP format specified in the 3.4.3. Having the first
2 octes of zero overlapping the Protocol and SPI Size fields of the
normal substructures inside GSA is a hack, and I think it would be
better to simply allocate one protocol number for sending GAP. At
least change the figure 16 so that first 8-bits of the substructure is
Protocol, and that MUST be zero for the GAP, and next 8-bits are
reserved...
Same for the Member Key Packet Substructure in section 3.5.3...
--
In section 3.7.1 the described behavior is different than what is
defined in the RFC7296. RFC7296 sends USE_TRASPORT_MODE notification
with protocol number 0, spi size of zero, and without SPI field.
Section 3.10 of RFC7296 says:
Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS, REKEY_SA, and
CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be
sent as zero and MUST be ignored on receipt.
and as USE_TRASPORT_MODE is defined in the RFC7296 it uses this
method, and does not include SPI. I.e., sending multiple
USE_TRASPORT_MODE notifications as specified in the section 3.7.1 does
not work.
One way to fix this is to say that if GCKS wants to use both transport
mode and tunnel mode, it MUST use separate exchanges to do that, i.e,
first include one GSA_INBAND_REKEY / GSA_REKEY to send information
about tunnel mode SAs, and then do another GSA_INBAND_REKEY /
GSA_REKEY with USE_TRASPORT_MODE notification to send transport mode
SAs (and after doing the GSA_AUTH or GSA_REGISTRATION with tunnel or
transport mode, it needs to do extra GSA_INBAND_REKEY for other mode).
--
Section 4.1. is not correct. The SK_w used to encrypt the keys inside
the KD payloads is protected by PPK, as it is derived from the SK_d
which is protected, thus all keying material transported in the
initial IKE SA is protected. As such I think all of the section 4.1
can be removed, the mandatory or not example does not really belong to
this document, as my understanding is that this is default RFC8784
behavior.
--
Section 5.2.1 requires more text about the case where GSA_REKEY does
not use AUTH payload.
--
Section 5.2.2 should include the fact that if RFC8784 is used then the
SK_w depends on the PPK, and all keying material wrapped inside the
G-IKEv2 are encrypted with either that key, or key encrypted depending
on that key.
--
I do not really understand what section 5.2.3 is trying to say? The
normal GSA_AUTH is protected against the Man-in-the-middle by using
normal authentication either shared keys or signatures. The GSA_REKEY
is protected by the man in the middle by the fact that the keys used
in to encrypt and authenticate it are only known by the members of the
group. Note that group members do not have any need to be a man in the
middle, as they can generate GSA_REKEY unless digital signature AUTH
payloads are used.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
