Configuring Authentication Records with IKE IDs

HP-UX IPSec uses IKE ID information to verify the identity that the remote system sends as part of the ISAKMP negotiation. HP-UX IPSec also verifies the IKE ID with the information in the remote system’s certificate.

HP-UX IPSec stores IKE information in authentication records. You do not have to configure authentication records with ID information if all the systems using certificate-based authentication meet the following conditions:

The local system is not multihomed.
None of the remote systems using certificate-based authentication are multihomed.
All of the remote systems using certificate-based authentication are HP-UX systems or systems from other vendors that use IPv4 addresses as the IKE ID (ISAKMP payload ID).

If you do not have to configure ID information, continue to “Retrieving the Certificate Revocation List (CRL)”.

As part of the ISAKMP/MM SA negotiation, the IKE peers exchange and verify ID types and ID values. During an ISAKMP/MM negotiation, HP-UX IPSec uses the remote system address to search for an authentication record. For certificate-based authentication, the authentication record can contain the following IKE ID information:

local ID type
local ID value
remote ID type
remote ID value

If HP-UX finds an authentication record that matches the remote IP address, HP-UX IPSec sends the configured local ID information in an ISAKMP ID payload. If the matching authentication record has no local ID information, HP-UX IPSec sends the IP address of the interface it is using for the IKE negotiation as the local ID value, and sends the appropriate address type (IPv4) as the local ID type.

If the matching authentication record has remote ID information, HP-UX IPSec uses it to verify what the remote system sends in the ISAKMP ID payload. HP-UX IPSec also verifies that the remote ID information matches ID information in the remote system’s certificate.

If the matching authentication record has no remote ID information for the remote system, HP-UX IPSec uses the remote system’s IP address (the source IP address from the inbound packet) as the remote ID value and the appropriate IP address type as the remote ID type. HP-UX then verifies that the remote ID information matches the information it receives in the ISAKMP ID payload and ID information in the remote system’s certificate.

Configuring Authentication Records with Certificate-Based Authentication

You must configure IKE/ISAKMP ID information in authentication records if any systems using certificate-based authentication meet the following conditions:

The local system is multihomed.
You must configure authentication records for the remote systems with local type set to IPV4, and the local ID value set to the IPv4 address in the security certificate for the local system. This causes HP-UX IPSec to send the correct local ID type and value to the remote system.
Use the procedures in “Determining the IPv4 Address in the SubjectAlternativeName” if you do not know the IPv4 address in the SubjectAlternativeName.
The remote system using certificate-based authentication is multihomed.
You must configure an authentication record for each IPv4 address on the remote system. Set the remote ID type and remote ID value to match the values configured on the multihomed system.
The remote system using certificate-based authentication is a non-HP system that does not use IPv4 addresses for IKE identification (the ISAKMP ID payload). For example, Microsoft systems use the Subject Distinguished Name as the ID type.
Configure the remote ID type and remote ID value to match the type and value configured on the non-HP system.

Determining the IPv4 Address in the SubjectAlternativeName

You can use the following procedures to determine the SubjectAlternativeName for the local system’s certificate.

VeriSign

To determine the SubjectAlternativeName for a VeriSign certificate, select the certificate for the 127.0.0.1 address from the ipsec_mgr Certificates screen, then click Details. The Subject box contains the SubjectName, followed by the SubjectAlternativeName IPv4 address. The SubjectAlternativeName is circled in Figure 4-2 “VeriSign SubjectAlternativeName”. The actual node name and IPv4 address captured in the screen image were obscured for publication.)

Figure 4-2 VeriSign SubjectAlternativeName

Baltimore

The IPv4 address in the SubjectAlternativeName field is the IPv4 address specified in the certificate request form of the Registration Authority Operator (RAO) utility. If you did not request the certificate, or do not remember the IPv4 address, contact the Baltimore CA Administrator.

Syntax

You can use the following ipsec_config add auth syntax to configure authentication records with ID information in most installations:

ipsec_config add auth auth_name 
-remote ip_addr[/prefix] 
[-ltype local_id_type] [-lid local_id] 
[-rtype remote_id_type] [-rid remote_id]

HP recommends that you use an ipsec_config batch file to configure HP-UX IPSec. To specify an add auth operation for an ipsec_config batch file, use the above syntax without the ipsec_config command name:

add auth auth_name -remote ip_addr[/prefix] 
[-ltype local_id_type] [-lid local_id] 
[-rtype remote_id_type] [-rid remote_id]

The full ipsec_config add auth syntax specification also allows you to specify the following arguments:

nocommit (verify the syntax but do not commit the information to the database)
profile (alternate profile file)
preshared (preshared key)

Refer to the ipsec_config(1M) manpage for full syntax information.

`auth_name`

The user-defined name for the authentication record. This name must be unique for each record and is case-sensitive.

Acceptable Values: 1 - 63 characters. Each character must be an ASCII alphanumeric character, hyphen (-), or underscore (_).

`ip_addr`[/`prefix`]

The IP address and network prefix length that specifies the remote system or subnet for this record. Each ip_addr and prefix combination (the significant bits of ip_addr, as specified by prefix) must be unique.If the remote system's IP address matches multiple IP address and prefix combinations, HP-UX IPSec uses the authentication record with the most specific address (longest prefix length).

Where:

`ip_addr`

The ip_addr is the remote IP address.

Acceptable Values: An IPv4 address in dotted-decimal notation or an IPv6 address in colon-hexadecimal notation. The address cannot be a broadcast, subnet broadcast, or multicast address.

Default: None.

`prefix`

The prefix is the prefix length, or the number of leading bits that must match when comparing the remote IP address with ip_addr.

For IPv4 addresses, a prefix length of 32 bits indicates that all the bits in both addresses must match. This prefix length is equivalent to an address mask of 255.255.255.255. Use a value less than 32 to specify a subnet address filter.

For IPv6 addresses, a prefix length of 128 bits indicates that all the bits in both addresses must match. Use a value less than 128 to specify a subnet address filter.

Range: 0 - 32 for an IPv4 address; 0 - 128 for an IPv6 address. If you are using manual keys, prefix must be 32 if ip_addr is an IPv4 address or 128 if ip_addr is an IPv6 address.

Default: 32 if ip_addr is a non-zero IPv4 address, 128 if ip_addr is a non-zero IPv6 address, or 0 (match any address) if ip_addr is an all-zeros address (0.0.0.0 or 0::0).

`-ltype` `local_id_type`

The local_id_type is the ID type the local system sends to the remote system when negotiating an ISAKMP/MM SA. This must match what is configured on the remote system.

You do not have to configure the local ID type if the local system is not multihomed.

Acceptable Values: When you are using security certificates, this must match the ID type in the SubjectAlternativeName field, so the only acceptable value is IPV4 (IPv4 address).

Default: IPV4, if the IKE daemon uses an IPv4 interface to communicate with the remote system, or IPV6, if the IKE daemon uses an IPv6 interface to communicate with the remote system.

`-lvalue` `local_id`

The local_id is the local ID value the local system sends to the remote system when negotiating an ISAKMP/MM SA. This must match what is configured on the remote system.

You do not have to configure the local ID value if the local system is not multihomed

Acceptable Values: When you are using security certificates, this must be the IPv4 address in the SubjectAlternativeName of the certificate for the local system.

Default: If local_id_type and local_id are not specified, HP-UX uses the IPv4 or IPv6 address of the interface the IKE daemon uses to communicate with the remote system.

`-rtype` `remote_id_type`

The remote_id_type is the ID type used to verify the ID type sent by the remote system when negotiating a ISAKMP/MM SA). This must match what is configured on the remote system.

You do not have to configure the remote ID type if the remote system is an HP-UX system or a non-HP system that uses IPv4 addresses as the ID type, and is not multihomed.

Acceptable Values: For certificate-based authentication, the acceptable values are IPV4 (IPv4 address), FQDN (Fully Qualified Domain Name, also known as Domain Name Server or DNS name), USER-FQDN (User-Fully Qualified Domain Name in Simple Mail Transfer Protocol (SMTP) format, X500-DN (X.500 Subject Distinguished Name or DN; encoded using OSI Abstract Syntax Notation One Distinguished Encoding Rules, ASN.1 DER). The ID type IPV6 is not valid with certificate-based authentication.

Default: IPV4. The ID type is based on the type of interface the IKE daemon uses to communicate with the remote system. For certificate-based authentication, the interface type will be IPV4.

`-rid` `remote_id`

The remote_id is the ID value used to verify the ID value sent by the remote system when negotiating a ISAKMP/MM SA). This must match what is configured on the remote system.

You do not have to configure the remote ID value if the remote system is an HP-UX system or a non-HP system that uses IPv4 addresses as the ID type, and is not multihomed.

Acceptable Values: The acceptable values depend on the remote_id_type.

For remote_id_type IPV4, remote_id is the IPv4 address in dotted-decimal notation for the subject of the certificate (the system associated with the certificate). This must match the certificate SubjectAlternativeName.

For remote_id_type FQDN, remote_id is the Fully Qualified Domain Name (FQDN), also known as Domain Name Server or DNS name, such as myhost.hp.com). This must match the subject of the certificate.

For remote_id_type USER-FQDN, remote_id is the User-Fully Qualified Domain Name (User-FQDN) in SMTP format, such as user@myhost.hp.com. This must match the subject of the certificate.

For remote_id_type X500-DN, remote_id is the X.500 Distinguished Name. This must match the Subject distinguishedName (Subject DN) of the certificate. The format for the DN is:

CN=commonName,O=organization,C=country[,OU=organizationUnit]

Where:

commonName: The commonName of the Subject DN is printable string format. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

organization: The organization of the Subject DN, for example Hewlett-Packard. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

country: The two-character ISO 3166-1 code for the country listed in the Subject DN, for example US for United States of America. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

organizationUnit: The organizationalUnit for the Subject DN, for example Marketing. This field is optional. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

Default: If remote_id_type and remote_id are not specified, HP-UX uses the IPv4 or IPv6 address of the IP address of the remote system, from the source address of the inbound IP packets.

Examples

The remote system Mike with address 192.1.1.1 uses X.500 Distinguished Names as IKE IDs. The local system is not multihomed, so you do not have to specify local ID information.

ipsec_config add auth Mike -remote 192.1.1.1 \
-rtype X500-DN -rid CN=hostn,O=myco,c=US

You are using certificate-based authentication between HP-UX systems Black (10.10.10.10) and Zebra. Zebra is multihomed, with addresses 10.20.20.20 and 192.6.2.20. The security certificate for Zebra contains the address 10.20.20.20 as the SubjectAlternativeName.

On Black, you add the following entries to the ipsec_config batch file:

add auth Zebra1 -remote 10.20.20.20 -rtype IPV4 \
-rid 10.20.20.20

add auth Zebra2 -remote 192.6.2.21 -rtype IPV4 \
-rid 10.20.20.20

You do not have to specify local ID information in the above entries because Black is not multihomed, and uses its IPv4 address as its ID.

On Zebra, you add the following entry to the ipsec_config batch file:

add auth Black -remote 10.10.10.10 -ltype IPV4 \
-lid 10.20.20.20

You do not have to specify remote ID information in the above entry because Black is not multihomed, and uses its IPv4 address as its ID.

Configuring Authentication Records with IKE IDs

Technical documentation

» Table of Contents

» Glossary

» Index

Configuring Authentication Records with Certificate-Based Authentication

Determining the IPv4 Address in the SubjectAlternativeName

VeriSign

Baltimore

Syntax

`auth_name`

`ip_addr`[/`prefix`]

`ip_addr`

`prefix`

`-ltype` `local_id_type`

`-lvalue` `local_id`

`-rtype` `remote_id_type`

`-rid` `remote_id`

Examples

Configuring Authentication Records with IKE IDs

Technical documentation

» Table of Contents

» Glossary

» Index

Configuring Authentication Records with Certificate-Based Authentication

Determining the IPv4 Address in the SubjectAlternativeName

VeriSign

Baltimore

Syntax

auth_name

ip_addr[/prefix]

ip_addr

prefix

-ltype local_id_type

-lvalue local_id

-rtype remote_id_type

-rid remote_id

Examples

`auth_name`

`ip_addr`[/`prefix`]

`ip_addr`

`prefix`

`-ltype` `local_id_type`

`-lvalue` `local_id`

`-rtype` `remote_id_type`

`-rid` `remote_id`