Re: [IPsec] Comments to the g-ikev2

[Valery Smyslov <[e-mail]>]

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

OK.

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

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

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

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.

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

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.

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

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.

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

I tend to agree.

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

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

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.

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