[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: >IPv4 Security redux
Reply to: RE>>IPv4 Security redux
>From: Phil Karn
>Date: 20 Apr 93 15:13:09 -0700
>
> ...
>
>I strongly agree that the ipsec charter ought to be strictly limited to
>IPv4. It's impossible to anticipate every future need of anything that
>could conceivably become a new IP, and attempting to do so is the surest
>path to OSIfication (i.e., producing lots of paper but no usable
>product).
At the last meeting I thought that the group had a rough consensus to
consider the implications of IPtng. This didnUt imply that we had to solve
all future security problems, but at a minimum we should at least be aware
of the impact of IPSP on IPtng. I do not think that this should be all that
difficult since we are pursuing a simple encapsulation protocol for IPSP.
Hopefully when the secretary posts the minutes (hint, hint, again) we will
have some documentation of our initial decisions on the groups direction.
>Our protocol may need replacement some day, but so what? To my
>knowledge, we're the first to talk about network layer security in the
>Internet. There's no experience base, so gaining one is a worthwhile
>goal in itself. And what we learn will put us in a much better position
>to design its replacement if that should become necessary.
But there is an experience base. SP3 has been fielded for years. NLSP has
been demonstrated by Jim Zmuda and give or take a few field formats is not
all that different from SP3. We need to built from this experience base
rather than starting from scratch.
>
>I advocate a highly pragmatic approach here, with a strong emphasis on
>ease of implementation and on solving immediate, known problems. Even
>though this is nominally a host-to-host protocol, I see the first
>implementations being in encapsulating gateways used to join trusted
>networks (e.g., internal corporate subnets) via untrusted ones (e.g.,
>public Internet carriers). This means supporting every existing
>transport protocol and application, robustly designed or not.
I agree mostly, but I would like to point out that IPSP is intended to
support both host-to-host, subnet-to-host, and subnet-to-subnet protection.
We attempted to prioritize the host-to-host solution first just to limit the
scope of the initial work.
>In particular, I think we need sequence numbering to protect against
>replay attacks. Although it is theoretically correct to cite layering
>and argue that internet transport protocols are supposed to protect
>against packet duplication, in practice a lot of existing Internet
>transport protocols and hosts rely on non-intentional duplication being
>rare, which it fortunately is, especially for long-delayed duplicates. A
>good example is the ARNS package when used to encapsulate Appletalk
>packets inside UDP. It's my understanding that Appletalk doesn't
>handle duplication very well at all.
An interesting proposal. The suggestions to add sequence integrity at the
network layer did seem to strongly divide our group in Ohio.
>Even TCP, whose designers had an almost pathological obsession with
>duplicate packets, has problems when hosts lose state (e.g., when
>they're rebooted). Many TCPs reuse the same sequence of port numbers and
>initial sequence numbers each time they're rebooted, creating an
>opportunity to replay packets recorded from before the reboot.
>
>If the ipsec protocol ran on a host-to-host basis, this problem could be
>avoided by simply requiring the hosts to rekey each time they reboot.
>But given the likely popularity of intermediate encapsulating gateways,
>I don't see any easy way to solve this problem without sequence
>numbering.
>
>Re some of the other fields, I question the need for a "security
>association identifier" (or key identifier, or whatever you call it).
>Given that every modern operating system I'm aware of has a trusted
>kernel that applications already rely on to protect themselves from each
>other and from the outside, I really don't see the point of having more
>than one active cryptographic key per host pair managed by these
>kernels. A host can determine the appropriate key to use for each packet
>solely from the address of the other host; it doesn't need an explicit
>key ID.
It took me a while to respond to this because the many possible uses of the
SAID are not always obvious. IPSP could simply use the lower layer source
and destination addresses to imply the Security Association (SA) for
host-to-host protection. This works fine as long as you only have a single
key per source/destination pair. The problem is that the cryptographic key
and even the security services may eventually change for that pair. You
need a mechanism to differentiate the new protection from the old. Because
of this all protected source/destination pairs need to support at least two
SAs.
Note that the unprotected destination address may not be the final
destination for packets that travel through IPSP protected routers. In this
case the final adresses may be determined by the SAID (e.g. SP3-N at a
router). These addresses could also be carried explicitly in the IPSP
protected header (e.g. SP3-A), or a complete IP packet can be encapsulated
inside the protected IPSP datagram (e.g. SP3-I).
>
>So as I see it, here is what should be in the ip security header:
>
>Flags - indicating the presence or absence of an authenticator in this
>packet, and whether the packet is encrypted. 1 byte. Sent in the clear,
>included in the authentication computation.
I seem to be missing something here. I do not see why you need an
authenticator field or encrypted flag.
>
>Protocol - the value that would have gone into the IP Protocol field had
>the security protocol not been used. This could be, eg., 17 (UDP) or 6
>(TCP) if the ip security protocol is implemented on the end host, or it
>could be 4 or 94 (two different values for IP-in-IP encapsulation) if
>this system is providing secure IP encapsulation on behalf of other
>hosts. 1 byte. Sent encrypted, and included in the authenticator.
>
>Packet serial number - used to thwart replay attacks. When this number
>is lost (e.g., due to a reboot) or wraps around, rekeying is required.
>Given this last rule, 2 bytes should be plenty. Included in the
>authenticator. Not sure whether it should be encrypted or not; leaving
>this in the clear makes it easier to filter out a heavy flood of replays
>without spending cycles decrypting them first.
>
>Authenticator - Optional, possibly variable length. Algorithm could be
>negotiated during key exchange. It would probably be something like the
>MD-5 hash of the protected portion of the packet, seeded with the
>current shared key. Up to 8 bytes. Not included in the authenticator
>(e.g., considered to be zero when computing and verifying the
>authentication). Should probably be sent in the clear, since encrypting
>it doesn't seem to buy anything, and would again make it easier to
>filter a flood of malicious traffic without spending cycles on
>decryption (which is likely to be much slower than MD5 hashing).
How is this different than the use of the Integrity Check Value (ICV) field
in NLSP, SP3, SP4, or IEEE 802.10. Why is authentication with a hash
different than any other cryptographic transformation applied to the data?
I would recommend that whatever you are trying to do with the authentication
could be accomplished with an SAID. The SAID would simply imply the type of
service provided by the cryptographic encapsulation - confidentiality,
integrity, integrity and authentication, confidentiality and integrity, etc.
>
>So, that means 4 bytes of fixed overhead, plus possibly 8 more for
>the authenticator. And everything lands on the right boundaries
>for performance.
>
>What else do we need?
>
A SAID field in the IPSP clear header.
>
>Phil
Paul