Assigning Security Labels to IPv6 Addresses

Implementing and Administering an Multilevel Secure System › Assigning Security Labels to IPv6 Addresses

Assigning Security Labels to IPv6 Addresses

In z/OS V1R5, IBM created a new SESSION type, IP, and a new port-of-entry class, SERVAUTH, on the RACROUTE REQUEST=VERIFY/X macro. The SERVAUTH keyword specifies the address of the identifier of the server through which a user is trying to gain access to the system. The address points to a 1-byte length field followed by a 64-byte data area, which contains the name of the resource in the SERVAUTH class. This resource name is the network access security zone name that contains the IPv6 address of the user. Security zone mappings are defined in the NETACCESS parameter block in a TCP/IP profile.

The network access zone name to which IPv6 addresses are mapped is in the following format:

EZB.NETACCESS.sysname.stackname.zone

While MLS is inactive on a system, a security administrator should label all SERVAUTH resources that require MAC protection, including IPv6 addresses through which users will attempt to gain access to the system.

To protect system entry from an IPv6 address:

Assign an IPv6 address to a network security zone by creating a TCP/IP Profile definition. For example:
```
TCP/IP Profile:
NETACCESS
        9.24.104.0/24	ZONE1		
        9.24.104.119/32	ZONE2		
ENDNETACCESS
```
Create an appropriate CA Top Secret Seclabel record, which classifies the network access zone name and the IPv6 address mapped to it.
The following CA Top Secret MLS resource record would allow USERA to access the system from IPv6 address 9.24.104.119/32 which is in ZONE2 only if the security label with which USERA enters the system is equivalent to LABEL2 (the security label of the network security ZONE2) and resource rule validation also allows the access.
```
TSS ADD(MLS) SERVAUTH(ezb.netaccess.-.zone2)
             seclabel(label2)
```

Once this is done, and MLS is active on the system, if a security label is not specified by a user or application at signon, the seclabel is defaulted from the SERVAUTH resource (if there is one and it is not SYSMULTI), only if the user is authorized to it in his User SECLABEL acid record. If a security label is specified by a user or application at signon, system entry is allowed if the user is authorized to the security label specified, it is equivalent to the security label that is protecting the IPv6 address in the SERVAUTH profile (if there is one), and rule validation allows the access.

Security label checking is performed at system entry to ensure that the user's security label is equivalent to the security label of the SERVAUTH resource. If it is not, the user will be denied access to the system through the server. If the security label check succeeds, rule validation is then performed to ultimately allow or deny the access request.

Note: To allow a user to enter the system from an IPv6 address, do not assign a security label to the network security zone. In addition, create a resource rule for the network security zone in which the user's IPv6 address is mapped. Otherwise, access will be denied.

The following CA Top Secret resource rule would allow USERA access the system from IPv6 address 9.24.104.119/32, which is in ZONE2.

TSS PER(USERA) servauth(ezb.netaccess.-.zone2)
               access(read)

Important! To support IPv6 addresses, which are much longer than IPv4 addresses, the TERMID is no longer used as the source ID for IP-based ports of entry trying to gain access to the system and resources. Instead, the network access security zone name in the SERVAUTH class contains the IPv6 address of the user trying to gain access to the system and resources. This functionality replaces conversion of IPv4 addresses to hexadecimal terminal names.