idnits 2.17.1 draft-dondeti-msec-mikey-genext-oma-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. 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 ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 54 has weird spacing: '...tension for O...' == Line 101 has weird spacing: '...tension for O...' -- 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 (February 6, 2007) is 6287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dondeti, Ed. 3 Internet-Draft QUALCOMM, Inc. 4 Intended status: Informational D. Castleford 5 Expires: August 10, 2007 Orange FT 6 F. Hartung 7 Ericsson Research 8 February 6, 2007 10 MIKEY General Extension Payload for OMA BCAST LTKM/STKM Transport 11 draft-dondeti-msec-mikey-genext-oma-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 10, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies a new MIKEY General Extension payload [1] to 45 transport the short term key message (STKM) and long term key message 46 (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser 47 and Content (BAC) Broadcast (BCAST) group's Service and Content 48 protection specification. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . 3 55 4. Interoperability considerations . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 The Multimedia Internet Keying (MIKEY) protocol specification [1] 68 defines a General Extension payload to allow possible extensions to 69 MIKEY without having to allocate a new payload type. The General 70 Extension payload can be used in any MIKEY message and is part of the 71 authenticated/signed data part. There is an 8-bit type field in that 72 payload and the type code assignment is IANA managed and RFC 3830 73 requires IETF consensus for assignments from the public range of 74 0-240. 76 The Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast 77 (BCAST) group's Service and Content Protection specification [2] 78 specifies the use of a short term key message (STKM) and a long term 79 key message (LTKM) that carry attributes related to Service and 80 Content protection. Note that any keys associated with the 81 attributes are part of the MIKEY KEMAC payload. This document 82 specifies the use of the General Extension payload of MIKEY to carry 83 the LTKMs or STKMs. 85 RFC 3830, the MIKEY General Extension payload defined in [3] along 86 with the 3rd Generation Partnership Project (3GPP)'s Multimedia 87 Broadcast/Multicast Service (MBMS) [4] document specify the transport 88 of MIKEY messages via unicast or broadcast and the OMA specifications 89 use either for transport of MIKEY messages. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [5]. 97 OMA BCAST STKM/LTKM MIKEY General Extension : We refer to the 98 General Extension type -- value, to be assigned by IANA -- as the 99 OMA BCAST STKM/LTKM MIKEY General Extension . 101 3. MIKEY General Extension for OMA BCAST Usage 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 S/LTKM Subtype (variable length) ~ 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 1: OMA BCAST MIKEY General Extension 112 Section 6.1 of RFC 3830 specifies the first three fields of the 113 General Extension Payload and defines a variable length Data field. 114 This document specifies the use of Type XX [To be filled in by the 115 RFC Editor after IANA assignment] for OMA BCAST Service and Content 116 Protection using the Smartcard Profile. The contents of the variable 117 length data field are defined below. 119 Sub Type: 8 bits. This field indicates the type of the OMA BCAST 120 payload. In this specification, only two values are specified: 121 LTKM (1), and STKM (2). 123 Sub Type Specific Data: Variable length. The contents of this 124 field are defined in Section 6 of the OMA BCAST Service and 125 Content Protection specification [2]. 127 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 ! Sub Type ! SubType specific data (variable length) ~ 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 2: STKM/LTKM Subtype Payload 135 4. Interoperability considerations 137 This document specifies the use of MIKEY General Extension Payload 138 Type XX [to be assigned by IANA based on IETF review] and a couple of 139 subtype values (1 and 2), one each for OMA BCAST Service and Content 140 protection's STKM and LTKM payloads. Interoperability considerations 141 span several standards bodies, with OMA BCAST 1.0 enabler compliance 142 being the key aspect; as such it is up to the OMA test planning to 143 verify the interoperability and compliance of OMA BCAST 1.0 144 implementations. This payload type assignment does not change MIKEY 145 beyond RFC 3830 and [3]. 147 5. Security Considerations 149 According to RFC 3830, the general extension payload can be used in 150 any MIKEY message and is part of the authenticated/signed data part. 151 The parameters proposed to be included in the OMA BCAST MIKEY General 152 Extension payload (listed in Section 3) need only to be integrity 153 protected, which is already allowed by the MIKEY specification. The 154 OMA BCAST MIKEY General Extension Payload SHALL be integrity 155 protected. Furthermore, keys or any parameters that require 156 confidentiality MUST NOT be included in the General Extension 157 Payload. If Keys or other confidential data are to be transported 158 via the General Extension Payload, such data MUST be encrypted and 159 encapsulated independently. Finally, note that MIKEY already 160 provides replay protection and that protection covers the General 161 Extension Payload also. 163 6. IANA Considerations 165 IANA is requested to allocate a new General Extension Type from the 166 "General Extensions payload name spaces" in the IANA registry at 167 http://www.iana.org/assignments/mikey-payloads for use by OMA BCAST. 168 Furthermore, IANA is requested to maintain a list of corresponding 169 subtypes (0-255) as follows: 171 0 ... Reserved 173 1 ... LTKM 175 2 ... STKM 177 3 ... 191 (maintained by IANA and assigned by IETF Review[6]) 179 192 ... 255 (Private use) 181 7. Acknowledgments 183 Many thanks to Jari Arkko, Piron Laurent and Steffen Fries for their 184 reviews and suggestions for improvement. 186 8. References 188 8.1. Normative References 190 [1] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 191 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 192 August 2004. 194 [2] Open Mobile Alliance, "Service and Content Protection for Mobile 195 Broadcast Services", OMA TS-BCAST-SvcCntProtection-V1_0- 196 20060412-D, 2006. 198 [3] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 199 Information Type for the General Extension Payload in Multimedia 200 Internet KEYing (MIKEY)", RFC 4563, June 2006. 202 [4] 3GPP, "3G Security; Security of Multimedia Broadcast/Multicast 203 Service (MBMS)", 3GPP TS 33.246 6.6.0, March 2006. 205 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 206 Levels", BCP 14, RFC 2119, March 1997. 208 8.2. Informative References 210 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 211 Considerations Section in RFCs", 212 draft-narten-iana-considerations-rfc2434bis-05 (work in 213 progress), September 2006. 215 Authors' Addresses 217 Lakshminath Dondeti (editor) 218 QUALCOMM, Inc. 219 5775 Morehouse Dr 220 San Diego, CA 221 USA 223 Phone: +1 858-845-1267 224 Email: ldondeti@qualcomm.com 226 David Castleford 227 Orange FT 228 4, rue du Clos Courtel 229 35512 Cesson Sevigne Cedex, 230 France 232 Phone: + 33 (0)2 99 12 49 27 233 Email: david.castleford@orange-ft.com 234 Frank Hartung 235 Ericsson Research 236 Ericsson Allee 1 237 52134 Herzogenrath, 238 Germany 240 Phone: +49 2407 575389 241 Email: frank.hartung@ericsson.com 243 Full Copyright Statement 245 Copyright (C) The IETF Trust (2007). 247 This document is subject to the rights, licenses and restrictions 248 contained in BCP 78, and except as set forth therein, the authors 249 retain all their rights. 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 254 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 255 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 256 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Intellectual Property 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the procedures with respect to rights in RFC documents can be 268 found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org. 283 Acknowledgment 285 Funding for the RFC Editor function is provided by the IETF 286 Administrative Support Activity (IASA).