summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5410.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5410.txt')
-rw-r--r--doc/rfc/rfc5410.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5410.txt b/doc/rfc/rfc5410.txt
new file mode 100644
index 0000000..34a8455
--- /dev/null
+++ b/doc/rfc/rfc5410.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group A. Jerichow, Ed.
+Request for Comments: 5410 Nokia Siemens Networks
+Obsoletes: 4909 L. Piron
+Category: Informational Nagravision S.A.
+ January 2009
+
+
+ Multimedia Internet KEYing (MIKEY) General Extension Payload
+ for Open Mobile Alliance BCAST 1.0
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
+ license-info) in effect on the date of publication of this document.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ This document specifies a new Multimedia Internet KEYing (MIKEY)
+ General Extension payload to transport the short-term key message
+ (STKM) and long-term key message (LTKM) payloads as well as the
+ management data LTKM reporting message and parental control message
+ payloads defined in the Open Mobile Alliance's (OMA) Broadcast
+ (BCAST) group's Service and Content protection specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 1]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3
+ 4. Interoperability Considerations . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Changes since RFC 4909 . . . . . . . . . . . . . . . . . . . . 5
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ The Multimedia Internet KEYing (MIKEY) protocol specification (RFC
+ 3830 [RFC3830]) defines a General Extension payload to allow possible
+ extensions to MIKEY without having to allocate a new payload type.
+ The General Extension payload can be used in any MIKEY message and is
+ part of the authenticated/signed data part. There is an 8-bit type
+ field in that payload. The type code assignment is IANA-managed, and
+ RFC 3830 requires IETF consensus for assignments from the public
+ range of 0-240.
+
+ The Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service
+ and Content Protection specification [SPCP] specifies the use of a
+ short-term key message (STKM), a long-term key message (LTKM), an
+ LTKM reporting message, and a parental control message that carry
+ attributes related to Service and Content protection. Note that any
+ keys associated with the attributes, such as the Parental Control
+ Pincode if present, are part of the MIKEY KEMAC payload.
+
+ This document specifies the use of the General Extension payload of
+ MIKEY to carry the messages mentioned above, as well as protection of
+ the credentials using mechanisms supported by MIKEY with
+ modifications in [RFC3830].
+
+ RFC 3830 [RFC3830], the MIKEY General Extension payload defined in
+ RFC 4563 [RFC4563], and the 3rd Generation Partnership Project
+ (3GPP)'s Multimedia Broadcast/ Multicast Service (MBMS) document
+ [3GPP.33.246] specify the transport of MIKEY messages via unicast or
+ broadcast; the OMA BCAST specifications use either for transport of
+ MIKEY messages.
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 2]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+2. Terminology
+
+ 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].
+
+ OMA BCAST MIKEY General Extension: We refer to the General Extension
+ type -- 5 -- as the OMA BCAST MIKEY General Extension.
+
+3. MIKEY General Extension for OMA BCAST Usage
+
+ The OMA BCAST Type (Type 5) formats the MIKEY 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 !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! OMA BCAST Data Subtype (variable length) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: OMA BCAST MIKEY General Extension
+
+ Next Payload and Length are defined in Section 6.15 of [RFC3830].
+
+ Type (8 bits): identifies the type of the General Extension Payload
+ (see Section 6.15 of [RFC3830]). This document adds a new type. It
+ specifies the use of Type 5 for OMA BCAST Service and Content
+ Protection using the Smartcard Profile.
+
+ Type | Value | Comments
+ ------------------------------------------------------------------
+ OMA BCAST | 5 | information on type and identity of messages
+
+ Figure 2: Definition of the OMA BCAST MIKEY General Extension Payload
+
+ OMA BCAST Data Subtype (variable length): defines a variable length
+ Data field. This field is formed by subtype-payloads. The contents
+ of the variable length OMA BCAST Data Subtype field are defined
+ below.
+
+
+
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 3]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Subtype ! Subtype Specific Data (variable length) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: STKM/LTKM/LTKM Reporting/Parental Control Subtype Payload
+
+ Subtype: 8 bits. This field indicates the subtype of the OMA
+ BCAST payload. In this specification, four values are specified:
+ LTKM (1), STKM (2), LTKM Reporting (3), and Parental Control (4).
+
+ Subtype Specific Data: Variable length.
+
+ OMA BCAST Data Subtype | Value | Comment
+ -----------------------------------------------------------
+ LTKM | 1 | Long Term Key Message
+ STKM | 2 | Short Term Key Message
+ LTKM Reporting | 3 | LTKM Reporting Message
+ Parental Control | 4 | Parental Control Message
+
+ Figure 4: Subtype Definitions for OMA BCAST Messages
+
+ The contents of the OMA BCAST Data Subtype payload field are defined
+ in Section 6 of the OMA BCAST Service and Content Protection
+ specification [SPCP].
+
+4. Interoperability Considerations
+
+ This document specifies the use of MIKEY General Extension payload
+ Type 5 and four subtype values: 1 and 2 for OMA BCAST Service and
+ Content protection's LTKM and STKM payloads (respectively), 3 for
+ LTKM Reporting payload, and 4 for Parental Control payload.
+ Interoperability considerations span several standards bodies, with
+ OMA BCAST 1.0 enabler compliance being the key aspect; as such, it is
+ up to the OMA test planning to verify the interoperability and
+ compliance of OMA BCAST 1.0 implementations. This payload type
+ assignment does not change MIKEY beyond RFC 3830 [RFC3830] and RFC
+ 4563 [RFC4563].
+
+5. Security Considerations
+
+ According to RFC 3830 [RFC3830], the General Extension payload can be
+ used in any MIKEY message and is part of the authenticated/signed
+ data part. The parameters proposed to be included in the OMA BCAST
+ MIKEY General Extension payload (listed in Section 3) need only to be
+ integrity protected, which is already allowed by the MIKEY
+ specification. The OMA BCAST MIKEY General Extension payload SHALL
+
+
+
+Jerichow & Piron Informational [Page 4]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+ be integrity protected. Furthermore, keys or any parameters that
+ require confidentiality MUST NOT be included in the General Extension
+ payload. If keys or other confidential data are to be transported
+ via the General Extension payload, such data MUST be encrypted and
+ encapsulated independently. Finally, note that MIKEY already
+ provides replay protection and that protection also covers the
+ General Extension payload.
+
+6. IANA Considerations
+
+ IANA has allocated an OMA BCAST MIKEY General Extension Type --5--
+ from the "General Extensions payload name space" for use by OMA BCAST
+ as requested by RFC 4909 [RFC4909]. Furthermore, IANA has created a
+ name space for the OMA BCAST payload subtype values defined in
+ [RFC4909] and has assigned the following subtype values from this
+ name space: LTKM (1), STKM (2).
+
+ IANA has allocated two new subtypes from the OMA BCAST payload
+ subtype name space.
+
+ The subtypes are as follows:
+
+ Subtype Name: LTKM Reporting
+
+ Value: 3
+
+ and
+
+ Subtype Name: Parental Control
+
+ Value: 4
+
+7. Changes since RFC 4909
+
+ OMA BCAST Service and Content Protection specification [SPCP]
+ contains messages that were created since RFC 4909 was written. This
+ document only adds the necessary assignments to support these new
+ messages. No modifications are made on values assigned by RFC 4909
+ [RFC4909].
+
+8. Acknowledgments
+
+ Many thanks to the authors of RFC 4909 [RFC4909] for allowing us to
+ obsolete their RFC.
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 5]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+9. References
+
+9.1. Normative References
+
+ [3GPP.33.246] 3GPP, "3G Security; Security of Multimedia Broadcast/
+ Multicast Service (MBMS)", 3GPP TS 33.246 6.12.0,
+ October 2007.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
+ K. Norrman, "MIKEY: Multimedia Internet KEYing",
+ RFC 3830, August 2004.
+
+ [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key
+ ID Information Type for the General Extension Payload
+ in Multimedia Internet KEYing (MIKEY)", RFC 4563,
+ June 2006.
+
+ [SPCP] Open Mobile Alliance, "Service and Content Protection
+ for Mobile Broadcast Services",
+ OMA-TS-BCAST_SvcCntProtection-V1_0,
+ <http://www.openmobilealliance.org>.
+
+9.2. Informative References
+
+ [RFC4909] Dondeti, L., Castleford, D., and F. Hartung,
+ "Multimedia Internet KEYing (MIKEY) General Extension
+ Payload for Open Mobile Alliance BCAST LTKM/STKM
+ Transport", RFC 4909, June 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 6]
+
+RFC 5410 OMA BCAST MIKEY GenExt January 2009
+
+
+Authors' Addresses
+
+ Anja Jerichow (editor)
+ Nokia Siemens Networks
+ Martinstr. 76
+ 81541 Munich
+ Germany
+
+ Phone: +49 89 636-45868
+ EMail: anja.jerichow@nsn.com
+
+
+ Laurent Piron
+ Nagravision S.A.
+ Case Postale 134
+ 1033 Cheseaux
+ Switzerland
+
+ Phone: +41 21 732 05 37
+ EMail: laurent.piron@nagravision.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jerichow & Piron Informational [Page 7]
+