Hi Scott,
Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote:
> - It defines the transform of the nonce from the on-the-wire version into
the
> one presented to the IKEv2 KDF (mixing in the PPK).
> - The initiator gives an indication of which PPK to use (without leaking
any
> information about it to someone two doesn’t know the value).
> For the first use, it would be reasonable to have the initiator define a
> bitmask of the algorithms it supports, and the responder to select one
That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
IANA values for all the algorithms involved? (shouldn't we have them)
The 'bitmask idea' was off the top of my head; we could certainly give a list of
IANA values (such as the IKEv2 PRF). My chief fear is that we don't
overengineer
this; this really is a "short term solution" (with the usual caveat that there
are no
short term solutions), and that a post-quantum DH-like function is the Right
Thing
(only we haven't agreed on that yet). The issue with having a complex
negotiation
process is that may be a lot of rarely executed code, and that in itself may
lead
to security vulnerabilities.
Is it possible to use the already negotiated IKEv2 prf inside the modified
crypto formulas?
In this case they would look like:
SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
(SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)
and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't
it?
In this case no additional negotiation is required since prf is negotiated in
IKEv2
anyway and thus we would have algorithm agility in KDF for free.
> This second use is rather trickier to have agility; it is sent before the
> initiator has any contact to the responder. I don’t see how the
> responder can
> indicate which algorithms it supports (without adding a round trip to the
> protocol).
This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.
One of the constraints that we felt we had to live within was to minimize
the changes we made to IKEv2, both from a crypto standpoint, and from
a state machine standpoint. Hence, we decided that adding vendor
id payloads (or notification payloads) to existing messages we OK,
however adding additional round trips was out of bounds.
Note, that IKEv2 state machine has already accomodated the possibility
of an additional round trip in case the initiator has incorrectly guessed the
DH group. Introducing one more condition for additional round trip
should not be too hard, however I agree that it adds some complexity
and thus may be considered inappropriate for a short-term solution.
However, if no better solution exists I'd prefer to live with a single
fixed crypto primitive, than with two. Is it possible to get rid of
AES and to change the indication of the ppk to use to something
like the following?
HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)
(disclaimer: I'm not a cryptographer)
If one were to add additional round trips, a cleaner solution would be
to negotiate the initial IKE SA as per the RFC, and then if the two sides
decide that they need QR, create a child SA (in a PQR manner).
The current approach has the issue that we need to stir in the post-quantum
magic before the identities were exchanged (and hence the initiator gives
the indication of the ppk). If you establish a secure connection (and exchange
identities) first, then it becomes much cleaner (as both sides would know who
they are talking to, and which ppk they should use). However, that was
deemed to be too large of an delta.
I'm not sure this approach is easier than approch with additional round trip.
I understand that it has some advantages (e.g. no need for linear key search),
but from state machine point of view it may appear to be more complex.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
