Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-04.txt is now available. It is
a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the
IETF.
Title: Mixing Preshared Keys in the IKE_INTERMEDIATE and in the
CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
Au
Hi,
it was pointed out to me in a private conversation that the way the PPK
Confirmation field is computed in IKE_INTERMEDIATE
is not appropriate for CREATE_CHILD_SA, since Nir is not yet known. The -04
version addresses this issue
by omitting Nr from the calculation for this situation. It also
Hi Wei,
Please ignore the previous response. Section 8 of the SKIP draft should read
as follows:
This document updates the use of the USE_PPK (16435) notify
message as defined in [RFC8784] to include the localSystemID of the
Key Provider as notification data,
Will update this in the ne
Valery Smyslov writes:
> > I did understand that, but I do not see point of sending extra 8-octets as
> the first 8-
> > octets already identifies the IKE SA...
>
> The point is that we want to re-use IKEv2 header, which contains two
> IKE SPIs.
Sure, but this does not have anything to do with th
Scott Fluhrer \(sfluhrer\) writes:
> I (and I don’t believe I am alone in this) would like to see an
> ML-KEM RFC for IKE; how can we make it happen?
>
> From what I see, the next step (now that the authors have updated it
> to specify the final version of ML-KEM) would be having it adopted
> by t
This protocol is confusingly named for IPsec types.
I thought that it was Cisco bringing the old Sun SKIP mechanism back to life.
Maybe it is. If so I'm really unclear from browsing the document.
If it is not doing that (and I see all sorts of HTTPAPI stuff), then maybe
someone has a better TLA
