[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: IKMP Security Exchange Negotiation
Paul Lambert <Paul_Lambert-P15452@email.mot.com> wrote:
(Is that "P15452" a cookie to prevent flooding by junk mail?)
> Example 5 - The cookies are needed when a recipient feels threatened (purhaps
> it just recieved a bogus DH initiation). It is then very important to allow
> the recipient to request a cookie using a stateless response:
> -> (DH,DH1),(KC,)
> <- (KC,)
> -> (KC,KC1)
> <- (KC,KC2)
> ... etc.
Please note that the initial setup message in Karn Cookies is stateless,
i.e. the "KC1" sent from intiator is 0 bits long. (Well, okay, it's the
IP address which is of non-zero size, but it's always included so you
can send the reply, so the size attributable to the protocol is 0.)
I was thinking of this for Photuris, although your technique is more general.
So the second message would be KC2 (the cookie).
The KC exchange is a bit odd, because it's to be used in *addition* to
another protocol. I.e. you then go on to send (DH,DH1),KC2.
Also note that a host that is making multiple connections can cache and
re-use KC2 cookies. But if the cookie gets captured in some
not-quite-on-line attack, the recipient could change it without notification,
so the initiator sends (KC,KC2) and the recipient says "sorry, bad
cookie, here's KC2'". It's basically as if the recipient rebooted,
but connections to it may still be established.
> Example 6 - Example 6 adds two PDUs beyond the cookie exchange. This could be
> reduced if initiators always sent a cookie along with the more common DH (my
> assumption) exchange:
> -> (DH,DH1),(KC,KC1)
> <- (KC,KC2)
> ... etc.
>
>
> Example 6 may not be worth the extra exchange bits if example 5 is an
> uncommon scenario.
It does depend. If I call KC1 the "believed cookie" (what the
initiator hash cached, possibly all zero or something from a previous
boot of the recipient) and KC2 the "true cookie" (computed from the
recipient's secret), then the following options seem plausible.
KC1 is a correct cookie (equal to KC2), while KC1' is an incorrect one.
-> (DH,DH1),(KC,KC1) cookie correct
<- (DH,DH2)
...etc.
-> (DH,DH1),(KC,KC1') cookie incorrect, host doesn't care
<- (DH,DH2)
...etc.
or
-> (DH,DH1),(KC,KC1') cookie incorrect, host doesn't care *now*
<- (DH,DH2),(KC,KC2) just for future reference...
...etc.
or
-> (DH,DH1),(KC,KC1') cookie incorrect, responding host feels threatened
<- (KC,KC2)
-> (DH,DH1),(KC,KC1)
<- (DH,DH2)
...etc.
If you can optionally send a zero-length cookie, then KC1' is very little
overhead when the recipient doesn't care and doesn't send a response. (Case
2, above). Also, the recipient could decide to stop feeling threatened
after a while and start responding to initiations including a cookie by
following case 3, and sending a zero-length KC2 response. This offers
a saving of KC1' overhead, against the risk of having to revert to case 4
if it feels threatened again in future. So presumably it should be pretty
sure of its safety before trading a few bits in a maessage for the risk
of teo more messages and a round trip delay.
--
-Colin