idnits 2.17.1 draft-carrara-newtype-keyid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 248. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 130 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MBMS' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Carrara, Lehtovirta, Norrman 2 (Ericsson) 3 INTERNET-DRAFT 4 EXPIRES: April 2005 October 2004 6 The Key ID Information Type for the General Extension Payload in MIKEY 7 9 Status of this memo 11 By submitting this Internet-Draft, the authors certify that any 12 applicable patent or other IPR claims of which I am (we are) aware 13 have been disclosed, and any of which I (we) become aware will be 14 disclosed, in accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, the authors accept the provisions 17 of Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This document is an individual submission to the IETF. Comments 36 should be directed to the authors. 38 Abstract 40 This memo specifies a new Type (the Key ID Information Type) for the 41 General Extension Payload in the Multimedia Internet KEYing 42 Protocol. This is used in the Multimedia Broadcast/Multicast Service 43 specified in the 3rd Generation Partnership Project. 45 TABLE OF CONTENTS 47 1. Introduction...................................................2 48 2. The MBMS key management........................................2 49 3. The Key ID Information Type for the General Extension Payload..3 50 4. Security Considerations........................................5 51 5. IANA Considerations............................................5 52 6. Acknowledgements...............................................5 53 7. Author's Addresses.............................................5 54 8. References.....................................................6 56 1. Introduction 58 The 3rd Generation Partnership Project (3GPP) is currently involved 59 in the development of a multicast and broadcast service, the 60 Multimedia Broadcast/Multicast Service (MBMS), and its security 61 architecture [MBMS]. This service is specified for 3GPP Release 6. 63 [MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) 64 Protocol [RFC3830], to convey the keys and related security 65 parameters needed to secure the media that is multicast or 66 broadcast. For the streaming scenario, the security protocol used to 67 protect the media is the Secure Real-time Transport Protocol (SRTP) 68 [RFC3711]. 70 One of the requirements that MBMS puts on security is the 71 possibility to perform frequent updates of the keys. The rationale 72 behind this is that it should be inconvenient for subscribers to 73 publish the decryption keys enabling non-subscribers to view the 74 content. To implement this, MBMS uses a three level key management, 75 to distribute group keys to the clients, and be able to re-key by 76 pushing down a new group key. As illustrated in the section below, 77 MBMS has the need to identify which types of key are involved in the 78 MIKEY message, and their identity. 80 This memo specifies a new Type for the General Extension Payload in 81 MIKEY, to identify the type and identity of involved keys. 83 2. The MBMS key management 85 The key management solution adopted by MBMS uses a three level key 86 management. The keys are used in the way described below. "Clients" 87 refers to the clients who have subscribed to a given 88 multicast/broadcast service. 90 - 91 the User Key (MUK), one point-to-point key between the multicast 92 server and each client 94 - 95 the Service Key (MSK), one group key between the multicast server 96 and all the clients 98 - 99 the Traffic Key (MTK), one group traffic key between the multicast 100 server and all clients. 102 The Traffic Keys are the keys that are regularly updated. 104 The point-to-point MUK key (first-level key) is shared between the 105 multicast server and the client via means defined by MBMS [MBMS]. 106 The MUK is used as pre-shared key to run MIKEY with the pre-shared 107 key method [RFC3830], to deliver (point-to-point) the MSK key. The 108 same MSK key is pushed to all the clients, to be used as a (second- 109 level) group key. 111 Then, the MSK is used to push to all the clients an MTK key (third- 112 level key), the actual group key that is used for the protection of 113 the media traffic. The MTK is, in other words, the master key for 114 SRTP in the streaming case. 116 To allow this distribution, an indication of the type and identity 117 of involved keys in the MIKEY message is needed. This indication is 118 carried in a new Type of the General Extension Payload in MIKEY. 120 3. The Key ID Information Type for the General Extension Payload 122 The General Extension payload in MIKEY is defined in Section 6.15 of 123 [RFC3830]. 125 The Key ID Information Type (Type 2) formats the General Extension 126 payload as follows: 128 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 ! Next payload ! Type ! Length ! 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 ! Key ID Information ~ 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Next Payload and Length are defined in Section 6.15 of [RFC3830]. 138 * Type (8 bits): identifies the type of the General Payload 139 [RFC3830]. This memo adds Type 2 to the ones already defined in 140 [RFC3830]. 142 Type | Value | Comments 143 ------------------------------------------------------------ 144 keyid | 2 | information on type and identity of keys 146 Table 1. 148 * Key ID Information (variable length): the general payload data 149 transporting the type and identifier of a key. This field is formed 150 by Key Type ID sub-payloads as specified below. 152 The Key Type ID sub-payload is formatted as follows: 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 ! Key Type ! Key ID Length ! Key ID ~ 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 * Key Type (8 bits): describes the type of the key. Predefined 159 types are listed in Table 2. 161 Key Type | Value | Comment 162 -------------------------------------- 163 MBMS User Key | 0 | User key (point-to-point) 164 MBMS Service Key | 1 | Group key 165 MBMS Transport Key | 2 | Group traffic key 167 Table 2. 169 * Key ID Length (8 bits): describes the length of the Key ID 170 field in bytes. 172 * Key ID (variable length): defines the identity of the key. 174 Note that there may be more than one Key Type ID sub-payload in an 175 extension, and that the overall length of the Key Identifier ID 176 field cannot exceed 2^16 bytes. 178 4. Security Considerations 180 This memo is not foreseen to introduce security implications. For 181 the security considerations of the MIKEY protocol, see [RFC3830]. 183 5. IANA Considerations 185 A new MIKEY General Extension Payload Type needs to be registered 186 for this purpose. The registered value is requested to be 2 187 according to Section 3. 189 The name spaces for the following fields in the General Extensions 190 payload (from Section 3) are requested to be managed by IANA: 192 * Key Type (Table 2). 194 6. Acknowledgements 196 We would like to thank Fredrik Lindholm. 198 7. Author's Addresses 200 Questions and comments should be directed to the authors: 202 Elisabetta Carrara 203 Ericsson Research 204 SE-16480 Stockholm Phone: +46 8 50877040 205 Sweden EMail: elisabetta.carrara@ericsson.com 207 Vesa Lehtovirta 208 Ericsson Research 209 02420 Jorvas Phone: +358 9 2993314 210 Finland EMail: vesa.lehtovirta@ericsson.com 212 Karl Norrman 213 Ericsson Research 214 SE-16480 Stockholm Phone: +46 8 4044502 215 Sweden EMail: karl.norrman@ericsson.com 217 8. References 219 Normative 221 [MBMS] 3GPP TS 33.246 V6.0.0 (2004-09), Technical Specification 3rd 222 Generation Partnership Project; Technical Specification Group 223 Services and System Aspects; Security; Security of Multimedia 224 Broadcast/Multicast Service (Release 6) 226 [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC 227 3830, August 2004. 229 Informative 231 [RFC3711] Baugher et al., "The Secure Real-time Transport Protocol 232 (SRTP)", RFC3711, March 2004. 234 Copyright Notice 236 Copyright (C) The Internet Society (2004). This document is subject 237 to the rights, licenses and restrictions contained in BCP 78, and 238 except as set forth therein, the authors retain all their rights. 240 Disclaimer of Validity 242 This document and the information contained herein are provided on 243 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 244 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 245 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 246 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 247 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 248 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 250 This draft expires in April 2005.