[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISAKMP commit and notify usage
I am trying to understand the usage of the ISAKMP commit bit flag and
notify messages.
The ISAKMP header contains a flags field which contains a commit bit. When
set by the sender this tells the peer ISAKMP not to use the (ISAKMP or
IPSEC ?) SA until the sender transmits an informational exchange.
Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that
once an ISAKMP SA has been established, the Informational Exchange MUST be
transmitted under the protection provided by the ISAKMP SA.
- Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC?
As an example which of the following Identity Protection Exchanges is
correct?
1. No ISAKMP Encryption Until Notified
Initiator direction Responder Note
(1) HDR: SA ==> Begin ISAKMP - SA
(2) <== HDR; SA
(3) HDR; KE; Nonce ==> Commit flag set
(4) <== HDR; KE; Nonce
Key generated
(5) HDR; Notify ==> Information Exchange
is not protected by
the SA
(6) HDR*; IDii; AUTH ==> ID is encrypted
(7) <== HDR*; IDir; AUTH
2. No IPSEC Encryption Until Notified
Initiator direction Responder Note
(1) HDR: SA ==> Begin ISAKMP - SA
(2) <== HDR; SA
(3) HDR; KE; Nonce ==> Commit flag set
(4) <== HDR; KE; Nonce
Key generated
(5) HDR*; IDii; AUTH ==> ID is encrypted
(6) <== HDR*; IDir; AUTH
(7) HDR; Notify ==> Information Exchange
is protected by
the SA
- What notify message type payload is used to commit/tell the peer ISAKMP
that it is time to start using the encryption key/SA?
- Is there an integrity check on the Notification Payload? Does each piece
of notification data define its own integrity mechanism? The OAKLEY error
payload appends a Sig/prf Payload.
Thanks,
Tom Markham markham@securecomputing.com
Secure Computing Corporation Phone (612) 628-2754
2675 Long Lake Road Fax: (612) 628-2701
Roseville, MN 55113 www.securecomputing.com
Follow-Ups: