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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
