idnits 2.17.1 draft-arkko-mikey-iana-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3830, updated by this document, for RFC5378 checks: 2001-11-13) -- 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 (May 20, 2011) is 4718 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5410 ** Downref: Normative reference to an Informational RFC: RFC 6043 -- Obsolete informational reference (is this intentional?): RFC 4909 (Obsoleted by RFC 5410, RFC 6309) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Keranen 4 Obsoletes: 4909 (if approved) J. Mattson 5 Updates: 3830, 4563, 5410, 6043 Ericsson 6 (if approved) May 20, 2011 7 Intended status: Standards Track 8 Expires: November 21, 2011 10 IANA Rules for MIKEY (Multimedia Internet KEYing) 11 draft-arkko-mikey-iana-01 13 Abstract 15 This document clarifies and relaxes the IANA rules for Multimedia 16 Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 17 5410, 6043, and obsoletes RFC 4909. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 21, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 This document relaxes the IANA rules for Multimedia Internet KEYing 54 (MIKEY) [RFC3830]. The IANA rules defined in [RFC3830], [RFC4563], 55 [RFC4909], and [RFC5410] are affected. In addition, the rules 56 specified in [RFC6043] are re-specified here. 58 Most of the values in MIKEY namespaces are divided into two ranges: 59 "IETF Review" (or "IETF Consensus" as it was previously called) and 60 "Reserved for Private Use" [RFC5226]. This document changes, for 61 majority of the namespaces, the requirement of "IETF Review" into 62 "IETF Review or IESG Approval" [RFC5226]. For some namespaces, the 63 requirement is changed to "Specification Required" [RFC5226]. 65 The rationale for this update is that there can be situations where 66 it makes sense to grant an allocation under special circumstances or 67 that time has shown that the current requirement is unnecessarily 68 strict for some of the namespaces. By changing the current IANA 69 rules to allow also for IESG Approval [RFC5226], it becomes possible 70 for the Internet Engineering Steering Group (IESG) to consider an 71 allocation request, even if it does not fulfill the default rule. 72 For instance, an experimental protocol extension could perhaps 73 deserve a new payload type as long as a sufficient number of types 74 still remains, and the MIKEY community is happy with such an 75 allocation. Moreover, for some registries a stable specification 76 would be a sufficient requirement and hence this is reflected in the 77 updated IANA rules. For instance, for some registries an RFC via the 78 Independent Stream at the RFC Editor is sufficient, and does not 79 force an IETF evaluation of a particular new extension for which 80 there is no general demand. 82 This document also makes some small corrections to the existing IANA 83 registries. (RFC Editor: Please remove this paragraph upon 84 publication as an RFC.) 86 The rest of this document is structured as follows. Section 2 87 defines the new IANA rules. Section 3 discusses the security 88 implications of this document. Section 4, Section 5, Section 6, and 89 Section 7, explain the changes to the RFCs 3830, 4563, 4909, 5410, 90 and 6043. 92 2. IANA Considerations 94 IANA is requested to update the registries related to MIKEY as 95 specified below. All other MIKEY IANA registries are to remain 96 unchanged. 98 A registry for the version field should be created, with the value 99 0x01 as the only currently allocated item. (RFC Editor: Please 100 remove the preceding sentence upon publication as an RFC.) New 101 values for the version field ([RFC3830], Section 6.1) and the C 102 envelope key cache indicator ([RFC3830], Section 6.3) field can be 103 allocated via IETF Review. 105 The requirement for adding new values into name spaces, originally 106 defined in [RFC3830], and having requirement of "IETF Review" is to 107 be changed into "IETF Review or IESG Approval". This change affects 108 the following namespaces: 110 o Data type ([RFC3830], Section 6.1) 112 o Next payload ([RFC3830], Section 6.1) 114 o PRF func ([RFC3830], Section 6.1) 116 o CS ID map type ([RFC3830], Section 6.1) 118 o Encr alg ([RFC3830], Section 6.2) 120 o MAC alg ([RFC3830], Section 6.2) 122 o DH-Group ([RFC3830], Section 6.4) 124 o S type ([RFC3830], Section 6.5) 126 o TS type ([RFC3830], Section 6.6) 128 o ID type ([RFC3830], Section 6.7) 130 o Cert type ([RFC3830], Section 6.7) 132 o Hash func ([RFC3830], Section 6.8) 134 o SRTP Type ([RFC3830], Section 6.10) 136 o SRTP encr alg ([RFC3830], Section 6.10) 138 o SRTP auth alg ([RFC3830], Section 6.10) 140 o SRTP PRF ([RFC3830], Section 6.10) 141 o FEC order ([RFC3830], Section 6.10) 143 o Key Data Type ([RFC3830], Section 6.13) 145 o KV Type ([RFC3830], Section 6.13) 147 The "IETF Review" requirement for the following registries, 148 originally defined in [RFC3830], [RFC4563], [RFC4909] and [RFC5410], 149 is to be changed into "Specification Required". 151 o Prot type ([RFC3830], Section 6.10) 153 o Error no ([RFC3830], Section 6.12) 155 o General Extension Type ([RFC3830], Section 6.15) 157 o KEY ID Type ([RFC4563], Section 4) 159 o OMA BCAST Types ([RFC5410], Section 3) 161 The "Specification Required" requirement remains for the following 162 namespaces: 164 o TS Role ([RFC6043], Section 6.4) 166 o ID Role ([RFC6043], Section 6.6) 168 o RAND Role ([RFC6043], Section 6.8) 170 o Ticket Type ([RFC6043], Section 6.10) 172 The range of valid values for certain namespaces defined in IANA 173 considerations of [RFC3830] was not explicitly defined and is 174 clarified here as follows: 176 +--------------------------------+--------------+ 177 | Namespace | Valid values | 178 +--------------------------------+--------------+ 179 | C envelope key cache indicator | 0 - 3 | 180 | S type | 0 - 15 | 181 | Key Data Type | 0 - 15 | 182 | KV Type | 0 - 15 | 183 +--------------------------------+--------------+ 185 (RFC Editor: please remove this paragraph before publication and when 186 the IANA registry has been updated with the following changes) The 187 current MIKEY IANA registry defines sub-registries with explicit name 188 for certain parameters (e.g., Next Payload) whereas other parameters 189 (e.g., Encr alg) have no (explicit) sub-registries. IANA is 190 requested to define explicit sub-registries for all the parameters 191 with sub-registry names matching the names used in this document. 193 3. Security Considerations 195 This specification does not change the security properties of MIKEY. 196 However, when new values are introduced without IETF consensus, care 197 needs to be taken to assure that possible security concerns regarding 198 the new values are still addressed. 200 4. Changes from RFC 3830 202 Section 2 relaxes the requirements from those defined in [RFC3830]. 203 A number of namespaces now have the "IETF Review or IESG Approval" 204 requirement, when they previously had the "IETF Review" requirement. 205 In addition, some namespaces now have the "Specification Required" 206 requirement. 208 5. Changes from RFC 4563 210 Section 2 relaxes the requirements from those defined in [RFC4563]. 211 The KEY ID Type namespace now has the Specification Required 212 requirement. 214 6. Changes from RFC 4909 and RFC 5410 216 Section 2 relaxes the requirements from those defined in [RFC4909]. 217 The OMA BCAST Types namespace now has the Specification Required 218 requirement. Note that [RFC5410] obsoleted [RFC4909] but does not 219 actually define the IANA rules itself. As a result, from now on this 220 RFC defines the IANA requirements for the OMA BCAST Type namespace. 222 7. Changes from RFC 6043 224 There are no changes to the rules specified in [RFC6043]. However, 225 for sake of completeness, Section 2 re-specifies these rules in this 226 document, and from now on this RFC defines the IANA requirements for 227 those namespaces. 229 8. References 230 8.1. Normative References 232 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 233 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 234 August 2004. 236 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 237 Information Type for the General Extension Payload in 238 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 240 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 241 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 242 May 2008. 244 [RFC5410] Jerichow, A. and L. Piron, "Multimedia Internet KEYing 245 (MIKEY) General Extension Payload for Open Mobile Alliance 246 BCAST 1.0", RFC 5410, January 2009. 248 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 249 Modes of Key Distribution in Multimedia Internet KEYing 250 (MIKEY)", RFC 6043, March 2011. 252 8.2. Informative References 254 [RFC4909] Dondeti, L., Castleford, D., and F. Hartung, "Multimedia 255 Internet KEYing (MIKEY) General Extension Payload for Open 256 Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909, 257 June 2007. 259 Authors' Addresses 261 Jari Arkko 262 Ericsson 263 Jorvas 02420 264 Finland 266 Email: jari.arkko@piuha.net 268 Ari Keranen 269 Ericsson 270 Jorvas 02420 271 Finland 273 Email: ari.keranen@ericsson.com 274 John Mattson 275 Ericsson 276 Stockholm SE-164 80 277 Sweden 279 Email: john.mattsson@ericsson.com