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]
datatracker.ietf.org