I hope you mean drawback caused by AES CBC-MAC which is resolved in AES-CMAC.

AES_CBC MAC if used properly with ISO padding technique should not result into a tag collision.

So AES-CBC MAC should look something like this.

In AES-CBC MAC if the last block is not 16 byte aligned (considering AES as PRF) then padding must be done to the last block. Padding should be done based on ISO (bit padding, using binary one followed by zeros, e.g. $\texttt{100..00}$) For ISO 1 indicates the start of the padding. If the block is already 16 byte aligned then a dummy block (with ISO padding) should be concatenated . After this only the tag should be calculated.

Let's see the collision situation: last block say m is of 13 bytes. Hence as per ISO padding the block would become $m\|\texttt{100}$ and then tag will be calculated. What if there is a block called $m'$ which ends with $\mathtt{100}$ as the real data and if the dummy 16 byte block is not added then tag will be of same as with $m\|\mathtt{100}$. This means that a collision can be created.

As per security two different data should not result in the same MAC with the same Key. Hence it can become insecure.

To overcome this, there is a solution in AES-CMAC where there is no need to add a dummy block if the it is already block aligned to the PRF (in this case it is AES then 16 bytes aligned).

In AES CMAC there are three keys ($K$,$K_1$ and $K_2$). $K_1$ and $K_2$ are derived from $K$. For the subkeys ($K_1$ and $K_2$ ) generation, please see section 2.3 (Subkey Generation Algorithm).

If the last block is not aligned (16 bytes in case AES PRF) then pad the last block as ISO padding . Encrypt it with AES and XOR the output with $K_1$ . The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for padded case in AES-CMAC

If the last block is aligned (16 bytes in case AES as PRF) then XOR the output of the block with the $K_2$. The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for the non padded case.

Note: referenced from Professor Dan Boneh.

I hope you mean drawback caused by AES CBC-MAC which is resolved in AES-CMAC.

AES_CBC MAC if used properly with ISO padding technique should not result into a tag collision.

So AES-CBC MAC should look something like this.

In AES-CBC MAC if the last block is not 16 byte aligned (considering AES as PRF) then padding must be done to the last block. Padding should be done based on ISO (bit padding, using binary one followed by zeros, e.g. $\texttt{100..00}$) For ISO 1 indicates the start of the padding. If the block is already 16 byte aligned then a dummy block (with ISO padding) should be concatenated . After this only the tag should be calculated.

Let's see the collision situation: last block say m is of 13 bytes. Hence as per ISO padding the block would become $m\|\texttt{100}$ and then tag will be calculated. What if there is a block called $m'$ which ends with $\mathtt{100}$ as the real data and if the dummy 16 byte block is not added then tag will be of same as with $m\|\mathtt{100}$. This means that a collision can be created.

As per security two different data should not result in the same MAC with the same Key. Hence it can become insecure.

To overcome this, there is a solution in AES-CMAC where there is no need to add a dummy block if the it is already block aligned to the PRF (in this case it is AES then 16 bytes aligned).

In AES CMAC there are three keys ($K$,$K_1$ and $K_2$). $K_1$ and $K_2$ are derived from $K$. For the subkeys ($K_1$ and $K_2$ ) generation, please see section 2.3 (Subkey Generation Algorithm).

If the last block is not aligned (16 bytes in case AES PRF) then pad the last block as ISO padding . Encrypt it with AES and XOR the output with $K_1$ . The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for padded case in AES-CMAC

If the last block is aligned (16 bytes in case AES as PRF) then XOR the output of the block with the $K_2$. The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for the non padded case.

Note: referenced from Professor Dan Boneh.

I hope you mean drawback caused by AES CBC-MAC which is resolved in AES-CMAC.

AES_CBC MAC if used properly with ISO padding technique should not result into a tag collision.

So AES-CBC MAC should look something like this.

[Please look at the image in the above link] In AES-CBC MAC if the last block is not 16 byte alligned(considering AES as PRF) then padding must be done to the last block. Padding should be done based on ISO (100..00) For ISO 1 indicates the start of the padding. If the block is already 16 byte alligned then a dummy block (with ISO padding) should be concatenated . After this only the tag should be calculated.

Let's see the collision situation: last block say m is of 13 bytes. Hence as per ISO padding the block would become m||100 and then tag will be calculated. What if there is a block called m' which ends with 100 as the real data and if the dummy 16 byte block is not added then tag will be of same as with m||100. This means that there is a collision

As per security two different data should not result in the same MAC with the same Key. Hence it can become insecure.

To overcome this, there is a solution in AES_CMAC where there is no need to add a dummy block if the it is already block alligned to the PRF(in this case it is AES then 16 bytes alligned).

In AES CAMC there are three keys (K,K1 and K2). K1 and K2 are derived from K. For the subkeys (K1 and K2 ) generation, please see the section 2.3(Subkey Generation Algorithm) in the below link. https://tools.ietf.org/html/rfc4493

If the last block is not alligned (16 bytes in case AES PRF) then pad the last block as ISO padding . Encrypt it with AES and XOR the output with K1 . The tag is calculated on the XORed output with the same key K.

Please see the imagefor padded case in AES-CMAC

If the last block is alligned (16 bytes in case AES as PRF) then XOR the output of the block with the K2. The tag is calculated on the XORed output with the same key K.

Please see the image for the non padded case.

Note: referenced from Professor Don Boneh  .

I hope you mean drawback caused by AES CBC-MAC which is resolved in AES-CMAC.

AES_CBC MAC if used properly with ISO padding technique should not result into a tag collision.

So AES-CBC MAC should look something like this.

In AES-CBC MAC if the last block is not 16 byte aligned (considering AES as PRF) then padding must be done to the last block. Padding should be done based on ISO (bit padding, using binary one followed by zeros, e.g. $\texttt{100..00}$) For ISO 1 indicates the start of the padding. If the block is already 16 byte aligned then a dummy block (with ISO padding) should be concatenated . After this only the tag should be calculated.

Let's see the collision situation: last block say m is of 13 bytes. Hence as per ISO padding the block would become $m\|\texttt{100}$ and then tag will be calculated. What if there is a block called $m'$ which ends with $\mathtt{100}$ as the real data and if the dummy 16 byte block is not added then tag will be of same as with $m\|\mathtt{100}$. This means that a collision can be created.

As per security two different data should not result in the same MAC with the same Key. Hence it can become insecure.

To overcome this, there is a solution in AES-CMAC where there is no need to add a dummy block if the it is already block aligned to the PRF  (in this case it is AES then 16 bytes aligned).

In AES CMAC there are three keys ($K$,$K_1$ and $K_2$). $K_1$ and $K_2$ are derived from $K$. For the subkeys ($K_1$ and $K_2$ ) generation, please see section 2.3 (Subkey Generation Algorithm).

If the last block is not aligned (16 bytes in case AES PRF) then pad the last block as ISO padding . Encrypt it with AES and XOR the output with $K_1$ . The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for padded case in AES-CMAC

If the last block is aligned (16 bytes in case AES as PRF) then XOR the output of the block with the $K_2$. The tag is calculated on the XOR-ed output with the same key $K$.

Please see the image for the non padded case.

Note: referenced from Professor Dan Boneh.