Internet Engineering Task Force SIP WG Internet Draft draft-ietf-sip-security-req-00.txt January 8, 2001 Expires: July, 2001 SIP Security Requirements 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/ietf/lid-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes identified security requirements for SIP. Security requirements occur at trust boundaries. Trust boundaries are defined by the actors involved in SIP signaling and naturally occur at the interfaces between actors. This draft therefore proposes the set of known actors, and then enumerates the security primitives applicable at each actor's trust boundary. 1 Introduction This draft describes identified security requirements for SIP. Security requirements occur at trust boundaries. Trust boundaries are defined by the actors involved in SIP signaling and naturally occur at the interfaces between actors. This draft therefore proposes the set of known actors, and then enumerates the security primitives applicable at each actor's trust boundary. 2 Definitions actor: An entity (on behalf of whom) a device participates in SIP signaling. trust domain: A domain within which all (SIP) signaling is trusted. trust boundary: The boundary between two trust domains. repudiation: The act of denying that you sent a message. 3 Actors Here is the list of the known actors that commonly participate in SIP signaling: 3.1 End-user A person 3.2 Enterprise Aggregate of end users 3.3 Internet Service Provider (ISP) Retailer of local connection to internet. 3.4 Carrier Wholesaler of network connections (to ISPs) 3.5 Application Service Provider (ASP) Retailer of a remote service. (eg. third-party voicemail) 4 Security primitives Here's a list of known security primitives: 4.1 Authentication Provides the ability for receiver of a message to ascertain the origin of the message. An intruder should not be able to masquerade as someone else. related threats: spoofing 4.2 Confidentiality Provides the ability for a message to be exchanged without eavesdropping. related threats: eavesdropping 4.3 Integrity Provides the ability for receiver of a message to verify that the message has not been modified in transit. An intruder should not be able to substitute a false message for a legitimate one. related threats: replay attack, reflection attack, hijacking a session 4.4 Non-repudiation Provides the ability to ensure that a sender cannot falsely deny later that he sent a message. A sender should not be able to falsely deny later that he sent a message. related threats: fraud 4.5 Access control Provides the ability to authorize access to a resource. related threats: unauthorized resource utilization 4.6 Availability related threats: denial of service (DoS) attack 5 Simplifying Assumptions For the purposes of this draft, the following simplifying assumptions hold: 5.1 A device acts as an agent on behalf of an actor. 5.2 Each individual actor has a logical contiguous trust boundary. Although an enterprise may have several remote networks which are physically connected by through untrusted networks, we assume that the enterprise uses VPN so that there is one logically contiguous trust boundary for that enterprise. 5.3 Security requirements occur at actor interfaces. 6 Security requirements The following list of security requirements is categorized by actor boundaries. At each boundary, applicability of each of the security primitives is listed. 6.1 End-user to End-user 6.1.1 Authentication There SHOULD be a mechanism to allow end-users to mutually authenticate one another. 6.1.2 Confidentiality There SHOULD be a mechanism to allow end-users to confidentially exchange SIP signaling. There SHOULD be a mechanism to allow end-users to confidentially exchange media streams (established via SIP signaling). There MAY be a mechanism to allow end-users to confidentially exchange signaling messages. 6.1.3 Integrity 6.1.4 Non-repudiation 6.1.5 Access Control 6.1.6 Availability 6.2 End-user to Enterprise 6.2.1 Authentication There SHOULD be a mechanism to allow an enterprise to authenticate an end-user. 6.2.2 Confidentiality 6.2.3 Integrity 6.2.4 Non-repudiation 6.2.5 Access Control There SHOULD be a mechanism to allow end-user SIP signaling and media streams through a firewall. 6.2.6 Availability 6.3 End-user to ISP 6.3.1 Authentication There SHOULD be a mechanism to allow an ISP to authenticate an end-user. 6.3.2 Confidentiality 6.3.3 Integrity 6.3.4 Non-repudiation 6.3.5 Access Control 6.3.6 Availability 6.4 End-user to Carrier 6.4.1 Authentication 6.4.2 Confidentiality 6.4.3 Integrity 6.4.4 Non-repudiation 6.4.5 Access Control 6.4.6 Availability 6.5 End-user to ASP 6.5.1 Authentication There SHOULD be a mechanism to allow an ASP to authenticate an end-user. 6.5.2 Confidentiality 6.5.3 Integrity 6.5.4 Non-repudiation 6.5.5 Access Control 6.5.6 Availability 6.6 Enterprise to Enterprise 6.6.1 Authentication 6.6.2 Confidentiality 6.6.3 Integrity 6.6.4 Non-repudiation 6.6.5 Access Control There SHOULD be a mechanism to allow SIP signaling and media streams through each enterprise's firewall. 6.6.6 Availability 6.7 Enterprise to ISP 6.7.1 Authentication 6.7.2 Confidentiality 6.7.3 Integrity 6.7.4 Non-repudiation 6.7.5 Access Control 6.7.6 Availability 6.8 Enterprise to Carrier 6.8.1 Authentication 6.8.2 Confidentiality 6.8.3 Integrity 6.8.4 Non-repudiation 6.8.5 Access Control 6.8.6 Availability 6.9 Enterprise to ASP 6.9.1 Authentication 6.9.2 Confidentiality 6.9.3 Integrity 6.9.4 Non-repudiation 6.9.5 Access Control 6.9.6 Availability 6.10 ISP to ISP 6.10.1 Authentication 6.10.2 Confidentiality 6.10.3 Integrity 6.10.4 Non-repudiation 6.10.5 Access Control 6.10.6 Availability 6.11 ISP to Carrier 6.11.1 Authentication 6.11.2 Confidentiality 6.11.3 Integrity 6.11.4 Non-repudiation 6.11.5 Access Control 6.11.6 Availability 6.12 ISP to ASP 6.12.1 Authentication 6.12.2 Confidentiality 6.12.3 Integrity 6.12.4 Non-repudiation 6.12.5 Access Control 6.12.6 Availability 6.13 Carrier to Carrier 6.13.1 Authentication 6.13.2 Confidentiality 6.13.3 Integrity 6.13.4 Non-repudiation 6.13.5 Access Control 6.13.6 Availability 6.14 Carrier to ASP 6.14.1 Authentication 6.14.2 Confidentiality 6.14.3 Integrity 6.14.4 Non-repudiation 6.14.5 Access Control 6.14.6 Availability 6.15 ASP to ASP 6.15.1 Authentication 6.15.2 Confidentiality 6.15.3 Integrity 6.15.4 Non-repudiation 6.15.5 Access Control 6.15.6 Availability 8 Acknowledgments // Put acknowledgments here 9 References [SIP] Handley, M., H. Schulzrinne, E. Schooler, and J. Rosenberg. "SIP: Session Initiation Protocol", RFC 2543, March 1999. [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC-2119, March 1997. Editor's Address Bryan J. Byerly Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA Email: byerly@cisco.com