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

Re: A problem with public key encrption in IKE



Scott,

        <<
        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. 
        >>
        
I'm not sure I understand this point.  I think you are saying that you 
want to specify ID PFS for some cnnections but not others.  That's fine, 
but I don't see the difficulty.  ID PFS can be specified as a phase 2 
requirement.  

Suppose IKE receives a request to establish a phase 2 SA.  The request 
specfies an IP address.  There may or may not be already a phase 1 SA 
for that IP address.  If there is one, IKE can find out the identity 
associated with it, and use that identity, together with the port and 
protocol info in the request, to look up the SPD and decide whether to 
provide ID PFS or not.  (If ID PFS is not needed IKE may reuse the phase 
1 SA; if it is needed, IKE must use a new phase 1 SA, and get rid of it 
after establishing the phase 2 SA.)  If there is no existing phase 1 SA 
for that IP address, IKE sets one up and finds out the identity of the 
peer.  Then it looks up the SPD and decides whether ID PFS is needed or 
not.  (If needed IKE will delete the phase 1 SA after using it, 
otherwise it will keep it.)

        <<
        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?
        >>

Every phase 1 SA should provide sufficient protection to protect 
negociation of any phase 2 SA that may have to be established.

I understand the need to provide different levels of protection for phase 2 
SAs, e.g. encryption is expensive and may be needed on an Internet 
connection but not on an intranet connection.  But I don't see much 
motivation for skimping on the protection level for a phase 1 SA.  For 
example, using DES instead of 3DES won't give you much of a performance 
improvement.

Francisco
     
     




Follow-Ups: References: