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 <ipsec-boun...@ietf.org> On Behalf Of Valery Smyslov
Sent: Friday, April 14, 2023 4:11 AM
To: IPsecME WG <ipsec@ietf.org>
Cc: ipsec-cha...@ietf.org
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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
