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

Re: A problem with public key encrption in IKE

     Dan,
     
     See my comments below, marked ***
     
     Francisco


______________________________ Reply Separator _________________________________
Subject: Re: A problem with public key encrption in IKE
Author:  Non-HP-dharkins (dharkins@Network-Alchemy.COM) at HP-ColSprings,mimegw5
Date:    12/12/99 9:28 PM


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. 

          *** This was intended as a new thread, not directly related to 
          the thread concerning MM and preshared keys

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. 

          *** You are right, I had forgotten about that.  This can be fixed, 
          however, if we adopt Hugo's redefinition of SKEYID_e.  To avoid 
          mixing the threads, I will describe the solution in a separate 
          message, on the other thread


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


          *** THE GATEWAY DOES KNOW THE IDENTITY OF THE RESPONDER, AND HAS 
          A POLCY BASED ON THAT KNOWN IDENTITY
          
          Let me try to explain the scenario in more detail.
          
          The gateway is at the edge of the intranet of a corporation, 
          let's call it HiTech, Inc.
          
          The gateway is negotiating on behalf of a client.  The client is 
          a host inside the intranet.

          The client wants to communicate with the laptop of the employee 
          John Smith.  This employee is travelling and is currently 
          connected to the Internet through an ISP which has no relation to 
          hitech.com.  The ISP has dynamically assigned the IP address 
          11.22.33.44 to the laptop of John Smith.  The client has learned 
          this IP address through a previous exchange, that may have gone 
          through the same or a different gateway.
          
          The client sends an IP packet to 11.22.33.44.  The gateway does 
          not have a policy for this IP address.  However, the gateway 
          initiates an IKE exchange with 11.22.33.44 on behalf of the 
          client, and as part of this exchange the laptop identifies itself 
          as John Smith's laptop by sending the distinguished name "CN=John 
          Smith; O=Hitech, Inc; C=US" in the ID payload.
          
          Now the gateway knows who it is talking too, and can look up the 
          appropriate policy based on the distinguished name.

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