Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw]

If you have the bandwidth, I would recommend publishing a new draft. The 
pre-meeting publication cut off is on Oct 24. Having an up to date document is 
helpful going into the meeting.

Roman


From: IPsec  on behalf of CJ Tjhai 

Sent: Friday, October 21, 2022 3:08 AM
To: Roman Danyliw 
Cc: Tero Kivinen ; Valery Smyslov ; 
ipsec@ietf.org ; Valery Smyslov 
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

Hi Roman,

We have updated our draft to incorporate Russ' feedback and also changes from 
IANA review. it also includes the following changes following your suggestions.

The updated draft is available here 
https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml.

Should we publish version 08 of the draft, or should we just wait for the end 
of IETF LC?

Best wishes,
CJ and Valery

[snip]
[Roman] Makes sense.  Thanks. To prevent this from coming up during subsequent 
reviews.  Please add a reference to that FAQ here.
We have added the reference to NIST FAQs.
[snip]

[Roman] A recommended value would help if you are comfortable giving it, or 
explaining why it’s hard to give one.  This is a common question that comes 
from transport review during IETC LC or IESG review.
We added the following sentences:

Note that due to various factors such as computational resource
and key exchange algorithm used, it is not possible to give a
normative guidance on how long this timeout period should be.
In general, 5-20 seconds of waiting time should be appropriate
in most cases.

[snip]

[Roman] Adding a bit of clarifying text like discussed here would be helpful – 
that the ordering does not matter.
We added this text as suggested:

The ordering of the additional key exchanges should not matter in
general, as only the final shared secret is of interest.
Nonetheless, because the strength of the running shared secret
increases with every additional key exchange, an implementer may
want to first perform the most secure method (in some metrics) and
followed by less secure one(s).


[Roman] Agreed. Consider if you need to talk about work that ISN’T done in this 
document here.  To keep things on point, I would recommend deleting this text.

We have removed the text as suggested.


On Wed, 12 Oct 2022 at 20:18, Valery Smyslov 
mailto:smyslov.i...@gmail.com>> wrote:
Hi Tero,

> Roman Danyliw writes:
> > ** Section 3.2.4.
> >
> > The responder MUST handle this
> >situation gracefully and delete the associated state if it does not
> >receive the next expected IKE_FOLLOWUP_KE request after some
> >reasonable period of time.
> >
> > Is there a guidance on the timeout value?
> >
> > IKEv2 traditionally does not mandate exact timeouts. For example, the
> same
> > situation happens if the initiator completes IKE_SA_INIT and never starts
> > IKE_AUTH. The responder should eventually delete the incomplete IKE SA,
> but
> > RFC 7296 does not specify how long the waiting time is.
> >
> > FWIW, our implementations waits 5 seconds by default (which is
> adjustable
> > value).
> >
> > Do you think we should recommend (but not mandate) to wait for 5-10
> seconds?
> >
> > [Roman] A recommended value would help if you are comfortable giving
> it, or
> > explaining why it’s hard to give one.  This is a common question that
> comes
> > from transport review during IETC LC or IESG review.
>
> Suitable values can be between few seconds up to few minutes. For
> example timeout between IKE_SA_INIT and IKE_AUTH might require user
> interaction, thus it might be up to minutes if PIN code to unlock user
> auth device is required etc.
>
> Because the timeouts are so different depending on the environment and
> usage scenario we do not give them in the IKEv2 document.

With the IKE_FOLLOWUP_KE exchange user interaction is not a problem (it should 
not take place).
However, since we are talking about PQ algorithms and some of them
may be quite costly in terms of generating a key pair, the initiator may just
be unable to provide data for the next IKE_FOLLOWUP_KE exchange quickly.

So, while I think that several minutes is too long in this case,
I agree that timeout values could be very different depending on the
initiator's resources and on the algorithm employed. For this reason
we didn't specify it. We can give a vague recommendation
that waiting for 5-20 seconds can be appropriate in most situations,
but definitely we don't want making these values normative.

Regards,
Valery.

> --
> kivi...@iki.fi<mailto:kivi...@iki.fi>
>
> ___
> IPsec mailing list
> IPsec@ietf.org<mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec


___

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[CJ Tjhai]

Hi Roman,

We have updated our draft to incorporate Russ' feedback and also changes
from IANA review. it also includes the following changes following your
suggestions.

The updated draft is available here
https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml
.

Should we publish version 08 of the draft, or should we just wait for the
end of IETF LC?

Best wishes,
CJ and Valery


[snip]

[Roman] Makes sense.  Thanks. To prevent this from coming up during
subsequent reviews.  Please add a reference to that FAQ here.

We have added the reference to NIST FAQs.

[snip]

[Roman] A recommended value would help if you are comfortable giving it, or
explaining why it’s hard to give one.  This is a common question that comes
from transport review during IETC LC or IESG review.

We added the following sentences:

Note that due to various factors such as computational resource

and key exchange algorithm used, it is not possible to give a

normative guidance on how long this timeout period should be.

In general, 5-20 seconds of waiting time should be appropriate

in most cases.



[snip]


[Roman] Adding a bit of clarifying text like discussed here would be
helpful – that the ordering does not matter.

We added this text as suggested:

The ordering of the additional key exchanges should not matter in
general, as only the final shared secret is of interest.
Nonetheless, because the strength of the running shared secret
increases with every additional key exchange, an implementer may
want to first perform the most secure method (in some metrics) and
followed by less secure one(s).




[Roman] Agreed. Consider if you need to talk about work that ISN’T done in
this document here.  To keep things on point, I would recommend deleting
this text.



We have removed the text as suggested.



On Wed, 12 Oct 2022 at 20:18, Valery Smyslov  wrote:

> Hi Tero,
>
> > Roman Danyliw writes:
> > > ** Section 3.2.4.
> > >
> > > The responder MUST handle this
> > >situation gracefully and delete the associated state if it does
> not
> > >receive the next expected IKE_FOLLOWUP_KE request after some
> > >reasonable period of time.
> > >
> > > Is there a guidance on the timeout value?
> > >
> > > IKEv2 traditionally does not mandate exact timeouts. For example, the
> > same
> > > situation happens if the initiator completes IKE_SA_INIT and never
> starts
> > > IKE_AUTH. The responder should eventually delete the incomplete IKE SA,
> > but
> > > RFC 7296 does not specify how long the waiting time is.
> > >
> > > FWIW, our implementations waits 5 seconds by default (which is
> > adjustable
> > > value).
> > >
> > > Do you think we should recommend (but not mandate) to wait for 5-10
> > seconds?
> > >
> > > [Roman] A recommended value would help if you are comfortable giving
> > it, or
> > > explaining why it’s hard to give one.  This is a common question that
> > comes
> > > from transport review during IETC LC or IESG review.
> >
> > Suitable values can be between few seconds up to few minutes. For
> > example timeout between IKE_SA_INIT and IKE_AUTH might require user
> > interaction, thus it might be up to minutes if PIN code to unlock user
> > auth device is required etc.
> >
> > Because the timeouts are so different depending on the environment and
> > usage scenario we do not give them in the IKEv2 document.
>
> With the IKE_FOLLOWUP_KE exchange user interaction is not a problem (it
> should not take place).
> However, since we are talking about PQ algorithms and some of them
> may be quite costly in terms of generating a key pair, the initiator may
> just
> be unable to provide data for the next IKE_FOLLOWUP_KE exchange quickly.
>
> So, while I think that several minutes is too long in this case,
> I agree that timeout values could be very different depending on the
> initiator's resources and on the algorithm employed. For this reason
> we didn't specify it. We can give a vague recommendation
> that waiting for 5-20 seconds can be appropriate in most situations,
> but definitely we don't want making these values normative.
>
> Regards,
> Valery.
>
> > --
> > kivi...@iki.fi
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
>

-- 

PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited 
company incorporated in England and Wales with registered number 06808505.
 

This email is meant only for the intended recipient. If you have received 
this email in error, any review, use, dissemination, distribution, or 
copying of this email is strictly prohibited. Please notify us immediately 
of the error by return email and please delete this message from your 
system. Thank you in advance for your cooperation.


For more information 
about Post-Quantum, please visit www.post-quantum.com 
.

In the course of our business 

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Valery Smyslov]

Hi Tero,

> Roman Danyliw writes:
> > ** Section 3.2.4.
> >
> > The responder MUST handle this
> >situation gracefully and delete the associated state if it does not
> >receive the next expected IKE_FOLLOWUP_KE request after some
> >reasonable period of time.
> >
> > Is there a guidance on the timeout value?
> >
> > IKEv2 traditionally does not mandate exact timeouts. For example, the
> same
> > situation happens if the initiator completes IKE_SA_INIT and never starts
> > IKE_AUTH. The responder should eventually delete the incomplete IKE SA,
> but
> > RFC 7296 does not specify how long the waiting time is.
> >
> > FWIW, our implementations waits 5 seconds by default (which is
> adjustable
> > value).
> >
> > Do you think we should recommend (but not mandate) to wait for 5-10
> seconds?
> >
> > [Roman] A recommended value would help if you are comfortable giving
> it, or
> > explaining why it’s hard to give one.  This is a common question that
> comes
> > from transport review during IETC LC or IESG review.
> 
> Suitable values can be between few seconds up to few minutes. For
> example timeout between IKE_SA_INIT and IKE_AUTH might require user
> interaction, thus it might be up to minutes if PIN code to unlock user
> auth device is required etc.
> 
> Because the timeouts are so different depending on the environment and
> usage scenario we do not give them in the IKEv2 document.

With the IKE_FOLLOWUP_KE exchange user interaction is not a problem (it should 
not take place).
However, since we are talking about PQ algorithms and some of them
may be quite costly in terms of generating a key pair, the initiator may just
be unable to provide data for the next IKE_FOLLOWUP_KE exchange quickly.

So, while I think that several minutes is too long in this case,
I agree that timeout values could be very different depending on the 
initiator's resources and on the algorithm employed. For this reason
we didn't specify it. We can give a vague recommendation
that waiting for 5-20 seconds can be appropriate in most situations,
but definitely we don't want making these values normative.

Regards,
Valery.

> --
> kivi...@iki.fi
> 
> ___
> 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

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Tero Kivinen]

Roman Danyliw writes:
> ** Section 3.2.4. 
>
> The responder MUST handle this
>situation gracefully and delete the associated state if it does not
>receive the next expected IKE_FOLLOWUP_KE request after some
>reasonable period of time.
>
> Is there a guidance on the timeout value?
> 
> IKEv2 traditionally does not mandate exact timeouts. For example, the same
> situation happens if the initiator completes IKE_SA_INIT and never starts
> IKE_AUTH. The responder should eventually delete the incomplete IKE SA, but
> RFC 7296 does not specify how long the waiting time is.
> 
> FWIW, our implementations waits 5 seconds by default (which is adjustable
> value).
> 
> Do you think we should recommend (but not mandate) to wait for 5-10 seconds?
> 
> [Roman] A recommended value would help if you are comfortable giving it, or
> explaining why it’s hard to give one.  This is a common question that comes
> from transport review during IETC LC or IESG review.

Suitable values can be between few seconds up to few minutes. For
example timeout between IKE_SA_INIT and IKE_AUTH might require user
interaction, thus it might be up to minutes if PIN code to unlock user
auth device is required etc.

Because the timeouts are so different depending on the environment and
usage scenario we do not give them in the IKEv2 document. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw]

Hi!

Thanks for the explanation and the revised text in -07.  I’m advancing the 
document to IETF LC.

I have a few replies to consider with any additional IETF LC feedback.

From: CJ Tjhai 
Sent: Tuesday, October 4, 2022 9:05 PM
To: Roman Danyliw 
Cc: Valery Smyslov ; ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[snip]

On Fri, 30 Sept 2022 at 23:20, Roman Danyliw 
mailto:r...@cert.org>> wrote:

[snip]
** Section 2

Federal Information Processing Standards (FIPS) compliance.
IPsec is widely used in Federal Information Systems and FIPS
certification is an important requirement.  However, algorithms
that are believed to be post-quantum are not FIPS compliant yet.
Still, the goal is that the overall hybrid post-quantum IKEv2
design can be FIPS compliant.

What kind of coordination was done to ensure that this design is FIPS 
compliant?  Do we have a read if it is?

See NIST PQC FAQs (Transition and Migration section): 
https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs

Are multiple classic (EC)DH key exchanges FIPS compliant?

Based on the above FAQ, if at least one (EC)DH is FIPS complaint, we think that 
the overall exchange should be.

[Roman] Makes sense.  Thanks. To prevent this from coming up during subsequent 
reviews.  Please add a reference to that FAQ here.

[snip]
** Section 3.2.4.

The responder MUST handle this
   situation gracefully and delete the associated state if it does not
   receive the next expected IKE_FOLLOWUP_KE request after some
   reasonable period of time.

Is there a guidance on the timeout value?

IKEv2 traditionally does not mandate exact timeouts. For example, the same 
situation happens if the initiator completes IKE_SA_INIT and never starts 
IKE_AUTH. The responder should eventually delete the incomplete IKE SA, but RFC 
7296 does not specify how long the waiting time is.

FWIW, our implementations waits 5 seconds by default (which is adjustable 
value).

Do you think we should recommend (but not mandate) to wait for 5-10 seconds?

[Roman] A recommended value would help if you are comfortable giving it, or 
explaining why it’s hard to give one.  This is a common question that comes 
from transport review during IETC LC or IESG review.


[snip]

** Section 5.  Is there any significance to the order of the KEs?  Does 
4096-bit MODP Group then PQ_KEM1 yield anything different than the reverse?  
Should the classic KEM come before the PQC one(s)?

In order to avoid potential fragmentation issue, KE payload should be small 
enough, so it may not be desirable to use PQ_KEM1 (assuming its public 
key/ciphertext is larger than 1.5KB) in the KE payload. So in general, we 
expect the KE payload to be used for (EC)DH and this will help in terms of 
backward compatibility. Ignoring this consideration, we think the ordering of 
the key exchange should not matter as we are only interested in the overall 
shared secret.

Having said that, we could also see that one could argue that it matters. Note 
that the "strength" of the running shared secret (assuming there is no issue on 
the random number generator used) increases with every new additional key 
exchange. So one may wish to first perform the most secure method (in some 
metrics) and then add less trusted one(s).

[Roman] Adding a bit of clarifying text like discussed here would be helpful – 
that the ordering does not matter.


** Section 5.

   Post-quantum authenticity
   may be provided by using a post-quantum digital signature and several
   of them have been being explored by IETF.  For example, if the
   implementation is able to reliably track state, the hash based
   method, XMSS has the status of an RFC, see [RFC8391].  Currently,
   post-quantum authentication methods are not specified in this
   document, but are planned to be incorporated in due course.

-- What activity in the IETF exploring PQ digital signatures?

There is this work on composite signatures: 
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
and an expired draft on the same subject but specific to IKEv2: 
https://datatracker.ietf.org/doc/draft-guthrie-ipsecme-ikev2-hybrid-auth/


-- Is using XMSS a recommendation?

Due to the need to keep states, we think XMSS may not be that suitable for 
IKEv2.

-- What is the planned due course referenced here?

We believe the document should focus on confidentiality. Supports for PQ 
digital signatures can be added as a separate document.

[Roman] Agreed. Consider if you need to talk about work that ISN’T done in this 
document here.  To keep things on point, I would recommend deleting this text.

Regards,
Roman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw]

Hi!

From: CJ Tjhai 
Sent: Tuesday, October 4, 2022 9:05 PM
To: Roman Danyliw 
Cc: Valery Smyslov ; ipsec@ietf.org
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

Hi Roman,

Many thanks for the review, really appreciate it. We will update our draft and 
submit a revision soon.

Please see our response inline below.

Best wishes,
CJ and Valery


On Fri, 30 Sept 2022 at 23:20, Roman Danyliw 
mailto:r...@cert.org>> wrote:
Hi!

I performed an AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06.  Thanks 
for the work on this document.

Per the shepherd write-up:

** Question 4

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

Could these implementations be explicitly named?

Just an extra to Andreas' response, the interop tests have been presented in 
IETF meetings and the latest one was in 2021. The slides can be found here: 
https://datatracker.ietf.org/meeting/111/materials/slides-111-ipsecme-hybrid-ikev2-interoperability-testing-00


** Question 5

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

With no disrespect intended to the expertise of the authors, what is the 
process used by the WG to review the robustness of the cryptographic 
mechanisms?  Was there an independent assessment beyond those on the author 
team?  Did the Crypto Panel have an independent look?

In terms of independent assessment, there is a paper on the formal proof 
analysis of the extension introduced in the draft: 
https://www.mnm-team.org/pub/Publikationen/gggh21b/PDF-Version/gggh21b.pdf

[Roman] Thanks for this pointer.  I’ll add that to the Shepherd Review citing 
it from the ACSAC 2021 proceedings 
(https://dl.acm.org/doi/10.1145/3485832.3485885).

Roman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[CJ Tjhai]

Hi Roman,

Many thanks for the review, really appreciate it. We will update our draft
and submit a revision soon.

Please see our response inline below.

Best wishes,
CJ and Valery


On Fri, 30 Sept 2022 at 23:20, Roman Danyliw  wrote:

> Hi!
>
> I performed an AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06.
> Thanks for the work on this document.
>
> Per the shepherd write-up:
>
> ** Question 4
>
> Several implementors have been integral in developing this document, thus
> implementors have indicated interest in implementing this. There is already
> at least two interoperable implementations of this specification.
>
> Could these implementations be explicitly named?
>

Just an extra to Andreas' response, the interop tests have been presented
in IETF meetings and the latest one was in 2021. The slides can be found
here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-ipsecme-hybrid-ikev2-interoperability-testing-00



>
> ** Question 5
>
> No. The document has already been reviewed by security area people, and
> the cryptographic algorithms are not part of this document, but are
> documented
> separately. In addition reviews from cryptographers have already been
> received
> to the basic protocol.
>
> With no disrespect intended to the expertise of the authors, what is the
> process used by the WG to review the robustness of the cryptographic
> mechanisms?  Was there an independent assessment beyond those on the author
> team?  Did the Crypto Panel have an independent look?
>

In terms of independent assessment, there is a paper on the formal proof
analysis of the extension introduced in the draft:
https://www.mnm-team.org/pub/Publikationen/gggh21b/PDF-Version/gggh21b.pdf


>
> Now to the document:
>
> ** Section 1.2.  Editorial.
>
> OLD
> ... is not limited to addressing the threat of
>quantum computer only.
>
> NEW
> ... is not limited to only addressing the threat of a
>quantum computer.
>
> ** Section 2.  Design Criteria #3
>
> A passive attacker can
> eavesdrop on IPsec communication today and decrypt it once a
> quantum computer is available in the future.  This is a very
> serious attack for which we do not have a solution.
>
> Isn't this the same thing as design criteria #1?
>

You have got a point here, they are similar. What if we change the design
criteria #1 to this:

   1)   Need for PQC in IPsec.  Quantum computers, which might become
feasible in the near future, pose a threat to our classical
public key cryptography.  PQC, a family of public key
cryptography that is believed to be resistant against these
computers, needs to be integrated into IPsec protocol suite to
restore confidentiality and authenticity.


>
> ** Section 2
>
> Federal Information Processing Standards (FIPS) compliance.
> IPsec is widely used in Federal Information Systems and FIPS
> certification is an important requirement.  However, algorithms
> that are believed to be post-quantum are not FIPS compliant yet.
> Still, the goal is that the overall hybrid post-quantum IKEv2
> design can be FIPS compliant.
>
> What kind of coordination was done to ensure that this design is FIPS
> compliant?  Do we have a read if it is?
>
>
See NIST PQC FAQs (Transition and Migration section):
https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs


> Are multiple classic (EC)DH key exchanges FIPS compliant?
>
>
Based on the above FAQ, if at least one (EC)DH is FIPS complaint, we think
that the overall exchange should be.


> ** Section 3.1
>
> We assume that new Transform Type 4 identifiers will be assigned
>later to the various post-quantum key exchanges.
>
> -- Please add reference to such as "[IANA-Type4-ID]
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8
> "
>
> -- s/assigned later to the/assigned later for/
>
> ** Section 3.1.
>
>To be more specific,
>this document renames Transform Type 4 from "Diffie-Hellman Group
>(D-H)" to "Key Exchange Method (KE)" and renames a field in the Key
>Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange
>Method".  The corresponding IANA registry is also renamed from
>"Diffie-Hellman Group Transform IDs" to "Key Exchange Method
>Transform IDs".
>
> Why repeat what is already spelled out more clearly in Section 4?
>

We would like to summarise the changes, in particular the change to the
field on the KE payload is not in Section 4. How about this?

This document renames a field in the Key Exchange Payload from
"Diffie-Hellman Group Num" to "Key Exchange Method".  It also renames
Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange
Method (KE)"; the corresponding renaming to the IANA registry is
described in Section 4.


>
> ** Section 3.1.
>
>Note that this document assumes, that each key exchange method
>requires one round trip and consumes exactly one 

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw]

Hi Adreas!

> -Original Message-
> From: IPsec  On Behalf Of Andreas Steffen
> Sent: Saturday, October 1, 2022 7:29 AM
> To: Roman Danyliw ; ipsec@ietf.org
> Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06
> 
> On 01.10.22 00:19, Roman Danyliw wrote:
> >
> > ** Question 4
> >
> > Several implementors have been integral in developing this document,
> > thus implementors have indicated interest in implementing this. There
> > is already at least two interoperable implementations of this specification.
> >
> > Could these implementations be explicitly named?
> > 1) strongSwan implements the draft-ietf-ipsecme-ikev2-multiple-ke
> document:
> 
> https://github.com/strongswan/strongswan/tree/ikev2-qske-multi-ke
> 
> As soon as the RFC is published, strongSwan 6.0 with QSKE-Multi-KE
> support will be released
> 
> 2) A second implementation with which strongSwan has been successfully
> interoperating is ELVIS by Valery Smyslov .

Thanks for this information.  I merged it into the shepherd report.

Roman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Andreas Steffen]

On 01.10.22 00:19, Roman Danyliw wrote:


** Question 4

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

Could these implementations be explicitly named?
1) strongSwan implements the draft-ietf-ipsecme-ikev2-multiple-ke

   document:

   https://github.com/strongswan/strongswan/tree/ikev2-qske-multi-ke

   As soon as the RFC is published, strongSwan 6.0 with QSKE-Multi-KE
   support will be released

2) A second implementation with which strongSwan has been successfully
   interoperating is ELVIS by Valery Smyslov .

Best regards

Andreas

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
strongSec GmbH, 8952 Schlieren (Switzerland)
==

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw]

Hi!

I performed an AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06.  Thanks 
for the work on this document.

Per the shepherd write-up:

** Question 4

Several implementors have been integral in developing this document, thus 
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

Could these implementations be explicitly named?

** Question 5

No. The document has already been reviewed by security area people, and 
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received 
to the basic protocol.

With no disrespect intended to the expertise of the authors, what is the 
process used by the WG to review the robustness of the cryptographic 
mechanisms?  Was there an independent assessment beyond those on the author 
team?  Did the Crypto Panel have an independent look?

Now to the document:

** Section 1.2.  Editorial.

OLD
... is not limited to addressing the threat of
   quantum computer only.

NEW
... is not limited to only addressing the threat of a 
   quantum computer.

** Section 2.  Design Criteria #3

A passive attacker can
eavesdrop on IPsec communication today and decrypt it once a
quantum computer is available in the future.  This is a very
serious attack for which we do not have a solution.  

Isn't this the same thing as design criteria #1?

** Section 2

Federal Information Processing Standards (FIPS) compliance.
IPsec is widely used in Federal Information Systems and FIPS
certification is an important requirement.  However, algorithms
that are believed to be post-quantum are not FIPS compliant yet.
Still, the goal is that the overall hybrid post-quantum IKEv2
design can be FIPS compliant.

What kind of coordination was done to ensure that this design is FIPS 
compliant?  Do we have a read if it is?

Are multiple classic (EC)DH key exchanges FIPS compliant?

** Section 3.1

We assume that new Transform Type 4 identifiers will be assigned
   later to the various post-quantum key exchanges.

-- Please add reference to such as "[IANA-Type4-ID] 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8;

-- s/assigned later to the/assigned later for/

** Section 3.1.

   To be more specific,
   this document renames Transform Type 4 from "Diffie-Hellman Group
   (D-H)" to "Key Exchange Method (KE)" and renames a field in the Key
   Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange
   Method".  The corresponding IANA registry is also renamed from
   "Diffie-Hellman Group Transform IDs" to "Key Exchange Method
   Transform IDs".

Why repeat what is already spelled out more clearly in Section 4?

** Section 3.1.

   Note that this document assumes, that each key exchange method
   requires one round trip and consumes exactly one IKE_INTERMEDIATE
   exchange.  This assumption is valid for all classic key exchange
   methods defined so far and for all post-quantum methods currently
   known.  

Is ensuring that a chosen algorithm fits into a single exchange now an 
additional criterial for the DE for adding anything into the Type 4 ID 
registry?  If so, should this be stated?

** Section 3.1.  Typo. s/splitted/split/

** Section 3.2.  Editorial.  Colloquial language.  s/the initiator is happy 
with/the initiator starts/

** Section 3.2.  Editorial.

OLD
   In this case, the initiator performs the IKE_SA_INIT as usual,
   inserting a preferred key exchange (which is possibly a post-quantum
   algorithm) as the listed Transform Type 4, and including the
   initiator KE payload.  

NEW
In this case, the initiator performs the IKE_SA_INIT for a single key exchange 
using a Transform Type 4 (possibly with a post-quantum algorithm), and 
including the initiator KE payload.

** Section 3.2.1.  s/uses the protocol listed below./uses the protocol behavior 
listed below./

** Section 3.2.1.  What is the basis for the design choice allow up to 8 (1 in 
the IKE_SA_INIT + 7 via the AKE) key exchanges?  I don't have an intuition on 
why 7 is "just right".

** Section 3.2.1.

   However, for the Additional
   Key Exchange types, the responder's choice MUST NOT contain
   duplicated algorithms, except for the transform ID of NONE.  

If an initiator gets are response with such duplicates, what error or follow-up 
action should be taken?  In reverse, what happens if an initiator sends a 
responder a combination of Additional Key Exchange which are duplicates?

** Section 3.2.1.  Why is there a need to support non-consecutive Additional 
Key Exchange transforms?

** Section 3.2.1.  Editorial.  For clarity, recommend narrating the figure 
above.

OLD

In this example, the initiator proposes to perform initial key
   exchange using 4096-bit MODP group followed by two mandatory
   additional key exchanges using PQ_KEM_1