[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A fix for main mode with preshared keys
One additional remark.
Dan Harkins reminded me of the following (in the pk encryption
thread).
Even if SKEYID_e is redefined as discussed, the initiator of a main
mode exchange with preshared keys still needs to know the identity of
the responder before it has received IDir. This is because it needs
to compute HASH_I in the fifth message, and HASH_I is computed using
SKEYID, which in turn is computed using the preshared key. The
preshared key *must* be used in the computation of HASH_I, since this
is what provides the proof that the initiator knows the preshared key.
IKE knows the IP address of the responder, but there are scenarios
where this may not be a "meaningful" form of identity, and where IKE
has no access to a more meaningful form of identity before it receives
IDir. I described one such scenario, involving a dynamically assigned
IP address, in the pk encryption thread. Another scenario could be
constructed in the case where the responder is a multihomed port.
There is also the possibility that a meaningful form identity is
simply not passed to IKE by the software that requests the IKE
exchange.
This difficulty could be resolved by changing main mode with preshared
keys from
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
to
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr, IDir*
HDR*, IDii, HASH_I -->
<-- HDR*, HASH_R
where IDir* is IDir with its body (excluding the "generic payload
header") encrypted under SKEYID_e, which is itself redefined as
discussed.
Francisco
(francisco_corella@hp.com)