<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902" 
docName="draft-arkko-mikey-iana-01"
category="std" 
updates="3830, 4563, 5410, 6043"
obsoletes="4909">

<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?> 
<?rfc subcompact="no"?>

  <front> 

    <title abbrev="MIKEY IANA Rules">IANA Rules for MIKEY (Multimedia
    Internet KEYing)</title>

    <author initials="J" surname="Arkko" fullname="Jari Arkko">
      <organization>Ericsson</organization>
      <address>
	<postal>
	  <street/>
	  <city>Jorvas</city> <code>02420</code>
	  <country>Finland</country>
	</postal>
	<email>jari.arkko@piuha.net</email>
      </address>
    </author>
    
    <author initials="A" surname="Keranen" fullname="Ari Keranen">
      <organization>Ericsson</organization>
      <address>
	<postal>
	  <street/>
	  <city>Jorvas</city> <code>02420</code>
	  <country>Finland</country>
	</postal>
	<email>ari.keranen@ericsson.com</email>
      </address>
    </author>
    
    <author initials="J" surname="Mattson" fullname="John Mattson">
      <organization>Ericsson</organization>
      <address>
	<postal>
	  <street/>
	  <city>Stockholm</city> <code>SE-164 80</code>
	  <country>Sweden</country>
	</postal>
	<email>john.mattsson@ericsson.com</email>
      </address>
    </author>

    <date year="2011" month="May"/>
    
    <keyword>IANA rules</keyword>
    <keyword>MIKEY</keyword>
    
    <abstract>
      
      <t> This document clarifies and relaxes the IANA rules for
      Multimedia Internet KEYing (MIKEY). This document updates RFCs
      3830, 4563, 5410, 6043, and obsoletes RFC 4909.</t>

    </abstract>
    
  </front>

  <middle>

    <section anchor="intro" title="Introduction">

      <t> This document relaxes the IANA rules for Multimedia Internet
      KEYing (MIKEY) <xref target="RFC3830"/>. The IANA rules defined
      in <xref target="RFC3830"/>, <xref target="RFC4563"/>, <xref
      target="RFC4909"/>, and <xref target="RFC5410"/> are
      affected. In addition, the rules specified in <xref
      target="RFC6043"/> are re-specified here.</t>

      <t> Most of the values in MIKEY namespaces are divided into two
      ranges: "IETF Review" (or "IETF Consensus" as it was previously
      called) and "Reserved for Private Use" <xref
      target="RFC5226"/>. This document changes, for majority of the
      namespaces, the requirement of "IETF Review" into "IETF Review
      or IESG Approval" <xref target="RFC5226"/>. For some namespaces,
      the requirement is changed to "Specification Required" <xref
      target="RFC5226"/>.</t>
      
      <t> The rationale for this update is that there can be
      situations where it makes sense to grant an allocation under
      special circumstances or that time has shown that the current
      requirement is unnecessarily strict for some of the
      namespaces. By changing the current IANA rules to allow also for
      IESG Approval <xref target="RFC5226"/>, it becomes possible for
      the Internet Engineering Steering Group (IESG) to consider an
      allocation request, even if it does not fulfill the default
      rule. For instance, an experimental protocol extension could
      perhaps deserve a new payload type as long as a sufficient
      number of types still remains, and the MIKEY community is happy
      with such an allocation. Moreover, for some registries a stable
      specification would be a sufficient requirement and hence this
      is reflected in the updated IANA rules. For instance, for some
      registries an RFC via the Independent Stream at the RFC Editor
      is sufficient, and does not force an IETF evaluation of a
      particular new extension for which there is no general
      demand.</t>

      <t> This document also makes some small corrections to the
      existing IANA registries. (RFC Editor: Please remove this
      paragraph upon publication as an RFC.)</t>

      <t> The rest of this document is structured as follows. <xref
      target="ianarules"/> defines the new IANA rules. <xref
      target="seccons"/> discusses the security implications of this
      document. <xref target="ch1"/>, <xref target="ch2"/>, <xref
      target="ch3"/>, and <xref target="ch4"/>, explain the changes to
      the RFCs 3830, 4563, 4909, 5410, and 6043.</t>

    </section>

    <section anchor="ianarules" title="IANA Considerations">

      <t> IANA is requested to update the registries related to MIKEY
      as specified below. All other MIKEY IANA registries are to
      remain unchanged. </t>

      <t> A registry for the version field should be created, with the
      value 0x01 as the only currently allocated item. (RFC Editor:
      Please remove the preceding sentence upon publication as an
      RFC.) New values for the version field (<xref
      target="RFC3830"/>, Section 6.1) and the C envelope key cache
      indicator (<xref target="RFC3830"/>, Section 6.3) field can be
      allocated via IETF Review.</t>

      <t> The requirement for adding new values into name spaces,
      originally defined in <xref target="RFC3830"/>, and having
      requirement of "IETF Review" is to be changed into "IETF Review
      or IESG Approval". This change affects the following
      namespaces:</t>

      <t><list style="symbols">
	  <t>Data type (<xref target="RFC3830"/>,  Section 6.1)</t>
	  <t>Next payload (<xref target="RFC3830"/>,  Section 6.1)</t>
	  <t>PRF func (<xref target="RFC3830"/>,  Section 6.1)</t>
	  <t>CS ID map type (<xref target="RFC3830"/>,  Section 6.1)</t> 
	  <t>Encr alg (<xref target="RFC3830"/>,  Section 6.2)</t>
	  <t>MAC alg (<xref target="RFC3830"/>,  Section 6.2)</t>
	  <t>DH-Group (<xref target="RFC3830"/>,  Section 6.4)</t>
	  <t>S type (<xref target="RFC3830"/>,  Section 6.5)</t>
	  <t>TS type (<xref target="RFC3830"/>,  Section 6.6)</t>
	  <t>ID type (<xref target="RFC3830"/>,  Section 6.7)</t>
	  <t>Cert type (<xref target="RFC3830"/>,  Section 6.7)</t>
	  <t>Hash func (<xref target="RFC3830"/>,  Section 6.8)</t>
	  <t>SRTP Type (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>SRTP encr alg (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>SRTP auth alg (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>SRTP PRF (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>FEC order (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>Key Data Type (<xref target="RFC3830"/>,  Section 6.13)</t>
	  <t>KV Type  (<xref target="RFC3830"/>,  Section 6.13)</t>
	</list></t>

      <t> The "IETF Review" requirement for the following registries,
      originally defined in <xref target="RFC3830"/>, <xref
      target="RFC4563"/>, <xref target="RFC4909"/> and <xref
      target="RFC5410"/>, is to be changed into "Specification
      Required".</t>

      <t><list style="symbols">
	  <t>Prot type (<xref target="RFC3830"/>,  Section 6.10)</t>
	  <t>Error no (<xref target="RFC3830"/>,  Section 6.12)</t>
	  <t>General Extension Type (<xref target="RFC3830"/>, Section
	  6.15)</t>
	  <t>KEY ID Type (<xref target="RFC4563"/>, Section 4)</t>
	  <t>OMA BCAST Types (<xref target="RFC5410"/>, Section 3)</t>
	</list></t>

      <t>The "Specification Required" requirement remains for the
      following namespaces:</t>
      
      <t><list style="symbols">
        <t>TS Role (<xref target="RFC6043"/>, Section 6.4)</t>
        <t>ID Role (<xref target="RFC6043"/>, Section 6.6)</t>
        <t>RAND Role (<xref target="RFC6043"/>, Section 6.8)</t>
        <t>Ticket Type (<xref target="RFC6043"/>, Section 6.10)</t>
      </list></t>

    
      <t> The range of valid values for certain namespaces defined in
      IANA considerations of <xref target="RFC3830"/> was not
      explicitly defined and is clarified here as follows: </t>

      <texttable anchor="ranges" suppress-title="true" >
          <ttcol align="left">Namespace</ttcol>
          <ttcol align="left">Valid values</ttcol>
          <c>C envelope key cache indicator</c>
          <c>0 - 3</c>
          <c>S type</c>
          <c>0 - 15</c>
          <c>Key Data Type</c>
          <c>0 - 15</c>
          <c>KV Type</c>
          <c>0 - 15</c>
      </texttable>

      <t> (RFC Editor: please remove this paragraph before publication
      and when the IANA registry has been updated with the following
      changes) The current MIKEY IANA registry defines sub-registries
      with explicit name for certain parameters (e.g., Next Payload)
      whereas other parameters (e.g., Encr alg) have no (explicit)
      sub-registries. IANA is requested to define explicit
      sub-registries for all the parameters with sub-registry names
      matching the names used in this document. </t>

    </section>

    <section anchor="seccons" title='Security Considerations'>

      <t> This specification does not change the security properties
      of MIKEY. However, when new values are introduced without IETF
      consensus, care needs to be taken to assure that possible
      security concerns regarding the new values are still
      addressed. </t>

    </section>

    <section anchor="ch1" title="Changes from RFC 3830">

      <t> <xref target="ianarules"/> relaxes the requirements from
      those defined in <xref target="RFC3830"/>. A number of
      namespaces now have the "IETF Review or IESG Approval"
      requirement, when they previously had the "IETF Review"
      requirement.  In addition, some namespaces now have the
      "Specification Required" requirement.</t>

    </section>

    <section anchor="ch2" title="Changes from RFC 4563">

      <t> <xref target="ianarules"/> relaxes the requirements from
      those defined in <xref target="RFC4563"/>. The KEY ID Type
      namespace now has the Specification Required requirement.</t>

    </section>

    <section anchor="ch3" title="Changes from RFC 4909 and RFC 5410">

      <t> <xref target="ianarules"/> relaxes the requirements from
      those defined in <xref target="RFC4909"/>. The OMA BCAST Types
      namespace now has the Specification Required requirement. Note
      that <xref target="RFC5410"/> obsoleted <xref target="RFC4909"/>
      but does not actually define the IANA rules itself. As a result,
      from now on this RFC defines the IANA requirements for the OMA
      BCAST Type namespace.</t>

    </section>

    <section anchor="ch4" title="Changes from RFC 6043">

      <t> There are no changes to the rules specified in <xref
      target="RFC6043"/>. However, for sake of completeness, <xref
      target="ianarules"/> re-specifies these rules in this document,
      and from now on this RFC defines the IANA requirements for those
      namespaces.</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">
      <?rfc include="reference.RFC.3830.xml"?>
      <?rfc include="reference.RFC.4563.xml"?>
      <?rfc include="reference.RFC.5226.xml"?>
      <?rfc include="reference.RFC.5410.xml"?>
      <?rfc include="reference.RFC.6043.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4909.xml"?>
    </references>

  </back>
</rfc>
