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

[Valery Smyslov <[e-mail]>]

Hi Rebecca,

thank you for your comments. Please, see inline.

> 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.

Correct.

> 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).

That's true, alas.

> 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.

In this case the responder has nothing to do except for aborting the negotiation.

> 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.

The draft was initially written as an extension to 8784, thus the negotiation was done in an implicit way.
I agree that this is sub-optimal in situations when it's critical for one of the peers to use this
mechanism and the other peer doesn't support it - this becomes clear late in the negotiation process.

It is possible to make the negotiation explicit by introducing a new status notify (however,
I would use name USE_ALT_PPK, since PPK is used early for IPsec SAs anyway).

In this case perhaps it's better to completely de-couple the negotiation of this specification 
from 8784: the initiator may send only USE_PPK (supports only 8784), only
USE_ALT_PPK (wants to use only this specification) or both (wants to use
this specification, but agrees to fall-back to 8784 if it is not supported by the responder).
The responder would respond accordingly.

> 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.

The reason why the initiator provides key confirmation(s) to the responder and not vice versa 
is that in this case it's more easy to handle PPK mismatch case in the protocol.
If the responder detects that the PPK value for the selected PPK mismatches, then it just sends
back AUTHENTICATION_FAILED (in the IKE_INTERMEDIATE) and the negotiation is aborted gracefully.
On the other hand, if the responder provided key confirmation to the initiator,
then in the situation when the selected PPK value mismatched, the initiator should inform the responder
somehow about this. From the responder's point of view the IKE_INTERMEDIATE exchange
has been completed successfully and the responder has been waiting for the IKE_AUTH request.
But the initiator could not start IKE_AUTH because it was unable to compute SK_* values.
The initiator might either send a clear INFORMATIONAL with AUTHENTICATION_FAILED
(that is not trusted at all) or might just abort the negotiation leaving the responder with 
the incomplete IKE SA, which would be eventually deleted, but would still consume some
memory before this and thus increasing surface for DoS attacks.
Note, that in this case there would be also no diagnostics on the responder
about the real reason the negotiation failed (it looked like DoS attack to the responder).

> 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).

The current Security Consideration section is mostly a stub.
I agree that more considerations should be added there.
Thank you for the concrete proposals.

Regards,
Valery.

> - 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
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec