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