The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
updated by
- rfc-6309 — IANA Rules for MIKEY (Multimedia Internet KEYing)
Extracted elements (20)
MBMS uses a three-level key hierarchy (MUK → MSK → MTK) to enable frequent traffic key updates. The cost of redistributing decryption keys to non-subscribers via unicast must exceed the cost of purchasing them, making re-keying economically viable as a content protection mechanism.
MBMS uses MIKEY both as a registration and a re-key protocol, extending MIKEY's original unicast-only re-keying design (per RFC 3830 / RFC 4046) to support multicast re-keying via the new General Extension payload.
MTK delivery uses a group MAC keyed by MSK rather than source origin authentication. 3GPP deemed the technical difficulties and costs of insider spoofing attacks acceptable relative to the expected attacker gain.
Security policy is delivered with the MSK rather than each MTK because MTK delivery can be as frequent as a few seconds apart, making per-MTK policy delivery prohibitively expensive in bandwidth. 3GPP decided session policy would not change during a session.
The Key ID Information General Extension payload (Type 3) is not restricted to MBMS; any application may define new Key ID types provided they register semantics per Section 8. MBMS-specific semantics are defined in 3GPP TS 33.246.
When Key-ID payload is used with MBMS, the underlying transport is UDP. The usage of MIKEY over UDP in the MBMS setting is defined by 3GPP TS 33.246 rather than this RFC.
Applications using the Key ID Information General Extension payload type MUST define the semantics and usage of the Key ID Type sub-payloads according to the IANA considerations in Section 8.
The overall length (sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets.
Values in the range 0–240 for each new Key ID Type namespace SHOULD be approved by the process of IETF consensus; values in the range 241–255 are reserved for Private Use.
When the CS ID map type is set to Empty map (value 1), there MUST NOT be any Security Policy payload present in the MIKEY message.
An Empty Map CS ID map type (value 1) is defined for use when map/policy information is conveyed outside of MIKEY, such as when parameters are signalled in-band via DRM Content Format objects.
Three predefined Key ID Types are defined: MBMS Key Domain ID (value 0, identifies the group key domain), MBMS Service Key ID (value 1, identifies the group key), and MBMS Traffic Key ID (value 2, identifies the group traffic key).
Type 3 (Key ID Information) is added to the MIKEY General Extension Payload namespace. It carries the type and identity of keys involved in a MIKEY message, enabling key distribution for multicast/broadcast services.
IANA registered Type 3 (Key ID Information) in the MIKEY General Extension Payload Type namespace, and value 1 (Empty map) in the CS ID map type namespace. A new Key ID Type namespace was created with predefined values 0–2 for MBMS types; values 0–240 require IETF consensus, 241–255 are reserved for Private Use.
Because MTK delivery lacks source origin authentication, adding source origin authentication to RTP streams (e.g., via SRTP-TESLA) provides no benefit. The current Key ID extension usage is incompatible with SRTP-TESLA, which requires source origin authentication of the integrity key.
MTK delivery is not source origin authenticated but protected by a group MAC keyed by MSK. Group members with access to MSK can spoof MTK updates to other members; injection on the air interface between base stations and user equipment is the primary risk.
The MSK is protected end-to-end from multicast server to clients using the client-unique MUK, but the MTK is only delivered under group key MSK protection, so source origin authentication is not achieved for MTK.
When the Empty map type is used (security policy conveyed in-band), security relies on DCF protections. MIKEY in this case only provides the master key for DCF processing and does not itself secure the policy.
Each Key ID Type sub-payload contains: Key ID Type (8 bits), Key ID Length (8 bits, length of Key ID in octets), and Key ID (variable length defining the identity of the key).
The Key ID Information Type (Type 3) formats the General Extension payload with a Next Payload field (8 bits), Type field (8 bits, value=3), Length field (16 bits), and a variable-length Key ID Information field containing one or more Key ID Type sub-payloads.