Re: [IPsec] Labeled IPsec options
Hi Paul,
I don't think option 4 is a good idea. If old responder
encounters an unknown payload with Critical bit set in IKE_AUTH, it will
return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up.
See section 2.21.2 of RFC7296. This would require initiator to retry from
IKE_SA_INIT, doubling the work. Or it can create childless IKE SA
and then try CREATE_CHILD_SA - not an optimal solution too.
I also don't like option 2 since it requires changing the way TSs are handled
in IKEv2.
Option 1 looks like the clearest from pure theoretical point of view,
however I agree that it could lead to TS types explosion in future.
Option 3 looks like a compromise from practical point of view.
You can solve the problem of imperfect error handling by adding
a new SECLABES_SUPPORTED notification, that must be exchanged
in IKE_SA_INIT. If both peers support seclabels, then
the responder must not ignore seclabel notifications in IKE_AUTH
and CREATE_CHILD_SA. The drawback is that we need
one more notification and it must be exchanged in IKE_SA_INIT,
increasing its message size. Not a big deal.
Regards,
Valery.
> Hi,
>
> As agreed at IETF 106, we would write up the options for negotiating
> Labeled IPsec that we have discussed, with their PROs and CONs, so
> that the working group can make a final decision.
>
>
>
> Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL
> https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00
>
> This option introduced a new Traffic Selector type that is similar
> to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but
> also contain a Security Label field
>
> PROs:
> - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes
> - Does not otherwise change the Traffic Selector processing
> CONs:
> - A bit ugly to have sort of duplicate Traffic Selector types
> - All new TS types in the future would need to get a seclabel and
> non-seclabel version.
>
>
>
>
> Option 2) TS_SECLABEL
> https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02
>
> PROs:
> - No copies of TS TYPE's with/without seclabel
> CONs:
> - Error handling is less nice. Responder might setup an IPsec SA
>narrowed to without security label (unsupported TStypes can be
>ignored according to RFC 7296), and the initiator has to refuse
>it by sending a Delete SA message (as security labels are typically
>mandatory)
> - Changes Traffic Selector processing, as now one is told that
>if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE.
>Thus updates RFC 7296 with "sub typing" of TS TYPEs.
>
>
>
>
> Option 3) Use NOTIFY payloads
> (not specified in a draft)
>
> PROs:
> - No changes to Traffic Selector code or specification. Easiest to
>implement.
> CONs:
> - Error handling is less nice. Responder might setup an IPsec SA
>without supporting the NOTIFY, and initiator has to Delete SA it.
>
>
>
> Option 4) A new payload type like NOTIFY but now we can set Critical Flag
> (not specified in a draft)
> PROs:
> - No changes to Traffic Selector code or specification. Easiest to
>implement.
> - Can use payload with Critical Flag, so exchange fails if not
>configured or supported for security label type payload
> - Error handling already done as part of standard IKEv2
> CONs:
> - Takes up a new payload number.
> - Old Implementations might ignore Critical Flag and new payload type
>and setup IPsec SA without Security Label? New implementations not
>receiving the new payload type must also send Delete SA to prevent
>non-label IPsec SA on responder to linger.
>
>
> Please let us know on the list which solution you prefer and why, so we
> can make a final decision and move on :)
>
> Paul & Sahana
>
> ___
> 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] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
On 11 Dec 2019, at 11:11, Yoav Nir wrote: Hi, Paul On 11 Dec 2019, at 20:03, Paul Hoffman wrote: On 11 Dec 2019, at 8:23, Salz, Rich wrote: We are seeing a flurry of these kind of “post quantum protection” things. This is the only one I have seen that is a method, not a new key exchange algorithm. It is understandable that you could have missed this from the title which misstates the topic. A much better title would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". Should we consider this a last call comment? Yes, please do. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
Hi, Paul > On 11 Dec 2019, at 20:03, Paul Hoffman wrote: > > On 11 Dec 2019, at 8:23, Salz, Rich wrote: > >> We are seeing a flurry of these kind of “post quantum protection” things. > > This is the only one I have seen that is a method, not a new key exchange > algorithm. It is understandable that you could have missed this from the > title which misstates the topic. A much better title would be "Mixing > Preshared Keys in IKEv2 for Postquantum Resistance". Should we consider this a last call comment? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Labeled IPsec options
+1 for option4, +0.5 for option3
One factor to consider is the granularity of label, for me it is per CHILD_SA;
option1 is per TS (e.g TS with label and TS without label could be mixed in the
same payload), option2 is per TS payload (e.g. you could have TSi with label,
TSr without label)
Option3 is a bit "abusing" the semantic of notification payload, since a "label
notification" is not communicating a status, error or capability.
-Original Message-
From: IPsec On Behalf Of Paul Wouters
Sent: Monday, December 9, 2019 8:58 PM
To: ipsec@ietf.org WG
Cc: Sahana Prasad
Subject: [IPsec] Labeled IPsec options
Hi,
As agreed at IETF 106, we would write up the options for negotiating Labeled
IPsec that we have discussed, with their PROs and CONs, so that the working
group can make a final decision.
Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL
https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00
This option introduced a new Traffic Selector type that is similar to the core
IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but also contain a Security
Label field
PROs:
- Early failure during IKE_AUTH when mismatched. No IPsec SA establishes
- Does not otherwise change the Traffic Selector processing
CONs:
- A bit ugly to have sort of duplicate Traffic Selector types
- All new TS types in the future would need to get a seclabel and non-seclabel
version.
Option 2) TS_SECLABEL
https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02
PROs:
- No copies of TS TYPE's with/without seclabel
CONs:
- Error handling is less nice. Responder might setup an IPsec SA
narrowed to without security label (unsupported TStypes can be
ignored according to RFC 7296), and the initiator has to refuse
it by sending a Delete SA message (as security labels are typically
mandatory)
- Changes Traffic Selector processing, as now one is told that
if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE.
Thus updates RFC 7296 with "sub typing" of TS TYPEs.
Option 3) Use NOTIFY payloads
(not specified in a draft)
PROs:
- No changes to Traffic Selector code or specification. Easiest to
implement.
CONs:
- Error handling is less nice. Responder might setup an IPsec SA
without supporting the NOTIFY, and initiator has to Delete SA it.
Option 4) A new payload type like NOTIFY but now we can set Critical Flag (not
specified in a draft)
PROs:
- No changes to Traffic Selector code or specification. Easiest to
implement.
- Can use payload with Critical Flag, so exchange fails if not
configured or supported for security label type payload
- Error handling already done as part of standard IKEv2
CONs:
- Takes up a new payload number.
- Old Implementations might ignore Critical Flag and new payload type
and setup IPsec SA without Security Label? New implementations not
receiving the new payload type must also send Delete SA to prevent
non-label IPsec SA on responder to linger.
Please let us know on the list which solution you prefer and why, so we can
make a final decision and move on :)
Paul & Sahana
___
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] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
Hi Rich, I think that Kenny's slides only support the idea, that the draft should be Standards Track. In particular, the slide "The Coming Crypt-Apocalypse?" has a bullet: * And traffic captured now could be broken later, so it’s a problem *today* if you have data that needs to be kept secure for decades. That's the problem the draft solves. Regards, Valery. > Slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-saag- > post-quantum-cryptography > > Video: https://www.youtube.com/watch?v=abmd1n5WUvc=1451s > > > On 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" > wrote: > > Did Kenny make this statement in the context of postquantum > cryptography (that is, public key algorithms that are believed to be secure > even if the adversary has a quantum computer)? > > That would certainly be a reasonable statement (as most postquantum > algorithms are fairly new, and are still being cryptographically vetted). > > On the other hand, this specific draft doesn't involve any postquantum > algorithms; it relies only on currently accepted algorithms, and so Kenny's > caution would not apply. > > > -Original Message- > > From: Salz, Rich > > Sent: Wednesday, December 11, 2019 11:23 AM > > To: last-c...@ietf.org > > Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; > david.walterm...@nist.gov; > > draft-ietf-ipsecme-qr-ik...@ietf.org > > Subject: Re: Last Call: > (Postquantum > > Preshared Keys for IKEv2) to Proposed Standard > > > > We are seeing a flurry of these kind of “post quantum protection” > things. > > This is premature. The co-chair of the CFRG, Kenny Paterson, said so > awhile > > back. > > > > At best, this should be EXPERIMENTAL. > > > > I would like to see an IESG policy that makes all drafts on this topic > be > > EXPERIMENTAL. > > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
> A much better title would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". That's better. I misunderstood the document as both you and David Mcgrew kindly explained. I withdraw my concerns and hope the title is changed. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
On 11 Dec 2019, at 8:23, Salz, Rich wrote: We are seeing a flurry of these kind of “post quantum protection” things. This is the only one I have seen that is a method, not a new key exchange algorithm. It is understandable that you could have missed this from the title which misstates the topic. A much better title would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance". This is premature. Disagree. The method described in the document has been well-discussed in the IPsecME for years, getting good cryptographic review. The co-chair of the CFRG, Kenny Paterson, said so awhile back. I don't think that's what he said in the slides you posted, but I've Cc'd him so he can reply. The slides are about picking new post-quantum algorithms; what is described in the draft is a method for mixing in preshared secrets with current algorithms. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
Hi Rich, I strongly disagree with your statement that “this is premature”, and the slides that you cite do not support that claim. I totally agree with the points in Kenny’s slides, especially as they pertain to QKD and SDO-shopping, but they say nothing about improvements to security protocols that use quantum-resistant *symmetric* cryptography. The Postquantum Preshared Keys for IKEv2 specification is a sound and mature specification that uses existing crypto algorithms with parameters that are widely believed to be post quantum secure. David > On Dec 11, 2019, at 11:40 AM, Salz, Rich wrote: > > Slides: > https://datatracker.ietf.org/meeting/99/materials/slides-99-saag-post-quantum-cryptography > > Video: https://www.youtube.com/watch?v=abmd1n5WUvc=1451s > > > On 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" wrote: > >Did Kenny make this statement in the context of postquantum cryptography > (that is, public key algorithms that are believed to be secure even if the > adversary has a quantum computer)? > >That would certainly be a reasonable statement (as most postquantum > algorithms are fairly new, and are still being cryptographically vetted). > >On the other hand, this specific draft doesn't involve any postquantum > algorithms; it relies only on currently accepted algorithms, and so Kenny's > caution would not apply. > >> -Original Message- >> From: Salz, Rich >> Sent: Wednesday, December 11, 2019 11:23 AM >> To: last-c...@ietf.org >> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; >> draft-ietf-ipsecme-qr-ik...@ietf.org >> Subject: Re: Last Call: (Postquantum >> Preshared Keys for IKEv2) to Proposed Standard >> >> We are seeing a flurry of these kind of “post quantum protection” things. >> This is premature. The co-chair of the CFRG, Kenny Paterson, said so awhile >> back. >> >> At best, this should be EXPERIMENTAL. >> >> I would like to see an IESG policy that makes all drafts on this topic be >> EXPERIMENTAL. >> > > > smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
Slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-saag-post-quantum-cryptography Video: https://www.youtube.com/watch?v=abmd1n5WUvc=1451s On 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" wrote: Did Kenny make this statement in the context of postquantum cryptography (that is, public key algorithms that are believed to be secure even if the adversary has a quantum computer)? That would certainly be a reasonable statement (as most postquantum algorithms are fairly new, and are still being cryptographically vetted). On the other hand, this specific draft doesn't involve any postquantum algorithms; it relies only on currently accepted algorithms, and so Kenny's caution would not apply. > -Original Message- > From: Salz, Rich > Sent: Wednesday, December 11, 2019 11:23 AM > To: last-c...@ietf.org > Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; > draft-ietf-ipsecme-qr-ik...@ietf.org > Subject: Re: Last Call: (Postquantum > Preshared Keys for IKEv2) to Proposed Standard > > We are seeing a flurry of these kind of “post quantum protection” things. > This is premature. The co-chair of the CFRG, Kenny Paterson, said so awhile > back. > > At best, this should be EXPERIMENTAL. > > I would like to see an IESG policy that makes all drafts on this topic be > EXPERIMENTAL. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
Did Kenny make this statement in the context of postquantum cryptography (that is, public key algorithms that are believed to be secure even if the adversary has a quantum computer)? That would certainly be a reasonable statement (as most postquantum algorithms are fairly new, and are still being cryptographically vetted). On the other hand, this specific draft doesn't involve any postquantum algorithms; it relies only on currently accepted algorithms, and so Kenny's caution would not apply. > -Original Message- > From: Salz, Rich > Sent: Wednesday, December 11, 2019 11:23 AM > To: last-c...@ietf.org > Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; > draft-ietf-ipsecme-qr-ik...@ietf.org > Subject: Re: Last Call: (Postquantum > Preshared Keys for IKEv2) to Proposed Standard > > We are seeing a flurry of these kind of “post quantum protection” things. > This is premature. The co-chair of the CFRG, Kenny Paterson, said so awhile > back. > > At best, this should be EXPERIMENTAL. > > I would like to see an IESG policy that makes all drafts on this topic be > EXPERIMENTAL. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
We are seeing a flurry of these kind of “post quantum protection” things. This is premature. The co-chair of the CFRG, Kenny Paterson, said so awhile back. At best, this should be EXPERIMENTAL. I would like to see an IESG policy that makes all drafts on this topic be EXPERIMENTAL. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
I'm glad to see this document finally make it towards standardization. Just a minor editorial note: capitalizing "Quantum Computers" is incorrect and should be fixed before it goes to the RFC Editor. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Postquantum Preshared Keys for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-12-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The possibility of Quantum Computers poses a serious challenge to cryptographic algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
