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

Re: A problem with public key encrption in IKE (long)

     
Scott,

   <<
     > You cannot authenticate a host that's behind a sgw by conducting phase 1 
     > exchange with the sgw.
     
     I disagree. It is possible to configure the sgw to represent (in an 
     authenticated manner) hosts which it protects in at least 2 ways: first, 
     the sgw may be configured with a private key and a matching cert containing 
     the protected endpoint's DN. This implies that the responder trusts the sgw 
     to act on the endpoint's behalf in this regard. A second way is to bind 
     attribute certs containing authorization info for specific endpoints into 
     the sgw's identity cert.
   >>

OK.  

   <<
     In the first case, individual phase 1 SAs are required for each phase 2 
     identity. In the second case, a single phase 1 SA could conceivably be used 
     for any phase 2 SA, provided that the phase 2 SAs did not require PFS. As 
     far as I know, currently deployed IKE implementations mostly support only 
     the first case.
   >>

Notice that, in the first case, you can still use the same policy for the 
individual phase 1 SAs, and then choose the phase 2 policy after phase 1 has 
revealed the identity of the peer.

Francisco


______________________________ Reply Separator _________________________________
Subject: Re: A problem with public key encrption in IKE (long)
Author:  Non-HP-skelly (skelly@redcreek.com) at HP-ColSprings,mimegw5
Date:    12/22/99 8:24 AM


Hi Francisco,
     
francisco_corella@hp.com wrote:
> 
> Scott,
> 
>         <<
>         Of course, you are right, and this is how the ID PFS requirement 
>         should be specified. Another issue which occurs to me is that
>         phase 2 IDs with respect to authentication are currently tied to 
>         the phase 1 SA. If a security gateway (sgw) is to provide
>         individualized authentication for hosts which it protects, it 
>         must use unique IDs for phase 1. These IDs must be tied to the
>         phase 2 SAs which they authenticate, and I think this means that 
>         phase 1 configuration is tied to phase 2 configuration. Do you
>         have a model which simplifies this? 
>         >>
> 
> What do you mean by "individualized authentication"?  What are the 
> unique IDs?
>
     
The unique IDs may be DNs which are tied to particular hosts behind the 
sgw.
     
> You cannot authenticate a host that's behind a sgw by conducting phase 1 
> exchange with the sgw.
     
I disagree. It is possible to configure the sgw to represent (in an 
authenticated manner) hosts which it protects in at least 2 ways: first, 
the sgw may be configured with a private key and a matching cert 
containing the protected endpoint's DN. This implies that the responder 
trusts the sgw to act on the endpoint's behalf in this regard. A second 
way is to bind attribute certs containing authorization info for specific 
endpoints into the sgw's identity cert.
     
In the first case, individual phase 1 SAs are required for each phase 2 
identity. In the second case, a single phase 1 SA could conceivably be 
used for any phase 2 SA, provided that the phase 2 SAs did not require 
PFS. As far as I know, currently deployed IKE implementations mostly 
support only the first case.
     
>  All you can do is, in phase 2, initiate a quick
> mode and send an SA proposal for a specific client identified by Idi2
> (using the notations of the 5/99 Ike draft).  I believe you can initiate 
> different quick modes with different proposals for different clients,
> all protected by the same phase 1 SA. 
> 
> If you want to authenticate a host "behind" the sgw then you have to
> talk directly to that host.  You could do that through a tunnel that you 
> have previously set up with the sgw, e.g. if you want to avoid
> disclosing the IP address of the host.
     
See above.
     
> 
>         <<
>         One other option that may be provided at the phase 2
>         (negotiation) level is key PFS. While I agree to some extent with 
>         your assertion, I think that you imply that every phase 1 SA
>         should provide for key PFS automatically. Is this right? 
>         >>
> 
> Why would I imply that?  Key PFS is also a phase 2 feature that can be
> selected or not selected after phase 1 has determined the identity of the 
> peer.
     
I was (mis)interpreting the following comment:
     
> Every phase 1 SA should provide sufficient protection to protect 
> negociation of any phase 2 SA that may have to be established.
     
I think you are correct that key pfs could be provided by a given phase 
1 SA on an ad hoc basis, with the caveat that once provided, at minimum 
one additional KE payload would be required to service the next phase 2 
consumer (since the one sent on behalf of the PFS consumer could not be 
re-used).
     
Scott
References: