Network Working Group K. Belgaied Internet Draft Sun Microsystems Inc. draft-belgaied-ipv6-lsopt-00.txt G. Winiger Sun Microsystems Inc. February 2001 Generalized Labeled Security Option for IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires August 22, 2001. Abstract This memo describes a new IPv6 Hop-by-Hop Option type used as an explicit security label. The hosts supporting Labeled Security add this option to the packets they originate in order to convey the sensitivity of the data. The routers that recognize this option will use it to make routing decision, in conformance with a pre-established policy. The IPSec protection requirements and a transition scheme from the existing IPv4 security options to the LS option are also proposed. draft-belgaied-ipv6-lsopt-00.txt [Page 1] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 Table of Contents 1. Introduction 2. LS option specification 2.1. Syntax 2.2. Alignment 2.3. Order and coexistence of Tags 3. Functional specification 3.1. Domain of Interpretation 3.2. Interface protection table 3.3. Host behavior 3.3.1 Originating host 3.3.2 Destination host 3.4 Router behavior 4. Deployment considerations 4.1 Policy information setting 4.2 IPv4 Security Options Transition 4.3 Key management 5. Security Considerations 6. IANA Considerations 7. References 8. Acknowledgments and Authors' Addresses draft-belgaied-ipv6-lsopt-00.txt [Page 2] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 1. Introduction Information in a multilevel security environment is labeled. The label of a process may represent the credentials of that process. The label on an object (file, device, ...) may represent the sensitivity, as in the Bell and Lapadula model [BL73], the integrity, as in the Biba model [Bib77], or other security attributes of the data. Multilevel secure operating systems enforce a set of mandatory access control rules, in order to guarantee that information is protected to a certain level of assurance, that can be evaluated according to predefined criteria [LSPP], [DoD85]. In order to enforce those access controls across a network, routing needs to be controlled so as to select specific network links in accordance with the security policy [DoD87], and host need to be able to retrieve the security attributes of data coming from the network, and to communicate those of their own processes when they access data at remote hosts. Making the security attributes of the information available to the entities that need it can be achieved by either explicitly or implicitly labeling the IP packets, as discussed in [RFC-1457], Security Labeling Framework for the Internet. Dedicating an IPSec security association for each sensitivity level is one way of implicit labeling [RFC-2401]. I has the advantage of tying the security attribute of the information to an SA, thus guaranteeing that the former is always protected by the latter. The implicit labeling has the following limitations though: . Scalability. Implicit binding of security attributes to SAs may be sufficient when there is a small set of values for those attributes. Communicating LS systems may exchange data at a wide range of sensitivities, produced by processes with varying credentials, and would need a separate SA for each combination. . Practical consideration. Although an IPSec SA can scale down to selectively protect a single socket (one connection / liaison), it is more efficient in practice to aggregate the flows by broader selectors, like host or subnet addresses or transport level port numbers, due to the cost of the SA establishment including the key management. . Routers cannot figure out the security attributes of the packets, unless they are members of the security association. IPv4 had previous experience with explicit labeling: [RFC-1108] defined the IPSO, a security option in the IPv4 header that can be used for a small number of possible labels mainly in use by the US Government. An IETF working group, cipso, was later formed to propose an IP labeling scheme more suitable to commercial use, and did produce an Internet draft, the Common IP Security Option specification. draft-belgaied-ipv6-lsopt-00.txt [Page 3] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 Although the IETF draft expired, the proposal was adopted in 1994 by the US Government as a Federal Information Processing Standard (FIPS) [CIPSO]. IPv6 [RFC2460] offers a convenient mechanism to carry ancillary data with packets, using options in the hop-by-hop and the destination extension headers. Such an option seems to be the natural choice for use as security label for IPv6 packets. The remainder of this memo proposes a generalized approach to the explicit labeling for IPv6 packet and to the migration of the currently most used labeling IPv4 options (CIPSO and IPSO) to the LS IPv6 option. It applies mainly to the [BL] model, although it may be adopted for an integrity model with some limitations. We'll also discuss the IPSec [RFC-2401] protection requirements when operating in the real world, outside the assumptions of a Trusted Computing Base [DoD85]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Unless otherwise stated, references to the link-local, site-local or global addressing scopes mean both unicast and multicast address types, as defined in [RFC-2373]. 2. LS option specification 2.1. Syntax The general format of an LS option is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSOPT type | Opt Data len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain of Interpretation (len = 4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Variable Length Option Data . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the fields are stored in the network-byte order. LSOPT type's value is an octet value to be requested from IANA, with the following constraints: . First 2 MSB are 00, instructing the non supporting nodes to skip over this option and continue processing the header . The next MSB is 0, indicating that the Option Data does not change en-route draft-belgaied-ipv6-lsopt-00.txt [Page 4] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 The Opt Data length is expressed in octets. The Domain of Interpretation field is a 4 octet integer that identifies the semantics of the option data to follow. Communicating nodes have to agree on a common interpretation of the LS option before acting upon it. The value DOI=0 is dedication for the transition from IPv4 security options. This specification proposes also to reserve the values 1-255. The option Data option is a list of self-describing tags. Each tag has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------+-+ | Tag Type | Tag Length | Tag Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------+-+ The Tag Type (TT) identifies the type of the information in the Tag Info (TI) field. Tag length (TL) to total length of the tag, expressed in octets. The following types are predefined in this document. The implementations are required to use them in the way indicated herein. All these tag types can be used in both hop-by-hop and destination headers, unless otherwise specified. We also provide how entities of each type are compared. TT 1: The tag is a hierarchical 2-octet entity. TL is 4. This can be thought of as a level or classification. The comparison of fields of this type is the conventional mathematical relation (<=, <, >, >=, ==, !=) TT 2: Non-hierarchical bit-vector. TL is a variable number of octets. TL MUST be an even number. This type is intended for categories/compartments bit sets. The comparison of fields of this type is the inclusion relation. TT 3: Enumeration. TL is a variable number of octets. This is a list of items. Each item is a short. It is a compact way of coding categories and compartments. The comparison of fields of this type is the inclusion relation. TT 4: List of ranges. TL is a variable number of octets. TL must be a 4n+2 integer. Each range has 2 shorts: lower and upper boundaries of the draft-belgaied-ipv6-lsopt-00.txt [Page 5] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 interval. The intervals MUST NOT overlap. The ranges are intended as an efficient grouping of categories and compartments. The comparison of fields of this type is the inclusion relation. TT 5: IPv4-Compatible option. TL is a variable number of octets. TL must be an even number. This tag contains an IPv4 security option. The intent of this tag is to provide an easy transition to IPv6 for the LS systems that already use legacy IPv4 options. TT 6: Destination-only data TL is a variable number of octets in this TI. TL must be an even number. Only the destinations that understand the DOI are able to interpret it. This option is not understood by routers when present in a hop-by-hop header and MUST be skipped. TT 7-255: Available for future use, to be requested from IANA. 2.2 Alignment The DOI MUST be aligned on an 8n+4 octet boundary. If the packet contains other options in the hop-by-hop extension header, Pad1 or PadN options MUST be used in order to ensure the DOI in the LS option fall in that boundary, in accordance with the formatting guidelines in [RFC2460] Tags MUST be aligned so that their fields fall in their natural boundaries. 2.3 Order and coexistence of Tags For implementation efficiency, fields with fixed size (TT1) MUST appear first, when present. The LS option MAY carry more than one tag of the same type, however, only the first tag of that type will be used for consistency checks at the interfaces. In order to avoid ambiguity, IPv4 compatibility tags MUST NOT be used with other tags. draft-belgaied-ipv6-lsopt-00.txt [Page 6] INTERNET-DRAFT Generalized LS Option for IPv6 Feb. 22, 2001 3. Functional specification 3.1 Domain of Interpretation Communicating hosts sharing the same set of security policies and a common interpretation of security attributes will use a unique value of the DOI in the labels of the packets they exchange. The DOI identifies the security domain made of that collection of hosts. For example, a label with a classification field TT1=5, may mean "public information" for a company A. Another company, B, may choose to assign the "competition-sensitive information" meaning to the same value, TT1=5. Obviously A and B cannot use TT1=5 to label packets between them. However, if A and B agree on a common set of labels and how to interpret them, they have to choose a unique DOI value, C, that identifies that common understanding. A and B will have to choose different DOI values for communication within their respective domains. A host can be a member of several domains, and use a different DOI value for communicating with peers in each. When A and B in the example above use the services of an application server provided by an outsourcing company, the server can be a member of the 3 domains, A, B and the C. It will use labels with DOI A to communicate with A, for instance, and apply the policy enforcement checks suitable for DOI A, in choosing routes or offering the appropriate IPSec protection, The server will use the DOI C for packets addressed to a multicast group containing both A and B. 3.2 Interface protection table An implementation that supports the LS option may associate with each network interface a table that specifies what domains of interpretations are supported and what are the constraints on the packets coming through or going out of that interface, for a given DOI. An example of such a table would look like: DOI | Constraints ----------+----------------------------------- doi1 | TT1: [min-max] | TT2: