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