Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02

From: CJ Tjhai <[email-masked]>
Date: Thu, 1 Nov 2018 08:59:42 +0000

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

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Thu, 1 Nov 2018 10:23:47 +0000

On 01/11/2018, 10:00, "CJ Tjhai" <[email-masked]> wrote:

    Hi all,

>> I would also not know how to guarantee that all deployed broken implementations can be fixed.

    SA Payload
          |

    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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 1 Nov 2018 14:14:02 +0300

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 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.

I think Tero has already addressed these concerns in his e-mail.

> >    For these reasons I think a different approach is more convenient: we
> > define
> >     new transform types as follows:
> >
> >     Transform Type 6: Additional QSKE performed in 1st IKE_AUX
> >     Transform Type 7: Additional QSKE performed in 2nd IKE_AUX
> >     Transform Type 8: Additional QSKE performed in 3rd IKE_AUX
> >     etc. (How many do we want to combine?)
> >
> >     The same list of possible Transform IDs representing QSKE methods will be
> > defined
> >     for each of these new Transform Types. In addition these QSKE Transform
> > IDs
> >     (or some of them with a small enough public key) will also be added to the
> > list
> >     of possible Transform IDs for Transform Type 4.
> 
> Why not make them all a possible transform id for type 4?  After all, there are scenarios where fragmentation
> is not an issue (e.g. TCP encaps)

Since responder can return only a single transform of each type, this would
mean that we cannot bundle several key exchanges unless new Transform Types are defined.

Or do you mean that we still define new Transform Types, but make all new key exchanges 
available in Transform Type 4 too for the cases where fragmentation is not an issue and
we don't need classic (EC)DH?

> >    This approach is flexible enough to define various policies:
> >    - don't use QSKE
> >    - use a single QSKE (in addition to classical KE)
> >    - use combination of no less than two (three, etc) QSKEs
> >
> >     The SA payload may still grow if you want to restrict which QSKE methods
> >     can be combined with which ones.
> >
> >    Comparing to the separate negotiation mechanism proposed in the draft:
> >    - it seems that using SA Proposals is clearer than separate mechanism
> >    - in case of complex policies the size of SA payload may grow, so the size
> >      of IKE_SA_INIT request may be larger than with the draft's negotiation
> >      mechanism. I still hope that we can avoid the necessity of complex
> >      policies, but if this is a concern, we may consider the draft
> >      draft-smyslov-ipsecme-ikev2-compact-04 "Compact Format of IKEv2
> > Payloads",
> >      which allows to substantially reduce the size of SA payload.
> >
> >     Any thoughts?
> 
> Now, one thing that had been bothering me with our proposal is that there is no way to include attributes
> along with the transform id.  Now, the existing DH/ECDH transforms do not have any attributes defined;
> however some of the NIST submissions have a large number of variations (Round2 had 30 different ones), and
> while we could make each variation a different transform id (which is effectively what we did with DH and
> ECDH; there really is only one DH algorithm; the exact transform id selected which parameters were used with
> that algorithm), however it's not clear if that's the approach we want to mandate with the newer
> postquantum transforms.

Using attributes will make definition of Transform ID clearer, but, as Tero pointed out, it won't help negotiation.
But using attributes instead of defining a large number of Transform IDs for all possible combination
of parameters looks like a good idea - at least we'll save a few bytes on the wire and a lot of lines
on IANA registry page :-)

> > 3. CREATE_CHILD_SA
> >
> >     The draft currently is silent about using QSKE in CREATE_CHILD_SA
> > exchange.
> 
> Or, more specifically, using more than one keying mechanism; you can use any single KE for a
> CREATE_CHILD_SA, either conventional or postquantum.
> 
> Actually, I believe that there is some weasel working saying "you can get this effect by negotiating several child
> SA's in succession"; however, I can certainly understand it if the working group decided that was not
> acceptable...

Do I get you right that the idea is to negotiate several successive SAs with unmodified CREATE_CHILD_SA, 
each with different (QS)KE methods, so that the resulting SA absorbs entropy from all the exchanges? 
That could work for IKE SA (rekeying), but I fail to understand how it will work for Child SAs. If you want 
to create new or rekey existing Child SA with additional entropy, then you cannot perform successive 
key exchanges unless you somehow modify CREATE_CHILD_SA exchange. Did I miss something?

> >
> >    Initiator                         Responder
> >    -------------------------------------------------------------------
> >    HDR, SK { N(ExchangeID1), N1i, QSKe1i,} -->
> >                                 <--  HDR, SK { N1r, QSKe1r, N(ExchangeID2)}
> >
> >    HDR, SK { N(ExchangeID2), N2i, QSKe2i,} -->
> >                                 <--  HDR, SK { N2r, QSKe2r, N(ExchangeID3)}
> >
> >    HDR, SK { N(ExchangeID3), N3i, QSKe3i,} -->
> >                                 <--  HDR, SK { N3r, QSKe3r}
> >
> >     At this point all key are exchanged, so the SA is created.
> 
> I suspect you'll need to be more explicit about having something tying the multiple messages together.  After
> all, there can be several of these exchanges going on simultaneously; it would be good to be explicit.

That's what ExchangeID is for. I think it can contain some random (or only meaningful to responder)
data, that helps responder to link each exchange to a previous one even if there are several in progress.
It also ensures that the initiator won't start next exchange until the previous one is completed.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 1 Nov 2018 14:48:08 +0300

Hi CJ,

> 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. 

> I have no idea what response we will get from other broken

Yes, we can develop some checks against most obvious types of brokenness.

> 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.

> manufacturers on this point.

Sure.

Regards,
Valery.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 1 Nov 2018 15:04:14 +0000

> -----Original Message-----
> From: Tero Kivinen <[email-masked]>
> Sent: Wednesday, October 31, 2018 7:04 PM
> To: Scott Fluhrer (sfluhrer) <[email-masked]>
> Cc: Valery Smyslov <[email-masked]>; IPsecME WG
> <[email-masked]>; [email-masked]
> Subject: 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).
> 

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?"

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.

> > > Valery:
> > >    For these reasons I think a different approach is more
> > > convenient: we define new transform types as follows:
> > >
> > >     The same list of possible Transform IDs representing QSKE
> > > methods will be defined for each of these new Transform Types. In
> > > addition these QSKE Transform IDs (or some of them with a small
> > > enough public key) will also be added to the list of possible
> > > Transform IDs for Transform Type 4.
> >
> > Why not make them all a possible transform id for type 4? After all,
> > there are scenarios where fragmentation is not an issue (e.g. TCP
> > encaps)
> 
> If all of them are Transform Type 4, i.e. D-H, then responder MUST pick
> exactly one that is the only one to be used. Responder is not allowed return
> more than one Transform ID for each Transform Type there is in proposal.

I believe that you misinterpreted my question.  This comment was in the context of Valery's proposal; in his last sentence "In addition these QSKE Transform IDs (or some of them with a small enough public keys)..." Valery suggested that some of the new QSKE transform id's were also to be added to the supported type 4 list.  My query is "why not include all of them in the list of valid type 4 transform types?"

For that matter (I didn't express this earlier, but I'll do it now) why not make the acceptable transform types for type 4, 6, 7, 8, etc to be exactly the same?  It would appear to me that mandating they be different (but have common entries) actually adds complexity for no good reason.

> 
> > Now, one thing that had been bothering me with our proposal is that
> > there is no way to include attributes along with the transform id.
> > Now, the existing DH/ECDH transforms do not have any attributes
> > defined; however some of the NIST submissions have a large number of
> > variations (Round2 had 30 different ones), and while we could make
> > each variation a different transform id (which is effectively what we
> > did with DH and ECDH; there really is only one DH algorithm; the exact
> > transform id selected which parameters were used with that algorithm),
> > however it's not clear if that's the approach we want to mandate with
> > the newer postquantum transforms.
> 
> Each Transform ID can also have arbitrary number of attributes inside, and
> the as you can have multiple entries with same Transform Type, but either
> different Transform ID or different Attributes inside, the responder can pick
> exactly one of the Transform Type of that type, and include all attributes
> unmodified.

Actually, I was making this comment in the context of "our proposal" (draft-tjhai-ipsece-hybrid-qske-ikev2-02), which negotiates the additional KE groups not within the IKE transform structure, but as 16 bit integers, and noting that the structure doesn't allow us to pass attributes along with the transform types (which the IKE transform structure does); I was wondering out loud if we would need to support attributes (which haven't been used in the context up until now).

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 1 Nov 2018 15:17:58 +0000

> From: Valery Smyslov <[email-masked]>
> Sent: Thursday, November 01, 2018 7:14 AM
> To: Scott Fluhrer (sfluhrer) <[email-masked]>; 'IPsecME WG'
> <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
> 
> Hi Scott,
> 
> > > 1. Nonces.
> > >
> > 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...

> > >     IKE_AUX content into the calculation. Is it OK, or should we
> > > modify AUTH payload
> > 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.

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.

> > >     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
> > 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.

Given that we don't know which such methods would eventually meet this final criteria of "usable only by itself", I would expect that we would be well advised to include everything on the list.  Even in cases of methods with moderately large key shares (e.g. Frodo), there are times that IKE doesn't care about fragmentation (e.g. TCP encaps), and in those cases, it might very well be considered a viable option by itself.

In addition, you essentially gave two proposals; one where transform type 6 meant "Lattice Based", and another proposal where transform type 6 meant "whatever key exchange we're doing in the first IKE AUX exchange".

Of those two proposals, I would personally vote for the second one; it would appear to me to be cleaner (of course, I would still prefer the tjhai proposal to either...)

> > > methods will be defined
> > >     for each of these new Transform Types. In addition these QSKE
> > > Transform IDs
> > >     (or some of them with a small enough public key) will also be
> > > added to the list
> Or do you mean that we still define new Transform Types, but make all new
> key exchanges available in Transform Type 4 too for the cases where
> fragmentation is not an issue and we don't need classic (EC)DH?

The latter (still define new Transform Types, but also make all new key exchanges available); I see no specific reason to restrict things unnecessarily...

> however it's not clear if that's the approach we want to mandate with the
> newer postquantum transforms.
> 
> But using attributes instead of defining a large number of Transform IDs for
> all possible combination of parameters looks like a good idea - at least we'll
> save a few bytes on the wire and a lot of lines on IANA registry page :-)

Actually, I believe using attributes (rather than distinct transform ids) would add to the payload size (but only slightly).  For example, instead of:

   +-- Transform D-H ( Name = NTRU_3 )

We might have

   +-- Transform D-H ( Name = NTRU )
       +-- Attribute ( Security Level = 3 )

(The "security level" attribute is just what immediately occurred to me; I don't know what actual attribute would make sense...)

In any case, I was just wondering whether we would use attributes as a part of the negotiation (and I suspect that we don't know yet); if we do, that would put the tjhai proposal at a disadvantage...

> 
> > > 3. CREATE_CHILD_SA
> > >
> > >     The draft currently is silent about using QSKE in
> > > CREATE_CHILD_SA exchange.
> >
> > Or, more specifically, using more than one keying mechanism; you can
> > use any single KE for a CREATE_CHILD_SA, either conventional or
> postquantum.
> >
> > Actually, I believe that there is some weasel working saying "you can
> > get this effect by negotiating several child SA's in succession";
> > however, I can certainly understand it if the working group decided that
> was not acceptable...
> 
> Do I get you right that the idea is to negotiate several successive SAs with
> unmodified CREATE_CHILD_SA, each with different (QS)KE methods, so that
> the resulting SA absorbs entropy from all the exchanges?
> That could work for IKE SA (rekeying), but I fail to understand how it will work
> for Child SAs. If you want to create new or rekey existing Child SA with
> additional entropy, then you cannot perform successive key exchanges
> unless you somehow modify CREATE_CHILD_SA exchange. Did I miss
> something?

Actually, the original idea was cruder than that; suppose you wanted to rekey an IPsec SA, and you used three key exchange methods.  What you would do  is:

- First create a child IKE SA (using keying mechanism 1); this would replace the original IKE SA
- Then, create a second child IKE SA (using keying mechanism 2); this would replace IKE SA that you just created
- Finally, create children IPsec SAs (using keying mechanism 3)

As I said earlier, I could certainly understand it if the WG decided that this was unacceptable...

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Nov 2018 11:23:35 +0300

> 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)

That's how I understood it.

> 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.

Sorry for being tedious, I just want to eliminate all possible misunderstanding.

I understand that the nonces exchanged in IKE_AUX are included through complex function.
My concern is about which nonces are included in signature. From my recollection of SIGMA
each party must sign (among other things, e.g. his MACed ID) his peer's nonce. I.e., 
initiator must sign responder's nonce and responder must sign initiator's nonce.
With nonces exchanged in IKE_AUX this is not true, each party signs his own nonces sent in IKE_AUX,
not peer's ones. So, the initiator still signs responder's nonce received in IKE_SA_INIT
but signs only his own nonces that he sent in IKE_AUX exchanges (implicitly, by including AUX_I which is 
PRF over initiator's IKE_AUX messages). The same for responder. 

So my concern is - is it OK that each party only signs his peer's nonce from IKE_SA_NIT
and doesn't sign his peer's nonces from IKE_AUX, signing his own nonces instead?

> Given that we don't know which such methods would eventually meet this final criteria of "usable only by
> itself", I would expect that we would be well advised to include everything on the list.  Even in cases of
> methods with moderately large key shares (e.g. Frodo), there are times that IKE doesn't care about
> fragmentation (e.g. TCP encaps), and in those cases, it might very well be considered a viable option by itself.

OK, this makes sense.

> In addition, you essentially gave two proposals; one where transform type 6 meant "Lattice Based", and
> another proposal where transform type 6 meant "whatever key exchange we're doing in the first IKE AUX
> exchange".
> 
> Of those two proposals, I would personally vote for the second one; it would appear to me to be cleaner (of
> course, I would still prefer the tjhai proposal to either...)

The second one was my preference too.

> The latter (still define new Transform Types, but also make all new key exchanges available); I see no specific
> reason to restrict things unnecessarily...

I agree.

>        +-- Attribute ( Security Level = 3 )

It seems that you are right here and I was wrong.
I was thinking of situation when attributes can define ranges,
in which case we could save some space in some situations, but it is not possible now.

> Actually, the original idea was cruder than that; suppose you wanted to rekey an IPsec SA, and you used three
> key exchange methods.  What you would do  is:
> 

Well, this essentially means that any need to create or rekey Child SA with additional entropy
will require several successive rekeys of IKE SA. How policy will be negotiated in this case?
In IKE_SA_INIT initiator proposes all KE methods at once and responder selects an appropriate
combination. In your proposal initiator proposes them one by one, so that responder
don't have whole picture. You can argue, that policy should non change in case of rekey,
but if you create a new Child SA for with different selectors you would probably
want to create it with different policy, than IKE SA and previous Child SAs... I also suspect 
some complications with simultaneous rekeying...

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Nov 2018 15:57:15 +0700

> On Nov 1, 2018, at 06:03, Tero Kivinen <[email-masked]> wrote:
> 
>> 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).
> 

Indeed, the WG repeatedly said this is not a valid argument. Let’s bury it for good this time.

>   the future

Agreed.

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 2 Nov 2018 16:09:03 +0000

> Sent: Friday, November 02, 2018 4:24 AM
> > > 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?
> > 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
> My concern is about which nonces are included in signature. From my
> recollection of SIGMA each party must sign (among other things, e.g. his
> MACed ID) his peer's nonce. I.e., initiator must sign responder's nonce and
> responder must sign initiator's nonce.
> With nonces exchanged in IKE_AUX this is not true, each party signs his own
> nonces sent in IKE_AUX, not peer's ones. So, the initiator still signs
> responder's nonce received in IKE_SA_INIT but signs only his own nonces
> that he sent in IKE_AUX exchanges (implicitly, by including AUX_I which is

Hmmmm, reviewing your draft, I see your point.  I had assumed that both sides signed a hash of the entire AUX transcript; I now see that both sides sign only what they sent.

Sigma has both sides sign the other side's nonces to avoid potential replay attacks (where the adversary replays a previously recorded signature).

This may be a concern in our case; the first obvious thing to do would be to modify the AUX draft to have both sides sign everything.

So, we would have (in terms of your draft):

AUX_I = [AUX_PRF_I_1 | AUX_PRF_R_1 [ | AUX_PRF_I_2 | AUX_PRF_R_2 [ ... ] ] ]

(and AUX_R could be exactly the same)

Does this sound reasonable?

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 3 Nov 2018 20:41:07 +0700

> > recollection of SIGMA each party must sign (among other things, e.g.
> > his MACed ID) his peer's nonce. I.e., initiator must sign responder's
> > nonce and responder must sign initiator's nonce.
> > With nonces exchanged in IKE_AUX this is not true, each party signs
> > his own nonces sent in IKE_AUX, not peer's ones. So, the initiator
> > still signs responder's nonce received in IKE_SA_INIT but signs only
> > his own nonces that he sent in IKE_AUX exchanges (implicitly, by
> > including AUX_I which is PRF over initiator's IKE_AUX messages). The
same
> for responder.
> 
> Hmmmm, reviewing your draft, I see your point.  I had assumed that both
> sides signed a hash of the entire AUX transcript; I now see that both
sides sign
> only what they sent.

Yes, that was inspired by the current IKE authentication scheme, 
when initiator includes only his IKE_SA_INIT message into the signature and
separately includes responder's nonce (and of course initiator's MACed ID).
Ditto for responder. Following this logic I added only each party relevant
IKE_AUX messages
(thinking of IKE_AUX as of extended IKE_SA_INIT) into their signatures.
Note, that at that time no additional nonces were exchanged in IKE_AUX.

> Sigma has both sides sign the other side's nonces to avoid potential
replay
> attacks (where the adversary replays a previously recorded signature).
> 
> This may be a concern in our case; the first obvious thing to do would be
to
> modify the AUX draft to have both sides sign everything.
> 

II believe yes. And I have no problem with this from implementer's point of
view.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2018 19:04:46 +0200

Scott Fluhrer (sfluhrer) writes:
> 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?"
-- 
[email-masked]