MAC-then-encrypt in SIGMA protocol for authenticated key exchange

Question

The SIGMA protocol proposed in 2003 and used in TLS 1.3 and IKE stands for "SIGn-and-MAc" and can optionally protect identity using encryption.

The SIGMA-I variant illustrated below indicates that it uses a MAC-then-encrypt approach:

Here $\{\dots \}_{K} $ denotes encryption of the information between the brackets under a symmetric encryption function using key $K$.

Is there a particular reason to use MAC-then-encrypt rather than encrypt-then-MAC for key exchange protocols? I wasn't able to find a better answer than it seems arbitrary when looking at a comparison between MAC-then-encrypt and encrypt-then-MAC.

Edit: RFC 7366 linked in this related answer gives some hints that encrypt-then-MAC should be preferred (D)TLS communication (none is said about handshaking). In particular, it states:

TLS and DTLS use a MAC-then-encrypt construction that was regarded as secure at the time the original Secure Socket Layer (SSL) protocol was specified in the mid-1990s, but that is no longer regarded as secure.

Interestingly, H Krawczyk (the author of SIGMA) wrote in 2001 The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)—before SIGMA.

Answer 1

Arnaud asked me to clarify this issue.

It is true that one should use an authenticated encryption mode or encrypt-then-MAC, and the paper says that explicitly. Indeed, the explanatory text in the paper following the figure shown above (Section 5.2 of https://webee.technion.ac.il/~hugo/sigma-pdf.pdf) addresses this issue. It says:

We stress that the encryption function (as applied in the third message) must be resistant to active attacks and therefore must combine some form of integrity protection. Combined secrecy-integrity transforms such as those from [16] can be used, or a conventional mode of encryption (e.g. CBC) can be used with a MAC function computed on top of the ciphertext [3, 26].

Namely, the encryption denoted $\{...\}_{K_e}$ needs to use an authenticated encryption scheme. (The need for authenticated encryption is also repeated in Appendix B that shows a more complete protocol in the form of SIGMA-R).

The fact that there is a MAC (on the identity) under the encryption is just because the MAC is (an essential) part of the SIGMA protocol and is completely unrelated to encryption (in particular, needed even if you do not care about protecting identities). So while it looks like "MAC-then encrypt" it has no relation to this mode of encryption.

Note: The reason the text says that authenticated encryption is only needed for the third message is that, as said at the beginning of that same paragraph, SIGMA-I protects the identity of the initiator from active attackers and the identity of the responder from passive attackers. So encrypting the identity of the responder only needs security against passive attacks for which UNauthenticated encryption suffices. This is really an academic remark since in practice one would use the same encryption scheme for both flows, namely, authenticated encryption for both.

Answer 2

This is somewhat of a speculation, but I would assume that this is due to the modular way in which Sigma was designed. Namely, when Hugo Krawczyk designed Sigma, the main security property he was after was AKE security which basically consists of two things:

1. Session key indistinguishability: the adversary shouldn't be able to distinguish real session keys from random ones; and

2. Explicit entity authentication (EA): the property that once a protocol participant completes the protocol run, it is guaranteed that it was in fact communicating with the expected party, and that this party did indeed compute the same session key.

The EA property is basically a key confirmation step that assures liveness and authentication. This is achieved by calculating a MAC over some of the protocol data, using a key $K_m$ derived from the same master secret used to derive the session key.

The point is that you can achieve AKE security (that is, property 1 and 2) without any encryption at all! Indeed, when Krawczyk proves that Sigma satisfies AKE security (can't remember which paper this was; will try to find it later), he simply assumes that the encryption step is not there at all! (He also does this in his OPTLS paper, which is the precursor to TLSv1.3).

As I said, the standard security goal for most key exchange protocols have, since the original papers by Bellare and Rogaway, basically all been about AKE security. However, when Krawczyk designed Sigma he also wanted to add another, non-standard, feature, namely identity-protection. But given that he had already shown that the Sigma protocol without encryption achieved AKE security, it was a simple matter of adding encryption on top of this in order to also get identity-protection. Thus: MAC-then-Encrypt.

But notice that these two uses of MACing and encrypting are rather orthogonal and serve different purposes: the inner-MAC is supposed to provide EA security, while the outer encryption is supposed to provide identity-protection.

Also, note that Sigma typically does use Encrypt-then-MAC. In particular, in the instantiation of Sigma in IKEv2, the outer encryption is accompanied by an additional MAC outside of the encryption in standard EtM fashion. In IKEv2, the inner MAC key is called SK_p*, the outer encryption key is called SK_e* and the outer MAC key is called SK_a* (the * is either i or r depending on whether this message is created by the initiator or the responder). Moreover, in newer instantiations of IKEv2 the outer encryption is replaced by dedicated authenticated encryption algorithms. In this case the SK_a* keys are not used (and the whole EtM question becomes moot). In the TLSv1.3 instantiation of Sigma only authenticated encryption is used. But again, notice that inside the encryption (be it AE or EtM), there is an inner MAC whose purpose is to provide EA security.