| 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
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.
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 (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.
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.
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].
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.
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.
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.
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
TBD.
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.
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.
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.
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.
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
This memo includes no request to IANA.
| [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. |
| [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. |