[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A problem with public key encrption in IKE
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?
You cannot authenticate a host that's behind a sgw by conducting phase 1
exchange with the sgw. 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.
<<
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.
Btw, how does one negotiate key PFS? It seems that the quick mode
initiator dictates whether key PFS is used or not by sending or not
sending the KE payload. Is that right?
Francisco
Follow-Ups:
References: