From: John Ioannidis <ji@cs.columbia.edu>
Date: Mon, 6 Dec 1993 17:19:01 -0500
To: ipsec@ans.net
Subject: swIPe Internet Draft, resent
Message-ID: <37706e274225bcd46f6bc3f960477b91@NO-ID-FOUND.mhonarc.org>
MIME-Version: 1.0
Content-Type: text/plain



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
   ji@cs.columbia.edu
   +1.212.939.7000

   Matt Blaze
   AT&T Bell Laboratories
   101 Crawfords Corner Road
   Holmdel, New Jersey 07733
   mab@research.att.com
   +1.908.949.8069