Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Tommy Pauly]

I think we should definitely add a discussion around this to the Berlin agenda.

>From our end, we definitely want to see some measures to add quantum 
>resistance into IKEv2 to promote the adoption of IKEv2 over IKEv1 for clients 
>that are concerned. I think draft-fluhrer-qr-ikev2 provides a good starting 
>point for a WG document to do that. I agree that we can defer some of the 
>complexities around ID hiding to later solutions, in the interest of 
>simplicity and providing basic QR in the short term.

Thanks,
Tommy Pauly
Apple

> On Jul 4, 2016, at 9:40 AM, Paul Wouters  wrote:
> 
> On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote:
> 
>> Actually, the draft is a bolt-on to existing authentication methods;
> 
>> You might object "how is this different from a having a possibly global 
>> authentication key";
> 
>> Because of this, it wouldn't appear to be advisable to wait for the full 
>> solution; for people who are concerned about Quantum Computers, it would be 
>> appropriate to have a short term solution.  In my mind, it's OK if the short 
>> term solution doesn't address all possible scenarios; it's sufficient if it 
>> provides a way to address the immediate need for those people who are 
>> concerned.
> 
> In that case, I feel we are back at making a much simpler solution of
> providing a key identifier that leads to an additional mixing in of
> SKEYSEED generation. And not add methods of ID hiding. And have
> something that can be tested by implementations using a shared OTP.
> 
> If the people discussing this will be in Berlin, perhaps we should put
> this on the agenda to discuss?
> 
> 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] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Wouters]

On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote:


Actually, the draft is a bolt-on to existing authentication methods;



You might object "how is this different from a having a possibly global 
authentication key";



Because of this, it wouldn't appear to be advisable to wait for the full 
solution; for people who are concerned about Quantum Computers, it would be 
appropriate to have a short term solution.  In my mind, it's OK if the short 
term solution doesn't address all possible scenarios; it's sufficient if it 
provides a way to address the immediate need for those people who are concerned.


In that case, I feel we are back at making a much simpler solution of
providing a key identifier that leads to an additional mixing in of
SKEYSEED generation. And not add methods of ID hiding. And have
something that can be tested by implementations using a shared OTP.

If the people discussing this will be in Berlin, perhaps we should put
this on the agenda to discuss?

Paul

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Monday, July 04, 2016 5:44 AM
> To: Yoav Nir
> Cc: ipsec@ietf.org; Mark McFadden
> Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME
> WG document
> 
> On Sun, 3 Jul 2016, Yoav Nir wrote:
> 
> >> 3) The Internet Draft Currently under consideration is not the best 
> >> starting
> point as it assumes that post-quantum pre-shared keys are the preferred
> solution for quantum resistance. This is not obviously the case; there are a
> number of drawbacks with the suggested system:
> >
> > I think this misstates the problem that the draft is trying to solve. The 
> > draft
> is not a solution to the problem of authenticating peers in a world where
> adversaries have quantum computers. The draft is a solution to the problem
> of authenticating peers *using pre-shared keys* in such a world. There may
> be different solutions for authenticating peers with other credentials.

Actually, the draft is a bolt-on to existing authentication methods; the 
authentication method uses is the new 'postquantum preshared keys' plus 
whatever IKEv2 authentication mechanism that the peers use.  For example, you 
can use certificates to authenticate; the draft assumes there's also a shared 
secret that the peers have.

You might object "how is this different from a having a possibly global 
authentication key"; the answer here is that this postquantum preshared key 
isn't making anything worse; if the adversary learns the ppk, they still can't 
break in (unless they also break the existing IKEv2 authentication mechanism).

So:
- An adversary can't break confidentiality unless they learn the ppk AND they 
can break the IKEv2 key exchange (such as with a Quantum Computer).
- An adversary can't break authentication unless they learn the ppk AND they 
can break the existing IKEv2 authentication mechanism.


Going to the broader topic, I agree that it would be preferable to have a 
postquantum solution that would work in all cases, without assuming a 
distributed secret.  However, in general, this would require a postquantum key 
exchange, and that's the rub; we're not there yet.  We have McEliece (which 
requires huge keys; key shares if we use it to do key exchange), we have NTRU 
(which some people don't trust), and they we have a large number of more recent 
schemes discovered in the last 5 years or so (and so haven't had enough time to 
be cryptographically vetted).

Now, eventually we'll come up with a scheme which is both deployable and has a 
reasonable amount of trust; however that'll be a few years from now.

On the other side, we can look at the need; no one really knows when a viable 
quantum computer (which can break the DH and ECDH groups that we use) will be 
built; the guesses that I've heard is that it might be in 10-15 years (maybe).  
That would make it sound like we have time, except that when a quantum computer 
does become available, then someone will be able to decrypt previously recorded 
sessions; this might mean that, in 10 years, someone might be able to decrypt 
encrypted traffic from today.

Because of this, it wouldn't appear to be advisable to wait for the full 
solution; for people who are concerned about Quantum Computers, it would be 
appropriate to have a short term solution.  In my mind, it's OK if the short 
term solution doesn't address all possible scenarios; it's sufficient if it 
provides a way to address the immediate need for those people who are concerned.


> 
> That was not clear to me when we were asking for adoption of the
> document. In one way, I have less issues with it if the document can clearly
> state that is the scope of it. On the other hand, we might want to have a
> discussion about the security of PSK in general, and whether the method
> deserves to be obsoleted completely because of its continued weak
> deployments (eg see Snowden leaks)
> 
> > However, with my vendor hat on, I know that PSKs are used extensively
> (and nobody’s asking me whether this is a good idea or not), and I have
> heard that some users are beginning to ask questions about quantum
> resistance.So I believe that there is a problem to solve here.
> 
> I can see that point. As vendor it is hard to tell people not to do a certain
> deployment because it is seen as "easiest". However with our IETF protocol
> designer hats on, this should not be a strong argument.

If we think that this WG should have a long term goal of designing a protocol 
that is easy to use securely, and is postquantum secure, I would agree that's a 
fine idea.  However, that's a long term goal; I would claim that we shouldn't 
ignore the short term requirements as well.


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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Valery Smyslov]

The draft provides postquantum protection to any SA, regardless
of the authentication methods used. In other words, PPKs (as specified in the 
draft)

don't replace preshred keys authentication in IKEv2, they augment
any authentication method to provide postquantum security.


 The original title to me reads like a "new feature" instead of like a
 "fix for old feature".



But then PaulH is wrong and this draft is a lot more then fixing just
IKEv2 PSK for postquantum.


Doesn't this new feature fixes IKEv2 preshared key auth?
I don't think PaulH is wrong, this draft just offers a bit more.


Paul


Valery.

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Wouters]

On Mon, 4 Jul 2016, Valery Smyslov wrote:

>  Isn't this kinda off-topic for the thread? I though we were first 
>  considering "create an IKEv2 extension that mixes in the PSK" as the 
>  simplest way to get around the "go back to IKEv1" guidance.


 So that was not entire clear to me from the title, but it seems you are
 right.

 Perhaps we can change the title from:

   Postquantum Preshared Keys for IKEv2

 to:

  Postquantum protection for IKEv2 Preshared Keys SA's


That's incorrect title. The original title is correct.

The draft provides postquantum protection to any SA, regardless
of the authentication methods used. In other words, PPKs (as specified in the 
draft)

don't replace preshred keys authentication in IKEv2, they augment
any authentication method to provide postquantum security.


 The original title to me reads like a "new feature" instead of like a
 "fix for old feature".



But then PaulH is wrong and this draft is a lot more then fixing just
IKEv2 PSK for postquantum.

Paul

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Valery Smyslov]

Hi Paul,

Isn't this kinda off-topic for the thread? I though we were first considering 
"create an IKEv2 extension that mixes in the PSK" as the simplest way to get 
around the "go back to IKEv1" guidance.


So that was not entire clear to me from the title, but it seems you are
right.

Perhaps we can change the title from:

  Postquantum Preshared Keys for IKEv2

to:

 Postquantum protection for IKEv2 Preshared Keys SA's


That's incorrect title. The original title is correct.

The draft provides postquantum protection to any SA, regardless
of the authentication methods used. In other words, PPKs (as specified in the 
draft)
don't replace preshred keys authentication in IKEv2, they augment
any authentication method to provide postquantum security.


The original title to me reads like a "new feature" instead of like a
"fix for old feature".


I think it is more like a new feature.

Regards,
Valery.


Paul


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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Yoav Nir]

On 4 Jul 2016, at 12:44 PM, Paul Wouters  wrote:

> On Sun, 3 Jul 2016, Yoav Nir wrote:
> 
>>> 3) The Internet Draft Currently under consideration is not the best 
>>> starting point as it assumes that post-quantum pre-shared keys are the 
>>> preferred solution for quantum resistance. This is not obviously the case; 
>>> there are a number of drawbacks with the suggested system:
>> 
>> I think this misstates the problem that the draft is trying to solve. The 
>> draft is not a solution to the problem of authenticating peers in a world 
>> where adversaries have quantum computers. The draft is a solution to the 
>> problem of authenticating peers *using pre-shared keys* in such a world. 
>> There may be different solutions for authenticating peers with other 
>> credentials.
> 
> That was not clear to me when we were asking for adoption of the
> document. In one way, I have less issues with it if the document
> can clearly state that is the scope of it. On the other hand, we
> might want to have a discussion about the security of PSK in general,
> and whether the method deserves to be obsoleted completely because
> of its continued weak deployments (eg see Snowden leaks)

We can have that discussion. Or we can resign ourselves to designing protocols 
to fill requirements imposed by other people.

Yoav

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Wouters]

On Sun, 3 Jul 2016, Paul Hoffman wrote:


On 3 Jul 2016, at 11:32, Paul Wouters wrote:


>  On Jul 3, 2016, at 21:08, Mark McFadden  wrote:
> 
>  A number of quantum-resistant asymmetric public key algorithms have been 
>  proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny 
>  Diffie-Hellman.


 I thought NTRU was patent encumbered? Is that still the case? How about
 the others you mention?

 I agree asking CFRG for help would be a wise decision.


Isn't this kinda off-topic for the thread? I though we were first considering 
"create an IKEv2 extension that mixes in the PSK" as the simplest way to get 
around the "go back to IKEv1" guidance.


So that was not entire clear to me from the title, but it seems you are
right.

Perhaps we can change the title from:

  Postquantum Preshared Keys for IKEv2

to:

Postquantum protection for IKEv2 Preshared Keys SA's

The original title to me reads like a "new feature" instead of like a
"fix for old feature".

Paul


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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Wouters]

On Sun, 3 Jul 2016, Yoav Nir wrote:


3) The Internet Draft Currently under consideration is not the best starting 
point as it assumes that post-quantum pre-shared keys are the preferred 
solution for quantum resistance. This is not obviously the case; there are a 
number of drawbacks with the suggested system:


I think this misstates the problem that the draft is trying to solve. The draft 
is not a solution to the problem of authenticating peers in a world where 
adversaries have quantum computers. The draft is a solution to the problem of 
authenticating peers *using pre-shared keys* in such a world. There may be 
different solutions for authenticating peers with other credentials.


That was not clear to me when we were asking for adoption of the
document. In one way, I have less issues with it if the document
can clearly state that is the scope of it. On the other hand, we
might want to have a discussion about the security of PSK in general,
and whether the method deserves to be obsoleted completely because
of its continued weak deployments (eg see Snowden leaks)


However, with my vendor hat on, I know that PSKs are used extensively (and 
nobody’s asking me whether this is a good idea or not), and I have heard that 
some users are beginning to ask questions about quantum resistance.So I believe 
that there is a problem to solve here.


I can see that point. As vendor it is hard to tell people not to do a
certain deployment because it is seen as "easiest". However with our
IETF protocol designer hats on, this should not be a strong argument.

Paul

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Yoav Nir]

Hi, Mark

> On 3 Jul 2016, at 9:08 PM, Mark McFadden  wrote:



> 3) The Internet Draft Currently under consideration is not the best starting 
> point as it assumes that post-quantum pre-shared keys are the preferred 
> solution for quantum resistance. This is not obviously the case; there are a 
> number of drawbacks with the suggested system:

I think this misstates the problem that the draft is trying to solve. The draft 
is not a solution to the problem of authenticating peers in a world where 
adversaries have quantum computers. The draft is a solution to the problem of 
authenticating peers *using pre-shared keys* in such a world. There may be 
different solutions for authenticating peers with other credentials. 

In general, someone deploying an IKE/IPsec solution can choose what credentials 
to deploy. So the system administrator for the Elbonian foreign office may 
decide to deploy NTRU keys to each embassy. Or ECDSA keys. Or pre-shared 
secrets. Or short passwords.

As implementers, we don’t get to decide this. Our implementations are required 
to support whatever credentials the users either already have or wish to 
deploy. If quantum resistance becomes a requirement, implementers like me will 
need to support pre-shared keys in a quantum safe way, and it is up to this 
working group to provide a method of doing just that.

Of course, I as an implementer may decide that I don’t want to solve this 
because maybe I think quantum resistance is not an important requirement, or 
because I don’t believe people are actually using pre-shared keys. Similarly, 
the WG may decide that solving the quantum resistant PSK method is not 
important enough to work on. Or that this particular solution to this problem 
is not the right one.

However, with my vendor hat on, I know that PSKs are used extensively (and 
nobody’s asking me whether this is a good idea or not), and I have heard that 
some users are beginning to ask questions about quantum resistance.So I believe 
that there is a problem to solve here. 

Yoav

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Hoffman]

On 3 Jul 2016, at 11:32, Paul Wouters wrote:

On Jul 3, 2016, at 21:08, Mark McFadden  
wrote:


A number of quantum-resistant asymmetric public key algorithms have 
been proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny 
Diffie-Hellman.


I thought NTRU was patent encumbered? Is that still the case? How 
about the others you mention?


I agree asking CFRG for help would be a wise decision.


Isn't this kinda off-topic for the thread? I though we were first 
considering "create an IKEv2 extension that mixes in the PSK" as the 
simplest way to get around the "go back to IKEv1" guidance.


--Paul Hoffman

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Wouters]

> On Jul 3, 2016, at 21:08, Mark McFadden  wrote:
> 
> A number of quantum-resistant asymmetric public key algorithms have been 
> proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny Diffie-Hellman.

I thought NTRU was patent encumbered? Is that still the case? How about the 
others you mention?

I agree asking CFRG for help would be a wise decision.

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

[IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Mark McFadden]

Considering: draft-fluhrer-qr-ikev2

For context and a reminder, another draft proposing the use of Quantum Key 
Distribution (QKD) in IPSec was previously rejected by the group:
https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01

The draft under consideration was prompted by an interest in the group in 
introducing quantum-resistant algorithms to the IKEv2 protocol of the IPSec 
standard. It makes sense to support the move to QR algorithms but it seems 
possible that the approach  outlined in the current draft will not lead to the 
best outcome for security or usability. I would propose that the WG take a 
different approach and not adopt the current draft but instead work towards an 
alternate draft based around quantum-resistant asymmetric cryptographic 
functions.

Earlier, we had David Waltermire of NIST ask for feedback from the group on the 
following questions:

1) Previous WG discussions have indicated interest in this problem. Does the 
working group think that there is a problem here that we need to address?

2) Should we do this work in the IPsecME working group? If not, where?

3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG 
solution to this problem? If not, what is a suitable starting point instead?

I’d propose answering these as follows:

1) Yes, there is a real threat here as recognized by NIST, NSA, ETSI etc. IKEv2 
key exchanges could be recorded now and attacked in future when a quantum 
computer is available to recover the IPSec session keys.

2) It is completely appropriate for the ipsecme working group to standardize 
the IPSec protocol modifications and extensions required to provide quantum 
resistance. The choice of quantum-resistant cryptographic primitives should be 
decided by the CFRG, NIST, ETSI or other competent body.

3) The Internet Draft Currently under consideration is not the best starting 
point as it assumes that post-quantum pre-shared keys are the preferred 
solution for quantum resistance. This is not obviously the case; there are a 
number of drawbacks with the suggested system:

a) PPKs do not provide Perfect Forward Secrecy - given a quantum computer to 
recover the Diffie-Hellman shared secret, a successful attack on the PPK for 
one session compromises all other sessions using the same PPK

b) The Responder has to scan through a list of PPKs, making an AES/HMAC_SHA256 
computation for each, comparing the result against the Indicator sent in the 
Initiator's payload. Since there is no intrinsic limit to the size of the 
Responder's PPK list, this is a linear amount of work that could result in 
potentially unbounded response times.

c) An additional round-trip is introduced over and above the normal IKEv2 key 
negotiation; this will increase the latency of setting up the SA.

d) Key distribution for pre-shared-key based cryptosystems can be problematic. 
A separate PPK will normally be required for each pair of correspondents, so 
the number of keys can be quadratic, unless group PPKs are used which increases 
the risk to confidentiality. How will PPKs be generated, will both 
correspondents contribute entropy to them, or will they be supplied by a 
trusted third party?

A number of quantum-resistant asymmetric public key algorithms have been 
proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny Diffie-Hellman. 
Some of these have ephemeral keys that will allow for Perfect Forward Secrecy, 
have security proofs, don't require an additional round-trip, and would bypass 
the PPK key distribution problem. Without wanting to make a decision between 
them until they have been properly evaluated, I think the working group should 
devise a protocol that allows for the use of a quantum-resistant asymmetric 
algorithm.

Mark

Mark McFadden
Principal Consultant, Internet Infrastructure and Governance
InterConnect Communications

Mobile: +44 (0) 7792 276 904
Skype: McElmside or +44 (0) 20 7558 8105
Email: markmcfad...@icc-uk.com
Web: http://www.icc-uk.com

InterConnect Communications Ltd, Merlin House, Station Road, Chepstow, NP16 
5PB, United Kingdom.
Registered in England and Wales, company registration no. 1828673.


This e-mail has been scanned for all viruses by Star Internet.  However, 
InterConnect makes no warranty that this email is virus-free.

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