On the modelling of Kerberos protocol in the Quality of Protection Modelling Language (QoP-ML)

– The security modelling of IT systems is a very complicated task. One of the issues which must be analysed is the performance of IT systems. In many cases the guaranteed security level is too high in relation to the real threats. The overestimation of security measures can decrease system performance. The paper presents the analysis of Kerberos cryptographic protocol in terms of quality of protection performed by Quality of Protection Modelling Language (QoP-ML). The analysis concerns the availability attribute. In the article the Kerberos protocol was modelled and the QoP analysis of two selected versions was performed.


Introduction
During modelling the IT security of the organization one has to consider system performance and financial costs. System security is guaranteed by using different types of security mechanisms [1]. Security analysts must decide which security measures should be used for the system protection and whether the selection is sufficient. The usage of strongest security mechanisms can lead to the overestimation of security measures which causes an unreasonable increase in the system load [2,3]. A better solution is to adjust the security measures to the required level of protection. Such an approach can be achieved by means of the Quality of Protection systems where the security measures are evaluated according to their influence on the system security.
analysis engine of the modelled protocol is the part of the core system. In the paper [13] the syntax, semantics and algorithms of the QoP-ML are presented.
In the paper we would like to present the case study of the quality of protection modelling by means of the QoP-ML. For illustration of the QoP analysis process we chose one of the most popular cryptographic protocols -Kerberos [15].

Case Study: Kerberos protocol
In this section we are going to present the case study of QoP modelling of the Kerberos cryptographic protocol [15]. We are analysing the two versions of the protocol. In the first one the symmetric key is generated by Trusted Third Party and in the second one the key is generated by both sides: A and B. The flows of both version of the protocol are realized in four steps and the schemes are presented in Figs 1 and 2.
Notation for Figs 1 and 2 TTP -Trusted Third Party; A -side A; B -side B; ticket B =(K, A, L) K BT T P -ticket for the side B; authenticator 1 =(A, T A ) K -authenticator 1; authenticator 2 =(A, T A ,K ′ ) K -authenticator 2; K -new generated symmetric key; L -lifetime of the ticket ticket B ; T X -timestamp from the local clock of side X; N X -the nonce of the X. K ′ -subkey of the key K generated by the site A; K ′′ -subkey of the key K generated by the site B.  The flows presented in Figs 1 and 2 are the simplified, fifth version of the Kerberos protocol. This protocol is fully analysed and described in [15]. In the next section it is briefly described according to the introduced notation used in Figs 1 and 2.
Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 06/04/2022 12:10:19 U M C S Step 1: A Client A generates a nonce N A and sends to the TTP the following information: his identification (A), generated nonce (N A ) and the identification of the side B with which he wants to perform the key exchange process.
Step 2: The TTP generates a new symmetric key K and defines the lifetime of ticket (ticket B ). After this, the TTP generates the ticket (ticket B ). The ticket contains: generated symmetric key K, identifier of side A (A) and the lifetime of the ticket L. This data is encrypted with the symmetric key K BT T P shared between TTP and B. Next, the TTP creates the message addressed to side A containing: the symmetric key K, identifier of side B (B ), the lifetime of the ticket L and the previously received nonce N A and encrypts it with the symmetric key K AT T P shared between TTP and A. Finally, the TTP sends these two encrypted data to the A.
Step 3: The side A decrypts the second encrypted data using the key K ATTP . After this it verifies the integrity of the received nonce N A with the one sent in step 1. In the next operation, side A generates one of the messages authenticator 1 or authenticator 2 depending on the selected version of the protocol. Both these messages contain identification of A and the current timestamp T A . In the second version, A additionally generates its subkey K and includes it in the message. Next the prepared message is encrypted with the received key K. Finally A sends the received ticket (ticket B ) and the authenticator (authenticator 1 or authenticator 2 ) to the side B.
Step 4: The side B decrypts the received ticket (ticket B ) using the shared key K BT T P and obtains the key K. After this the side B decrypts the authenticator and verifies the following information: the identifiers A in the ticket and the authenticator, the timestamp in the authenticator and the ticket lifetime L. If the verification of all components is positive then, depending on the selected version, the side B either encrypts only the received timestamp T A (in version 1) or generates its own subkey K and encypts both the received timestamp T A and generated key K . In both cases the encryption is performed using the key K. The encrypted data is sent to the side A. Next, the side A receives the data and decrypts it with the key K. The decrypted timestamp T A is used for authentication of the side B.
The QoP analysis process includes the five steps: protocol modelling, security metrics definition, precess instantiation, QoP-ML processing and QoP evaluation [13]. The following section describes these steps during modelling of the Kerberos protocol.

Protocol modelling
In the first step one has to model all operations required in the Kerberos protocol [15]. These operations are generally described in the protocol flow scheme (Figs 1 and  2). In the article we present one level analysis where only the cryptographic operation will be considered. The QoP analysis can refer to different security attributes and each of them must be proceeded according to the special algorithms. In the article which introduces QoP-ML [13] the algorithm referring to the availability security attribute [16] is presented. Thus the Kerberos protocol will be analysed according to this security attribute.
The protocol modelling step includes the four operations: function defining, equation defining, channels defining and protocol flow description.

Functions
For modelling of the Kerberos protocol we defined the functions which refer to the cryptographic operations required in the protocol. These functions are presented below. In the round bracket the description of these functions is presented.

Equations
After defining the functions one can describe the relations between them. eq dec(enc(data,K),K) = data (symmetric encryption/decryption)

Channels
In the presented example we define two synchronous channels. channel ch1,ch2(0);

Protocol flow
The last and the most important operation during the modelling process is abstracting the protocol flow. In the presented case study we analyse two versions of the Kerberos protocol. In the first one, the exchanged key K is generated by the Trusted Third Party (TPP) and used by both sides. In the second version, the key generated by Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 06/04/2022 12:10:19 TPP is used to encrypt the messages which include the subkeys K and K of boths sides while the exchanged key will be derived from these subkeys.
To analyse it, one does not have to design these two versions separately, but they can be abstracted in one protocol flow. While defining the protocol instantiation one can specify the parameters typical of specific versions of Kerberos.
The operations inside the processes are numbered owing to which one can easily refer to them during the QoP analysis. These operations are numbered independently (locally) inside every single process.
In the following section the high hierarchy processes will be described in detail.

Host A
The processes inside the Host A are scheduled according to the round robin (rr) algorithm where the quantum of time is defined in QoP-ML as the single operation. All communication channels are accepted by this process (*). Firstly, the operation, which is executed before the process Host A starts, is defined (# operator). This is K_ATTP -defining the symmetric key shared by the Hosts A and TTP. process A1 Process A1 can communicate with the other processes through the channels ch1 and ch2. In the first operation the id of side A, which starts the protocol, is created and is assigned to the variable IDA. Next, Host A creates the id of the side IDB which he wants to authorise and with whom he wants to exchange the new key. In the third operation the nonce is generated and assigned to the variable NA. Additionally, the Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 06/04/2022 12:10:19 U M C S qop parameters are defined (according to the defined function description), there is the bits length -256 and the algorithm used in the Linux Ubuntu System named -Linux PRNG. In the next operation the message M1 is created containing the following data: IDA, IDB, NA. After this, the message M1 is sent through the channel ch1 and Host A starts to listen on the channel ch1. When the messages are received on the channel ch1, they are assigned to the variables TicketB and Y. The variable Y is decrypted using the key K_ATTP and the result is assigned to variable M4. Next, timestamp TA is created and one of the subprocesses (Av1 or Av2) is run (depending on the selected version in the process instantiation). These subprocesses differ in only one operation -the new symmetric subkey generation (functionskey) which distinguishes the analysed Kerberos protocol versions. As the output of these subprocesses the message containing TicketB and one type of the authenticator are created and sent through the channel ch2. In the next operation the Host A starts to listen on the channel ch2. When a message is received, it is assigned to the variable Z and decrypted using the key K. The result of this operation is assigned to the variable M7 and the ingredient containing the timestamp TArec is compared with the previously sent timestamp TA. When these timestamps are the same, then the authorization process is finished sucessfully and the state of the protocol flow is changed into the finished newstate. When the timestamp TArec is not equal to TA, the protocol is stopped stop.

subprocess Av1
The subprocess Av1 can communicate with other processes through all channels (*). In the first operation the message M5 is created which contains the created timestamp TA and identification of side A IDA. After this, the message M5 is encrypted with the key K received in the message Y. The result of this encryption is assigned to the variable authenticator1. Next, both the TicketB (received with the message Y) and authenticator1 are sent through the channel ch2. subprocess Av2 The subprocess Av2 can communicate with other processes through all channels (*). This subprocess differs from the subprocess Av1 in one step only. In this process the symmetric key KA is created and joined to the message M5. As a result, the new authenticator is created authenticator2 and sent with TicketB through the channel ch2.

Host TTP
In this Host the processes are scheduled according to the same algorithm as in Host A and all communication channels are accepted by this process (*).A si nHost A, firstly the operations executed before Host TTP starts the main process are defined (# operator). There are: K_BTTP -the secret key shared between B and TTP and K_ATTPthe secret key shared between A and TTP.

process TPP1
Process TPP1 can communicate with other processes through the channels ch1 and ch2. At the beginning the process is waiting for incoming message which is assigned to the variable X. When the message is received the process generates a new symmetric key and stores it in the variable K. Next the lifetime of ticket is stored in L and identification of the side that started protocol is retrived from the message X and assigned to IDA. The process TTP1 can now create message M2 including: the generated key K, retrived id IDA and lifetime L and encrypt it using the key K_BTTP to obtain TicketB destined for the side B. In the next four operations the process TTP1 preapres the returning message for the side A. This message includes: the nonce retrived in message X, generated key K, lifetime L and identification of side B obtained from message X. Next the message is encryptrd with the key K_ATTP shared between Host A and Host TTP and both TicketB and the encrypted message M3E are sent through the channel ch1.

Host B
In Host B processes are sheduled in the same way as in prevoius hosts and all communication channels are accepted by this process (*). It has one previously computed value stored in the variable K_BTTP. It is the symmetric key shared between Host B and Host TTP.
process B1 The process B1 can communicate with other processes using the channel ch2. Firstly, Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 06/04/2022 12:10:19 U M C S the process is waiting for two messages (stored in TicketB and authenticator variables) on the channel ch1. Next, both messages are decrypted. TicketB is decrypted using the key K_BTTP because it comes from Host TTP and was forwarded by Host A. The result of decryption is stored in the M1 variable. The second message authenticator is decrypted with the key K generated by TTP and the result is stored in the variable M2. Further, one of the subprocesses (Bv1 or Bv2) is executed depending on the selected version in the process instantion.

subprocess Bv1
The subprocess Bv1 can communicate with other processes through all channels (*). Firstly, it obtains the timestamp of side A (TA) and the key generated by TTP (K) from the retrived messages. Next, the subprocess sends the timestamp TA encrypted with the key K through the channel ch2. Then the protocol is finished for Host B.

subprocess Bv2
The second version of the protocol flow is similar at the beginning. It also obtains the timestamp of side A (TA) and the key generated by TTP (K), but later the flow is different from the previous subprocess. Instead of sending only timestamp TA, the subprocess Bv2 generates the subkey K" of side B stored in the variable KB. Next, the subprocess sends both: timestamp TA and generated key KB encrypted with the key K through the channel ch2. Then the protocol is finished for Host B.

Security metrics definition
When modelling the protocol, the designer needs to define the security metrics for all functions connected with each security attribute which he wants to test. In the presented case study we test the availability of two different flows of Kerberos protocol. Hence, we need metrics for all functions that may affect the availability. We have checked the execution times of operations used in the Kerberos protocol that may be used (ie. nonce/key generation, encryption).
Many security metrics may be obtained from benchmarks present in both, official hardware specifications and literature [17,18]. Some of them can be found in the specialized scientific articles, such as performance characteristics of the S-blocks [19,20]. However, some metrics may depend on the hardware on which the protocol is executed [21]. Therefore, in our case study we have used commonly applied software to compute metrics so that everyone can very easily compute them on his host. For encrypting and decrypting we have used openssl program with speed library [22]. For the functions which generates the nonce and keys we prepared our own software described in [13].

Process instantiation
During the process instantiation one can define the versions of the modelled protocol. In the presented example we set two versions of the Kerberos protocol, the first version with one key generation and the second one with subkeys generated by both sides (A and B). In these versions three high hierarchy processes are executed: Host A, Host B and Host TTP.
In version 1 inside the process Host A the process A1 is executed (functionrun) with the subprocess Av1. Inside the process Host B the process B1 is executed with the subprocess Bv1. The process Host TTP is run the same way in both cases. The Kerberos protocol versions can be modelled by defining the subprocess which will be executed in the specific protocol instantiation.
The second version of the Kerberos protocol differs from the first one in the key generation. The key is generated from two subkeys generated by both sides A and B. This flow was modelled as the subprocesses Av2 and Bv2 in the processes A1 and B1, respectively.

QoP-ML processing and QoP evaluation
The final step in the QoP analysis process is QoP-ML processing and QoP evaluation which can investigate the influences of the security mechanisms for ensuring security attributes. In the presented case study we focus on the availability of the cryptography protocol. The QoP-ML processing of this security attribute should be prepared according to the algorithms presented in the article [13]. Unfortunately, realization of this security attribute is a complex task because it refers to configuration of the whole teleinformatic infrastructure in which the protocol is realized. In the article the QoP evaluation is focused on one level of security aspect which refers to the cryptographic algorithm. Based on these algorithms we calculated the total execution time (T Total )of the two analysed versions of the Kerberos protocol. For the first version of the protocol the T Total =0.0050004018 s. In the second the T Total =0.010000441 s. The execution time for the first version of the protocol is 50% shorter than in the second version.

Conclusions
The aim of this study was to present a new language QoP-ML [13] and show how to perform an QoP analysis of cryptographic protocols. A full, multi-level cryptographic protocol analysis is very complex and exceeds the opportunity to be presented in this article. The study contains two selected versions of the Kerberos protocol and only cryptographic algorithms were taken into account. The QoP-ML modelling language allows to analyse protocols in terms of different security attributes, this paper presents an analysis in terms of availability. Based on the algorithms presented in [13]w e calculate the total protocol runtime for two versions of the Kerberos protocol.
The main feature of QoP-ML is that the cryptographic protocol can be analysed on different levels of security analysis. Owing to that the QoP analysis can take into consideration any factors which influence the overall system security. Another main feature of QoP-ML is that one can define the security metrics of the used operations in the analysed protocol.