[Swan-dev] ikev2parent_inI1outR1 parsing questions

[Andrew Cagney]

On 20 January 2016 at 16:59, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 20 Jan 2016, Andrew Cagney wrote:
>
>> Um, what is "connection switching"?
>
>
> We answer IKE_INIT, they come back with IKE_AUTH. We then check if there
> is a better matching connection to switch to.

In IKEv2, the only way the initiator is going to encrypt and the
responder decrypt that IKE_AUTH packet is by using the KE and proposal
agreed to during IKE_INIT.

> for example, say one is authby=secret and the other authby=rsasig, then
> in IKEv2 we will only know the difference during IKE_AUTH. If we
> happened to have taken the initial packet on the conn with
> authby=secret, we need to switch.
>
> This is why later in the IKE negotiation we can find out the KE payload
> we had is actually not valid (because we had to switch connection)

I suspect there's something else I'm missing.

>>> vendorid information might go onto the state, but that assumes there
>>> is a state. For NO_PROPOSAL_CHOSEN or INVALID_KE we would not need it,
>>> unless later in life we need to do some workaround based on VID.
>>
>>
>> The current IKEv2 code seems to simply log the values received (but I
>> could easily be wrong).
>
>
> Yes. we are not acting on any kind of VID right now.
>
>> Without the proposal:
>>
>> - the keying material is the wrong size for the group being proposed;
>> this would be a new test lifted from accept_KE
>
>
> If there is no proposal matching the KE offered I'm fine with only
> rejecting it later on when we are going through the proposals. The
> client is stupid and so they can wait :P

>> - the group isn't in any of the local proposals at all; this is
>> stronger than the current code which just checks that lookup_group()
>> isn't NULL
>
>
> But if they have another proposal value that is not the one they picked
> for KE, then we can send back INVALID_KE with a value that matches a
> mutually agreeable group. If there is no group that is shared between
> initiator and responder, NO_PROPOSAL_CHOSEN should be returned instead
> of INVALID_KE.

Ah, you'd like to play nice :-)

The existing code:

-        struct ikev2_ke *ke = &md->chain[ISAKMP_NEXT_v2KE]->payload.v2ke;
-        st->st_oakley.group = lookup_group(ke->isak_group);
-        if (st->st_oakley.group == NULL) {
-            /*
-             * It is arguable what to do here: reply with
-             * INVALID_SYNTAX; reply with INVALID_KE and
-             * no group; reply with INVALID_KE and a group
-             * that matches; or reply INVALID_KE and the
-             * default group.
-             *
-             * Go with the last one so that, for little
-             * cost, a legitimate initiator gets a hint as
-             * to the problem.
-             */

I believe:

- sends back INVALID_KE(default)

causing remote end to come back with a KE we might consider, and then either:

- sends-back (I hope) INVALID_KE(correct ke); causing the remote end
to come back with KE we'll hopefully agree to
- or, no proposal chosen

either way we give their end some extra work

>> and with the proposal:
>>
>> - the KE matches the group in the chosen proposal
>>
>> In the case where NO_PROPSOAL_CHOSEN and INVALID_KE are both true,
>> does it matter which fail we send back?
>
>
> If there is a potentially matching group, we should send back
> INVALID_KE. If there is not, send back NO_PROPSOAL_CHOSEN.

Ok.

Once the proposals are being parsed before DH I'll remove the
INVALID_KE pre-check.

Andrew