HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)
RFC 4650

 
Document Type RFC - Proposed Standard (September 2006; Errata)
Last updated 2013-03-02
Replaces draft-euchner-mikey-dhhmac
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4650 (Proposed Standard)
Telechat date
Responsible AD Russ Housley
Send notices to <canetti@watson.ibm.com>, <ldondeti@nortel.com>
Network Working Group                                         M. Euchner
Request for Comments: 4650                                September 2006
Category: Standards Track

                   HMAC-Authenticated Diffie-Hellman
                 for Multimedia Internet KEYing (MIKEY)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a lightweight point-to-point key management
   protocol variant for the multimedia Internet keying (MIKEY) protocol
   MIKEY, as defined in RFC 3830.  In particular, this variant deploys
   the classic Diffie-Hellman key agreement protocol for key
   establishment featuring perfect forward secrecy in conjunction with a
   keyed hash message authentication code for achieving mutual
   authentication and message integrity of the key management messages
   exchanged.  This protocol addresses the security and performance
   constraints of multimedia key management in MIKEY.

Euchner                     Standards Track                     [Page 1]
RFC 4650      HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

Table of Contents

   1. Introduction ....................................................2
      1.1. Definitions ................................................5
      1.2. Abbreviations ..............................................6
      1.3. Conventions Used in This Document ..........................7
   2. Scenario ........................................................7
      2.1. Applicability ..............................................7
      2.2. Relation to GKMARCH ........................................8
   3. DHHMAC Security Protocol ........................................8
      3.1. TGK Re-keying .............................................10
   4. DHHMAC Payload Formats .........................................10
      4.1.  Common Header Payload (HDR) ..............................11
      4.2. Key Data Transport Payload (KEMAC) ........................12
      4.3. ID Payload (ID) ...........................................12
      4.4. General Extension Payload .................................12
   5. Security Considerations ........................................13
      5.1. Security Environment ......................................13
      5.2. Threat Model ..............................................13
      5.3. Security Features and Properties ..........................15
      5.4. Assumptions ...............................................19
      5.5. Residual Risk .............................................20
      5.6. Authorization and Trust Model .............................21
   6. Acknowledgments ................................................21
   7. IANA Considerations ............................................22
   8. References .....................................................22
      8.1. Normative References ......................................22
      8.2. Informative References ....................................22
   Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25

1.  Introduction

   There is work done in IETF to develop key management schemes.  For
   example, IKE [12] is a widely accepted unicast scheme for IPsec, and
   the MSEC WG is developing other schemes, addressed to group
   communication [17], [18].  For reasons discussed below, there is,
   however, a need for a scheme with low latency, suitable for demanding
   cases such as real-time data over heterogeneous networks and small
   interactive groups.

   As pointed out in MIKEY (see [2]), secure real-time multimedia
   applications demand a particular adequate lightweight key management
   scheme that takes care to establish dynamic session keys securely and
   efficiently in a conversational multimedia scenario.

   In general, MIKEY scenarios cover peer-to-peer, simple one-to-many,
   and small-sized groups.  MIKEY in particular describes three key

Euchner                     Standards Track                     [Page 2]
RFC 4650      HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

   management schemes for the peer-to-peer case that all finish their
   task within one roundtrip:

   -  a symmetric key distribution protocol (MIKEY-PS) based on pre-
      shared master keys

   -  a public-key encryption-based key distribution protocol (MIKEY-PK
Show full document text