| DISPATCH WG | J. Elwell |
| Internet-Draft | Siemens Enterprise Communications |
| Intended status: Informational | V. Pascual |
| Tekelec | |
| 2009 |
Requirements for secure caller identification in the Session Initiation Protocol (SIP)
draft-elwell-dispatch-identity-reqs-00.txt
This document examines requirements for secure caller identification 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.
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
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."
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 (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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 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].
Existing SIP authentication mechanisms 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:
Therefore in one sense, caller identification is a particular instance of sender identification. 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). 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.
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. 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]. This document also covers requirements for connected user identification, which are similar to those for caller identification.
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].
Caller identification is delivered to the called UA, which can use it for a number of purposes, for example:
The called user can use this information for a number of purposes, for example:
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 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].
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
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.
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 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.
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. 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.
REQ1 - 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.
REQ2 - 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.
REQ3 - It MUST be possible for a called UA to verify such an assertion based on a trust anchor, such as a CA certificate.
REQ4 - It MUST be possible to bind the source and sink of secure media (e.g., using SRTP or TLS) to an asserted caller identification.
REQ5 - The solution MUST work when a call traverses multiple domains, including cases where domains change certain parts of the SIP message.
REQ6 - It MUST be possible for a calling user to receive connected user identification meeting similar requirements to those above for caller identification.
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?
This document requires no IANA actions.
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.
The author received help and encouragement from Victor Pascual Avila during drafting.