idnits 2.17.00 (12 Aug 2021) /tmp/idnits47950/draft-lehtovirta-rtpsec-infra-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.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 206. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 26, 2007) is 5562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-wing-media-security-requirements-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Lehtovirta 3 Internet-Draft Ericsson Research NomadicLab 4 Intended status: Informational February 26, 2007 5 Expires: August 30, 2007 7 Infrastructure aspects to media security 8 draft-lehtovirta-rtpsec-infra-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document discusses some infrastructure aspects that should be 42 considered in the media security requirements work. 44 Table of Contents 46 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Termination of media security in a gateway . . . . . . . . . . 5 49 4. Using shared keys to provide media security . . . . . . . . . 6 50 5. Setting up media security with the help of a third party . . . 7 51 6. Termination of media streams in different devices . . . . . . 8 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 54 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 55 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 Intellectual Property and Copyright Statements . . . . . . . . . . 12 59 1. Requirements notation 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Introduction 67 Requirements related to the ongoing media security work are discussed 68 for example in [I-D.wing-media-security-requirements]. 70 This document discusses some infrastructure aspects that should be 71 considered in the media security requirements work. 73 These aspects are: 75 o Termination of media security in a gateway 77 o Using shared keys to provide media security 79 o Setting up media security with the help of a third party 81 o Termination of media streams in different devices 83 3. Termination of media security in a gateway 85 A typical case of using media security is the one where two entities 86 are having a VoIP conversation over IP capable networks. However, 87 there are cases where the other end of the communication is not 88 connected to an IP capable network. In this kind of setting, there 89 needs to be some kind of gateway at the edge of the IP network which 90 converts the VoIP conversation to format understood by the other 91 network. An example of such gateway is a PSTN gateway sitting at the 92 edge of IP and PSTN networks. 94 If media security (e.g. SRTP protection) is employed in this kind of 95 gateway-setting, then media security and the related key management 96 needs to be terminated at the gateway. The other network (e.g. 97 PSTN) may have its own measures to protect the communication, but 98 this means that from media security point of view the media security 99 is not employed end-to-end between the communicating entities. 101 Therefore, media security solutions should cover the cases where 102 media security is not employed end-to-end but is terminated in a 103 gateway. 105 4. Using shared keys to provide media security 107 There are environments where the communicating endpoints set up 108 shared keys with the network infrastructure. An example of such 109 environment is the widely deployed GSM system and its 3G successor, 110 the UMTS. It would be beneficial if the shared keys between the 111 endpoints and the network infrastructure in these kind of systems 112 could be re-used to provide shared keys also between the 113 communicating endpoints. 115 Therefore, it might be justified to consider using shared keys in 116 addition to public keys to provide media security in some 117 environments. 119 5. Setting up media security with the help of a third party 121 Setting up a secured connection to an arbitrary peer requires that 122 the communicating entities have in some way agreed on key management 123 credentials, e.g. shared keys or certificates. From scalability 124 point of view it is in practice not feasible to achieve this to an 125 arbitrary peer without the help of some third party providing the 126 credentials. 128 To enable a scalable solution that allows to set up a secure 129 connection to an arbitrary peer seems to require the help of some 130 third party. 132 6. Termination of media streams in different devices 134 In some cases, different media streams might be terminated in 135 different devices. For example, the video part of a multimedia 136 session could terminate in one device, while the audio part would 137 terminate in another device. It should be possible to set up media 138 security efficiently in such scenarios. 140 7. Security Considerations 142 None. 144 8. References 146 8.1. Normative References 148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 149 Requirement Levels", BCP 14, RFC 2119, March 1997. 151 8.2. Informative References 153 [I-D.wing-media-security-requirements] 154 Wing, D., "Media Security Requirements", 155 draft-wing-media-security-requirements-00 (work in 156 progress), October 2006. 158 Author's Address 160 Vesa Lehtovirta 161 Ericsson Research NomadicLab 162 JORVAS FIN-02420 163 FINLAND 165 Phone: +358 9 299 1 166 Email: vesa.lehtovirta@ericsson.com 168 Full Copyright Statement 170 Copyright (C) The IETF Trust (2007). 172 This document is subject to the rights, licenses and restrictions 173 contained in BCP 78, and except as set forth therein, the authors 174 retain all their rights. 176 This document and the information contained herein are provided on an 177 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 178 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 179 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 180 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 181 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 182 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 184 Intellectual Property 186 The IETF takes no position regarding the validity or scope of any 187 Intellectual Property Rights or other rights that might be claimed to 188 pertain to the implementation or use of the technology described in 189 this document or the extent to which any license under such rights 190 might or might not be available; nor does it represent that it has 191 made any independent effort to identify any such rights. Information 192 on the procedures with respect to rights in RFC documents can be 193 found in BCP 78 and BCP 79. 195 Copies of IPR disclosures made to the IETF Secretariat and any 196 assurances of licenses to be made available, or the result of an 197 attempt made to obtain a general license or permission for the use of 198 such proprietary rights by implementers or users of this 199 specification can be obtained from the IETF on-line IPR repository at 200 http://www.ietf.org/ipr. 202 The IETF invites any interested party to bring to its attention any 203 copyrights, patents or patent applications, or other proprietary 204 rights that may cover technology that may be required to implement 205 this standard. Please address the information to the IETF at 206 ietf-ipr@ietf.org. 208 Acknowledgment 210 Funding for the RFC Editor function is provided by the IETF 211 Administrative Support Activity (IASA).