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]
<mailto:[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]
<mailto:[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]
