I'm not sure which of the inputs in your HMAC is your key and which one the message. The secret should be in the key position here.
Also, you might want to include the message (either plaintext or ciphertext) itself in the MAC - otherwise you are vulnerable to an attacker which can change the data (even if he can't read it, and does not exactly know to what he is changing).
About your comment:
Perhaps I didn't make clear that the HMAC only serves as an identification method to Party 2 without revealing the actual ID or SECRET (the values I'm trying to hide).
The point is, if your authentication relies only on HMAC(secret, ID)
, then this value is the effective password, as it does not change between messages.
These are not bound to the message, which means that a changed message is accepted anyways.
Why will it be better to include a MAC of the ciphertext? The ciphertext is encrypted
and as such one needs the SECRET (key) to successfully change the underlying input.
If an attacker tries to change the ciphertext (without knowing the key), the intended
recipient of the message will run into an error decrypting the ciphertext, or the
underlying message will fail to be validated.
From this point of view, you don't need the identifying first part of the message at all.
There will not be an error on decrypting a changed message - just the result will be garbage. It depends on the message type which you are transporting here, whether this garbage can actually be identified as such. Using something like
MAC(ID + ciphertext, secret)
makes sure that the receiver will not even try to decrypt a faked message.