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]
