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

Re: A problem with public key encrption in IKE




Francisco, please see my comments below


Regards, Pau-Chen

------------------------------------------------------------------

On Tue Dec 14 11:36:48 1999, francisco_corella@hp.com wrote

> 
>      Pau-Chen,
>      
>      See my comments below, marked ***
>      
>      Francisco
> 
> 
> ______________________________ Reply Separator ____________________________
> Subject: Re: A problem with public key encrption in IKE
> Author:  Non-HP-pau (pau@watson.ibm.com) at HP-ColSprings,mimegw5
> Date:    12/13/99 8:53 AM
> 
> 
>      
>      
>      
>      
> 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.
> 
>         *** By the simple expedient of having the parties provide their 
>         certificates you can remove the dependency of IPSEC on these 
>         other deployments.

Please see my comments below.

>      
> > 
> > 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.
> 
>         *** Hopefully the more detailed scenario that I provided in an 
>         earlier message has cleared this objection.  The gateway may not 
>         be familiar with the dynamically assigned IP address of the 
>         responder, but may be familiar with some other form of identity 
>         submitted by the responder (in the ID payload) during the 
>         exchange.

I think you may have a point here. But if I understand your scenario correctly,
the gateway has to initiate the IKE exchange with the remote host of which
the gateway knows nothing. So the gateway may have difficulty in determining
what to propose. Of course, a catch-all wildcard entry in the gateway's
policy may solve the problem; but I am not too sure about the wildcard's
security implication.

>      
> > 
> > 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.
> 
>         *** I would agree with that, but then why have two forms of 
>         public key encryption in addition to digital signatures and 
>         preshared keys?  If we do have support public key 
>         encryption, we may as well make it as broadly applicable as 
>         possible.
>

Having two forms of public key encryption modes came from some
miscommunication we (I, Hugo and Ran) had with Dan.

As for your proposed solution, the problems I have with it are :

   1. It introduces yet another new exchange type into ISAKMP.

   2. An initiator or a responder may be revealing its ID to
      an unknown party. The publick-key modes, as they are now,
      do not have this problem.
         
>      
> Pau-Chen
>      
> > 
> > Francisco
> > 
> > (francisco_corella@hp.com)
> > 
> 
>
Follow-Ups: