Administration of Labeled IPsec
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 CALIPSO or CIPSO IP options. Labels are sent implicitly by using labeled IPsec security associations (SAs). Additionally, IPsec encrypted packets with different implicit labels can be tunneled across an unlabeled network.
For general IPsec concepts and configuration procedures, see Securing the Network in Oracle Solaris 11.4. For Trusted Extensions modifications to IPsec procedures, see Configuring Labeled IPsec.
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.
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.
The labels on IPsec packets from an application in a labeled zone that must pass these checks are the inner label, the wire label, and the key management label:
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.
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 CALIPSO or CIPSO IP options in IP packets. This configuration enables labeled traffic to traverse label-unaware or label-hostile networks.
Label extensions enable you to do the following:
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(8) 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
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 labeled 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 labeled IP options in transmitted packets.
wire_label none label – Causes behavior similar to wire_label label, except that labeled IP options are suppressed on transmitted IKE packets and data packets under the SA.
IKEv1 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:
For more information, see the ike.config(5) 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 IKEv1 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.
|
Note - You cannot use IPsec AH integrity protections to protect the labeled IP option if label-aware routers might strip or add the labeled IP option as a message travels through the network. Any modification to the labeled IP option will invalidate the message and cause a packet that is protected by AH to be dropped at the destination.