Extending TLS with KMIP protocol

for Cloud Computing

Mounira MSAHLI1 , Ahmed SERHROUCHNI1 , Mohamed BADRA2
1 Institut Mines Telecoms, Paris 75013
2 Zayed University, Abu Dhabi, United Arab Emirates
1 (mounira.msahli, ahmed.serhrouchni)@telecom-paristech.fr,
2 [email protected]

Abstract—Any information system using encryption tends protocols based on infrastructures become impracticals
to have its own key management infrastructure. In practice, for large scale information system like Cloud Computing.
we find a separate key management systems dedicated In traditional key management infrastructure, there is
to application encryption, or database encryption, or file
encryption etc. This emergent needs to several key management no centralisation of key management operations. Key
systems and multiple cryptographic algorithms are resolved Management Interoperability Protocol KMIP [1] tried to
by the new Key Management Interoperability Protocol resolve this problem by designing an efficient protocol for
(KMIP). This work specifies how the Key Management key management used for communication and to define
Interoperability Protocol (KMIP) can be included in Transport messages formats to manipulate cryptographic keys on a key
Layer Security (TLS) protocol in order to provide additional
security features, flexibility, interoperability and authentication management server. The related KMIP Profiles [2] are now
specially in distributed systems like Cloud Computing. Till official OASIS [3] Standards, a status that means its highest
now, authentication in TLS is limited to digital certificate level of maturity and its ratification.
and Kerberos. In this paper, we use the Key Management
Interoperability Protocol to make an additional authentication Generally, all security services can be provided by TLS[4].
option for TLS and we reduce handshake latency to 0-RTT
for repeated handshakes and 1-RTT for full handshakes. We For instance, it is quite common for systems to provide a
specify also the KMIP-TLS extension and its formal validation secure web page using https. When a client wants to connect
with AVISPA tool. to a server via TLS, he can use his certificate or Kerberos [5]
to make authentication. Our proposal in this paper consists on
Index Terms—Key Management Interoperability Protocol, using KMIP protocol to enssure client-server authentication.
Cloud, TLS, Security, AVISPA, Authentication.
We propose a new method for authentication in TLS, based
on KMIP protocol. The basic idea is to find a flexible and
I. I NTRODUCTION
practical authentication method via TLS mainly in Cloud
Key management process plays an important role on computing and web-based applications. In fact, the use of
enforcing access control, authentication and security on KMIP to manage authentication provides a simple and flexible
multi-actors communications. It allows the settlement and and strong client-server authentication. This strengthening
the maintenance of key relationships between valid parties is in total compliance with other TLS standard extensions.
according to a defined security policy. Basically, it includes Our goal for this solution is to stay as close as possible to
all mechanisms and procedures that perform verification the TLS standard treatments and calculations of different
of entities using cryptographic keys and performing security settings. The addition of KMIP to TLS preserves the
cryptographic operations. So it allows an entity to verify maximum operation of TLS protocol.
whether another entity is really what it claims to be. It ensures
generation, distribution and installation of key materials. It When data is placed in or transferred to a Cloud computing
is responsible for maintenance of keys generated, for their environment, the responsibility for its protection and its
change frequently to preserve their secrecy. Entreprises use security typically remains with the customer (the data
always a key management infrastructure to ensure the role of controller). This work is a continuity of other works already
key management entity. The choice of this entity depends on: done on security in the cloud [6, 7, 8]. We have already
the cryptographic algorithms employed on the company, the proposed a secure architecture for archiving Cloud service [9],
purposes for which cryptography is employed and the number which aims at archiving sensitive documents during a defined
and the complexity of cryptographic relationships required period in a secure environment. We suggested an architectural
by an organization and the operational and communications model that intends to satisfy Cloud user requirements and
relationships among the organizational elements being served. Cloud security challenges. In previous work, we defined a
new access control paradigm called profile centric model
Traditional internet key exchange and key distribution [10]. Which defines the access control in the context Cloud as

978-1-5090-2914-3/16/$31.00 ©2016 IEEE

a graph of profiles consisted of (authorization, condition and
obligation) with users assignment. The proposed model was
implemented and validated in the archiving Cloud service.
In this work, we focus specially on authentication service in
Cloud computing.

The map of this paper is as follow: in the second section

we present an overview of TLS and KMIP protocols. We
cover their important technical details. In the third section,
we focus on the proposed TLS-KMIP extension to add a new
authentication mechanism to TLS and its technical details.
In the fourth section, we present the formal validation and
security specifications of the proposal using AVISPA [11]. The
fifth section sums up this paper.

II. TLS AND KMIP OVERVIEW

Fig. 1: KMIP Network Architecture
In this section we are concerned with the presentation of
used protocols in our proposal:

A. TLS protocol that enterprises can use to deploy effective and unified key
management infrastructure for all their encryption materiels
TLS is actually, the most used standard for authentication in and components such as: certificates, digital signatures, etc...
wired and wireless communications. It is a security standard In practice, there are a number of standards applicable to
that provides end to end secure connections between two hosts. key management in the Cloud, the OASIS Key Management
Basically, it makes authentication based on digital certificates Interoperability Protocol is a recent one. It is used to
[12] or pre-shared keys[13] to ensure secure transactions. As provide basic encryption key paradigm to ensure Cloud based
mentioned in figure 1, TLS protocol is composed of three application and services security or it can be used directly by
sub protocols: (1) the Handshake protocol, (2) the Records Cloud customers to make encryption, signature ect...
protocol and (3) the Application data protocol. The purpose
of the (1) TLS-handshake [14] could be summarized under By definition, there are three primary elements in the KMIP
three headings. Firstly, the client and the server need to specifications:
agree on algorithms which will be used to encrypt exchanged
1) Objects: are symmetric keys, asymmetric keys, digital
data. Secondly, they establish a set of cryptographic keys
certificates ect.., on which we apply operations.
that will be used by those algorithms. Third, the handshake
2) Operations: are all actions taken with respect to the ob-
may optionally authenticate the client. In TLS protocol, users
jects, such as getting an object from a key management
generally to make authentication, they use a digital certificate.
system, modifying attributes of an object and so on.
Basically, the handshake protocol is used to establish security
3) Attributes: are the properties and characteristics such
parameters for TLS session. (2) The TLS Record Protocol
as the name of the object and its unique identifier.
is used for encapsulation of application layer messages. It
fragments message into packets to treat it independently. Each
fragment is compressed, encrypted and sent to the destination When a KMIP user sends a request to the key management
of the message. This treatment allows having a data structures server, it indicates the target object, its attributes and
named: TLS-Plaintext, TLS-Compressed and TLS-Ciphertext. properties and operation that must be executed by the key
The TLS Record Header is added to the TLS-Ciphertext to management server on that object.
make the TLS-Record. All of already cited structures include 4
fields (type, version, length and fragment). (3) The Application By definition, KMIP specifies the format in which a mes-
Data Protocol enables two hosts to exchange data. In fact sage is constructed and the elements that are included in the
it takes the data from the application layer to put it in the message. This allows KMIP to be used by any cryptographic
TLS Record protocol for fragmentation, compression, and client, from any device needing a security objects. KMIP re-
encryption in the sender side. After that, the set data is quests and responses messages are constructed by assembling
received, decrypted, verified, decompressed, and reassembled the message in a Tag/Type/Length/Value format, as shown in
in the receiver side. Figure 1.

B. KMIP protocol III. TLS-KMIP A RCHITECTURE AND M ODEL

There are several key management concerns and challenges Figure 2 provides a detailed description of TLS client to
within Cloud Computing. KMIP meets a pressing requirement server connection using KMIP authentication. In fact in this
to define a global and complete key management protocol, architecture, we have three actors: the client, the server and
 Fig. 4: KMIP response message

Fig. 2: KMIP-TLS Network architecture

name attribute. Once the key is located, it then uses its unique
identifier attribute id placeholder attribute, to retrieve the key,
assemble a response message and return the response to the
client (see KMIP response message).
The retrived Data: server certificate will be used in next step
to make TLS connection between the client and the server. In
the same way, the symetric session key to be used for TLS
connection is generated in KMS server and sent to TLS client
and TLS server. More details will be given in the next section.

B. TLS Client-Server Connection

In this section, we focus on TLS handshake exchanges.
Fig. 3: KMIP request message Full details of exchanged messages are provided here. The
main advantages of TLS-KMIP extension are: reducing the
latency and the handshake time. In fact using our extension,
the KMS (Key Management System) using KMIP as key the handshake protocol takes only one RTT(see figure 5) or 1.5
management protocol. The KMS is the third party responsible RTT(see figure 6) this is all coming from the low computation
for the key management between all actors. In our model, the needs. Here, we explain steps of TLS protocol with KMIP
KMIP server plays the role of authenticator and central server extension in two cases below (figure 5 and 6).
to provide all required cryptographic materiels to make client- 1) As presented in figure 5 and 6, the TLS Client (Cloud
server connection. The steps (1, 2, 3, 4) indicated in figure 2 user in our case) sends a ”Client Hello” message that
are repeated in each new connection. lists cryptographic information such as the TLS version
and in the client’s order of preference: the CipherSuites
A. Client-KMS Connection supported by the client, a random byte string that is
When the client wants to make connection with server. It used in subsequent computations. In order to negotiate
must send a client request to KMS server as modeled by Step the support of KMIP authentication option, clients must
1 in figure 2. include an extension in the extended client hello. The
The message sent by the client in step one is a KMIP ”extension data” field of this extension contains a list
request for session key. The KMIP request message contains: of supported authentication methods proposed by the
the protocol Version, this field contains the version number of client, where:
the protocol, in order to ensure that the protocol is undrestood
by two communicating parties. The operation field indicates Struct {
the operation being requested. ExtensionType extension type,
In our case, we use the operation ”Get”, that requests opaque extension data<0..2 ˆ16-1>, }
the server to return the managed object ”the symetric key” Extension;
specified by its Unique Identifier and its attribute name.
In a Cloud computing area and to make data pro-
On the server side, the client requests the key management cessing, privacy is an important parameter. To preserve
server to use the locate operation in order to find the client- anonymity, TLS Client makes authentication only with
server secret key and the certificate of the server based on its KMIP server. No need to contact directly the TLS server.
 Fig. 5: KMIP-TLS Extension with 1 RTT Fig. 6: KMIP-TLS Extension with 1.5 RTT

2) The server responds with its ”Server Hello” message that session key, and MAC will be based on the MD5 algorithm.
contains the CipherSuite chosen by the server from the Thus, to facilitate the KMIP authentication option, we must
list provided by the client, the session ID and another start by defining new cipher suites. Table 1 presents KMIP-
random byte string. In case of figure 6, the server TLS extension CipherSuits (see table 1).
response is sent just after the Client Hello as classical In order to establish a TLS session using KMIP security
TLS and since we don’t need the certificate verification parameters, one of the cited cipher suites in table 1 has to be
process and the session secret is already taken from the specified in the client hello message. If TLS sever supports
KMS server the client does’nt wait for server response the KMIP authentication option, the server hello message
and goes directly to step 3) as mentioned in figure 5. must be sent to the client to state and confirm the KMIP
Servers aware of the extension described here but not authentication option. The hello server message sent to the
wishing to use it, should gracefully revert to a classical client, will confirm the KMIP cipher suite selected by the
TLS handshake or decide not to proceed with the server. The Certificate request message will be eliminated
negotiation. since authentication is already done using the Client-KMS
3) The TLS Client sends the cipher spec to be used for Connection detailed in previous subsection. The client
encrypting subsequent message data. certificate will be eliminated for the same reason. The KMIP
4) The TLS client sends to the server a ”finished” message, option must be added to the ClientKeyExchange message and
which is encrypted with the secret key, indicating that ServerKeyExchange.
the client part of the handshake is complete.
5) The TLS server sends to the client a ”finished” message, As presented in figures 5 and 6, the message certifi-
which is encrypted with the secret key, indicating that cate is ommited. The KMIP option must be added to the
the server part of the handshake is complete. ServerKeyExchange message as below:
struct
Finally, the finished messages are used to complete the { select (KeyExchangeAlgorithm)
handshake and to establish the TLS session normally. For { case KMIP: KMIPWrapper;
the rest of TLS session, the server and the client can /*new addition*/ };
now exchange messages that are symmetrically encrypted } ServerKeyExchange;
with the shared secret key already taken from the KMIP server.
struct
In order to achieve the addition of KMIP specifications { opaque KMIP Key ; /* KMIP key */ }
to TLS protocol, we focus now on client to server TLS KMIPWrapper;
connection. The client uses retrievd data to make client-server
connection. Throught this extension, we refer to the basic TLS The KMIP option must be added to the ClientKeyExchange
protocol version 1.2[4]. The TLS security session parameters message as below:
are negotiated and fixed via Hello messages. Always in TLS, struct
we define CipherSuit like: T LS − RSA − W IT H − RC4 − { select (KeyExchangeAlgorithm)
M D5 which means that the initial authentication will be done { case KMIP: KMIPWrapper;
using the RSA public key algorithm, RC4 will be used for the /* new addition Exchange keys */ }
 Ciphersuite Key Exchange Cipher Hash
TLS–KMIP–WITH –RC4 –128 –SHA KMIP RC4 –128 SHA
TLS–KMIP–WITH–AES–128–CBC–SHA KMIP AES–128–CBC SHA
TLS–KMIP–WITH–AES–256–CBC–SHA KMIP AES–256–CBC SHA
TLS–DHE–KMIP–WITH–RC4–128–SHA DHE–KMIP RC4–128 SHA
TLS–DHE–KMIP–WITH–3DES–EDE–CBC–SHA DHE–KMIP 3DES–EDE–CBC SHA
TLS–DHE–KMIP–WITH–AES–128–CBC–SHA DHE–KMIP AES–128–CBC SHA
TLS–DHE–KMIP–WITH–AES–256–CBC–SHA DHE–KMIP AES–256–CBC SHA
TLS–RSA–KMIP–WITH–RC4–128–SHA DHE–KMIP RC4–128 SHA
TLS–RSA–KMIP–WITH–3DES–EDE–CBC–SHA — DHE–KMIP 3DES–EDE–CBC SHA
TLS–RSA–KMIP–WITH–AES–128–CBC–SHA DHE–KMIP AES–128–CBC SHA
TLS–RSA–KMIP–WITH–AES–256–CBC–SHA DHE–KMIP AES–256–CBC SHA

Fig. 7: KMIP-TLS Ciphertext

ClientKeyExchange;

struct
{ opaque KMIP Key ;
/* KMIP key */ Alice (A, a), Bob (B,b): roles
opaque EncryptedPremasterSecret; H, PRF, KeyGen: hashfunc
/*encrypted with the key provided by KMIP */ Kmipa Kmipb: respectives public keys of Alice and Bob
}KMIPWrapper; send, receive: channels
N, Sid, PreMS: nonce, session id, pre-master secret
Using the KMIP option in TLS , we achieved the following start: starting function
advantages: the mutual authentication between TLS client Finished: the finished function of handshake protocol
and TLS server that has been delegated to a trusted third State 0: A —>B
party, which is the KMIP server. We note that the KMIP-TLS receive(start)
extension is seamlesly without adding new messages on TLS State 1: B —>A
protocol. Using this approach, we can ommit several messages {receive(Na, Sid, Pa)
on handshake subprotocol. This allows us to reduce latency send(Nb, Sid, Pa, Kmipb–(inv(Kmip))) }
and to make lightweight session renewal in TLS connection State 2: A —>B
which can be an important issue if there are many connections {receive(Nb, Sid, Pa, Kmipb–(inv(Kmip)))
requests such as the case of Cloud computing. send((PreMS–Kmipb. A.Kmipa
–(inv(Kmip)). H(Nb.B.PreMS)–(inv(Kmipa)).
C. Error messages H(PRF(PreMS.Na.Nb).A.B.Na.Pa.Sid) –
The table below introduces a new TLS error related to the KeyGen(A.Na.Nb.PRF(PreMS.Na. Nb))))}
KMIP-TLS extension: State 3: B —>A
{receive(Nb, Sid, Pa, Kmipb–(inv(Kmip))
Error message Description send((PreMS–Kmipb. A.Kmipa–(inv(Kmip)).
”bad-authen” This error MUST be sent by the server H(Nb.B.PreMS)–(inv(Kmipa)).
when it does’nt support the KMIP H(PRF(PreMS.Na.Nb).A.B.Na.Pa.Sid) textendash
authentication method. This error indicates KeyGen(A.Na.Nb.PRF(PreMS.Na.
the failure of client authentication Nb))))}
and it is always fatal. State 4: A —>B
{ receive(Finished–ServerK) }
IV. F ORMAL VALIDATION State 5: B —>A
In the rest of this paper, we focus on the formal validation { send(H(PRF(PreMS.Na.Nb). A.B.Na.Pa.Sid) –
of KMIP-TLS extension using Automated Validation of Trust KeyGen(B.Na.Nb.PRF(PreMS.Na.Nb)
and Security of Service-oriented Architectures (AVISPA tool). ))}
We specify the extended protocol with HLPSL langage. We
illustrate the session establishement between two actors (TLS Fig. 8: The security specifications of our extension in AVISPA
client: Alice and TLS server: Bob) that present the source host
(TLS client) and the destination host (TLS server) respectively.
Our proposal is represented with five steps as mentioned in the
 Fig. 9: AVISPA Validation

figure 8. The completeness and validity of our proposal was authentication between TLS client and server. Future works
verified by an AVISPA simulation (see figure 9). will focus on providing more experimental results about the
Our proposal is represented with six steps as mentioned imlpementations of presented extension using GNUTLS API.
in figure 8. TLS protocol proceeds between the client A and This proposal will be the subject of IETF RFC and the same
the server B with respective public keys Kmipa and Kmipb. extension will be discussed for TLS version 1.3.
These two actors generate nonces Na and Nb, respectively.
VI. ACKNOWLEDGMENT
In addition, we assume the existence of a trusted third party:
the certificate of KMIP server whose public key is Ks. Each This work has been supported by the IGDI-KMIP FUI17
session is identified by a unique Sid. The protocol also makes IGDCI (Infrastructure de Gestion et Distribution de Cles
use of a pseudo-random number generator PRF which we Interoprable) project sponsored by Systematic Paris-Region.
model as a hash function. In state 1 and 2 the Pa is a R EFERENCES
cryptosuite offer and Pb is server’s counteroffer. In state 2
[1] Kiran Thota, Kelley Burgin: Key Management Interoperability Protocol
and 3 we have the hello messages. In order to minimize the Specification Version 1.2, 19 May 2015
number of transitions specified, we have combined the sending [2] Tim Hudson , Robert Lockhart: Key Management Interoperability Proto-
of messages 1. and 2. as well as the sending of messages 3. col Profiles Version 1.2, OASIS Standard, 19 May 2015
[3] Advancing open standards for the information society, https://www.oasis-
4. 5. and 6. into single transitions (see figure 9). open.org/
The major advantage of our extension KMIP-TLS is its [4] T. Dierks, E. Rescorla: The Transport Layer Security (TLS) Protocol
ease of deployment since we don’t need changes to be Version 1.2, IETF (August 2008)
[5] B Medvinsky, A. and M. Hur: Addition of Kerberos Cipher Suites to
made to the application layer protocols. This extension is Transport Layer Security (TLS): RFC 2712: Network Working Group
fully compatible with existing TLS specifications without Request for Comments, October 1999
requirement to make any major changes to the TLS. It does’nt [6] Bhaskar Prasad Rimal, Eunmi Choi, Ian Lumb: A Taxonomy and Survey
of Cloud Computing Systems In: NCM ’09, pp. 44 - 51. IEEE , Seoul
impact communications of TLS entities that support this (2009)
extension with another TLS entities that do not. [7] Wayne Jansen, Timothy Grance: Guidelines on Security and Privacy in
Public Cloud Computing. Technical report, NIST Special Publication 800-
144 (2012)
[8] NIST group, Cloud Architecture Reference Models. Technical report: A
V. C ONCLUSION Survey, NIST CCRATWG 004 v2 (January 25, 2011 )
[9] MSAHLI, Mounira et SERHROUCHNI, Ahmed. SBaaS: Safe Box as
Currently, with the rapid growth of Cloud computing and a service. In: 9th International Conference Conference on Collaborative
the diversity of distributed applications and the multiplicity of Computing: Networking, Applications and Worksharing (Collaborate-
its actors, security has become a complex and urgent need com), p. 143-147, IEEE, Austin (2013)
[10] Mounira Msahli; Ahmed Serhrouchni: Profile centric modelling In:
to protect all possible exchanges between applications and International Journal of Internet Technology and Secured Transactions
entities. Many traditional and existing security protocols are (IJITST), Vol. 5, No. 4, p. 344-357, (2014)
not suitable for this context. Current solutions cannot offer [11] Automated Validation of Internet Security Protocols and Applications
(AVISPA), http://www.avispa-project.org/
required flexiblity and extendibility. In this paper, we tackle [12] Housley, R., Internet X.509 Public Key Infrastructure, RFC 2459:
authentication in Cloud computing. We propose the KMIP- Network Working Group Request for Comments, (January 1999)
TLS extension. In fact, we extend TLS to support KMIP [13] Eronen, P. and H. Tschofenig, Pre-Shared Key Ciphersuites for Transport
Layer Security (TLS), RFC 4279: Network Working Group Request for
authentication. The proposed extension was formally validated Comments, (December 2005)
with AVISPA tool. This extension inherits all security advan- [14] Stephen A. Thomas, SSL and TLS Essentials Securing the Web, Wiley
tages already provided by TLS such as: authentication and Computer Publishing, Canada (2000)
confidentiality. The deployed architecture introduces a third-
party auditing capability for TLS transactions without making
any changes to concerned applications. At the same time,
proposed extension allows to improve TLS latency so we
reduce handshake latency to 0-RTT for repeated handshakes
and 1-RTT for full handshake and we have always a mutual