Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

[Rebecca Guthrie <[e-mail]>]

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)

-----Original Message-----
From: IPsec <[e-mail]> On Behalf Of Valery Smyslov
Sent: Friday, April 14, 2023 4:11 AM
To: IPsecME WG <[e-mail]>
Cc: [e-mail]
Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

Hi,

a new version of the draft has been published.
It addresses issue with mismatched PPKs and also adds some clarifications on interaction with RFC 8784.

As it was discussed at the IETF116 IPSECME meeting, once the new version is published, a call for adoption would  be issued.

Chairs, can you please issue an adoption call?

Regards,
Valery.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, April 14, 2023 10:32 AM
> To: Valery Smyslov
> Subject: New Version Notification for 
> draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> 
> 
> A new version of I-D, draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> has been successfully submitted by Valery Smyslov and posted to the 
> IETF repository.
> 
> Name:		draft-smyslov-ipsecme-ikev2-qr-alt
> Revision:	07
> Title:		Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security
> Document date:	2023-04-14
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/archive/id/draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-qr-alt
> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-smyslov-ipsecme-ikev2-qr-alt-07
> 
> Abstract:
>    An IKEv2 extension defined in [RFC8784] allows IPsec traffic to be
>    protected against someone storing VPN communications today and
>    decrypting it later, when (and if) cryptographically relevant quantum
>    computers are available.  However, this protection doesn't cover an
>    initial IKEv2 SA, which might be unacceptable in some scenarios.
>    This specification defines an alternative way get protection against
>    quantum computers, but unlike the [RFC8784] solution it covers the
>    initial IKEv2 SA too.
> 
> 
> 
> 
> The IETF Secretariat


_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec