Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
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
> -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
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
> -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
> -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
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
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
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
Yoav Nirwrote: > 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
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
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