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

A pothole in ISAKMP/Oakley




Folks,

Pau-Chen and I just stumbled over a pretty significant security pothole in the 
ISAKMP/Oakley draft. I believe it's important enough to mandate 
the appropriate change, as annoying as it may be. Luckily, the required 
change is small.

Assume that the same instance of quickmode is used to create two different SA's 
(say, one for AH and one for ESP). The current method for deriving  KEYMAT 
allows unsuspecting implementations to have the same KEYMAT for the two
SA's. This situation - two SA's with the same KEYMAT - is a cryptographic
show stopper. (See my note to the list from earlier today
about the hazards of using the same key for two different
algorithms/purposes.)

Details: 
The problem: Currently, KEYMAT is calculated as follows: (page 15)

KEYMAT = prf(SKEYID_d, SPI | Ni | Nr)
or
KEYMAT = prf(SKEYID_d, g^xy | SPI | Ni | Nr)

In either case, the only field that makes the KEYMAT of the two SA's
different is the SPI. However, do the SPIs of the two SA's need to be 
different? Here the opinions differ...

ISAKMP draft 07 (section 2.1) says:

   "Each security protocol has its own ``SPI-space''.
    A (security protocol, SPI) pair may uniquely identify an
    SA. Depending on the DOI, additional information (e.g.  host address)
    may be necessary to identify an SA."

The IPSEC architecture document says:
  
   "The combination of an SPI and a destination address uniquely 
    identifies a simplex security association". 
    
In practice, we have actually encountered during interop tests an 
implementation where two such SA's had the same SPI!


The fix:
The goal is, as usual, to avoid having the security of the
protocol rely on architectural issues such as whether the SPI's should be
different or not. Specifically, A relatively simple fix is to add 
protocol-ID as an additional input to the prf in the computation of KEYMAT.  
This way, we will be assured that the inputs to the prf differ between the 
two SA's, thus the two SA's will have cryptographically independent  
values of KEYMAT.

That is, define

KEYMAT = prf(SKEYID_d, protocol-ID | SPI | Ni | Nr)
or
KEYMAT = prf(SKEYID_d, protocol-ID | g^xy | SPI | Ni | Nr)




Ran Canetti