DISPATCH WG J. Elwell Internet-Draft Siemens Enterprise Communications Intended status: Informational V. Pascual Expires: April 9, 2010 Tekelec October 6, 2009 Requirements for secure caller identification in the Session Initiation Protocol (SIP) draft-elwell-dispatch-identity-reqs-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on April 9, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document examines requirements for secure caller identification Elwell & Pascual Expires April 9, 2010 [Page 1] Internet-Draft SIP Secure Caller ID Requirements October 2009 in SIP. Although existing mechanisms exist to achieve this, there are some known shortcomings or deployment difficulties. This work is being discussed on the dispatch@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Caller identification versus sender identification . . . . . . 4 4. Connected user identification . . . . . . . . . . . . . . . . 4 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Uses of caller identification . . . . . . . . . . . . . . . . 5 7. Forms of caller identification . . . . . . . . . . . . . . . . 6 8. Security of caller identification . . . . . . . . . . . . . . 6 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security considerations . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 15. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Elwell & Pascual Expires April 9, 2010 [Page 2] Internet-Draft SIP Secure Caller ID Requirements October 2009 1. Introduction This document examines requirements for secure caller identification in the Session Initiation Protocol (SIP) [RFC3261]. The primary purpose of SIP is establishment of a session, or call, between two users, each represented by a user agent (UA). One UA (the calling UA) originates the call (on behalf of the calling user or caller) and the other UA (the called UA) receives the call (on behalf of the called user or callee). Call establishment is achieved using the SIP INVITE method. Caller identification is the provision of calling user identification to the called UA, which can then make it available to the called user. Caller identification can be used for many purposes, some of which require the information to be secure (e.g., not subject to forgery). SIP already has some mechanisms for achieving caller identification, and some of these mechanisms can be secure, depending on how they are deployed. One mechanism uses the From header field, with authentication provided by the Identity header field (SIP Identity) [RFC4474]. Alternatively, in trusted environments, the P-Asserted- Identity header field [RFC3325] can be used. Doubts have been expressed as to whether these mechanisms are sufficient to address all requirements for secure caller identification. This document examines requirements for secure caller identification and secure connected user identification as a step towards evaluating existing mechanisms and proposing new or modified mechanisms where requirements are not yet met. The importance of secure end-to-end identification is discussed in more detail in [I-D.elwell-sip-e2e-identity-important]. 2. Terminology 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 [RFC2119]. This specification defines the following additional terms: o Sender identification: Identification of the user whose SIP UA sends a SIP request. o Caller identification: Identification of the user whose SIP UA initiates a call by issuing a SIP INVITE request and with which information is exchanged during that call. Elwell & Pascual Expires April 9, 2010 [Page 3] Internet-Draft SIP Secure Caller ID Requirements October 2009 o Connected user identification: Identification of the user whose SIP UA successfully accepts a call by sending a SIP 200 response to a SIP INVITE request and with which information is exchanged during that call. The other terms and concepts used in this document are consistent with [RFC3261], [RFC4474] and [RFC4916]. 3. Caller identification versus sender identification Existing SIP mechanisms (SIP Identity and P-Asserted-Identity) serve the purpose of providing secure identification of the sender of a SIP request (sender identification). They can be applied to a variety of request types, including: o INVITE requests (for initiating a call); o other dialog-initiating requests (e.g. SUBSCRIBE, REFER); o mid-dialog requests (e.g., BYE or re-INVITE requests during an INVITE-initiated dialog, NOTIFY requests); o stand-alone requests (e.g., MESSAGE, PUBLISH). Therefore in one sense, caller identification is a particular instance of sender identification (i.e., the sender of an INVITE request). However, caller identification is more than that, because a call comprises not only the signalling messages exchanged between UAs, but also the media streams established as a result of that signalling. The average user does not distinguish signalling and media, and expects caller identification to identify the other party in the call (i.e., both signalling and media). 4. Connected user identification A caller sometimes needs to know to which user the call has been delivered. Because of serial or parallel forking of an INVITE request, a call can be offered to more than one called UA, perhaps representing different called users. The call is normally awarded to the first UA that answers, which might not represent the user that the caller expected to reach. Identification of the user whose UA successfully answers a call is known as connected user identification (often shortened to "connected identity"). This needs to be delivered to the calling UA securely. An existing mechanism for achieving secure connected user identification is specified in [RFC4916] and builds on the SIP Identity mechanism [RFC4474]. Elwell & Pascual Expires April 9, 2010 [Page 4] Internet-Draft SIP Secure Caller ID Requirements October 2009 5. Scope There is some overlap between requirements for caller identification and requirements for sender identification, but this document focuses on requirements for caller identification. Because there are both similarities and differences in requirements between caller identification and sender identification, it may or may not be possible to use a single mechanism to solve the two problems. This document also covers requirements for connected user identification, which are similar to those for caller identification. 6. Uses of caller identification Caller identification is delivered to the called UA, which can use it for a number of purposes, for example: o presentation to the called user; o access to other information about the caller (e.g., account details); o automatic call handling (e.g., rejection of unwanted calls, forwarding to voice mail, forwarding to another user); o logging of received and missed calls; o facilitating the establishment of a return call. The called user can use this information for a number of purposes, for example: o deciding whether to answer a call, ignore a call, reject a call or cause a call to be forwarded to voicemail or elsewhere; o deciding how to greet the caller; o deciding how to behave during the call (e.g., whether it is safe to disclose sensitive information). Recognition of the caller by voice or video is clearly an alternative means of accomplishing the last of these, but only if the called user knows the caller in person. Sometimes decisions can be made on the basis of the name, telephone number or other form of identification of the particular caller, but on other occasions the caller's affiliation may be of more use. For Elwell & Pascual Expires April 9, 2010 [Page 5] Internet-Draft SIP Secure Caller ID Requirements October 2009 example, a called user may not know a particular employee of company X, but can make useful decisions in the knowledge that the call is from company X. Handling of received identification information by a UA and use by a user is discussed in more detail in [I-D.elwell-sip-identity-handling-ua]. 7. Forms of caller identification Caller identification, as delivered to the called UA, is in the form of a SIP (or SIPS) URI or a TEL URI. In practice it is usually a SIP URI. A SIP URI can be based on an E.164 telephone number, in which case the meaning of the domain part is unclear. However, generally the call will have arrived from or via the indicated domain. If all calls arriving via the called user's service provider carry that service provider's domain name, the domain name says nothing about the origin of the call. The domain part would be far more useful if it represented the originating domain. This is particularly true if the called user or called UA does not recognise the particular telephone number. For example, if caller identification sip:+123456789@example.com;user=phone is received, even if the telephone number is not recognised, the fact that the call has come from the example.com domain might be of use, but not if all calls arrive via example.com. In some cases the telephone number alone may be useful and the domain part can be ignored. In the case of a SIP URI not based on an E.164 number (e.g., with a name or private telephone number in the user part) either the domain part alone or the domain part plus user part might be of use to the called UA or called user. The user part alone might be of use, but only if it is fairly unique. 8. Security of caller identification A user often needs to know whether a call is secure. Typically a user's expectation is that information (media) cannot be eavesdropped during a secure call, e.g., anything spoken cannot be overheard by third parties. Another reasonable expectation is that information received has not been inserted, removed or modified by a third party. These expectations imply that the user must know with certainty who Elwell & Pascual Expires April 9, 2010 [Page 6] Internet-Draft SIP Secure Caller ID Requirements October 2009 is the other party in the call. Therefore secure caller or connected user identification plays an important part in determining whether a call is secure. The need for a visual indication that caller identification can be trusted is discussed in [I-D.york-sip-visual-identifier-trusted-identity]. Identification information in a SIP message can be subject to forgery, unless a trusted entity can assert that the information is correct. Any assertion must itself be protected against forgery, and must be accompanied by evidence that the assertion is made by an entity that possesses secret information (e.g., a private key known only to the trusted entity or a shared secret known only to the trusted party and a relying party). The asserting entity has to be trusted not to disclose the secret information to other parties and to assert only what it knows to be true. For example, a user might trust his/her local SIP service provider to assert the identity of the other user. This is the solution provided by P-Asserted-Identity, the assertion being secured by using TLS transport between the local proxy and the UA, the UA having authenticated the proxy at TLS establishment time. However, if the remote user is not within the local domain, the local domain must rely on an assertion from an upstream domain. Depending on how many domains the call passes through, there could be a chain of assertions of arbitrary length. The first domain should have based its assertion on authentication of its user (e.g., using SIP digest authentication). It is not uncommon for a call to pass through 4 domains (e.g., enterprise 1, service provider 1, service provider 2 and enterprise 2), resulting in a chain of assertions. There can be more domains in the case of a forwarded call. The UA receiving an assertion is not aware of the length of the chain or the intermediate domains whose assertions are being relied upon. As another example, a user might trust the other user's domain to assert the identity of that user, this assertion being based on authentication of the user (e.g., using SIP digest authentication). Authentication of the asserting domain requires that the UA knows in advance the expected certificate of that domain or the expected certification authority (CA) certificate. This is the solution provided by SIP Identity. The assertion has to pass through any intermediate domains en route to the validating UA, and this tends to encounter deployment difficulties. In particular, the common practice of performing media steering results in changes to SDP at intermediate domains and breaking the SIP Identity signature. As yet another example, a UA could initiate some form or return routability check. For example, on receipt of an INVITE request, the UA could send a SIP request to the identified calling user or domain. Elwell & Pascual Expires April 9, 2010 [Page 7] Internet-Draft SIP Secure Caller ID Requirements October 2009 Trust then is in any intermediate domains to route only to the target domain or user, and in the target domain or user to reject the request if it cannot be correlated with an outbound call request. In all cases, the identified calling or connected user is the user that the calling or connected UA is acting on behalf of. Whether it really is that particular user or another person gaining authorised or unauthorised access to the device cannot be known. It depends on the user interface provided by the UA (e.g., whether it is password protected) and user discipline (e.g., not leaving the device unattended and unlocked, not disclosing the password to others). This aspect of the problem cannot be solved by protocols and is not addressed in this document. 9. Requirements Based on the above discussion, the following requirements can be identified for secure caller identification. These requirements are not intended to replace any existing sender identification requirements for SIP messages outside the context of a call (e.g., using the MESSAGE method). REQ1 - It MUST be possible to ensure that sensitive information sent and received during a call cannot be eavesdropped by a third party (confidentiality) and assert such a property to a caller or called user. REQ2 - It MUST be possible to ensure that information sent and received during a call is not inserted, modified or deleted by a third party (integrity) and assert such a property to a caller or called user. REQ3 - It MUST be possible to provide a called user with verified information identifying the party to which information is sent and from which information is received during a call (authenticated caller identification). REQ4 - It MUST be possible for a called user to receive caller identification that includes the calling user's domain and the calling user's name or telephone number within that domain. REQ5 - It MUST be possible for a called UA to receive an assertion from the calling user's domain that the call originates in that domain and that caller identification is correct, based on that domain having authenticated the calling UA. REQ6 - It MUST be possible for a called UA to verify such an Elwell & Pascual Expires April 9, 2010 [Page 8] Internet-Draft SIP Secure Caller ID Requirements October 2009 assertion based on a trust anchor, such as a CA certificate. REQ7 - It MUST be possible to bind the source and sink of secure media (e.g., using SRTP or TLS) to an asserted caller identification. REQ8 - It MUST be possible to bind sensitive end-to-end information sent by the calling UA in call-related SIP messages to an asserted caller identification. REQ9 - The solution MUST work when a call traverses multiple domains, including cases where domains perform media steering. REQ10 - It MUST be possible for a calling user to receive connected user identification meeting corresponding requirements to those above for caller identification. REQ11 - The resulting mechanisms MUST be backward compatible with [RFC3261]. 10. IANA considerations This document requires no IANA actions. 11. Security considerations Authentication of parties involved in a call is an essential part of this document and is fully discussed in the preceding sections. There are no other security considerations. 12. Acknowledgements The authors were motivated to write this document by the extensive discussions on the subject in the former SIPPING Working Group and more recently in the DISPATCH Working Group. 13. Open Issues This current draft does not address PSTN interworking, where clearly considerations are very different. This current draft does not address 3PCC situations. Does anything need to be said about the special requirements of conferences? Elwell & Pascual Expires April 9, 2010 [Page 9] Internet-Draft SIP Secure Caller ID Requirements October 2009 14. Change log -00 New document. -01 Shortening of Introduction and moving remaining material into separate sections. Additional requirements. Change to requirement concerning multiple domains. Minor changes. 15. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [I-D.elwell-sip-e2e-identity-important] Elwell, J., "End-to-End Identity Important in the Session Initiation Protocol (SIP)", draft-elwell-sip-e2e-identity-important-03 (work in progress), February 2009. [I-D.elwell-sip-identity-handling-ua] Elwell, J., "Identity Handling at a Session Initiation Protocol (SIP) User Agent", draft-elwell-sip-identity-handling-ua-00 (work in progress), October 2008. [I-D.york-sip-visual-identifier-trusted-identity] York, D., "The Importance of a Visual Identifier of Trusted Identity", draft-york-sip-visual-identifier-trusted-identity-01 (work in progress), November 2008. Elwell & Pascual Expires April 9, 2010 [Page 10] Internet-Draft SIP Secure Caller ID Requirements October 2009 Authors' Addresses John Elwell Siemens Enterprise Communications Phone: +44 1908 855608 Email: john.elwell@siemens-enterprise.com Victor Pascual Avila Tekelec Am Borsigturm 11 Berlin Germany Email: victor@iptel.org Elwell & Pascual Expires April 9, 2010 [Page 11]