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

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

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
Follow-Ups: References: