Can I use ChaCha20-Poly1305 as my KDF? I have two devices that use a PSK. One is embedded and extremely resource confined. I'm already using ChaCha20-Poly1305 so it would be &quot;free&quot; to reuse this. There is no transport encryption layer, all clear and has middlemen.
I want to establish a randomvalue/salt/kdf-base and send this to the other device on authentication so that I'm never actually using my PSK directly. Both sides know the PSK, and use this modifier to alter their stored key, and use a common derivative for packets going forward.
My plan was to use some KDF to modify my key into a temporary session key.
Is it satisfactory to use my existing AEAD like this:
nonce: the generated salt
payload: empty 
additional data: empty (OR a flag of key type I want, NIST 800-108)
key: my 16Byte PSK
tag: The 16Bytes I will use as this session's temporary key

What I FEEL like this is doing is giving me a tag that will be crypto secure to prevent leakage of my real PSK, and the salt will be OK to use here as well as send over the wire so the other side can do the same thing and evaluate the auth packets going forward.
Is this at all legitimate?
Since you have ChaCha20 as the cipher, it shouldn't occupy too much resource to add a BLAKE2 hash function next to it.
The BLAKE2 hash function comes in 2 variants: BLAKE2b, and BLAKE2s. ChaCha20 uses 32-bit words, which is more compatible with BLAKE2s. The only major difference between the hash and the cipher are the shift/rotate amounts, and the HAIFA hash compression function mode of operation.
While @SAI_Peregrinus have a good suggestion, I find it a little bit radical, so if you prefer a conservative approach, you can implement an additional BLAKE2 hash function to be used in any hash-based KDF you prefer.
As for your original ideal, I wouldn't recommend it as the authenticator is based on universal hashing in a biased modular integer arithmetic.