On Aug 9, 2017, at 2:12 PM, Michael Richardson 
<mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> wrote:
I don’t find the re-use of transform 4 in this proposal, and the
implicit combination of QS + non-QS algorithms, to be the most elegant,
though I can understand it in the context of not wanting to add a new
transform type.

So you are suggesting that the QR mechanism be a new transform type then?
I could live with that actually since it make the combinatorics easier to 

Yes, I’m suggesting reconsidering putting the QR key agreement algorithms in a 
new transform type. This is part of CJ’s & co's suggestion from the original 
draft, but this was rejected in Prague. Their transform type was added to the 
proposals in the SA payload, while I’m suggesting only using it in a new QS_SA 
payload. (Perhaps eventually it could migrate to the SA payload in future 
drafts if non-QR connections ever need to be removed from IKEv2).

The idea is to add the new transform type 6 (Q-S-Group) like CJ’s
proposal, but don’t include it in the SA payload. Rather, introduce a
new QS_SA payload which would be identical in structure to the SA
payload except that it would also include the Q-S-Group transform
type. An endpoint could configure the proposals in this payload to

I don't think we need to do this.
I think that unknown transform types will be ignored by compliant

The reason why the original suggestion was rejected in Prague was because of 
backwards compatibility issues with non-compliant implementations. From 
experience, StrongSwan is non-compliant in this regard. If it receives a 
proposal with a transform type that it doesn’t understand it will pretend that 
the transform type isn’t there rather than rejecting the proposal and moving on 
to the next one. Thus it can end up responding with a proposal which the 
initiator didn’t suggest.

For example, if the initiator is configured to send:


A non-upgraded StrongSwan will reply with:


which from the initiator’s perspective is not one of its suggestions. The 
initiator will then error out and fail to establish the connection. We could 
define this new transform type as optional and hope that other implementations 
don’t behave even more poorly than this. But maybe an initiator doesn’t want to 
use aes256-sha512-modp3072 if it’s not talking to an upgraded responder, maybe 
for performance reasons it would prefer using weaker primitives with them.

Putting the QS proposals in a separate QS_SA payload would also allow an 
initiator to mark the payload as critical if it wants to require QS connections.

Something to keep in mind is that many QS key agreement algorithms
don’t have exactly the same message flow as Diffie Hellman. With DH,
each endpoint’s public/private keys can be generated independently of
each other. But many QS algorithms have an initiator-responder flow, so
the responder can only generate its public key once it has processed
the initiator’s public key. We just need to keep this in mind when
designing the flow of the PRE_AUTH messages. An initiator can’t send
the first chunk of a public key, and the responder reply with the first
chunk of their public key, the responder would need to process all
initiator chunks for that key first. This means the initiator would
have to send a special acknowledgement response for chunks that don’t
complete a public key rather than responding with a partial key when
receiving a partial key.

Would the initiator know how much data to expect from the responder?
If so, the initiator can just keep sending query messages to get new blocks
of data back.

I’d answer that with a tentative yes. From the algorithms I’ve seen that’s the 
case, though one could imagine an algorithm where some (possibly 
non-deterministic amount of?) padding is added for some reason or other? 
Regardless, even if the initiator doesn’t know the amount of data to expect, it 
can keep querying and the responder payload could include a terminator flag 
indicating it is the last chunk of data.

If we decide that we want to be able break up the QR public key payloads across 
multiple message exchanges, then do we have to add some mechanism for the 
endpoints to agree on the maximum size of each message? Declaring a chunk size 
as part of the spec may not be a good idea because some QR public keys are 
~1.5Kb while others are >64Kb. So picking a small chunk size to avoid IKEv2 
fragmentation means many message exchanges when using large key sizes, but 
picking large chunk sizes increases the changes of dropping IKEv2 fragments and 
having to retransmit entire messages.

Daniel Van Geest (daniel.vange...@isara.com<mailto:daniel.vange...@isara.com>)

IPsec mailing list

Reply via email to