[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
At 01:52 AM 2/23/98 +0000, Steven M. Bellovin wrote:
>At 05:13 PM 2/22/98 -0800, Alex Alten wrote:
>>IPSEC WG,
>>
>>These are my main technical criticisms of the current set of IPSEC
>>documents.
>>
>>1. No data recovery of an encrypted IP datagram payload.
>>
>> Regardless of the merits of the design by not supporting this
>> requirement it will probably kill IPSEC as a viable Internet
>> standard.
>
>This is a feature, not a bug, by strong consensus of not just the working
>group, but also the entire security area.
>
>You are, of course, free to buy IPsec software from vendors who implement
>some form of key recovery, if that meets you operational or philosophical
>needs. We chose not to standardize something like that -- the IETF is an
>international group; in our judgment, the best technical results are
>obtained by not implementing such features, especially for communications
>protocols. See RFC 1984 for the IAB's and IESG's views on the subject.
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,
and still be technically excellent. I strongly feel that it should be an
integral part of the IPSEC design to ensure interoperability and to help
product vendors meet the requirement.
>>
>>
>>2. Interoperability requirement not met.
>>
>> To ensure interoperability only one cryptographic mechanism should
>> specified, and no others should be allowed. The current proposal
>> allows an unlimited variety to be used, it seems primarily to allow
>> the standard to scale cryptographic strength upwards. The requirement
>> for DES-CBC to be always implemented cannot be met because objection
>> #1 cannot be met with it. Probably RC4 with 40b keys will become
>> the de facto interoperable mechanism (this has happened to SSL).
>
>To promote interoperability, a minimum set of algorithms was specified.
>Designing a mechanism that only permitted one to be used is very unsound,
>from a cryptographic perspective.
>
I disagree with you. The US electronic funds transfer network has used
only one cipher for over 20 years. From a software engineering perspective
allowing more than one is a poor design, leading to unnecessary complexity
and making interoperability much more difficult.
>>
>>
>>3. IPSEC does not properly fit with the IP routing model.
>>
>> It force fits the concept of a security session (SA) onto the IP
>> datagram routing model. Certainy the concept of a user id does
>> not fit the IP address model. The requirement that AH must know
>> about the IP header structure breaks the general rule of protocol
>> layering.
>
>The concept of an SA is necessary if one ever wishes to rekey. The
>desire for user-oriented keying, though somewhat controversial, is at
>least partially driven by some of the results in a paper of mine ("Problems
>with the IP Security Protocols"; see the bibliographies or check
>http://www.research.att.com/~smb/papers/badesp.{ps,pdf}). I think
>you're right about the AH design; others felt differently.
>
I am very uncomfortable with the use of SA for end-to-end hosts (assuming
an intervening set of routers). This is more of a transport service.
The SP3 you mentions sounds like it might be a good model. Do you
have a URL to a description of it?
>>
>>
>>4. The design is too complex
>>
>> This design seems to have been driven primarily by the following.
>>
...
>>
>> B. The desire to use a proven cipher, i.e. DES.
>>
>> This decision has had a profound impact on the design. Because
>> DES is slow, it has forced encryption & decryption to the edge
>> hosts, requiring the SA construct to allow the packets to traverse
>> intervening routers. This slowness also contributed to the
>> decision to create AH. Choosing it has forced the need to handle pad
>> & IV bytes within the IP payload, increasing protocol stack
complexity
>> when handling the mapping between clear and encrypted payloads. There
>> are many excellent high performance ciphers available many of them do
>> not require IV's or pad bytes. Many of these can be proved to be
very
>> secure, often in a manner obvious to most competent engineers.
>
>You seem to be suggesting the use of stream ciphers. Other than DES in
>certain modes, there are in reality very few stream ciphers that have
>been examined very much. There's only one popular one, RC4 -- and it's
>(arguably) proprietary. If you use RC4 with datagram-oriented encryption,
>you need a sequence number for each byte. Furthermore, you need to keep
>a fair amount of keying state, in case packets arrive out of order. For
>further difficulties with stream ciphers, especially if authentication is
>not used, see the paper cited above.
>
I wasn't thinking of stream ciphers. You are right, there are tradeoffs.
>>
>> C. The desire to use a public key algorithm.
>>
>> This decision has also had an impact on the design. Because PK is
>> so slow this has also contributed to the use of the SA construct
>> instead of other methods which could more closely match how
>> IP routing really works. It makes the management of trust more
>> difficult, for example deleting untrustworthy hosts in a timely
>> manner.
>
>Use of a public key algorithm is an engineering necessity, not a desire.
>You receive mail on netcom -- what authority would both my employer and
>netcom trust to hold our *private* keys, which is the other alternative?
>For a discussion on why public key algorithms are preferable in such
>situations, see Whit Diffie's ten year retropsective on public key
>cryptography.
>
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. Hosts and routers are then allowed by the owner to
participate by giving them each a key. In this model PK has no
advantage and other algorithms outperform it.
>>
>> D. The desire to distribute policy storage and enforcement.
>>
>> By distributing policy storage and enforcement across all the
>> participating hosts and routers it has made it almost impossible
>> to scale this design to very large numbers.
>
>I'm not entirely certain what you mean here. But why shouldn't policy
>be distributed, in a network as heterogeneous as the Internet?
Say an organization has 10,000 hosts and routers. Should policy
be on each and every one of them? How about 100,000 or more?
>>
>>
>>5. The design is incomplete
>>
>> A. Auditing needs to be completed. At the very least what policy events
>> or queries must be specified that can trigger audits. Also for
>> interoperability reasons, audit record formats should be specified.
>
>Since many systems don't have audit abilities, it can't be specified.
>Many auditable events are. There may or may not be a need for an
>interoperable audit format; if there is, it's well beyond the scope
>of this group.
It depends on your design. Systems charged with policy enforcement
need to audit, the rest don't need to.
--
Alex Alten
Andrade@Netcom.Com
P.O. Box 11406
Pleasanton, CA 94588 USA
(510) 417-0159
Follow-Ups:
References: