[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A problem with public key encrption in IKE
On 12 Dec 1999 18:43:16 -0800, francisco_corella@hp.com wrote :
> 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.
Francisco :
I am one of the co-authors of the original pk-encryption mode draft;
and indeed it was assumed that initiator knows the responder's public key
when it starts the IKE negotiation. But this is really not a bug of
IKE or pk-encryption mode.
IMHO, the problem we have today is that there is a big gap between the
internet names (IP addresses, DNS names, ...) used in IKE and the
(would-be) directory structure (X500) used to search the certificates.
In general, one cannot search a X509 certificate by a DNS name or an
IP address. Using DNSSEC and Dynamic DNS would solve the problem, sadly
the deployment is not there yet.
>
> 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.
You can use signature mode with in-line certificates in this case.
If the remote host cannot produce its certificate and signature,
then most likely pk-encryption mode cannot be used neither.
I must agree with Dan that the gateway will still have a hard time in
determining what to do with a remote host of which the gateway knows
nothing.
>
> 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.
IMHO, IKE should really not be twisted for every conceivable
authentication/application scenarios. Then it would go down the
tube as many OSI protocols, they have a little something for
everyone but becomes too heavy for anyone. I personally think IKE and
IPSEC are meant to provide the basic communication security,
any finer-grain or more sophisticated authentication can be built
on top with added ease and security assurance; but we don't have to
change IKE to get all those.
Pau-Chen
>
> Francisco
>
> (francisco_corella@hp.com)
>
Follow-Ups: