Re: [IPsec] Comments to the g-ikev2

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > 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.

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. 

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

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

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.

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

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. 

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

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

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

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.

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

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

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

> 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.
-- 
[e-mail]