rfc-6309

IANA Rules for MIKEY (Multimedia Internet KEYing)

J. Arkko, A. Keranen, J. Mattsson

date2011-08 streamIETF wgnon working group statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6309 doi10.17487/RFC6309

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]

obsoletes

rfc-4909 — Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport

updates

rfc-3830 — MIKEY: Multimedia Internet KEYing
rfc-4563 — The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
rfc-5410 — Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0
rfc-6043 — MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

Extracted elements (9)

design-rationale §1

For some registries, a stable specification (e.g., an RFC via the Independent Stream) is sufficient, removing the need for IETF evaluation of extensions lacking general demand. 'IETF Review' is still encouraged over 'IESG Approval' when there is doubt about whether it is needed.

registry, process, realtime

design-rationale §1

The relaxation from 'IETF Review' to 'IETF Review or IESG Approval' was motivated by scenarios where allocations under special circumstances are warranted and by recognition that 'IETF Review' was unnecessarily strict for some namespaces. IESG Approval allows consideration of requests (e.g., experimental extensions) without requiring full IETF consensus.

registry, process, realtime

interoperability-note §6

RFC 5410 obsoleted RFC 4909 but did not itself define IANA rules for the OMA BCAST Data Subtype namespace. RFC 6309 now authoritatively defines those IANA requirements, replacing both RFC 4909 and RFC 5410 for that namespace.

registry, realtime

interoperability-note §7

RFC 6309 re-specifies the IANA rules from RFC 6043 (MIKEY-TICKET) for completeness and becomes the authoritative reference for those namespaces, even though no substantive changes were made to those rules.

registry, realtime, crypto

protocol-element §2

Valid value ranges clarified for four MIKEY namespaces: C Envelope Key Cache Indicator (0–3), S type (0–15), Key Data Type (0–15), and KV Type (0–15), which were not explicitly bounded in RFC 3830.

registry, crypto, realtime

registry §2

MIKEY namespaces with registration policy changed from 'IETF Review' to 'Specification Required': Prot type, Error no, General Extension Type (RFC 3830), KEY ID Type (RFC 4563), and OMA BCAST Data Subtype (RFC 5410).

registry, crypto, realtime

registry §2

MIKEY-TICKET namespaces from RFC 6043 retain 'Specification Required' registration policy: TS Role, ID Role, RAND Role, and Ticket Type. RFC 6309 now authoritatively defines these IANA requirements.

registry, crypto, realtime

registry §2

Version field and C envelope key cache indicator namespaces (RFC 3830 Sections 6.1 and 6.3) retain 'IETF Review' as the registration policy for new values.

registry, crypto, realtime

security-consideration §3

RFC 6309 does not change the security properties of MIKEY. However, when new values are introduced without IETF consensus, care must be taken to ensure that security concerns regarding those new values are still addressed.

security, crypto, realtime