Hi Valery, Thanks for your confirmation. I believe using the same value in libreswan will be better for cross interoperability until IANA assigned one.
Best regards, Shubham On Wed, Mar 25, 2026 at 3:23 PM Valery Smyslov <[email protected]> wrote: > Hi Shubham, > > > > Hi Valery, > > > > I had 2 quick questions, I am hoping you could help clarify them too: > > > > 1) > > In Section 7.2 of the draft, > > > > The information of whether an implementation used the new > > authentication logic for old SA MUST be stored in the ticket and the > > implementation MUST act the same way when doing resumption. This > > means that in the IKE_SESSION_RESUME exchange peers do not send the > > IKE_SA_INIT_AUTH notification and do not expect it in the received > > messages. > > > > the notification is referred to as IKE_SA_INIT_AUTH, but earlier in the > document it is introduced as IKE_SA_INIT_FULL_TRANSCRIPT_AUTH. I assume > both actually refer to the same notification and this might be a minor > typo, but I wanted to confirm this, just to be sure. > > > > This is a typo. Thanks for catching it up. > > > > 2) > > Since an official IANA value hasn't been assigned for this notification > yet, could you suggest what temporary value (from the Unassigned or Private > Use ranges, ref: > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16), > one can currently use for testing? I'd like to use the exact same temporary > value in LibreSwan so I can easily perform cross-vendor interoperability > testing. > > > > Our implementation (ELVIS-PLUS) uses temporary value 50500. I > believe the same uses strongswan. > > > > Regards, > > Valery. > > > > Thanks, > > Shubham > > > > > > On Mon, Mar 23, 2026 at 7:51 PM Shubham Kumar <[email protected]> > wrote: > > Hi Valery, > > Got it. Thanks for clarification. > > Best, > Shubham > > > > On Mon, Mar 23, 2026 at 6:04 PM Valery Smyslov <[email protected]> > wrote: > > Hi Shubham, > > > > please see inline. > > > > Hi, > > > > Can anyone clarify this RFC draft ( > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/) > section 7.2, para 2 and 3: > > > > The information of whether an implementation used the new > > authentication logic for old SA MUST be stored in the ticket and the > > implementation MUST act the same way when doing resumption. This > > means that in the IKE_SESSION_RESUME exchange peers do not send the > > IKE_SA_INIT_AUTH notification and do not expect it in the received > > messages. > > > > If there is a chance that the state of this feature can be changed > > during SA inactivity (e.g., a host is upgraded or its configuration > > was changed), it is RECOMMENDED that the host do not use IKE SA > > resumption and does a full handshake instead. > > > > As per this draft, 2 peers establish an IKE SA with full transcript auth > and the auth payloads will be computed as: > > > > InitiatorSignedOctets = ZeroPrefix | RealMessage2 > > | RealMessage1 | NonceRData | MACedIDForI > > > > ResponderSignedOctets = ZeroPrefix | RealMessage1 > > | RealMessage2 | NonceIData | MACedIDForR > > > > This will authenticate both IKE_SA_INIT messages, which is the whole > point, proving nobody tampered with the algorithm negotiation. > > > > However, in case of session resumption, the IKE_AUTH code will see that > the initial IKE_SA_INIT uses the modified construction (auth over complete > transcript, from session ticket), reads the first packet which will now > hold the IKE_SESSION_RESUME messages, not the original IKE_SA_INIT messages > and end up authenticating the IKE_SESSION_RESUME messages instead of > original IKE_SA_INIT messages. So now, the auth payloads will be computed > as: > > > > InitiatorSignedOctets = ZeroPrefix | IKE_SESSION_RESUME_response > | IKE_SESSION_RESUME_request | NonceRData | > MACedIDForI > > ResponderSignedOctets = ZeroPrefix | IKE_SESSION_RESUME_request > | IKE_SESSION_RESUME_response | NonceIData | > MACedIDForR > > > > Correct. > > > > But the IKE_SESSION_RESUME messages doesn't contain any algorithm > negotiation, only ticket, nonce and cookie. There is nothing to "downgrade" > in the IKE_SESSION_RESUME exchange. > > > > Yes, no algorithm negotiation is performed during IKE session > resumption. > > However, negotiation of some features may still take place (e.g. > using separate transports > > for IKE and ESP or Child SA policy information). Perhaps this is > not a “downgrade”, > > but still it is possibility to change the behavior of the resumed > IKE SA. > > > > So, I wonder if is there a point in computing the auth over the complete > transcript in this case. And, I guess the author also sees this problem > and suggest to not use IKE SA resumption and does a full handshake instead. > > > > I agree that downgrade prevention has less value in session > resumption, but it costs nothing to add it there > > and it can still provide some additional defense. > > > > Regards, > > Valery. > > > > So, can anyone suggest what should be the exact behavior in session > resumption case with regard to this draft? > > > > Thanks in advance. > > > > With regards, > > Shubham > > > > > > > > > >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
