Different parties are being
authenticated during each of the phases of negotiation. During the
first phase, the parties being authenticated are the ISAKMP
servers/hosts, while during the second phase, users or application
level programs are being authenticated.
If you look at the RFC of ISAKMP, in the section 2.3 (Negotiation phase) it talks about advantages of such implementation:
While the two-phased approach has a higher start-up cost for most
simple scenarios, there are several reasons that it is beneficial for
most cases.
First, entities (e.g. ISAKMP servers) can amortize the cost of the
first phase across several second phase negotiations. This allows
multiple SAs to be established between peers over time without having
to start over for each communication.
Second, security services negotiated during the first phase provide
security properties for the second phase. For example, after the
first phase of negotiation, the encryption provided by the ISAKMP SA
can provide identity protection, potentially allowing the use of
simpler second-phase exchanges. On the other hand, if the channel
established during the first phase is not adequate to protect
identities, then the second phase must negotiate adequate security
mechanisms.
Third, having an ISAKMP SA in place considerably reduces the cost of
ISAKMP management activity - without the "trusted path" that an
ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have
to go through a complete re-authentication for each error
notification or deletion of an SA.
