Network Working Group J. Arkko INTERNET-DRAFT V. Torvinen draft-uusitalo-sipping-algorithm-agreement-00.txt I. Uusitalo Expires: August 2002 Ericsson February 2002 Requirements for SIP Security Mechanism Agreement Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Abstract The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution and multimedia conferences. SIP has a number of security mechanisms used for hop- by-hop or end-to-end protection. In this document we discuss requirements concerning SIP security mechanism agreement. 2. Conventions used in this document Arkko et al. February 2002 [Page 1] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this document are to be interpreted as described in [RFC 2119]. 3. Table of contents 1. Abstract........................................................1 2. Conventions used in this document...............................1 3. Table of contents...............................................2 4. Introduction and Motivation.....................................2 5. Definitions.....................................................2 6. Requirements....................................................3 7. Discussion......................................................4 9. Acknowledgments.................................................4 10. References.....................................................4 11. Author's Address...............................................5 4. Introduction and Motivation SIP has a number of security mechanisms for hop-by-hop and end-to- end protection. Some of the security mechanisms are built-in to the SIP protocol, such as variants of HTTP authentication and secure attachments such as S/MIME. SIP can also use underlying security protocols such as IPSec/IKE [7] and TLS [6]. Some of the built-in security protocols have alternative algorithms and parameters. A way to negotiate the used mechanisms, and parameters used within them, is needed. Without a secure negotiation method SIP is vulnerable to certain attacks. For example, HTTP authentication is known to be vulnerable to so called Bidding-Down attacks. There a Man-In-The- Middle attacker modifies messages in such a way that communicating parties believe the other side only supports weaker algorithms than they actually do. In small workstation networks these issues might not be very relevant, but the deployment of hundreds of millions of small devices with little or no possibilities for coordinated security policies, let alone software upgrades makes these issues much worse. You either deny connections from large amounts of older equipment or risk losing the benefit of new algorithms through attacks that are trivial to attackers. The need for a security mechanism agreement is also supported by the fact that deployment of a large number of SIP-based consumer devices such as 3GPP terminals requires all network devices to be able to accommodate both current and future mechanisms. There is no possibility for instantaneous change since new solutions are coming gradually as new standards and product releases occur. It isn't even possible to upgrade some of the devices without getting completely new hardware. The conclusions above are supported by the requirements from 3GPP [2] and discussed in more detail in [5]. This document is an effort to define requirements for secure algorithm agreement used with SIP protocol. Most of the requirements Arkko et al. February 2002 [Page 2] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 are discussed also in "3GPP Requirements on SIP" [2], but we consider them to be beneficial also to infrastructures other than 3GPP. Therefore they've been separated into this new draft that's easier to deal with. The requirements of this document address attacks discussed in chapter 22.1.3 and mechanisms discussed in chapter 22.2 of SIP-draft [1]. 5. Definitions MITM: Man-In-The-Middle 6. Requirements Some of the built-in SIP security functions like HTTP Digest have alternative algorithms and other parameters. Different algorithms are suitable for different situations. Also, security holes might be found from old algorithms and new algorithms will evolve. Without a secure method to choose between algorithms and their parameters SIP is vulnerable to certain attacks, for example the MITM attack described above and in [5]. >> Req 1: It MUST be possible for a SIP node to select message protection algorithms and parameters within security mechanisms. Also new security mechanisms will evolve and existing ones, like HTTP Digest or TLS, might be used in parallel depending on the situation. In order to achieve interoperability and backward compatibility, it would be beneficial if a SIP node could choose the security mechanism used. >> Req 2: A SIP node MUST be able to select a SIP security mechanism among supported alternatives. The negotiation methods must not be vulnerable to so called Bidding- Down attacks. In such an attack a MITM attacker modifies messages in such a way that parties believe the other side supports weaker security methods than they actually do. >> Req 3: The negotiation mechanism MUST protect against attackers who do not have access to authentication credentials. In particular, it must not be possible for man-in-the-middle attackers to influence the negotiation result such that services with lower or no security are negotiated. 7. Discussion Bidding-down protection is needed between different security schemes. It will not be sufficient to do bidding-down protection just for e.g. Digest. In SIP [8], only Digest is required, and most 3GPP terminals will also apply Digest. Hence a very large number of devices supporting only Digest will be deployed, and these devices Arkko et al. February 2002 [Page 3] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 will probably be used for long in the future. Now, assume that in the future other mechanisms, for example S/MIME or TLS, are used in parallel with Digest. The new devices capable of these additional security mechanisms could offer to run e.g. TLS, but without protection against bidding-down attacks an attacker could make parties believe that the device on the other end does not support TLS. Therefore TLS would not be used even if both devices supported it. Algorithms can be agreed upon with basic SIP features, such as OPTIONS request and Require, Supported headers. They are capable of informing parties about various capabilities including security mechanisms. However, using these features in a straightforward manner does not guarantee the security of an agreement. In their basic form these methods are vulnerable to for example bidding-down attacks. At least some kind of integrity protection for the methods is needed. Draft "Security Mechanism Agreement for SIP connections" [5] proposes a secure solution for algorithm agreement. There the security features are represented as regular option tags in SIP. The client announces a list of supported option tags in its first message, and the server returns its selection in the second message. The agreement is secured by simply repeating the client's original list of option tags in the client's first protected request (protected with a lower layer protocol). The solution in [5] supports both end-to-end and hop-by-hop agreement in a controllable fashion and without a large increase in roundtrips. 8. Acknowledgments We would like to thank Allison Mankin, Dean Willis, Rohan Mahy, Bernard Aboba, Miguel Garcia, as well as numerous people at 3GPP SA3 and Ericsson for interesting discussions in this problem space. 9. References 1. Rosenberg, J., et al., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-07.txt, February 2002, work in progress. 2. Garcia, M., et al., "3GPP requirements on SIP", draft-garcia- sipping-3gpp-regs-02.txt, November 2001, work in progress. 3. 3GPP TS 23.228: "IP Multimedia (IM) Subsystem (Stage 2) - Release 5". Version 5.3.0 is available at ftp://ftp.3gpp.org/Specs/2001-12/Rel-5/23_series/23228-530.zip 4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call control based on SIP and SDP". Version 1.9.0 is available at ftp://ftp.3gpp.org/tsg_cn/WG1_mm-cc-sm/TSGN1_22/Docs/N1- Arkko et al. February 2002 [Page 4] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 20280_24228-190.zip 5. Arkko, J., et al., "Security Mechanism Agreement for SIP Connections", draft-arkko-sip-sec-agree-00.txt, November 2001, work in progress. 6. Dierks, T., Allen, C., "The TLS Protocol, Version 1.0", RCF 2246, January 1999. 7. Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 8. Rosenberg, J., et al., "SIP:Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in progress. 10. Authors' Addresses Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Vesa Torvinen Oy LM Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland Phone: +358 40 7230822 EMail: vesa.torvinen@ericsson.fi Ilkka Uusitalo Oy LM Ericsson Ab Tutkijantie 2C 90570 Oulu Finland Phone: +358 40 7245404 EMail: ilkka.uusitalo@ericsson.fi Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Arkko et al. February 2002 [Page 5] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Arkko et al. February 2002 [Page 6] SIP ALGORITHM AGREEMENT REQUIREMENTS January 2002 Arkko et al. February 2002 [Page 7]