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