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]
