Difference Between AES CCM and AES CCM* (CCM-Star) used by 802.15.4

This is from 802.15.4 standard itself p.253:

With regard to security of the CCM* mode of operation, the CCM* mode coincides with the original CCM mode specification (ANSI X9.63-2001 [B1]) for messages that require authentication and, possibly, encryption, but also offers support for messages that require only encryption. Moreover, it can be used in implementation environments for which the use of variable-length authentication tags, rather than fixed-length authentication tags only, is beneficial. As with the CCM mode, the CCM* mode requires only one key. The CCM* specification differs from the CCM specification, as follows:

— The CCM* mode allows the length of the Authentication field M to be zero as well (the value M = 0 correspond-
ing to disabling authenticity because then the Authentication field is the empty string).
— The CCM* mode imposes a further restriction on the nonce N: it shall encode the potential values for M so that one can uniquely determine from N the actually used value of M.
As a result, if M is fixed and the value M = 0 is not allowed, then there are no additional restrictions on N, in which case the CCM* mode reduces to the CCM mode. In particular, the proof of the CCM mode applies (Jonsson [B13] and [B14]).
For fixed-length authentication tags, the CCM* mode is equally secure as the original CCM mode. For variable-length authentication tags, the CCM* mode completely avoids, by design, the vulnerabilities that do apply to the original CCM mode.
For fixed-length authentication tags, the security proof of the original CCM mode carries over to that of the CCM* mode (also for M = 0), by observing that the proof of the original CCM mode relies on the following properties, which slightly relax those stated in Jonsson [B13] and [B14] (relaxed property indicated in italics):
— The B0 field uniquely determines the value of the nonce N.
— The authentication transformation operates on input strings B0 || B1 || B2 || … || Bt from which one can uniquely
determine the input strings a and m (as well as the nonce N). In fact, for any two input strings corresponding to distinct triples (N, m, a), neither one is a prefix string of the other.
— All the Ai fields are distinct from the B0 fields that are actually used (over the lifetime of the key), as those have a Flags field with a nonzero encoding of M in the positions where all Ai fields have an all-zero encoding of the integer 0.
Hence, if M is fixed, then the CCM* mode offers the same security properties as the original CCM mode: confidentiality over the input string m and data authenticity over the input strings a and m, relative to the length of the authentication tag. Obviously, if M = 0, then no data authenticity is provided by the CCM* mode itself (but may be provided by an external mechanism).
For variable-length authentication tags, the original CCM mode is known to be vulnerable to specific attacks (see, e.g., Section 3.4 of Rogaway and Wagner [B17]). These attacks may arise with the original CCM mode because the decryption transformation does not depend on the length of the authentication tag itself. The CCM* mode avoids these attacks altogether, by requiring that one shall be able to uniquely determine the length of the applicable authentication tag from the Ai fields (i.e., from the counters blocks).
NOTE 2—With regard to the interoperability between CCM mode and CCM* mode of operation, the CCM* mode reduces to the CCM mode in all implementation environments where the length of the authentication tag is fixed and where the value M = 0 (encryption-only) is not allowed. In particular, the CCM* mode is compatible with the CCM mode, as specified in IEEE Std 802.11i™-2004 (for WLANs) [B7], IEEE Std 802.15.3™-2003 (for WPANs) [B10], and IEEE Std 802.15.4-2003 (for older WPANs).