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

[Valery Smyslov]

Hi Scott,


I see the point, thank you. However AES support in hardware is not always
available, so I still think that having a single crypto primitive is better in 
this
situation.

But your explanations brings me to a conclusion, that the protocol could me
modified. Please see my logical chain.

The necessity to perform a linear serach of the ppk keys (and thus spending
some CPU power) makes a responder more succeptible to DoS attack,
because it must spend resources in response to any IKE_SA_INIT exchange
even from spoofed IP address. In this situation a sane responder would try to
defend itself sending a cookie request - this would guarantee that the
initiator is alive and the IP address is not spoofed. So, if the cookie request 
is
to be sent in most cases when the IKE_SA_INIT message contains ppk
extension anyway, then the protocol could be modified to make cookie
request mandatory in this situation. Then the IKE_SA_INIT exchange would
look like:

   HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED)  -->
<--  HDR, N(COOKIE), N(PPK_SUPPORTED, 
crypto=xxx,
random_data=zzz)

The responder selects prf (and encryption, if it is used) algorithms from the
SAi1 payload. It also supplies random_data that the initiator must use when it
encodes the ppk. The initiator computes an encoded ppk and retries the
request.

   HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY)  -->
<--  HDR, SAr1, KEr, Nr, [CERTREQ]

This variant has a disadvantage that ppk will always require an additional
round trip.
However it has the following benefits:
1. Full support for algorithms agility
2. No need to perform CPU-intensive operations until the initiator's IP is
confirmed 3. In this variant it is the responder who supplies random_data to
initiator to encode ppk,
so it is on the responder discretion how to choose them. For example,
it may precompute the encoded ppk values when it is idle, or it can
reuse random_data several times. This allow the responder to perform
the ppk search in sub-linear time in some circumstances.
4. The additional round trip requires a minimum change to IKEv2,
since cookie request must be supported anyway.

What do you think?


I like it.  Someone acting as an active server could determine if two people have the same ppk 
(by giving them the same random data); however an active server can determine their identities 
anyways, and so that's not a concern.  That does mean that we're allowing the server to make 
the trade-off between computational complexity and client privacy; if everyone else is OK with that, 
so am I.


The one part that I would ask is that the crypto=xxx be a simple field (for example, it's a 32 bit value 
in the payload), and not a more complicated payload.  My fear is that if we make that parsing 
more complex, that would add little-used complexity to the protocol (and parts of the protocol 
that are little used/tested are just havens for exploitable bugs).


By crypto=xxx I meant a generic indication of what crypto primitive(s) are to 
be used by initiator.
In your original proposal you used two primitives: encryption (AES) and prf 
(HMAC_SHA256).
If you accept my proposal then I think it is better to simplify things and use 
only one
primitive - prf (for two reasons - first now server can choose a sutable 
tradeoff between
client's privacy and the server's CPU load, and second - with generic 
encryption you
won't always get any speed benefit from using both encryption and prf). 

So I'd suggest to use only prf. In this case crypto=xxx becomes prf=xxx, where prf is a 16-bit 
integer containing one of the the values defined in IANA-IKEv2 table "Transform Type 2 - 
Pseudo-random Function Transform IDs", and the server selects it from what is present

in the initiator's SA payload in transfoms of type 2. This guarantees that the 
initiator
supports that prf (otherwise he wouldn't include it in the SA payload).
In this case the initiator would then compute prf(prf(ppk, "A"), random_bytes).

And there is no need that this selected prf is equal to the prf that is 
negotiated
later and used in all SKEYSEED etc claculations - they are not related.
The fact that they are not related simplifies their selection (for example,
you don't need to look at the local policy when selecting mutually supported
prf for ppk).

Regards,
Valery.

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

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

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Valery Smyslov [mailto:sva...@gmail.com]
> Sent: Friday, January 15, 2016 3:48 AM
> To: Scott Fluhrer (sfluhrer); Michael Richardson; ipsec@ietf.org
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
> 
> Hi Scott,
> 
> >> However, if no better solution exists I'd prefer to live with a
> >> single fixed crypto primitive, than with two. Is it possible to get
> >> rid of AES and to change the indication of the ppk to use to something like
> the following?
> >>
> >> HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)
> >>
> >> (disclaimer: I'm not a cryptographer)
> >
> > Your proposal is perfectly sound from a cryptography perspective.
> > Actually, the reason we proposed the "entry in the AES codebook"
> > approach, rather than something like the above structure, is due to
> practical reasons.
> > When the responder receives the hint, he has no idea which ppk the
> > initiator is referring to (and he doesn't know the identity yet); our
> > model is that the responder has a list of ppk's that he knows about,
> > and checks to see if the one that the initiator had is on the list.
> > It'd be nice if there was a way for the responder to search through
> > his databases of known ppk's quickly, however I don't know how to let
> > him do it in sublinear time (without leaking whether two exchanges
> > used the same ppk, which would leak information about the identities).
> > So, what we settled on is to make the linear scan for the right PPK as
> > fast as possible.  With our proposed solution, an aggressive responder
> > could have all the AES keys corresponding to the ppk preexpanded, and
> just check each potential ppk by doing one AES block encryption (or
> decryption, if they prefer); if the implementation has AES-NI, that is fairly
> fast.
> > With your proposal, they could preexpand the HMAC keys, but would
> > still need to do two SHA256 compression function evaluations.
> 
> I see the point, thank you. However AES support in hardware is not always
> available, so I still think that having a single crypto primitive is better 
> in this
> situation.
> 
> But your explanations brings me to a conclusion, that the protocol could me
> modified. Please see my logical chain.
> 
> The necessity to perform a linear serach of the ppk keys (and thus spending
> some CPU power) makes a responder more succeptible to DoS attack,
> because it must spend resources in response to any IKE_SA_INIT exchange
> even from spoofed IP address. In this situation a sane responder would try to
> defend itself sending a cookie request - this would guarantee that the
> initiator is alive and the IP address is not spoofed. So, if the cookie 
> request is
> to be sent in most cases when the IKE_SA_INIT message contains ppk
> extension anyway, then the protocol could be modified to make cookie
> request mandatory in this situation. Then the IKE_SA_INIT exchange would
> look like:
> 
>HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED)  -->
> <--  HDR, N(COOKIE), N(PPK_SUPPORTED, 
> crypto=xxx,
> random_data=zzz)
> 
> The responder selects prf (and encryption, if it is used) algorithms from the
> SAi1 payload. It also supplies random_data that the initiator must use when it
> encodes the ppk. The initiator computes an encoded ppk and retries the
> request.
> 
>HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY)  -->
> <--  HDR, SAr1, KEr, Nr, [CERTREQ]
> 
> This variant has a disadvantage that ppk will always require an additional
> round trip.
> However it has the following benefits:
> 1. Full support for algorithms agility
> 2. No need to perform CPU-intensive operations until the initiator's IP is
> confirmed 3. In this variant it is the responder who supplies random_data to
> initiator to encode ppk,
> so it is on the responder discretion how to choose them. For example,
> it may precompute the encoded ppk values when it is idle, or it can
> reuse random_data several times. This allow the responder to perform
> the ppk search in sub-linear time in some circumstances.
> 4. The additional round trip requires a minimum change to IKEv2,
> since cookie request must be supported anyway.
> 
> What do you think?

I like it.  Someone acting as an active server could determine if two people 
have the same ppk (by giving them the same random data); however an active 
server can determine their identities anyways, and so that's not a concern.  
That does mean that we're allowing the server to make the trade-off between 
computational complexity 

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

[Valery Smyslov]

Hi Scott,


Scott Fluhrer (sfluhrer)  wrote:
> - It defines the transform of the nonce from the on-the-wire version into
the
> one presented to the IKEv2 KDF (mixing in the PPK).

> - The initiator gives an indication of which PPK to use (without leaking 
any
> information about it to someone two doesn’t know the value).

> For the first use, it would be reasonable to have the initiator define a
> bitmask of the algorithms it supports, and the responder to select one

That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
IANA values for all the algorithms involved? (shouldn't we have them)


The 'bitmask idea' was off the top of my head; we could certainly give a list of
IANA values (such as the IKEv2 PRF).  My chief fear is that we don't 
overengineer
this; this really is a "short term solution" (with the usual caveat that there 
are no
short term solutions), and that a post-quantum DH-like function is the Right 
Thing
(only we haven't agreed on that yet).  The issue with having a complex 
negotiation
process is that may be a lot of rarely executed code, and that in itself may 
lead
to security vulnerabilities.


Is it possible to use the already negotiated IKEv2 prf inside the modified 
crypto formulas?
In this case they would look like:

   SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
   (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
 prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)

and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't 
it?
In this case no additional negotiation is required since prf is negotiated in 
IKEv2
anyway and thus we would have algorithm agility in KDF for free.


> This second use is rather trickier to have agility; it is sent before the
> initiator has any contact to the responder. I don’t see how the
> responder can
> indicate which algorithms it supports (without adding a round trip to the
> protocol).

This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.


One of the constraints that we felt we had to live within was to minimize
the changes we made to IKEv2, both from a crypto standpoint, and from
a state machine standpoint.  Hence, we decided that adding vendor
id payloads (or notification payloads) to existing messages we OK,
however adding additional round trips was out of bounds.


Note, that IKEv2 state machine has already accomodated the possibility
of an additional round trip in case the initiator has incorrectly guessed the
DH group. Introducing one more condition for additional round trip
should not be too hard, however I agree that it adds some complexity
and thus may be considered inappropriate for a short-term solution.

However, if no better solution exists I'd prefer to live with a single
fixed crypto primitive, than with two. Is it possible to get rid of
AES and to change the indication of the ppk to use to something
like the following?

HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)

(disclaimer: I'm not a cryptographer)


If one were to add additional round trips, a cleaner solution would be
to negotiate the initial IKE SA as per the RFC, and then if the two sides
decide that they need QR, create a child SA (in a PQR manner).
The current approach has the issue that we need to stir in the post-quantum
magic before the identities were exchanged (and hence the initiator gives
the indication of the ppk). If you establish a secure connection (and exchange
identities) first, then it becomes much cleaner (as both sides would know who
they are talking to, and which ppk they should use).  However, that was
deemed to be too large of an delta.


I'm not sure this approach is easier than approch with additional round trip.
I understand that it has some advantages (e.g. no need for linear key search),
but from state machine point of view it may appear to be more complex.

Regards,
Valery. 


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

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

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov
> Sent: Thursday, January 14, 2016 7:58 AM
> To: Scott Fluhrer (sfluhrer); Michael Richardson; ipsec@ietf.org
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
> 
> Hi Scott,
> 
> >> Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote:
> >> > - It defines the transform of the nonce from the on-the-wire
> >> version into the
> >> > one presented to the IKEv2 KDF (mixing in the PPK).
> >>
> >> > - The initiator gives an indication of which PPK to use (without 
> >> leaking
> any
> >> > information about it to someone two doesn’t know the value).
> >>
> >> > For the first use, it would be reasonable to have the initiator 
> >> define a
> >> > bitmask of the algorithms it supports, and the responder to
> >> select one
> >>
> >> That's not very algorithm agile, nor very IKEv2 happy. Don't we
> >> already have IANA values for all the algorithms involved? (shouldn't
> >> we have them)
> >
> > The 'bitmask idea' was off the top of my head; we could certainly give
> > a list of IANA values (such as the IKEv2 PRF).  My chief fear is that
> > we don't overengineer this; this really is a "short term solution"
> > (with the usual caveat that there are no short term solutions), and
> > that a post-quantum DH-like function is the Right Thing (only we
> > haven't agreed on that yet).  The issue with having a complex
> > negotiation process is that may be a lot of rarely executed code, and that 
> > in
> itself may lead to security vulnerabilities.
> 
> Is it possible to use the already negotiated IKEv2 prf inside the modified
> crypto formulas?
> In this case they would look like:
> 
> SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
>   prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)
> 
> and so on. I'm not a cryptographer, but it seems to me that this is safe, 
> isn't
> it?
> In this case no additional negotiation is required since prf is negotiated in
> IKEv2 anyway and thus we would have algorithm agility in KDF for free.

I like this -- I'm stealing this idea.

> 
> >> > This second use is rather trickier to have agility; it is sent 
> >> before the
> >> > initiator has any contact to the responder. I don’t see how the
> >> > responder can
> >> > indicate which algorithms it supports (without adding a round trip to
> the
> >> > protocol).
> >>
> >> This is why I suggested... if you have to add a round trip anyway...
> >> might as well solve a puzzle or something along the way.
> >
> > One of the constraints that we felt we had to live within was to
> > minimize the changes we made to IKEv2, both from a crypto standpoint,
> > and from a state machine standpoint.  Hence, we decided that adding
> > vendor id payloads (or notification payloads) to existing messages we
> > OK, however adding additional round trips was out of bounds.
> 
> Note, that IKEv2 state machine has already accomodated the possibility of an
> additional round trip in case the initiator has incorrectly guessed the DH
> group. Introducing one more condition for additional round trip should not
> be too hard, however I agree that it adds some complexity and thus may be
> considered inappropriate for a short-term solution.
> 
> However, if no better solution exists I'd prefer to live with a single fixed
> crypto primitive, than with two. Is it possible to get rid of AES and to 
> change
> the indication of the ppk to use to something like the following?
> 
> HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)
> 
> (disclaimer: I'm not a cryptographer)

Your proposal is perfectly sound from a cryptography perspective.  Actually, 
the reason we proposed the "entry in the AES codebook" approach, rather than 
something like the above structure, is due to practical reasons.  When the 
responder receives the hint, he has no idea which ppk the initiator is 
referring to (and he doesn't know the identity yet); our model is that the 
responder has a list of ppk's that he knows about, and checks to see if the one 
that the initiator had is on the list.  It'd be nice if there was a way for the 
responder to search through his databases of known ppk's quickly, however I 
don't know how to let him do it in sublinear time (without leaking whether two 
exchanges used the same ppk, which would leak inform

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

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Michael
> Richardson
> Sent: Wednesday, January 13, 2016 11:59 AM
> To: ipsec@ietf.org
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
> 
> 
> Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote:
> > - It defines the transform of the nonce from the on-the-wire version 
> into
> the
> > one presented to the IKEv2 KDF (mixing in the PPK).
> 
> > - The initiator gives an indication of which PPK to use (without 
> leaking any
> > information about it to someone two doesn’t know the value).
> 
> > For the first use, it would be reasonable to have the initiator define a
> > bitmask of the algorithms it supports, and the responder to select one
> 
> That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
> IANA values for all the algorithms involved? (shouldn't we have them)

The 'bitmask idea' was off the top of my head; we could certainly give a list 
of IANA values (such as the IKEv2 PRF).  My chief fear is that we don't 
overengineer this; this really is a "short term solution" (with the usual 
caveat that there are no short term solutions), and that a post-quantum DH-like 
function is the Right Thing (only we haven't agreed on that yet).  The issue 
with having a complex negotiation process is that may be a lot of rarely 
executed code, and that in itself may lead to security vulnerabilities.

> 
> > This second use is rather trickier to have agility; it is sent before 
> the
> > initiator has any contact to the responder. I don’t see how the
> > responder can
> > indicate which algorithms it supports (without adding a round trip to 
> the
> > protocol).
> 
> This is why I suggested... if you have to add a round trip anyway... might as
> well solve a puzzle or something along the way.

One of the constraints that we felt we had to live within was to minimize the 
changes we made to IKEv2, both from a crypto standpoint, and from a state 
machine standpoint.  Hence, we decided that adding vendor id payloads (or 
notification payloads) to existing messages we OK, however adding additional 
round trips was out of bounds.

If one were to add additional round trips, a cleaner solution would be to 
negotiate the initial IKE SA as per the RFC, and then if the two sides decide 
that they need QR, create a child SA (in a PQR manner).  The current approach 
has the issue that we need to stir in the post-quantum magic before the 
identities were exchanged (and hence the initiator gives the indication of the 
ppk). If you establish a secure connection (and exchange identities) first, 
then it becomes much cleaner (as both sides would know who they are talking to, 
and which ppk they should use).  However, that was deemed to be too large of an 
delta.


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

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

[Michael Richardson]

Scott Fluhrer (sfluhrer)  wrote:
> - It defines the transform of the nonce from the on-the-wire version into 
the
> one presented to the IKEv2 KDF (mixing in the PPK).

> - The initiator gives an indication of which PPK to use (without leaking 
any
> information about it to someone two doesn’t know the value).

> For the first use, it would be reasonable to have the initiator define a
> bitmask of the algorithms it supports, and the responder to select one

That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
IANA values for all the algorithms involved? (shouldn't we have them)

> This second use is rather trickier to have agility; it is sent before the
> initiator has any contact to the responder. I don’t see how the
> responder can
> indicate which algorithms it supports (without adding a round trip to the
> protocol).

This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Panos,

thank you for sharing this draft. A couple of quick comments. 

First, I think that it is better to use a new status Notification to negotiate 
this feature 
rather than a Vendor ID payload. It is more in line with the way other IKEv2 
extensions 
are negotiated and it would allow not to waste 16 bytes in the IKE_SA_INIT 
messages. 

And second, I'm not comfortable with using fixed algorithms (AES, HMAC_SHA2) and
not addressing algorithm agility. Fortunately, your draft says that this might 
change
in future versions. I think it is an important feature ant I hope it'll be 
addressed.

Regards,
Valery Smyslov.

  - Original Message - 
  From: Panos Kampanakis (pkampana) 
  To: Perlner, Ray ; ipsec@ietf.org 
  Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; Frankel, 
Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody, Dustin 
  Sent: Tuesday, January 12, 2016 8:44 AM
  Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance


  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 <yi-kai@nist.gov>; Moody, Dustin <dustin.mo...@nist.gov>; 
Frankel, Sheila E. <sheila.fran...@nist.gov>; Waltermire, David A. 
<david.walterm...@nist.gov>
  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
___
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 <yi-kai@nist.gov>; Moody, Dustin <dustin.mo...@nist.gov>; 
Frankel, Sheila E. <sheila.fran...@nist.gov>; Waltermire, David A. 
<david.walterm...@nist.gov>
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

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

[Michael Richardson]

Yoav Nir  wrote:
> Short version: I think it’s fine. Now let’s see an actual proposal.

+1.

A desireable property which we do not presently have, is if the amount of
work the initiator has to do for step 1 is less than what the responder has
to do for step 2, and the responder can cheaply verify the "freshness" of
the work.  During times of attack, there can be an additional step -1/0
where the responder provides a challenge to the initiator.

We have been looking at using puzzle solving to let the responder seperate
the wheat from the DDoS-provided-chaff quickly.   If a new protocol was
quantum resistant, and *also* provided a measure of DDoS resistance, then
that would probably significantly improve the industry interest in it.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] NIST question concerning IKEv2 and quantum resistance

[Perlner, Ray]

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

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

[Paul Wouters]

On Wed, 6 Jan 2016, Perlner, Ray wrote:


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.


There is:

https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01

It was thrown out of the working group before. I think it is time to
reconsider with everyone focusing on post-quantum worlds.

Paul

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