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?
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?
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.
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).
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 types of QSKE,
we can define also Transform Types 9, 10, 11 and so on (how many is enough?)
for yet unknown types of QSKE (populated only with NONE Transform ID for
now).
With this "hack" all new implementations will know what these transforms are
and won't reject proposals with them.
Another problem with this approach is that if we want to express policy
"perform single QSKE of any type" then the number of proposals would
grow, since initiator has to include all the new Transform Types
in each proposal including NONE Transform ID in all but one Transform Type,
different in each proposal.
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.
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?
3. CREATE_CHILD_SA
The draft currently is silent about using QSKE in CREATE_CHILD_SA exchange.
However it seems that QSKE methods must also be supported in this
exchange (at least for IKE SA rekeying). IKE_AUX is specifically designed
to be used between IKE_SA_INIT and IKE_AUTH, so either we must
modify CREATE_CHILD_SA to allow multiple KE payloads or define
some new exchange. My concern is that sending all QSKE payloads
in one message may result in a very large number of fragments, that would
potentially decrease protocol reliability on a lossy networks (if any
single
fragment is lost all fragments must be resent). With IKE_AUX QSKE
are performed one by one, so the number of fragments will be less.
If this is a concern, then some mechanisms need to be defined
that allow to perform QSKE one by one even in CREATE_CHILD_SA.
For example, perform a series of INFORMATIONAL exchanges
linked to CREATE_CHILD_SA to complete QS key exchange:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, Nr, KEr, N(ExchangeID1)}
since initiator proposed and responder agreed upon that
one or more QSKE need to be performed, the new SA is not
created at this point, instead the responder returns some
Exchange ID in a new notification (this Exchange ID allows
to link INFORMATIONAL exchanges with the CREATE_CHILD_SA
and with subsequent INFORMATIONAL). Then initiator starts
series of INFORMATIONAL exchanges (one by one) to complete
key exchange with QS methods:
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.
Any ideas?
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
