TCP/IP Tutorial and Technical Overview - IBM Redbooks

IKE phase 2: Setting up protocol Security Associations
After completing the phase 1 negotiation process to set up the ISAKMP Security
Associations, Host-A's next step is to initiate the Oakley phase 2 message
exchanges (also known as Oakley Quick Mode) to define the Security
Associations and keys that will be used to protect IP datagrams exchanged
between the pair of users. (In the Internet drafts, these are referred to somewhat
obtusely as “non-ISAKMP SAs.”)
Because the purpose of the phase 1 negotiations was to agree on how to protect
ISAKMP messages, all ISAKMP phase 2 payloads, but not the ISAKMP header
itself, must be encrypted using the algorithm agreed to by the phase 1
negotiations.
When Oakley Quick Mode is used in phase 2, authentication is achieved through
the use of several cryptographically based hash functions. The input to the hash
functions comes partly from phase 1 information (SKEYID) and partly from
information exchanged in phase 2. Phase 2 authentication is based on
certificates, but the phase 2 process itself does not use certificates directly.
Instead, it uses the SKEYID_a material from phase 1, which itself was
authenticated through certificates.
Oakley Quick Mode comes in two forms:
► Without a Key Exchange attribute, Quick Mode can be used to refresh the
cryptographic keys, but does not provide the property of Perfect Forward
Secrecy (PFS).
► With a Key Exchange attribute, Quick Mode can be used to refresh the
cryptographic keys in a way that provides PFS. This is accomplished by
including an exchange of public Diffie-Hellman values within messages 1
and 2.
Note: PFS apparently is a property that is very much desired by cryptography
experts, but strangely enough, the specifications treat PFS as optional. They
mandate that a system must be capable of handling the Key Exchange field
when it is present in a Quick Mode message, but do not require a system to
include the field within the message.
A detailed description of the phase 2 messages and exchanged information
follows.
840 TCP/IP Tutorial and Technical Overview