Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke

[Tobias Brunner <[e-mail]>]

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