doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4563.txt b/doc/rfc/rfc4563.txt
new file mode 100644
index 0000000..4048f54
--- /dev/null
+++ b/doc/rfc/rfc4563.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+