idnits 2.17.1 draft-uusitalo-sipping-algorithm-agreement-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 95 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 125: '... >> Req 1: It MUST be possible for ...' RFC 2119 keyword, line 134: '...eq 2: A SIP node MUST be able to selec...' RFC 2119 keyword, line 142: '...iation mechanism MUST protect against ...' 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 (February 2002) is 8098 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 section? 'RFC 2119' on line 49 looks like a reference -- Missing reference section? '7' on line 69 looks like a reference -- Missing reference section? '6' on line 69 looks like a reference -- Missing reference section? '2' on line 102 looks like a reference -- Missing reference section? '5' on line 183 looks like a reference -- Missing reference section? '1' on line 109 looks like a reference -- Missing reference section? '8' on line 152 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 INTERNET-DRAFT V. Torvinen 4 draft-uusitalo-sipping-algorithm-agreement-00.txt I. Uusitalo 5 Expires: August 2002 Ericsson 6 February 2002 8 Requirements for SIP Security Mechanism Agreement 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 1. Abstract 34 The Session Initiation Protocol (SIP) is an application-layer 35 control (signaling) protocol for creating, modifying and terminating 36 sessions with one or more participants. These sessions include 37 Internet telephone calls, multimedia distribution and multimedia 38 conferences. SIP has a number of security mechanisms used for hop- 39 by-hop or end-to-end protection. In this document we discuss 40 requirements concerning SIP security mechanism agreement. 42 2. Conventions used in this document 44 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in 48 this document are to be interpreted as described in [RFC 2119]. 50 3. Table of contents 52 1. Abstract........................................................1 53 2. Conventions used in this document...............................1 54 3. Table of contents...............................................2 55 4. Introduction and Motivation.....................................2 56 5. Definitions.....................................................2 57 6. Requirements....................................................3 58 7. Discussion......................................................4 59 9. Acknowledgments.................................................4 60 10. References.....................................................4 61 11. Author's Address...............................................5 63 4. Introduction and Motivation 65 SIP has a number of security mechanisms for hop-by-hop and end-to- 66 end protection. Some of the security mechanisms are built-in to the 67 SIP protocol, such as variants of HTTP authentication and secure 68 attachments such as S/MIME. SIP can also use underlying security 69 protocols such as IPSec/IKE [7] and TLS [6]. Some of the built-in 70 security protocols have alternative algorithms and parameters. A way 71 to negotiate the used mechanisms, and parameters used within them, 72 is needed. Without a secure negotiation method SIP is vulnerable to 73 certain attacks. For example, HTTP authentication is known to be 74 vulnerable to so called Bidding-Down attacks. There a Man-In-The- 75 Middle attacker modifies messages in such a way that communicating 76 parties believe the other side only supports weaker algorithms than 77 they actually do. In small workstation networks these issues might 78 not be very relevant, but the deployment of hundreds of millions of 79 small devices with little or no possibilities for coordinated 80 security policies, let alone software upgrades makes these issues 81 much worse. You either deny connections from large amounts of older 82 equipment or risk losing the benefit of new algorithms through 83 attacks that are trivial to attackers. 85 The need for a security mechanism agreement is also supported by the 86 fact that deployment of a large number of SIP-based consumer devices 87 such as 3GPP terminals requires all network devices to be able to 88 accommodate both current and future mechanisms. There is no 89 possibility for instantaneous change since new solutions are coming 90 gradually as new standards and product releases occur. It isn't even 91 possible to upgrade some of the devices without getting completely 92 new hardware. 94 The conclusions above are supported by the requirements from 3GPP 95 [2] and discussed in more detail in [5]. 97 This document is an effort to define requirements for secure 98 algorithm agreement used with SIP protocol. Most of the requirements 100 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 102 are discussed also in "3GPP Requirements on SIP" [2], but we 103 consider them to be beneficial also to infrastructures other than 104 3GPP. Therefore they've been separated into this new draft that's 105 easier to deal with. 107 The requirements of this document address attacks discussed in 108 chapter 22.1.3 and mechanisms discussed in chapter 22.2 of SIP-draft 109 [1]. 111 5. Definitions 113 MITM: Man-In-The-Middle 115 6. Requirements 117 Some of the built-in SIP security functions like HTTP Digest have 118 alternative algorithms and other parameters. Different algorithms 119 are suitable for different situations. Also, security holes might be 120 found from old algorithms and new algorithms will evolve. Without a 121 secure method to choose between algorithms and their parameters SIP 122 is vulnerable to certain attacks, for example the MITM attack 123 described above and in [5]. 125 >> Req 1: It MUST be possible for a SIP node to select message 126 protection algorithms and parameters within security mechanisms. 128 Also new security mechanisms will evolve and existing ones, like 129 HTTP Digest or TLS, might be used in parallel depending on the 130 situation. In order to achieve interoperability and backward 131 compatibility, it would be beneficial if a SIP node could choose the 132 security mechanism used. 134 >> Req 2: A SIP node MUST be able to select a SIP security mechanism 135 among supported alternatives. 137 The negotiation methods must not be vulnerable to so called Bidding- 138 Down attacks. In such an attack a MITM attacker modifies messages in 139 such a way that parties believe the other side supports weaker 140 security methods than they actually do. 142 >> Req 3: The negotiation mechanism MUST protect against attackers 143 who do not have access to authentication credentials. In particular, 144 it must not be possible for man-in-the-middle attackers to influence 145 the negotiation result such that services with lower or no security 146 are negotiated. 148 7. Discussion 150 Bidding-down protection is needed between different security 151 schemes. It will not be sufficient to do bidding-down protection 152 just for e.g. Digest. In SIP [8], only Digest is required, and most 153 3GPP terminals will also apply Digest. Hence a very large number of 154 devices supporting only Digest will be deployed, and these devices 156 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 158 will probably be used for long in the future. Now, assume that in 159 the future other mechanisms, for example S/MIME or TLS, are used in 160 parallel with Digest. The new devices capable of these additional 161 security mechanisms could offer to run e.g. TLS, but without 162 protection against bidding-down attacks an attacker could make 163 parties believe that the device on the other end does not support 164 TLS. Therefore TLS would not be used even if both devices supported 165 it. 167 Algorithms can be agreed upon with basic SIP features, such as 168 OPTIONS request and Require, Supported headers. They are capable of 169 informing parties about various capabilities including security 170 mechanisms. However, using these features in a straightforward 171 manner does not guarantee the security of an agreement. In their 172 basic form these methods are vulnerable to for example bidding-down 173 attacks. At least some kind of integrity protection for the methods 174 is needed. 176 Draft "Security Mechanism Agreement for SIP connections" [5] 177 proposes a secure solution for algorithm agreement. There the 178 security features are represented as regular option tags in SIP. The 179 client announces a list of supported option tags in its first 180 message, and the server returns its selection in the second message. 181 The agreement is secured by simply repeating the client's original 182 list of option tags in the client's first protected request 183 (protected with a lower layer protocol). The solution in [5] 184 supports both end-to-end and hop-by-hop agreement in a controllable 185 fashion and without a large increase in roundtrips. 187 8. Acknowledgments 189 We would like to thank Allison Mankin, Dean Willis, Rohan Mahy, 190 Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3 191 and Ericsson for interesting discussions in this problem space. 193 9. References 195 1. Rosenberg, J., et al., "SIP: Session Initiation Protocol", 196 draft-ietf-sip-rfc2543bis-07.txt, February 2002, work in 197 progress. 199 2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia- 200 sipping-3gpp-regs-02.txt, November 2001, work in progress. 202 3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) - 203 Release 5". Version 5.3.0 is available at 204 ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip 206 4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call 207 control based on SIP and SDP". Version 1.9.0 is available at 208 ftp://ftp.3gpp.org/tsg_cn/WG1_mm-cc-sm/TSGN1_22/Docs/N1- 210 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 212 20280_24228-190.zip 214 5. Arkko, J., et al., "Security Mechanism Agreement for SIP 215 Connections", draft-arkko-sip-sec-agree-00.txt, November 2001, 216 work in progress. 218 6. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0", RCF 219 2246, January 1999. 221 7. Kent, S., Atkinson, R., "Security Architecture for the Internet 222 Protocol", RFC 2401, November 1998. 224 8. Rosenberg, J., et al., "SIP:Session Initiation Protocol", 225 draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in 226 progress. 228 10. Authors' Addresses 230 Jari Arkko 231 Oy LM Ericsson Ab 232 02420 Jorvas 233 Finland 235 Phone: +358 40 5079256 236 EMail: jari.arkko@ericsson.com 238 Vesa Torvinen 239 Oy LM Ericsson Ab 240 Joukahaisenkatu 1 241 20520 Turku 242 Finland 244 Phone: +358 40 7230822 245 EMail: vesa.torvinen@ericsson.fi 247 Ilkka Uusitalo 248 Oy LM Ericsson Ab 249 Tutkijantie 2C 250 90570 Oulu 251 Finland 253 Phone: +358 40 7245404 254 EMail: ilkka.uusitalo@ericsson.fi 256 Full Copyright Statement 258 Copyright (C) The Internet Society (2002). All Rights Reserved. 260 This document and translations of it may be copied and furnished to 261 others, and derivative works that comment on or otherwise explain it 263 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 265 or assist in its implementation may be prepared, copied, published 266 and distributed, in whole or in part, without restriction of any 267 kind, provided that the above copyright notice and this paragraph 268 are 269 included on all such copies and derivative works. However, this 270 document itself may not be modified in any way, such as by removing 271 the copyright notice or references to the Internet Society or other 272 Internet organizations, except as needed for the purpose of 273 developing Internet standards in which case the procedures for 274 copyrights defined in the Internet Standards process must be 275 followed, or as required to translate it into languages other than 276 English. 278 The limited permissions granted above are perpetual and will not be 279 revoked by the Internet Society or its successors or assigns. 281 This document and the information contained herein is provided on an 282 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 283 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 284 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 285 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 286 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002