<?xml version="1.0" encoding="UTF-8"?>
 <?xml-stylesheet type='text/xsl' href='../rfc2629.xslt' ?>
 <!DOCTYPE rfc SYSTEM "../rfc2629.dtd"[
 <!ENTITY rfc2119 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY rfc3830 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml'>
 <!ENTITY rfc2434 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml'>
<!ENTITY rfc4771 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
 <!ENTITY keyid SYSTEM
 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml">
 ]>
 <?rfc toc="yes"?>
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 <?rfc sortrefs="yes" ?>
 <?rfc symrefs="no"?>
 <?rfc comments="yes"?>
 <?rfc inline="no"?>
<rfc ipr="full3978" obsoletes="4909" docName="draft-jerichow-msec-mikey-genext-oma-00" category="info">
    <front>
        <title abbrev="OMA BCAST MIKEY GenExt"> MIKEY General Extension Payload for OMA BCAST 1.0 </title>
        <author fullname="Anja Jerichow" initials="A" surname="Jerichow" role="editor">
            <organization>Nokia Siemens Networks</organization>
            <address> <postal> 
                <street>Martinstr. 76</street> 
                <city>81541 Munich</city>
                <country>Germany</country>
            </postal>
                <phone>+49 89 636-45868</phone>
                <email>anja.jerichow@nsn.com</email>
            </address>
        </author>
       <author fullname="Laurent Piron" initials="L" surname="Piron">
            <organization>Nagravision S.A.</organization>
            <address> <postal> 
                <street>Case Postale 134</street> 
                <city>1033 Cheseaux</city>
                <country>Switzerland</country>
            </postal>
                <phone>+41 21 732 05 37</phone>
                <email>laurent.piron@nagravision.com</email>
            </address>
        </author>
        <date month="October" year="2008"/>
        <area> </area>
        <workgroup>Network Working Group</workgroup>
        <keyword>Internet-Draft</keyword>
        <keyword>MIKEY Extension </keyword>
        <keyword>IANA registration</keyword>
        <keyword>OMA BCAST</keyword>
        
<abstract>
            <t>This document extends the General Extension Payload for OMA BCAST usage defined in RFC 4909 <xref target="RFC4909"/>.  It adds necessary support for the newly specified management data as defined in the Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content protection specification <xref target="SPCP"/>.</t>
        
</abstract>

</front>

<middle>
        
<section title="Introduction" anchor="intro">
            <t> The Multimedia Internet Keying (MIKEY) protocol specification (RFC 3830 <xref target="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.</t>

            <t> The Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service
   		and Content Protection specification <xref target="SPCP"/> specifies the use of a short-
   		term key message (STKM), a long-term key message (LTKM), a LTKM
   		reporting message, as well as 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.</t>
	    <t> 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 <xref target="RFC3830"/>.</t>

	   <t>  RFC 3830 <xref target="RFC3830"/>, the MIKEY General Extension payload 
		defined in RFC 4563 <xref target="RFC4563"/>, 
		and the 3rd Generation Partnership Project (3GPP)'s Multimedia Broadcast/
   		Multicast Service (MBMS) document <xref target="3GPP33246"/> specify the transport of MIKEY
   		messages via unicast or broadcast and the OMA specifications use
   		either for transport of MIKEY messages.</t>
</section>

<section anchor="terms" title="Terminology">
            <t> 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 
                    <xref target="RFC2119"/>. </t>
	    <t> OMA BCAST MIKEY General Extension: We refer to the General 
		Extension type -- 5 -- as the OMA BCAST MIKEY General Extension.</t>
</section>


<section title="MIKEY General Extension for OMA BCAST Usage">

<t>
Section 6.1 of RFC 3830 <xref target="RFC3830"/> specifies the first three fields of the
   General Extension Payload and defines a variable length Data field.
</t>            
<t> 
<figure anchor="f1" title="OMA BCAST MIKEY General Extension">         
<artwork>
                    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         !      Type     !            Length              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       OMA BCAST Payload Subtype  (variable length)            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>          
</figure>
<t>
   This document specifies the use of Type 5 for OMA BCAST Service and
   Content Protection using the Smartcard Profile.  
</t>
<t>
<figure anchor="t1" title="Definition of the New General Extension Payload">
<artwork>
Type        | Value | Comments
------------------------------------------------------------------
OMA BCAST   |     5 | information on type and identity of messages
</artwork>
</figure>
</t>

<t>
The contents of the variable length data field are defined below.
</t>
       
</t>

<t> 
<figure anchor="f2" title="STKM/LTKM/LTKM Reporting/Parental Control Subtype Payload">
           
<artwork>
                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   Sub Type    ! Subtype Specific Data (variable length)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
           
</figure>
</t>
<list style="empty">
      <t>Sub Type: 8 bits.  This field indicates the type of the OMA BCAST
      payload.  In this specification, four values are specified:
      LTKM (1), STKM (2), LTKM Reporting (TBD1), and Parental Control (TBD2).
</t>
<t>Sub Type Specific Data: Variable length.</t>
</list>        

<t>
<figure anchor="t2" title="Subtype definitions for OMA BCAST messages">
<artwork>
    
      OMA BCAST Type        | Value | Comment
      -----------------------------------------------------------
      LTKM                  |     1 | Long Term Key Message
      STKM                  |     2 | Short Term Key Message
      LTKM Reporting        |  TBD1 | LTKM Reporting Message
      Parental Control      |  TBD2 | Parental Control Message
 
</artwork>
</figure>
</t>
<t> The contents of the OMA BCAST payload field are defined in Section 6 of the OMA BCAST Service and
      Content Protection specification <xref target="SPCP"/>.
</t>
</section>


<section title="Interoperability considerations">
<t>
This document specifies the use of MIKEY General Extension Payload
   Type 5 and four subtype values (1, 2, TBD1 and TBD2), one each
   for OMA BCAST Service and Content protection's STKM and LTKM payloads.
   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 <xref target="RFC3830"/> and RFC 4563 <xref target="RFC4563"/>.
</t>
</section>

<section title="Security Considerations">
<t>According to RFC 3830 <xref target="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 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 covers also the General
   Extension Payload.
</t>
</section>
        
<section title="IANA Considerations">

<t>IANA has allocated an OMA BCAST MIKEY General Extension Type --5-- from the "General Extensions payload name space" in the IANA registry at http://www.iana.org/assignments/mikey-payloads for use by OMA BCAST as requested by RFC 4909 <xref target="RFC4909"/>.  Furthermore, IANA has created a name space for the OMA BCAST payload subtype values defined in <xref target="RFC4909"/> and has assigned the following subtype values from this name space: LTKM (1), STKM (2).
</t> 
<t>
IANA is requested to allocate two new subtypes from the OMA BCAST payload subtype name space, referenced above, in the IANA registry at http://www.iana.org/assignments/mikey-payloads.
</t>
<t>The requested subtypes are as follows:

<list style="hanging">
<t>Subtype Name: LTKM Reporting</t>          
<t>Value: TBD1</t>
<t>Suggested value: 3</t>
</list>
<t>and</t>
<list style="hanging">
<t>Subtype Name: Parental Control </t>          
<t>Value: TBD2</t>
<t>Suggested value: 4</t>
</list>
</t>
<t>
Note to Editor: Please replace all TBD1 and TBD2 in this specification with the values assigned by IANA.
</t>

</section>
<section title="Changes since RFC 4909">
<t>
OMA BCAST Service and Content Protection specification <xref target="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 <xref target="RFC4909"/>.
</t>

</section>
<section anchor="ack" title="Acknowledgments" toc="default">
<t>Many thanks to the authors of RFC 4909 <xref target="RFC4909"/> for allowing to update their RFC.
</t>
</section>

</middle>

<back>
        
<references title="Normative References"> &rfc2119; &rfc4563; &rfc2434; &rfc3830; 
<reference anchor="SPCP">
                <front>
                    <title>Service and Content Protection for Mobile Broadcast Services</title>
                    <author>
                        <organization>Open Mobile Alliance</organization>
                    </author>
                    <date year="2008"/>
                </front>
                <seriesInfo name="OMA" value="OMA-TS-BCAST_SvcCntProtection-V1_0-20081015-D"/>
</reference>
<reference anchor="3GPP33246">
		<front>
                    <title>3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)
		    </title>
                    <author>
                        <organization>3GPP</organization>
                    </author>
                    <date month="March" year="2006"/>
                </front>
                <seriesInfo name="3GPP" value="TS 33.246 6.6.0"/>
</reference><reference anchor="RFC4909">
		<front>
                    <title>Multimedia Internet KEYing (MIKEY) General Extension
		    </title>
                    <author>
                        L. Donetti, D. Castleford, F. Hartung
                    </author>
                    <date month="June" year="2007"/>
                </front>
                <seriesInfo name="RFC" value="4909"/>
</reference>
</references>
</back>
</rfc>
