Network Working Group J. Arkko INTERNET-DRAFT V. Torvinen draft-uusitalo-sipping-delegation-00.txt I. Uusitalo Expires: August 2002 Ericsson February 2002 Requirements for Delegation of Message Protection for SIP 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 message protection. The SIP node handling authentication and initial message protection may decide, for efficiency reasons, to delegate subsequent message protection to another SIP node. In this document we discuss requirements concerning the delegation of message protection for SIP. Arkko et al. February 2002 [Page 1] SIP DELEGATION REQUIREMENTS February 2002 2. Conventions used in this document 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...............................2 3. Table of contents...............................................2 4. Introduction and Motivation.....................................2 5. Requirements....................................................2 6. Discussion......................................................3 7. Acknowledgments.................................................4 8. References......................................................4 9. Author's Address................................................5 4. Introduction and Motivation A SIP node that shares a security context with a user may decide to delegate, according to a policy, further message protection after the initial authentication to another SIP node. This might be necessary due to e.g. re-allocation of clients for capacity reasons, or in order to avoid additional authentication in a multi-hop situation (e.g. via TLS and PKI for the first hop). An essential part of delegating message protection is the transportation of keys used for message protection. Since the security of a system relies on the secrecy of the keys, care has to be taken to ensure that the keys are transported in a secure manner. For example, it is not recommended to specify a key transport mechanism that relies on underlying security because the application using the keys might not be aware of the security. It is also not recommended to make bundled key transport features into authentication mechanisms without confidentiality protection. It may also be possible to use Kerberos [5] in SIP in the future. Even though Kerberos tickets are safe as such, the same delegation and key transport features as proposed in this document may be needed. This document assumes that keying material and tickets require the same mechanisms from SIP. This document is an effort to define requirements applicable for delegation of message protection with SIP protocol. Most of these requirements are listed 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. 5. Requirements Arkko et al. February 2002 [Page 2] SIP DELEGATION REQUIREMENTS February 2002 A SIP node may decide, according to a policy, to delegate further message protection after the initial authentication to another SIP node. For example, the SIP node delegating further message protection might be a registrar. >> Req 1. A SIP node MUST be able to send keying material (or tickets) to another SIP node. Performing authentication on all SIP signaling messages would likely create bottlenecks in the authentication infrastructure. Therefore, a distributed implementation of security functions responsible for authentication may be required in some SIP implementations (e.g. 3GPP). >> Req 2: It SHOULD be possible to perform an initial authentication based on long-term authentication credentials, followed by subsequent protected signaling that uses short-term authentication credentials. Secret keys and tickets are of importance to a security of a system and compromising them would be harmful. >> Req 3. The key transport mechanism MUST protect transferred keys (or tickets) in a secure manner. SIP can be transported over different underlying protocols, some of which offer security while some don't. The application using the keys is not necessarily aware of lower layer security deployment. Therefore it is not recommended to specify a key transport mechanism that relies on the security of the underlying layers. >> Req 4. The key transport mechanism MUST not depend on the security of any underlying layers. 6. Discussion Currently, SIP does not have secure way to transport keying material or tickets between the SIP nodes. SIP does not include a mechanism for delegation of security tasks either. SIP body (e.g. SDP) can be used to carry keying material to protect subsequent multimedia sessions. It has also been proposed that SIP could be used to carry keys to protect SIP [2]. Similar requirements may be found if other similar security credentials, such as tickets or tokens, are utilized in SIP in the future. For example, the transport of Kerberos tickets [5] between SIP nodes may be required. Even though tickets may be secured by some other means, the same transport and delegation features as proposed in this document may be needed. The key transport should be specified as an individual function, with its specific headers or bodies used for transporting the keys in SIP. Arkko et al. February 2002 [Page 3] SIP DELEGATION REQUIREMENTS February 2002 The reliance to lower-layer security schemes in the transport of the keys is also problematic. Due to the importance of the session keys for the security of the system, the applications should be aware of where they are receiving keys. While some SIP implementations may be able to trust on the underlying network security, a standardized key transport mechanism is likely to find other users as well, and needs to prepare for different network cases. For example, a separate gateway solution is unlikely to provide application layer information about the source of the keys - it can at most guarantee that the keys came from one of the sources trusted by the gateway. In a multi-hop situation, even information provided from an underlying security mechanism may not be very helpful. Therefore, the recommendation is that an application layer mechanism is used to protect key transport. One such mechanism is S/MIME, though also other possibilities such as XML Digital Signatures exist. Delegation of security tasks should be somehow integrated as a part of key transport. In practice, there should be some way to communicate the purpose for which the transported keys are used. HTTP authentication framework [6] includes functionality similar to the delegation requirement. HTTP server may be responsible for authenticating data that is situated in another server. This basic delegation mechanism is achieved by using the "opaque" parameter together with sequential 401 unauthorized and 301/302 redirection error messages. The servers do not exchange key material, however the delegating server is able to send delegation-related data to the delegated server in the "opaque" parameter. 7. 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. 8. References 1. Rosenberg, J., et al., "SIP:Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, October 2001, 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/Specs/Latest-drafts/24288-190.zip Arkko et al. February 2002 [Page 4] SIP DELEGATION REQUIREMENTS February 2002 5. Kohl, J., Neuman, C., " The Kerberos Network Authentication Service (V5)", RCF 1510, September 1993. 6. Franks, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 9. 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 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 Arkko et al. February 2002 [Page 5] SIP DELEGATION REQUIREMENTS February 2002 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 DELEGATION REQUIREMENTS February 2002 Arkko et al. February 2002 [Page 7]