if the participants have their own private key and a generated public key
Diffie-Hellman doesn't have a public and private key. Let's imagine you're in a room with at least three people: Alice, Bob and Eve. Alice and Bob want to talk privately (and going into a different room is too easy), so Alice proposes to use Diffie-Hellman:
Alice: Let's do a DH key exchange. Pick a random number and raise 5 to the power of that number. Divide the result by 23 and tell me the remainder.
Alice picks 16,
5**16=152587890625, and the remainder when divided by 23 is 3.
Bob picks 25,
5**25=298023223876953125, and the remainder when divided by 23 is 10.
Alice: I got 3. Now raise my number to the power of that number again, and divide by 23 again, and take the remainder.
Alice raises Bob's 10 to the power 16,
10**16=10000000000000000, and takes the remainder when dividing by 23,
Bob raises Alice's 3 to the power 25,
3**25=847288609443, and takes the remainder when dividing by 23,
They got the same result. They have a common number that Eve does not know. Eve only heard that Alice sent 3 to Bob, and that Bob sent 10 to Alice. She cannot compute the number 4.
Alice: Now use this key for AES and let's speak encrypted!
Of course, in the real world, the numbers are all much bigger. Guessing that the password for AES is "4" is not very difficult.
Do we need to specify it, put a digital signature in the messages or can we assume authentication whenever there is a public key involved?
In the above example, Alice and Bob could see each other. If Alice spoke, Bob could see that is was Alice. On the Internet, this is not the case. It's more like communicating by letter: anyone delivering mail could inject fake letters.
So you still need to digitally sign this exchange, to be sure that a (wo)man in the middle does not inject anything into the conversation. Diffie-Hellman cannot do this, so you need an additional algorithm: one that uses public and private keys. The most popular systems to do this are the RSA algorithm and elliptic curve cryptography.
How digital signatures work is explained abundantly elsewhere. Just apply digital signatures to the above conversation (where Alice gives the parameters 5 and 23, where Bob says 10 and where Alice says 3) and you have an authenticated key exchange protocol.
But to exchange public keys, you have the same issue: how do you know that nobody in the middle switched out the real public key for their own public key? That is what Certificate Authorities (CAs) are used for: they are a trusted third party, and they put a digital signature on the public key. Another way of solving this is TOFU: Trust On First Use. This has the disadvantage that, if your first communication was already intercepted, then your communication is compromised. But it has the advantage that there is no CA system needed, and thus there is no CA that can be compromised.