Main mode scenario 2

Pre-shared keys are defined based on the identities of ISAKMP servers. Ideally, pre-shared keys are unique between ISAKMP server pairs. Unfortunately, during a Main mode exchange the responding ISAKMP server must determine the pre-shared key to use before learning the identity of the initiating ISAKMP server.

The z/OS® IKE daemon handles this limitation as follows:
  1. A key proposal is selected as described in Main mode scenario 1.
  2. If the selected key proposal indicates pre-shared key mode authentication, then the IKE daemon must use a pre-shared key to generate message 4.
  3. Upon receipt of message 5, the IKE daemon must use the same pre-shared key to decrypt the message to learn the identity of the initiating ISAKMP server.
  4. After message 5 is successfully decrypted, the IKE daemon uses the IP address of the initiator, the IP address of the responder, and the identity of the initiator to find an applicable KeyExchangeRule:
    • If a KeyExchangeRule is not found or is found but is inconsistent with the proposal accepted in message 1, the negotiation fails.
    • If a KeyExchangeRule is found and is consistent with the proposal accepted in message 1, it is considered final, and the negotiation proceeds.
Parent topic: ISAKMP Main mode limitations