Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
Scott Fluhrer (sfluhrer) writes: > > That implementation is broken, and needs to be fixed. > > I can easily see a manufacturer claiming "my implementation has been > working without a problem for 13 years; why does it need to be > fixed?" And the answer will be: Because it is broken, and it is not following what RFC says. Even if this issue was not found before as this feature was not used, this does not mean that their implementation would be less broken. And if any vendor says that they have not done any single security fix for their implementation for last 13 years, it is time to switch vendors. > Ultimately, it's the working group that needs to decide whether we > need to respect the (to the implementors) apparently valid > assumption as de facto, or whether we feel we can break them. We had same issue earlier. I.e., several implementations did assume that we never need mor than one proposal, as there is never need to support policies that would require more than one proposal. I.e., they did not support policies which said 3DES + MD5 or AES + SHA1, but which forbid 3DES + SHA1 and AES + MD5. This would have required two proposals, and as those kind of policies are stupid, some implementations (like mine) did not support them. When we defined combined mode ciphers, we decided that you need to do that with two proposals, one having non-combined mode ciphers and other having only combined mode ciphers. All implementations wanting to support combined mode ciphers, needed to include support for at least two proposals if they wanted to allow policies that allow both. To support backwards compability implementations can put the non-combined mode ciphers in first proposal, so if other end only parses first proposal, it will find the find the acceptable proposal from there. Those old implementations did not support combined mode ciphers anyways. We can do same here. Put traditional DH version in first proposal, and they will most likely pick that... Or you can put vendor ID check and return error "Other end is using obsolete implementation of the IKEv2, please upgrade it immediately as those kind of implementations not receiving updates are most likely vulnerable to all kind of attacks. Are you sure you really still want to connect using compatibility mode?" -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
> On Nov 1, 2018, at 06:03, Tero Kivinen wrote: > > Scott Fluhrer (sfluhrer) writes: >> My issue with this general idea is backwards compatibility; if we >> issue a transform of type 5 to an old IKEv2 system, it may reject >> the entire exchange with an "unrecognized transform type" error (and >> yes, there are real systems that behave this way). > > That implementation is broken, and needs to be fixed. Indeed, the WG repeatedly said this is not a valid argument. Let’s bury it for good this time. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. > > In section 3.3.6 this is explained very clearly: > > If the responder receives a proposal that contains a Transform Type > it does not understand, or a proposal that is missing a mandatory > Transform Type, it MUST consider this proposal unacceptable; however, > other proposals in the same SA payload are processed as usual. > Similarly, if the responder receives a transform that it does not > understand, or one that contains a Transform Attribute it does not > understand, it MUST consider this transform unacceptable; other > transforms with the same Transform Type are processed as usual. This > allows new Transform Types and Transform Attributes to be defined in > the future Agreed. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
> -Original Message- > From: Valery Smyslov > Sent: Thursday, November 01, 2018 7:14 AM > To: Scott Fluhrer (sfluhrer) ; 'IPsecME WG' > > Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org > Subject: RE: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 > > Hi Scott, > > > > 1. Nonces. > > > > > > The draft specifies that each additional key exchange performed > > > over IKE_AUX includes new nonces. My question - why nonces > exchanged > > > during IKE_SA_INIT cannot be used instead? Is it critical for > > > security? > > > > No, it is not. Instead, we were (mostly) reusing the format of the > > CREATE_CHILD_SA request; as that request already had nonces, we saw no > specific reason to remove them. Correction to what I said: the original reasoning was not to keep the IKE message format, but rather to reuse the IKE child SA key derivation function (section 2.17) > > Well, I definitely don't insist, but if we reused the nonces exchanged in > IKE_SA_INIT, it would have saved a few bytes on the wire :-) Ultimately, I don't believe it matters all that much... > > > > I have no problem with exchanging new nonces in each IKE_AUX, > > > my concern is that while performing authentication only the nonces > > > exchanged in IKE_SA_INIT are covered by the signature. For example > > > for initiator: > > > > > > InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI > > > > > > where NonceRData is the content of the responder's nonce from > > > IKE_SA_INIT. > > > Currently IKE_AUX draft doesn't redefine this, except that it adds > initiator's > > > IKE_AUX content into the calculation. Is it OK, or should we > > > modify AUTH payload > > > calculation in case QSKE is used? In particular - include all the > > > peer's > > > nonces from IKE_AUX exchanges in NonceRData? > > > > Your draft includes the hash (collision resistant PRF, actually) of > > the aux messages in the AUX_I, which is included in the data which is > > signed. Because the nonces are included in computing the AUX_I > messages, we are protected; there is no specific need to include those > nonces separately. > > It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX > messages) > is included in the initiator's signature. > My concern is: from my recollection of SIGMA paper it is essential for > security > that each party includes its peer's nonce in the signature. In case of IKE > initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it is > included. > But the AUX_I contains only PRF over initiator's messages, i.e. it contains > only > initiator's additional nonces, not responder's ones. > Is it OK for authentication that we don't include peer's additional nonces in > the signature? Won't we screw up SIGMA? > (Disclaimer: I'm not a cryptographer). The nonces are included; however instead of including the text of the nonce directly, we're including a complex function of (among other things) the nonces. If you change the nonces, you change the output of that complex function, which changes the text of what is signed, and that is what SIGMA relies on. > > > > 2. QSKE negotiation. > > > > > >I still think that we can use the existing negotiation mechanism > > > instead > of > > >defining an additional one. I don't think we should consider the > argument > > >that now there are buggy implementations out there, since we're > > >developing a long term solution. > > > > > > How it can be done with existing mechanism. > > > > > > First approach, classical: we define new transform types as follows: > > > > > > Transform Type 6: QSKE of type 1 (say lattice based) > > > Transform Type 7: QSKE of type 2 (say isogeny based) > > > Transform Type 8: QSKE of type 3 (say code based) > > > etc. > > > > > > In this case list of Transform IDs for each new Transform Type > > > will be different - only relevant > > > algorithms must be included. In addition some QSKE Transform IDs > > > with a small public key > > > (regardless of type) will also be added to the list of possible > > > Transform IDs for Transform Type 4. > > > > Minor comment on the last bit about making small public key transforms > > all type 4; because (with your > > proposal) the responder can't accept more than one type 4 transform, > > that would mean that you couldn't bundle (say) Curve25519 and SIKE > (which is a small postquantum key exchange). > > I would claim that is something that we would want to allow people to > > negotiate (as SIKE isn't necessarily well trusted, and so it would be > > plausible > that someone would like to negotiate Curve25519 as well). > > My understanding is that the crypto world is now trying to migrate to > quantum-safe crypto (including key exchange). > The problem is that now we don't have quantum safe key exchange > methods that are fully trusted by cryptographers and have
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
Hi CJ, > > That implementation is broken, and needs to be fixed. > > What's the procedure on this? Is there a need to publish a document or > some test vectors that all implementations can validate against? > > Personally, it is more logical to introduce new transform types for > QSKEs, but one of my concerns is how can we guarantee that all broken > implementations are fixed? Of course there is no guarantee... However, as we repeated several times, this solution is not intended to be deployed in a nearest future. We don't yet even have QSKE methods that are more or less trusted by the majority of cryptographers (as far as I understand). So, vendors have plenty of time to fix their implementations and to align there with RFC. And yes, I do understand, that it doesn't mean that all customers will upgrade to a new version... On the other hand, some broken implementations can be dealt with. Just add an additional checks on initiator. > Consider the following simplified proposal: > > SA Payload > | > +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, > | |6 transforms) > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > +-- Transform QSKE1 ( Name = Foobar ) > +-- Transform QSKE2 ( Name = Zappa ) > > At the moment, some broken implementations may abort the exchange > entirely and in some way, this helps as we may want to establish a > connection with a broken implementation. On the other hand, there > could be other implementations that ignore both QSKE1 and QSKE2 and > return a response as if there is an implicit second proposal: > | > +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, > |4 transforms) > | > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > > So more complex checks will be required to cater for all broken cases. > I have no idea what response we will get from other broken > implementations. Yes, we can develop some checks against most obvious types of brokenness. > Or alternatively, do we have to rely on another Notification payload > to check for potential backward compatibility issues? Implementations can rely on AUX_EXCHANGE_SUPPORTED. If responder doesn't return it, then it might be broken, so restart the exchange with only classical KE methods included. > I think it would be great to also get some thoughts from VPN > manufacturers on this point. Sure. Regards, Valery. > Cheers, > CJ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
Hi Scott, > > 1. Nonces. > > > > The draft specifies that each additional key exchange performed > > over IKE_AUX includes new nonces. My question - why nonces exchanged > > during IKE_SA_INIT cannot be used instead? Is it critical for security? > > No, it is not. Instead, we were (mostly) reusing the format of the > CREATE_CHILD_SA request; as that request > already had nonces, we saw no specific reason to remove them. Well, I definitely don't insist, but if we reused the nonces exchanged in IKE_SA_INIT, it would have saved a few bytes on the wire :-) > > I have no problem with exchanging new nonces in each IKE_AUX, > > my concern is that while performing authentication only the nonces > > exchanged in IKE_SA_INIT are covered by the signature. For example > > for initiator: > > > > InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI > > > > where NonceRData is the content of the responder's nonce from > > IKE_SA_INIT. > > Currently IKE_AUX draft doesn't redefine this, except that it adds > > initiator's > > IKE_AUX content into the calculation. Is it OK, or should we modify AUTH > > payload > > calculation in case QSKE is used? In particular - include all the peer's > > nonces from IKE_AUX exchanges in NonceRData? > > Your draft includes the hash (collision resistant PRF, actually) of the aux > messages in the AUX_I, which is > included in the data which is signed. Because the nonces are included in > computing the AUX_I messages, we > are protected; there is no specific need to include those nonces separately. It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX messages) is included in the initiator's signature. My concern is: from my recollection of SIGMA paper it is essential for security that each party includes its peer's nonce in the signature. In case of IKE initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it is included. But the AUX_I contains only PRF over initiator's messages, i.e. it contains only initiator's additional nonces, not responder's ones. Is it OK for authentication that we don't include peer's additional nonces in the signature? Won't we screw up SIGMA? (Disclaimer: I'm not a cryptographer). > > 2. QSKE negotiation. > > > >I still think that we can use the existing negotiation mechanism instead > > of > >defining an additional one. I don't think we should consider the argument > >that now there are buggy implementations out there, since we're > >developing a long term solution. > > > > How it can be done with existing mechanism. > > > > First approach, classical: we define new transform types as follows: > > > > Transform Type 6: QSKE of type 1 (say lattice based) > > Transform Type 7: QSKE of type 2 (say isogeny based) > > Transform Type 8: QSKE of type 3 (say code based) > > etc. > > > > In this case list of Transform IDs for each new Transform Type will be > > different - only relevant > > algorithms must be included. In addition some QSKE Transform IDs with a > > small public key > > (regardless of type) will also be added to the list of possible > > Transform IDs > > for Transform Type 4. > > Minor comment on the last bit about making small public key transforms all > type 4; because (with your > proposal) the responder can't accept more than one type 4 transform, that > would mean that you couldn't > bundle (say) Curve25519 and SIKE (which is a small postquantum key exchange). > I would claim that is something that we would want to allow people to > negotiate (as SIKE isn't necessarily well > trusted, and so it would be plausible that someone would like to negotiate > Curve25519 as well). My understanding is that the crypto world is now trying to migrate to quantum-safe crypto (including key exchange). The problem is that now we don't have quantum safe key exchange methods that are fully trusted by cryptographers and have acceptable performance and public key size. For that reason we want to bundle several key exchange methods and for this purpose we need to invent that things like IKE_AUX. But I hope that in a future cryptographers will eventually invent key exchange methods that will be fully trusted and have acceptable key size, and these methods will be so good, that can even replace classic (EC)DH. If that happen, all sophisticated games with IKE_AUX will become unnecessary and we can come back to a single key exchange in IKE_SA_INIT using these new methods... So I meant that only such methods should be added to Transform Type 4. > > With this approach there's no strict mapping from QSKE to IKE_AUX, > > actually all the > > selected QSKE can be put together into single IKE_AUX exchange or can be > > performed > > one after one in a series of IKE_AUX exchanges. The latter seems more > > natural > >and is in line with current QSKE draft. Note, that KE from Transform
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
On 01/11/2018, 10:00, "CJ Tjhai" wrote: Hi all, > > That implementation is broken, and needs to be fixed. What's the procedure on this? Is there a need to publish a document or some test vectors that all implementations can validate against? Personally, it is more logical to introduce new transform types for QSKEs, but one of my concerns is how can we guarantee that all broken implementations are fixed? >> I would also not know how to guarantee that all deployed broken >> implementations can be fixed. Consider the following simplified proposal: SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | |6 transforms) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) +-- Transform QSKE1 ( Name = Foobar ) +-- Transform QSKE2 ( Name = Zappa ) At the moment, some broken implementations may abort the exchange entirely and in some way, this helps as we may want to establish a connection with a broken implementation. On the other hand, there could be other implementations that ignore both QSKE1 and QSKE2 and return a response as if there is an implicit second proposal: | +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, |4 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) So more complex checks will be required to cater for all broken cases. I have no idea what response we will get from other broken implementations. Or alternatively, do we have to rely on another Notification payload to check for potential backward compatibility issues? I think it would be great to also get some thoughts from VPN manufacturers on this point. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. > > In section 3.3.6 this is explained very clearly: > >If the responder receives a proposal that contains a Transform Type >it does not understand, or a proposal that is missing a mandatory >Transform Type, it MUST consider this proposal unacceptable; however, >other proposals in the same SA payload are processed as usual. >Similarly, if the responder receives a transform that it does not >understand, or one that contains a Transform Attribute it does not >understand, it MUST consider this transform unacceptable; other >transforms with the same Transform Type are processed as usual. This >allows new Transform Types and Transform Attributes to be defined in >the future. > > I.e., the intention is that if there is transform type you do not > understand you skip whole proposal, but STILL PROCESS rest of the > proposals normally, i.e., this allows backward compatiblity. > Yes, this is how it should behave. Cheers, CJ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
Hi all, > > That implementation is broken, and needs to be fixed. What's the procedure on this? Is there a need to publish a document or some test vectors that all implementations can validate against? Personally, it is more logical to introduce new transform types for QSKEs, but one of my concerns is how can we guarantee that all broken implementations are fixed? Consider the following simplified proposal: SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | |6 transforms) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) +-- Transform QSKE1 ( Name = Foobar ) +-- Transform QSKE2 ( Name = Zappa ) At the moment, some broken implementations may abort the exchange entirely and in some way, this helps as we may want to establish a connection with a broken implementation. On the other hand, there could be other implementations that ignore both QSKE1 and QSKE2 and return a response as if there is an implicit second proposal: | +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, |4 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) So more complex checks will be required to cater for all broken cases. I have no idea what response we will get from other broken implementations. Or alternatively, do we have to rely on another Notification payload to check for potential backward compatibility issues? I think it would be great to also get some thoughts from VPN manufacturers on this point. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. > > In section 3.3.6 this is explained very clearly: > >If the responder receives a proposal that contains a Transform Type >it does not understand, or a proposal that is missing a mandatory >Transform Type, it MUST consider this proposal unacceptable; however, >other proposals in the same SA payload are processed as usual. >Similarly, if the responder receives a transform that it does not >understand, or one that contains a Transform Attribute it does not >understand, it MUST consider this transform unacceptable; other >transforms with the same Transform Type are processed as usual. This >allows new Transform Types and Transform Attributes to be defined in >the future. > > I.e., the intention is that if there is transform type you do not > understand you skip whole proposal, but STILL PROCESS rest of the > proposals normally, i.e., this allows backward compatiblity. > Yes, this is how it should behave. Cheers, CJ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
Scott Fluhrer (sfluhrer) writes: > My issue with this general idea is backwards compatibility; if we > issue a transform of type 5 to an old IKEv2 system, it may reject > the entire exchange with an "unrecognized transform type" error (and > yes, there are real systems that behave this way). That implementation is broken, and needs to be fixed. > And, it could be argued that such an IKEv2 implementation would be > compliant; section 3.3.3 of RFC7296 would appear to forbid any > transform types other than 1-4 in an IKE negotiation. That is not true. Section 3.3.3 lists mandatory types, and those optional types, which are included in that RFC. It does NOT list any of the future optional types. In section 3.3.6 this is explained very clearly: If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future. I.e., the intention is that if there is transform type you do not understand you skip whole proposal, but STILL PROCESS rest of the proposals normally, i.e., this allows backward compatiblity. I.e., if we have SA payload: SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | |14 transforms) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) | +-- Transform D-H ( Name = 8192-bit MODP Group ) | +-- Transform D-H ( Name = Curve25519 ) | +-- Transform D-H ( Name = Curve448 ) | +-- Transform QSKE1 ( Name = Foobar ) | +-- Transform QSKE1 ( Name = Zappa ) | +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, | |14 transforms) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) | +-- Transform D-H ( Name = 8192-bit MODP Group ) | +-- Transform D-H ( Name = Curve25519 ) | +-- Transform D-H ( Name = Curve448 ) | +-- Transform QSKE1 ( Name = Foobar ) | +-- Transform QSKE2 ( Name = Zappa ) | +--- Proposal #3 ( Proto ID = IKE(1), SPI size = 0, |12 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 128 ) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 192 ) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = 8192-bit MODP Group ) +-- Transform D-H ( Name = Curve25519 ) +-- Transform D-H ( Name = Curve448 ) Then complient old implementation will ignore proposals 1 and 2, as they include Transforms they do not understand, and see that proposal 3 has all the things it needs, and nothing extra, and then it will pick
Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
> -Original Message- > From: Valery Smyslov > Sent: Wednesday, October 31, 2018 9:55 AM > To: IPsecME WG > Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org > Subject: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 > > Hi, > > here are some comments on -02 QSKE draft to stimulate further discussion. > > > 1. Nonces. > > The draft specifies that each additional key exchange performed > over IKE_AUX includes new nonces. My question - why nonces exchanged > during IKE_SA_INIT cannot be used instead? Is it critical for security? No, it is not. Instead, we were (mostly) reusing the format of the CREATE_CHILD_SA request; as that request already had nonces, we saw no specific reason to remove them. > I have no problem with exchanging new nonces in each IKE_AUX, > my concern is that while performing authentication only the nonces > exchanged in IKE_SA_INIT are covered by the signature. For example > for initiator: > > InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI > > where NonceRData is the content of the responder's nonce from > IKE_SA_INIT. > Currently IKE_AUX draft doesn't redefine this, except that it adds > initiator's > IKE_AUX content into the calculation. Is it OK, or should we modify AUTH > payload > calculation in case QSKE is used? In particular - include all the peer's > nonces from IKE_AUX exchanges in NonceRData? Your draft includes the hash (collision resistant PRF, actually) of the aux messages in the AUX_I, which is included in the data which is signed. Because the nonces are included in computing the AUX_I messages, we are protected; there is no specific need to include those nonces separately. > > > 2. QSKE negotiation. > >I still think that we can use the existing negotiation mechanism instead of >defining an additional one. I don't think we should consider the argument >that now there are buggy implementations out there, since we're >developing a long term solution. > > How it can be done with existing mechanism. > > First approach, classical: we define new transform types as follows: > > Transform Type 6: QSKE of type 1 (say lattice based) > Transform Type 7: QSKE of type 2 (say isogeny based) > Transform Type 8: QSKE of type 3 (say code based) > etc. > > In this case list of Transform IDs for each new Transform Type will be > different - only relevant > algorithms must be included. In addition some QSKE Transform IDs with a > small public key > (regardless of type) will also be added to the list of possible Transform > IDs > for Transform Type 4. Minor comment on the last bit about making small public key transforms all type 4; because (with your proposal) the responder can't accept more than one type 4 transform, that would mean that you couldn't bundle (say) Curve25519 and SIKE (which is a small postquantum key exchange). I would claim that is something that we would want to allow people to negotiate (as SIKE isn't necessarily well trusted, and so it would be plausible that someone would like to negotiate Curve25519 as well). > > With this approach there's no strict mapping from QSKE to IKE_AUX, > actually all the > selected QSKE can be put together into single IKE_AUX exchange or can be > performed > one after one in a series of IKE_AUX exchanges. The latter seems more > natural >and is in line with current QSKE draft. Note, that KE from Transform Type 4 > will > always be performed in IKE_SA_INIT. If QSKEs are performed in a series of > IKE_AUX, >the order of them is not defined explicitly. Either we decide that the > order > is not imported >(if it is OK from security PoV), or the order will be implicitly defined > by the > order >of new Transform Types (6 and up) in initiator's proposal (there is no > requirement in RFC 7296 that >responder keep the order of Transform Types in a response). My issue with this general idea is backwards compatibility; if we issue a transform of type 5 to an old IKEv2 system, it may reject the entire exchange with an "unrecognized transform type" error (and yes, there are real systems that behave this way). And, it could be argued that such an IKEv2 implementation would be compliant; section 3.3.3 of RFC7296 would appear to forbid any transform types other than 1-4 in an IKE negotiation. > >This approach has a potential problem: if more types of QSKE appear this > will require to add >new Transform Types. Since old implementations are unaware of these > types (even if they are >aware of Types 6, 7, 8 etc), policy need to be written in such a way, >that proposals are doubled - one with new types and one without them. >This will increase the size of SA payload. This problem can be dealt with > if we define spare Transform Types beforehand - so as the same time > as Transform Types 6-8 are defined for known
