Internet Engineering Task Force Carrara, Lehtovirta, Norrman
(Ericsson)
INTERNET-DRAFT
EXPIRES: March 2006 September 2005
The Key ID Information Type for the General Extension Payload in MIKEY
<draft-ietf-msec-newtype-keyid-02.txt>
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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-DRAFT newtype-keyid September, 2005
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 document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This memo specifies a new Type (the Key ID Information Type) for the
General Extension Payload in the Multimedia Internet KEYing
Protocol. This is used in, e.g., the Multimedia Broadcast/Multicast
Service specified in the 3rd Generation Partnership Project.
TABLE OF CONTENTS
1. Introduction...................................................2
2. Rationale......................................................3
3. The Key ID Information Type for the General Extension Payload..4
4. The Key ID Information Type for the General Extension Payload..5
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Acknowledgements...............................................6
8. Author's Addresses.............................................7
9. References.....................................................7
1. Introduction
The 3rd 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 the multimedia that is multicast or
broadcast.
Carrara et al. [Page 2]
INTERNET-DRAFT newtype-keyid September, 2005
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 would be inconvenient for subscribers to publish the
decryption keys enabling non-subscribers to view the content. 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 key 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.
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), point-to-point key between the multicast
server and each client
* The MBMS Service Key (MSK), group key between the multicast server
and all the clients
* The MBMS Traffic Key (MTK), group traffic key between the
multicast server and all clients.
The Traffic Keys are the keys that are regularly updated.
The point-to-point MUK key (first-level key) is shared between the
multicast server and the client via means defined by MBMS [MBMS].
The MUK is used as pre-shared key to run MIKEY with the pre-shared
key method [RFC3830], to deliver (point-to-point) the MSK key. The
same MSK key is pushed to all the clients, to be used as a (second-
level) group key.
Then, the MSK is used to push to all the clients an MTK key (third-
level key), the actual group key that is used for the protection of
the media traffic. For example, the MTK could be the master key for
SRTP [3711] in the streaming case.
Carrara et al. [Page 3]
INTERNET-DRAFT newtype-keyid September, 2005
A Key Domain identifier defines the domain where the group keys are
valid or applicable. For example it may define a specific service
provider.
To allow the key distribution described above, an indication of the
type and identity of keys being carried in a MIKEY message is
needed. This indication is carried in a new Type of the General
Extension Payload in MIKEY.
It is necessary to specify what Crypto Session ID map type is
associated with a given key. There are cases, for example the
download case in MBMS, where the required parameters are signalled
in-band (each downloaded DCF-object [DCF] contains the necessary
parameters needed by the receiver to process the it). Since the
parameters are not transported by MIKEY, this implies that a CS ID
map type needs to be registered to the "empty map" as defined in
Table 3, which is to be used when the map/policy information is
conveyed outside of MIKEY.
3. The Key ID Information Type for the General Extension Payload
The General Extension payload in MIKEY is defined in Section 6.15 of
[RFC3830].
The Key ID Information Type (Type 3) formats the General Extension
payload as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Key ID Information General Extension Payload.
Next Payload and Length are defined in Section 6.15 of [RFC3830].
* Type (8 bits): identifies the type of the General Payload
[RFC3830]. This memo adds Type 3 to the ones already defined in
[RFC3830].
Type | Value | Comments
------------------------------------------------------------
Key ID | 3 | information on type and identity of keys
Carrara et al. [Page 4]
INTERNET-DRAFT newtype-keyid September, 2005
Table 1. Definition of the new General Extension Payload.
* Key ID Information (variable length): the general payload data
transporting the type and identifier of a key. This field is formed
by Key ID Type sub-payloads as specified below.
The Key ID Type sub-payload is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Type ! Key ID Length ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The Key ID Type sub-payload.
* Key ID Type (8 bits): describes the type of the key ID.
Predefined types are listed in Table 2.
Key ID Type | Value | Comment
--------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Transport Key ID | 2 | ID of the group traffic key
Table 2. Type definitions for Key IDs.
* Key ID Length (8 bits): describes the length of the Key ID
field in octets.
* Key ID (variable length): defines the identity of the key.
Note that there may be more than one Key ID Type sub-payload in an
extension, and that the overall length (i.e., the sum of lengths of
all Key ID Type sub-payloads) of the Key ID information field cannot
exceed 2^16 - 1 octets. Applications using this general extension
payload have to define the semantics and usage of the Key ID Type
sub-payloads.
4. The Key ID Information Type for the General Extension Payload
Carrara et al. [Page 5]
INTERNET-DRAFT newtype-keyid September, 2005
When the security policy information is conveyed outside of MIKEY,
the CS ID map type is set to value defined in Table 3 to indicate
"empty map".
CS ID map type | Value | Comments
------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
Table 3. Definition of the new CS ID map type.
5. Security Considerations
It is not anticipated that this memo will have any additional
security implications beyond those already identified for the MIKEY
protocol, see [RFC3830].
6. IANA Considerations
According to Section 10 of RFC 3830, IETF consensus is required to
register values in the range 0-240 in the Type namespace of the
MIKEY General Extension Payload and the CS ID map type namespace of
the Common Header Payload.
A new MIKEY General Extension Payload Type needs to be registered
for this purpose. The registered value for Key ID is requested to be
3 according to Section 3.
It is also requested to register the value 1 for the Empty map in
the CS ID map namespace of the Common Header Payload as specified in
Table 3 in Section 4.
The name space for the following field in the Key ID information
sub-payload (from Sections 3 and 4) is requested to be managed by
IANA:
* Key ID Type
It is requested that IANA register the pre-defined types of Table 2
for this namespace.
7. Acknowledgements
We would like to thank Fredrik Lindholm.
Carrara et al. [Page 6]
INTERNET-DRAFT newtype-keyid September, 2005
8. Author's Addresses
Questions and comments should be directed to the authors:
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@ericsson.com
Vesa Lehtovirta
Ericsson Research
02420 Jorvas Phone: +358 9 2993314
Finland EMail: vesa.lehtovirta@ericsson.com
Karl Norrman
Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@ericsson.com
9. References
Normative
[RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC
3830, August 2004.
Informative
[RFC3711] Baugher et al., "The Secure Real-time Transport Protocol
(SRTP)", RFC3711, March 2004.
[MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation
Partnership Project; Technical Specification Group Services and
System Aspects; Security; Security of Multimedia Broadcast/Multicast
Service."
[DCF] OMA, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0",
Candidate Version 2.0 - 29 March 2005
Carrara et al. [Page 7]
INTERNET-DRAFT newtype-keyid September, 2005
Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This draft expires in March 2006.
Carrara et al. [Page 8]
