What is Wide-Mouth Frog?

The Wide Mouth Frog Protocol is a computer network verification protocol typically used on unsecured networks. It permits people communicating over a network to verify their identity to each other, it also helps in preventing replay attacks, or snooping and offers detection of any alteration and the prevention of any unwanted reading. This can be demonstrated by means of BAN (Burrows–Abadi–Needham) logic. However, to avoid active attacks, some form of message authentication or authenticated encryption must be used.

The protocol can be specified as follows in security protocol notation, where user A is verifying itself to user B using a server S:

• Where the identities of user A, user B, and the trusted server are A, B, and S respectively.
• Timestamps generated by user A and server S are TS1 and TS2 respectively.
• A Symmetric key KAS that is only known to A and S.
• A generated symmetric key KAB, which will be the session key of the session between user A and user B.
• A Symmetric key KBS that is only known to B and S.

A  → S: A, {T{S1}, B, K{AB}}K{AS}
S  → B: {T{S2}, A, K{AB}}K{BS}

Wide Mouth Frog Protocol

Working of Wide Mouth Frog Protocol:

To understand the working let’s consider the example of the Wide-Mouthed-Frog protocol:

M1 A → S: {T{S1}.B.K{AB}}SKey(A)  
M2 S → B: {T{S2}.A.K{AB}}SKey(B)  

Here the server shares two different keys that are SKey(A) and SKey(B) with A and B; the purpose of the protocol is to establish a session key K{AB} between user A and user B, and to verify A to B. After that user A creates a session key and directs it to the server along with a timestamp TS1; the server then sends the key to user B along with a new timestamp TS2. Timestamps are generally used so that the users can obtain indications that the messages they have received were created recently. It should be noted that for passing and for this mechanism to work the different users’ clocks need to be synchronized; each user’s clock is crucial to the security of the protocol.

To understand this protocol, we will need to look at how time can be modeled in Casper, some other features of the Casper syntax, and the pragmatics of selecting the system to check.  For this let’s take four different systems running the protocol into consideration. FDR discovers that there is no attack upon system A, though it discovered three different attacks on the other systems. Big systems need significantly more time to check, so a practical approach would be to start with a smaller system and work our way up. The system D we check has, undoubtedly, been tailored to some extent to allow a particular attack; though, systems A, B, and C are examples of systems that one should always consider.

Most of the modeling of the protocol is generally simple; some points are given below.

#Free variables
A, B : User
S : Server
SKey : User → SKeys
KAB : SEKey
TS1, TS2 : TimeStamp
InverseKeys = (SKey, SKey)

Most names of types in Casper scripts can be selected by the user, though timestamp is an exception.

Timestamps are modeled in Casper by natural numbers. Hence making no assumptions about the time unit size compared to the time taken to send a message; numerous messages may arise within the same time unit, and it is also possible that some time units may pass between consecutive messages.

#Processes
INITIATOR (A, S, KAB) knows SKey(A)
RESPONDER(B) knows Skey(B)
SERVER(s) knows SKey
#Protocol description
0. → A : B
1. A → S : {B, TS1, K{AB}}{SKey(A)}
[TS1==now or TS1+1==now]
2. S → B : {A, TS2, K{AB}}{SKey(B)}
[TS2==now or TS2+1==now]

The users in the Wide Mouth Frog protocol obtain a message, they can check that whether the timestamps they receive are recent or not. They are done by the user who obtains the preceding message; and if the check fails, the user can abort the run.

#Specification  
TimedAgreement(A, B, 2, [KAB])

The requirement is that if a responder user B finishes a run of the protocol, with user A, then user A should have been running the protocol within the preceding two-time units; additionally, the two users should approve the value of KAB, and there must be a one-to-one relationship between the runs of A and B. All these tests that are performed on the timestamps allow for a delay of the one-time unit each, therefore making a maximum possible delay of two-time units.

However, for this specification to have any chance of holding up, there needs to be a negligible delay between S checking message 1 and sending message 2.

Let’s look at system A now, considering a system with a single initiator, user A, and a single responder, user B, both can run the protocol once; taking all the datatypes to be as small as possible and consistent with this system. Generally, the description of the actual variables is simple; the only new feature is how time is modeled here:

#Actual variables
User A, User B, kcbt : User
mkcbt : Server
KAB : SessionKey
TimeStamp = 0 .. 0
MaxRunTime = 0

#System
INITIATOR(User A, mkcbt, KAB)
RESPONDER(User B)
SERVER(mkcbt)

#Functions
symbolic ServerKey

#Intruder Information
Intruder = kcbt
IntruderKnowledge = {User A, User B, kcbt, mkcbt, SKey(kcbt)}

Here we assumed that the intruder can produce all timestamps; thus, they don’t have to be included in the intruder’s initial knowledge. Hence, when the above file is compiled by using Casper, FDR fails to find any attack upon the subsequent system.

Now, let’s take a look at system B, considering a system where user A can run protocol once as initiator, concurrently.

#System  
INITIATOR(user A, mkcbt, kcbt)  
RESPONDER(user A)  
SERVER(mkcbt)

Here FRD discovers that the protocol doesn’t authenticate the initiator user B to responder user A correctly. Hence, by using the FRD debugger we find the form of the attack as given below.

M α.1 A → mkcbt: {B.0.KAB}SKey(A)
M β.2 Imkcbt → kcbt: {B.0.KAB}Skey(A)

The attacker merely reruns user A’s first message back at the user itself, which they construe as being message 2 of a run started by user B.

Now, let’s take a look at system C, where the responder user B can run the protocol sequentially twice.

#System
INITIATOR(A, mkcbt, KAB)
RESPONDER(B) ; RESPONDER(B)
SERVER(mkcbt)

It can be attacked if the user can run the protocol more than once; though usually, the attacker can use information from the first run in order to fake a second run.

#System
INITIATOR(A, mkcbt, KAB)
RESPONDER(B)
RESPONDER(B)
SERVER(mkcbt)

Now, in this, the FCR tells us that user A is not correctly authenticated. Hence, the FDR debugger can be used to exhibit some of the following attacks as these violate the injective authentication property.

M α.1 A → mkcbt : {B.0.KAB}SKey(A)
M α.2 mkcbt → B : {A.0.KAB}SKey(B)
M β.2 Imkcbt → B : {A.0.KAB}SKey(B)  

The issue here is that user B perceives that he has completed two runs of the protocol, while user A only wanted to perform a single run. Here the attacker basically replays the message from mkcbt to user B, so that user B thinks that user A is trying to establish a second session.

Now, let’s take a look at system D, here an attacker can break the two-time unit limit. That is user B completes a run of more than two-time units after the corresponding run of user A.

TimeStamp = 0 . . 3
#System
INITIATOR(A, mkcbt, KAB)
RESPONDER(B)
SERVER(mkcbt) ; SERVER(mkcbt) ; SERVER(mkcbt)

After the system is checked, FDR looks that initiator user A is not authenticated as per the above-timed specification. So, after using a debugger the following attacks can be found.

M α.1 A → mkcbt : {B.0.KAB}SKey(A)
M α.2 mkcbt → IB : {A.0.KAB}SKey(B)
                   tock
M β.1 IB → mkcbt : {A.0.KAB}SKey(B)
M β.2 mkcbt → IA : {B.1.KAB}SKey(A)
                     tock
M γ.1 IA → mkcbt : {B.1.KAB}SKey(A)
M γ.2 mkcbt → IB : {A.2.KAB}SKey(B)
                     tock
M δ.1 Imkcbt → B : {A.2.KAB}SKey(B)

Problems in Wide Mouth Protocol:

• It requires a global clock.
• Server S has access to all the keys.
• The value of the session key KAB is determined by user A.
• It can only replay the messages within the valid timestamp period.
• User A is not certain that user B exists.
• It is a stateful protocol.