On Aug 9, 2017, at 2:12 PM, Michael Richardson
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
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