Skip to main content

Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments
draft-alexander-roll-mikey-lln-key-mgmt-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
Authors Tzeta Tsao , Roger Alexander
Last updated 2011-07-26 (Latest revision 2011-07-12)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

Multimedia Internet Keying (MIKEY) is a key management protocol used for real-time applications. As standardized within RFC3830 it defines four key distribution methods, including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange, with allowances for ready protocol extension. A number of additional methods have been developed and continue to be built from the base protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility and more general applicability, MIKEY and its related extensions have primarily focused on the support of the Secure Real-time Transport Protocol (SRTP). This document specifies a simple adaptation of the MIKEY specification to allow the base protocol and its various key management mode extensions to be readily applied in more general environments beyond the multimedia SRTP domain. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure and introduces a set of message extensions to the base specification to allow the MIKEY key management methods to be applied within Low-power and Lossy networks (LLNs) and other general constrained-device networks.

Authors

Tzeta Tsao
Roger Alexander

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)