datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
RFC 4563

Document type: RFC - Proposed Standard (June 2006; No errata)
Updated by RFC 6309
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4563 (Proposed Standard)
Responsible AD: Russ Housley
Send notices to: canetti@watson.ibm.com, ldondeti@qualcomm.com

Network Working Group                                         E. Carrara
Request for Comments: 4563                                           KTH
Category: Standards Track                                  V. Lehtovirta
                                                              K. Norrman
                                                                Ericsson
                                                               June 2006

   The Key ID Information Type for the General Extension Payload in
                   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 memo specifies a new Type (the Key ID Information Type) for the
   General Extension Payload in the Multimedia Internet KEYing (MIKEY)
   Protocol.  This is used in, for example, the Multimedia
   Broadcast/Multicast Service specified in the Third Generation
   Partnership Project.

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Rationale .......................................................2
   3. Relations to MIKEY and GKMARCH ..................................3
   4. The Key ID Information Type for the General Extension Payload ...4
   5. Empty Map Type Definition for the CS ID Map Type ................5
   6. Transport Considerations ........................................5
   7. Security Considerations .........................................5
   8. IANA Considerations .............................................7
   9. Acknowledgements ................................................7
   10. References .....................................................8
      10.1. Normative References ......................................8
      10.2. Informative References ....................................8

Carrara, et al.             Standards Track                     [Page 1]
RFC 4563          Key ID for General Extension Payload         June 2006

1.  Introduction

   The Third Generation Partnership Project (3GPP) is currently involved
   in the development of a multicast and broadcast service, the
   Multimedia Broadcast/Multicast Service (MBMS), and its security
   architecture [MBMS].

   [MBMS] requires the use of the Multimedia Internet KEYing (MIKEY)
   Protocol [RFC3830] to convey the keys and related security parameters
   needed to secure multimedia that is multicast or broadcast.

   One of the requirements that MBMS puts on security is the ability to
   perform frequent updates of the keys.  The rationale behind this is
   that it will be costly for subscribers to re-distribute the
   decryption keys to non-subscribers.  The cost for re-distributing the
   keys using the unicast channel should be higher than the cost of
   purchasing the keys for this scheme to have an effect.  To implement
   this, MBMS uses a three-level key management, to distribute group
   keys to the clients, and be able to re-key by pushing down a new
   group key.  As illustrated in the section below, MBMS has the need to
   identify which types of keys are involved in the MIKEY message and
   their identity.

   This memo specifies a new Type for the General Extension Payload in
   MIKEY, to identify the type and identity of keys involved.

1.1.  Conventions Used in This Document

   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 RFC 2119 [RFC2119].

2.  Rationale

   An application where this extension is used is MBMS key management.
   The key management solution adopted by MBMS uses three-level key
   management.  The keys are used in the way described below.  "Clients"
   refers to the clients who have subscribed to a given
   multicast/broadcast service.

   * The MBMS User Key (MUK), a point-to-point key between the multicast
     server and each client.

   * The MBMS Service Key (MSK), a group key between the multicast
     server and all the clients.

   * The MBMS Traffic Key (MTK), a group traffic key between the
     multicast server and all clients.

Carrara, et al.             Standards Track                     [Page 2]

[include full document text]