IKE defines a two-phased protocol to establish IPsec SAs for the communication peers. In Phase I, an authenticated, ephemeral Diffie-Hellman exchange allows the peers to authenticate each other, and provides a secure communication channel (an IKE security association) for later use. The IKE SA created in Phase I is then used in Phase II to establish the IPsec SAs used in the ESP and AH security protocols. Multiple Phase II exchanges can be performed under a protection of a single Phase I IKE SA.
One of the following authentication methods must be chosen for the two IKE peers to authenticate each other:
Pre-shared key
DSS signatures
RSA signatures
RSA encryption
IKE supports the use of X.509 public key certificates for authentication. SunScreen maintains a certificate database for the local system's certificates and for certificates of IKE peers with which the system may communicate. Certificates can be generated on a SunScreen system itself--self-signed, and manually distributed and verified--or can be generated and signed by a certificate authority, the signature validated automatically using the certificate authority's public certificate. An alternative to certificates is the use of a pre-shared key by both peers to authenticate each other, but this method has some security disadvantages.
Other security parameters that must be chosen for Phase I include an encryption algorithm (SunScreen supports DES and Triple-DES), an authentication algorithm (SunScreen supports MD5 and SHA-1), and an Oakley Group (SunScreen supports groups 1, 2, and 5).
RSA-ENCRYPTION cannot use certificate payload. This precludes interoperating with Win2K using this authmethod. Since Win2K does not support this authmethod, this is not a significant problem. The following two conditions must be met for RSA-ENCRYPTION:
The certificate must have a Subject Alternative Names IP field.
The certificate RSA modulus should be at least 1024 bytes--to ensure that it is large enough for the subject name.