Authentication in Key-Exchange: Definitions, Relations and Composition

We present a systematic approach to define and study authentication notions in authenticated key-exchange protocols. We propose and use a flexible and expressive predicate-based definitional framework. Our definitions capture key and entity authentication, in both implicit and explicit variants, as well as key and entity confirmation, for authenticated key-exchange protocols. In particular, we capture critical notions in the authentication space such as key-compromise impersonation resistance and security against unknown key-share attacks. We first discuss these definitions within the Bellare-Rogaway model and then extend them to Canetti-Krawczyk-style models. We then show two useful applications of our framework. First, we look at the authentication guarantees of three representative protocols to draw several useful lessons for protocol design. The core technical contribution of this paper is then to formally establish that composition of secure implicitly authenticated key-exchange with subsequent confirmation protocols yields explicit authentication guarantees. Without a formal separation of implicit and explicit authentication from secrecy, a proof of this folklore result could not have been established.


Introduction
The commonly expected level of security for authenticated key-exchange (AKE) protocols comprises two aspects.Authentication provides guarantees on the identities of the parties involved in the protocol execution.Secrecy promises that the key is not known by active adversaries.The two together ensure that the key is only known by the "right" parties.
The apparent simplicity of these informal definitions hides a complex landscape as both secrecy and authentication come in many related but distinct flavours.Authentication can be one-way or mutual; it can refer directly to the entities involved in the protocol run (entity authentication) or indirectly to the identities of the parties that hold the keys (key authentication); it can be explicit (i.e.hold as soon as the protocol has finished) or implicit (i.e.refer to the moment when the key is actually used).In addition, AKE protocols are often expected to guarantee key-confirmation, where a party which derives a key is convinced that it has also been derived by another session, to ensure that only properly shared keys are used in communication.Each of the above properties may also come with different levels of strength due to the asymmetry in most two-party protocols. 4tarting with the seminal work of Bellare and Rogaway [BR94], research has made steady progress in formalizing and clarifying what some of these security notions signify.For example, the early definition proposed in [BR94] requires explicit entity authentication for all AKE protocols: when a session finishes its execution, there exists a unique session of the intended peer to which it is partnered. 5In particular, this definition is applicable to arbitrary two-party protocols (i.e. it does not require that parties derive keys).Subsequent work resulted in numerous extensions and variations including changes to the core partnering mechanism [BPR00,BR95,CK01,BFWW11,LS17] and extensions of the adversarial powers [CK01,LLM07,CF12].Over time, definitions have shifted to guarantees associated only with keys, separated from identities [Kra05,BSWW13], and formalized other aspects not considered by original definitions e.g.various forms of forward secrecy [Kra05,CF12] and key-confirmation properties [FGSW16].
All these developments were guided chiefly by protocol design ideas and intuitive understanding of the security guarantees and therefore happened outside of a complete framework of security notions.Despite some works which attempt to systematize and understand the relative merits of the different models [CBH05a, Ust09,Cre11], emphasis was on protocol design and more pressing aspects (e.g.privacy) rather than on a thorough evaluation of the different guarantees (including authentication).This lack of comprehensive study has led to missing definitions, unclear relations between properties, and the use of folklore results which lack formal support.Perhaps surprisingly, core security notions such as implicit authentication have influenced the design of large classes of protocols while not being formally defined.Similarly, large classes of attacks on authentication, such as unknown key-share or key-compromise impersonation, have led many individual protocols to attempt to avoid them, but no single security definition has been argued to properly defend against such attacks.Relationship of notions for implicit key and entity authentication (iKeyAuth and iEntAuth), explicit key and entity authentication (exKeyAuth and exEntAuth), key and entity confirmation (KeyConf and EntConf), Match security and key Secrecy.We note that key confirmation and explicit authentication definitions actually come in two flavours, full and almost-full, depending on which party receives the final protocol message.The implications hold accordingly for these sub versions.
Our definitions use a formalism inspired by the work of Rogaway and Stegers [RS09].Specifically, we use logical statements to express when a desirable property is satisfied by the overall state of the protocol execution; security then demands that this property is satisfied with overwhelming probability.A key benefit of the approach is that these precise guarantees are unambiguous, unlike the English prose often used to describe authentication properties in AKE [MvOV97], and can be assessed by parsing the logical formalism.
Not evident from Figure 1 is that we cover both one-way and mutual authentication settings using a new and flexible mechanism to unify both versions.Another aspect not illustrated in Figure 1 is that some of the notions come in two flavours: "full" which is the stronger guarantee, offered to the party which receives the last message, and "almost-full" which is offered to the party that sends the last message (and therefore does not know if this message is delivered).
In our work we made several important choices about the definitional framework.The first concerns the adversarial powers and goals.While the rigorous formalization of adversarial goals is one of our main contributions, we are aware that these need to be placed in (and often depend on) the context of the available adversarial powers.A variety of choices exists, especially when deciding which parties the adversary is allowed to corrupt, and we opt for a more conservative scenario.We extend the Bellare-Rogaway (BR) model [BR94] by selectively allowing the adversary to compromise any of the two parties that engage in an authenticated session.One implication of this choice is that our definitions fully cover advanced properties like key-compromise impersonation (KCI) resistance [BJM97] and security against unknown key-share (UKS) attacks [BWM99].We also fully allow the reveal of session keys as we consider that authentication should already hold upon derivation of the key.In a later section, we extend our definitions to the AKE models in the Canetti-Krawczyk style [CK01] which also include the reveal of ephemeral material.We show that our definitions naturally extend to this stronger adversarial model and that we can in fact separate out authentication from secrecy definitions in order to capture our stronger form of implicit authentication.
Another choice is how to capture matching sessions (sometimes called session partnering).Such sessions are deemed by the model to have communicated with one another and, among other implications, they are channel protocol.Such a composed protocol clearly does not guarantee key secrecy anymore and one thus needs to argue along the authentication property alone to justify this property.
expected to derive the same key.The notion of partnering is crucial for defining secrecy of keys (technically to restrict the powers of the adversary in a meaningful way) but also impacts authentication.When authentication is required, then sessions deemed as matching should agree on identities.In the literature, there are two prevalent mechanisms that capture this idea: matching conversations and session identifiers.In this paper we use session identifiers -some related to keys, some related to identities -and demand that they meet a refined definition of Match security which was first proposed in earlier work [BFWW11] as "partnering security." Such careful reflections about security notions and the logical formalism enable the intuitive understanding to be matched almost one-for-one in the security definitions, therefore guaranteeing that each stand-alone definition captures exactly what it is supposed to, something that could not be achieved with a single, secrecy-focused definition.

Relations.
A second benefit of our predicate-based definitions is that the use of logic simplifies and facilitates the study of relations between the different properties.It is immediate, for example, that implicit authentication is a consequence of explicit authentication.It is also easy to see that implicit key authentication together with key confirmation yield explicit key authentication.
The logical formulations also make it clear that although key authentication and entity authentication are obviously related, the relation is more subtle than appears at first.A clear separation is that the latter property is applicable to a larger class of protocols.Perhaps less clear is that for AKE protocols, entity authentication does not imply key authentication.Indeed, the authentication guarantee could come from protocol flows that are not involved in key generation; moreover, the key could be non-secret so authentication via keys would then be meaningless.However, we complete the study of relations between the different notions by showing formally that an equivalence holds for all protocols which satisfy Match security and for which the keys are private.Protocols.To illustrate the different levels of key authentication we briefly discuss how three well-known protocols fare with respect to the notions we put forth.Among other properties, we show that plain Diffie-Hellman formally provides authentication only when no party is required to authenticate themselves.Of course, this case does not imply any meaningful guarantees.
More interestingly, we test our formulation of implicit authentication in the case of the HMQV protocol [Kra05].Due to the prudent choices in our definitions, we find that we cannot use the original proof of secrecy in a black-box fashion since it holds for different adversarial powers.This indicates that existing security definitions for IAKE protocols do not straightforwardly provide the strongest implicit guarantees.Finally, we show that the much heavier TLS 1.3 protocol satisfies the strongest guarantee: explicit key authentication.Following our analysis, we derive some rules of thumb which can inform the design of protocols for AKE protocols.These analyses with our stand-alone definitions also allow us to hone in on the assumptions that are necessary for authentication which turn out to be significantly weaker than those required for secrecy.
Composition result.As explained above, a protocol with implicit key authentication and key confirmation also satisfies explicit key authentication.This result can be used to prove the folklore (composition) result that the use of the key obtained from an implicitly authenticated protocol yields stronger authentication guarantees.Of course, the use of the key has to be meaningful, in the sense that only a party who possesses the key can successfully engage in the task.One can then regard the use of the key as a means to "strengthen" the key-exchange protocol to also provide key confirmation.
We formalize this idea as follows.We define the class of key-confirming protocols which, in addition to their basic functionality, provide a key confirmation guarantee upon a "successful" use of a key.Such protocols can be as simple as sending a MAC on some fixed message 7 , or more complex.For example, we argue that an authenticated channel also offers key-confirming guarantees.We then prove that running an implicitly authenticated key-exchange protocol followed by a key-confirming protocol results in an explicitly authenticated key-exchange protocol.The desired result follows by observing that the composition is still an implicitly authenticated protocol in addition to providing key confirmation.

Game-based security for AKE protocols
We use the framework of Brzuska et al. [BFWW11] for cryptographic games and describe its formulation of the BR model [BR94] for AKE protocols.We augment it to provide a flexible authentication framework and to capture key-confirmation as formalised by Fischlin et al. [FGSW16].
In the security game, the adversary interacts with parties executing the protocol via queries; these capture its capabilities in a real-world execution.The adversary's aim is to trigger an event defined as "bad" by the game whilst abiding by the game's limitations on queries.We use λ to denote the security parameter, let 1 λ be its unary representation and let negl(λ) denote an arbitrary negligible function.We denote by {0, 1} * the set of all finite-length bit-strings.
Identities.We let n i be the number of parties modelled by the game.Each party has a unique identity i and we denote by I = {i} the identity set of size n i .
To separate identities who are expected to authenticate we specify a subset S ⊆ I; this is our first augmentation.This models real-world servers who have to convince clients of their identity by means of a certificate.These clients, modelled by the identities in I \ S, do not have such secret information.This modelling flexibly captures varying forms of authentication; a secure protocol for which S = I provides mutual authentication for all sessions, whereas one for which S = ∅ provides no authentication whatsoever; for S a non-empty proper subset of I, it provides one-way authentication from identities in S. We leave the specification of S within I as a design choice for protocols.
We assume that each party is aware of its own identity in an execution.We sometimes use id A and id B to distinguish between the identities of two parties A and B in an execution.We work in the pre-specified peer model [MU08] where each session knows its intended partner's identity from the start.We can restrict to the case that only identities of authenticating partners are known, e.g. if a client remains anonymous in a TLS connection.

Protocols and sessions.
A protocol is a pair of algorithms π = (kg, ζ) where kg(1 λ ) is a randomized key generation algorithm and where ζ is the algorithm executed locally by parties engaging in the protocol.Local sessions are identified by a local session identifier ∈ I × I × Z where = (i, j, k) refers to the k-th session of identity i with intended peer j.We use .idand .pid to refer to i and j respectively.We let n s be the maximum value of k for any in a game.
We use the notion of session identifiers as was originally proposed by [BPR00] to "partner" two sessions as having engaged in the same execution.These are computed by the protocol itself, different from the local session identifier which is an artefact of the model.For simplicity we maintain the original approach of considering these session identifiers to be revealed upon acceptance.

Common game states
Security games maintain states to keep track of the execution of the protocol.This consists of five elements: a list LSID of valid local session identifiers, a list SST of protocol-related session states, a list LST of gamerelated local session states, a game execution state EST which contains global protocol-related information, and a model state MST which contains global game-related information, relevant to the security notion (e.g. a hidden bit) Our authentication games share the same execution, game and local states.Here we describe and augment the states from [BFWW11].
Game execution state.As in [BFWW11], the execution state EST contains a list L keys = {(i, pk i , sk i , δ i )} i∈I where δ i ∈ {honest, corrupt} denotes whether sk i has been corrupted.Session state.The state of the local session with identifier = (i, j, k) is composed of the following: -(pk i , sk i ), the long-term key pair of identity i, the "owner" of the session.This is initialised to .id'skey pair if i ∈ S or set to ⊥ if i ∈ I \ S. One may think of the public keys as certified, in which case the party also holds a certificate cert i for pk i under its identity, but we omit details here.-pk j , the long-term public key of identity j, the intended peer of the session.This is initialised to .pid'spublic key if j ∈ S or set to ⊥ if j ∈ I \ S. -crypt ∈ {0, 1} * is some protocol-specific private session state used to maintain secret values from one invocation to the next.-accept ∈ {true, false, ⊥} indicates whether the party has accepted or rejected the session as an succesful execution of π.Initially set to ⊥, to signify running, accept may change to either true or false only upon termination.We assume the value of accept is public.-sid ∈ {0, 1} * ∪{⊥}, the session identifier as specified by the protocol.Initially set to ⊥, it may be changed once to a non-trivial value.If the sid is different from ⊥, then accept must be set to true, and vice versa, if accept is set to true, then sid must become different from ⊥.We assume that the value of sid is made public when accept is set to true.
key ∈ {0, 1} * ∪ {⊥} is the (session-)key locally derived during the execution.Initially set to ⊥, it may be changed once to a non-trivial value.If the key is different from ⊥, then accept must be set to true, and vice versa, if accept is set to true then, key must become different from ⊥.We note that this implies that sessions must terminate with the same call to the protocol as that which sets the key and the sid, they cannot continue once the key is set.-kconf ∈ {full, almost, no, ⊥} indicates the form of key confirmation that the owner expects to receive.This addition to the model captures the fact that one partner of a run always terminates first and therefore may not expect a full confirmation of the final session-key.The value of kconf is initialised to ⊥ and set when the session is first activated.-kcid ∈ {0, 1} * ∪ {⊥} is a key-confirmation identifier, indicating sessions which will eventually derive the same key.Initially set to ⊥, it may be changed once to a non-trivial value and may not be changed again.
If key is different from ⊥, then kcid must be different from ⊥.We write SST[ ] = ((pk i , sk i ), pk j , crypt, accept, sid, key, kconf, kcid) to denote the session state of .We use the notation .sidor .key to refer to individual elements and use similar notation for the game, local session or model states.
This session state augments that of [BFWW11] with kconf and kcid from [FGSW16] along with some renaming.These are used to to modularly capture the formal definition of key confirmation of [FGSW16], similarly to our addition of S to capture different authentication directions.We refer to [BFWW11, Section 3] for a discussion on public session identifiers.

Local session state. The local session state consists of:
δ ownr ∈ {honest, corrupt}: denotes whether the owner of the session was corrupted before the session was completed (i.e. while .accept= ⊥).δ peer ∈ {honest, corrupt}: denotes whether the intended peer of the session was corrupted before the session was completed.δ sess ∈ {fresh, revealed}: denotes whether the session-key for this session has been revealed to the adversary.As in [BFWW11], keeping track of δ ownr separately from δ i allows sessions that terminated before their owner was corrupted to remain honest; this enables the modelling of forward secrecy.We write LST[ ] = (δ ownr , δ peer , δ sess ) for the local session state of session and use the notation .δsess to refer to individual elements.
-(LST, MST) ← setupG(LSID, SST, EST, 1 λ ): for game-relevant components.Our setupE is similar to that of [BFWW11] but it only generates long-term keys for the identities in S and initialises the new elements of the session state.

Session partnering.
We define the partnering predicate using session identifiers.
Definition 2.1 (Partners).We say that two sessions and are partners if the predicate Partner( , ) holds true, where Partner( , ) ⇐⇒ ( = ) ∧ ( .sid= .sid= ⊥) .Thus, to be partners, two sessions need to be administratively different and to both have set a non-trivial sid.This does not exclude the possibility that they belong to the same identity, i.e. that .id= .id.
For correctness, we require that two sessions executing π without adversarial interaction derive identical sids upon accepting and are therefore partnered.We also require that two such sessions derive identical keys and kcids.
Wile this definition of partnering appears similar to that of "matching" sessions in CK-like models [CK01,Kra05,LLM07], it differs it two important aspects.The first is that it does not involve the sessions' identities, thus separating out authentication notions.The second is that our sids are derived by the protocol itself rather than arbitrarily set by a higher layer.We note that our notion of sids superseeds that of matching conversations used for partnering in [Kra05,LLM07].

Adversarial interaction and common queries
The adversary A is a probabilistic polynomial-time (PPT) algorithm that interacts with a game through queries specified by a set Q. Upon receiving a query q ∈ Q, the game has a behaviour algorithm χ which takes q together with the state to return a response to A.
Not every query is always valid; this is captured by the Valid predicate which the game evaluates each time a query q is received.Based on q and on the current state, Valid returns either true or false which determines if χ is executed on q.
In addition to the common states, our security games for authentication notions also share a query set Q. We specify here the Send, Reveal and Corrupt queries following the work of Brzuska et al. but, as we model KCI resistance, we modify the Valid predicate.
The Send query.Whatever the game, Q always includes the Send query.It takes an identifier ∈ LSID and a message m ∈ {0, 1} * as inputs and is processed by χ by running π on SST[ ] with input m.This updates SST and returns a response m which is given to A together with accept and also sid if m triggered the termination of the session.This gives control of the network to A and allows it to forward, alter, delay, create or delete messages.
The Reveal query.When A submits Reveal( ), this sets .δkey ← revealed and returns .key .
The Corrupt query.We formalise the Corrupt(i) query as follows.First, the value of δ i in L keys is set to corrupt.Then, for any session of the format (i, * , * ) for which accept = ⊥, we set δ ownr ← corrupt; for any session of the format ( * , i, * ) which is still running, we set δ peer = corrupt.Finally, sk i is returned to A.
The Valid predicate.A significant difference to [BFWW11] is that our Valid predicate allows for the adversary to submit a Send query to a session whose owner has already been corrupted.This is crucial to model KCI resistance as this notion guarantees a security property to sessions whose owner was corrupted before they terminated.Furthermore, the Valid predicate returns false if a Reveal query is made to a session whose key = ⊥.

Winning condition and formal game definition
A game considers that A has won a security game, i.e. broken a security property of π, if it succeeds in triggering a "bad" event.This event is defined by a predicate P which is a logical statement evaluated on the state.We denote this by b ← P(LSID, SST, LST, EST, MST), where b ∈ {0, 1}, and b = 1 signifies that A has successfully triggered the "bad" event.We therefore define a generic security experiment as follows.
Definition 2.2.A game G maintains a state (LSID, SST, LST, EST, MST) and is defined by the tuple (setupE, setupG, Q, Valid An experiment is parameterised by a protocol π, an adversary A and a game G; it is executed as follows. 1.The experiment runs (SST, EST) ← setupE(LSID, kg, 1 λ ) and (LST, MST) ← setupG(LSID, SST, EST, 1 λ ). 2. The adversary submits queries from Q to the game which processes them with Valid and χ.We note that our definition of a game G includes more than [BFWW11, Definition 1], namely Q and P , as these also uniquely characterise it.We denote the experiment by Exp G A,π (1 λ ) and we write Exp G A,π (1 λ ) = b.

Match security
Before authentication or secrecy, a "good" AKE protocol should first provide certain correctness and soundness guarantees.A Match-secure AKE protocol should ensure that: 1. Partner sessions derive the same key and kcid (properties 1 and 2 below); 2. at most two sessions derive the same sid (property 3); 3. sessions with the same kcid accept with the same key (property 4).This guarantees that A is unable to create disagreements between partnered sessions.Formally, we define the following predicate.
We then define the Match security game G Match in the sense of Definition 2.2 where π is an AKE protocol, the state, and the setupE algorithm are as in Section 2.1, the query set Q = {Send, Reveal, Corrupt} and the behaviour χ are as in Section 2.3, the setupG algorithm sets the LST of each session to (honest, honest, fresh) and the predicate P = Match.The advantage of an adversary A against the game G Match with identity sets I, S is written as Definition 2.4 (Match security).An AKE protocol π is Match-secure for identity sets I, S if, for all PPT adversaries A, Adv G Match A,π,I,S (1 λ ) = negl(λ).
Comparison to previous definitions.Considered in the context of the BR model, our definition of Match security refines that of [BFWW11] in two ways.We first incorporate the conditions of the KCIDbind predicate of [FGSW16] as conditions (2) and (4).As this work builds a unified model of AKE protocols with both authentication and key confirmation, it is reasonable to add this predicate to the definition of Match since it concerns notions of correctness and soundness, as the previous definition already did for keys.
Secondly, we remove the requirement that partnered sessions should agree on each other's identities.This condition implied that Match-secure AKE protocols already provided some form of authentication, albeit very weak.This mixed an authentication with design and soundness and we therefore remove it.We present separate definitions for authentication in the next section.
In the context of the CK-style models, as summarised in [Cre11], the usual first requirement of security is for matching sessions of uncorrupted identities to derive equal keys.We note that our notion of Match security would capture and extend this requirement if a StateReveal query were added to its game.We note that we do not restrict to uncorrupted identities, as we do not consider that the adversary takes control of sessions managed by the game; thus our Match predicate is only evaluated for honestly-behaving sessions.

Key authentication and confirmation
We present here our new predicate-based definitions for key authentication notions.We define three distinct flavours of authentication: implicit, confirmation and explicit.For each, we first discuss the intuitive understanding that motivates our definition and then give a formal statement.We then show that our definitions are consistent and that a protocol that combines implicit key authentication and key confirmation also provides explicit key authentication.

Implicit authentication
We take implicit to mean: "should there be a session that possesses the same key as session , then the owner of session must be the identity designated as the peer of session ."This does not guarantee the secrecy of the key, nor whether such a session exists.Equivalently, this means that any session whose owner is not designated by the peer of is incapable of deriving the same session-key.(Recall that the term "session" refers to sessions executed by the model and that this does not forbid the adversary from deriving the key itself.) This informal notion of implicit authentication raises the question whether to only consider sessions which interact with an honest peer, or to also allow those with a corrupted peer.The impact of this distinction was first observed by Diffie et al. [DvOW92].In their design of the station-to-station (STS) protocol they aimed to prevent an attack in which one can make an honest B believe it is sharing a key with a malicious E, whereas the actual other honest key holder A intends to communicate with B. This has later become known as an unknown key-share (UKS) attack [BWM99] which, ironically, was shown to apply to the STS protocol in the same work [BWM99].
For our formal definition, the question is then either to restrict the adversary's valid targets to the sessions that were executed with an honest peer, or to allow all sessions, even those that accepted with a corrupted peer, as valid targets.The first choice would comply with the idea stated in [BWM99]: "By definition, the provision of implicit key authentication is only considered in the case where B engages in the protocol with an honest entity (which E isn't)."The second choice, would instead lead to a definition where UKS attack scenarios even with dishonest peers are accounted for.Such a scenario would include a corrupt server causing a client to exchange a key with another, unintended, server.It is clear that this yields a stronger security guarantee and we therefore choose the second formulation in our definitions.
We stress that our model also captures key-compromise impersonation resistance [BJM97]-where the adversary knows the long-term key of a party A and tries to impersonate another party to A-since our formalization also allows the owner of target sessions to be corrupted.Definition 3.1 (Implicit key authentication).The iKeyAuth predicate evaluates to 1 if and only if where .acceptholds true if and only if .accept= true.We then say that the AKE protocol π with identity sets I, S provides implicit key authentication if, for all PPT adversaries A, where G iKeyAuth is the same as G Match with P = iKeyAuth.
Note that the predicate only applies to sessions that expect authentication, which is captured by the condition that .pid∈ S.This models the fact that one can only provide authentication to keys if one possesses authenticating information.An artefact of this is that protocols without authentication (i.e. with S = ∅) strictly speaking provide implicit key authentication as there is no authenticating party which the adversary can attack.Mathematically, this corresponds to a quantification over the empty set.
On the other end of the spectrum, we see that the case where S = I rejoins mutual authentication where, upon completion, session has authenticated to session and vice-versa.Indeed, if .id∈ S and also .pid ∈ S, then it is expected to authenticate itself to its intended peer in the same way that it expects to receive authentication.Upon both sessions completing, the predicate therefore induces a symmetry in the authentication guarantees.
As explained in the introduction, our basic definition considers the strongest adversarial model.We remark that we could relax the above requirement and only consider sessions with an honest peer, i.e. with .δpeer = honest.Indeed, this notion sometimes appears in the literature: it still provides guarantees for parties who engage in sessions of the protocol with an honest peer as intended partner.Clearly, the notion neglects executions in which the intended peer is dishonest in which case one could be vulnerable to certain UKS attacks.

Key confirmation
Intuitively, this second notion is "the guarantee that another session possesses the same key."While this does not provide authentication in the sense of binding an identity to a key, we define it here because its existential guarantee is a link between implicit and explicit authentication.
Here, we note that key confirmation only makes sense for honest peers because an adversary impersonating an honest party can always compute the key and provide confirmation to the target session.To prevent this trivial attack, we introduce a freshness condition on the peer.Definition 3.2 (Authentication freshness).For any ∈ LSID, the predicate aFresh( ) evaluates to true if and only if .δ peer = honest.
We note that this freshness notion does not prohibit Reveal queries; this is because key authentication properties are expected to hold upon derivation of the key, and knowledge of the key should not benefit the adversary in breaking these.Furthermore, we show that the Reveal query is not useful for the adversary to wrongfully provide confirmation.Either another session derives the same key and the adversary reveals it, but then another session with the same key does exist, and therefore confirmation holds even though it does with the adversary's intervention; or the adversary reveals the target session itself.However, the second option is not possible, since, in our model, setting the key to a non-trivial value is synonymous with accepting and terminating.Therefore the adversary cannot submit a Reveal query before the session has already accepted, at which point the adversary has already won if the session does not share a key with any other.Hence our freshness predicate does not need to eliminate trivial attacks using the Reveal query.
Fischlin et al. [FGSW16] introduced the distinction between full and almost-full key confirmation which captures the differences in guarantees that the last sender and last receiver in an AKE session can expect.We present here their predicate-based definitions and refer to [FGSW16] for a discussion.The former one says if an "authentication fresh" session with full key confirmation accepts, then there must be at least one other session also holding the key.Definition 3.3 (Full key confirmation).The fKeyConf predicate evaluates to 1 if and only if ∀ ∈ LSID, (aFresh( ) ∧ .kconf= full ∧ .pid∈ S ∧ .accept)=⇒ ∃ ∈ LSID :: Samekey( , ).
We then say that the AKE protocol π with identity sets I, S provides full key confirmation if, for all PPT adversaries A, Adv where G fKeyConf is defined similarly to G iKeyAuth .
We see that the session's expected level of key confirmation, which is set when the session is first activated, is captured with the condition that .kconf= full -for a given protocol π, a session can decide which key confirmation to expect if it is activated as an initiator or a responder.Also, the session in question is excluded from the existence condition by the Samekey predicate and therefore a session cannot confirm its own key.We note that fKeyConf is only tested against sessions that expect authentication, with .pid∈ S, as is discussed in [FGSW16, Section III.D].Whilst this condition is not strictly required in the predicate for our result in Section 3.4, we adopt it here to align ourselves on the stand-alone definition of key confirmation.As pointed out by Fischlin et al. [FGSW16], almost-full key confirmation is delicate to define.We adopt their notion saying that if such a fresh session accepts, then there must be a another session holding the same key-confirmation identifier and, moreover, if that other session has already derived a key, then it is the same one as the original session.
Definition 3.4 (Almost-full key confirmation).The afKeyConf predicate is defined as We then say that the AKE protocol π with identity sets I, S provides almost-full key confirmation if, for all PPT adversaries A, Adv where G afKeyConf is defined similarly to G iKeyAuth .

Explicit authentication
This third notion is much stronger than the first.Indeed, we take explicit to mean that authentication is obtained at termination, and therefore it does not rely on the potential use of the key at a later time.In other words, session , upon accepting, knows that there is another session which has the same key and whose identity is bound to it.Intuitively, it is a combination of implicit authentication and key confirmation, and indeed it was informally defined as such in Menezes, van Oorschot and Vanstone's Handbook of Applied Cryptography [MvOV97]; this appears in the logic of the predicates below.
Similarly to key confirmation, the existence of a session which has already derived the same key cannot always be guaranteed due to the asymmetry of the final message.We therefore define the two analogous notions of full and almost-full explicit key authentication.
As before, we study the requirements of a freshness predicate.As in the case of implicit authentication we do not stipulate that the peer is honest for the target session when it comes to the condition that any partner holding the same key is correctly identified (∀ ∈ LSID, Samekey( , ) =⇒ .id= .pid).This again provides safety against all possible UKS attacks.Only for the "liveness" condition (i.e. that there exists a party with the same key) do we require that the intended peer is honest (aFresh( ) =⇒ ∃ ∈ LSID :: Samekey( , )), otherwise the session may have communicated with an impersonating adversary which could trivially compute the key.Similarly to key confirmation, the Reveal query would not enable the adversary to conduct trivial attacks; this implies that the aFresh predicate is also the correct one here.
In summary, full explicit key authentication demands that for any fresh accepting session, any other session deriving the same key has the correct identity and there exists at least one other session holding the same key, if the peer is honest.We then say that the AKE protocol π with identity sets I, S provides full explicit key authentication if, for all PPT adversaries A, where G fexKeyAuth is defined similarly to G iKeyAuth .
We see that a session's expectation of both authentication and confirmation appears as .pid∈ S and .kconf= full in the predicate.Definition 3.6 (Almost-full explicit key authentication).The predicate afexKeyAuth evaluates to 1 if and only if We then say that the AKE protocol π with identity sets I, S provides almost-full explicit key authentication if, for all PPT adversaries A, where G afexKeyAuth is defined similarly to G iKeyAuth .

Equivalence results
We formally prove the coherence of the authentication definitions presented above.Namely, we show that a protocol which satisfies both implicit key authentication and key confirmation also satisfies explicit key authentication, and we show that the converse holds.
Theorem 3.1.Let π be an AKE protocol.Then it holds for π that iKeyAuth ∧ fKeyConf ⇐⇒ fexKeyAuth, (5) iKeyAuth ∧ afKeyConf ⇐⇒ afexKeyAuth. (6) Proof.We first focus on equation (5) and show that iKeyAuth ∧ fKeyConf =⇒ fexKeyAuth; we proceed by proving the contrapositive.Let A be a successful adversary against the fexKeyAuth predicate; i.e.A reaches an execution state where ¬fexKeyAuth holds true.This is equivalent to Thus if ¬fexKeyAuth holds true, either the first expression of the or clause holds, which implies ¬iKeyAuth, or the second one holds and implies ¬fKeyConf.We therefore obtain that which completes the first part of the proof.We now show that fexKeyAuth =⇒ iKeyAuth ∧ fKeyConf.We first show that fexKeyAuth =⇒ iKeyAuth.Let A be a successful adversary against the iKeyAuth predicate; i.e.A reaches an execution state where ¬iKeyAuth holds true which is equivalent to ∃ * :: * .pid∈ S ∧ ( * .kconf= full) ∧ * .accept∧ ∃ :: Samekey( * , ) ∧ ( .id= * .pid). (9) Note that we include * .kconf= full in ¬iKeyAuth as we only aim to prove that fexKeyAuth implies iKeyAuth for sessions that expect full explicit key authentication.We now assume, for contradiction, that fexKeyAuth holds; this implies ∀ , (Samekey( , * ) =⇒ .id= .pid)∧ (aFresh( * ) =⇒ ∃ :: for * as in (9).We see that the existence of that holds from (9) contradicts the first condition of (10) which shows that fexKeyAuth =⇒ iKeyAuth as expected from the formulation of the predicates.We now show that fexKeyAuth =⇒ fKeyConf.Let A be a successful adversary against the fKeyConf predicate; i.e.A reaches an execution state where ¬fKeyConf holds true.This is equivalent to This * is now exactly one that satisfies ¬fexKeyAuth and hence we immediately have that fexKeyAuth =⇒ fKeyConf.Since we have that fexKeyAuth implies both iKeyAuth and fKeyConf, combined with (8) this concludes the proof that iKeyAuth ∧ fKeyConf ⇐⇒ fexKeyAuth.
The proof of the same equivalence for almost-full confirmation notions, equation (6), follows from a similar argument.

Protocol examples
In this section we present established protocols and study which of our notions they achieve.We omit the secrecy proofs and sketch the proof for Match security to focus on the other properties.Our results confirm that a "rule of thumb" for protocol design to achieve implicit key authentication is to include the parties' identities in the key derivation step, key = KDF(K, (id A , id B , . . .)).If the key derivation function is collision-resistant then different identities immediately imply different session keys.Indeed this strategy has already been applied in very early protocols proposals, such as [BPR00], and has even been sometimes used to fix insecure protocols, e.g., [CBH05b].We note that this method is also used in the TLS 1.3 protocol.
From the analysis of key confirmation in TLS 1.3 of [FGSW16], we see that a good strategy to obtain full or almost-full key confirmation is to send a MAC computed over a known value (such as the transcript) with a key derived from the same material as the final session key.

Plain Diffie-Hellmann
We begin with the plain Diffie-Hellmann (DH) protocol, presented in Figure 2, in which the parties exchange g x and g y to derive a key from g xy and the communication transcript.One may also use the identities in the key derivation.The exchanged elements live in a cyclic group G of prime order |G| = q with generator g such that g = G.We assume that this group is known to all parties.Since this is an unauthenticated protocol, we have S = ∅.
Fig. 2. The plain Diffie-Hellman protocol with identifiers sid = kcid = (idA, X, idB, Y ).Note that both parties know the identities idA and idB in advance.The notation [idA, idB] means that the identities are optional.
Match security.The plain DH protocol provides Match security.Indeed both the session and key-confirmation identifiers fully determine the key (Properties 1 and 2).Furthermore, since the key-confirmation and session identifiers are identical, equal key-confirmation identifiers imply identical keys (Property 4).Finally, an honest party will contribute a random Diffie-Hellman share, such that the probability of matching any other share, is at most n 2 s • 1 q for a total number of n s sessions, and thus negligible (Property 3).
Implicit key authentication.The plain DH protocol trivially provides implicit key authentication, as S = ∅.We note that setting S = ∅ would allow an adversary to break implicit key authentication as it could create a mismatch in the expected peer identities for any two sessions.However, by including the identities in the key derivation function (as shown in Figure 2) this protocol can provide implicit key authentication even in the setting where S = ∅.Indeed, the adversary has no control over a session's owner identity .idwhich implies that if .pid= .idthen .key= .keyonly if there is a collision in the KDF.In the random oracle model, or assuming a collision-resistant KDF, this happens only with negligible propability.
Key confirmation and explicit key authentication.As expected, this protocol does not provide key confirmation since no information about the key is exchanged after it is derived.We can show this formally by taking an adversary which initiates a session with an honest party (either client or server) without initiating a matching partner session.It then creates the message g x or g y to complete the exchange with the honest party.Obviously, there is then no other session which holds the same key nor the same key-confirmation identifier.
As the protocol does not provide key confirmation, Theorem 3.1 implies that it cannot provide explicit key authentication either.Intuitively this is clear since no authentication takes place and the adversary can substitute any value.

HMQV
We next come to one of the most prominent candidates for implicitly authenticated key exchange, the HMQV protocol [Kra05].The idea here is to run a DH key exchange and to mix Schnorr-type signatures under the parties' public keys in the key derivation.These signatures are not sent but only used locally, thus "implicitly" authenticating the key.
The protocol works over a group g = G and uses a hash function H to compute the Schnorr signature.It is mutually authenticating, i.e. S = I, for which both parties use a long-term key.We assume that each party holds a certificate cert i for its public key pk i , and that the certificate is verified upon receiving it.We also assume that the public key and the owner's identity can be recovered from the certificate.We set sid = kcid = (cert A , X, cert B , Y ).Since key derivation in HMQV is also determined by the transcript and the hash function, Match security follows as in the plain DH case.
Implicit key authentication.We provide a proof that the HMQV protocol achieves our strong notion of implicit key authentication and is therefore secure against all possible UKS and KCI attacks.Recall that we need to show that ∀ ∈ LSID, ( .pid∈ S ∧ .accept)=⇒ ∀ = ∈ LSID, (Samekey( , ) =⇒ .id= .pid) .
Due to the differences in the corruption queries that the adversary is allowed to make, the proof of secrecy for HMQV in [Kra05] is not immediately sufficient to imply our strong notion.Indeed, this proof holds only when the test-session in the secrecy experiment is fresh in the sense of secrecy freshness (see Section 5).An attack on implicit key authentication which would require the corruption of the owner before the session took place would therefore not be considered as valid against key secrecy and would not be ruled out by the proof of [Kra05].
Proposition 4.1.The HMQV protocol provides unconditional mutual implicit key authentication, with Adv where h is the number of queries made to H, modelled as a random oracle.
Proof.To break the iKeyAuth predicate, it must be that a session A = (A, B, * ) shares a key with a session The later implies a collision in the KDF and we assume that this happens only with negligible probability.The only freedom that A then has is to modify the Y value sent to A as a response to its first message.Since the value of K C , x, d and a are already fixed, A must choose a value of Y such that Y B e , where e = H(Y, cert A ) is exactly the right value such that K A = K C .Modelling H as a random oracle ensures that each value of Y yields a new random value of e and therefore that there is a probability of 1/q that a given value of Y will yield the correct value of Y B e .Given that there are at n 2 i • n s /2 pairs of sessions, it holds that the adversary has at most a n 2 i • n s • h/2q probability of finding a suitable Y for which the equality holds.
Similarly to the plain DH protocol, setting key = KDF(K, (id A , id B )) immediately provides implicit key authentication if the KDF is collision resistant.
Key confirmation and explicit key authentication.HMQV does not provide key confirmation in the same way that the plain DH does not.It immediately follows that the protocol does not provide explicit key authentication either.

TLS 1.3
We give a simplified version of the DH mode of the TLS 1.3 protocol suite in Figure 4 on page 16.Namely, we omit intermediate keys, in particular the handshake key and the encryption of the handshake protocol.We also look at server-only authentication, disallowing client authentication or anonymous executions.Match security and implicit key authentication.TLS 1.3 is Match-secure; the argument is identical to the plain DH case and appears in [DFGS15].Implicit key authentication follows as for the identifier-including HMQV variant, if we assume that the KDF function is collision-resistant: since the server authenticates and cert B appears in the key derivation, equal keys imply a correct authentication.Similarly to the HMQV protocol, the key secrecy of TLS would not suffice to imply implicit key authentication.
Key confirmation and explicit key authentication.Key confirmation for TLS 1.3 (draft-10) was shown in [FGSW16] and our simplified version corresponds to the analysed variant.The idea of the proof is that the parties use the key in the handshake protocol within the MAC.The property holds for full and almost-full key confirmation, such that our version also provides explicit key authentication.

Key Secrecy
In this section we define key secrecy in the BR-style via a security game and cast the main implication in terms of a logical formula.

BR-Style Key Secrecy
We recall the definition of secrecy for AKE protocols from [BFWW11].Here the adversary is challenged, for a session of its choice, to distinguish between the honestly generated key or a randomly sampled one.The Valid predicate requires that the Test query is made only once and to a session which has derived a key, and that only one Guess query is made.The adversary may therefore chose to submit queries that will trivially allow him to win the BR-secrecy game.
To catch this, if A tests a session with .δownr = corrupt or with .δpeer = corrupt, the sFresh predicate returns false.It also does so if the session, or any of its partners, has been revealed.We also take care of sessions which do not expect authentication as A may impersonate the unauthenticated party and learn the session key.Hence, sFresh also returns false if the intended partner .pidbelongs to the set I \ S of unauthenticated parties.However, there is one exception: if there exists an honest session which is partnered to test , even if it does not belong to the intended partner, then the session took place between two honest session and the key is still expected to remain secret.We could further relax the requirement for sessions with unauthenticated parties by defining almostpartnered sessions and allowing these to be tested.This would be the least strict requirement but we refrain from introducing antoher identifier and instead keep the simpler definition with partnering.Definition 5.2 (BR-secrecy).The BRSec predicate is defined differently from the authentication ones due to its distinguishing nature.Instead of returning 0 or 1 to signify whether a certain condition holds, the BRSec predicates evaluates to MST.b guess if and only if MST. test = ⊥ ∧ sFresh(MST.test ) and evaluates to ⊥ otherwise.We also denote by G btest BRSec,D the secrecy game with a specific value for b test .We then say that the AKE protocol π with identity sets I, S is BR-secret w.r.t.output key distribution D if, for all PPT adversaries A,

Key-Match Soundness
We now define the KMSoundness property which captures the essence of secrecy as a predicate over the core key-exchange mechanisms, without Test and Guess queries.It says that for any authentication fresh and accepting session , there does not exist another session which holds the same key but is not partnered with .
We then say that the AKE protocol π with identity sets I, S provides key-match soundness if, for all PPT adversaries A, where G KMSoundness is defined similarly to G iKeyAuth .
The next theorem establishes that an adversary who can contradict Key-Match soundness must break either BR-secrecy or Match-security.
Theorem 5.1.Let π be an AKE protocol with Match security and BR secrecy w.r.t.D. Then it also provides key-match soundness.More precisely, for any PPT algorithm A attacking KMSoundness in at most n sessions, it holds that for some PPT algorithms B 1 , B 2 and the output length |key| of keys.
Proof.The first observation is that Match security implies that any partnered session to either or to must hold the same key as the corresponding session.If this would not hold with overwhelming probability, we could build an algorithm B 1 to refute Match security in a straightforward way.This enables us to assume that there are two sessions 0 and 0 with the above property and which accept first.That is, 0 and 0 hold identical keys, Samekey( 0 , 0 ), are not partnered, ¬Partner( 0 , 0 ), and for neither of the two sessions, in the moment when the session accepts, there is another session which is yet partnered with the session.
Note that 0 must have accepted by assumption, such that 0 .key= ⊥, and therefore Samekey( 0 , 0 ) implies that session 0 , too, must have a valid key.In particular it must have accepted (and can both be tested and revealed in an attack on secrecy).Assume now that there was a successful adversary A against key-match soundness (with two sessions 0 , 0 as above).We show how to break BRSec through an adversary B 2 with non-negligible probability in this case.
Our adversary B 2 will try to predict the sessions 0 , 0 by picking two session numbers i, j at random from {1, 2, . . ., n}, where we count sessions according to their initialisation in A's simulated attack.Next, B 2 runs A's attack, relaying all inputs and oracle queries and answers between B 2 's game and A. Note that B 2 has the same oracle interfaces as A, but in addition may call the Test and the Guess oracle.
Adversary B 2 diverges from A with respect to two points: If the i-th session in the attack accepts, then B 2 immediately asks to Reveal the session key key i .If the j-the session accepts, then B 2 immediately calls Test to get a key value key j .Adversary B 2 makes the Guess(b guess ) query and stops, where the bit b guess is set to 1 if key i = key j , and to 0 otherwise.
Note that up to the point when B 2 makes the Test query, the simulation to A is perfect.Assume that B 2 predicts 0 , 0 correctly for the Test query resp.the Reveal query, which happens with probability at least 1/n 2 .Then the Test session 0 does not have a partner yet, is authentication fresh and the authenticating partner is still honest, such that the session is still secrecy fresh.In this case, if b test = 1 the Test oracle returns the actual session key, such that the keys match, and we have B 2 output 1, too.In summary, the probability of this happening is at least 1 n 2 times the probability that A succeeds, minus a negligible term for refuting Match security.This is non-negligible.
Next consider the case b test = 0 such that the test session 0 returns a random key.Then the probability that this independent random key matches the other key is 2 −|key| and thus negligible, such that B 2 only returns 1 with this negligible probability.

Relation with CK-style Security
In all CK-style models (CK, CK HMQV and eCK) the definition of "matching sessions" includes, among others, the requirement that parties agree on each other's identities.As there is no other mention of matching expected identities, this seems to be the only capture of authentication in such models.
Capturing authentication in CK-style models.Some light is shed on this by Cremers's argument in [Cre11].He states that since "the test session-key must be indistinguishable from keys computed by non-matching sessions", then sessions that compute the same key must be matching sessions.This is analogous to our Theorem 5.1 concerning KMSoundness except that the CK-style definition of matching also includes expected identities, and therefore this result implies that CK-style security also guarantees (at least) implicit authentication.
Crucially, this argument however only applies for sessions for which CK-style security holds, that is sessions that remain sFresh CK , for a suitable definition of this extended secrecy freshness predicate that captures the restriction of the CK-style models as presented in [Cre11].In contrast, our standalone definition of implicit authentication (Definition 3.1) captures security against a much wider range of attacks due to its absence of freshness requirements on the target session.
Extending authentication freshness.To establish our authentication definitions of Section 3 in a CK-style model, we consider whether the freshness conditions changes upon the addition of a StateReveal query.This reveals to the adversary either the entire state of a session or only its ephemeral key, as defined by the protocol, for the CK and eCK models respectively [Cre11].
Following from the discussion of Section 3.1, we allow the adversary to perform StateReveal queries when attacking the iKeyAuth CK predicate as we wish to capture the widest possible range of attacks.We recall that this implies that A can both StateReveal a session and Corrupt its owner during its attack, which is not allowed by the freshness conditions of CK-style models.Following similarly from Sections 3.2 and 3.3, we have a restriction that the adversary cannot trivially obtain the key when attacking key confirmation and explicit key authentication.Therefore we add the condition that the adversary cannot both corrupt the intended partner and also StateReveal a partner session for attacks against CK variants of these predicates.
Separating authentication from secrecy.Let E denote the event, in a CK-style secrecy experiment, where the adversary succeeds in causing two game-controlled sessions to share a key without matching in the CK-style sense, i.e. without agreeing on each other's identities.Let G CK denote the usual CK-style secrecy game and let also G − CK be the secrecy game which instead uses our definition of partnering of Section 2.2 without expected identities (i.e. an extension of the secrecy game of Section 5.1).Using a rather informal terminology, we then have Pr [A wins First, E corresponds exactly to a break of iKeyAuth CK and so we have Second, if A wins G CK without triggering E, then his attack can be reproduced in G − CK and so we have In conclusion, Pr [A wins G CK ] ≤ Pr [¬iKeyAuth CK ] + Pr A wins G − CK , which shows that we can represent CK-style key secrecy through our separate notions of authentication and key secrecy when adapted to these models.

Key-confirming protocols
In this section we define the class of symmetric key-confirming protocols.These are protocols which provide guarantees on the existence of a session with the same key.We note that this guarantee may be secondary to the main functionality of these protocols.For example, we would expect that protocols for authenticated message transmission would belong to this class.
Based on the model of [BFWW11, Section 4], we describe the syntax for such protocols and the security game for key confirmation.We formalise these protocols as π = (kg, ζ) and write D kg to denote the output distribution of the randomized key generation algorithm kg; we use the same mechanism of local session identifiers.For the game execution state, as there are not long-term keys, EST is not defined.
Session state.The session state for key-confirming protocols consists of: crypt ∈ {0, 1} * is some protocol-specific private session state.
kcind ∈ {true, false, ⊥} indicates key confirmation achieved.Initially set to ⊥, it must be changed to true or false before termination.The value of kcind is always public.The difference with [BFWW11] is the addition of the key confirmation indicator kcind which informs the owner if key confirmation has been obtained.We stress that setting kcind is done independently of termination.For example, a secure channel protocol could achieve key confirmation with the first messages exchanged but continue running for much longer as the channel is used for communication.We will only focus on guarantees related to the setting of kcind and will not make assumptions or requirements on the session's termination.
Local session state.As in [BFWW11], the local session state consists of: δ key ∈ {fresh, revealed} denotes whether the key is known to the adversary.
lst ∈ {0, 1} * is any other local session state required to model the protocol's other security requirements.
Setup.The setupE algorithm only initialises crypt, key and kcind to ⊥ for each ∈ LSID.The setupG algorithm also only initialises δ key ← fresh for every session as our security game for key confirmation does not require any model-wide state.
Queries.As in [BFWW11], our model allows A to initialise sessions with three different queries.The first, InitS( ), initialises a session with an honestly generated key, .key← kg(1 λ ), which remains outside of the adversary's view.The second, InitP( 1 , 2 ), initialises a session with the same key as another.Here, the game sets 2 .key← 1 .keyand 2 .δkey ← 1 .δkey .The third query, InitK( , κ), allows A to set his own key for a given session.It sets .key← κ and immediately sets .δkey ← revealed to note that A already knows the key.As before, Send( , m) and Reveal( ) allow A to control the network and view honestly generated keys.
The Valid predicate verifies that Send and Reveal queries are only made to sessions which have been initialised and that initialisation queries are only made to sessions for which the key has not yet been set.For the InitP query, it also verifies that 1 has already been initialised.Key confirmation guarantee.We note that here there no longer exists a distinction between full and almostfull key confirmation since keys are set upon initialisation.This notion says that for any session which has set the key confirmation identifier to true, there is another session which uses the same key.
The symKeyConf predicate evaluates to 1 if and only if where Samekey is defined as for AKE protocols, including the condition that =8 .The game G symKeyConf is then defined with state, setupE, setupG and behaviour as above, with query set Q = {Send, InitS, InitP, InitK, Reveal} and winning predicate P = symKeyConf.
The protocol π provides (secure) key confirmation, or is a key-confirming protocol, if, for all PPT adversaries A, Adv We note that a symmetric protocol π which always sets kcind = false trivially achieves secure key confirmation.This is similar to an AKE protocol formally achieving implicit key authentication by setting S = ∅.
Protocol example.We present an example of key-confirming protocols.Let M = (kg, MAC, Vf) be an unforgeable message authentication code (MAC) which requires that, for any PPT adversary A, where MAC(key, •) denotes access to a tagging oracle and Q denotes the messages queried by A for tagging.
From such a MAC, we construct the protocol π kconf as follows.If a session is activated with m = init, it sends t = MAC(key, 1).When it receives a second message m * , it verifies that it is a tag for the message "2" by checking if Vf(key, 2, m * ) = 1.If this holds, then it sets kcind ← true, otherwise it sets kcind ← false.If a session is instead activated as a receiver, then it plays the counterpart and checks that it correctly receives a tag for the message "1" and, if so, sets kcind ← true and replies with a tag for "2".We present the formal description of π kconf in Figure 5.
To show that the protocol π kconf is key-confirming, we use the concept of single-session reducible games presented in [BFWW11].Without specifying the formal details, we see that the independence or sessions in the game G π kconf symKeyConf , apart from their potential partner, implies that this game is session restricted.
We first recall that a key-confirming protocol π = (kg π , ζ π ) must set kcind before terminating and that a session can then continue its execution; this is not the case when forming an AKE protocol by composing with π since it must terminate upon acceptance of the key, as in Section 2. We therefore define the protocol π to be π with the algorithm ζ π the same as ζ π but halted after kcind is set.Thus the key derived by ζ ke is only accepted as the final key for the composed protocol once ζ π has terminated with kcind set to true.Now, given an AKE protocol ke = (kg ke , ζ ke ), we write ke; π = (kg ke;π , ζ ke;π ) for the composition.
As we consider ke; π as an AKE protocol, it uses the same long-term key generation as ke and therefore kg ke;π = kg ke .The algorithm ζ ke;π first runs ζ ke .If it rejects, then ζ ke;π rejects the entire session; otherwise it runs ζ π with the derived key and accepts or rejects depending on kcind.Formally, given an incoming message m, the algorithm ζ ke;π first examines the value of accept ke from the ke protocol.If accept ke = ⊥, it passes m to ζ ke ; if accept ke = true, it passes m to ζ π .We note that this value of accept ke from ke is different from the value of accept ke;π for ke; π which is only set once both ke and π have terminated.
Syntax of composed games.Our composed game G ke;π Pred enables the adversary to interact with simultaneous sessions of the composed protocol.We stress that the adversary's goal here is to "break" the authentication property Pred of ke; π seen as an AKE protocol.We build our composed game from the elements of the games for the protocols ke and π and use indices to distinguish them.
Game state.The composed execution state EST ke;π is set to be EST ke as key-confirming protocols do not have one.The session state SST ke;π of a session is made up of the same elements as for key exchange protocols but constructed from the composing session states in the following way: -The long-term keying information (pk i , sk i ) and pk j is the same as in SST ke .
-The protocol-specific private session state is defined as the concatenation of both protocols' states: crypt ke;π = crypt ke crypt π .-The accept ke;π indicator is set to true once kcind π is set to true.Note that this only happens if accept ke is also already set to true as π does not begin until ke has accepted.-The session identifier sid ke;π is set to sid ke only when accept ke;π is set to true.-The key ke;π is set to key ke only when accept ke;π is set to true.Before then, the value of key ke is kept internally and passed on to π, so that key π ← key ke , when accept ke ← true.-As π always provides full key confirmation, we have that kconf ke;π = true for all sessions.The local session state LST ke;π remains the same as for AKE protocols and the model state remains undefined as not required for authentication.
Setup, queries and Valid predicate.These are the same as described in Section 2 with the addition that the Valid predicate makes use of the Valid π predicate for Send and Reveal queries to sessions that are executing π.
Winning predicate.We can use any of the predicates defined in Sections 2 and 3.
Composition result.We show that a implicitly authenticated key exchange protocol composed with a key-confirming protocol produces an explicitly authenticated key exchange protocol.Our choice of public session identifiers means we do not require a session matching algorithm as in [BFWW11, Section 3].
Theorem 8.1.Let ke be a Match-secure key exchange protocol which provides implicit key authentication and BR-secrecy w.r.t.key distribution D. Let π be a symmetric-key protocol with key generation distribution D which provides secure key confirmation.Then ke; π is a key exchange protocol with provides explicit key authentication.
Proof.We make use of Theorem 3.1 to separate our work into two steps.First we prove in Lemma 8.1 that ke; π provides implicit key authentication under the assumption that ke does.Then we prove in Lemma 8.2 that ke; π provides full key confirmation under the assumption that ke is BR-secret and that π provides secure key confirmation.As the two property hold separately, Theorem 3.1 immediately gives us that ke; π provides explicit key authentication.Proof.Let A be an adversary against ke; π in the G ke;π iKeyAuth game, which we refer to G ke;π when the context is clear.We build an adversary B against ke in the G ke iKeyAuth game, which we similarly refer to G ke .B sets up G ke;π for A as described above using elements from G ke .It then responds to A's queries in the following way.(We use the notation ke;π to denote session identifiers used by A in G ke;π and the notation ke to denote the corresponding identifiers used by B in G ke .)-When A submits Corrupt(i), B submits Corrupt(i) to G ke and receives sk i which it returns to A. At that moment, G ke will mark the values of ke .δownr and ke .δpeer as corrupt for relevant ke as decribed in Section 2. However, B will not update the corresponding sessions in G ke;π in the same way as this would leak information to A about the internal stage of the sessions.Instead, B marks the values as corrupt for the sessions ke;π which have not completed the entire composed protocol, even if they have already completed the key exchange protocol and would not be marked as corrupt in G ke .
We now argue that if A is able to reach an execution state in G ke;π for which the iKeyAuth predicate evaluates to 0, then B, by behaving as described above, reaches a state in G ke for which the iKeyAuth predicate also evaluates to 0. This means that the composed protocol preserves implicit key authentication.If A reaches such a state, then we have that ∃ ke;π ∈ LSID ke;π :: ( ke;π .pid∈ S ∧ ke;π .accept)∧ ∃ ke;π ∈ LSID ke;π :: Samekey( ke;π , ke;π ) ∧ ke;π .id= ke;π .pid .
We show that this also holds for the corresponding sessions ke and ke in G ke .We first have that ke .pid∈ S as all the sessions and the set S match one-to-one between the two games.We then have that ke .accept= true as ke;π .accept is set to true only if the ke session accepts, and B relays A's Send queries exactly which causes ke to accept in G ke .
As per the definition of the composed protocol ke; π, the final key is fixed as soon as the ke part completes, therefore it holds that if two sessions accept with the same key in G ke;π , then they have derived that same key in the first part.As B relays A's queries exactly, we have that Samekey( ke , ke ) holds in G ke for the sessions corresponding to ke;π and ke;π .Furthermore, ke .id= ke .pidalso holds as these values are the same as the ones for the sessions in G ke;π .This shows that the following holds for the corresponding sessions: ∃ ke ∈ LSID ke :: ( ke .pid∈ S ∧ ke .accept)∧ (∃ ke ∈ LSID ke :: Samekey( ke , ke ) ∧ ke .id= ke .pid), which implies that B is a successful adversary for the game G ke iKeyAuth exactly when A is succesful for the game G ke;π iKeyAuth .Lemma 8.2.Let ke be a Match-secure key exchange protocol with output key distribution D. Let π be a symmetric-key protocol with key generation distribution D. Let n = n 2 i • n s .For any PPT adversary A, it holds that Adv for some PPT algorithms B 1 and B 2 .
Proof.We use a strategy similar to the proof of Theorem 1 in [BFWW11], namely we first replace all the keys derived by the ke part of the composed protocol by randomly sampled keys from the correct distribution, using BR-secrecy to show that the final game is indistinguishable from the first.Then we show, similarly to Lemma 8.1, that if an adversary manages to break the key confirmation property of the composed protocol, then a reduction can break the key confirmation property of the symmetric protocol π.
To replace all the keys used, we proceed with a hybrid argument.Let the game G ke;π,Σ,D fKeyConf be the game G fKeyConf played against protocol ke; π, where the first Σ sessions to accept a new key, i.e.where a partner session has not already accepted a key, have their keys from ke replaced by a random value from D for the π part, where D = D kg is the output distribution of the key generation algorithm for π.We remove the mention of fKeyConf when the context is clear.The original game G fKeyConf for A is therefore G ke;π,0,D where only honestly computed keys are used for π.
The game G ke;π,Σ,D runs just as G ke;π fKeyConf does with the following modifications.It maintains a counter σ to keep track of the number of new keys that are accepted (not counting those which the adversary might already know by corrupting one of the parties); this is set to 0 initially.The behaviour of G ke;π,Σ,D is then the same as G ke;π with the following differences to the Send( ke;π , m) query: -If σ ≥ Σ, behave as in G ke;π , otherwise: -If ke has accepted already, simulate the π part honestly with π .key;-Compute the response and the state update according to the ke algorithm; -If ke .accept← true: • If there exists an ke;π ∈ LSID such that Partner( ke;π , ke;π ) = true and ke .accept= true, then set π .key← π .key;• If there does not exist such an ke;π that is partnered and whose ke part has already accepted, but either ke;π .δownr = corrupt or ke;π .δpeer = corrupt then set π .key← ke .key;• If both identities are still honest, and no partner session exists or has already accepted a ke key, then set π .key

Entity authentication
This second form of authentication does not involve the key in its security guarantees.Our entity authentication definitions are instead based on the Partner predicate, instead of Samekey, and say that if two sessions terminate with the same sid, then they should agree on each other's identities.This corresponds to the intuitive notion of entity authentication where sessions obtain guarantees upon terminating and deriving an identifier.We first present our definitions and then demonstrate that for Match-secure and BR-secret protocols, entity and key authentication are equivalent.
This equivalence also shows that, similarly to including the identities in the key to ensure implicit key authentication, including the identities in the session identifiers ensures implicit entity authentication.It also suggests that involving the sids in a MAC is a good method for ensuring entity confirmation.

Implicit and full explicit entity authentication and confirmation
To adapt our definitions to entity authentication, we replace Samekey by Partner.Below we present only the predicates for implicit entity authentication, entity confirmation and full explicit entity authentication; the full case requires the definition of the session state variable econf ∈ {full, almost, no, ⊥}, indicating, analogously to kconf, which form of authentication a session expects.The almost-full case is more involved because it also requires entity confirmation identifiers, similarly to the kcid; for the sake of brevity, we do not include it here.The full definitions can be derived from the following predicates.Implicit entity authentication: The iEntAuth predicate is defined as ∀ ∈ LSID, ( .pid∈ S ∧ .accept)=⇒ ∀ ∈ LSID, (Partner( , ) =⇒ .id= .pid) .
We note that implicit entity authentication is a very weak notion as the session terminates neither with an explicit guarantee nor with a secret element, such as a key, that it may use later to obtain a stronger guarantee.Separating the two different properties that constitute explicit authentication may be helpful to understand and guide protocol design.For example, with this separation in mind, a signature over the transcript sent at the end of an execution can be seen as providing entity confirmation, and therefore boosting implicit entity authentication to explicit authentication.A similar argument could show that password authentication over a secure channel can serve a similar purpose.

Key and entity authentication relationships
We now present the necessary conditions for key and entity authentication notions to be equivalent to one another.We use the "secrecy and match-security predicate" KMSoundness from Definition 5.3 to state the relationships in terms of predicates.Recall that this predicate holds (with overwhelming probability) for a Match-secure and BR-secret protocol.The results are intuitively compelling.Under the assumption that partnered sessions derive equal keys and equal keys can only be derived in partnered sessions, authentication guarantees obtained via keys are equivalent to those obtained directly via session identifiers.
Fig.1.Relationship of notions for implicit key and entity authentication (iKeyAuth and iEntAuth), explicit key and entity authentication (exKeyAuth and exEntAuth), key and entity confirmation (KeyConf and EntConf), Match security and key Secrecy.We note that key confirmation and explicit authentication definitions actually come in two flavours, full and almost-full, depending on which party receives the final protocol message.The implications hold accordingly for these sub versions.
3. When A terminates, b ← P(LSID, SST, LST, EST, MST) is evaluated by the experiment which finally outputs b.

Fig. 4 .
Fig. 4. (Simplified) TLS 1.3 in mode (EC)DH, without handshake encryption and with server-only authentication.The session identifier and key-confirmation identifier are given by sid = kcid = (r, X, S, Y, certB).Notation x, . . ., y means all transmitted communication data, ranging from x to y.
To define the BR-secrecy game G BRSec,D , where D denotes the distribution of keys, we use the same execution, session and local session states as in Section 2. The model state contains two bits, b test ∈ {0, 1} (initialised at random) and b guess ∈ {0, 1, ⊥} (intialised to ⊥) along with a session identifier test ∈ LSID ∪ {⊥} (initialised to ⊥).The identifier test is the local session to which the Test query is made (see below).The bit b test determines whether the adversary receives the real key from test , or a random value, in response to the Test query-we assume that only one Test query is made.The bit b guess stores the adversary's guess.There are two additional queries, namely Test and Guess.The Test( ) query sets test ← and returns key = .keyif b test = 1 or key $ ← − D otherwise.The query Guess(b) sets b guess ← b.

Lemma 8. 1 .
Let ke be a key exchange protocol and let π be a symmetric-key protocol.For any PPT adversary A, it holds that Adv G ke;π iKeyAuth A,ke;π,I,S (1 λ ) = Adv G ke iKeyAuth B,ke,I,S (1 λ ) for some PPT algorithm B.

$
← − D and update σ ← σ + 1.With this new behaviour, we have that the first Σ new keys that are unknown to the adversary at the time of their acceptance are replaced with keys sampled from D for the π part of the protocol.Lemma 8.3 now allows us to change the game G ke;π,0,D into the game G ke;π,n,D for n = n 2 i • n s where the indinstinguishability of the two games is guaranteed by the BR-secrecy of the ke protocol.This yields AdvG ke;π,0,D fKeyConf A,ke;π,I,S (1 λ ) − Adv G ke;π,n,D fKeyConf A,ke;π,I,S (1 λ ) ≤ n • Adv G D BRSec B1,ke,I,S (1 λ ),for a first reduction B 1 .In Lemma 8.4, we then show that key confirmation of the composed protocol follows from key confirmation of the symmetric-key protocol: AdvG ke;π,n,D fKeyConf A,ke;π,I,S (1 λ ) = Adv G symKeyConf B2,π,I (1 λ ) for a second reduction B 2 .This allows us to conclude that Adv G ke;π fKeyConf A,ke;π,I,S (1 λ ) ≤ n • Adv G BRSec,D B1,ke,I,S (1 λ ) + Adv G symKeyConf B2,π,I (1 λ ).

Proposition 9. 1 .
Let π be an AKE protocol.Then it holds for π thatiKeyAuth ∧ Match =⇒ iEntAuth, (11) fexKeyAuth ∧ Match ∧ KMSoundness =⇒ fexEntAuth, When A submits Send( ke;π , m), B checks the value of ke;π .accept.If it is either true or false, B responds ⊥ to A as the sessions has either already accepted or rejected.If it is still ⊥, B examines the value of ke .accept.• If ke .accept= ⊥, B submits Send( ke , m) to G ke and responds to A with m returned by G ke .If ke .sid is set at that step, B sets ke;π .sid← ke .sid.If ke .accept← false, B sets ke;π .accept← false and makes this known to A. If ke .accept← true, B submits Reveal( ke ) to G ke to obtain ke .key.• If ke .accept= true and π .kcind= ⊥, B has obtained ke .keyso it can respond to A according to π by computing the response internally.If π .kcind← false, B sets ke;π .accept← false.If π .kcind← true, B sets ke;π .accept← true and ke;π .key← key .key.• The case of ke .accept= false is never examined as it would already hold that ke;π .accept= false.-When A submits Reveal( ke;π ), B checks the value of ke;π .accept.If it is either ⊥ or false, B responds ⊥ to A as his Reveal query is invalid.If it is true, then ke;π .keywas set when ke;π .accept← true so B responds with ke;π .key to A and sets ke;π .δsess ← revealed.