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

Re: IPSEC WORKING GROUP LAST CALL



At 10:48 AM 2/26/98 -0500, Henry Spencer wrote:
>>>>1. No data recovery of an encrypted IP datagram payload.
>>>This is a feature, not a bug, by strong consensus...
>>
>>I understand this.  I am certain that this requirement will not change for 
>>the forseeable future, regardless of our consensus.  I am also certain that 
>>this requirement can be met, in a manner that would satisfy our community...
>
>A significant fraction of the community will not be satisfied by any
>protocol which incorporates key recovery.  The objection is not to the
>technical details of key recovery, but to its presence in any form.
>

My view is that it's just another tool to be used to solve certain types of 
problems.  Whether you realize it or not, we have been outmaneuvered by other 
communities with different desires.  Their position is now being reinforced 
by members of the industry who are coming up with solutions meeting this 
requirement.

>Key recovery is readily added by separate mechanisms, e.g. a separate 
>key-escrow system, but is not readily removed if it is present in the 
>central protocol.

You are right, it has to be hooked somehow into each datagram.  

>
>>>>   C. The desire to use a public key algorithm.
>>>Use of a public key algorithm is an engineering necessity, not a desire.
>>
>>Here I think we differ on what the secure IP network model should be.  
>>I believe that it should be a resource owned by an organization or a 
>>company that wants to control access to it and protect their 
>>communications...
>
>What of two organizations which wish to limit access to, and protect,
>their inter-organization communications?  This is not an imaginary
>example:  the auto industry has been pushing IPSEC, because the car
>manufacturers want secure electronic communication with their part
>suppliers.  Note that the pattern of trust and non-trust here is complex,
>and probably could not be satisfied by a single key authority or a small
>number of them:  many of the companies involved are competitors, and the
>supplier relationship is a complex dynamic directed graph, not a simple
>fixed tree.  Any attempt to solve this with private keys ends up inventing
>something vaguely analogous to a public-key system, but more complex and 
>with more vulnerabilities. 
>
>IPSEC, like IP, is not just for single-organization private networks.
>A *general-purpose* cryptographic security system must use public-key
>technology. 
>

Well, let's agree to disagree.  My contention is that the establishment 
of this pattern of trust is equally difficult for PK and symmetric type 
of ciphers, regardless of whether we are talking about intra- or inter-
organization communications.

--
Alex Alten
Andrade@Netcom.Com
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159



Follow-Ups: References: