    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

    Carrara, et al.             Standards Track                     [Page 1]

    RFC 4563          Key ID for General Extension Payload         June 2006

    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.

    Carrara, et al.             Standards Track                     [Page 2]

    RFC 4563          Key ID for General Extension Payload         June 2006

       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.

    Carrara, et al.             Standards Track                     [Page 3]

    RFC 4563          Key ID for General Extension Payload         June 2006

    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

    Carrara, et al.             Standards Track                     [Page 4]

    RFC 4563          Key ID for General Extension Payload         June 2006

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

    Carrara, et al.             Standards Track                     [Page 5]

    RFC 4563          Key ID for General Extension Payload         June 2006

       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.

    Carrara, et al.             Standards Track                     [Page 6]

    RFC 4563          Key ID for General Extension Payload         June 2006

    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.

    Carrara, et al.             Standards Track                     [Page 7]

    RFC 4563          Key ID for General Extension Payload         June 2006

    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.

    Carrara, et al.             Standards Track                     [Page 8]

    RFC 4563          Key ID for General Extension Payload         June 2006

    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

    Carrara, et al.             Standards Track                     [Page 9]

    RFC 4563          Key ID for General Extension Payload         June 2006

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

    Carrara, et al.             Standards Track                    [Page 10]