Chapter 18 Trusted Networking (Overview)

This chapter describes trusted networking concepts and mechanisms in Trusted Extensions.

• The Trusted Network

• Network Security Attributes in Trusted Extensions

• Trusted Network Fallback Mechanism

• Overview of Routing in Trusted Extensions

• Administration of Routing in Trusted Extensions

• Administration of Labeled IPsec

The Trusted Network

Trusted Extensions assigns security attributes to zones, hosts, and networks. These attributes ensure that the following security features are enforced on the network:

• Data is properly labeled in network communications.

• Mandatory access control (MAC) rules are enforced when data is sent or received across a local network and when file systems are mounted.

• MAC rules are enforced when data is routed to distant networks.

• MAC rules are enforced when data is routed to zones.

In Trusted Extensions, network packets are protected by MAC. Labels are used for MAC decisions. Data is labeled explicitly or implicitly with a sensitivity label. A label has an ID field, a classification or “level” field, and a compartment or “category” field. Data must pass an accreditation check. This check determines if the label is well formed, and if the label lies within the accreditation range of the receiving host. Well-formed packets that are within the receiving host's accreditation range are granted access.

IP packets that are exchanged between trusted systems can be labeled. Trusted Extensions supports Commercial IP Security Option (CIPSO) labels. A CIPSO label on a packet serves to classify, segregate, and route IP packets. Routing decisions compare the sensitivity label of the data with the label of the destination.

Typically on a trusted network, the label is generated by a sending host and processed by the receiving host. However, a trusted router can also add or strip labels while forwarding packets in a trusted network. A sensitivity label is mapped to a CIPSO label before transmission. The CIPSO label is embedded in the IP packet. Typically, a packet sender and the packet's receiver operate at the same label.

Trusted networking software ensures that the Trusted Extensions security policy is enforced even when the subjects (processes) and objects (data) are located on different hosts. Trusted Extensions networking preserves MAC across distributed applications.

Trusted Extensions Data Packets

Trusted Extensions data packets include a CIPSO label option. The data packets can be sent over IPv4 or IPv6 networks.

In the standard IPv4 format, the IPv4 header with options is followed by a TCP, UDP, or SCTP header and then the actual data. The Trusted Extensions version of an IPv4 packet uses the CIPSO option in the IP header for the security attributes.

In the standard IPv6 format, an IPv6 header with extensions is followed by a TCP, UDP, or SCTP header and then the actual data. The Trusted Extensions IPv6 packet includes a multilevel security option in the header with extensions.

Trusted Network Communications

Trusted Extensions supports labeled and unlabeled hosts on a trusted network. LDAP is a fully supported naming service. Various commands and GUIs enable the network to be administered.

Systems that run Trusted Extensions software support network communications between Trusted Extensions hosts and any of the following types of systems:

• Other systems that are running Trusted Extensions

• Systems that are running operating systems that do not recognize security attributes, but do support TCP/IP, such as Solaris systems, other UNIX® systems, Microsoft Windows, and Macintosh OS systems

• Systems that are running other trusted operating systems that recognize CIPSO labels

As in the Solaris OS, Trusted Extensions network communications and services can be managed by a naming service. Trusted Extensions adds the following interfaces to Solaris network interfaces:

• Trusted Extensions adds three network configuration databases, tnzonecfg, tnrhdb, and tnrhtp. For details, see Network Configuration Databases in Trusted Extensions.

• The Trusted Extensions version of the naming service switch file, nsswitch.conf, includes entries for the tnrhtp and tnrhdb databases. These entries can be modified to suit each site's configuration.

  Trusted Extensions uses the LDAP naming service to centrally manage configuration files that define hosts, networks, and users. The default nsswitch.conf entries for the trusted network databases for the LDAP naming service follow:

  # Trusted Extensions tnrhtp: files ldap tnrhdb: files ldap

  The LDAP naming service on a Sun Java System Directory Server is the only fully supported naming service in Trusted Extensions. For information about the use of LDAP on a system that is configured with Trusted Extensions, see Chapter 15, Trusted Extensions and LDAP (Overview).

• Trusted Extensions adds tools to the Solaris Management Console. The console is used to centrally manage zones, hosts, and networks. The network tools are described in Solaris Management Console Tools.

  The Part I, Initial Configuration of Trusted Extensions describes how to define zones and hosts when you configure the network. For additional details, see Chapter 19, Managing Networks in Trusted Extensions (Tasks).

• Trusted Extensions adds commands to administer trusted networking. Trusted Extensions also adds options to the Solaris network commands. For a description of these commands, see Network Commands in Trusted Extensions.

• Trusted Extensions extends the IKE configuration file, /etc/inet/ike/config for labeled IPsec. For more information, see Administration of Labeled IPsec and the ike.config(4) man page

Network Configuration Databases in Trusted Extensions

Trusted Extensions loads three network configuration databases into the kernel. These databases are used in accreditation checks as data is transmitted from one host to another host.

• tnzonecfg – This local database stores zone attributes that are security-related. The attributes for each zone specify the zone label and the zone's access to single-level and multilevel ports. Another attribute handles responses to control messages, such as ping. The labels for zones are defined in the label_encodings file. For more information, see the label_encodings(4) and smtnzonecfg(1M) man pages. For a discussion of multilevel ports, see Zones and Multilevel Ports.

• tnrhtp – This database stores templates that describe the security attributes of hosts and gateways. tnrhtp can be a local database or stored on the LDAP server. Hosts and gateways use the attributes of the destination host and next-hop gateway to enforce MAC when sending traffic. When receiving traffic, hosts and gateways use the attributes of the sender. For details of the security attributes, see Trusted Network Security Attributes. For more information, see the smtnrhtp(1M) man page.

• tnrhdb – This database holds the IP addresses and network prefixes (fallback mechanism) that correspond to all hosts that are allowed to communicate. tnrhdb can be a local database or stored on the LDAP server. Each host or network prefix is assigned a security template from the tnrhtp database. The attributes in the template define the attributes of the assigned host. For more information, see the smtnrhdb(1M) man page.

In Trusted Extensions, the Solaris Management Console has been extended to handle these databases. For details, see Solaris Management Console Tools.

Network Commands in Trusted Extensions

Trusted Extensions adds the following commands to administer trusted networking:

• tnchkdb – This command is used to verify the correctness of the trusted network databases. The tnchkdb command is used whenever you change a security template (tnrhtp), a security template assignment (tnrhdb), or the configuration of a zone (tnzonecfg). The Solaris Management Console tools run this command automatically when a database is modified. For details, see the tnchkdb(1M) man page.

• tnctl – This command can be used to update the trusted network information in the kernel. tnctl is also a system service. A restart with the command svcadm restart /network/tnctl refreshes the kernel cache from the trusted network databases on the local system. The Solaris Management Console tools run this command automatically when a database is modified in the Files scope. For details, see the tnctl(1M) man page.

• tnd – This daemon pulls tnrhdb and tnrhtp information from the LDAP directory. tnd is started at boot time as a service, as in svcadm start /network/tnd. This command also can be used for debugging and for changing the polling interval. For details, see the tnd(1M) man page.

• tninfo – This command displays the details of the current state of the trusted network kernel cache. The output can be filtered by host name, zone, or security template. For details, see the tninfo(1M) man page.

Trusted Extensions adds options to the following Solaris network commands:

• ifconfig – The all-zones interface flag for this command makes the specified interface available to every zone on the system. The appropriate zone to deliver data to is determined by the label that is associated with the data. For details, see the ifconfig(1M) man page.

• netstat – The -R option extends Solaris netstat usage to display Trusted Extensions-specific information, such as security attributes for multilevel sockets and routing table entries. The extended security attributes include the label of the peer, and whether the socket is specific to a zone, or available to several zones. For details, see the netstat(1M) man page.

• route – The -secattr option extends Solaris route usage to display the security attributes of the route. The value of the option has the following format:

  min_sl=label,max_sl=label,doi=integer,cipso

  The cipso keyword is optional and set by default. For details, see the route(1M) man page.

• snoop – As in the Solaris OS, the -v option to this command can be used to display the IP headers in detail. In Trusted Extensions, the headers contain label information.

• ipseckey – In Trusted Extensions, the following extensions are available to label IPsec-protected packets: label label, outer-label label, and implicit-label label. For details, see the ipseckey(1M) man page.

Trusted Network Security Attributes

Network administration in Trusted Extensions is based on security templates. A security template describes a set of hosts that have common protocols and identical security attributes.

Security attributes are administratively assigned to systems, both hosts and routers, by means of templates. The security administrator administers templates and assigns them to systems. If a system does not have an assigned template, no communications are allowed with that system.

Every template is named, and includes the following:

• A host type of either Unlabeled or CIPSO. The protocol that is used for network communications is determined by the host type of the template.

  The host type is used to determine whether to use CIPSO options and affects MAC. See Host Type and Template Name in Security Templates.

• A set of security attributes that are applied to each host type.

For more detail about host types and security attributes, see Network Security Attributes in Trusted Extensions.

Network Security Attributes in Trusted Extensions

Trusted Extensions is installed with a default set of security templates. When a template is assigned to a host, the security values in the template are applied to the host. In Trusted Extensions, both unlabeled hosts and labeled hosts on the network are assigned security attributes by means of a template. Hosts that are not assigned a security template cannot be reached. The templates can be stored locally, or in the LDAP naming service on the Sun Java System Directory Server.

Templates can be assigned directly or indirectly to a host. Direct assignment assigns a template to a particular IP address. Indirect assignment assigns a template to a network address that includes the host. Hosts that do not have a security template cannot communicate with hosts that are configured with Trusted Extensions. For an explanation of direct assignment and indirect assignment, see Trusted Network Fallback Mechanism.

Templates are modified or created by using the Security Templates tool in the Solaris Management Console. The Security Templates tool enforces the completion of the required fields in the templates. Which fields are required is based on the host type.

Each host type has its own set of additional required and optional security attributes. The following security attributes are specified in security templates:

• Host type – Defines whether the packets are labeled with CIPSO security labels or not labeled at all.

• Default label – Defines the level of trust of the unlabeled host. Packets that are sent by an unlabeled host are read at this label by the receiving Trusted Extensions host or gateway.

  The Default label attribute is specific to the unlabeled host type. For details, see the smtnrhtp(1M) man page and the following sections.

• DOI – A positive, non-zero integer that identifies the domain of interpretation. The DOI is used to indicate which set of label encodings applies to a network communication or network entity. Labels with different DOIs, even if otherwise identical, are disjoint. For unlabeled hosts, the DOI applies to the default label. In Trusted Extensions, the default value is 1.

• Minimum label – Defines the bottom of the label accreditation range. Hosts and next-hop gateways do not receive packets that are below the minimum label that is specified in their template.

• Maximum label – Defines the top of the label accreditation range. Hosts and next-hop gateways do not receive packets that are higher than the maximum label that is specified in their template.

• Security label set – Optional. Specifies a discrete set of security labels for a security template. In addition to their accreditation range that is determined by the maximum and minimum label, hosts that are assigned to a template with a security label set can send and receive packets that match any one of the labels in the label set. The maximum number of labels that can be specified is four.

Host Type and Template Name in Security Templates

Trusted Extensions supports two host types in the trusted network databases and provides two default templates:

• CIPSO host type – Intended for hosts that run trusted operating systems. Trusted Extensions supplies the template named cipso for this host type.

  The Common IP Security Option (CIPSO) protocol is used to specify security labels that are passed in the IP options field. CIPSO labels are derived automatically from the data's label. Tag type 1 is used to pass the CIPSO security label. This label is then used to make security checks at the IP level and to label the data in the network packet.

• Unlabeled host type - Intended for hosts that use standard networking protocols but do not support CIPSO options. Trusted Extensions supplies the template named admin_low for this host type.

  This host type is assigned to hosts that run the Solaris OS or other unlabeled operating systems. This host type gives provides a default label and a default clearance to apply to communications with the unlabeled host. Also, a label range or a set of discrete labels can be specified to allow the sending of packets to an unlabeled gateway for forwarding.

The admin_low template provides an example for constructing unlabeled templates with site-specific labels. While the admin_low template is required for the installation of Trusted Extensions, the security settings might not be appropriate for normal system operations. Retain the provided templates without modification for system maintenance and support reasons.

Default Label in Security Templates

Templates for the unlabeled host type specify a default label. This label is used to control communications with hosts whose operating systems are not aware of labels, such as Solaris systems. The default label that is assigned reflects the level of trust that is appropriate for the host and its users.

Because communications with unlabeled hosts are essentially limited to the default label, these hosts are also referred to as single-label hosts.

Domain of Interpretation in Security Templates

Organizations that use the same Domain of Interpretation (DOI) agree among themselves to interpret label information and other security attributes in the same way. When Trusted Extensions performs a label comparison, a check is made as to whether the DOI is equal.

A Trusted Extensions system enforces label policy on one DOI value. All zones on a Trusted Extensions system must operate at the same DOI. A Trusted Extensions system does not provide exception handling on packets that are received from a system that uses a different DOI.

If your site uses a DOI value that is different from the default value, you must add this value to the /etc/system file, and change the value in every security template. For the initial procedure, see Configure the Domain of Interpretation. To configure the DOI in every security template, see Example 19–1.

Label Range in Security Templates

The minimum label and maximum label attributes are used to establish the label range for labeled and unlabeled hosts. These attributes are used to do the following:

• To set the range of labels that can be used when communicating with a remote CIPSO host

  In order for a packet to be sent to a destination host, the label of the packet must be within the label range assigned to the destination host in the security template for that host.

• To set a label range for packets that are being forwarded through a CIPSO gateway or an unlabeled gateway

  The label range can be specified in the template for an unlabeled host type. The label range enables the host to forward packets that are not necessarily at the label of the host, but are within a specified label range.

Security Label Set in Security Templates

The security label set defines at most four discrete labels at which packets can be accepted, forwarded, or sent by the remote host. This attribute is optional. By default, no security label set is defined.

Trusted Network Fallback Mechanism

The tnrhdb database can assign a security template to a particular host either directly or indirectly. Direct assignment assigns a template to a host's IP address. Indirect assignment is handled by a fallback mechanism. The trusted network software first looks for an entry that specifically assigns the host's IP address to a template. If the software does not find a specific entry for the host, it looks for the “longest prefix of matching bits”. You can indirectly assign a host to a security template when the IP address of the host falls within the “longest prefix of matching bits” of an IP address with a fixed prefix length.

In IPv4, you can make an indirect assignment by subnet. When you make an indirect assignment by using 4, 3, 2, or 1 trailing zero (0) octets, the software calculates a prefix length of 0, 8, 16, or 24, respectively. Entries 3 – 6 in Table 18–1 illustrate this fallback mechanism.

You can also set a fixed prefix length by adding a slash (/) followed by the number of fixed bits. IPv4 network addresses can have a prefix length between 1 – 32. IPv6 network addresses can have a prefix length between 1 – 128.

The following table provides fallback address and host address examples. If an address within the set of fallback addresses is directly assigned, the fallback mechanism is not used for that address.

192.168.118.57:cipso

192.168.118.57/32:cipso

192.168.118.57

192.168.118.128/26:cipso

192.168.118.0:cipso

192.168.118.0/24:cipso

192.168.0.0/24:cipso

192.168.0.0:cipso

192.168.0.0/16:cipso

192.0.0.0:cipso

192.0.0.0/8:cipso

192.168.0.0/32:cipso

192.168.118.0/32:cipso

192.0.0.0/32:cipso

0.0.0.0/32:cipso

0.0.0.0:cipso

2001\:DB8\:22\:5000\:\:21f7:cipso

2001:DB8:22:5000::21f7

2001\:DB8\:22\:5000\:\:0/52:cipso

0\:\:0/0:cipso

Note that the 0.0.0.0/32 address matches the specific address, 0.0.0.0. The tnrhdb entry 0.0.0.0/32:admin_low is useful on a system where the literal address, 0.0.0.0, is used as a source IP address. For example, DHCP clients contact the DHCP server as 0.0.0.0 before the server provides the clients with an IP address.

To create a tnrhdb entry on a Sun Ray server that serves DHCP clients, see Example 19–13. Because 0.0.0.0:admin_low is the default wildcard entry, see How to Limit the Hosts That Can Be Contacted on the Trusted Network for issues to consider before removing or changing this default.

For more information about prefix lengths in IPv4 and IPv6 addresses, see Designing Your CIDR IPv4 Addressing Scheme in System Administration Guide: IP Services and IPv6 Addressing Overview in System Administration Guide: IP Services.

Overview of Routing in Trusted Extensions

In Trusted Extensions, routes between hosts on different networks must maintain security at each step in the transmission. Trusted Extensions adds extended security attributes to the routing protocols in the Solaris OS. Unlike the Solaris OS, this Trusted Extensions release does not support dynamic routing. For details about specifying static routing, see the -p option in the route(1M) man page.

Gateways and routers route packets. In this discussion, the terms “gateway” and “router” are used interchangeably.

For communications between hosts on the same subnet, accreditation checks are performed at endpoints only because no routers are involved. Label range checks are performed at the source. If the receiving host is running Trusted Extensions software, label range checks are also performed at the destination.

When the source and destination hosts are on different subnets, the packet is sent from the source host to a gateway. The label range of the destination and the first-hop gateway is checked at the source when a route is selected. The gateway forwards the packet to the network where the destination host is connected. A packet might go through several gateways before reaching the destination.

Background on Routing

On Trusted Extensions gateways, label range checks are performed in certain cases. A Trusted Extensions system that is routing a packet between two unlabeled hosts compares the default label of the source host to the default label of the destination host. When the unlabeled hosts share a default label, the packet is routed.

Each gateway maintains a list of routes to all destinations. Standard Solaris routing makes choices to optimize the route. Trusted Extensions provides additional software to check security requirements that apply to the route choices. The Solaris choices that do not satisfy security requirements are skipped.

Routing Table Entries in Trusted Extensions

The routing table entries in Trusted Extensions can incorporate security attributes. Security attributes can include a cipso keyword. Security attributes must include a maximum label, a minimum label, and a DOI.

For entries that do not provide security attributes, the attributes in the gateway's security template are used.

Trusted Extensions Accreditation Checks

Trusted Extensions software determines the suitability of a route for security purposes. The software runs a series of tests called accreditation checks on the source host, the destination host, and the intermediate gateways.

In the following discussion, an accreditation check for a label range also means a check for a security label set.

The accreditation check verifies the label range and CIPSO label information. The security attributes for a route are obtained from the routing table entry, or from the security template of the gateway if the entry has no security attributes.

For incoming communications, the Trusted Extensions software obtains labels from the packets themselves, whenever possible. Obtaining labels from packets is only possible when the messages are sent from systems that support labels. When a label is not available from the packet, a default label is assigned to the message from trusted networking database files. These labels are then used during accreditation checks. Trusted Extensions enforces several checks on outgoing messages, forwarded messages, and incoming messages.

Source Accreditation Checks

The following accreditation checks are performed on the sending process or sending zone:

• For all destinations, the label of the data must be within the label range of the next hop in the route, that is, the first hop. And, the label must be contained in the first-hop gateway's security attributes.

• For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of all hops along the route, including its first-hop gateway.

• When the destination host is an unlabeled host, one of the following conditions must be satisfied:

  • The sending host's label must match the destination host's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label dominates the destination's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label is ADMIN_LOW. That is, the sender is sending from the global zone.

A first-hop check occurs when a message is being sent through a gateway from a host on one network to a host on another network.

Gateway Accreditation Checks

On a Trusted Extensions gateway system,the following accreditation checks are performed for the next-hop gateway:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• Checks for forwarding a packet proceed similar to source accreditation:

  • For all destinations, the label of the data must be within the label range of the next hop. And, the label must be contained in the security attributes of the next-hop host.

  • For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of the next-hop host.

  • The label of an unlabeled packet must match the destination host's default label.

  • The label of a CIPSO packet must be within the destination host's label range.

Destination Accreditation Checks

When a Trusted Extensions host receives data, the software performs the following checks:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• The label and DOI for the packet must be consistent with the destination zone or destination process's label and DOI. The exception is when a process is listening on a multilevel port. The listening process can receive a packet if the process is privileged to perform cross-label communications, and the process is either in the global zone or has a label that dominates the packet's label.

Administration of Routing in Trusted Extensions

Trusted Extensions supports several methods for routing communications between networks. In the Security Administrator role, you can set up routes that enforce the degree of security required by your site's security policy.

For example, sites can restrict communications outside the local network to a single label. This label is applied to publicly available information. Labels such as UNCLASSIFIED or PUBLIC can indicate public information. To enforce the restriction, these sites assign a single-label template to the network interface that is connected to the external network. For more details about TCP/IP and routing, see the following:

• Planning for Routers on Your Network in System Administration Guide: IP Services

• Configuring Systems on the Local Network in System Administration Guide: IP Services

• Major TCP/IP Administrative Tasks (Task Map) in System Administration Guide: IP Services

• Preparing Your Network for the DHCP Service (Task Map) in System Administration Guide: IP Services

Choosing Routers in Trusted Extensions

Trusted Extensions hosts offer the highest degree of trust as routers. Other types of routers might not recognize Trusted Extensions security attributes. Without administrative action, packets can be routed through routers that do not provide MAC security protection.

• CIPSO routers drop packets when they do not find the correct type of information in the IP options section of the packet. For example, a CIPSO router drops a packet if it does not find a CIPSO option in the IP options when the option is required, or when the DOI in the IP options is not consistent with the destination's accreditation.

• Other types of routers that are not running Trusted Extensions software can be configured to either pass the packets or drop the packets that include the CIPSO option. Only CIPSO-aware gateways such as Trusted Extensions provides can use the contents of the CIPSO IP option to enforce MAC.

To support trusted routing, the Solaris Express Community Edition routing tables are extended to include Trusted Extensions security attributes. The attributes are described in Routing Table Entries in Trusted Extensions. Trusted Extensions supports static routing, in which the administrator creates routing table entries manually. For details, see the -p option in the route(1M) man page.

The routing software tries to find a route to the destination host in the routing tables. When the host is not explicitly named, the routing software looks for an entry for the subnetwork where the host resides. When neither the host nor the network where the host resides is defined, the host sends the packet to a default gateway, if defined. Multiple default gateways can be defined, and each is treated equally.

In this release of Trusted Extensions, the security administrator sets up routes manually, and then manually changes the routing table when conditions change. For example, many sites have a single gateway that communicates with the outside world. In these cases, the single gateway can be statically defined as the default on each host on the network. Dynamic routing support might be available in future releases of Trusted Extensions.

Gateways in Trusted Extensions

An example of routing in Trusted Extensions follows. The diagram and table show three potential routes between Host 1 and Host 2.

Figure 18–1 Typical Trusted Extensions Routes and Routing Table Entries

• Route #1 can transmit packets within the label range of CONFIDENTIAL to SECRET.

• Route #2 can transmit packets from ADMIN_LOW to ADMIN_HIGH.

• Route #3 does not specify routing information. Therefore, its security attributes are derived from the template in the tnrhtp database for Gateway 5.

Routing Commands in Trusted Extensions

To show labels and extended security attributes for sockets, Trusted Extensions modifies the following Solaris network commands:

• The netstat -rR command displays the security attributes in routing table entries.

• The netstat -aR command displays the security attributes for sockets.

• The route -p command with the add or delete option changes the routing table entries.

For details, see the netstat(1M) and route(1M) man pages.

For examples, see How to Configure Routes With Security Attributes.

Administration of Labeled IPsec

Solaris Trusted Extensions systems can protect labeled network packets with IPsec. The IPsec packets can be sent with explicit or implicit Trusted Extensions labels. Labels are sent explicitly by using CIPSO IP options and implicitly by using labeled IPsec security associations (SAs). Also, IPsec encrypted packets with different implicit labels can be tunneled across an unlabeled network.

For general IPsec concepts and configuration procedures, see Part III, IP Security, in System Administration Guide: IP Services. For Trusted Extensions modifications to IPsec procedures, see Configuring Labeled IPsec (Task Map).

Labels for IPsec-Protected Exchanges

All communications on Trusted Extensions systems, including IPsec-protected communications, must satisfy security label accreditation checks. The checks are described in Trusted Extensions Accreditation Checks.

The labels on IPsec packets that must pass these checks are the inner label, the wire label, and the key management label:

• Application security label – The label of the zone in which the application resides.

• Inner label – The label of the unencrypted message data before IPsec AH or ESP headers have been applied. This label can be different from the application security label when the SO_MAC_EXEMPT socket option (MAC-exempt) or multilevel port (MLP) features are being used. When selecting security associations (SAs) and IKE rules that are constrained by labels, IPsec and IKE use this inner label.

  By default, the inner label is the same as the application security label. Typically, applications at both ends have the same label. However, for MAC-exempt or MLP communication, this condition might not be true. IPsec configuration settings can define how the inner label is conveyed across the network, that is, they can define the wire label. IPsec configuration settings cannot define the value of the inner label.

• Wire label – The label of the encrypted message data after IPsec AH or ESP headers have been applied. Depending on the IKE and IPsec configuration files, the wire label might be different from the inner label.

• Key management label – All IKE negotiations between two nodes are controlled at a single label, regardless of the label of application messages that trigger the negotiations. The label of IKE negotiations is defined in the /etc/inet/ike/config file on a per-IKE rule basis.

Label Extensions for IPsec Security Associations

IPsec label extensions are used on Trusted Extensions systems to associate a label with the traffic that is carried inside a security association (SA). By default, IPsec does not use label extensions and therefore ignores labels. All traffic between two systems flows through a single SA, regardless of the Trusted Extensions label.

Label extensions enable you to do the following:

• Configure a different IPsec SA for use with each Trusted Extensions label. This configuration effectively provides an additional mechanism for conveying the label of traffic that travels between two multilevel systems.

• Specify an on-the-wire label for IPsec encrypted message text that is different from the unencrypted form of the text. This configuration supports the transmission of encrypted confidential data through a less secure network.

• Suppress the use of CIPSO IP options in IP packets. This configuration enables labeled traffic to traverse CIPSO-unaware or CIPSO-hostile networks.

You can specify whether to use label extensions automatically through IKE as described in Label Extensions for IKE, or manually through the ipseckey command. For details on the label extensions features, see the ipseckey(1M) man page.

When using label extensions, SA selection for outbound traffic includes the inner sensitivity label as part of the match. The security label of inbound traffic is defined by the security label of received packet's SA.

Label Extensions for IKE

IKE on Trusted Extensions systems supports the negotiation of labels for SAs with label-aware peers.

You can control this mechanism by using the following keywords in the /etc/inet/ike/config file:

• label_aware – Enables the in.iked daemon's use of Trusted Extensions label interfaces and the negotiation of labels with peers.

• single_label – Indicates that the peer does not support the negotiation of labels for SAs.

• multi_label – Indicates that the peer supports the negotiation of labels for SAs. IKE creates a new SA for each additional label that IKE encounters in the traffic between two nodes.

• wire_label inner – Causes the in.iked daemon to create labeled SAs where the wire label is the same as the inner label. The key management label is ADMIN_LOW when the daemon is negotiating with cipso peers. The key management label is the peer's default label when the daemon is negotiating with unlabeled peers. Normal Trusted Extensions rules are followed for inclusion of the CIPSO IP options in transmitted packets.

• wire_label label – Causes the in.iked daemon to create labeled SAs where the wire label is set to label, regardless of the value of the inner label. The in.iked daemon performs key management negotiations at the specified label. Normal Trusted Extensions rules are followed for inclusion of CIPSO IP options in transmitted packets.

• wire_label none label – Causes behavior similar to wire_label label, except that CIPSO IP options are suppressed on transmitted IKE packets and data packets under the SA.

For more information, see the ike.config(4) man page.

Labels and Accreditation in Tunnel Mode IPsec

When application data packets are protected by IPsec in tunnel mode, the packets contain multiple IP headers.

The IKE protocol's IP header contains the same source and destination address pair as the application data packet's outer IP header.

Trusted Extensions uses the inner IP header addresses for inner label accreditation checks. Trusted Extensions performs wire and key management label checks by using the outer IP header addresses. For information about the accreditation checks, see Trusted Extensions Accreditation Checks.

Confidentiality and Integrity Protections With Label Extensions

The following table explains how IPsec confidentiality and integrity protections apply to the security label with various configurations of label extensions.

You cannot use IPsec AH integrity protections to protect the CIPSO IP option if CIPSO-aware routers might strip or add the CIPSO IP option as a message travels through the network. Any modification to the CIPSO IP option will invalidate the message and cause a packet that is protected by AH to be dropped at the destination.