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]