Networking Working Group Nouha Oualha Mounir Kellil Christophe Janneteau Internet Draft CEA, LIST Intended status: Standards Track June 24, 2013 Expires: December 2013 Extending Multimedia Internet KEYing (MIKEY) protocol for use in constrained networks draft-oualha-mikey-ext-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 24, 2013. Oualha Expires December 24, 2013 [Page 1] Internet-Draft Extending MIKEY for use in LLNs June 2013 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. Abstract The Multimedia Internet KEYing (MIKEY) protocol is a key management standard defined in RFC 3830 for streaming and real-time applications. In these applications, the MIKEY protocol may be used to provide group key management. With the base protocol, the change of one group member triggers the unicast transmission of a new group key to all members. In the context of an application delivering multicast streams to end-users located at multiple capillary networks, the key update messages may scale in proportion to the number of nodes; thus creating a substantial overhead. This I-D proposes an extension to the MIKEY protocol allowing the management of the group as a set of clusters, but with fewer changes to the RFC 3830 standard. Clustering helps in reducing the communication overhead produced during key update by using unicast mode only with nodes that belong to clusters where group membership changes Table of Contents 1. Introduction ................................................ 3 1.1. Terminology and definitions ............................. 3 1.1.1. Definitions ........................................ 3 1.1.2. Abbreviations ...................................... 4 1.1.3. Rationale ......................................... 4 1.1.4. Outline ........................................... 5 2. Clustering-based approach overview ........................... 5 2.1. Context ................................................ 5 2.2. Description ............................................ 5 2.2.1. Demonstrative example .............................. 6 3. Extension elements to MIKEY .................................. 7 4. Security Considerations ...................................... 7 5. IANA Considerations ......................................... 7 6. References .................................................. 8 6.1. Normative References .................................... 8 6.2. Informative References .................................. 9 Oualha Expires December 24, 2013 [Page 2] Internet-Draft Extending MIKEY for use in LLNs June 2013 1. Introduction The Multimedia Internet KEYing (MIKEY) protocol [RFC3830] is a key management standard that has been designed to be easily integrated with the existing security protocols. The extensions proposed for this protocol (like [RFC4650], [RFC4738], [RFC5197], [RFC6043], and [RFC6267]) focus mainly on providing different encryption modes and algorithms to be used by the protocol. Other efforts have recently been undertaken (e.g., [I-D.ietf-roll-mikey-lln-key-mgmt]) to lighten the protocol in order to extend the applicability of the protocol to resource constrained-device networks. To further adapt MIKEY to these networks, we propose a group-clustering-based approach that uses unicast mode only within a cluster of nodes of the group whenever group key update is needed. The approach requires few changes to the base MIKEY protocol. 1.1. Terminology and definitions The following gives the definitions and abbreviations that are mostly a remainder from [RFC3830]. 1.1.1. Definitions (Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP. Data Security Association (Data SA): information for the security protocol, including a TEK and a set of parameters/policies. Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TGKs and security parameters. Crypto Session ID: unique identifier for the CS within a CSB. Crypto Session Bundle ID (CSB ID): unique identifier for the CSB. TEK Generation Key (TGK): a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-encrypting Keys can then be generated without needing further communication. Traffic-Encrypting Key (TEK): the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK. Oualha Expires December 24, 2013 [Page 3] Internet-Draft Extending MIKEY for use in LLNs June 2013 Key Index: The Key Index (KI) is used as identifier to allow referencing the key(s) that are associated with a given CS. Each TGK is associated with a KI as defined in [I-D.ietf-roll-mikey-lln-key- mgmt]. TGK re-keying: the process of re-negotiating/updating the TGK (and consequently future TEK(s)). Initiator: the initiator of the key management protocol, not necessarily the initiator of the communication. Responder: the responder in the key management protocol. 1.1.2. Abbreviations CS Crypto Session CSB Crypto Session Bundle DoS Denial of Service KI Key Index MAC Message Authentication Code MIKEY Multimedia Internet KEYing PK Public-Key PSK Pre-Shared key RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP TEK Traffic-encrypting key TGK TEK Generation Key 1.1.3. Rationale The approach proposed in this I-D is intended for networks that are composed of resource constrained devices. Examples of such networks are wireless sensor networks or multiple of these networks receiving the same streaming content. Devices in these networks are generally large in number, but they can be divided into multiple clusters where they are highly correlated to each other (e.g., by type or by location). The dynamics of devices (e.g., device join/leave to the group, failure) could be different in these clusters. The proposed approach aims at MIKEY objective to establish a security association and keys for a security protocol like SRTP. It extends the base MIKEY protocol by considering the group divided into multiple clusters based on group members' dynamics. The group clustering reduces the communication overhead caused by group key updating due to members' dynamics, which contributed in unloading the constrained-network nodes. Oualha Expires December 24, 2013 [Page 4] Internet-Draft Extending MIKEY for use in LLNs June 2013 1.1.4. Outline Section 2. describes the context for which the approach is proposed. The section gives also an overview of the architecture that is considered and illustrates the main contribution of the approach using a demonstrative example. Section Erreur ! Source du renvoi introuvable.details the practical extensions and added elements to the base MIKEY protocol [RFC3830]. 2. Clustering-based approach overview This section gives an overview of the proposed approach. It first defines the context in which the approach can be applied. It then details the description of the approach pinpointing the changes proposed to the base MIKEY protocol. 2.1. Context The proposed approach uses the architecture of [RFC3740] composed of the group controller/key server (GCKS) and a group of sender/receiver nodes. The GCKS authenticates nodes. If nodes are authorized to receive or send the stream, they will be provided from the GCKS with the required keying materials. The approach assumes that the group of receiver nodes is divided into a number of clusters. The management of clusters is handed out to the GCKS. Since the GKCS is responsible of the issuance and management of cryptographic keys and also user-authentication and authorization checks, we can assume that this entity is responsible of affecting nodes to clusters based on their location, their mobility pattern, etc. For example, clusters may be mapped to the physical network topology: each cluster may correspond to a different capillary network. The assignment of nodes to clusters is out of the scope of this I-D. 2.2. Description The idea behind the proposed approach is summarized with the following: o The GCKS launches multiple instances of the MIKEY protocol. Each MIKEY protocol instance corresponds to a different cluster of receiver nodes (seen Figure 1). o Each cluster receives a set of TGKs. Subsets of these TGKs are shared with some other clusters. Additionally, each TGK is identified by the same KI along the different clusters. The GCKS ensures this dependency between the different protocol instances. Oualha Expires December 24, 2013 [Page 5] Internet-Draft Extending MIKEY for use in LLNs June 2013 o Key management is handled independently for each MIKEY instance; though the GCKS ensures that at all times, all clusters share at least one TGK that is used to establish common security associations for the underlying security protocol e.g., SRTP. o Whenever a node leaves or joins the group, the GCKS dynamically update the group key TGK, by synchronizing key update operation for each of the MIKEY protocol instances. The usual unicast key update is used for the cluster concerned with the membership change. On the other hand, the remaining clusters will update their security association based on the KI associated with the new shared TGK. +------------------+ | +----------+ | MIKEY({TGK, KI}) ............. | +->|MIKEY |<==============================>: Cluster 1 : | | |instance 1| | :...........: | | +----------+ | | | | | | +----------+ | MIKEY({TGK, KI}) ............. | |->|MIKEY |<==============================>: Cluster 2 : | | |instance 2| | :...........: | | +----------+ | | | | | |->... | ... | | | | | +----------+ | | +->|KEY mgmt. | | | |entity | | | +----------+ | | GCKS | +------------------+ Figure 1 The clustering-based approach 2.2.1. Demonstrative example Demonstrative example: We consider a group composed of two clusters C1 and C2 of identical size. The nodes in both clusters share a group key TGK1 and TGK2. Additionally, nodes in the cluster C1 (respectively C2) share an additional group key TGK3 (respectively TGK4) with the GCKS. At first, we assume TGK1 needs to be updated (e.g., because it has been compromised). In this case, nodes will be simply notified of the new group key, TGK2 that is shared by all nodes in the group, using the corresponding KI in the underlying security protocol. Later, we assume that a node from C2 leaves the group. This event triggers TGK key update. For the remaining members of C2, TGK3 is Oualha Expires December 24, 2013 [Page 6] Internet-Draft Extending MIKEY for use in LLNs June 2013 distributed based on the base MIKEY unicast mode. On the other hand, members of C1 will be notified of TGK update by simply using KI to identify the new group key TGK3 through the underlying security protocol. With this proposed approach, the communication overhead due to group key update is divided by 2, compared to the basic MIKEY protocol, thanks to the use of multiple instances of MIKEY. 3. Extension elements to MIKEY The proposed approach was thought in a way where changes to the base MIKEY protocol are limited. Since management of MIKEY instances is handled by the GCKS, the main transformation is carried out at this entity. No extra signaling is needed in the network. At the receiver node side, no transformation occurs, apart from the consideration of a KI to notify nodes of the update of the TGK key. The GCKS is in charge of launching MIKEY protocol instances for each of the different clusters. The GCKS must guarantee that these instances are synchronized and that they share the same group key TGK at all times. Each receiver node within the same cluster will share other TGK keys shared with nodes from some other clusters. The base MIKEY protocol does not provide TGK rekeying in the GKMARCH sense [RFC4046]. The MIKEY protocol is re-executed again and keys are updated using unicast messages. With the approach proposed in this I-D, TGK update uses the same procedure as the base MIKEY protocol for nodes in the cluster where membership changes occur. Otherwise, a notification of the change of the group key is performed at the underlying security protocol using the key index associated with the new group key. The decision of TGK update procedure is carried out by the GCKS that ensures synchronization between the different instances of MIKEY for the same group communication. 4. Security Considerations Since the proposed approach relies on multiple instances of the base MIKEY protocol, it does not perform significant changes to the base protocol, and rather focuses on the group architecture without impacting the security of the protocol. 5. IANA Considerations IANA is requested to record the pre-defined values defined in [RFC3830]. The name spaces for the new field Key index identified in [I-D.ietf-roll-mikey-lln-key-mgmt] are requested to be managed by IANA. Oualha Expires December 24, 2013 [Page 7] Internet-Draft Extending MIKEY for use in LLNs June 2013 6. References 6.1. Normative References [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and Norrman, K. "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC6407] Weis, B., Rowles, S., and Hardjono, T., "The Group Domain of Interpretation", RFC 6407, October 2011. [RFC4442] Fries, S. and Tschofenig, H., "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006. [RFC4563] Carrara, E., Lehtovirta, V., and Norrman, K., "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006. [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and Lin, P., "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006. [RFC5197] Fries, S. and Ignjatic, D., "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008. [RFC5410] Jerichow, A. and Piron, L., "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0", RFC 5410, January 2009. [RFC6043] Mattsson, J. and Tian, T., "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011. [RFC6267] Cakulev, V. and Sundaram, G., "MIKEY-IBAKE: Identity- Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6267, June 2011. [RFC3740] Hardjono, T. and Weis, B., "The Multicast Group Security Architecture", RFC 3740, March 2004. Oualha Expires December 24, 2013 [Page 8] Internet-Draft Extending MIKEY for use in LLNs June 2013 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F., "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4563] Carrara, E., Lehtovirta, V., and Norrman, K. "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", IETF RFC 4563, June 2006. 6.2. Informative References [I-D.ietf-roll-mikey-lln-key-mgmt] Alexander, R. and Tsao, T., "Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments", draft-alexander-roll-mikey-lln-key- mgmt-03, March 12, 2012. Oualha Expires December 24, 2013 [Page 9] Internet-Draft Extending MIKEY for use in LLNs June 2013 Authors' Addresses Nouha Oualha CEA, LIST CEA Saclay Nano-Innov Bat 862 - PC 173 - F91191 Gif sur Yvette Cedex France Email: nouha.oualha@cea.fr Mounir Kellil CEA, LIST CEA Saclay Nano-Innov Bat 862 - PC 173 - F91191 Gif sur Yvette Cedex France Email: mounir.kellil@cea.fr Christophe Janneteau CEA, LIST CEA Saclay Nano-Innov Bat 862 - PC 173 - F91191 Gif sur Yvette Cedex France Email: christophe.janneteau@cea.fr Oualha Expires December 24, 2013 [Page 10]