Main mode scenario 1
Key policy definition is based on the identities of remote ISAKMP servers. Unfortunately, during a Main mode exchange the responding ISAKMP server must accept a key proposal prior to learning the identity of the initiating ISAKMP server. The responder must later verify that the proposal that was agreed to is acceptable with defined policy when the identity becomes known.
The z/OS® IKE daemon
handles this limitation as follows:
- Upon receipt of message 1, the IKE daemon uses the IP address
of the initiator and responder to find an applicable KeyExchangeRule,
which encapsulates the key policy:
- If an applicable KeyExchangeRule is found, it is considered tentative until the identity of the initiator becomes known.
- Upon receipt of message 5, which includes the initiator's identity,
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.