Hi,
I agree with Rebecca's suggestion. Especially the first one, regarding
introducing the USE_EARLY_PPK notify, since it seems the introduction would
also make the implementation of the draft (combined with RFC 8784)
'cleaner'/easier to understand and verify.
BTW. I support the adoption of the draft as well (there is a newer -08
version).
Regards,
Vukašin Karadžić
уто, 22. авг 2023. у 21:01 <ipsec-requ...@ietf.org> је написао/ла:
> Message: 1
> Date: Mon, 21 Aug 2023 21:25:08 +0000
> From: Rebecca Guthrie <rmgu...@uwe.nsa.gov>
> To: Valery Smyslov <s...@elvis.ru>, IPsecME WG <ipsec@ietf.org>
> Cc: "ipsec-cha...@ietf.org" <ipsec-cha...@ietf.org>
> Subject: Re: [IPsec] New Version Notification for
> draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> Message-ID:
> <
> ph8pr09mb92945faff119de5abfe3601bfc...@ph8pr09mb9294.namprd09.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Greetings,
>
> I wrote to the mail list before IETF 117 that I support adoption of
> draft-smyslov-ipsecme-ikev2-qr-alt, and I have comments I would like to
> make. The draft did not get discussed at 117, so I'll share my comments
> here.
>
> Comment: I suggest that the draft define a new Notify Payload,
> USE_EARLY_PPK, that uniquely specifies support for this draft, rather than
> relying on USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED.
>
> Explanation: There was agreement at the 116 meeting that the extension
> specified in this draft should not be used in conjunction with RFC 8784.
> The draft does allow for a fall-back to the PSK mechanism specified in RFC
> 8784 if the mechanism specified in this draft is not supported by the
> responder- this necessitates USE_PPK to be used ambiguously, such that its
> inclusion by the initiator in IKE_SA_INIT can represent the initiator's
> intent to do either (this draft's PSK mechanism or RFC 8784).
>
> However, since it is still possible that RFC 8784 and RFC 9242 are used
> together, the inclusion of both USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED
> does not uniquely specify this draft; rather, it could mean that an IKE
> peer supports RFC 8784, plans to use IKE_INTERMEDIATE for another purpose,
> and does not support this draft.
>
> There may be a time where certain IKEv2 instances require the use of this
> draft such that the peer will abort the creation of the IKE SA if the
> extension specified in this draft cannot be supported. The peer may require
> the use of this draft either after transitioning away from RFC 8784, or
> having never supported RFC 8784 at all. In either case, the initiator and
> responder must be able to negotiate the use of this extension in
> IKE_SA_INIT. As the draft is currently written, depending on assumptions
> made by initiator and responder and depending on what is supported, they
> are able to get all the way to the end of IKE_INTERMEDIATE before realizing
> requirements cannot be met.
>
> In the case where the Initiator requires draft-smslov-ipsecme-ikev2-qr-alt
> and RFC 9370, and the Responder supports RFC 8784 and RFC 9370, both will
> include USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED in their respective
> IKE_SA_INIT messages, but the Initiator will not discover that it must
> abandon the SA until it has computed all of the intermediate key exchanges
> only to receive no response to its PPK_IDENTITY_KEY notification(s).
>
> On the other hand, if the Responder requires the use of this draft and the
> Initiator instead supports RFC 8784, it is unclear what the responder
> should do when it does not receive a PPK negotiation message from the
> Initiator in the last IKE_INTERMEDIATE exchange. It is possible that the
> Responder may be expecting another IKE_INTERMEDIATE message containing PPK
> negotiation information, but if the Initiator does not support this
> extension, then it would instead begin the IKE_AUTH exchange.
>
> Defining a new Notify Payload, USE_EARLY_PPK, that uniquely specifies
> support for this draft would remove the described ambiguity. In order to
> indicate support for the fall-back to RFC 8784 capability, the Initiator
> would send both USE_PPK and USE_EARLY_PPK Notify Payloads. It should be the
> case that when these are sent together, the preference for USE_EARLY_PPK is
> implicit. If the responder also supports USE_EARLY_PPK, it will ignore
> USE_PPK. If the responder does not support or does not recognize
> USE_EARLY_PPK, it may still support USE_PPK, and can proceed with the PSK
> mechanism described in RFC 8784.
>
> Comment: During IKE_INTERMEDIATE, use N(PPK_IDENTITY) in initiator message
> and N(PPK_IDENTITY_KEY) in responder message, only for the single PPK the
> responder has selected.
>
> Explanation: Currently, in the last IKE_INTERMEDIATE, the initiator sends
> SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1) [ , ... , N(PPK_IDENTITY_KEY,
> PPK_ID_n ) ] } where PPK_IDENTITY_KEY is sent for each PPK_ID the initiator
> is offering. The responder then sends SK { N(PPK_IDENTITY) } for the PPK it
> selects, using the N(PPK_IDENTITY) Notify Payload specified in RFC 8784.
>
> It's my understanding that the initiator and responder expect the PPKs to
> match for any given PPK_ID (i.e. that there is a very high likelihood that
> they match). If this assumption is incorrect, please correct me, but if
> this is the case, in order to perform fewer computations and shrink the
> size of the initiator message, it may make sense to use N(PPK_IDENTITY)
> [RFC8784] in the initiator message, and the new N(PPK_IDENTITY_KEY) in the
> responder message, only for the single PPK the responder has selected.
> Then, before the initiator sends IKE_AUTH, it can use the confirmation
> value sent by the responder in N(PPK_IDENTITY_KEY) to check that the PPK
> values the initiator and responder are using match. (If they do not match,
> the initiator could send another IKE_INTERMEDIATE containing
> N(PPK_IDENTITY_KEY)s for each PPK it supports, as currently specified.)
> Depending on how many PPKs the initiator offers, this may not considerably
> shrink the message size.
>
> Comment: Update Security Considerations section.
>
> Explanation: The Security Considerations section currently cites RFC 8784.
> I'd suggest that RFC 9242's security considerations be referenced as well,
> and I'd suggest repeating some of the security considerations from RFC 9370
> that are relevant here- in particular, the second paragraph of RFC 9370
> discusses how to ensure quantum resistance in Transform Types 2 and 3- this
> is worth repeating here, especially in the case that this draft is used
> independently (without RFC 9370) to provide QR.
>
> In RFC 8784 and RFC 9370, there is discussion of the security of each
> extension with regard to an active attacker- it may be useful in this draft
> to extend this discussion here in order to cover 1. the addition of
> IKE_INTERMEDIATE, 2. the fact that QR is achieved prior to IKE_AUTH (either
> if this draft is used on its own or in conjunction with RFC 9370), and 3.
> the fact that authentication is QR (compared to RFC 9370 alone).
>
> - Rebecca
>
> Rebecca Guthrie
> she/her
> Center for Cybersecurity Standards (CCSS)
> Cybersecurity Collaboration Center (CCC)
> National Security Agency (NSA)
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
