Re: [IPsec] Comments to the g-ikev2

[Valery Smyslov <[e-mail]>]

Hi Tero,

many thanks for your review.

> 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.

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
> more vague about it.

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.

> --
> 
> 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,

Agree, will do.

> 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)

OK.

> --
> 
> 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...

Fixed.

> --
> 
> 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.

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.

> --
> 
> 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.

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

> I assume those SKe and SKa are keys transmitted from the GCKS to GM
> inside KD payloads or something.

Yes, see Section 2.3.

> 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.

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.

> 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.

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

> --
> 
> 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. 

Sure.

> 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. 

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
> 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.

Exactly.

> I would actually explictly forbid using shared key authentication in
> the AUTH payload of the GSA_REKEY, and only allow digital signature
> methods.

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.

> --
> 
> 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.

Good catch.

> 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.

I tend to agree.

> --
> 
> 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.

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.

> --
> 
> 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.

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.

> --
> 
> 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.

Will clarify.

> --
> 
> 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?

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.

> --
> 
> 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.

OK, will clarify.

> 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?

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.

> --
> 
> 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?

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.

> --
> 
> 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...

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.

> --
> 
> 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.

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).

> 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).

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.

> --
> 
> 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.

> --
> 
> Section 5.2.1 requires more text about the case where GSA_REKEY does
> not use AUTH payload.

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

> --
> 
> 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.

OK.

> --
> 
> 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.

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

Thank you again for the detailed review!

Regards,
Valery.

> --
> [e-mail]