Internet DRAFT - draft-olivereau-sake-mikey-ticket
draft-olivereau-sake-mikey-ticket
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.
Olivereau, et al. Expires April 24, 2014 [Page 1]
Internet-Draft -sake-mikey-ticket October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. MIKEY-TICKET Overview . . . . . . . . . . . . . . . . . . . . 4
4. New Mode Proposal . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Replay attack . . . . . . . . . . . . . . . . . . . . . . 9
5.2. DoS attack . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Man In The Middle (MITM) attack . . . . . . . . . . . . . 9
5.4. Key escrow attack . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Olivereau, et al. Expires April 24, 2014 [Page 2]
Internet-Draft -sake-mikey-ticket October 2013
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
Olivereau, et al. Expires April 24, 2014 [Page 3]
Internet-Draft -sake-mikey-ticket October 2013
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.
As depicted in Figure 1, MIKEY-Ticket relies on six messages to
establish a new key between I and R.
+---+ +-----+ +---+
| 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)
(1) REQUEST_INIT from I to KMS
Olivereau, et al. Expires April 24, 2014 [Page 4]
Internet-Draft -sake-mikey-ticket October 2013
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.
Olivereau, et al. Expires April 24, 2014 [Page 5]
Internet-Draft -sake-mikey-ticket October 2013
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
Olivereau, et al. Expires April 24, 2014 [Page 6]
Internet-Draft -sake-mikey-ticket October 2013
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)}
Olivereau, et al. Expires April 24, 2014 [Page 7]
Internet-Draft -sake-mikey-ticket October 2013
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.
Olivereau, et al. Expires April 24, 2014 [Page 8]
Internet-Draft -sake-mikey-ticket October 2013
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
Olivereau, et al. Expires April 24, 2014 [Page 9]
Internet-Draft -sake-mikey-ticket October 2013
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
Olivereau, et al. Expires April 24, 2014 [Page 10]
Internet-Draft -sake-mikey-ticket October 2013
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
Olivereau, et al. Expires April 24, 2014 [Page 11]
