Subject: [MSEC] WGLC draft-ietf-msec-newtype-keyid-03.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Dec 2005 13:38:02 -0800

Hi all,

This revision has been available for ~3 weeks,  I will give another 
week until next Monday Dec 26th, 2005 for any comments.  Only the 
revisions between -02- and -03- are open for discussion.

thanks and regards,
Lakshminath

>Subject: Submission of draft-ietf-msec-newtype-keyid-03.txt
>Date: Wed, 30 Nov 2005 13:47:11 +0100
>X-MS-Has-Attach: yes
>X-MS-TNEF-Correlator:
>Thread-Topic: Submission of draft-ietf-msec-newtype-keyid-03.txt
>Thread-Index: AcX1rC68KKQSrlAoQumv1mc773DjsQ==
>From: "Karl Norrman (KI/EAB)" <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>
>X-OriginalArrivalTime: 30 Nov 2005 12:47:13.0165 (UTC) 
>FILETIME=[2F98CBD0:01C5F5AC]
>X-Brightmail-Tracker: AAAAAA==
>X-PMX-Version: 4.7.0.111621
>X-PMX-Version: 4.6.0.99824, Antispam-Engine: 2.1.0.0, Antispam-Data: 
>2005.11.30.8
>
>Dear Editor,
>
>please submit the new version of draft-ietf-msec-newtype-keyid-03.txt,
>work item in the msec WG.
>
>Best Regards,
>Karl Norrman
>Ericsson
>

   Internet Engineering Task Force                       Carrara (KTH)
                                        Lehtovirta, Norrman (Ericsson)
   INTERNET-DRAFT
   EXPIRES: June 2006                                    December 2005

 The Key ID Information Type for the General Extension Payload in MIKEY
                 <draft-ietf-msec-newtype-keyid-03.txt>

Status of this memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in June 2006.

Abstract

   This memo specifies a new Type (the Key ID Information Type) for the
   General Extension Payload in the Multimedia Internet KEYing
   Protocol. This is used in, e.g., the Multimedia Broadcast/Multicast
   Service specified in the 3rd Generation Partnership Project.


INTERNET-DRAFT               newtype-keyid             December, 2005

   TABLE OF CONTENTS

    1. Introduction...................................................2
    2. Rationale......................................................2
    3. The Key ID Information Type for the General Extension Payload..3
    4. Empty map type definition for the CS ID map type...............5
    5. Security Considerations........................................5
    6. IANA Considerations............................................6
    7. Acknowledgements...............................................7
    8. Author's Addresses.............................................7
    9. References.....................................................7

1. Introduction

   The 3rd 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 the 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 would be inconvenient for subscribers to publish the
   decryption keys enabling non-subscribers to view the content. 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 key 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.

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.

Carrara et al.                                                [Page 2]

INTERNET-DRAFT               newtype-keyid             December, 2005

   * The MBMS User Key (MUK), point-to-point key between the multicast
     server and each client

   * The MBMS Service Key (MSK), group key between the multicast server
     and all the clients

   * The MBMS Traffic Key (MTK), 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 key (first-level key) is shared between the
   multicast server and the client via means defined by MBMS [MBMS].
   The MUK is used as pre-shared key to run MIKEY with the pre-shared
   key method [RFC3830], to deliver (point-to-point) the MSK key. The
   same MSK key 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 key (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
   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 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 DCF-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. The Key ID Information Type for the General Extension Payload

   The General Extension payload in MIKEY is defined in Section 6.15 of
   [RFC3830].

Carrara et al.                                                [Page 3]

INTERNET-DRAFT               newtype-keyid             December, 2005

   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.

Carrara et al.                                                [Page 4]

INTERNET-DRAFT               newtype-keyid             December, 2005

         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 Transport 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. Applications using this general extension
   payload have to define the semantics and usage of the Key ID Type
   sub-payloads.

4. 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 value defined in Table 3 to indicate
   "empty map".

          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.

5. 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 mainly two 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).

Carrara et al.                                                [Page 5]

INTERNET-DRAFT               newtype-keyid             December, 2005

   The threat this raises is that users that are part of the group are
   able to send faked 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 on the MBMS bearers (from within the operator's network).
   However, there is always the risk that traffic is injected in 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.

   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 very 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 identified need for updating the
   policy during an ongoing session, and 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.

6. 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 MIKEY General Extension Payload Type needs to be registered
   for this purpose. The registered value for Key ID is requested to be
   3 according to Section 3.

   It is also requested to register the value 1 for the Empty map in
   the CS ID map namespace of the Common Header Payload as specified in
   Table 3 in Section 4.

   The name space for the following field in the Key ID information
   sub-payload (from Sections 3 and 4) is requested to be managed by
   IANA:

Carrara et al.                                                [Page 6]

INTERNET-DRAFT               newtype-keyid             December, 2005

   * Key ID Type

   It is requested that IANA register the pre-defined types of Table 2
   for this namespace.

7. Acknowledgements

   We would like to thank Fredrik Lindholm.

8. Author's Addresses

   Questions and comments should be directed to the authors:

      Elisabetta Carrara
      Royal Institute of Technology
      Stockholm              Phone:
      Sweden                 EMail:  [email-masked]

      Vesa Lehtovirta
      Ericsson Research
      02420 Jorvas           Phone:  +358 9 2993314
      Finland                EMail:  [email-masked]

      Karl Norrman
      Ericsson Research
      SE-16480 Stockholm     Phone:  +46 8 4044502
      Sweden                 EMail:  [email-masked]

9. References

   Normative

   [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC
   3830, August 2004.

   Informative

   [RFC3711] Baugher et al., "The Secure Real-time Transport Protocol
   (SRTP)", RFC3711, March 2004.

   [MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation
   Partnership Project; Technical Specification Group Services and

Carrara et al.                                                [Page 7]

INTERNET-DRAFT               newtype-keyid             December, 2005

   System Aspects; Security; Security of Multimedia Broadcast/Multicast
   Service."

   [DCF]  OMA, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0",
   Candidate Version 2.0 - 29 March 2005

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-
   [email-masked].

Copyright Notice

   Copyright (C) The Internet Society (2005).  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.

Disclaimer of Validity

   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

Carrara et al.                                                [Page 8]

INTERNET-DRAFT               newtype-keyid             December, 2005

   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   This Internet-Draft will expire in June 2006.

Carrara et al.                                                [Page 9]


_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec