Hi Valery, Thanks. Yes, I think spelling it out would help a little, mostly to avoid implementers reading "different PSKs" as only two different configured byte strings.
I opened a tiny PR here: https://github.com/smyslov/ikev2-downgrade-prevention/pull/50 The intended point is that the relevant condition is not just PSK inequality. The PSKs also need to be selected and verified as peer- and direction-specific authentication credentials, bound to the corresponding peer identities. Otherwise the text may be read as a configuration property rather than an authentication-bound security condition. Please feel free to take, adjust, or drop the wording if it is too much for this stage. Regards, Songbo On Thu, 18 Jun 2026 09:59:26 +0300, Valery Smyslov <[email protected]> wrote: > Hi Songbo, > > > 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" > > Urgh, result of my careless typing :-) > Thanks for spotting. > > > 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. > > Yes, the binding was implied. If you think that this should be spelled out, > we will try to clarify this. > > Regards, > Valery. > > > 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] > > > <draft-ietf-ipsecme-ikev2-downgrade- > > [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] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
