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

Re: A problem with public key encrption in IKE

     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.
     
> 
> 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.
     
> 
> 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.
        
     
Pau-Chen
     
> 
> Francisco
> 
> (francisco_corella@hp.com)
>
References: