From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5410.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc5410.txt (limited to 'doc/rfc/rfc5410.txt') 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, + . + +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] + -- cgit v1.2.3