CoRE Working Group A. Olivereau
Internet-Draft A. Boudguiga
Intended status: Informational N. Oualha
Expires: April 24, 2014 CEA
October 21, 2013

Server-Assisted Key Exchange (SAKE): A new mode for MIKEY-TICKET
draft-olivereau-sake-mikey-ticket-00

Abstract

A key establishment protocol intended to run between constrained devices has to be both lightweight and secure. Among the existing key establishment families (key agreement, key transport, server-assisted key transport or key distribution), the latter is the best candidate for constrained devices, since it can keep cryptographic operations simple at nodes sides. Nevertheless, most key distribution protocols exhibit an asymmetric design, since they are supposed to run between devices playing well-defined client and server roles, implying different security assumptions between the devices involved in the exchange.

MIKEY-Ticket is a key distribution protocol that specifies new modes for the Multimedia Internet KEYing (MIKEY) protocol. It answers situations where the network contains a trusted third party (one or multiple trusted key management servers). The general MIKEY-Ticket mode is a key distribution scheme relying on six messages exchanged between the node initiating the protocol (Initiator), the Key Management Server (KMS) and the responding node (Responder). This general mode assumes that the two parties establishing a key with each other play similar roles, with the only exception that one is the Initiator and the other one the Responder.

However, this mode suffers from a risk of a Denial of Service (DoS) inherited from the protocol design. In addition, the protocol syntax involves very large messages that would have to be fragmented, and would therefore not be convenient to communications between constrained nodes. In this document, we propose a new MIKEY-Ticket mode that solves the risk of DoS during the key establishment between the Initiator and the Responder, relies on a 5-message exchange instead of a 6-message one and bases on a simplified syntax, leading to lighter messages.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 24, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Key establishment protocols serve to establish a secret key between two communicating entities. These entities do not necessarily share common credentials before starting a key management session. In practice, key establishment methods either rely on a key agreement protocol such as the Diffie-Hellman (DH) exchange, or pass through a Trusted Third Party (TTP) in a key transport protocol. Key agreement protocols assume that the communicating entities share a common secret or are able to use public key cryptography. However, in key transport protocols, the TTP is in charge of deriving and securely transporting a symmetric key to the two communicating parties. This approach is more suitable to constrained devices.

The MIKEY-TICKET [RFC6043] specification describes a key transport protocol which relies on a TTP called the Key Management Server (KMS). MIKEY-TICKET was initially defined to enhance the Multimedia Internet KEYing protocol [RFC3830] by adding new modes of key distribution. These modes are adapted to centralized deployment scenarios where two entities called the Initiator and the Responder establish a shared key by passing through the KMS.

We present in this draft a new mode for the MIKEY-TICKET protocol. We will be focusing on the first (PSK) variant of MIKEY-TICKET which relies on pre-shared keys between the Initiator or the Responder, and the KMS. We do not consider the second, public key (PK) variant of MIKEY-TICKET, which relies on the much heavier asymmetric cryptography.

2. Terminology

2.1. Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2.2. Definitions

KDF: Key Derivation Function

I: Initiator

Initiator: the node that starts the key establishment protocol.

KMS: Key Management Sever. It is in charge of deriving the MPK for the initiator and the responder.

MAC: Message Authentication Code

MPK: MIKEY Protection Key.

R: Responder

Responder: the sensor that participates to the key establishment protocol.

3. MIKEY-TICKET Overview

In its first variant which is the only one considered throughout this draft, MIKEY-Ticket assumes that each one of the two parties (X) involved in the MIKEY-TICKET exchange is sharing with the KMS a secret master key K_X. From K_X, two keys Ke_X and Ka_X are derived. Ke_X is used to provide confidentiality through the encryption of sensitive data. Ka_X is used to provide data authenticity by computing Messages authentication Codes (MAC). Eventually the initiator (I) and the responder (R) are sharing with the KMS the tuples of keys {K_I, Ke_I, Ka_I} and {K_R, Ke_R, Ka_R}, respectively.

   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
             (1) REQUEST_INIT
     -------------------------------->
             (2) REQUEST_RESP
     <--------------------------------
                             (3) TRANSFER_INIT
     ---------------------------------------------------------------->
                                              (4) RESOLVE_INIT
                                     <--------------------------------
                                              (5) RESOLVE_RESP
                                     -------------------------------->
                             (6) TRANSFER_RESP
     <----------------------------------------------------------------

Figure 1: MIKEY-Ticket exchange (source: RFC6043)

As depicted in Figure 1, MIKEY-Ticket relies on six messages to establish a new key between I and R.

(1)
REQUEST_INIT from I to KMS
I starts the protocol by sending the REQUEST_INIT message to the KMS. This message contains information about the identity of R, a nonce (i.e. a random number, a timestamp or a sequence number) to avoid replay attacks and a MAC computed with Ka_I.
The validity of this MAC is verified by the KMS at the reception of this first message. Then, the KMS generates K_IR, the key to be shared between I and R, and responds with the REQUEST_RESP message.
(2)
REQUEST_RESP from KMS to I
This message contains the ticket (TICKET), the encryption of K_IR with Ke_I and a MAC computed with Ka_I.
At the reception of the REQUEST_RESP message, I verifies the validity of the MAC. Then, it decrypts and recovers K_IR. K_IR is then used to derive two keys Ke_IR and Ka_IR (for more details about key derivation and messages content, please refer to [RFC6043]). Ke_IR serves to encrypt data between I and R while Ka_IR provides data integrity through MAC computing. The ticket is then transferred from I to R in the TRANFER_INIT message.
(3)
TRANFER_INIT from I to R
Note that this message contains a MAC computed with the key Ka_IR.
At the reception of TRANSFER_INIT, R does not verify the MAC computed by I because R has not yet received the key K_IR. Consequently, R sends to the KMS the RESOLVE_INIT message to request K_IR.
(4)
RESOLVE_INIT from R to KMS
R includes in that message the ticket, in order to identify the current MIKEY-Ticket session initiated by I. The message also contains a MAC computed with Ka_R.
After verifying the MAC value of RESOLVE_INIT, the KMS responds to R with the RESOLVE_RESP message.
(5)
RESOLVE_RESP from KMS to R
This message which contains the encryption of K_IR with Ke_R and a MAC computed with Ka_R.
After verification of that MAC and decryption of K_IR, R is in possession of the key K_IR and can derive Ke_IR and Ka_IR. It can then verify the MAC value that had been received in the TRANFER_INIT message. If this MAC is valid, R sends to I the TRANSFER_RESP message to acknowledge not only the good reception of K_IR but also the successful derivation of Ka_IR and Ke_IR.
(6)
TRANSFER_RESP from R to I
This message concludes the exchange by proving to I the knowledge of K_IR by R.

4. New Mode Proposal

4.1. Overview

We assume, as for MIKEY-Ticket, that I and R are sharing with the KMS the tuples of keys {K_I, Ke_I, Ka_I} and {K_R, Ke_R, Ka_R}, respectively.

The essential design choice in the current proposal is to involve the KMS in message exchanges as much as possible, in order to benefit from from the pre-established security contexts is has with both I and R.

4.2. Exchanges

The proposed new mode is started by I and contains five exchanges as presented in Figure 2:

   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
             (1) REQUEST_INIT
     -------------------------------->
                                           (2) RESOLVE_PUSH_INIT
                                     -------------------------------->
                                           (3) RESOLVE_PUSH_RESP
                                     <--------------------------------
             (4) REQUEST_RESP
     <--------------------------------
                            (5) TRANSFER_SYNTH
     ---------------------------------------------------------------->

Figure 2: New mode exchange

(1)
REQUEST_INIT from I to KMS
I generates a random nonce N_I and concatenates it to its identifier (ID_I ), the identifier of the KMS (ID_KMS) and the identifier of R (ID_R). In addition, I adds to the REQUEST_INIT message a MAC computed with Ka_I over the elements sent in clear, namely (ID_I, ID_KMS, ID_R, N_I).
Upon receiving the REQUEST_INIT message, the KMS checks the freshness of the nonce N_I to ensure that the message is not being replayed by an attacker. Then, the KMS validates the MAC. If it is authentic, the KMS sends the RESOLVE_PUH_INIT message to R.
(2)
RESOLVE_PUSH_INIT from KMS to R
First, the KMS generates a master session key K_IR to be subsequently used to secure communications between I and R. Then, it encrypts this key with the encryption key it shares with R (Ke_R). The result is concatenated to the identifiers (ID_KMS, ID_I, ID_R ), to the nonce N_I and to a MAC computed with Ka_R to form the RESOLVE_PUSH_INIT message, which is then sent to R.
Upon reception of the RESOLVE_PUSH_INIT message, R verifies the freshness of the nonce N_I which will be also serving as a session identifier. Then, R checks the validity of the MAC received from the KMS. If the message is fresh and valid, R uses its encryption key Ke_R to decrypt and recover K_IR.
(3)
RESOLVE_PUSH_RESP from R to KMS
R generates a random nonce N_R. Then, it uses K_IR and a key derivation function (KDF) to derive a pair of keys (Ke_IR, Ka_IR). The first key, Ke_IR, is used to encrypt data exchanged with I. The second key, Ka_IR, is used to compute MAC over the messages exchanged with I. KDF can be, for example, the HMAC_SHA256() function which outputs 256-bit long keys [RFC2104]. The KDF is fed with the key K_IR, the identifiers and the nonces of I and R, and a unique distinguishing string. That distinguishing string ensures that encryption and integrity keys will be different. That is, Ke_IR and and Ka_IR will respectively be computed as follows:
  • Ke_IR = KDF{K_IR,(ID_I,ID_R,N_I,N_R,Encryption-Key-Distinguisher)}
  • Ka_IR = KDF{K_IR,(ID_I,ID_R,N_I,N_R,Authenticity-Key-Distinguisher)}

Within RESOLVE_PUSH_RESP message, R also includes two MAC values related to the identifiers ID_R and ID_KMS, and the nonces N_I and N_R. The first MAC is computed with Ka_IR over the nonces N_I and N_R and is sent to I via the KMS. This MAC will be received by I as the proof of the good reception of K_IR by R. The second MAC is computed with Ka_R over the content of the RESOLVE_PUSH_RESP message and is used to provide message integrity. Then, the RESOLVE_PUSH_RESP message is sent to the KMS. Upon receiving it, the KMS checks the freshness of the nonce N_R. Then, it checks the validity of the MAC computed with Ka_R. If the MAC value is valid, the KMS sends the REQUEST_RESP message to I.
(4)
REQUEST_RESP from KMS to I
The KMS includes in that message the identifiers ID_I and ID_KMS, the nonces N_I and N_R, the MAC received from R in the RESOLVE_PUSH_RESP message and intended to I, the encryption of K_IR with Ke_I and a MAC computed with Ka_I over the aforementioned fields.
Upon reception of that message, I checks the freshness of N_I and verifies the validity of the MAC computed by the KMS. Then, I decrypts and recovers K_IR. Afterwards, I derives the two keys Ke_IR and and Ka_IR using KDF. KDF is the same key derivation function as used by R upon reception of K_IR. At this point, I computes with Ka_IR a MAC over N_I and N_R and compares it to the one sent by R via the KMS. If the two MAC values match, I authenticates R as the owner of Ka_IR and hence as the owner of K_IR and Ke_IR. Consequently, I generates the next TRANSFER_SYNTH message to acknowledge to R the good reception of the proof of K_IR knowledge and thereby close the session.
(5)
TRANSFER_SYNTH from I to R
I includes in that message the identifiers ID_I and ID_R, the nonces N_I and N_R and a MAC computed with Ka_IR over the aforementioned fields.
Upon reception of that message, it is sufficient for R to check the validity of the MAC to know that I has successfully received K_IR.

4.3. Syntax

TBD.

5. Security Considerations

5.1. Replay attack

To avoid Replay attacks, we make use of nonces (N_I and N_R). We assume that the nonces are at least 128 bits long. As a consequence, the probability of getting the same random number twice for two different sessions is equal to 1/2^128. In addition, when we use nonces, we impose that each node stores the list of nonces already used and checks the nonce of each received message against this list. As such, any replayed message will be detected thanks to the presence of its nonce in the receiver's list of nonces. Replayed messages have to be dropped by the receiver. However, when the number of detected replays exceeds a certain threshold during a given slot of time, the network administrator has to be informed about the threat of presence of a malicious node.

To get rid of the nonces storage issue, timestamps can be used to provide message freshness but other issues like nodes synchronization during timestamps verification may then arise.

5.2. DoS attack

As each message of SAKE contains a MAC computed with a key shared with the receiver, the DoS attack risk is reduced. That is, a peer will not engage on encrypting or decrypting some data without verifying the MAC value of the received message. As such, each entity identifies its communication peers before starting any memory and/or energy consuming operation.

5.3. Man In The Middle (MITM) attack

As the four first exchanges of SAKE pass through the KMS, an attacker can not realize a MITM attack. Indeed, the attacker would need to know the keys shared between I and KMS or R and KMS in order to realize a MITM attack, while these keys are secret. As such, MITM is not feasible against the proposed mode.

5.4. Key escrow attack

The KMS is the only node capable of realizing a key escrow attack as it is in charge of generating I and R shared key. However, the KMS is assumed to be a trusted party. That is, the KMS will not attempt to impersonate a legitimate node.

6. Acknowledgements

This work is part of the European project TWISNet (Trustworthy Wireless Industrial Sensor Network, FP7-ICT-STREP, contract No. 258280) and is totally funded by the European Union

7. IANA Considerations

This memo includes no request to IANA.

8. References

8.1. Normative References

[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.

8.2. Informative References

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

Alexis Olivereau CEA CEA Saclay-Nano-INNOV, Batiment 862 Gif-sur-Yvette Cedex, 91191 FR Phone: +33 169089233 EMail: alexis.olivereau@cea.fr
Aymen Boudguiga CEA CEA Saclay-Nano-INNOV, Batiment 862 Gif-sur-Yvette Cedex, 91191 FR Phone: +33 169086357 EMail: aymen.boudguiga@cea.fr
Nouha Oualha CEA CEA Saclay-Nano-INNOV, Batiment 862 Gif-sur-Yvette Cedex, 91191 FR Phone: +33 169084625 EMail: nouha.oualha@cea.fr