MIKEY Key ID type: The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
Telling receivers which kind of key a MIKEY message carries, and which key it is.
Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, DOI 10.17487/RFC4563, June 2006, <https://www.rfc-editor.org/info/rfc4563>.
@misc{rfc4563,
series = {Request for Comments},
number = 4563,
howpublished = {RFC 4563},
publisher = {RFC Editor},
doi = {10.17487/RFC4563},
url = {https://www.rfc-editor.org/info/rfc4563},
author = {E. Carrara and V. Lehtovirta and K. Norrman},
title = {{The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)}},
pagetotal = 10,
year = 2006,
month = jun,
} RFC text
Contents
Network Working Group E. Carrara
Request for Comments: 4563 KTH
Category: Standards Track V. Lehtovirta
K. Norrman
Ericsson
June 2006
The Key ID Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo specifies a new Type (the Key ID Information Type) for the
General Extension Payload in the Multimedia Internet KEYing (MIKEY)
Protocol. This is used in, for example, the Multimedia
Broadcast/Multicast Service specified in the Third Generation
Partnership Project.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Rationale .......................................................2
3. Relations to MIKEY and GKMARCH ..................................3
4. The Key ID Information Type for the General Extension Payload ...4
5. Empty Map Type Definition for the CS ID Map Type ................5
6. Transport Considerations ........................................5
7. Security Considerations .........................................5
8. IANA Considerations .............................................7
9. Acknowledgements ................................................7
10. References .....................................................8
10.1. Normative References ......................................8
10.2. Informative References ....................................8
1. Introduction
The Third Generation Partnership Project (3GPP) is currently involved
in the development of a multicast and broadcast service, the
Multimedia Broadcast/Multicast Service (MBMS), and its security
architecture [MBMS].
[MBMS] requires the use of the Multimedia Internet KEYing (MIKEY)
Protocol [RFC3830] to convey the keys and related security parameters
needed to secure multimedia that is multicast or broadcast.
One of the requirements that MBMS puts on security is the ability to
perform frequent updates of the keys. The rationale behind this is
that it will be costly for subscribers to re-distribute the
decryption keys to non-subscribers. The cost for re-distributing the
keys using the unicast channel should be higher than the cost of
purchasing the keys for this scheme to have an effect. To implement
this, MBMS uses a three-level key management, to distribute group
keys to the clients, and be able to re-key by pushing down a new
group key. As illustrated in the section below, MBMS has the need to
identify which types of keys are involved in the MIKEY message and
their identity.
This memo specifies a new Type for the General Extension Payload in
MIKEY, to identify the type and identity of keys involved.
1.1. Conventions Used in This Document
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 [RFC2119].
2. Rationale
An application where this extension is used is MBMS key management.
The key management solution adopted by MBMS uses three-level key
management. The keys are used in the way described below. "Clients"
refers to the clients who have subscribed to a given
multicast/broadcast service.
* The MBMS User Key (MUK), a point-to-point key between the multicast
server and each client.
* The MBMS Service Key (MSK), a group key between the multicast
server and all the clients.
* The MBMS Traffic Key (MTK), a group traffic key between the
multicast server and all clients.
The Traffic Keys are the keys that are regularly updated.
The point-to-point MUK (first-level key) is shared between the
multicast server and the client via means defined by MBMS [MBMS].
The MUK is used as a pre-shared key to run MIKEY with the pre-shared
key method [RFC3830], and to deliver (point-to-point) the MSK. The
same MSK is pushed to all the clients, to be used as a (second-level)
group key.
Then, the MSK is used to push to all the clients an MTK (third-level
key), the actual group key that is used for the protection of the
media traffic. For example, the MTK could be the master key for the
Secure Real-time Transport Protocol (SRTP) [RFC3711] in the streaming
case.
A Key Domain identifier defines the domain where the group keys are
valid or applicable. For example, it may define a specific service
provider.
To allow the key distribution described above, an indication of the
type and identity of keys being carried in a MIKEY message is needed.
This indication is carried in a new Type of the General Extension
Payload in MIKEY.
It is necessary to specify what Crypto Session ID (CS ID) map type is
associated with a given key. There are cases (for example, the
download case in MBMS) where the required parameters are signalled
in-band (each downloaded Digital Rights Management Content Format
object [DCF] contains the necessary parameters needed by the receiver
to process it). Since the parameters are not transported by MIKEY,
this implies that a CS ID map type needs to be registered to the
"empty map", as defined in Table 3, which is to be used when the
map/policy information is conveyed outside of MIKEY.
3. Relations to MIKEY and GKMARCH
According to [RFC3830], MIKEY is a registration protocol that
supports re-keying for unicast in the terms of the MSEC Group Key
Management Architecture [RFC4046]. MBMS uses MIKEY both as a
registration protocol and a re-key protocol, and the specified
extension implements the necessary additions to [RFC3830] that allows
MIKEY to function both as a unicast and multicast re-key protocol in
the MBMS setting.
4. The Key ID Information Type for the General Extension Payload
The General Extension payload in MIKEY is defined in Section 6.15 of
[RFC3830]. The General Extension payload type (Key ID Information)
defined in the present document is not restricted to MBMS.
Applications using this General Extension payload type may define new
Key ID types, and these applications MUST define the semantics and
usage of the Key ID Type sub-payloads according to Section 8. The
MBMS use of the Key ID Type sub-payloads, defined in Table 2, is
specified in [MBMS].
The Key ID Information Type (Type 3) formats the General Extension
payload as follows:
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 payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Key ID Information General Extension Payload
Next Payload and Length are defined in Section 6.15 of [RFC3830].
* Type (8 bits): identifies the type of the General Extension
Payload [RFC3830]. This memo adds Type 3 to the ones already
defined in [RFC3830].
Type | Value | Comments
------------------------------------------------------------
Key ID | 3 | information on type and identity of keys
Table 1. Definition of the New General Extension Payload
* Key ID Information (variable length): the general payload data
transporting the type and identifier of a key. This field is
formed by Key ID Type sub-payloads as specified below.
The Key ID Type sub-payload is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Type ! Key ID Length ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The Key ID Type Sub-payload
* Key ID Type (8 bits): describes the type of the key ID.
Predefined types are listed in Table 2.
Key ID Type | Value | Comment
-----------------------------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Traffic Key ID | 2 | ID of the group traffic key
Table 2. Type definitions for Key IDs
* Key ID Length (8 bits): describes the length of the Key ID
field in octets.
* Key ID (variable length): defines the identity of the key.
Note that there may be more than one Key ID Type sub-payload in an
extension, and that the overall length (i.e., the sum of lengths of
all Key ID Type sub-payloads) of the Key ID information field cannot
exceed 2^16 - 1 octets.
5. Empty Map Type Definition for the CS ID Map Type
When the security policy information is conveyed outside of MIKEY,
the CS ID map type is set to a value defined in Table 3 to indicate
"empty map". In this case, there MUST NOT be any Security Policy
payload present in the message.
CS ID map type | Value | Comments
-------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
Table 3. Definition of the CS ID Map Type.
6. Transport Considerations
As specified in Section 7 of [RFC3830], the underlying transport of
the MIKEY protocol has to be defined for each type of transport.
When the Key-ID payload is used with MBMS, the transport is UDP, and
the usage of MIKEY over UDP in the MBMS setting is defined in [MBMS].
7. Security Considerations
The usage of MIKEY for updating the traffic encryption key (MTK) in
the broadcast manner, described in Section 2, deviates from the way
MIKEY [RFC3830] was originally designed. There are two main points
that are related to the security of the described usage.
First, the delivery of the MTK is not source origin authenticated,
but rather protected by a group MAC, keyed by the group key (MSK).
The threat this raises is that users that are part of the group are
able to send fake MTK messages to other group members. The origin of
the MTK messages is a node inside the core network, and the trust
model used in MBMS is that only trusted traffic is allowed to be sent
(from within the operator's network) on the MBMS bearers. However,
there is always the risk that traffic is injected on the air
interface between the base stations and the user equipment. It is
possible for members of the group (i.e., with access to the MSK) to
spoof MTK updates to other members of the group. 3GPP decided that
the technical difficulties and costs involved in performing such an
attack are large enough compared to the expected gain for the
attacker, that the risk was deemed acceptable. Note that, since the
delivery of the MTK is not source origin authenticated, there is
nothing gained by adding source origin authentication to the RTP
streams (e.g., using SRTP-TESLA [RFC4383]). Hence, the current use
of the specified extension is not compatible with SRTP-TESLA, which
requires source origin authentication of the integrity key.
Note that in MBMS the MSK is protected end-to-end, from the multicast
server to the clients, using a client-unique key MUK, but the MTK is
delivered under protection by the group key MSK, so source origin
authentication is not achieved.
Secondly, the delivery of the MTK is separated from the delivery of
the security policy. The security policy is delivered with the MSK.
The delivery of the MTKs is assumed to be frequent (some scenarios
require the delivery of MTKs to be as frequent as a few seconds
apart). This would imply that the cost (in terms of bandwidth) would
be very high if the security policy was delivered together with each
MTK. Furthermore, the security policy parameters of the streaming
session are not anticipated to change during the session, even though
there would be an update of the MTK. It was decided in 3GPP that
there was no need for updating the policy during an ongoing session,
and that the cost of allowing such a feature, only to be on the safe
side, would be too high. On the other hand, updating the security
policy during an ongoing session would be possible by updating the
MSK.
The Empty map type used when the security policy is delivered in band
relies on the security provided by DCF [DCF], and MIKEY is, in this
case, only used to provide the master key for the DCF processing.
8. IANA Considerations
According to Section 10 of RFC 3830, IETF consensus is required to
register values in the range 0-240 in the Type namespace of the MIKEY
General Extension Payload and the CS ID map type namespace of the
Common Header Payload.
A new value in the MIKEY General Extension Payload Type name space
has been registered for this purpose. The registered value for Key
ID is 3 according to Section 4.
Also, the value 1 has been registered for the Empty map in the
existing CS ID map namespace of the Common Header Payload, as
specified in Table 3, in Section 5.
The new name space for the following field in the Key ID information
sub-payload (from Sections 4 and 5) has been established and will be
managed by IANA:
* Key ID Type
The IANA has registered the pre-defined types of Table 2 for this
namespace. IANA will also manage the definition of additional values
in the future. Values in the range 0-240 for each name space SHOULD
be approved by the process of IETF consensus, and values in the range
241-255 are reserved for Private Use, according to [RFC2434].
9. Acknowledgements
We would like to thank Fredrik Lindholm.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Security; Security of
Multimedia Broadcast/Multicast Service".
10.2. Informative References
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[DCF] Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM
Content Format V2.0", Candidate Version 2.0 - 29 March
2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February
2006.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Authors' Addresses
Elisabetta Carrara
Royal Institute of Technology
Stockholm
Sweden
EMail: carrara@kth.se
Vesa Lehtovirta
Ericsson Research
02420 Jorvas
Finland
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Karl Norrman
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ISO Plain Language
On this page
§1Introduction
The Third Generation Partnership Project (3GPP) is involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture. MBMS requires the use of the Multimedia Internet KEYing protocol to convey the keys and related security parameters needed to secure multimedia that is multicast or broadcast.
One of the requirements MBMS puts on security is the ability to perform frequent updates of the keys. The rationale is that it will be costly for subscribers to redistribute the decryption keys to non-subscribers, and the cost of redistributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To implement this, MBMS uses a three-level key management to distribute group keys to the clients and to be able to re-key by pushing down a new group key. MBMS therefore needs to identify which types of keys are involved in the MIKEY message and their identity.
This memo specifies a new type for the General Extension payload in MIKEY, to identify the type and identity of keys involved.
Broadcast services change their keys often, because handing a new key to every subscriber by unicast message would be far too expensive. To re-key often, a receiver has to be told which of several keys a message is about.
§2The Three-Level Key Management of MBMS
An application where this extension is used is MBMS key management, which uses three levels of keys. Clients refers to the clients who have subscribed to a given multicast or broadcast service.
- The MBMS User Key (MUK) is a point-to-point key between the multicast server and each client.
- The MBMS Service Key (MSK) is a group key between the multicast server and all the clients.
- The MBMS Traffic Key (MTK) is a group traffic key between the multicast server and all clients.
The Traffic Keys are the keys that are regularly updated. The point-to-point MUK is shared between the multicast server and the client, and is used as a pre-shared key to run MIKEY with the pre-shared key method and to deliver the MSK point-to-point. The same MSK is pushed to all the clients to be used as a second-level group key. The MSK is then used to push to all the clients an MTK, the third-level key, which is the actual group key used for the protection of the media traffic. For example, the MTK could be the master key for the Secure Real-time Transport Protocol in the streaming case.
A Key Domain identifier defines the domain where the group keys are valid or applicable, for example a specific service provider. To allow the key distribution described above, an indication of the type and identity of the keys being carried in a MIKEY message is needed, and this indication is carried in the new Type of the General Extension payload.
MBMS nests its keys. A per-subscriber key unlocks a service key shared by everyone, and the service key unlocks the traffic key that actually protects the media. Only the traffic key changes often, and each level has to be named in the message that carries it.
- MBMS User Key (MUK) Point-to-point key between the multicast server and each client.
- MBMS Service Key (MSK) Group key between the multicast server and all the clients.
- MBMS Traffic Key (MTK) Group traffic key that protects the media traffic. The level that is updated often.
- MBMS Service Key (MSK) Group key between the multicast server and all the clients.
§3How the Extension Fits MIKEY
According to RFC 3830, MIKEY is a registration protocol that supports re-keying for unicast in the terms of the MSEC Group Key Management Architecture. MBMS uses MIKEY both as a registration protocol and as a re-key protocol, and the specified extension implements the necessary additions to RFC 3830 that allow MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
It is also necessary to specify what Crypto Session ID map type is associated with a given key. There are cases, for example the download case in MBMS, where the required parameters are signalled in-band, each downloaded Digital Rights Management Content Format object containing the parameters needed by the receiver to process it. Since those parameters are not transported by MIKEY, a Crypto Session ID map type needs to be registered to the empty map, to be used when the map and policy information are conveyed outside of MIKEY.
MIKEY was designed for one-to-one sessions. Using it for a broadcast means adding the missing pieces: the ability to name the kind of key, and a way to say that the session mapping is not carried in this message at all.
- MUKShared point-to-point and used as the pre-shared key for MIKEY.
- MSKDelivered point-to-point under the MUK, and pushed to all clients as the second-level group key.
- MTKPushed to all clients under the MSK as the third-level key that protects the media.
§4The Key ID Information Payload
The General Extension payload in MIKEY is defined in section 6.15 of RFC 3830. The General Extension payload type defined here, the Key ID Information, is not restricted to MBMS. Applications using this General Extension payload type may define new Key ID types, and these applications must define the semantics and usage of the Key ID Type sub-payloads according to section 8 of this document. The MBMS use of the Key ID Type sub-payloads is specified in the 3GPP specification.
The Key ID Information Type, number 3, formats the General Extension payload with a Next Payload field, a Type field and a Length field, followed by the Key ID Information field, which is the general payload data transporting the type and identifier of a key and is formed by Key ID Type sub-payloads. Next Payload and Length are defined in section 6.15 of RFC 3830. The Type field is 8 bits and identifies the type of the General Extension payload; this memo adds Type 3 to the ones already defined in RFC 3830.
The Key ID Type sub-payload carries a Key ID Type field of 8 bits that describes the type of the key ID, a Key ID Length field of 8 bits that describes the length of the Key ID field in octets, and a Key ID field of variable length that defines the identity of the key. The predefined Key ID types are 0 for the MBMS Key Domain ID, the ID of the group key domain; 1 for the MBMS Service Key ID, the ID of the group key; and 2 for the MBMS Traffic Key ID, the ID of the group traffic key.
There may be more than one Key ID Type sub-payload in an extension, and the overall length, the sum of the lengths of all Key ID Type sub-payloads, of the Key ID information field cannot exceed 2^16 - 1 octets.
The new payload holds a list of small sub-payloads. Each one says which kind of key it is talking about and then carries that key's identifier. Several can appear in one message, and the whole list must stay under 65535 octets.
- 0MBMS Key Domain ID — ID of the group key domain.
- 1MBMS Service Key ID — ID of the group key.
- 2MBMS Traffic Key ID — ID of the group traffic key.
§5The Empty Map CS ID Map Type
When the security policy information is conveyed outside of MIKEY, the Crypto Session ID map type is set to the value defined for the empty map, which is 1. In this case there must not be any Security Policy payload present in the message.
This value exists because the map and policy information is sometimes delivered in band, as part of the protected content itself, and in that case the MIKEY message has nothing to map. The empty map says exactly that, so that a receiver does not go looking for a policy that was never sent.
Sometimes the rules for a session travel inside the content rather than inside the key message. The empty map value records that, so nobody waits for a security policy that is not coming.
§6Transport Considerations
As specified in section 7 of RFC 3830, the underlying transport of the MIKEY protocol has to be defined for each type of transport. When the Key ID payload is used with MBMS, the transport is UDP, and the usage of MIKEY over UDP in the MBMS setting is defined in the 3GPP specification.
MIKEY needs a transport named for each kind of network. For the broadcast service the transport is UDP, and the 3GPP specification says how it is used there.
§7Security Considerations
The usage of MIKEY for updating the traffic encryption key in the broadcast manner deviates from the way MIKEY was originally designed. Two main points relate to the security of the described usage.
First, the delivery of the traffic key is not source origin authenticated, but is protected by a group MAC keyed by the service key. The threat this raises is that users who are part of the group can send fake traffic key messages to other group members. The origin of the traffic key messages is a node inside the core network, and the trust model used in MBMS is that only trusted traffic is allowed to be sent, from within the operator's network, on the MBMS bearers. There is always the risk that traffic is injected on the air interface between the base stations and the user equipment, so it is possible for members of the group to spoof traffic key updates to other members. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker that the risk was deemed acceptable. Since the delivery of the traffic key is not source origin authenticated, there is nothing gained by adding source origin authentication to the RTP streams, for example using SRTP-TESLA, and the use of the specified extension is therefore not compatible with SRTP-TESLA, which requires source origin authentication of the integrity key. In MBMS the service key is protected end-to-end from the multicast server to the clients using the client-unique MUK, but the traffic key is delivered under protection by the service key, so source origin authentication is not achieved.
Second, the delivery of the traffic key is separated from the delivery of the security policy. The security policy is delivered with the service key. The delivery of the traffic keys is assumed to be frequent, and some scenarios require it to be as frequent as a few seconds apart, which would make the bandwidth cost very high if the security policy were delivered together with each traffic key. The security policy parameters of the streaming session are not anticipated to change during the session, even though the traffic key is updated, so 3GPP decided there was no need for updating the policy during an ongoing session. Updating the policy during an ongoing session would still be possible by updating the service key.
The empty map type used when the security policy is delivered in band relies on the security provided by the Digital Rights Management Content Format, and MIKEY is in that case only used to provide the master key for the content processing.
Two things are weaker than in ordinary MIKEY. The traffic key is protected by the shared service key, so anyone who has that key could try to send a fake update, and 3GPP judged the cost of that attack high enough to accept the risk. The rules for the session travel with the service key rather than with each traffic key update, because they rarely change.
- No source authentication on the traffic keyThe traffic key is protected by a group MAC keyed by the service key, so group members can try to spoof updates. 3GPP judged the risk acceptable.
- Not compatible with SRTP-TESLASRTP-TESLA requires source origin authentication of the integrity key, which this delivery method does not provide.
- Policy delivered apart from the keyThe security policy travels with the service key, because traffic key updates can be a few seconds apart and carrying the policy each time would be costly.
§8IANA Considerations
According to section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension payload and in the CS ID map type namespace of the Common Header payload.
A new value in the MIKEY General Extension payload Type namespace has been registered, and the registered value for Key ID is 3. The value 1 has also been registered for the empty map in the existing CS ID map namespace of the Common Header payload.
A new namespace for the Key ID Type field has been established and will be managed by IANA. The IANA has registered the predefined types of the Key ID table, and will also manage the definition of additional values in the future. Values in the range 0-240 for each namespace should be approved by the process of IETF consensus, and values in the range 241-255 are reserved for Private Use, according to RFC 2434.
IANA now keeps three new lists: the payload types, the key identifier types and the empty map value. Ordinary values are agreed by IETF consensus, and the top fifteen are left for private use.