[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