> -----Original Message-----
> From: Valery Smyslov <[email protected]>
> Sent: Thursday, November 01, 2018 7:14 AM
> To: Scott Fluhrer (sfluhrer) <[email protected]>; 'IPsecME WG'
> <[email protected]>
> Cc: [email protected]
> 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 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...)
>
> > > 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?
The latter (still define new Transform Types, but also make all new key
exchanges available); I see no specific reason to restrict things
unnecessarily...
>
> > > 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 :-)
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...
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
