[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A problem with public key encrption in IKE
The public key encryption methods for phase 1 authentication require the
initiator to know the public key of the responder, as explained in section
6.1, 4th paragraph of the 5/99 draft. The responder does not have the
option to send its certificate as part of the change. This is unfortunate,
since there are cases where the initiator may have no other way of
obtaining the certificate, e.g. because a certificate repository is behind
a firewall.
A more serious problem, however, is that the initiator may not even know
the identity of the responder. This may seem odd, but it can easily happen
in cases where the initiator is a gateway acting as a proxy for a client.
Suppose the IP address of the responder as been assigned dynamically. The
client may have learned this address in a previous exchange through the
same gateway or through a different gateway. The client may then send an IP
packet to this IP address, and this may cause the gateway to initiate an
IKE exchange with that IP address. In this situation, the gateway, which
is the initiator of the IKE exchange, knows the dynamically assigned IP
address but may not know the "real" identity of the responder, the identity
that determines the public key.
It should be possible to fix these two problems, probably at the expense of
additional messages, by first establishing the DH secret, then exchanging
identities and optional certificates encrypted under a symmetric key
derived from the DH secret, then exchanging the nonces encrypted under the
public keys of the parties.
Francisco
(francisco_corella@hp.com)
Follow-Ups: