RFC 6309

IANA Rules for MIKEY (Multimedia Internet KEYing)

📅 published August 2011, from ietf

Abstract ✨

Internet Engineering Task Force (IETF) 🌸 · Request for Comments: 6309 🎀 · Category: Standards Track 💅 · Date: August 2011 📅 · ISSN: 2070-1721

Okay bestie, here's the title block tea ☕:

  • Title: IANA Rules for MIKEY (Multimedia Internet KEYing)
  • Authors: J. Arkko, A. Keranen, J. Mattsson (all from Ericsson) 🧚
  • Obsoletes: 4909
  • Updates: 3830, 4563, 5410, 6043

This doc is all about cleaning up and loosening the IANA rules for MIKEY 🦋. It updates RFCs 3830, 4563, 5410, and 6043, and it obsoletes RFC 4909 💜.

Status of This Memo 🍓

This is an Internet Standards Track document, so it's officially a big deal 👑.

This doc comes from the IETF 💖. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info about Internet Standards, check out Section 2 of RFC 5741 🌈.

You can find the current status of this doc, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6309 🫶.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License ⚠️.

1. Introduction 🧚‍♀️

Okay so this doc loosens up the IANA rules for Multimedia Internet KEYing (MIKEY) [RFC3830] ✨. The IANA rules in [RFC3830], [RFC4563], [RFC4909], and [RFC5410] are all affected 🌸. On top of that, the rules in [RFC6043] get re-specified here 💖.

Most values in MIKEY namespaces are split into two ranges: "IETF Review" (which used to be called "IETF Consensus") and "Reserved for Private Use" [RFC5226] 🎀. This doc changes the requirement from "IETF Review" to "IETF Review or IESG Approval" [RFC5226] for most of the namespaces 🦋. For a few namespaces, the requirement becomes "Specification Required" [RFC5226] 💜.

Why? Because there can be situations where it makes sense to hand out an allocation under special circumstances, or because time has shown the current requirement is unnecessarily strict for some namespaces 🙄. Adding "IESG Approval" [RFC5226] means the Internet Engineering Steering Group (IESG) can look at an allocation request even if it doesn't meet the default rule 👑. For example, an experimental protocol extension could maybe deserve a new payload type, as long as enough types are still left and the MIKEY community is happy with it 🧁. Also, for some registries, a stable specification is enough, so the updated IANA rules reflect that 💅. For instance, an RFC from the Independent Stream at the RFC Editor is enough for some registries, and it doesn't force an IETF evaluation of an extension nobody's really asking for 🌈. That said, "IETF Review" is still encouraged (instead of the "IESG Approval" path) if you're not sure whether it's needed for a new allocation 🫶.

The rest of this doc is laid out like this: Section 2 defines the new IANA rules 📋. Section 3 talks about the security implications 🔐. Sections 4, 5, 6, and 7 explain the changes to [RFC3830], [RFC4563], [RFC4909], [RFC5410], and [RFC6043] 💖.

2. IANA Considerations 📚

IANA updated the registries related to MIKEY as specified below. All other MIKEY IANA registries remain unchanged ✨.

New values for the version field ([RFC3830], Section 6.1) and the C envelope key cache indicator ([RFC3830], Section 6.3) field can be allocated via "IETF Review" 🎀.

The "IETF Review" requirement for adding new values into namespaces, originally defined in [RFC3830], is to be changed to "IETF Review or IESG Approval". This change affects the following namespaces 🦋:

  • data type ([RFC3830], Section 6.1)
  • Next payload ([RFC3830], Section 6.1)
  • PRF func ([RFC3830], Section 6.1)
  • CS ID map type ([RFC3830], Section 6.1)
  • Encr alg ([RFC3830], Section 6.2)
  • MAC alg ([RFC3830], Section 6.2)
  • DH-Group ([RFC3830], Section 6.4)
  • S type ([RFC3830], Section 6.5)
  • TS type ([RFC3830], Section 6.6)
  • ID Type ([RFC3830], Section 6.7)
  • Cert Type ([RFC3830], Section 6.7)
  • Hash func ([RFC3830], Section 6.8)
  • SRTP Type ([RFC3830], Section 6.10)
  • SRTP encr alg ([RFC3830], Section 6.10)
  • SRTP auth alg ([RFC3830], Section 6.10)
  • SRTP PRF ([RFC3830], Section 6.10)
  • FEC order ([RFC3830], Section 6.10)
  • Key Data Type ([RFC3830], Section 6.13)
  • KV Type ([RFC3830], Section 6.13)

The "IETF Review" requirement for the following registries, originally defined in [RFC3830], [RFC4563], [RFC4909], and [RFC5410], is to be changed to "Specification Required" 💅.

  • Prot type ([RFC3830], Section 6.10)
  • Error no ([RFC3830], Section 6.12)
  • General Extension Type ([RFC3830], Section 6.15)
  • KEY ID Type ([RFC4563], Section 4)
  • OMA BCAST Data Subtype ([RFC5410], Section 3)

The "Specification Required" requirement stays put for these namespaces 🔒:

  • TS Role ([RFC6043], Section 6.4)
  • ID Role ([RFC6043], Section 6.6)
  • RAND Role ([RFC6043], Section 6.8)
  • Ticket Type ([RFC6043], Section 6.10)

The valid range of values for some namespaces in the IANA considerations of [RFC3830] was never explicitly defined. This doc clarifies it like this 🧮:

          +--------------------------------+--------------+
          | Namespace                      | Valid values |
          +--------------------------------+--------------+
          | C Envelope Key Cache Indicator | 0 - 3        |
          | S type                         | 0 - 15       |
          | Key Data Type                  | 0 - 15       |
          | KV Type                        | 0 - 15       |
          +--------------------------------+--------------+

3. Security Considerations 🔐

⚠️ This is the serious part, so pay attention, bestie 💀.

This spec does not change the security properties of MIKEY 🛡️. However, when new values get introduced without IETF consensus, care needs to be taken to make sure possible security concerns about those new values are still addressed 😭.

4. Changes from RFC 3830 🌷

Section 2 relaxes the requirements from those defined in [RFC3830] ✨. A bunch of namespaces now have the "IETF Review or IESG Approval" requirement, when they used to just have "IETF Review" 🦋. On top of that, some namespaces now have the "Specification Required" requirement 💜.

5. Changes from RFC 4563 🦄

Section 2 relaxes the requirements from those defined in [RFC4563] 💖. The KEY ID Type namespace now has the "Specification Required" requirement 🎀.

6. Changes from RFC 4909 and RFC 5410 🌈

Section 2 relaxes the requirements from those defined in [RFC4909] 🧚. The OMA BCAST Data Subtype namespace now has the "Specification Required" requirement 💅. Note that [RFC5410] obsoleted [RFC4909] but doesn't actually define the IANA rules itself 🙈. So from now on, this RFC defines the IANA requirements for the OMA BCAST Data Subtype namespace 🫶.

7. Changes from RFC 6043 🍓

There are no changes to the rules in [RFC6043] 🙌. However, for the sake of completeness, Section 2 re-specifies these rules in this doc, and from now on, this RFC defines the IANA requirements for those namespaces ✨.

8. References 📖

8.1. Normative References

[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.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC5410]  Jerichow, A. and L. Piron, "Multimedia Internet KEYing
           (MIKEY) General Extension Payload for Open Mobile Alliance
           BCAST 1.0", RFC 5410, January 2009.

[RFC6043]  Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
           Modes of Key Distribution in Multimedia Internet KEYing
           (MIKEY)", RFC 6043, March 2011.

8.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.

Authors' Addresses 💌

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Ari Keranen
Ericsson
Jorvas  02420
Finland

EMail: ari.keranen@ericsson.com


John Mattsson
Ericsson
Stockholm  SE-164 80
Sweden

EMail: john.mattsson@ericsson.com
📦 where this page comes from