idnits 2.17.1 draft-ietf-avt-register-srtp-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3711, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4568, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3711, updated by this document, for RFC5378 checks: 2001-02-27) -- 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 (April 20, 2010) is 5120 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) == Missing Reference: 'RFCXXXX' is mentioned on line 98, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group D. Wing 3 Internet-Draft Cisco 4 Updates: 4568, 3711 April 20, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: October 22, 2010 9 Policy for Registering SRTP Transforms 10 draft-ietf-avt-register-srtp-02 12 Abstract 14 IETF procedure requires country-specific cryptographic transforms to 15 be Informational RFCs. This document allows such Informational RFCs 16 to be used by SRTP and SRTP Security Descriptions. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 22, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Update to RFC3711 . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Update to RFC4568 . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 4 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 It is desirable to extend Secure Real-time Transport Protocol (SRTP 72 [RFC3711]) and its keying mechanisms to support country-specific 73 cryptographic transforms. This document resolves a clash between 74 IETF procedure and existing RFCs. IETF procedure requires that 75 cryptographic transforms not intended for deployment on the Internet 76 be published as Informational RFCs (Section 4.2 of [RFC2026]). 77 However, existing documents require extensions to SRTP and extensions 78 to SRTP keying to be published as Standards-Track RFCs. 80 This document resolves this clash by allowing Informational RFCs to 81 register new cryptographic transforms. 83 2. Update to RFC3711 85 This document updates Section 6 and Section 12 of [RFC3711], which 86 currently require a standards track RFC to define a new SRTP 87 transform. After publication of this document, new SRTP transforms 88 can be defined using "IETF Review" policy of [RFC5226]. 90 3. Update to RFC4568 92 This document updates Section 10.3.2.1 of [RFC4568] to change the 93 requirements to add a new crypto suite to the IANA registry "SRTP 94 Crypto Suite Registrations" which currently requires Standards 95 Action. After publication of this document, new SRTP crypto suite 96 registrations are allocated using the "IETF Review" policy of 97 [RFC5226], and the "SRTP Crypto Suite Registrations" table should 98 also reference [RFCXXXX]. 100 [RFC Editor, IANA: RFCXXXX should be replaced by the number for 101 this RFC.] 103 4. Security Considerations 105 This specification makes it easier for new cryptographic transforms 106 to be used with SRTP. However, this specification does not lift the 107 requirement that cryptographic transforms are subject to IETF Review 108 [RFC5226]. 110 5. IANA Considerations 112 Please see Section 3. 114 6. Acknowledgements 116 Thanks to Roni Even for guidance on this document. Thanks to Carlos 117 Pignataro and Brian Weis and for their review comments. 119 This document was produced using version e1-dwing of XML2RFC. 121 7. References 123 7.1. Normative References 125 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 126 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 127 RFC 3711, March 2004. 129 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 130 Description Protocol (SDP) Security Descriptions for Media 131 Streams", RFC 4568, July 2006. 133 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 134 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 135 May 2008. 137 7.2. Informative References 139 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 140 3", BCP 9, RFC 2026, October 1996. 142 Author's Address 144 Dan Wing 145 Cisco Systems, Inc. 146 170 West Tasman Drive 147 San Jose, CA 95134 148 USA 150 Email: dwing@cisco.com