Hi Paul,
Trying to clarify some things from my experience implementing this
extension. The authors might have some more insights on these points.
Key exchange methods negotiated via Transform Type 4 MUST always take
place in the IKE_SA_INIT exchange. Additional key exchanges
negotiated via newly defined transforms MUST take place in a series
of IKE_INTERMEDIATE exchanges, in an order of the values of their
transform types, so that key exchange negotiated using Transform Type
n always precedes that of Transform Type n + 1.
I don't understand this section, specifically the use of "Transform Type 4"
and "Transport Type n+1", as we only have transform type 5 and nothing
higher and that is Extended Sequence Number.
The documents defines additional transform types for the additional key
exchanges.
I think it might be trying to say if there are more than one Key Exchange,
that the subsequent key exchange should follow in the next IKE message
exchange (eg in a round of IKE_INTERMEDIATE) ?
They should, but the exchanges should also be performed in order. So if
e.g. algorithms for Additional Key Exchange 1 and Additional Key
Exchange 2 are negotiated, the key exchange for Additional Key Exchange
1 has to be done before the one for Additional Key Exchange 2.
Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange
method.
I don't understand why there is this limitation. What if some Key
Exchange mechanism will require 2 RTTs. Why preventively forbid that?
That would be a new type of key exchange that couldn't be used with
IKEv2 as it is currently defined (neither for IKE nor Child SAs). But I
think you misunderstood. What the above means is that you can't send
two KE payloads in a single IKE_INTERMEDIATE exchange (i.e. you can't
send the KE paylaods for Additional Key Exchange 1 and Additional Key
Exchange 2 if algorithms were negotiated for both).
Additional key exchange methods are proposed
using Additional Key Exchanges transform types. All these transform
types are optional, the initiator is free to select any of them for
proposing additional key exchange methods. Consequently, if none of
Additional Key Exchange transforms are included in the proposal, then
this proposal indicates performing standard IKEv2, as defined in
[RFC7296].
So how does an intiiator convey that it deems an additional Key Exchange
to be mandatory?
It proposes the respective transform type without adding NONE. What the
above means is that the initiator can freely choose to propose e.g.
Additional Key Exchange 1, but not Additional Key Exchange 2 and 3, and
Additional Key Exchange 4 (for whatever reason, maybe each transform
type is somehow linked to a specific class of algorithms in this
implementation and it only has some of them available). Or it can also
not propose any of them or include NONE in some or all of them to leave
it up to the responder if a specific key exchange is performed.
If the initiator includes any transform of type n (where
n is among Additional Key Exchanges) in the proposal, the responder
MUST select one of the algorithms proposed using this type. A
transform ID NONE may be added to those transform types which contain
key exchange methods that the initiator believes are optional.
And so I again do not understand this. What is "n" here? a new transform
type ? ( eg n=6 ??) or a new entry in the Transform Type 4 Key Exchange
registry?
Yes, a new transform type (Additional Key Exchange 1-7), not a new entry
in the registry for transform type 4.
At his point, the Additional Key Exchange is introduced, and I am
beginning to understand things. This should really be explained before
the text I pointed at above to make any sense to the reader. And see
below on placing "Additional Key Exchanges" into the "Key Exchanges"
Registry.
I see :)
The next part explains the CREATE_CHILD_SA and IKE_FOLLOWUP_KE exchanges. I
personally would prefer that a different exchange than CREATE_CHILD_SA
is used if the completion of such an exchange does not lead to a fully
rekeyed state. This use of completing a CREATE_CHILD_SA and being in a
state that is not "rekeyed" or "failed" complicates the state machine.
Until the proposals are negotiated during the CREATE_CHILD_SA exchange,
the initiator doesn't know if any new mechanisms or exchanges are
needed. And because a PQ-safe IKE_SA protects the negotiation of
additional CHILD_SAs or their rekeying, classic key exchanges could be
considered perfectly safe for those if forward secrecy is desired.
The data associated with this notification is a blob meaningful only to
the responder
Why a blob? Why not the imminent new SPI it generated for this new IKE SA?
If you really want a blob, there should be an example of how to generate
the blobs. I don't see any such guidance in the document.
As the text says, it's a completely arbitrary blob of data. So you
could use the allocated SPI if that's helpful to you. In my
implementation (with Window Size 1) I just use a static, single-byte
value as it really doesn't matter.
Below is an example of three additional key exchanges.
Initiator Responder
---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)}
Why does the initiator not start out with a N(ADDITIONAL_KEY_EXCHANGE) ?
There has been an Additional Key Exchange in the initial exchanges, so
why not start out with one in the rekey from the initiator?
Because this notify is only for the responder to associate
IKE_FOLLOWUP_KE requests with the state it created for the original
CREATE_CHILD_SA exchange. As mentioned above, it's basically irrelevant
for implementations with Windows Size 1, but if that's not the case, the
initiator might initiate multiple CREATE_CHILD_SA exchanges concurrently
and that might result in multiple IKE_FOLLOWUP_KE requests that the
responder later has to associate with the correct states.
What would an initiator do if the responder omited N(ADDITIONAL_KEY_EXCHANGE) ?
It has given no indication it might be mandatory from the initiator's point of
view.
It's mandatory from the protocol's point of view. I guess the behavior
could be clarified (e.g. demand that the initiator sends an
INVALID_SYNTAX notify in a new INFORMATIONAL exchange).
It is possible that due to some unexpected events (e.g. reboot) the
initiator could forget that it is in the process of performing
additional key exchanges and never starts next IKE_FOLLOWUP_KE
exchanges. The responder MUST handle this situation gracefully
And wouldn't that solve this weird state issue if the initiator already
signalled this clearly in CREATE_CHILD_SA, so the responder could in
that case already return an error in the CREATE_CHILD_SA exchange?
Note that I find the argument weird, why would an IKE peer forget some
of its state after a reboot? Both peers should always remember AKE's
were used and have to be used again upon (PFS) rekeys.
It's not about the configs but the runtime state. Your implementation
doesn't persist all the IKE and IPsec SAs and their state during a
reboot, right? So it's similar to half-open IKE_SAs where the initiator
might never send an IKE_AUTH (or IKE_INTERMEDIATE) message because it
rebooted or there was a network issue. Because the operation initiated
by the CRATE_CHILD_SA request is not complete with sending the
CREATE_CHILD_SA response if additional KEs are used, the responder is in
a situation where it might wait for an IKE_FOLLOWUP_KE request indefinitely.
However, I'm not sure if there is any benefit in setting a timer and
only removing the state associated with the CREATE_CHILD_SA exchange as
it seems unlikely to me that the initiator would only lose the state for
a single such exchange and later initiate a different exchange on the
same IKE_SA. So maybe removing the complete IKE_SA might be the better
approach (or just don't do anything and rely on DPDs initiated by the
server to resolve this).
it MUST send back a new error type notification STATE_NOT_FOUND.
This is a non-fatal error notification
[...]
If the initiator receives this notification in
response to IKE_FOLLOWUP_KE exchange performing additional key
exchange, it MUST cancel this exchange and MUST treat the whole
series of exchanges started from the CREATE_CHILD_SA exchange as
failed.
So why use a non-fatal error notification that leads to a guaranteed failure ?
"non-fatal" refers to the IKE_SA. The operation (rekey or Child SA
creation) initiated by the CREATE_CHILD_SA request is aborted but can
get restarted if deemed necessary by the initiator. But as mentioned
above, I'm not entirely sure if the timeout set on individual
CREATE_CHILD_SA exchange states makes sense.
Note there seems to be a notion of AKE's having continuous state, as
opposed to (EC)DH where you start a new state with the rekey exchange.
Perhaps this should be clarified at the beginning of the document?
Where do you get that from?
This document adds the following Transform Types to the "Transform
Type Values" registry:
Type Description Used In
-----------------------------------------------------------------
<TBA> Additional Key Exchange 1 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 2 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 3 (optional in IKE, AH, ESP)
<TBA> Additional Key Exchange 4 (optional in IKE, AH, ESP)
Why are the descriptions referring to "additional" key exchange? I would
assume the registry is just a list of Key Exchange types, and whether
one of these is "additional" or not depends on its use in IKE ? That is,
one of the Key Exchanges that today is "additional" might one day be
used as the only Key Exchange without Additional Key Exchanges? If we
really are making some of these exchanges as "additional use only", then
we should really create a new transform type registry for AKE that is
separate from the Key Exchange Type (4).
They are additional to the default key exchange with transform type 4.
Since the algorithms for all of these are from the same registry (that
for transform type 4) there is nothing (except maybe IP fragmentation)
preventing you from using new PQ-safe algorithms with transform type 4
during IKE_SA_INIT. So it's not that any algorithms are considered
additional it's the key exchanges negotiated with those transform types.
Regards,
Tobias
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
