Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: IP Services Oracle Solaris 11 Information Library |
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
7. Troubleshooting Network Problems
11. Administering the ISC DHCP Service
12. Configuring and Administering the DHCP Client
13. DHCP Commands and Files (Reference)
14. IP Security Architecture (Overview)
16. IP Security Architecture (Reference)
17. Internet Key Exchange (Overview)
IKE With Preshared Key Authentication
IKE With Public Key Certificates
19. Internet Key Exchange (Reference)
20. IP Filter in Oracle Solaris (Overview)
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)
The IKE daemon, in.iked, negotiates and authenticates keying material for IPsec SAs in a secure manner. The daemon uses random seeds for keys from internal functions provided by the OS. IKE provides perfect forward secrecy (PFS). In PFS, the keys that protect data transmission are not used to derive additional keys. Also, seeds used to create data transmission keys are not reused. See the in.iked(1M) man page.
The following table lists terms that are used in key negotiation, provides their commonly used acronyms, and gives a definition and use for each term.
Table 17-1 Key Negotiation Terms, Acronyms, and Uses
|
The Phase 1 exchange is known as Main Mode. In the Phase 1 exchange, IKE uses public key encryption methods to authenticate itself with peer IKE entities. The result is an Internet Security Association and Key Management Protocol (ISAKMP) security association (SA). An ISAKMP SA is a secure channel for IKE to negotiate keying material for the IP datagrams. Unlike IPsec SAs, the ISAKMP SAs are bidirectional, so only one security association is needed.
How IKE negotiates keying material in the Phase 1 exchange is configurable. IKE reads the configuration information from the /etc/inet/ike/config file. Configuration information includes the following:
Global parameters, such as the names of public key certificates
Whether perfect forward secrecy (PFS) is used
The interfaces that are affected
The security protocols and their algorithms
The authentication method
The two authentication methods are preshared keys and public key certificates. The public key certificates can be self-signed. Or, the certificates can be issued by a certificate authority (CA) from a public key infrastructure (PKI) organization.
The Phase 2 exchange is known as Quick Mode. In the Phase 2 exchange, IKE creates and manages the IPsec SAs between systems that are running the IKE daemon. IKE uses the secure channel that was created in the Phase 1 exchange to protect the transmission of keying material. The IKE daemon creates the keys from a random number generator by using the /dev/random device. The daemon refreshes the keys at a configurable rate. The keying material is available to algorithms that are specified in the configuration file for IPsec policy, ipsecinit.conf.