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