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

Re: A problem with public key encrption in IKE

On Sun, 12 Dec 1999 18:43:16 PST you 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.

What problem are you trying to solve? This thread started because you wanted
to use pre-shared keys in Main Mode and not have to bind that key to an
IP address. But in that case the initiator has to know the identity of
the responder anyway so I'm not sure what's the hold-up here. (Note: cert-
ificates are not required, these can be uncertified public keys which are
distributed in the same fashion as your pre-shared keys).

> 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 
n> 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.

Hmmm. A gateway which has policy to an identity which it does no know. That
sounds like a bogus policy right there. Forget IKE. How would you express
"I want to protect packets from 'host X' to 'somewhere interesting'" if you
can't know the identity of "somewhere interesting" a priori!? How would you
know what to protect in that case? It doesn't seem you would. So an invalid
policy which cannot be expressed in IKE doesn't seem like a problem.

> 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.

What problems? You want to have a way to not bind a key to an IP address.
Fine, use uncertified public keys. Then you want to have policy to a wildcard.
Sorry, but things just don't work that way, and that has nothing to do
with IKE.

  Dan.
Follow-Ups: References: