[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A pothole in ISAKMP/Oakley
> From owner-ipsec@portal.ex.tis.com Tue Apr 15 12:57:42 1997
> From: Dan.McDonald@Eng.sun.com (Dan McDonald)
> Message-Id: <199704151642.JAA14702@kebe.eng.sun.com>
> Subject: Re: A pothole in ISAKMP/Oakley
> To: ho@earth.hpc.org (Hilarie Orman)
> Date: Tue, 15 Apr 1997 09:42:43 -0700 (PDT)
> Cc: ipsec@tis.com
> In-Reply-To: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 am
> X-Mailer: ELM [version 2.4 PL25]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Sender: owner-ipsec@ex.tis.com
> Precedence: bulk
> Content-Length: 415
> Status: RO
>
> > 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.
>
> Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I
> remember the specs correctly. Implementations that do otherwise are probably
> broken.
Dan, the spec does say so. But if an implementation uses a montonically
increasing counter to generate SPI's for ESP and AH, it can interop with
others. So I think it is worthwhile to put in a safeguard.
Also, I would like to emphasize that Ran's msg is about QUICK Mode
KEYMAT derivation in Phase 2. It is NOT about Phase 1.
> Dan
>
Regards, Pau-Chen
Follow-Ups: