[Swan-dev] Question on get_cookie() code

[Andrew Cagney]

On 7 January 2016 at 13:26, Paul Wouters <paul at nohats.ca> wrote:
> On Thu, 7 Jan 2016, Andrew Cagney wrote:
>
>>> Why are you looking at spi cookies at all?
>>
>>
>> Unfortunately, Pluto's old SA proposal matcher for ESP/AH, has code
>> generating SPIs embedded within it (and if we ever rekey ike, it
>> likely should but doesn't).  I suspect the reason (which seems sound),
>> is to delay the RND call until after a proposal is matched.  I'm,
>> well, replicating the behaviour and sketching in the missing rekey-ike
>> bits.
>
>
> I see.
>
>> Speaking of which, for an initial IKE, I believe, when there is no
>> match, the SPI is generated and then discarded?
>
>
> If we are responder and send back NO_PROPOSAL_CHOSEN in response to the
> first IKE message, our SPI should be 0. If the error happens later in
> the exchange, then we have commited to a SPI (and they might resend with
> different proposal values although very unlikely)

Yes, and doing that doesn't end well (read bugs :-).  Same goes for
sending back an SPI and INVALID_KE.

>>> Why does it need a different one?
>>
>>
>> For the moment because the way it interfaces is weird - its like IKE
>> vs ESP vs AH there's duplicated code with no clear rationale.  This:
>>   get_rnd_bytes(spi, spi_size)
>>   DBG_log("XXX: really generate SPI");
>> is much easier for now.  Once SPI exchanges work I can see about using
>> those functions.
>
>
> Ok.
>
>>> Agreed but its weird because these appear in the IKE header, so are
>>> shared between IKEv1 and IKEv2, and IKEv1 calls it cookies not SPI
>>> numbers.
>>
>>
>> Yea IKEv2 has real cookies and these are not it.
>
>
> I'm very much aware of the confusion. I probably have a tshirt somewhere :)
>
>>  In fact, if we
>> suspect we're under some sort of crypto pool attack then isn't the
>> defence to use strong-random cookies?
>
>
> We use a hash so it does not use randomness/entropy while providing
> strong pseudorandom.

Oh, yes.  IKEv2 suggests one.  That's even cheaper, and keeps
attackers away from the entropy pool.