[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A problem with public key encrption in IKE
Pau-Chen,
<<
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.
>>
Well, let's think about this...
It seems that IPSEC implementations select the protection requirements
(what they will propose/accept) for phase 1 and phase 2 together, based on
the identity of the peer. I don't know if this is required by one of the
RFCs, or if that's just the way it's done.
It would make sense, though, to determine the protection requirements for
each phase separately. The protection requirements for phase 1 could be
determined independently of the identity of the peer. (After all, one
purpose of phase 1 is to determine the identity of the peer.) The phase 1
requirements would not be specified by the SPD, they would be selected by
the IPSEC administrator by means that need not be part of the IPSEC
standard. Then the protection requirements for phase 2 could be determined
based on the identity of the peer established in phase 1. These requirments
would be specified by the SPD.
Is this allowed by the RFCs?
Francisco
Follow-Ups:
References: