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]
