JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: IP Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

Part I TCP/IP Administration

1.  Planning the Network Deployment

2.  Considerations When Using IPv6 Addresses

3.  Configuring an IPv4 Network

4.  Enabling IPv6 on the Network

5.  Administering a TCP/IP Network

6.  Configuring IP Tunnels

7.  Troubleshooting Network Problems

8.  IPv4 Reference

9.  IPv6 Reference

Part II DHCP

10.  About DHCP (Overview)

11.  Administering the ISC DHCP Service

12.  Configuring and Administering the DHCP Client

13.  DHCP Commands and Files (Reference)

Part III IP Security

14.  IP Security Architecture (Overview)

15.  Configuring IPsec (Tasks)

16.  IP Security Architecture (Reference)

17.  Internet Key Exchange (Overview)

Key Management With IKE

IKE Key Negotiation

IKE Key Terminology

IKE Phase 1 Exchange

IKE Phase 2 Exchange

IKE Configuration Choices

IKE With Preshared Key Authentication

IKE With Public Key Certificates

IKE Utilities and Files

18.  Configuring IKE (Tasks)

19.  Internet Key Exchange (Reference)

20.  IP Filter in Oracle Solaris (Overview)

21.  IP Filter (Tasks)

Part IV Networking Performance

22.  Integrated Load Balancer Overview

23.  Configuration of Integrated Load Balancer (Tasks)

24.  Virtual Router Redundancy Protocol (Overview)

25.  VRRP Configuration (Tasks)

26.  Implementing Congestion Control

Part V IP Quality of Service (IPQoS)

27.  Introducing IPQoS (Overview)

28.  Planning for an IPQoS-Enabled Network (Tasks)

29.  Creating the IPQoS Configuration File (Tasks)

30.  Starting and Maintaining IPQoS (Tasks)

31.  Using Flow Accounting and Statistics Gathering (Tasks)

32.  IPQoS in Detail (Reference)

Glossary

Index

IKE Configuration Choices

The /etc/inet/ike/config configuration file contains IKE policy entries. For two IKE daemons to authenticate each other, the entries must be valid. Also, keying material must be available. The entries in the configuration file determine the method for using the keying material to authenticate the Phase 1 exchange. The choices are preshared keys or public key certificates.

The entry auth_method preshared indicates that preshared keys are used. Values for auth_method other than preshared indicate that public key certificates are to be used. Public key certificates can be self-signed, or the certificates can be installed from a PKI organization. For more information, see the ike.config(4) man page.

IKE With Preshared Key Authentication

Preshared keys are used to authenticate two peer systems. The preshared key is a hexadecimal number or ASCII string that is created by an administrator on one system. The key is then shared with administrators of the peer system in a secure way. If the preshared key is intercepted by an adversary, that adversary might be able to impersonate one of the peer systems.

The preshared key on the peers that use this authentication method must be identical. The keys are tied to a particular IP address or range of addresses. The keys are placed in the /etc/inet/secret/ike.preshared file on each system. For more information, see the ike.preshared(4) man page.

IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Public keys use the Diffie-Hellman algorithm (DH) for authenticating and negotiating keys. Public key certificates come in two flavors. The certificates can be self-signed, or the certificates can be certified by a certificate authority (CA).

Self-signed public key certificates are created by you, the administrator. The ikecert certlocal -ks command creates the private part of the public-private key pair for the system. You then get the self-signed certificate output in X.509 format from the remote system. The remote system's certificate is input to the ikecert certdb command for the public part of the key pair. The self-signed certificates reside in the /etc/inet/ike/publickeys directory on the communicating systems. When you use the -T option, the certificates reside on attached hardware.

Self-signed certificates are a halfway point between preshared keys and CAs. Unlike preshared keys, a self-signed certificate can be used on a mobile machine or on a system that might be renumbered. To self-sign a certificate for a system without a fixed number, use a DNS (www.example.org) or email (root@domain.org) alternative name.

Public keys can be delivered by a PKI or a CA organization. You install the public keys and their accompanying CAs in the /etc/inet/ike/publickeys directory. When you use the -T option, the certificates reside on attached hardware. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, you are responsible for installing the CRL in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside organization, rather than by the site administrator. In a sense, CAs are notarized certificates. As with self-signed certificates, CAs can be used on a mobile machine or on a system that might be renumbered. Unlike self-signed certificates, CAs can very easily scale to protect a large number of communicating systems.