It is quite easy to see that integrity, sender authorization, and confidentiality properties are preserved under the protocol. Integrity is implicit with the use of symmetric key cryptosystem as long as there are enough redundancies in the message in which the receiver can verify. Authorization of sender is guaranteed by Trent's access control list. Confidentiality is guaranteed by the Alice's secret key in step 1 and group key in step 2.
It is less obvious what sender authenticity means in this protocol. In step 1, Alice's message is authenticated by the secret key K.Alice shared between Alice and Trent. In step 2, the Trent's signature simply means ``the sender of this message is authenticated by me and is authorized to send you this message''. To provide conventional message authenticity, Alice can sign her message at step 1 and later Trent broadcasts the signature with the message. Alternatively, Trent can reveal Alice's identity with the protection of his digital signature in step 2. Note that there is a conflicting interests between authenticity and anonymity; our protocol preserves sender anonymity while maintaining some level of authenticity.
At the protocol level, Alice's anonymity is preserved as long as Trent does not explicitly leak out Alice's identity. Unfortunately there is a catch. Unlike encryption, anonymity is not end-to-end; Alice's identity may be leaked at every level of the protocol stack, such as IP unicast to Trent. The same argument holds true for receiver privacy. Although this protocol does not leak any privacy information about Bob, a potential eavesdropper Eve may listen to Bob's LAN traffic and learn that Bob belongs to the multicast group at the lower protocol layer (such as IP multicast and reliable multicast). We will discuss this further in section ???.