INTERNET-DRAFT SIP Security Requirements Michael Thomas Cisco Systems 12 November 2001 SIP Security Requirements draft-thomas-sip-sec-req-00.txt 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/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The SIP security requirements identifies a range of possible threats that a SIP message in transit might be subject to and defines a set of requirements that must be addressed by the SIP working group. 1. Introduction SIP, because of its many trust boundaries and modes of operation pro- vides a challenge for the effective application of security mechan- isms that address the various threats. It should be noted from the Thomas draft-thomas-sip-sec-req-00.txt [Page 1] INTERNET-DRAFT SIP Security Requirements 12 November 2001 outset that there is no such thing as "absolute" security. There are different levels of risk that various deployments are willing to tolerate given the spectrum of risk versus operational and deployment ease. Adding to the confusion, there are many existing security mechanisms with overlapping functionality. This draft identifies a number of threats which SIP is subject to, and a set of requirements which any proposed solution must satisify. 1.1. Definitions Crypto-System In this memo, crypto-system refers to the general security scheme which provides cryptographic services which are available with that scheme. These services may include privacy, message integrity, replay protection, etc. Typical crypto-systems including CHAP/RADIUS, Kerberos, IPsec/IKE, etc. Message-Integrity A message integrity check is means of insuring that a mes- sage in transit was not altered. In combination with a key, a message integrity check (or checksum, or keyed hash) insures that only the holders of the proper keying materiel will be able to modify a message in transit without detec- tion. Authentication Authentication is means of identifying another entity. There are many ways to authenticate another entity, but the typical computer based methods involve digitally signing a set of bytes using a keyed hash. Authentication usually relies on either direct knowledge of the other entity (say, a shared symmetric key or possession of the other person's public key), or third party schemes such as Kerberos and X.509 Certificate Authorities. Authorization Once indentification of a correspondent is achieved, a decision must be made as to whether that identity should be granted access for the requested services. This is the act of authorization Confidentiality Cryptographic confidentiality means that only the intended recipients will be able to determine the contents of the confidential area. This is typically done using encryption Thomas draft-thomas-sip-sec-req-00.txt [Page 2] INTERNET-DRAFT SIP Security Requirements 12 November 2001 algorithms such as DES and AES. Keyed-Hash A keyed hash is a means of providing message integrity by use with a strong one-way hash over the message body and a secret. Keyed hashes may be used with both symmetric and asymmetric keys to provide message integrity. Main-Level-SIP-Headers In the context of the SIP security requirements, the term "mail level SIP headers" refers to the SIP headers which are not contained within attachments, and are typically where volatile headers such as VIA's go. Challenge A challenge is a means of requesting that an entity prove its identity using a particular crypto-system. Transform A Transform is a generic cryptographic operation, be it a one-way hash such as SHA-1 or an encryption/decryption algorithm such as AES. Credentials Credentials are identifying information which are typically cryptographically protected by a third party. Kerberos tickets and X.509 certficates issued by a certificate authority are examples of credentials. Realm A realm defines the boundary of trust from one administra- tive domain to another. Security-Association A security association refers to the existence of shared cryptographic state between two or more entities. Security associations are typically installed to mitigate the compu- tational and message overhead of cryptographic operations which could otherwise be performed without any prior state. 2. Threats SIP deployments are expected to run the gambit of exposure to threats. They may be deployed into relatively safe environments where equipment is all mutually trustworthy and physical security is Thomas draft-thomas-sip-sec-req-00.txt [Page 3] INTERNET-DRAFT SIP Security Requirements 12 November 2001 argueably sufficient, all the way to the hostile environment of the Internet where no assumptions should be made. We consider threats to be one of two kinds. Outside threats are the broad spectrum of threats which can be perpetrated by attackers who are not in any way party to the SIP transaction at hand. Inside threats, on the other hand, are comprized of attacks where at least one party who is part of a particular transaction is not entirely trustworthy. In this draft, we use the term "transaction" to mean a (possibly forked) SIP message and responses it elicits. A transaction may traverse many SIP entities before a final response is given to the initiator. 2.1. Outside Threats Outside threats are of the type where a SIP message may traverse an untrustworthy segment of the network where exposure to uninvolved third parties is both possible and likely. The threats involved for SIP are essentially the same as the threats for any other protocol such as HTTP and SMTP which can traverse the network as plain text. The following list is not intended to be a comprehensive list of attacks; we list them only to reenforce the notion that the Internet is a hostile medium. 2.1.1. Authentication In order to mitigate man in the middle attacks from outside parites, authentication may be required. 2.1.2. Confidentiality If eavesdropping by third parties is possible, confidentiality of the SIP signaling may be required. 2.1.3. Integrity In order to mitigate tampering attacks by third parties, integrity protection may be required. Additionally, detection of replays of old message sequences may be required. Thomas draft-thomas-sip-sec-req-00.txt [Page 4] INTERNET-DRAFT SIP Security Requirements 12 November 2001 2.1.4. Authorization Even if a party can successfully authenticate, it may not be author- ized for some or all of the services that are being requested, and as such will need authorization checks. 2.2. Outside Attacks The following mechanisms may be used to mount an attack on a SIP node from a node which is not in any way party to the session. 2.2.1. Replay If an unprotected SIP message is snooped, an attacker could poten- tially gain services for which it is not authorized, cause the dis- closure sensitive information, and possibly disrupt an ongoing ses- sion. 2.2.2. Modification An intercepted SIP message could allow an attacker to construct new SIP messages which could lead to registration hijacking, hangup, take over, insertion as a man in the middle, identity spoofing, and many other mid-call attacks. 2.2.3. Forgery SIP messages which are not authenticated and authorized could lead to registration hijacking, user impersonation, and all of the other attacks listed above. That is, interception of a SIP message may be useful for an attacker, but is not strictly necessary to mount vari- ous attacks. 2.2.4. Disclosure Potentially confidential information may be containted witnin SIP messages, such as user location, media encryption keys, user iden- tity, out of band IVR signaling, sensitive internal routing topology, etc. 2.2.5. Denial of Service (DoS) There are many potential denial of service attacks available to an outside attacker, such as flooding attacks, memory exhaustion attacks which are mounted by the attacker flooding SIP nodes with otherwise legitimate messages which cause it to retain state (ala SYN flooding in TCP). There are potential CPU complexity attacks if an attacker Thomas draft-thomas-sip-sec-req-00.txt [Page 5] INTERNET-DRAFT SIP Security Requirements 12 November 2001 can for little CPU effort cause a SIP node to perform many complex operations (disk IO, modular arithmetic, etc) without first identify- ing itself to the SIP node. A third line of attack is the ability to set up a packet reflector where for low cost of CPU and/or bandwidth an attacker leverages SIP hosts to bombard unsuspecting hosts with data which requires a proportionally higher amount of work/storage than the attacker requires. This is also known as an amplification attack. 2.3. Inside Threats Inside threats are threats which can be mounted by one or more of the participants of a particular transaction. Of inside and outside threats, inside threats pose a harder set of security problems. The reason lies in the fact that a participant to a transaction must be trusted to some degree, but not wholely trusted. For example, a UA may be trusted to hang up a phone to stop a billing timer to which it is cryptographically bound to, but may not be trusted to not try to assume the identity of another subscriber. SIP further complicates matters by allowing both end to end transactions as well as transac- tions which pass through intermediate proxies. The trust relationship between each pair of hosts in the overall transaction may be dif- ferent. 2.3.1. Authentication Between any two hosts involved in a transaction, an attacker could forge the identity of a legitimate user of the service. For example, unless some entity checks, there is nothing to prevent a UA to forge a legitimate From: address in an INVITE. Likewise, it may be possible for a host involved in the transaction to spoof a legitimate server in the transaction. 2.3.2. Confidentiality In a particular transaction, various parts of the messages may reveal confidential information to eavesdroppers. An obvious example is that Thomas draft-thomas-sip-sec-req-00.txt [Page 6] INTERNET-DRAFT SIP Security Requirements 12 November 2001 confidential information such as media encryption keys may be revealed to intermediate proxies thus allowing the operator of the proxy to decrypt media streams. Another example is that certain pieces of SIP headers may reveal confidential information such as internal network topology, etc. 2.3.3. Privacy Running SIP over an IP network provides the opportunity for a user or intermediary to reveal information which would like to be kept confi- dential. An example is that some services require that the identity of a participant of a session must be kept confidential (eg, caller ID blocking). 2.3.4. Integrity It is possible that a party to a transaction could tamper with vari- ous parts of the transaction, perhaps acting as a malicious man in the middle. Another threat is a replay attack where a man in the mid- dle could replay a legitimate portion of a previously received mes- sage (perhaps encrypted), for which the end receiver could not dis- cern the difference between a legitimate piece of information and a replay. 2.3.5. Authorization Even if the participants in a transaction are properly identified, there are threats where the requestor is not authorized to perform the action. Likewise, a responder may be not be authorized to perform the action which was requested. Given the vagueries of proxy routed traffic, forking, etc, this threat with SIP requires more provision than a simplistic "don't request something from somebody you don't trust". Thomas draft-thomas-sip-sec-req-00.txt [Page 7] INTERNET-DRAFT SIP Security Requirements 12 November 2001 2.4. Inside Attacks The following mechanisms may be used to mount an attack on a SIP node from a node which is either part of a current session, or who could be part of a SIP session which would accepted by another SIP node. That is, an otherwise authenticated user may still not be trusted to act responsibly. 2.4.1. Replay An attacker might cut and paste various parts of other snooped SIP messages to hijack other SIP sessions, misidentify itself to other SIP nodes, inserting inappropriate signaling into other sessions, as well as inappropriately insert SIP headers which are not appropriate for thier function. 2.4.2. Modification An intercepted SIP message could allow an attacker to construct a new SIP message which could lead to registration hijacking, hangup, take over, insertion as a man in the middle, identity spoofing, and many other mid-call attacks. In addition, an attacking interior node could insert or delete various headers which are not detectable by the node which expects that the headers not to be tampered with. 2.4.3. Forgery SIP messages which are not authenticated and authorized could lead to registration hijacking, user impersonation, and all of the other attacks listed above. That is, interception of a SIP message may be useful for an attacker, but is not strictly necessary to mount vari- ous attacks. In addition, an attacker inside node could modify pass- ing messages to place itself in the middle of a session for both the signaling as well as any potential media, as well as change identi- ties, invoke signaling which should have only originated on a user agent, etc. 2.4.4. Disclosure Potentially confidential information may be containted witnin SIP messages, such as user location, media encryption keys, user iden- tity, out of band IVR signaling, sensitive internal routing topology, etc. In addition, unscrupulous intermediaries may disclose sensitive information for either active or passive attacks on the signaling or media. Thomas draft-thomas-sip-sec-req-00.txt [Page 8] INTERNET-DRAFT SIP Security Requirements 12 November 2001 2.4.5. Denial of Service (DoS) All of the denial of service attacks available to an outside attacker are available to an inside attacker. If the outside signaling is protected in some way, an inside attacker would still have all of the same avenues upon since there would be no way to differentiate a leg- itimate user from a legitimate user who is bent on abusing the ser- vice. [XXX need more help here/mat] 3. Proxy Routed Message Interfaces SIP brings to the fore many different trust boundaries which need to be considered. It should be noted that "trust" is a relative term, situational, and not necessarily symmetric. For example, a UA may trust its first hop proxy to route INVITE's expeditiously, but it may not trust its proxy to not expose media encryption keys to third par- ties. We introduce the concept of a trust boundary. Simply put, a trust boundary is the edge of where trust policies and considerations change. This draft considers each of the various trust boundaries and what the security implications are for each of them. SIP trapezoid is typically modeled as a trapezoid where there is a UAC and UAS with two intermediate proxies for initial INVITE's. This model reenforces the notion that SIP may go through multiple proxies as well suggesting that the notion that UA's may associate with prox- ies which are trusted to some degree. This is a good start for SIP in general, but not entirely adequate for modeling the various threats that can arise with proxy routed INVITE's. The reason is that an INVITE may pass through a proxy for which neither the UAC or UAS have no direct trust relationship at all. For this reason, we model the SIP trust boundaries as a pentagon instead. To differentiate it from the SIP trapezoid, we will call this the SIP JITB (Jack in the Box). I / \ / \ / \ / \ H J \ / \ / M-----B Thomas draft-thomas-sip-sec-req-00.txt [Page 9] INTERNET-DRAFT SIP Security Requirements 12 November 2001 3.0.1. M->H, B->J (UA to first hop proxy) In many cases, the UA will be set up with an outbound proxy which provides it services such as call routing, media QoS authorization, etc. There may or may not be a trust boundary here, but in the gen- eral case, the UA may not be trustworth to the proxy, though one gen- erally assumes that the UA wouldn't be talking to a proxy it does not trust (assuming a reasonable degree of certainty about the presented identities, of course). 3.0.1.1. Authentication The Proxy and UA may require mutual authentication. This may require operation with many different crypto systems and may be required at the transport layer, application layer or both. For example, a proxy may demand that a UA identify itself to the proxy. Another example is that a proxy may want to provide a cryptographically signed version of some identifying header which the UA could determine is from a trusted source in the proxy routed path. 3.0.1.2. Confidentiality The Proxy and UA may require message confidentiality for their mes- sages. It is possible that they may want to protect their traffic both with transport layer mechanisms for direct communication, or within the proxy routed traffic itself. One use of confidentiality is the use of encrypted state tokens which the proxy can give to the UA for later retrieval as described in [SIPSTATE]. 3.0.1.3. Integrity The Proxy and UA may require message integrity and freshness proof for their messages. It is possible that they may want to protect their traffic both with transport layer mechanisms for direct commun- ication, or within the proxy routed traffic itself. 3.0.1.4. Authorization Once authenticated, the Proxy may require authorization to services desired during the session. Additionally, the proxy may want to pre- authorize the UA for various other services as in [MEDIAAUTH]. 3.0.2. M->I, B->I, M->J, B->H (UA to Intermediate proxy) UA's may be challenged by intermediate proxies that are not neces- sarily their first hop proxies, or within the same administrative domain is the UA itself. A typical example of this may be a situation where a user agent is attached to its local proxy which provides it Thomas draft-thomas-sip-sec-req-00.txt [Page 10] INTERNET-DRAFT SIP Security Requirements 12 November 2001 various services, but needs to pass a firewall proxy at the edge of a corporate network. The important thing to take from this is that the UA may be challenged at many points along the proxy routed path in many different domains and that the security solution MUST NOT make any assumption about the number or kind of places that the UA will be required to be challenged. 3.0.2.1. Authentication The UA's and Intermediate Proxy may require mutual authentication. This may require operation with many different crypto systems and is required at the application layer. 3.0.2.2. Confidentiality The UA's and Intermediate Proxy may require message confidentiality for their messages. It is possible that they may want to protect their traffic with within the proxy routed traffic itself. 3.0.2.3. Integrity The UA's and Intermediate Proxies may require message integrity and freshness proof for their messages. It is possible that they may want to protect their traffic within the proxy routed traffic itself. 3.0.2.4. Authorization Once authenticated, the UA's and Intermediate Proxies may require authorization to services desired during the session. 3.0.3. M->B (end to end UAC to UAS) The UAC and UAS may require end to end security services. Typically, once the UAS has been found, the UA's may want to exchange informa- tion between one another which is confidential and/or integrity pro- tected. The obvious example here is media encryption keys contained within an SDP announcement. 3.0.3.1. Authentication The UAC and UAS may require mutual authentication. This may require operation with many different crypto systems and may be required at the transport layer, application layer or both. 3.0.3.2. Confidentiality The UAC and UAS may require message confidentiality for their mes- sages. It is possible that they may want to protect their traffic Thomas draft-thomas-sip-sec-req-00.txt [Page 11] INTERNET-DRAFT SIP Security Requirements 12 November 2001 both with transport layer mechanisms for direct communication, or within the proxy routed traffic itself. 3.0.3.3. Integrity The UAC and UAS may require message integrity and freshness proof for their messages. It is possible that they may want to protect their traffic both with transport layer mechanisms for direct communica- tion, or within the proxy routed traffic itself. 3.0.3.4. Authorization Once authenticated, the UA's may require authorization to services desired during the session. 3.0.4. H->I, J->I (Proxy-Proxy traffic) Proxy-proxy traffic may or may not cross a trust boundary. As usual, "trust boundary" depends on what action/service is or isn't trustable at the next hop, where there may be complex shades trust grayness where the next hop is trustable for action X, but untrustable for service Y. As such, proxy-proxy traffic may exhibit many of the same characteristics as UA/Proxy traffic that crosses a trust boundary. 3.0.4.1. Authentication The Proxies may require mutual authentication. This may require operation with many different crypto systems and may be required at the transport layer, application layer or both. It is also possible that they may want to create digitally signed pieces of information to be forwarded back along the proxy routed path which could vouch for certain headers, etc. 3.0.4.2. Confidentiality The Proxies may require message confidentiality for their messages. It is possible that they may want to protect their traffic both with transport layer mechanisms for direct communication. It is also pos- sible that they may want to be able to send and receive information that they, or one of their charges desires to be kept confidential but must be forwarded (cf call trace). 3.0.4.3. Integrity The Proxies may require message integrity and freshness proof for their messages. It is possible that they may want to protect their traffic both for transport layer mechanisms for direct communication, or within the proxy routed traffic itself. Thomas draft-thomas-sip-sec-req-00.txt [Page 12] INTERNET-DRAFT SIP Security Requirements 12 November 2001 3.0.4.4. Authorization Once authenticated, the proxies may require authorization to services desired during the session. One piece of authorization worth singling out here is that proxy-proxy authorization across administrative domains is typically where settlement would take place, be it of third party kind (ie OSP clearinghouse), or using bilateral settle- ment agreements. SIP is typically interested in the former as the latter is outside of the scope of SIP. 3.0.5. H->J, J->H (Maybe Bogus Combination) For completeness, we list non-adjacent proxies. SIP has no real con- cept of communication across non-adjacent proxies to this author's knowledge as of now. Maybe somebody brighter than the author of this memo could elucidate him should this combination need to be con- sidered. 3.1. Redirect and Registration Interface Requirements As far as the author can tell, there aren't any unique requirements for redirect and registration servers. Registration and redirect servers appear to have the same security requirements as the UA/Proxy interface. 4. Requirements o Authentication -- the recepient of a SIP message MUST be able to demand authentication from the initiator. There MUST be mechan- isms which provide for end to end authentication as well as authentication to intermediate proxies. o Mutual Authentication -- a SIP host which is challenged to authenticate itself to another SIP host MUST be able to demand mutual authentication. [XXX/mat: is it worth while considering the case where a client wants the server to authenticate itself, but the server doesn't care, ala TLS/Web?] o Privacy -- SIP Messages MUST be able to be transported Thomas draft-thomas-sip-sec-req-00.txt [Page 13] INTERNET-DRAFT SIP Security Requirements 12 November 2001 confidentially hop by hop. SIP MUST also provide a means of transporting portions of SIP messages that are not required for hop-by-hop processing privately between arbitrary SIP nodes in the proxy routed path. o Replay protection -- Both hop by hop solutions and point to intermediate proxy routed point MUST be able to detect replays and reject them. It MUST NOT be possible for a snooper to replay a sequence of bits which is not detectable. o Transport -- A SIP host MUST be able to transport entire SIP messages securely (eg, private, replay proof, integrity checked...) for TCP and UDP. SCTP SHOULD be supported as well. o The solution SHOULD allow for multiple different authentication schemes to be added in time (eg, PKI-based, Kerberos based, AAA, etc). The solution MUST provide a solution for direct pre-shared keys. o Considering the difficulty of deploying strong cryptographic based solutions, the solution MUST provide a means to prevent source spoofing attacks which does not rely on strong authenti- cation, and SHOULD provide authentication security on the order guessing a large number in the absense of active snooping. This solution MUST be mandatory to execute when strong authentication is not available. o Proxied authentication -- an intermediate SIP node MUST be able to assert identity for user agents which are be used in addition or in lieu of user agent credentials. These identities MUST have the ability to be support strong cryptographic authentication. o Support for public key authentication -- the solution MUST pro- vide a means either initially or in the future to use public base authentication, either using direct public keys, or using publkc key infrastructures. It MUST also provide a means leveraging authentication to provide strong crypto based integrity and privacy. (PKI's). o Support secret key authentication -- the solution MUST provide a means of using direct peer to peer secret key authentication as well as privacy and message integrity checking. The solution MUST allow either initially or in the future centralized secret key based authentication schemes like Kerberos and AAA. o Guard against hostile MITM -- In situations where traffic is routed through possibly untrusted intermediaries (proxies), the solution MUST provide a means of transporting sensitive headers Thomas draft-thomas-sip-sec-req-00.txt [Page 14] INTERNET-DRAFT SIP Security Requirements 12 November 2001 integrity protected as well as private to their ultimate desti- nation. The solution MUST NOT try to protect against attacks which are inherent to routing itself. o The solution SHOULD consider the cost of any public key opera- tions which are used, and the sizes of authentication creden- tials. If deemed necessary, the solution SHOULD provide a means of caching the state of "expensive" credentials which are amor- tized over subsequent messaging using less expensive mechanisms. o The solution SHOULD allow for the transport of 3rd party authentication/authorization tokens for use in conjunction with other protocols. (eg, DCS state blobs, OSP tokens, etc) o The solution SHOULD consider the sizes of messages, and SHOULD provide a mechanism to first compress any encrypted portions of messages. o The solution MUST consider denial of service attacks, and in particular MUST consider the ramifications of CPU and storage attacks from unauthenticated sources against SIP nodes. The solution MAY consider denial of service attacks by authenti- cated, but otherwise rogue nodes. References [SIP] The SIP Working Group, M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 [Kerberos]The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Net- work Authentication Service (V5)", RFC 1510, September 1993 [IPSEC] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [IKE] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998 [SIPSTATE]SIP Working Group, W. Marshal et al, "Sip Extensions for sup- porting Distributed Call State", draft-ietf-sip-state-02.txt [SIPPRIVACY] SIP Working Group, W. Marshal et al, "SIP Extensions for Caller Identity and Privacy", draft-ietf-sip-privacy-02.txt [MEDIAAUTH]SIP Working Group, W. Marshal et al, "SIP Extensions for Thomas draft-thomas-sip-sec-req-00.txt [Page 15] INTERNET-DRAFT SIP Security Requirements 12 November 2001 Media Authorization", draft-ietf-sip-call-auth-01.txt Author's Address Michael Thomas Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA Tel: +1 408-525-5386 email: mat@cisco.com Thomas draft-thomas-sip-sec-req-00.txt [Page 16]