Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

[Panos Kampanakis (pkampana)]

Hi Quynh, 

 

> An obvious question is that what is the performance impact from this large
KEM using the approaches above when compared with a KEM (if its public key
and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq
signature algorithm has a small signature and a small public key) which
would work well in a normal IKEv2's implementation ? 

> I guess the impact is small generally because an IPsec tunnel normally
stays up for a long time. Does my guess seem ok here ?

> Would there be some noticeable impact on a high-volume connections VPN
server ?

> An obvious question is that what is the performance impact from this large
KEM using the approaches above when compared with a KEM (if its public key
and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq
signature algorithm has a small signature and a small public key) which
would work well in a normal IKEv2's implementation ? 

> I guess the impact is small generally because an IPsec tunnel normally
stays up for a long time. Does my guess seem ok here ?

> Would there be some noticeable impact on a high-volume connections VPN
server ?

 

We tested this in the context of TLS in https://eprint.iacr.org/2020/071.
For a tunnel that stays up for a long time (not just a few seconds like
HTTPS) and sends Megabytes of data or more, then the larger key+signatures
size are amortized over the tunnel data. What becomes more important then is
the keygen, encap, decap, sign/verify time. 

 

In other words, servers that terminate a lot of connections at the same time
will be impacted by slower operations in the handshake (the server
throughput drops), but their tunnels that send a few more kilobytes of
handshake data and magnitudes more over the tunnel are not significantly
affected especially if we are talking about UDP and not TCP (with congestion
control slowing down the handshake). 

 

 

 

From: IPsec  On Behalf Of Dang, Quynh H. (Fed)
Sent: Wednesday, June 17, 2020 12:37 PM
To: Valery Smyslov ; 'ipsecme mailing list'

Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?

 

Thank you Valery and thank you everyone who responded to me.

 

The approaches in the drafts
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-
1.1  and
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look
good to me.

 

It looks like if/when someone implements them and adds a large key and/or
ciphertext KEM, the maximum IKEv2 message size must be adjusted if the
existing implementation does not already support the corresponding message
size with the new KEM ( for an ephemeral key exchange, it contains a public
key and a ciphertext) because I don't see any mentioning of the maximum
IKEv2 message size (it is an implementation specific issue). 

 

Let's say after 10 or 15 years from now, the group trusts the security of
some PQ KEM and signature algorithms and would like to use them in normal
IKEv2 without the 2 methods above.

 

In that situation, if the KEM has large public key and/or ciphtertext would
have the IP fragmentation and packet drop issues. So, this KEM should use
the approaches in the drafts above to deal with these issues. 

 

An obvious question is that what is the performance impact from this large
KEM using the approaches above when compared with a KEM (if its public key
and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq
signature algorithm has a small signature and a small public key) which
would work well in a normal IKEv2's implementation ? 

 

I guess the impact is small generally because an IPsec tunnel normally stays
up for a long time. Does my guess seem ok here ?

 

Would there be some noticeable impact on a high-volume connections VPN
server ?

 

Regards,

Quynh. 


 
draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the
IKEv2 Protocol

This documents defines a new exchange, called Intermediate Exchange, for the
Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used
for transferring large amount of data in the process of IKEv2 Security
Association (SA) establishment. Introducing Intermediate Exchange allows
re-using existing IKE Fragmentation mechanism, that helps to avoid IP
fragmentation of large IKE ...

tools.ietf.org

 

 

 

  _  

From: Valery Smyslov mailto:smyslov.i...@gmail.com>
>
Sent: Wednesday, June 17, 2020 9:57 AM
To: Dang, Quynh H. (Fed) mailto:quynh.d...@nist.gov>
>; 'ipsecme mailing list' mailto:ipsec@ietf.org> >
Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? 

 

Hi Quinh,

 

please look at the  draft-ietf-ipsecme-ikev2-multiple-ke-00.

It specifically addresses your concern about large public keys of PQ KE
methods.

 

Actually, it's generally OK to have public keys/signatures up to 64Kbytes.

If you need to deal with larger keys, then some update of the specs is
needed.

 

Regards,

Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt

[Panos Kampanakis (pkampana)]

Hello, 
This iteration addresses all feedback received in the IESG Review. 
Thanks to Alissa, Adam, Barry, Alexey, Mijra, Roman, Martin and Eric for
their reviews. 
Rgs,
Panos


-Original Message-
From: IPsec  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, January 15, 2020 12:17 AM
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions WG
of the IETF.

Title   : Mixing Preshared Keys in IKEv2 for Post-quantum
Security
Authors : Scott Fluhrer
  Panos Kampanakis
  David McGrew
  Valery Smyslov
Filename: draft-ietf-ipsecme-qr-ikev2-11.txt
Pages   : 20
Date: 2020-01-14

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-11
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Roman,

Two more comments in addition to Valery's. 

> > ** Section 1.  Per “Recent achievements in developing quantum computers …”, 
> > is there a citation?

[I-D.hoffman-c2pq] is a good citation which we use already that talks about the 
QC concern and Grover and Shor's algorithms. So we could cite it here as well. 
Now about the latest QC advancements, the latest that I know of was Google's 
quantum supremacy one https://www.nature.com/articles/d41586-019-03224-w But 
that will change with other announcements that will come a later. So, I am 
afraid there is no good citation here other than [I-D.hoffman-c2pq]. 

> -- The definition of quantum resistant doesn’t seem exactly precise.  

There have been four terms that can be used interchangeably. Quantum-safe used 
by ETSI, post-quantum used by NIST, quantum-secure, and quantum-resistant. 
Practically all these mean algorithms that are not susceptible to a variant of 
Shor's algorithm and offer adequate classical and PQ security. NIST defines it 
as "cryptographic systems that are secure against both quantum and classical 
computers, and can interoperate with existing communications protocols and 
networks. ". I guess we could use one of the terms throughout the document. And 
we could rephrase the sentence 

  invulnerable to an attacker with a
  quantum computer.

to say something like 

   secure against classical attackers 
   of today or future attackers with a 
   quantum computer.

Rgs, 
Panos



-Original Message-
From: IPsec  On Behalf Of Valery Smyslov
Sent: Wednesday, January 08, 2020 9:42 AM
To: 'Roman Danyliw' ; 'The IESG' 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; 
draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: Re: [IPsec] Roman Danyliw's No Objection on 
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Hi Roman,

> Roman Danyliw has entered the following ballot position for
> draft-ietf-ipsecme-qr-ikev2-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/
> 
> 
> 
> --
> COMMENT:
> --
> 
> These are all editorial.
> 
> ** Section 1.  Per “Recent achievements in developing quantum 
> computers …”, is there a citation?

Do you mean a citation about achievements? I'm not sure it's easy to find a 
stable reference here, but probably Scott or David or Panos have a good one...

> ** Section 1. Per:
>If the preshared key has
>sufficient entropy and the PRF, encryption and authentication
>transforms are quantum-secure, then the resulting system is believed
>to be quantum resistant, that is, invulnerable to an attacker with a
>quantum computer.
> 
> -- The definition of quantum resistant doesn’t seem exactly precise.  
> A quantum-resistant algorithm isn’t “invulnerable to an attacker with 
> a quantum computer”, rather isn’t it instead no easier to attack than 
> with known classical architectures?

My understanding is that it's infeasible to break such a system even with a 
help of quantum computer. 
Grover's algorithm still gives an attacker equipped with QC an advantage 
comparing with classical architectures, but proper selection of algorithms and 
key lengths doesn't allow him to break the system.

It was discussed a bit during AD's review of the draft:
https://mailarchive.ietf.org/arch/msg/ipsec/8AEgzGjqsDMTUy1X0IB4JWv_zlE

And probably my co-authors will give more authoritative answer here.

> -- The first clause says the underlying primitives are quantum-secure, 
> but then says that this translated into something being 
> quantum-resistant.  I found it confusing to mix both terms (which 
> sometimes are used interchangeably)

To be frank I don't feel difference here, but again I rely on my co-authors 
here.

> ** Section 1.  Per “This document describes a way to extend IKEv2 to 
> have a similar property; assuming that the two end systems share a 
> long secret key then the resulting exchange is quantum resistant.”, I 
> stumbled over this language a bit because I wasn’t sure which property 
> you were referencing – was it the list of things in the previous 
> paragraph’s last sentence that made it “quantum-secure”?

I believe it is a property of being "quantum-secure" (or "quantum resistant").

If we change all instances of "quantum resistant" with "quantum-secure"
in the Section 1, will the text be more clear?

> ** Section 3. Per the description of modified IKEv2 key derivation:
> 
> -- Recommend explicitly 

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Mirja,

To try to answer your questions

1) You are right. This is mentioned in a paragraph below that reads 

   [...] or continue without using the
   PPK (if the PPK was not configured as mandatory and the initiator
   included the NO_PPK_AUTH notification in the request).

But for clarity we will slightly rephrase the sentence you pointed out to 

   only if using PPKs for communication with this responder
   is optional for the initiator (based on the mandatory_or_not flag), 
   then the initiator MAY include a notification NO_PPK_AUTH in the 
   above message.

2) It is a little hard to include a time that would match all situations. It 
really depends on the server DoS protection policy and when it kicks on. The 
initiator cannot really know how fast is considered too fast for the responder 
so it has to make a conservative decision. Adding a " (e.g., seconds) " would 
probably suffice here. 

3) Waiting for one or two RTTs is probably a good rule. The side-effect could 
be that the initiator stays waiting for responses for too long which delays the 
handshake. I am not sure we can mandate in absolute time because it depends on 
the relative distance between client and server. We can probably include " 
(e.g., one round-trip) " in the text. 

4) I am not sure adding one more notification for downgrade detection adds much 
here. Remember IKEv2 has subsequent messages to do IKE_AUTH etc and we wanted 
to not introduce more significant deviations on IKEv2. 

If the PPK is optional for both peers then downgrade is possible but it is the 
cost of being flexible to allow some peers to use PPK and some to not. If any 
of the peers has PPK as mandatory then downgrade will be caught and rejected as 
explained in the Sec Considerations section, so I think we are OK there. 

Rgs,
Panos

-Original Message-
From: IPsec  On Behalf Of Mirja Kühlewind via 
Datatracker
Sent: Tuesday, January 07, 2020 8:41 AM
To: The IESG 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; 
draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: [IPsec] Mirja Kühlewind's No Objection on 
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipsecme-qr-ikev2-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/



--
COMMENT:
--

1) One small question on section 3:
"if using PPKs for communication with this responder
   is optional for the initiator, then the initiator MAY include a
   notification NO_PPK_AUTH in the above message."
This does mean that NO_PPK_AUTH notification should not be sent when the 
mandatory_or_not flag indicates that PPK is mandatory, right? Or is that a 
separate configuration? Would be good to clarify in the doc!

2) Section 6 says:
"In this situation, it is RECOMMENDED
   that the initiator caches the negative result of the negotiation for
   some time and doesn't make attempts to create it again for some time,"
Would it be possible to give any hints about what "some time" means or at least 
the order of magnitude? Maybe it could be recommended to wait a couple of 
seconds? Or how long is it usually expected to take until the half-open 
connection will be expired?

3) Also here:
"then the initiator doesn't abort the
   exchange immediately, but instead waits some time for more responses
   (possibly retransmitting the request)."
How long should one wait? Probably 1-2 RTTs if the RTT is known or maybe there 
is some good max value like 500ms or 1s or more...?  Is there any risk in 
waiting too long?

3) And one high-level comment (without knowing to much details about IKEv2):
Would it be possible do a downgrade detection, meaning when non-PKK encryption 
is established the initiator would tell the responser again that it was 
initially requesting PKK, just to double-check...?


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


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Panos Kampanakis (pkampana)]

Thanks Alexey. The text will now read 

  [...] both the PPK and the PPK_ID strings be limited
  to the base64 character set, namely the 64 ASCII [RFC0020]
  characters 0-9, A-Z, a-z, + and /.


-Original Message-
From: IPsec  On Behalf Of Alexey Melnikov via
Datatracker
Sent: Tuesday, January 07, 2020 1:16 PM
To: The IESG 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov;
draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: [IPsec] Alexey Melnikov's No Objection on
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-ipsecme-qr-ikev2-10: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/



--
COMMENT:
--

Thank you for this document. One small suggestion below:

5.1.  PPK_ID format

   o  PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the
  PPK are fixed octet strings; the remaining bytes of the PPK_ID are
  a configured value.  We assume that there is a fixed mapping
  between PPK_ID and PPK, which is configured locally to both the
  initiator and the responder.  The responder can use the PPK_ID to
  look up the corresponding PPK value.  Not all implementations are
  able to configure arbitrary octet strings; to improve the
  potential interoperability, it is recommended that, in the
  PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
  to the base64 character set, namely the 64 characters 0-9, A-Z,
  a-z, + and /.

In order to avoid any doubt, I suggest you make it clear that you mean ASCII
encoding here. For this you should add a normative reference to RFC 20 in
the last quoted sentence.


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


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alissa, 

Just adding a couple more responses: 

>> I think the citation for [NISTPQCFP] should link to the actual call for
proposals.

We will add a link to the CFP pointing to
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/document
s/call-for-proposals-final-dec-2016.pdf Hopefully the URL will not change as
Paul also pointed out. 


>>future cryptographical results), below is a list of defined IKEv2 and
>>IPsec algorithms that should not be used, as they are known to
>>provide less than 128 bits of post-quantum security"

> I think that it's OK here (because the first SHOULD is normative, while
the second is just an advise of what algorithms are not secure from current
cryptographers point of view).

As authors, we require 256-bit keys (assuming Grover halves key search time
which makes it 128-bits of PQ security). Now, NIST has in their FAQs that
they consider 128-bits AES (64-bit PQ security level) good enough for a long
time because Grover cannot be parallelized. Even though we see the rationale
behind this, we feel that using 256-bit keys for this draft (128-bit PQ
security) is trivial and without extra cost so that is what implementers
should use. But we did not make this a normative "SHOULD" just to avoid
conflicting with NIST. We wanted to stay loyal to what we say in the Sec
Considerations section "while this RFC doesn't claim to give advice as to
what algorithms are secure [...]". 

Let us know if there are objections. 

Panos


-Original Message-
From: IPsec  On Behalf Of Valery Smyslov
Sent: Monday, January 06, 2020 12:40 PM
To: 'Alissa Cooper' ; 'The IESG' 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; 'David Waltermire'
; draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: Re: [IPsec] Alissa Cooper's No Objection on
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Hi Alissa,

> --
> COMMENT:
> --
> 
> I think this document should formally update RFC 7296. Was that 
> discussed in the WG?

I don't think it is necessary. This document defines an extension to IKEv2,
which is negotiated by means of exchange of notifications (a "de facto"
standard negotiation mechanism in IKEv2), so it doesn't  change anything
defined in RFC7296. An application compliant with RFC7296 will remain
compliant after this specification is (hopefully) be published as RFC.
We have a lot of extensions to IKEv2 defined they didn't update RFC7296.

> I think the citation for [NISTPQCFP] should link to the actual call 
> for proposals.

I'll let Panos or Scott comment on it.

> Section 6:
> 
> "In addition, the policy SHOULD be set to negotiate only quantum-
>resistant symmetric algorithms; while this RFC doesn't claim to give
>advice as to what algorithms are secure (as that may change based on
>future cryptographical results), below is a list of defined IKEv2 and
>IPsec algorithms that should not be used, as they are known to
>provide less than 128 bits of post-quantum security"
> 
> This paragraph mixes normative SHOULD with non-normative "should not"
> in the
> same paragraph. I was wondering if that is intentional.

I think that it's OK here (because the first SHOULD is normative, while the
second is just an advise of what algorithms are not secure from current
cryptographers point of view).

Regards,
Valery.


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


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Éric, 

To improve the IANA section a bit we followed the guidelines in RFC8126 more 
religiously and I am attaching the diff here. 

Let me know if there are more changes you would like to suggest for the IANA 
section. 

Rgs,
Panos

-Original Message-
From: IPsec  On Behalf Of Éric Vyncke via Datatracker
Sent: Friday, January 03, 2020 4:14 AM
To: The IESG 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; 
draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-qr-ikev2-10: 
(with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-qr-ikev2-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/



--
COMMENT:
--

Thank you for the work put into this document. I found it very interesting to 
read BTW. I have only one minor non-blocking comment: please read RFC 8126 to 
have a correct IANA section about "type 16435" (and others). Same applies for 
section 5.1.

I hope that this helps to improve this document or any future one of yours,

Regards,

-éric


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<<< text/html;	name="Diff_ draft-ietf-ipsecme-qr-ikev2-10.xml - draft-ietf-ipsecme-qr-ikev2-11.xml.html": Unrecognized >>>


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09

[Panos Kampanakis (pkampana)]

To make sure we mention the NIST PQ Level categorization (that will not
change as the NIST PQ Project progresses), I was thinking we could add
something in the Sec Considerations section like 

   [...] Because of
   this, the user SHOULD ensure that the post-quantum preshared key used
   has at least 256 bits of entropy, in order to provide 128 bits of
   post-quantum security.  That provides security equivalent to Level 5
   defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. 


-Original Message-
From: IPsec  On Behalf Of Paul Wouters
Sent: Thursday, December 26, 2019 12:58 PM
To: Valery Smyslov 
Cc: ipsec@ietf.org WG ; last-c...@ietf.org;
draft-ietf-ipsecme-qr-ikev2@ietf.org; 'secdir' 
Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of
draft-ietf-ipsecme-qr-ikev2-09

On Wed, 25 Dec 2019, Valery Smyslov wrote:

> Uri, I don't mind referencing NIST levels, but I'd like to first hear 
> from my co-authors,
> 
> who are definitely more experienced in cryptography and in NIST levels 
> than I am :-)

I don't think mentioning the NIST competition is useful. Per definition,
that is incomplete preliminary data.

Paul

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


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2

[Panos Kampanakis (pkampana)]

+1 on adopting draft-tjhai-ipsecme-hybrid-qske-ikev2
draft-tjhai-ipsecme-hybrid-qske-ikev2 and draft-ietf-ipsecme-ikev2-intermediate 
are essential for enabling PQ Key Exchange in IKEv2.


From: IPsec  On Behalf Of Jonathan Hammell
Sent: Sunday, November 10, 2019 7:51 PM
To: ipsec@ietf.org
Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2

I support adoption of this draft. Like others have said, there is a desire to 
have support of post-quantum key establishment in protocols such as IKEv2 so 
implementations are ready when the NIST process for algorithm standardization 
completes.

Jonathan

Tero Kivinen mailto:kivi...@iki.fi>> Sun, 03 November 2019 
22:42 UTCShow header

This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2
draft to be accepted to be WG Document. This draft has been around for
some time, and we have been discussing it in the meetings.

If you support adopting this document as WG Document, then send email
indicating your support to the ipsec@ietf.org 
mailing-list. If you
have any comments or reservations send them to the list too.

This adoption call finishes 2019-11-11.
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

[Panos Kampanakis (pkampana)]

Thanks Tobias, Valery and Stefan. 

Imo Classic McEliece is impractical for use in live key negotiations in 
protocols like TLS, IKE, SSH etc. NIST will standardize more practical and 
secure postquantum KEMs and the added complexity for McEliece is not necessary. 
I understand that others might want McEliece because they trust it more. In 
that case, I suggest the mechanism described in #6 to be a "MAY" in the draft. 

Panos



-Original Message-
From: Tobias Guggemos  
Sent: Thursday, March 28, 2019 4:37 AM
To: Panos Kampanakis (pkampana) ; Tobias Heider 
; IPsecME WG 
Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org; ste...@gazdag.de
Subject: AW: [IPsec] New Version Notification for 
draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

* PGP Signed by an unknown key

> > #4 Big Keys (e.G. Classic McEliece)
> > In general there was consensus that we should find a way to enable the use 
> > of McEliece keys.
> > The problem is that McEliece keys are >1MB in size and thus can not 
> > fit into the KE payload (which has a 16 bit size field).
> Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. 
> There are multiple candidates in the NIST PQ Project that offer pk+ct sizes 
> of a few kilobytes. It is likely that some will be standardized. Classic 
> McEliece performance seems much slower than other candidates as well. 
> Sorry I missed it, but why was it decided that supporting Classic McEliece is 
> a must? 

There is no decision made on this, at the end this is a question to be 
discussed and agreed on in the WG.
However, with McEliece being the proposal which is most trusted in the crypto 
community, there will be people wanting to support it (let it be governmental 
institutions with strict security requirements).
We had "consensus" on:
1) that the draft should support the possibility to exchange McEliece keys 
without "breaking" the protocol again. 
2) we all hope that we won't need it! =)

Correct me if I'm wrong.

> Panos

Cheers Tobias

* Unknown Key
* 0xC833559F
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

[Panos Kampanakis (pkampana)]

> #4 Big Keys (e.G. Classic McEliece)
> In general there was consensus that we should find a way to enable the use of 
> McEliece keys.
> The problem is that McEliece keys are >1MB in size and thus can not fit into 
> the KE payload
> (which has a 16 bit size field).

Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. There 
are multiple candidates in the NIST PQ Project that offer pk+ct sizes of a few 
kilobytes. It is likely that some will be standardized. Classic McEliece 
performance seems much slower than other candidates as well. Sorry I missed it, 
but why was it decided that supporting Classic McEliece is a must?

Panos


From: IPsec  On Behalf Of Tobias Heider
Sent: Wednesday, March 27, 2019 1:30 PM
To: IPsecME WG 
Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org; ste...@gazdag.de
Subject: Re: [IPsec] New Version Notification for 
draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

Hi,

we had a side meeting today where some of us shared our experiences 
implementing this
draft and we had the chance to discuss the future of this draft with the 
authors.
Here's what we have talked about and our results:

#1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:

The current draft proposes to send a pair of new nonces in every subsequent 
IKE_INTERMEDIATE exchange.
We agreed that none of us sees any obvious security problems with only using 
the nonces exchanged in
IKE_SA_INIT, but we should try to get this confirmed by cryptologists (maybe 
CFRG can help).

#2 Using a single IKE_INTERMEDIATE to transport all additional keys

One single big IKE_INTERMEDIATE message that transports all additional key 
exchanges would be enough to
allow big keys to be fragmented. The main problem of this approach is that 
fragmentation handles lost
fragments by resending all fragments. There is no way of requesting 
retransmission of a single fragment.
This may turn out to be a problem, which is why each new key is sent in a 
separate IKE_INTERMEDIATE.
Another solution might be to change fragmentation to allow retransmission of 
single fragments.

#3 Using a reserved field to avoid 7 new transform types

It was discussed whether it makes sense to use a reserved field in the 
transform substructure header
to combine transforms of the same transform type (e.g. Diffie-Hellman group) 
with logical AND instead of OR.
We agreed that the current solution is less work to implement and using the 
reserved field offers no
functional benefit.

#4 Big Keys (e.G. Classic McEliece)

In general there was consensus that we should find a way to enable the use of 
McEliece keys.
The problem is that McEliece keys are >1MB in size and thus can not fit into 
the KE payload
(which has a 16 bit size field).

The solution we came up with is fragmenting a single key over several KE 
payloads which are transmitted
in a single IKE_INTERMEDIATE message that can be fragmented over several udp 
datagrams using
IKEv2 fragmentation:

HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} -->

<-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)}


This approach is only limited by the size field of the IKEv2 header, which is 
32 bit.

#5 Rekeying and CREATE_CHILD_SA

Nonces should be handled as said in #1.
The draft does not yet specify how the new SKEYSEED is generated.
We agreed that the best way would be to do this in a single prf (different than 
in the INTERMEDIATE
exchanges which are "rekeying" incrementally), e.G. :

SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr)

The use of INFORMATIONAL exchange for the additional key exchanges was 
criticized.
Several alternative designs were discussed, here's the most important ones:

Design 1: Sending all in a single exchange:

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4}

Problems include that the initiator might generate keys that are then not 
accepted by the responder.
Also the message would probably be very big, so the same problems as in #2 
apply here.
It was discussed what happens if the responder does not accept the proposal.
As in normal IKEv2 the INVALID_KE notify can be sent by the responder and that 
CREATE_CHILD_SA
has to be redone with the new knowledge of what the responder supports.

Design 2: Single additional INFORMATIONAL

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)}

HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->
<-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4}

Implementers might have problems with the complexity of using the (link1) cookie
values as well as with the use of INFORMATIONAL for yet another thing.

Feel free to correct us or comment if we made a mistake or missed something 
important!
Thanks to everyone for joining the conversation!

Regards,
Tobias and Stefan
___
IPsec mailing list
IPsec@ietf.org

Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

[Panos Kampanakis (pkampana)]

+1 on adopting this draft. 

-Original Message-
From: IPsec  On Behalf Of Valery Smyslov
Sent: Thursday, March 14, 2019 4:38 AM
To: 'Tero Kivinen' ; ipsec@ietf.org
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

Hi,

as author of the document I (obviously) support its adoption.
It's a building block for QSKE solution (at least how the WG sees it now) so I 
think we should adopt it.

Regards,
Valery.

> This document has been stable for some time, and I think it is ready 
> to go forward. Because of that I will start one week long WG 
> adoptation call for this draft which will expire end of next week 
> (2019-03-22).
> 
> If you have any reasons why this should not be adopted as WG document, 
> send email to the list as soon as possible.
> --
> 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

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

Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.txt

[Panos Kampanakis (pkampana)]

Thanks for the detailed reviews Paul. I don't think the new text is changing 
the meaning of the text that is already there. Anyone reading either of the 
two, would be able to understand the point. Thus, I feel there is no need to 
make the new change this late in WGLC process. 
Panos

-Original Message-
From: IPsec  On Behalf Of Paul Wouters
Sent: Friday, January 18, 2019 10:22 AM
To: Valery Smyslov 
Cc: IPsecME WG ; ipsecme-cha...@ietf.org; 
david.walterm...@nist.gov
Subject: Re: [IPsec] New Version Notification for 
draft-ietf-ipsecme-qr-ikev2-06.txt


On Fri, 18 Jan 2019, Valery Smyslov wrote:

> a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted.
> It addresses Paul Wouters' comment about the Security Considerations text.

Thanks!

I have another minor suggested change :)

current:

Note that [RFC6023] allows to
skip creating Child SA in the IKE_AUTH exchange, so that the
supporting peers can rekey the IKE SA before any Child SA is created.
Note also that some information (identities of the peers, feature
negotiation notifications, Vendor IDs etc.) is always exchanged in
initial exchanges and thus cannot be protected from the attack
described above by performing an IKE SA rekey.

new:

It is possible to create a childless IKE SA in IKE_AUTH as specified in 
[RFC6023]. This prevents Child SA configuration information from being 
transmited in the original IKE SA that is not protected by a PPK. Information 
in the initial IKE_INIT and IKE_AUTH exchanges, such as peer identities, 
feature notifications and Vendor ID's cannot be hidden from the attack 
described above, even if the additional IKE SA rekey is performed. Although 
this information would also be available to a Man-in-the-middle attacker 
without a quantum computer.

This removes the two "note" from sentences which make them less easy to read, 
and quantifies the leaked information a bit in the context of a simple MITM, 
non-quantum attack. It explains a bit better why there isn't a strong reason to 
try and hide the peer identities and VIDs from attackers with quantum computers.

Paul

___
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] Verification of IKEv2 PPK

[Panos Kampanakis (pkampana)]

Hi Hammell,

This is interesting. Thank you for doing this work to systematically confirm 
the logic and the state machine of the protocol update. 

You assumptions are correct. 
- The Have_PPK indeed means we have a PPK configured for the PPK_ID sent in the 
initiator's notification.
- The PPK Mandatory indeed is there to prevent downgrades when configured but 
also allow for backwards compatibility when disabled.

Rgs,
Panos


-Original Message-
From: IPsec  On Behalf Of Hammell, Jonathan F
Sent: Thursday, November 01, 2018 2:43 PM
To: 'ipsec@ietf.org' 
Subject: [IPsec] Verification of IKEv2 PPK

Classification: UNCLASSIFIED

Researchers at the Canadian Centre for Cyber Security (CCCS) have modeled the 
state machine of the IKEv2 PPK I-D draft-ietf-ipsecme-qr-ikev2-04 in order to 
verify the logic.  

The attached file qr_ppk_responder.smv contains a model written for NuSMV 
(http://nusmv.fbk.eu) of an asynchronous finite-state machine modelling the 
responder role described in the I-D. The file also contains CTL specifications 
of the 7 conditions presented in the table on page 8 of the draft.

To run, please install a recent version of NuSMV and run the command

   ./NuSMV qr_ppk_responder.smv

The output shows the results of the application of the CTL specifications to 
the model. 

We also include several CTL sanity checks for the model, but they are currently 
disabled in order to be clear about the claims.


Comments about the implementation of the draft:

The table on page 8 was found to be essential in developing a working model.. 
Several of the table conditions needed some interpretation and we hope ours is 
correct.

"Have PPK"
 
Our interpretation was that "Have PPK" specifies whether a Responder shared a 
valid PPK with an Initiator. We noted that in order for determination to be 
made whether he did nor not, the Responder would first need to receive an ID 
either in the PPK_IDENTITY notification or from the IDi payload (if configured 
to do so), and then check whether the ID was known and if it was whether or not 
a PPK was configured for this ID. 

In our implementation for example, we modelled that a Responder shared a PPK 
with the initiator with the condition:

 NOTIFY.PPK_ID = TRUE & VERIFY.PPK_ID_KNOWN =TRUE 

Which states that a PPK_ID notify was received and that the ID from the notify 
was known 

Equivalently he could use the ID from the Idi payload if configured 
appropriately, which is expressed as follows

 NOTIFY.PPK_ID = TRUE & VERIFY.PPK_ID_KNOWN = FALSE & VERIFY.PAYLOAD_ID_KNOWN = 
TRUE & CONFIG.USE_ID_PAYLOAD = TRUE 

In both cases after a successful ID check, they will then check whether they 
actually share a PPK i.e  VERIFY.HAVE_PPK = TRUE



"PPK Mandatory"
Our interpretation is that PPK Mandatory limits successful completion of the 
handshake to cases where the parties share a PPK, in this case no downgrade is 
possible. 

The check occurs after a successful ID check and at the same time as the check 
to see if they share a PPK. If it is mandatory, the only non-error path is when 
they share a PPK.

 CONFIG.PPK_MANDATORY = TRUE & VERIFY.HAVE_PPK = TRUE


If you have comments/questions, reply to the list or we can chat in Bangkok..

Jonathan Hammell
Canadian Centre for Cyber Security
https://cyber.gc.ca

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-01.txt

[Panos Kampanakis (pkampana)]

This draft incorporates some minor text fixes, nits, small updates and 
PPK_SUPPORT notification is changed to USE_PPK to better reflect its purpose. 

It also includes two more important changes 
- Clarified using PPK in case of EAP authentication. It follow the same 
rational as IKE_AUTH in the last version of the draft.
- prf is replaced with prf+ for the SK_d and SK_pi/r calculations. That is done 
to accommodate potential user cases where the prf output size is not equal to 
the preferred key size. 

We think this draft is ready for LC, after the two above changes are reviewed. 

Panos



-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Thursday, December 21, 2017 11:00 AM
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of 
the IETF.

Title   : Postquantum Preshared Keys for IKEv2
Authors : Scott Fluhrer
  David McGrew
  Panos Kampanakis
  Valery Smyslov
Filename: draft-ietf-ipsecme-qr-ikev2-01.txt
Pages   : 18
Date: 2017-12-21

Abstract:
   The possibility of Quantum Computers pose a serious challenge to
   cryptography 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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-01
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt

[Panos Kampanakis (pkampana)]

Hi Paul,

This draft merges all suggestions and addresses all issues brought up for the 
previously draft-fluhrer-qr-ikev2 draft. It includes many changes for 
readability and some new insightful Security Considerations. It does include 
the optional  NO_PPK_AUTH Valery brought up to solve the cases where a PPK_ID 
is not  configured for a responder. For more details Check out the -05 changes 
in the Changes section. 

We think it is more complete now and closer to finalization. 

Further feedback appreciated.

Rgs, 
Panos


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Thursday, October 19, 2017 7:48 PM
To: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt

Did it not get marked as replacing the fluhrer draft ? Now there is no diff 
available. Can that still be fixed?

Sent from my iPhone

> On Oct 19, 2017, at 17:59, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions WG of 
> the IETF.
> 
>Title   : Postquantum Preshared Keys for IKEv2
>Authors : Scott Fluhrer
>  David McGrew
>  Panos Kampanakis
>  Valery Smyslov
>Filename: draft-ietf-ipsecme-qr-ikev2-00.txt
>Pages   : 16
>Date: 2017-10-16
> 
> Abstract:
>   The possibility of Quantum Computers pose a serious challenge to
>   cryptography 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-00
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-00
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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

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

Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

[Panos Kampanakis (pkampana)]

Thank you Derrel.

Getting to this a little late. 

All your comments will be addressed in the next iteration. 

We will add some clarification text to clear up your points about rfc6023. 
About rfc6030 we will make clear that this out of scope of this doc or IKE, but 
it will just be an informative reference. 

Panos


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Derrell Piper
Sent: Friday, August 18, 2017 4:56 PM
To: ipsec@ietf.org WG 
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Notes on draft-fluhrer-qr-ikev2-04, mostly nits:

pp. 1
"...pose a serious challenge to cryptography algorithms [deployed?] widely 
today."

pp. 2
"when might one be implemented" -> "when one might be implemented"

pp. 3
The Changes section wording confuses me.  Does that mean, relative to the last 
draft?  Or does it mean those were the change in -03?

pp. 4
"...then it must check if has a..." -> "...if it has a..."

pp. 8

"Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin"

RE: rfc6030, any chance we can not refer to an RFC with XML in it?  I strongly 
object to XML.  Does IKEv2 reference any XML?  (sticks fingers in ears...)

pp. 9

RE: rfc6023 text

I would prefer text here that suggests exactly how to achieve post-quantum ID 
confidentiality.  This is vague and that means people will implement it all 
over the map.  I also don't think Child SAs should ever have been made 
mandatory, so refering to rfc6023 is fine.

Overall, I think this document should advance.  This is nice and simple, more 
or less.

Derrell

___
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] draft-fluhrer-qr-ikev2 AUTH issue

[Panos Kampanakis (pkampana)]

Valery,
It is a good idea. A new optional notification that includes the auth_data as 
it would be calculated without the PPK would work. With that, the corner case 
of ' PPK_id configured on initiator but missing on the responder' is addressed. 
There is an additional cost of the extra notification message for every 
initiator that has no-mandatory ppk configured for the responder. In the worst 
case scenario the responder would need to go through looking up the PPK_id and 
if that fails then authenticate the auth_data. Even though it is slightly more 
work for the responder, I don't consider that heavy processing that would 
introduce attack concerns. 

My concerns is that we might be making it too complicated by potentially 
introducing two separate SK_p's. From an ops perspective, if we stated the rule 
that when we want to go postquantum a PPK should be populated on the responder 
first as Graham and others suggested, then the extra complication of a new 
notification can be avoided. Violation of that rule would lead to IKE_AUTH 
failure for that initiator only.

Vukasin,
Any thoughts from an implementer's standpoint? 

Panos


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov
Sent: Monday, August 21, 2017 10:25 AM
To: Scott Fluhrer (sfluhrer) ; 'Paul Wouters' 
; ipsec@ietf.org
Cc: 'Vukasin Karadzic' 
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Hi Scott, 

> > then it has to flip a coin on whether or not to send the PPK_SUPPORT 
> > notify and if it guessed wrong, the AUTH payload on the initiator 
> > will be wrong. Sending the notify commits to using a PPK because the 
> > initiator uses it as input to the AUTH payload.

[...]

> > One way of solving this could be to allow PPK_SUPPORT to have some 
> > notify data, which could for instance be a hash of the 
> > connection/group name used by the responder.
> > Another option is to use the PPK as one of the inputs to some hash 
> > algorithm as PPK_SUPPORT data, so the responder can go through its 
> > list of PPKs to match it back to a connection/group. But we would 
> > need to be sure that this does not open up the PPK to attacks 
> > (classic and
> > quantum)
> 
> That's what we did in our original proposal (actually, it was a 
> function of the PPK itself).  The problems with that were:
> 
> - If we made it a nondeterministic function (that is, include a 
> randomizer), then the server had to do a linear scan over all their known 
> PPKs to find the matching one.
> 
> - If we made it a deterministic function, then someone listening in 
> can trivially determine when we're reusing the same PPK
> 
> (There's also a minor issue of "which hash function to use"; we haven't 
> negotiated any at this time).
> 
> A linear scan over possibly 10,000 PPKs was considered unacceptable.  
> One of our proposals even allowed the server to specify the trade-off between 
> the above two; that was considered too complex.
> 
> I'm not thrilled with Tero's answer of "lets be careful about the 
> order we upgrade things in complex networks", but I don't know how to 
> better solve it without adding lots of complexity to the protocol, potential 
> anonymity leaks or requiring significant computation on the server side.

One (relatively) simple solution would be the following.

If initiator is configured with PPK, but at the same time its policy marks 
using PPK as optional, then the initiator can send two authenticators - one 
using SK_pi' and the other using SK_pi (where SK_pi = prf(PPK, SK_pi')). The 
one, computed using SK_pi (where PPK is involved) is placed in AUTH payload, 
and the other, computed using SK_pi' (without PPK) is placed in a new optional 
status notification NO_PPK_AUTH.

   Initiator   Responder
   --
   HDR, SK {IDi, [CERT,] [CERTREQ,]
   [IDr,] AUTH, SAi2, TSi, TSr, 
   N(PPK_IDENTITY)(PPK_id), 
  [N(NO_PPK_AUTH)(auth_data)] }  --->

When responder receives this message and cannot find the corresponding PPK 
based on PPK_id and is configured to allow PPK-less SA, it can still 
authenticate initiator by using the content of NO_PPK_AUTH. 
In this case the Responder replies with the IKE_AUTH response lacking 
PPK_IDENTITY to let the initiator know that AUTH payload is computed as per 
RFC7296 (using SK_pr', i.e. without using PPK).

<---   HDR, SK {IDr, [CERT,]
   AUTH, SAr2, TSi, TSr} 

If the responder has the corresponding PPK, then it computes its AUTH payload 
using SK_pr and includes PPK_IDENTITY notification:

<---   HDR, SK {IDr, [CERT,] 
   AUTH, SAr2, TSi, TSr, 
   N(PPK_IDENTITY)(PPK_id)} 

This solution allows peers to communicate in different settings and to enforce 
their own policy.
For instance, if the initiator is configured to always use PPK, it won't 
include NO_PPK_AUTH at all. If responder is 

Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

[Panos Kampanakis (pkampana)]

Good point Paul. The issue will also hold for an initiator. The initiator might 
have PPK enabled with other peers but not have a PPK_id configured for a 
responder after he gets her IKE_INIT response with N(PPK_SUPPORT) included. 
Practically the N(PPK_SUPPORT) is dictated by a global PPK support 
configuration on the initiator and responder, but that does not mean a PPK is 
configured for all their peers.

As Tero and Scott suggested, for the shake of simplicity it makes sense to 
tighten the text with normative language to make it clear to an implementer. 
For an initiator with PPK enabled but no PPK_id, regular IKE should be included 
in the initiators IKE_AUTH message. For the responder, imo a failure should 
occur after the initiator's IKE_AUTH if a PPK_id doesn't exist and PPK is 
enabled in the responder. And optionally the responder could add the initiator 
in a no_PPK_supported local cache.  

Rgs,
Panos


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Wednesday, August 16, 2017 10:16 PM
To: ipsec@ietf.org WG 
Cc: Vukasin Karadzic ; Scott Fluhrer (sfluhrer) 

Subject: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue


Hi,

Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2 for 
libreswan and stumbled upon a problem. The relevant text:

When the initiator receives this reply, it checks whether the
responder included the PPK_SUPPORT notify.  If the responder did not,
then the initiator MUST either proceed with the standard IKE
negotiation (without using a PPK), or abort the exchange (for
example, because the initiator has the PPK marked as mandatory).  If
the responder did include the PPK_SUPPORT notify, then it selects a
PPK, along with its identifier PPK_id.  Then, it computes this
modification of the standard IKE key derivation:

A responder answering an IKE_INIT containing PPK_SUPPORT needs to reply without 
knowing for which connection this IKE_INIT will be.

The responder has not yet received the initiator's ID. If the responder has 
some connections that require a PPK and some connections that require NO PPK, 
then it has to flip a coin on whether or not to send the PPK_SUPPORT notify and 
if it guessed wrong, the AUTH payload on the initiator will be wrong. Sending 
the notify commits to using a PPK because the initiator uses it as input to the 
AUTH payload.

So this table from the RFC is incomplete:

This table summarizes the above logic by the responder

  Received PPK_SUPPORT  Have PPK   PPK MandatoryAction
  --
   No  No  *Standard IKE protocol
   No Yes NoStandard IKE protocol
   No YesYesAbort negotiation
  Yes  No  *Standard IKE protocol
  Yes Yes  *Include PPK_SUPPORT

Basically, we are in the case where "Have PPK" is not yet known.


One way of solving this could be to allow PPK_SUPPORT to have some notify data, 
which could for instance be a hash of the connection/group name used by the 
responder. Another option is to use the PPK as one of the inputs to some hash 
algorithm as PPK_SUPPORT data, so the responder can go through its list of PPKs 
to match it back to a connection/group. But we would need to be sure that this 
does not open up the PPK to attacks (classic and quantum)

Paul

___
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] Proposed text for the draft-fluhrer-qr-ikev2

[Panos Kampanakis (pkampana)]

Thank you for the text Valery. We appreciate it.
We might reorganize it in a section that basically talks about PPKs, PPK 
Distribution and PPK operations. The changes will go in the next iteration. As 
discussed in Prague we will try to have normative language to make clear that 
null auth is not recommended and that the caveats of using group PPKs. 
Panos


-Original Message-
From: Valery Smyslov [mailto:sva...@gmail.com] 
Sent: Thursday, July 27, 2017 10:39 AM
To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; David McGrew (mcgrew) 
<mcg...@cisco.com>; Panos Kampanakis (pkampana) <pkamp...@cisco.com>
Cc: ipsec@ietf.org
Subject: Proposed text for the draft-fluhrer-qr-ikev2

Hi,

at the ipsecme meeting in Prague I was asked to contribute a text for the 
draft-fluhrer-qr-ikev2 about operational considerations.
Here is my try. I think the text should be placed into a new section, 
"Operational Considerations". Any thoughts?

Regards,
Valery.


X. Operational Considerations

This document provides a solution that doesn't replace classical public key 
cryptographic mechanisms used in IKEv2, like (EC)DH or digital signatures . 
Instead, the proposed solution extends these mechanisms by using an additional 
security credential, namely PPK, to make IKEv2 secure against Quantum 
Computers. In practice it means, that each peer must possess two security 
credentials to successfully complete authentication - a classic one (like 
certificate private key) and a PPK. 

The need to maintain several independent sets of security credentials can 
significantly complicate security administrators job, and can potentially slow 
down widespread adoption of this solution. It is anticipated, that 
administrators will try to simplify their job by decreasing the number of 
credentials they need to maintain. Two possible approaches are given below. 

X.1 Group PPK

This document doesn't explicitly require that PPK is unique for each pair of 
peers.
If it is the case, then this solution provides full peer authentication, but it 
also means that each host must have that many independent PPKs, how many peers 
it is going to communicate with. As the number of hosts grows this will scale 
badly.

It is possible to use a single PPK for a group of users. Since each peer uses 
classical public key cryptography in addition to PPK for key exchange and 
authentication, members of the group can neither impersonate each other nor 
read other's traffic, unless they use Quantum Computers to break public key 
operations. 

Although it's probably safe to use group PPK in short term, the fact, that the 
PPK is known to a (potentially large) group of users makes it more susceptible 
to a theft. If an attacker equipped with a Quantum Computer get access to a 
group PPK, then all the communications inside the group are revealed.

X.2 PPK-only Authentication

If Quantum Computers become a reality, classical public key cryptography will 
provide little security, so administrators may find it attractive not to use it 
at all for authentication. This will reduce the number of credentials they need 
to maintain to PPKs only.

PPK-only authentication can be achieved in IKEv2 if NULL Authentication method 
[RFC7619] is employed. Without PPK the NULL Authentication method provides no 
authentication of peers, however since PPK is stirred into SK_pi and SK_pr, the 
peers become authenticated if PPK is in use. Note, that using PPK MUST be 
mandatory for both Initiator and Responder if PPK-only authentication (i.e. the 
NULL Authentication method + PPK) is employed.

Combining group PPK and PPK-only authentication is NOT RECOMMENDED, since in 
this case any member of the group can impersonate any other member even without 
help of Quantum Computers.




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

Re: [IPsec] New charter proposal

[Panos Kampanakis (pkampana)]

+1 

Tero, 
Waiting for your IKEv2 quantum resistance slides to become available, as a 
great summary of the potential requirements.




-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
Sent: Wednesday, July 20, 2016 12:56 PM
To: Valery Smyslov 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New charter proposal

Valery Smyslov writes:
> > - Add Quantum Resistance for IKEv2 as new work item with milestone 
> > as  Feb 2017 for IETF LC.
> 
> This milestone looks a bit optimistic for me. 
> Otherwise the updated chapter looks good.

The limited resistance we are talking about is in the same level of protection 
which IKEv1 has, i.e., PPK. We are not yet talking about doing using any 
quantum resistant protocols to generate the PPK, we just assume that the PPK 
comes through some out of band method and we can want to make sure we use it in 
the protocol in the way that makes
IKEv2 quantum resistant in a way that traffic stored now using this extension 
cannot be decrypted after the quantum computers are there, and attackers can 
break Diffie-Hellman done in IKEv2.

I.e., the actual work item is:

IKEv1 using shared secret authentication was partially resistance to quantum 
computers. IKEv2 removed this feature to make the protocol more usable. The 
working group will add a mode to IKEv2 or otherwise modify IKEv2 to have 
similar quantum resistant properties than IKEv1 had.

and I think we should be able to finish that in WG in the next 6 months.  
--
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] NIST question concerning IKEv2 and quantum resistance

[Panos Kampanakis (pkampana)]

Hi Ray,

Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first 
take of QC resistant IKEv2. It is still in its early stages and has not been 
adopted as any WG's item yet.

Feedback is welcome.

Rgs,
Panos



From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Perlner, Ray
Sent: Wednesday, January 06, 2016 3:33 PM
To: ipsec@ietf.org
Cc: Liu, Yi-Kai ; Moody, Dustin ; 
Frankel, Sheila E. ; Waltermire, David A. 

Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance

Hi all.

NIST is investigating quantum-resistant alternatives to presently standardized 
public-key algorithms. We are reaching out to the IPSec working group to 
determine if there are any unique needs associated with trying to add 
quantum-resistance to IKEv2, which currently only uses variants of the 
Diffie-Hellman key exchange.

We believe a number of the properties of the Diffie-Hellman construction (such 
as perfect forward secrecy) can be met using generic constructions based on 
standard cryptographic primitives and security models (such as IND-CCA2 
encryption and EUF-CMA signature) as long as key generation times are fast. If 
IKEv2 can accommodate such generic constructions, there are likely to be many 
proposals to choose from. However, there are some additional properties of the 
Diffie-Hellman exchange which may be difficult to duplicate (such as the 
property that the responder can compute his key exchange message without seeing 
the initiator's key-exchange message) and it's not as clear to us what the 
security model for a key exchange replacing DH should be.

So in summary, we would like to answers to the following questions:

1)  Can IKEv2 can be modified to replace the Diffie-Hellman exchange with a 
generic construction based on standard encryption, signature, and PRF 
primitives?

2)   If not, what specific security and correctness requirements should we 
target to meet the need?

Thanks,
Ray





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