[IPsec] Re: draft-ietf-ipsecme-ikev2-qr-alt-04 review
Hi Panos,
thank you for your revew.
Hi Valery,
I reviewed draft-ietf-ipsecme-ikev2-qr-alt-04 of the draft and below is some
feedback:
One comment is that I prefer
SKEYSEED' = prf+ (PPK, SK_d)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
over
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
where SK(n)=PPK
I can't think of a way to exploit it, but the PPK could be a secret that did
not come from a key exchange, so it may be distinguishable from random.
Stirring the PPK in SKEYSEED matches the spirit for RFC8784 and does not
need the RFC9370 implementation to have access to the PPK. All secrets in
RFC9370 come from a key agreement, not from a static config.
More importantly, SKEYSEED' = prf+ (PPK, SK_d) matches a Key Based KDF as
per SP800-108 where K is the PPK and SKd_is the input to the PRF plus the
counter. So, it aligns well for key based key derivation in counter mode as
specified in SP 800-108. I would suggest to introduce some context unique to
the exchange, maybe Ni | Nr or the SPIs but that is not mandatory.
Nits / suggestions:
- s/storing VPN communications today and decrypting it later/storing VPN
communications today and decrypting them later/
- s/before the IKE SA is expired/before the IKE SA expires/
- s/and for rekeys operations/and for rekey operations/
- s/modifications to core IKEv2 protocol, that contradicted to one of the
goals to minimize such changes/modifications to core IKEv2 protocol. The
goal was to minimize such changes./
I changed to "One of the goals was." (I presume there were several
goals, no?)
- s/(and [I-D.ietf-ipsecme-g-ikev2] specifies how to do this)/ (as specified
in [I-D.ietf-ipsecme-g-ikev2])/
Oops. This para is a bit out-of-date, since it was written before
key wrapping was added to G-IKEv2. I updated the whole para to match the
current situation:
However, in some situations it is desirable to have this protection
for IKE SA from the very beginning, when an initial IKE SA is
created. An example of such situation is Group Key Management
protocol using IKEv2, defined in [I-D.ietf-ipsecme-g-ikev2]. In this
protocol group policy and session keys are transferred from Group
Controller/Key Server (GCKS) to Group Members (GM) immediately once
an initial IKE SA is created. While session keys are additionally
protected with a key derived from SK_d (and thus are immune to
quantum computers if PPKs [RFC8784] are employed), the other
sensitive data, including group policy, is not.
- s/Another issue with use of PPKs/Another issue with using PPKs/
- s/MUST ignore any data/MUST ignore any data in the notification/
- s/negotiation of using PPKs in the IKE_AUTH exchange/optional PPK
negotiation in the IKE_AUTH exchange/
Hmm. I believe the proposed change is wrong. It sounds to me that
the negotiation takes place in IKE_AUTH,
while the original meaning was that we negotiate use of PPKs in
IKE_AUTH (the negotiation still takes place in IKE_SA_INIT).
If the current text is confusing, then perhaps:
- s/negotiation of using PPKs in the IKE_AUTH exchange/ negotiation of using
PPKs as specified in [RFC8784]/
- s/ both use PPKS in IKE_AUTH [RFC8784] and use PPKS in IKE_INTERMEDIATE
MAY include both the USE_PPK_INT (along with the
INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it is
configured to use either specification / both the use of PPKs in IKE_AUTH
[RFC8784] and in IKE_INTERMEDIATE MAY include both the USE_PPK_INT and the
USE_PPK notifications if configured to do so./
- s/ specifications have to choose one to use/ specifications has to choose
one to use/
- I would not repeat the PPK_IDENTITY_KEY notification in Figure 1. I would
just reference it from RFC8784 and briefly mention the two fields it
includes.
This notification is introduced in this draft, RFC8784 used the
PPK_IDENTITY notification (w/o confirmation), which is also used in this
draft.
I think that it is better to keep the full specification for the
new notification.
- The combinations of optional or mandatory PPK at the end of section 3.1
would be summarized with a table like Table 1 in RFC8784. The would be more
clear for implementers like that.
OK, I see your point. I'll think a bit more how to proceed better
with this.
Thank you, I made all the changes in my local copy (waiting for
more reviews).
Regards,
Valery.
Rgs,
Panos
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] draft-ietf-ipsecme-ikev2-qr-alt-04 review
Hi Valery,
I reviewed draft-ietf-ipsecme-ikev2-qr-alt-04 of the draft and below is some
feedback:
One comment is that I prefer
SKEYSEED' = prf+ (PPK, SK_d)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
over
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
where SK(n)=PPK
I can't think of a way to exploit it, but the PPK could be a secret that did
not come from a key exchange, so it may be distinguishable from random.
Stirring the PPK in SKEYSEED matches the spirit for RFC8784 and does not need
the RFC9370 implementation to have access to the PPK. All secrets in RFC9370
come from a key agreement, not from a static config.
More importantly, SKEYSEED' = prf+ (PPK, SK_d) matches a Key Based KDF as per
SP800-108 where K is the PPK and SKd_is the input to the PRF plus the counter.
So, it aligns well for key based key derivation in counter mode as specified in
SP 800-108. I would suggest to introduce some context unique to the exchange,
maybe Ni | Nr or the SPIs but that is not mandatory.
Nits / suggestions:
- s/storing VPN communications today and decrypting it later/storing VPN
communications today and decrypting them later/
- s/before the IKE SA is expired/before the IKE SA expires/
- s/and for rekeys operations/and for rekey operations/
- s/modifications to core IKEv2 protocol, that contradicted to one of the goals
to minimize such changes/modifications to core IKEv2 protocol. The goal was to
minimize such changes./
- s/(and [I-D.ietf-ipsecme-g-ikev2] specifies how to do this)/ (as specified in
[I-D.ietf-ipsecme-g-ikev2])/
- s/Another issue with use of PPKs/Another issue with using PPKs/
- s/MUST ignore any data/MUST ignore any data in the notification/
- s/negotiation of using PPKs in the IKE_AUTH exchange/optional PPK negotiation
in the IKE_AUTH exchange/
- s/ both use PPKS in IKE_AUTH [RFC8784] and use PPKS in IKE_INTERMEDIATE MAY
include both the USE_PPK_INT (along with the INTERMEDIATE_EXCHANGE_SUPPORTED)
and the USE_PPK notifications if it is configured to use either specification /
both the use of PPKs in IKE_AUTH [RFC8784] and in IKE_INTERMEDIATE MAY include
both the USE_PPK_INT and the USE_PPK notifications if configured to do so./
- s/ specifications have to choose one to use/ specifications has to choose one
to use/
- I would not repeat the PPK_IDENTITY_KEY notification in Figure 1. I would
just reference it from RFC8784 and briefly mention the two fields it includes.
- The combinations of optional or mandatory PPK at the end of section 3.1 would
be summarized with a table like Table 1 in RFC8784. The would be more clear for
implementers like that.
Rgs,
Panos
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
[IPsec] Re: I-D Action: draft-pan-ipsecme-anti-replay-notification-00.txt
Hi John, Thanks very much for pointing out the requirements defined in 3GPP. Firstly, I must highlight that in this draft we certainly don’t and won’t suggest any requirements of whether to enable or disable the anti-replay protection. For this document, what we are considering is how to handle the frequent IPsec rekey issue when the anti-replay protection is disabled. If the anti-replay function is enabled, the frequent IPsec SA rekey can be avoided by using ESN, therefore, it’s not in the scope of our document. Hence, I don’t see any actual conflict between us. I apologize if my presentation was misleading to you that we suggest disabling the anti-replay function for 3GPP networks. Secondly, regarding the current anti-replay window mechanism, I have to say it is not so friendly to the high-traffic-volume scenario and hardware-implemented IPsec. And, from what I heard, many operators currently have to choose to disable the anti-replay function, otherwise, they’ll face a large amount of packets dropped due to disorder and a significant performance reduction. I’m not sure what mobile network operators choose, and I’ll need more time to check for this. I also wonder how they handle the anti-replay issue while the traffic rate is higher and higher along with the evolution to 5G and more. Lastly, my ultimate goal is not to weaken IPsec but to make it more suitable for high-traffic-volume scenarios, maybe we need to find a new anti-replay protection mechanism that is friendly to the high-traffic-volume scenario, or maybe there is such a way but I am just not aware of it. Regards & Thanks！ Wei PAN (潘伟) From: John Mattsson Sent: Friday, November 8, 2024 3:56 PM To: Panwei (William) ; ipsec@ietf.org Subject: Re: Re: [IPsec] I-D Action: draft-pan-ipsecme-anti-replay-notification-00.txt Hi, I was extremely suprised that this draft claimed to have anything to do with mobile networks. 3GPP specifications has _always_ mandated replay protection for all 3GPP uses of IPsec, without exceptions. This has been a very clear choice by 3GPP. I have been actively (as a delegate or backoffice) taking part of almost all changes and discussion to the 3GPP use of IPsec for the last 20 years. I cannot remember anyone suggesting to relax the mandate on replay protection. And if anyone was to suggest such a thing, Ericsson would strongly object to such a change. TS 33.210 "For NDS/IP-networks the IPsec security protocol shall always be ESP. For NDS/IP-networks it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used." https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279 TS 33.501 If you look at the 5G security specification, you will find the sentence "shall be integrity, confidentiality and replay-protected" for every interface. Additionally the requirement in 33.210 apply to all uses of IPsec in 5G and 4G. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169 Upper layers in mobile networks are designed with the expectation that the security layer always provide replay protection. If you turn of replay protection in a 3GPP network you likely end up with a large number of nasty vulnerabilities. For a summary why you should not turn off replay protection except in very specific circumstances see the comments Ericsson recently send to NIST. https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-38b-initial-public-comments-2024.pdf "We think replay protection should be a strong requirement unless careful analysis of the whole system shows that replay protection is not needed in some specific part. Users and developers expect replay protection and higher layer protocols are often designed with the expectation that the security protocol provides replay protection. One example where no replay protection might be acceptable is 0-RTT in TLS 1.3 [22], but only after very careful analysis by the server on what kind of data to accept. Systems without replay protection often leads to surprising attacks and are hard to analyze. It is not a coincidence that Section 8 and E.5 in RFC 8446 [22] spends many pages analyzing security considerations for replayable 0-RTT data. If an upper layer was designed with the expectation of replay protection in a lower layer, using a security protocol without replay protection in the lower layers can compromise confidentiality, integrity, and availability in the higher layer, i.e., the whole infosec CIA triad. Practical and serious vulnerability due to the lack of replay protection has been common in both standardized and proprietary systems. It is sometimes argued that replay protection can be turned off in a lower layer as it is handled in a higher layer. This might be correct for the current configuration but often leads to securi
