Why are MACs not included when defining Protocols?

Question

I see often in literature related to cryptographic protocols that MACs (Message Authentication Codes) are not included in protocol definitions.

For example:

A -> S: {TA, B}KAS
S -> A: {TS, KAB, B}KAS
S -> B: {T'S, KAB, A}KBS

Shouldn't it be defined as follows ? (Encrypt-then-MAC + using second key for MACs)

A -> S: {TA, B}KAS, [{TA, B}KAS]KAS'
S -> A: {TS, KAB, B}KAS, [{TS, KAB, B}KAS]KAS'
S -> B: {T'S, KAB, A}KBS, [{T'S, KAB, A}KBS]KBS'

Isn't integrity a concern, or do protocol analysts generally assume that cipher-text cannot be modified at this level of protocol abstraction? Do you exclude ciphertext-only attacks?

Answer 1

It depends on the protocol. In general IND-CPA secure ciphers are assumed. That would mean that confidentiality is taken care of by the cipher.

If integrity and/or authenticity are also required then it should be made explicit in the protocol. In that case it is however perfectly possible to use one key, e.g. by using an authenticated cipher such as GCM.

If ciphertext only attacks are excluded depends on the context.

Answer 2

as far as I know, MAC's can vary depending on implementation and/or situation, like in SSL certs. So standartizing a MAC hardly can mess things up, so that's why they're not included