[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
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.
>
>
>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.
You may well be correct that 40-bit keying will become the de facto
standard. I hope not, especially in unconstrained environments (which,
I should note, includes domestic traffic almost everywhere, and even
international traffic if each party has purchased a legal version that
implements strong cryptography -- the U.S. is not the only source for
such things).
>
>
>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 should note, btw, that using SAs closely mirrors SP3, which is at
least 10 years old. As someone who had been thinking about IP
encryption for quite a while before SP3 was published, I'll state
that when I first saw SP3, I was extremely impressed by its elegance.
>
>
>4. The design is too complex
>
> This design seems to have been driven primarily by the following.
>
> A. The desire to side-step export restrictions if necessary.
Nonsense. That wasn't at all a consideration.
>
> This has caused two protocols, AH & ESP, to be specified.
> If #1 is properly satisfied then AH can be eliminated.
There are good reasons to do away with AH. This isn't one of them, or at
least not one that was used in the working group. (The claim was made
and refuted.) The two real reasons it was kept are to protect some portions
of the IP header without using tunnel mode, and to permit context-free
examination and monitoring of the port number fields.
>
> 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.
The notion of router-to-router encryption was in SP3, too. While you're
right that expense was one driving factor, speed of the encryption algorithm
is a small part of that expense. There are very sound reasons for wanting
to do encryption in hardware, and to put it in physically secure boxes.
For that matter, policy enforcement -- that is, to what sites must one
encrypt traffic -- is best put in places not accessible to typical users.
The ability to trade cost for security was an explicit benefit of SP3;
it's equally valuable in IPsec.
As for ciphers being "proved to be very secure" -- that, in my opinion
as a cryptographer, is largely beyond the state of the art. I welcome
references to prove otherwise.
And of course, using a "proven cipher" is generally considered a feature,
not a bug.
>
> 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.
SKIP -- a design rejected for other reasons -- more closely matches the
IP model. But it also uses public key algorithms.
>
> 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?
>
>
>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.
>
> B. The trust model needs to be worked out more completely. How does the
> secure IP network first get established? How are nodes added or
> deleted? How does a corporate/organization need for controlling
> its own security get reconciled with the need for global
> Internet interoperability?
This is an issue. It's largely been deferred to the vpn and/or IPsecond
working groups. For now, such configuration is largely static, and set
by individual sites. Briefly, each encryption endpoint has a list of
IP addresses to which traffic must be encrypted; for all others, either
plaintext is used, or the site responds to IPsec negotiations initiated
by its peers.
Follow-Ups:
References: