[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A problem with public key encrption in IKE
Hi Francisco,
francisco_corella@hp.com wrote:
<trimmed...>
> 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.
>
The requirement for ID PFS may be specific to the peers, i.e. I may
require ID PFS for my connections, while other folks I work with do not,
meaning they may share phase 1 SAs with one another, while I will not.
If you divorce the phase 1 security requirements from the phase 2
security requirements, you remove this capability. Also, as a phase 2
consumer, what assurance would I then have that the protection level of
the phase 1 SA is sufficient to protect negotiation of my perhaps highly
secured phase 2 SA?
Scott
Follow-Ups:
References: