[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A pothole in ISAKMP/Oakley
> From ho@earth.hpc.org Tue Apr 15 10:15:11 1997
> Date: Tue, 15 Apr 1997 09:50:44 -0400
> From: ho@earth.hpc.org (Hilarie Orman)
> Message-Id: <199704151350.JAA26384@earth.hpc.org>
> To: canetti@watson.ibm.com
> Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com
> In-Reply-To: Yourmessage <199704150414.VAA27630@baskerville.CS.Arizona.EDU>
> Subject: Re: A pothole in ISAKMP/Oakley
> Content-Length: 563
> Status: RO
>
Hilarie :
> The basic problem was noted in January, and the fragility of the use
> of the SPI was also noted then. My preference is to include a state
> variable with SKEYID that is an instance number; the state variable
> gets incremented every time keying material is generated, and the
> keying material depends on the variable.
This may require some tight synchorization between I and R to
keep the instance number in sync. I prefer not to do that.
>
> I will note, however, that if the SPI's are pseudo-randomly generated,
> as is required by the spec, then the probability of using the same SPI
> twice should be extremely low. So the implementations that revealed
> this problem were defective.
Yes. But the fix suggested in Ran's msg make the protocol immune to such
"defect". Besides, there is value to use non pseudo-random SPI's for ESP
and AH SA's (such as array indices to speed up SA look-up); I agree that
for ISAKMP SA's the SPI's (cookies) should be pseudo-random to counter
clogging attacks.
>
> Hilarie
Regards, Pau-Chen