Subject: [IPsec] Comments to the g-ikev2

From: Tero Kivinen <[email-masked]>
Date: Tue, 11 Jan 2022 00:45:24 +0200

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.
-- 
[email-masked]

---

From: Valery Smyslov <[email-masked]>
Date: Fri, 14 Jan 2022 17:10:44 +0300

Hi Tero,

many thanks for your review.

> above should work without changes.

It is my understanding that G-IKEv2 should inherit all
extensions defined for IKEv2, so that GSA_AUTH and IKE_AUTH
are almost the same. In fact, in my implementation
they share a single code with small number of "if" statements
making them behave a bit different.

> The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is

We can make this more explicit by writing that 
GSA_AUTH is a variant of IKE_AUTH with different exchange type
and slightly different properties and that G-IKEv2 implicitly inherits
any extension defined in IKEv2 for use while IKE SA is being established
(this includes, for example using IKE_INTERMEDIATE) unless
an extension explicitly states the opposite.

I think eliminating GSA_AUTH completely is also an option, but 
in this case some indication of the purpose of the IKE SA being created
should be introduced, since there may be different policies 
at GCKS for IKEv2 and G-IKEv2 clients.

Agree, will do.

> (and I have no idea what is some of the SAs are supposed to mean)

OK.

Fixed.

No. If implicit authentication of GSA_REKEY messages is used, then 
they are authenticated by the fact that GMs verify their ICV.
Since we assume that only GCKS (and other GMs in the group)
knows the current SK_a, we implicitly authenticate it (no origin
authentication is provided as with any symmetric key authentication).
In this case no keys dedicated only for authentication 
(these keys are conveyed in the AUTH_KEY attribute during GM registration) 
are needed.

They were meant to be SK_e/SK_a (typo, fixed) and the way they are obtained
is defined in Section 2.4.

> inside KD payloads or something.

Yes, see Section 2.3.

> GSK_e and GSK_a or something.

I used these names so that they resemble SK_ei. SK_er and SK_ai, SK_ar
and removing trailing "i" and "r" should have made them distinct
from those. But I have no problem renaming them if they are still
too similar.

> is not clear how those are supposed to match.

Oh, these are left over from terminology used in previous versions of the draft.
They must be clarified.

Sure.

> When we check the ICV value we do know that the message is from
> group, so that somewhat authenticates the message. 

Yes, and this is called "implicit authentication" in the draft.
In case only implicit authentication is needed, AUTH payload may be omitted.

> Of course having

Exactly.

> the AUTH payload of the GSA_REKEY, and only allow digital signature

This idea is worth to think about. Implicit authentication
appeared only in recent version of the draft and explicit one
was left over not to break things. But you are right that 
there is no much value in using it. One possible reason is that 
in this case authentication key may be long lived and specifically generated 
with the desired security properties, while with implicit
authentication keys are usually auto-generated and 
are changed with every rekey. Don't know how much this matters.

system administers may have better control over the key used for authentication.
I mean that this key may be generated with some desired security properties,
that may differ from those of SK_a used for implicit authentication.

Good catch.

> force all members to register.

I tend to agree.

It is a bit complex than that. Note, that using Rekey SA (rekeying over multicast)
is optional. The GCKS may do rekeying over unicast SAs with each GM
(using GSA_INBAND_REKEY), in this case Rekey SA is not installed.
It is also possible not to rekey at all, so that data security SAs 
expires and GMs will re-register. 

But I agree that all these nuances should be clarified here.

No, it is not a typo, the text explicitly use zero SPI to indicate that all SAs
for the particular protocol are deleted. I agree that it is possible to change
the way to indicate this by sending zero-length SPI. This would
save few bytes, but the question is - how it is handled in the code?
In IKEv2 zero length SPI (along with zero protocol) is traditionally associated with IKE SA,
but here the protocol field will be non-zero. It seems to me that
semantically having zero SPI (and SPI length corresponding to the protocol)
looks more appropriate.

Will clarify.

I admit that text is not clear enough and I'll try to improve it.
Section 2.1.1 defines how SK_w is obtained in the unicast IKE SA,
when GM registers to the group. Section 2.4 defines how 
SK_e, SK_a , SK_w are obtained in the multicast Rekey SA
when GCKS rekeys this SA. 

So, when GM is first contacted GCKS, the unicast IKE SA is created.
For this SA SK_* are generated as defined in RFC 7296, the only key that 
is lacking is SK_w and it is calculated as defined in 2.1.1.
SK_w allows GM to unwrap keys sent over this unicast SA.
If GCKS is going to use multicast Rekey SA for rekeys, then among these keys will
be keys for this multicast SA, so that GM is able to decrypt, authenticate its messages
and unwrap new keys that will later be sent over it. The keys for multicast SA are sent
(initially over unicast SA and lately may be sent over multicast SA)
in the form of KEYMAT wrapped using the current SK_w.
So, initially (in unicast SA) they are wrapped with SK_w from 2.1.1.
The GM unwraps them and gets a new SK_w (and SK_a, SK_e) that it
will use when it receives new keys over multicast Rekey SA.
If multicast SA is rekeyed later, then GM will receive new
keys in the form defined in 2.4 and use them for the new multicast SA.

The things are a bit more complicated if LKH strategy is used.

OK, will clarify.

> could use NULL authentication?

Current draft doesn't allow this. It is assumed that only one Rekey SA exists
in every single period of time, but it can rekey itself over time in which
case it is replaced with a new one. I think this design was chosen 
for simplicity.

There is not much difference. The primary difference is that with
Shared Key Message Integrity Code the authentication key can be
specifically generated and be long lived, so that the authentication
key persisted between rekeys.

It use protocol 0, no need for fake protocol to allocate :-)
Yes, it's a bit of hack, but permissible in my opinion.
Zero always mean "all", so in this case it means "for all protocols".

I can change figures, no problem.

I know this, and this is where G-IKEv2 behaves differently from IKEv2
(note, that sending Delete Payload with protocol 0 is also not allowed
in IKEv2m but is used in G-IKEv2).

> transport mode, it needs to do extra GSA_INBAND_REKEY for other mode).

I think it complicates things more than redefining USE_TRANSPORT_MODE
for G-IKEv2 purposes. Alternatively we can allocate a new notify, say
USE_MCAST_TRANSPORT_MODE with a different semantics.

I think you are correct. This section was written before the way
keys are transported in the SA was completely redesigned and SK_w 
keys were introduced. Since then I didn't revise it and overlooked that 
the protection against QC is now achieved "for free". My bad.

I don't think the section should be removed, since some 
information is still visible to an attacker equipped with QC,
e.g. the parameters of the multicast SAs. The section
should be rewritten instead.

Agree. Again, implicit authentication was introduced only recently,
and this section was written long before.

OK.

I agree that the current text is very formal. Will try to elaborate.

Thank you again for the detailed review!

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 15 Jan 2022 19:24:33 +0200

> an extension explicitly states the opposite.

Now, after some time of thinking about this I think we should exactly
that, i.e., explain that GSA_AUTH is exactly same as IKE_AUTH except
it does not have payloads for creating IPsec unicast SA, but will add
payloads for creating multicast SAs.

I.e., add text to the 1.4.1 which explicitly says that. 

> at GCKS for IKEv2 and G-IKEv2 clients.

I think if we can share everything between IKE_AUTH and GSA_AUTH and
we are carefull with how we defined future extesions we should
probably keep the GSA_AUTH, as it does save one round trip... 

> (these keys are conveyed in the AUTH_KEY attribute during GM registration) 

Ok. The next question is we most likely want to make sure that one
Rekey SA can't update the AUTH_KEY for another rekey SA? I.e., the
SPIs inside the SA payload must match this Rekey SA if it contains
AUTH_KEY payloads to upda the authentication key of this rekey SA?

Or do we disallow multicast AUTH_KEY completely? We must not allow one
shared key rekey SA to update another rekey sa using public key
signatures, but we might want to allow GCKS to update its public key by
sending new AUTH_KEY for this rekey SA. Do we have some text somewhere
that explictly allows/forbids that.

I assume we disallow changing authentication method using GSA_REKEY,
i.e., there is no way for moving from implicit authentication (or
shared key authentication) to public key signatures? As there is no
origin authentication in implicit authentication or shared key
authentication we do not want to use them to update the rekey sa to
public key signatures.

> This idea is worth to think about. Implicit authentication appeared
> only in recent version of the draft and explicit one was left over
> not to break things. But you are right that there is no much value
> in using it. One possible reason is that in this case authentication
> key may be long lived and specifically generated with the desired
> security properties, while with implicit authentication keys are
> usually auto-generated and are changed with every rekey. Don't know
> how much this matters.

I would asume auto-generated keys are most likely much more secure
than shared keys used by the adminstrators.... 

> system administers may have better control over the key used for
> authentication. I mean that this key may be generated with some
> desired security properties, that may differ from those of SK_a used
> for implicit authentication.

There is already pairwise authentication key used in the GSA_AUTH,
and not sure if there is any reason to have another long lived
authentication shared key for specific SAs, explictly one that is
shared with lots of clients. 

> No, it is not a typo, the text explicitly use zero SPI to indicate
> that all SAs for the particular protocol are deleted. I agree that
> it is possible to change the way to indicate this by sending
> zero-length SPI. This would save few bytes, but the question is -
> how it is handled in the code? In IKEv2 zero length SPI (along with
> zero protocol) is traditionally associated with IKE SA, but here the
> protocol field will be non-zero. It seems to me that semantically
> having zero SPI (and SPI length corresponding to the protocol) looks
> more appropriate.

Ok. For special SPI value that indicates all possible SAs, I agree
that having some reserved SPI value (like zero), makes more sense. 

> case it is replaced with a new one. I think this design was chosen 

Ok. As I said there are so many different types of SAs there and I am
not really sure their relations to each other. Clarifying that in the
beginning in the terminology section may make things easier to
understand.

> USE_MCAST_TRANSPORT_MODE with a different semantics.

We need to point this out much more strongly, i.e., explain that
behavior is different from the RFC7296. Allocating new notify just for
that might be even better, as then we do no need to "Update" 7296... 

> should be rewritten instead.

Works for me.

> Thank you again for the detailed review!

I just want to get this document out also, and there does not seem to
be that many people interested in it, so I had to do my review of it
already now. Usually I do my full reviews only after WGLC while doing
shephard writeup, but moved it bit earlier now just to get things
going forward.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 17 Jan 2022 15:34:20 +0300

> > We can make this more explicit by writing that GSA_AUTH is a variant
> > of IKE_AUTH with different exchange type and slightly different
> > properties and that G-IKEv2 implicitly inherits any extension defined
> > in IKEv2 for use while IKE SA is being established (this includes, for
> > example using IKE_INTERMEDIATE) unless an extension explicitly states
> > the opposite.
> 
that, i.e.,
> explain that GSA_AUTH is exactly same as IKE_AUTH except it does not have
> payloads for creating IPsec unicast SA, but will add payloads for creating
> multicast SAs.

OK.

> > I think eliminating GSA_AUTH completely is also an option, but in this
> > case some indication of the purpose of the IKE SA being created should
> > be introduced, since there may be different policies at GCKS for IKEv2
> > and G-IKEv2 clients.
> 
> I think if we can share everything between IKE_AUTH and GSA_AUTH and we
> are carefull with how we defined future extesions we should probably keep
> the GSA_AUTH, as it does save one round trip...

OK, let's keep it and add more clarifications.

> > > 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.
> >
> > Since we assume that only GCKS (and other GMs in the group) knows the
> > current SK_a, we implicitly authenticate it (no origin authentication
> > is provided as with any symmetric key authentication).
> > In this case no keys dedicated only for authentication (these keys are
> > conveyed in the AUTH_KEY attribute during GM registration) are needed.
> 
> Ok. The next question is we most likely want to make sure that one Rekey
SA
> can't update the AUTH_KEY for another rekey SA? I.e., the SPIs inside the
SA
> payload must match this Rekey SA if it contains AUTH_KEY payloads to upda
> the authentication key of this rekey SA?

There is only one Rekey SA active at any given period of time.
There is no way to update AUTH_KEY in the current draft
(the text at the end of 1.4.5.1 contradicts to the text in 3.5.3 and is a
left-over 
from previous version of the document, but 3.5.3 is wrong too, since
Member Packet can be sent in multicast rekey...). So, the AUTH_KEY is kind
of 
constant. If GCKS wants to change it, all group SAs must be deleted
causing GMs to re-register.

If this is too restrictive, we can make this possible.

> shared key rekey SA to update another rekey sa using public key
signatures,
> but we might want to allow GCKS to update its public key by sending new
> AUTH_KEY for this rekey SA. Do we have some text somewhere that explictly
> allows/forbids that.

See above. 

> I assume we disallow changing authentication method using GSA_REKEY, i.e.,
> there is no way for moving from implicit authentication (or shared key
> authentication) to public key signatures? As there is no origin
authentication in
> implicit authentication or shared key authentication we do not want to use
> them to update the rekey sa to public key signatures.

Makes sense, but see above.

> > only in recent version of the draft and explicit one was left over not
> > to break things. But you are right that there is no much value in
> > using it. One possible reason is that in this case authentication key
> > may be long lived and specifically generated with the desired security
> > properties, while with implicit authentication keys are usually
> > auto-generated and are changed with every rekey. Don't know how much
> > this matters.
> 
> I would asume auto-generated keys are most likely much more secure than
> shared keys used by the adminstrators....

Shared key authentication with explicit key is mostly there
because I didn't want to break things after adding implicit authentication.
Since they provide mostly the same properties, I think we can 
get rid of one of them, unless someone disagrees.

> There is already pairwise authentication key used in the GSA_AUTH, and not
> sure if there is any reason to have another long lived authentication
shared
> key for specific SAs, explictly one that is shared with lots of clients.

I tend to agree.

> > > 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?
> > >
> > Current draft doesn't allow this. It is assumed that only one Rekey SA
> > exists in every single period of time, but it can rekey itself over
> > time in which case it is replaced with a new one. I think this design
> > was chosen for simplicity.
> 
> Ok. As I said there are so many different types of SAs there and I am not
really
> sure their relations to each other. Clarifying that in the beginning in
the
> terminology section may make things easier to understand.

Will do.

> > > 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).
> >
> We need to point this out much more strongly, i.e., explain that behavior
is
> different from the RFC7296. Allocating new notify just for that might be
even
> better, as then we do no need to "Update" 7296...

I don't think we need to update RFC7296 in any case, since this new
semantics 
would work only in the context of G-IKEv2. So, no update to existing
IKEv2 implementations is needed.

I don't have strong preference here. Allocating a new notify
is a possible alternative too.

> > > 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.
> >
> > I think you are correct. This section was written before the way keys
> > are transported in the SA was completely redesigned and SK_w keys were
> > introduced. Since then I didn't revise it and overlooked that the
> > protection against QC is now achieved "for free". My bad.
> >
> > I don't think the section should be removed, since some information is
> > still visible to an attacker equipped with QC, e.g. the parameters of
> > the multicast SAs. The section should be rewritten instead.
> 
> Works for me.

After some thinking and recollecting I realized, that things are not that
simple.
It's true that SK_w is derived in QC-resistant way, but it is only used
for providing confidentiality of the wrapped keys. Note, that their
authenticity and integrity is provided only on G-IKEv2 message level, 
so it is SK_a[i/r] that are responsible for these properties, and 
these keys are not QC-resistant. So, a QC-equipped attacker
cannot learn the keys, but can substitute them if they are
transferred in GSA_AUTH. 

The design choice was mostly driven by the desire to keep messages
small. It is not a problem for GSA_AUTH, but may be a problem for 
GIKE_REKEY in case LKH is used and the GCKS wants to exclude
a GM from the group. In this case the rekey message would contain keys 
for all other GMs. If the size of the group is about 2^n, then the
number of keys sent during excluding the GM is about n (if memory saves me).
Each Wrapped key structure contains 8 bytes header and IV in addition 
to the encypted key. If the key size is 256 bits and the IV size (AES-GCM)
is 126 bits, then we have 56 bytes per structure. Adding ICV
to this would increase the size by additional 12-16 bytes.
For million size group the size of the rekey message would be
close to 1500 bytes, causing IP fragmentation, that is not good.

We can work out this in some ways. For example, 
we can authenticate only KD payload with some key derived from SK_d...

Regards,
Valery.

> [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Jan 2022 17:49:00 +0200

> cannot learn the keys, but can substitute them if they are

True, but note, that this requires active attack with real time attack
against the IKEv2 Diffie-Hellman.

The main reason for PPK is to provide protection against the store and
attack later cases, i.e., where attackers store all traffic now, and
then later break the Diffie-Hellman and then can see the traffic keys
and then will be able to decrypt the traffic protected by those keys.

I.e. PPK is not properly trying to protect against the cases where
there is real time quantum computers, for that we most likely need to
have quantum safe key exchange, and authentication algorithms too,
i.e., multiple-ke and ikev2 intermediate...

I think we can simply document this to the security considerations
section saying that if that kind of protection against real time
attacks is needed then quantum safe key exchange is needed, and most
likely also quantum safe authentication algorithms...
-- 
[email-masked]