idnits 2.17.1 draft-jerichow-msec-mikey-genext-oma-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC4909, but the abstract doesn't seem to directly say this. It does mention RFC4909 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2008) is 5661 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4909 (ref. '1') (Obsoleted by RFC 5410, RFC 6309) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Jerichow, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Obsoletes: 4909 (if approved) L. Piron 5 Intended status: Informational Nagravision S.A. 6 Expires: April 27, 2009 October 24, 2008 8 MIKEY General Extension Payload for OMA BCAST 1.0 9 draft-jerichow-msec-mikey-genext-oma-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 27, 2009. 36 Abstract 38 This document extends the General Extension Payload for OMA BCAST 39 usage defined in RFC 4909 [1]. It adds necessary support for the 40 newly specified management data as defined in the Open Mobile 41 Alliance's (OMA) Broadcast (BCAST) group's Service and Content 42 protection specification [2]. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3 49 4. Interoperability considerations . . . . . . . . . . . . . . . . 5 50 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 51 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 52 7. Changes since RFC 4909 . . . . . . . . . . . . . . . . . . . . 6 53 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 54 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Intellectual Property and Copyright Statements . . . . . . . . . . 8 58 1. Introduction 60 The Multimedia Internet Keying (MIKEY) protocol specification (RFC 61 3830 [3]) defines a General Extension payload to allow possible 62 extensions to MIKEY without having to allocate a new payload type. 63 The General Extension payload can be used in any MIKEY message and is 64 part of the authenticated/signed data part. There is an 8-bit type 65 field in that payload. The type code assignment is IANA-managed, and 66 RFC 3830 requires IETF consensus for assignments from the public 67 range of 0-240. 69 The Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service 70 and Content Protection specification [2] specifies the use of a 71 short- term key message (STKM), a long-term key message (LTKM), a 72 LTKM reporting message, as well as a parental control message that 73 carry attributes related to Service and Content protection. Note 74 that any keys associated with the attributes, such as the Parental 75 Control Pincode if present, are part of the MIKEY KEMAC payload. 77 This document specifies the use of the General Extension payload of 78 MIKEY to carry the messages mentioned above, as well as protection of 79 the credentials using mechanisms supported by MIKEY with 80 modifications in [3]. 82 RFC 3830 [3], the MIKEY General Extension payload defined in RFC 4563 83 [4], and the 3rd Generation Partnership Project (3GPP)'s Multimedia 84 Broadcast/ Multicast Service (MBMS) document [5] specify the 85 transport of MIKEY messages via unicast or broadcast and the OMA 86 specifications use either for transport of MIKEY messages. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [6]. 94 OMA BCAST MIKEY General Extension: We refer to the General Extension 95 type -- 5 -- as the OMA BCAST MIKEY General Extension. 97 3. MIKEY General Extension for OMA BCAST Usage 99 Section 6.1 of RFC 3830 [3] specifies the first three fields of the 100 General Extension Payload and defines a variable length Data field. 102 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 ! Next ! Type ! Length ! 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 ! OMA BCAST Payload Subtype (variable length) ~ 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 1: OMA BCAST MIKEY General Extension 112 This document specifies the use of Type 5 for OMA BCAST Service and 113 Content Protection using the Smartcard Profile. 115 Type | Value | Comments 116 ------------------------------------------------------------------ 117 OMA BCAST | 5 | information on type and identity of messages 119 Figure 2: Definition of the New General Extension Payload 121 The contents of the variable length data field are defined below. 123 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 ! Sub Type ! Subtype Specific Data (variable length) ~ 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 3: STKM/LTKM/LTKM Reporting/Parental Control Subtype Payload 131 Sub Type: 8 bits. This field indicates the type of the OMA BCAST 132 payload. In this specification, four values are specified: LTKM 133 (1), STKM (2), LTKM Reporting (TBD1), and Parental Control (TBD2). 135 Sub Type Specific Data: Variable length. 137 OMA BCAST Type | Value | Comment 138 ----------------------------------------------------------- 139 LTKM | 1 | Long Term Key Message 140 STKM | 2 | Short Term Key Message 141 LTKM Reporting | TBD1 | LTKM Reporting Message 142 Parental Control | TBD2 | Parental Control Message 144 Figure 4: Subtype definitions for OMA BCAST messages 146 The contents of the OMA BCAST payload field are defined in Section 6 147 of the OMA BCAST Service and Content Protection specification [2]. 149 4. Interoperability considerations 151 This document specifies the use of MIKEY General Extension Payload 152 Type 5 and four subtype values (1, 2, TBD1 and TBD2), one each for 153 OMA BCAST Service and Content protection's STKM and LTKM payloads. 154 Interoperability Considerations span several standards bodies, with 155 OMA BCAST 1.0 enabler compliance being the key aspect; as such it is 156 up to the OMA test planning to verify the interoperability and 157 compliance of OMA BCAST 1.0 implementations. This payload type 158 assignment does not change MIKEY beyond RFC 3830 [3] and RFC 4563 159 [4]. 161 5. Security Considerations 163 According to RFC 3830 [3], the general extension payload can be used 164 in any MIKEY message and is part of the authenticated/signed data 165 part. The parameters proposed to be included in the OMA BCAST MIKEY 166 General Extension payload (listed in Section 3) need only to be 167 integrity protected, which is already allowed by the MIKEY 168 specification. The OMA BCAST MIKEY General Extension Payload SHALL 169 be integrity protected. Furthermore, keys or any parameters that 170 require confidentiality MUST NOT be included in the General Extension 171 Payload. If Keys or other confidential data are to be transported 172 via the General Extension Payload, such data MUST be encrypted and 173 encapsulated independently. Finally, note that MIKEY already 174 provides replay protection and that protection covers also the 175 General Extension Payload. 177 6. IANA Considerations 179 IANA has allocated an OMA BCAST MIKEY General Extension Type --5-- 180 from the "General Extensions payload name space" in the IANA registry 181 at http://www.iana.org/assignments/mikey-payloads for use by OMA 182 BCAST as requested by RFC 4909 [1]. Furthermore, IANA has created a 183 name space for the OMA BCAST payload subtype values defined in [1] 184 and has assigned the following subtype values from this name space: 185 LTKM (1), STKM (2). 187 IANA is requested to allocate two new subtypes from the OMA BCAST 188 payload subtype name space, referenced above, in the IANA registry at 189 http://www.iana.org/assignments/mikey-payloads. 191 The requested subtypes are as follows: 193 Subtype Name: LTKM Reporting 195 Value: TBD1 197 Suggested value: 3 199 and 201 Subtype Name: Parental Control 203 Value: TBD2 205 Suggested value: 4 207 Note to Editor: Please replace all TBD1 and TBD2 in this 208 specification with the values assigned by IANA. 210 7. Changes since RFC 4909 212 OMA BCAST Service and Content Protection specification [2] contains 213 messages that were created since RFC 4909 was written. This document 214 only adds the necessary assignments to support these new messages. 215 No modifications are made on values assigned by RFC 4909 [1]. 217 8. Acknowledgments 219 Many thanks to the authors of RFC 4909 [1] for allowing to update 220 their RFC. 222 9. Normative References 224 [1] "Multimedia Internet KEYing (MIKEY) General Extension", 225 RFC 4909, June 2007. 227 [2] Open Mobile Alliance, "Service and Content Protection for Mobile 228 Broadcast Services", OMA OMA-TS-BCAST_SvcCntProtection-V1_0- 229 20081015-D, 2008. 231 [3] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 232 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 233 August 2004. 235 [4] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 236 Information Type for the General Extension Payload in Multimedia 237 Internet KEYing (MIKEY)", RFC 4563, June 2006. 239 [5] 3GPP, "3G Security; Security of Multimedia Broadcast/Multicast 240 Service (MBMS)", 3GPP TS 33.246 6.6.0, March 2006. 242 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 243 Levels", BCP 14, RFC 2119, March 1997. 245 Authors' Addresses 247 Anja Jerichow (editor) 248 Nokia Siemens Networks 249 Martinstr. 76 250 81541 Munich 251 Germany 253 Phone: +49 89 636-45868 254 Email: anja.jerichow@nsn.com 256 Laurent Piron 257 Nagravision S.A. 258 Case Postale 134 259 1033 Cheseaux 260 Switzerland 262 Phone: +41 21 732 05 37 263 Email: laurent.piron@nagravision.com 265 Full Copyright Statement 267 Copyright (C) The IETF Trust (2008). 269 This document is subject to the rights, licenses and restrictions 270 contained in BCP 78, and except as set forth therein, the authors 271 retain all their rights. 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 276 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 277 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 278 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Intellectual Property 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org.