Why does device authentication take place last in IKEv1 phase 1 main mode?

The operation IKEv1 can be broken down into two phases. 1) Phase 1 (IKE SA Negotiation) and 2) Phase 2 (IPSec SA Negotiation). IKEv1 Phase 1 SA negotiation is for protecting IKE. IKEv1 Phase 2 SA negotiation is for protecting IPSec (real user traffic). IKEv1 Phase 1 negotiation can happen in two modes, either using Main Mode or using Aggressive Mode. IKEv1 Phase 1 Main mode has three pairs of messages (total six messages) between IPSec peers. IKE Phase 1 Aggressive Mode has only three message exchanges. The purpose of IKEv1 Phase 1 is to establish IKE SA. IKEv1 Phase 2 (Quick Mode) has only three messages. The purpose of IKEv1 Phase 2 is to establish IPSec SA. Phase 1 is used to negotiate the parameters and key material required to establish IKE Security Association (SA) between two IPSec peers. The Security Associations (SAs) negotiated in Phase 1 is then used to protect future IKE communication. Following explanation is based on the assumption that the peers are using Pre-Shared Key for authentication.

This is to verify tunnel peers IP address in encryted form. The main purpose of main mode is matching IKE SAs b/w peers to provide a protected tunnel for subsequent protected ISAKMP exchanges and this is achieve thru six messgaes echnaged b/w the peers. During these exchegae other tunnel parameters were also negotiated.

An IKE session begins with the initiator sending a proposal or proposals to the responder. The proposals define what encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy should be enforced, for example. Multiple proposals can be sent in one offering. The first exchange between nodes establishes the basic security policy; the initiator proposes the encryption and authentication algorithms it is willing to use. The responder chooses the appropriate proposal (we'll assume a proposal is chosen) and sends it to the initiator. The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA. The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (Quick Mode) begins. (so in other words the introduction and proposal process has been completed and now the devices are now now in agreement now its like the signature to approve the association)

In the main mode totaly six messages are being exchanged between authentication parties, in the first 2 messages ISAKMP SA parameters such as encryption type, hasshing algorithm and DH group are negotiated. After that DH algorithm (Asymetric) is being run by 2 parties and kyes are exchanged which is done in third and fourth message. Finally the initiator sends its hostname or FQDN as an identity payload to responder which is received and accepted by responder, this happens in the 5th and 6th message of the main mode which completes the authentication process.

This is the reason why authentication takes place last in the IKEv1 Phase1 

Hello!To do device Authentication within IKEV1 phase1, we need first to encrypt our negotiations (Hashing, lifetime, encryption, ......) and to do that, we need to generate psk (that is generated by DH).

So first we negotiate (Hashing, Encryption and lifetime) then we negotiate DH (Diffie-Hellman) to generate PSK that we will use it to do device Authentication

so we use it last in IKEV1 phase1

IKEV1 is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA).The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption.

The authentication occurs in the last step as they have to agree on the encryption suit, hashing and DH first to be able to encrypt the key that is matched between them for authentication. Without selecting first the proposals we won't be able to generate a shared secret key to encrypt further IKE communications.

I can't understand your question proberly !