[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A pothole in ISAKMP/Oakley



> From piper@cisco.com Tue Apr 15 14:45:12 1997
> Message-Id: <199704151838.LAA09674@fluffy.cisco.com>
> To: pau@watson.ibm.com
> Cc: ho@earth.HPC.ORG, Dan.McDonald@eng.sun.com, ipsec@tis.com
> Subject: Re: A pothole in ISAKMP/Oakley
> In-Reply-To: Your message of "Tue, 15 Apr 1997 13:25:16 EDT."
             <9704151725.AA22888@secpwr.watson.ibm.com>
> Date: Tue, 15 Apr 1997 11:38:38 -0700
> From: Derrell Piper <piper@cisco.com>
> Content-Length: 2040
> 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.
>

Derrell:

> Correct me if I'm wrong, but there's no longer any security basis for
> having the Phase 2 SPI's be pseudo-randomly generated.  In fact, there were
> implementations at the IPSEC bake-off that used monotonically increasing
> SPI's.  This argues for fixing this in the protocol.
> 
> On the other hand, this is not a problem if you're doing the combined ESP
> for authentication, as you wouldn't then have a separate SA for an AH key.
> I think this is the normal case.

AH still has its value in that it protects the "invariant" parts of
IP header. I remember there was a (big) debate on this in the ipsec list
and we end up with the AH we have today.

> 
> I would like to reitterate what Douglas Maughan pointed out at the
> implementor's discussion last week, which is to remind everyone that the
> ISAKMP framework is specifically designed to accomodate multiple and
> divergent key exchange protocols.  This allows us to cleanly define a new
> key exchange identifier in the future with fixes for "problems" like this.
> This might also include the performance improvements requested by Hugo.
> 
> I don't think this is worth reopening the document to fix.  I'd like to see
> it corrected in the next rev of the protocol, which should have a new key
> exchange identifier in the IPSEC DOI.  In the mean time, the suggested use
> of pseudo-randomly generated Phase 2 SPI's remains a useful recommendation.

If this were a change for performance, I think we should wait for the next rev..
But it is really a change to close a potential security loop hole.

This is a 2-line change to the ISAKMP-OAKLEY doc.
As for the code, the current doc requires the code to take the SPI value
from the PROPOSAL payload header when computing Quick Mode KEYMAT.
The proposed change requires the code to also take the "Protocol-ID"
value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT.
I don't think that is a difficult change.

> 
> Derrell, last seen rooting around his office for the Nomex suit...


Regards, Pau-Chen


Follow-Ups: