oualha-mikey-ext-00.txt

Internet DRAFT - draft-oualha-mikey-ext

draft-oualha-mikey-ext

Last Version:	draft-oualha-mikey-ext-00.txt	Tracker Entry
Date:	`25-Jun-2013`
Disposition:	expired

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

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]