[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
swIPe Internet Draft, resent
The swIPe IP Security Protocol John Ioannidis
INTERNET DRAFT (Columbia University)
Expires June 3, 1994 Matt Blaze
<draft-ipsec-swipe-01.txt> (AT&T Bell Labs)
December 3rd, 1993
The swIPe IP Security Protocol
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' Please check the 1id-
abstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
Abstract
This document describes swIPe, a network-layer security protocol for
the IP protocol suite. swIPe provides confidentiality, integrity,
and authentication of network traffic, and can be used to provide
both end-to-end and intermediate-hop security. swIPe is concerned
only with security mechanisms; policy and key management are handled
outside the protocol.
1. Introduction
Security of network resources has been viewed traditionally as a
trade-off between security and convenience. The lack of a
network-layer security protocol suitable for use in large,
administratively heterogeneous internetworks, has given rise to ad
hoc security efforts, such as mailbridges, filtering routers,
firewalls, application-level gateways, etc. The fundamental problem
with these efforts is that, in enforcing security, they cripple the
connectivity that makes internetworking attractive in the first
place.
Ioannidis & Blaze [Page 1]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
In order that the Internet continue to grow in size and features,
its users must be confident that it is safe to connect without hiding
behind impenetrable draconian barriers. The existing internetworking
protocols, including IP, are deficient in three areas:
* Lack of source authentication.
* Lack of data integrity.
* Lack of data confidentiality.
The lack of these features in the network requires relying on
higher-layer protocol features (e.g., TCP port numbers), or
lower-layer features (e.g., which network interface a packet arrived
from) to perform security functions (such as access control). In
most cases, `firewalls' simply create an impenetrable barrier, thus
making it cumbersome, or even impossible, for users inside the
firewall to take advantage of network services in the global
Internet.
Network security being critically important to the continued growth
of the Internet, it is necessary to solve these problems while
maintaining connectivity. Cryptographic protection of network
traffic can solve all three problems. However, we still lack full
understanding of the problems of heterogeneous security policies and
of cryptographic key management in large scale networks. Therefore,
it is important to separate policy considerations and key management
from the actual mechanisms in any security protocol.
swIPe is a network-layer security protocol that provides the
mechanisms to solve the three problems listed above. It works by
augmenting each packet with a cryptographically-strong authenticator
and/or encrypting the data to be sent.
swIPe is simple to define, implement and use in existing and future
networks and operating systems. It provides all the necessary
security mechanisms and is easy to interface to loosely coupled
policy and key management facilities that are outside the swIPe
protocol itself. In addition, is tied to any specialized underlying
protocol features or cryptographic algorithms, and can therefore be
readily adapted to new protocols and new crypto systems.
Because swIPe operates at the network layer, it can be used to
implement a variety of security configurations. It can operate at
the same granularity level as the network and therefore can provide
security between any entities identified at the network layer (e.g.,
host-to-host security, host-to-network, individual links, etc.).
Depending on the capabilities of the host environment, finer
Ioannidis & Blaze [Page 2]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
granularity is possible as well, such as security between individual
processes running on different hosts.
The precise security configuration of a network (which links, hosts,
connections between processes in hosts, etc. are protected) depends
on the policy configuration of each network entity. That is, a host
may determine which outgoing packets are protected, a router may
determine which packets to pass or reject, and so on. For example, a
trusted internal network need not run swIPe at all, but may still
securely connect to external networks by running swIPe on its
routers.
It is important to note that the existence of a security protocol is
not sufficient; host and site security policies must be chosen
judiciously, and often in combination with higher-level security
mechanisms to yield the desired effects. As an example, providing a
secure link between a workstation and its file server does not
protect file data once they are on the server itself. Similarly,
trusting the identity of a particular host is not the same as
trusting the integrity of the data and services provided by that
host.
Although it was designed to be readily adaptable to any
connectionless network protocol, swIPe as described in this document
is specific to IP.
2. Protocol Description
swIPe works by encapsulating each IP datagram to be secured inside a
swIPe packet. A swIPe packet is an IP packet of protocol type
IPPROTO_SWIPE (temporarily, protocol 94, or IPPROTO_IPIP, is being
used). A swIPe packet starts with a header, which contains
identifying data and authentication information; the header is
followed by the original IP datagram, which in turn is followed by
any padding required by the security processing. Depending on the
negotiated policy, the sensitive part of the swIPe packet (the
authentication information and the original IP datagram) may be
encrypted.
In this document, we refer to the original IP datagram as the `inner
packet', and the entire swIPe datagram as the `outer' packet. The
components of a swIPe packet are shown in the following diagram.
+-----+-----------+-----+----------------------+---------+
|IPhdr| swIPe hdr |IPhdr| payload | padding |
+-----+-----------+-----+----------------------+---------+
^_______ inner packet _______^
^__________________ outer (swIPe) packet ________________^
Ioannidis & Blaze [Page 3]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
The inner IP header and the payload are transferred intact with
respect to the swIPe endpoints. That is, the Time To Live field,
original source and destination addresses, and other such fields in
the inner IP header are not modified. It may be desirable (in a
future version of the protocol) to `compress' the inner IP header,
that is, replace it with enough information to reconstruct it from
the outer header. This `compression', however, must be invisible at
the swIPe endpoints.
The format of a swIPe packet is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s H | Packet type | Header length | Policy identifier |
w e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I a | Packet sequence number |
P d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e e / /
r \ Authenticator (optional, variable length) \
`- / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ \
/ Original (inner) packet /
\ \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ Padding (optional) \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the swIPe header are:
Packet type (8 bits)
0 Plain encapsulation; Header length should be 1 and
the Policy identifier should be 1.
1 Packet is authenticated but not encrypted.
2 Packet is encrypted; the encryption algorithm may
provide some authentication (e.g., DES CBC residue).
3 Packet is both authenticated and encrypted
4-15 Unused.
Ioannidis & Blaze [Page 4]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
16-63 Control packet. Reserved, undefined by the protocol,
interpreted by policy and key management engines.
64-255 Reserved; must never be used.
Header length (8 bits)
The length of the swIPe header in 32-bit words. The minimum
value is 1.
Policy Identifier (16 bits)
A token, negotiated at key- or policy-setup time, used by the
recipient of the packet to choose the proper policy. Similar
to a SAID.
Packet sequence number (32 bits)
This field protects against replay attacks and may also be used
for synchronization by a stream cipher. It is unique within
the context of an endpoint pair (common source/destination
address and Policy identifier). It is incremented by one with
every packet sent, and initialized whenever the hosts
re-negotiate keys and/or policies.
The hosts MUST renegotiate crypto variables before the packet
sequence number wraps around. A host MUST NOT accept duplicate
packets; this may be achieved by only accepting packets which
increment the sequence number, or maintaining a small window
of acceptable packet numbers.
Authentication data (variable length, multiple of 32 bits)
An authenticator, computed over the entire swIPe packet (minus
the outer IP header), but before any confidentiality processing
is performed. When the authenticator is computed, the
authentication data field is zeroed.
Encapsulated packet (variable length)
The actual packet being secured.
Padding (variable length)
Some security algorithms (such as DES) require padding to bring
the length of the data to an integral multiple of the block
size. The padding is added after the authentication data have
been computed.
A swIPe system consists of three conceptual entities; the protocol
engine, the key management engine, and the policy engine. The swIPe
protocol described in this document comprises the protocol engine.
We describe the swIPe processing without specifying the precise
semantics of either the policy or key management engines, since these
Ioannidis & Blaze [Page 5]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
are not part of the protocol itself. It is useful, however, to
consider the interaction between protocol and key management and
policy in terms of a simple upcall interface: whenever the swIPe
processing engine needs to determine which keys and what policy to
use in processing a datagram, it calls the appropriate processing
engine. Needless to say, an implementation may optimize the actual
mechanisms or blur the boundaries between protocol processing and
policy.
The policy engine is responsible for determining the precise kind of
processing required of outgoing datagrams, and acceptance policy for
incoming datagrams. The key management engine establishes the
cryptographic variables used by the protocol. Both the policy and
the key management engines may also communicate with their respective
peers on remote endpoints for negotiation of policy and keys, as
required.
Outgoing datagrams are processed by swIPe as follows: based on
information from the inner packet itself (IP source and destination
address, IP protocol, other transport-layer parameters), as well as
information from local system control structures such as protocol
control blocks, a decision is made whether to send the packet and, if
so, whether to apply swIPe processing to it. If swIPe processing is
required, the authentication and encryption algorithms, the keys to
use, and the destination of the outer packet are determined by
consulting the policy and key management engines. Once the
parameters have been determined, the swIPe packet is constructed.
The swIPe header is prepended to the (inner) IP datagram. The
sequence number is copied into the packet and incremented. If
authentication is to be performed, the authenticator field (of the
appropriate length) is zeroed, and the authentication algorithm is
applied to the authentication information part of the header (i.e.,
the swIPe header minus the first 32 bits) and the original IP
datagram. The checksum resulting from the application of the
authentication algorithm is copied into the authenticator field. If
authentication is not performed, then the authenticator field is not
present. Next, if encryption is (also) specified, the appropriate
algorithm and crypto variable are selected and applied to the same
parts of the datagram as the authentication. The algorithm may
require padding, which is appended to the packet after encryption has
been performed. The resulting datagram is then transmitted to its
destination (which may not be the same as that of inner packet).
Input processing proceeds in roughly the opposite fashion. swIPe
datagrams that arrive are decrypted and authenticated based on
information contained in their swIPe header. Namely, the source,
destination, and Policy Identifier of the outher packet are examined
and the crypto variables and algorithms used to decrypt, verify, and
Ioannidis & Blaze [Page 6]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
reconstruct the original packet. The resulting datagrams, plus any
non-swIPe datagrams that arrive directly are checked against the
local policy configuration to determine whether they should be
accepted or not. Accepted packets are processed in the ordinary
manner (delivered to the corresponding higher-layer protocol if they
were destined for the receiving host, or further routed if not).
3. Discussion
The security provided by swIPe depends upon the strength of the
underlying cryptographic algorithms, the security of secret key
information, and the characteristics of the protocol itself. Since
swIPe can be used with a wide range of crypto systems, we focus on
the impact of the protocol features on the resulting security.
Source authenticity of the inner packet is protected by including the
entire inner packet (and hence its source and destination IP
addresses) in the computation of the authenticator. The implicit
assumption is that the authentication function is a cryptographically
strong one-way authenticator (such as key-seeded MD5), and that only
the legitimate hosts have access to the authentication key.
Similarly, data integrity is protected by the same checksum
mechanism; replays are thwarted by the presence of the sequence
number field.
An adversary not possessing the authentication key cannot generate
the authenticator for fraudulent packets; furthermore, since only
packets that increase the sequence number are accepted (or packets
within the acceptable window), replay attacks are not feasible either.
Data confidentiality is provided by encrypting the entire swIPe
packet. Confidentiality is not limited to the actual data being
transmitted in the inner packet, but also extends to the source and
destination addreses, protocol characteristics (such as TCP port
number), and so on. Note that since the addresses of the inner
packet are not necessarily the same as those of the outer packet, it
is not possible for an adversary to determine the actual endpoints of
communication without resorting to global traffic analysis.
There are many ways to configure systems running swIPe, and many
types of security policies that can be implemented with it. For a
discussion of applications of swIPe and its implementation under
Unix, the reader is referred to "The Architecture and Implementation
of Network-Layer Security Under Unix", by John Ioannidis and Matt
Blaze, which appeared in the proceedings of the 4th USENIX Security
Symposium, Santa Clara, CA, October 1993.
Ioannidis & Blaze [Page 7]
INTERNET-DRAFT The swIPe IP Security Protocol December 1993
Authors' Addresses
John Ioannidis
Computer Science Department
Columbia University
500 W. 120th Street
New York, NY 10027
[email protected]
+1.212.939.7000
Matt Blaze
AT&T Bell Laboratories
101 Crawfords Corner Road
Holmdel, New Jersey 07733
[email protected]
+1.908.949.8069