Hi Valery, Chris, I did a quick pass over the new PSK/EAP text in -06. The security distinction looks right to me: the relevant condition is whether at least one authentication direction still depends on a secret or signature the attacker cannot compute.
In addition to Guilin's two nits, I noticed a few small editorial points in the same new text: - "attcker" -> "attacker" - "downgrade pevention" -> "downgrade prevention" - "first IKE_AUTH mesaage" -> "first IKE_AUTH message" One small clarity suggestion: it may help to avoid making "PSKs are different" carry too much by itself. The condition is really that the peers use distinct peer/direction-specific PSKs, those PSKs are correctly bound to the peer identities, and at least one of the relevant authentication secrets is not known to the attacker. If both directions use the same PSK and that value is compromised, the attacker can compute both AUTH payloads, so this mechanism cannot provide the intended downgrade-prevention property in that run. The current text already says most of this; I only suggest making the identity/direction binding explicit enough that implementers do not read "different PSKs" as only a configuration detail. Best, Songbo On Wed, 17 Jun 2026 16:28:06 +0000, Wang Guilin <[email protected]> wrote: > Congrats to the output! > > Just read Section 8 (Security considerations) and found two typos. > > 1. "However, if these PSKs are the same and this fact and the PSK value are > known to the attacker, ...": " and this fact" is redundant. > > 2. "Note, that mixing pre-shared keys into ...": "Note, that" should be "Note > that", I think. > > Guilin > > 发件人：Valery Smyslov <[email protected]> > > 收件人：'Yaroslav Rosomakho' <[email protected]>;[email protected] > <[email protected]> > > 抄 送：[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] <[email protected]> > > 时 间：2026-06-17 22:29:50 > > 主 题：[IPsec] Re: draft-ietf-ipsecme-ikev2-downgrade-prevention-05 ietf last > call Secdir review > > Hi Yaroslav, > > after discussing with Chris, we decided to add some text into the Security > considerations > > section that addresses nuances concerned with PSK (and EAP) authentication. > > Please find it in the new version of the draft: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/ > > The diff is: > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-ipsecme-ikev2-downgrade-prevention-05&url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-06&difftype=--html > > We hope this text resolves your concerns. > > Regards, > > Chris & Valery. > > > Hi Yaroslav, > > > > > > thank you for your review. Please, see inline. > > > > > > > Document: draft-ietf-ipsecme-ikev2-downgrade-prevention > > > > Title: Downgrade Prevention for the Internet Key Exchange Protocol > > > Version 2 > > > > (IKEv2) Reviewer: Yaroslav Rosomakho Review result: Has Issues > > > > > > > > I have reviewed this document as part of the security directorate's > > > ongoing > > > > effort to review all IETF documents being processed by the IESG. These > > > comments > > > > were written primarily for the benefit of the security area directors. > > > Document > > > > editors and WG chairs should treat these comments just like any other > > > last call > > > > comments. > > > > > > > > This specification describes an extension to IKEv2 that prevents > > > particular > > > > downgrade attacks. > > > > > > > > Minor issues: > > > > > > > > I found Section 7.2 incomplete. It requires the new mechanism to be used > > > during > > > > IKE session resumption if it was used during the previous IKE SA > > > establishment, > > > > but it does not specify the transcript to be signed or MAC'ed for the > > > > IKE_SESSION_RESUME exchange. > > > > > > RFC 5723 (IKE Session Resumption) does not define any new transcript for > > authentication, > > > it is the same as specified in Section 2.15 of RFC 7296, but RealMessage1 > > and RealMessage1 > > > in this case will be the IKE_SESSION_RESUME messages and not the > > IKE_SA_INIT messages. > > > > > > For this reason, there is no need to specify a separate transcript for > > resumption. > > > the draft modifies the way data to be authenticated is constructed (as per > > Section 2.15) > > > and this automatically applies to IKE session resumption too. > > > > > > > I believe it would be beneficial to clarify the security properties when > > > > symmetric shared secrets are used for authentication. The security > > > argument > > > > relies on at least one non-compromised authentication key being used. > > > This is > > > > clear for asymmetric authentication, where compromise of one peer's > > > private key > > > > does not imply compromise of the other peer's private key. However, when a > > > > single shared symmetric secret is used for authentication, compromise of > > > that > > > > secret compromises both authentication directions. > > > > > > In IKEv2 each peer can use its own PSK for authentication (to construct the > > AUTH payload). > > > It's true, that in this case both peers have to know both PSKs, but > > _formally_ they > > > can be different. Thus, I can imagine a situation when one of these PSKs is > > known to an attacker, > > > while the other is not. In this case we have the situation similar to the > > asymmetric > > > authentication, - the attacker can create the AUTH payload on behalf of one > > > peer, but not on behalf of the other (provided peers check that the used > > PSK is associated > > > with the peer identity). Sure, if these PSKs are the same and the attacker > > knows this fact > > > and this PSK is compromised, then our defense does not work. > > > > > > Do you think this should be clarified somehow in the draft? > > > > > > > Nits: > > > > > > > > Some articles missing: > > > > > > It happens (I'm sure these parts were written by me) :-) > > > > > > > Section 7.1: If peers support extension defined in this document -> If > > > peers > > > > support the extension defined in this document > > > > > > > > Section 7.2: provides a client with session ticket -> provides a client > > > with a > > > > session ticket > > > > > > > > Section 8: one of extensions -> one of the extensions > > > > > > > > Section 9: defines new Notify Message Type -> defines a new Notify > > > Message Type > > > > > > > > Minor grammar: > > > > > > > > Section 7.2: each of parameter -> each parameter > > > > > > > > Section 7.2: it is RECOMMENDED that the host do not use -> it is > > > RECOMMENDED > > > > that the host does not use > > > > > > > > Section 8: Note, that -> Note that > > > > > > Thanks for these findings, a PR is created: > > > https://github.com/smyslov/ikev2-downgrade-prevention/pull/45 > > > > > > Regards, > > > Valery. > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
