Solaris Trusted Extensions Administrator's Procedures

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 graphic shows an outer IP header followed by ESP
or AH, then an inner IP header, a TCP header, then data.

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

The graphic shows an outer IP header followed by a UDP
header, and finally the IKE key management protocol.

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.

Security Association	Confidentiality	Integrity
Without label extensions	Label is visible in the CIPSO IP option.	Message label in the CIPSO IP option is covered by AH, not by ESP. See Note.
With label extensions	A CIPSO IP option is visible, but represents the wire label, which might be different from the inner message label.	Label integrity is implicitly covered by the existence of a label-specific SA. On-the-wire CIPSO IP option is covered by AH. See Note.
With label extensions and CIPSO IP option suppressed	Message label is not visible.	Label integrity is implicitly covered by existence of a label-specific SA.

Security Association

Confidentiality

Integrity

Without label extensions

Label is visible in the CIPSO IP option.

Message label in the CIPSO IP option is covered by AH, not by ESP. See Note.

With label extensions

A CIPSO IP option is visible, but represents the wire label, which might be different from the inner message label.

Label integrity is implicitly covered by the existence of a label-specific SA.

On-the-wire CIPSO IP option is covered by AH. See Note.

With label extensions and CIPSO IP option suppressed

Message label is not visible.

Label integrity is implicitly covered by existence of a label-specific SA.

Note –

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.