SIP WG J. Elwell Internet-Draft Siemens Enterprise Communications Intended status: BCP October 1, 2008 Expires: April 4, 2009 Identity Handling at a Session Initiation Protocol (SIP) User Agent draft-elwell-sip-identity-handling-ua-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 4, 2009. Abstract Session Initiation Protocol (SIP) User Agents (UA) receive identifiers for the caller and callee during call establishment. These identifiers can come in a variety of forms, can be delivered by a variety of means, and may or may not be accompanied by evidence of authenticity. Furthermore, if media are secured (e.g., using the Secure Real-Time Protocol, SRTP), the security properties of the media will depend on binding the media to a received authenticated identifier. This document examines the various identification information a UA can receive during call establishment and how a user agent can use this information to present a caller or callee identifier to the user and indicate to the user the security properties of the call, as well as how the user agent might use this Elwell Expires April 4, 2009 [Page 1] Internet-Draft Identity Handling at a SIP UA October 2008 information for other purposes, such as authorizing acceptance of a call. This work is being discussed on the sip@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Considerations for caller identifiers received in INVITE requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Uses of caller identifiers . . . . . . . . . . . . . . . . 4 2.2. Types of URI for caller identifiers . . . . . . . . . . . 5 2.3. Means of delivering caller identifiers . . . . . . . . . . 6 2.4. Reliability of caller identifiers . . . . . . . . . . . . 7 2.5. Message integrity . . . . . . . . . . . . . . . . . . . . 9 2.6. Media security . . . . . . . . . . . . . . . . . . . . . . 10 2.7. Considerations when presenting a received caller identifier to the user . . . . . . . . . . . . . . . . . . 11 2.8. Considerations for providing a secure call indicator to the user . . . . . . . . . . . . . . . . . . . . . . . 13 2.9. Considerations for using a received caller identifier for other purposes . . . . . . . . . . . . . . . . . . . . 14 2.10. Summary of considerations . . . . . . . . . . . . . . . . 15 3. UA best practice for handling received caller identifiers . . 16 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Security considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Informative References . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Elwell Expires April 4, 2009 [Page 2] Internet-Draft Identity Handling at a SIP UA October 2008 1. Introduction An important aspect of the Session Initiation Protocol (SIP) [RFC3261] is the delivery of an identifier (in the form of a URI) representing the source of a request to a User Agent (UA) that receives the request. In the case of an INVITE request, used to establish a call, the delivered identifier is taken to represent the caller's identity. Typically this information is rendered to the called user in some way. A successful INVITE request results in the establishment of one or more media sessions. Usually the identified caller is also taken to be the source of any received media and the sink of any transmitted media. Unfortunately, unless proper security measures are taken, there is scope for delivering an incorrect caller identifier and misleading the called user. This can have serious consequences in some circumstances, where the called user relies on receiving a correct caller identifier in order to decide whether to accept the call and how to behave during the call (e.g., in terms of information disclosed to the caller). Also an incorrect caller identifier can impact any automated call handling at the UA, e.g., authorising acceptance of the call. This document specifies best practices for UAs handling received caller identifiers, taking into account any evidence as to their authenticity. Similarly a caller's UA can receive an identifier representing the user who answers a call, i.e., the callee. The callee identifier, sometimes known as the connected identifier, may differ from the target identifier used when establishing the call, e.g., because of call forwarding. The callee identifier can be received in a request in the reverse direction on the INVITE-initiated dialog. Although this document primarily talks about caller identifiers, most of the considerations apply equally to callee identifiers. Note that although a response to an INVITE request may be considered an appropriate vehicle for delivering a callee identifier, security considerations have so far prevented this being standardised. SIP also delivers to the UA the source identifier of non-INVITE requests outside the context of an INVITE-initiated dialog. Some of these, such as MESSAGE requests, result in information being rendered to the user, and here too a reliable source identifier can be important to the user. Some requests (such as SUBSCRIBE requests) do not necessarily result in rendering anything to the user, but still the source identifier may be important to the UA, e.g., for authorizing acceptance of the request. Considerations for other requests are similar to those for INVITE requests, with the exception that there are no media streams established. Elwell Expires April 4, 2009 [Page 3] Internet-Draft Identity Handling at a SIP UA October 2008 OPEN ISSUE. Do we need anything else on non-INVITE requests, later in the document? 2. Considerations for caller identifiers received in INVITE requests 2.1. Uses of caller identifiers A UA can make use of caller identifier in a number of ways, for example: o for rendering to the user during alerting and during the answered call (e.g., by means of a display); o for inclusion in an entry in a call log of missed or answered calls; o for making a return call to the caller; o for authorizing receipt of an incoming call (e.g., by checking against a white list or black list); o for look-up in a phone book in order to obtain and render to the user more information about the caller (e.g., name, customer number, picture); o for deciding whether the call requires special treatment, e.g., redirecting. For all of these the authenticity of the caller identifier is important, and for some uses it is particularly important. For example, it is particularly important for checking against a white list. Although an unauthenticated identifier could still be rendered to the user, in doing so it would need to be made clear to the user that the identity is not to be relied on. Similarly a caller can make use of a callee identifier in a number of ways, e.g.: o for rendering to the user during the call; o for inclusion in an entry in a call log of outgoing calls; o for making a repeat call to the callee. This information is particularly useful when the callee (the answering user) is not the anticipated user, as a result of the call undergoing forwarding, for example. The authenticity of the callee Elwell Expires April 4, 2009 [Page 4] Internet-Draft Identity Handling at a SIP UA October 2008 identifier might also be important for some purposes. 2.2. Types of URI for caller identifiers SIP normally delivers the following types of URI: o type 1 - a telephone number in a TEL URI (e.g., tel:+123456789); o type 2 - a telephone number and a domain name in a SIP or SIPS URI (e.g., sip:+123456789@example.com;user=phone); or o type 3 - a SIP or SIPS URI not containing a telephone number (e.g., sip:alice@example.com). Type 1 can be subdivided according to whether the telephone number is global E.164 number (type 1a), as denoted by a '+' before the number, or significant only within a certain context (type 1b). For a type 1b identifier, the TEL URI will contain a phone-context parameter. Type 2 identifiers are marked as such by user=phone parameter in the SIP or SIPS URI, in which case the user part of the URI is a telephone subscriber string, as for a TEL URI. In this case type 2 identifiers can be subdivided according to whether the telephone number is global (type 2a) or significant only within a certain context (type 2b). For a type 2b identifier, the telephone subscriber string will contain a phone-context parameter. Type 3 identifiers lack a user=phone parameter. The user part is often not numeric, and this type of identifier is sometimes referred to as email-style. Sometimes the user part of a type 3 identifier can be numeric, in which case often it can represent a phone number and often it is interpreted by a recipient as representing a phone number. In the absence of a phone-context parameter associated with the number, the context is given by the domain part, although the use of "+" in front of a number by convention tends to mean it is a global E.164 number. This is a grey area. Strictly speaking such URIs should be treated as type 3, but in practice they are often treated as type 2. For the purposes of this document they are treated as type 3. For type 1 identifiers, the only information is the telephone number, plus the context in the case of type 1b. The number (plus the context in the case of type 1b) should be rendered to the user and/or used for other purposes by the UA. For type 2 identifiers, the domain part might also be significant. In theory, given the presence of a user=phone parameter, the user Elwell Expires April 4, 2009 [Page 5] Internet-Draft Identity Handling at a SIP UA October 2008 part alone (including phone context in the case of type 2b) is globally unique. However, the domain part might still be useful information. For example, a user who does not recognise the number might recognise the domain name. Note that the domain part does not necessarily imply that the number is owned by that domain, but it does mean that the number is meaningful within that domain and that the user of that number is reachable via that domain. Where a phone- context parameter is present, this may or may not be redundant information (i.e., it could indicate the same domain that is in the domain part). Herein lies a potential problem, however. It is sometimes the practice of intermediaries to change the domain part of a type 2 identifier to their own domain name. Since the user part is globally unique, this apparently does no harm. Effectively it says that, by routing through my domain, you can reach the identified user. However, this reduces the value of a type 2 URI received by a UA. For example, if all requests arrive via the user's service provider and that service provider always substitutes its own domain name, the UA and its user will always receive the same domain name and will not receive the original domain name. This renders the domain part of a type 2 identifier useless. For type 3 identifiers, the user part alone is not significant, even if it might look like a telephone number. A UA must always take the domain part into account when rendering to a user and for other purposes. Although URI schemes other than TEL, SIP and SIPS can be encountered, this is unusual and is not considered further in this document. 2.3. Means of delivering caller identifiers SIP provides 3 ways of delivering the source of a request and hence the caller identifier. o the From header field; o the P-Asserted-Identity header field [RFC3325]; o an S/MIME [RFC3851] body part known as Authenticated Identity Body (AIB) [RFC3893]. As S/MIME has not seen any deployment in SIP, the last of these methods in practice is not available, even though it would provide an authenticated identifier. A major obstacle is the need for UAs to have PKI-based certificates. Therefore in practice the options are the From header field and the P-Asserted-Identity header field. In Elwell Expires April 4, 2009 [Page 6] Internet-Draft Identity Handling at a SIP UA October 2008 many cases a UA may receive both. There may also be an Identity header field [RFC4474] providing a signature over the From header field URI and other parts of the message (this technique being known as SIP Identity). A UA can receive more than one caller identifier: up to two identifiers can be received in P-Asserted-Identity (one TEL URI and/or one SIP or SIPS URI) and one identifier can be received in From (a TEL, SIP or SIPS URI). The choice of which to use is not a straightforward decision. It will be influenced by the extent to which each received identifier is trusted. There can be grounds for making use of more than one received identifier. Similar mechanisms can be used to deliver the callee identifier in a request in the reverse direction. Doing this using the From and Identity header fields is specified in [RFC4916]. Note that, other than S/MIME, there is currently no available mechanism for delivering an authenticated identity in a response. An identifier delivered in a From or P-Asserted-Identifier header field can be accompanied by a "display-name" field giving further information about the caller, typically the name. 2.4. Reliability of caller identifiers The From header field is always present in a request (even though it might be anonymised), and hence a URI is always available (except that it could be a special URI denoting anonymity). Without a valid signature in an Identity header field, the From URI is easily forged, either by the UAC or by an intermediary. Thus an unsigned From URI is the least trustworthy of the caller identifiers that can be received. If accompanied by an Identity header field containing a valid signature signed using a certificate whose certification authority (or chain of certification authorities) is trusted, a far higher degree of trust can be placed in the From URI. The request is known to have come from the signing domain (the domain in the From URI), and, if that domain can be trusted, the request is known to have come from the entity identified in the user part of the From URI. The From URI can only be a SIP or SIPS URI in this case, not a TEL URI. The signature does not cover the display-name part of the From header field, and therefore the display-name cannot be relied upon. A P-Asserted-Identity URI is asserted by the last proxy. This assertion may be on the basis of an assertion by the previous proxy, and so on. Therefore it relies on transitive trust. Moreover, an Elwell Expires April 4, 2009 [Page 7] Internet-Draft Identity Handling at a SIP UA October 2008 entity should trust its next upstream entity only if the SIP message is delivered over a secure transport (e.g., TLS). Even though a UA may trust its inbound proxy, it generally has no idea what further proxies and domains upstream have been involved in delivering the request and whether secure transport has been used on all signalling hops. Even if a received request has been delivered over TLS and has a SIPS Request-URI, the UA can never be sure that a secure transport has been used on all signalling hops, as explained in [I-D.ietf-sip-sips]. This transitive trust model is designed for use only in closed environments where all involved entities can be trusted, but as those environments open up to accepting traffic from other domains, the model breaks down. Consequently, a P-Asserted- Identity URI is generally less trustworthy than a signed From URI, but more trustworthy than an unsigned From URI. Furthermore, although a P-Asserted-Identity header field can contain a display-name, the assertion strictly speaking covers only the URI, and therefore the display-name is even less trustworthy than the URI. Verifying a SIP Identity header field is not a simple matter, involving steps such as fetching the certificate (if not already cached), verifying the certification chain and performing the cryptographic operations. Often this job is done by the inbound proxy, which can then insert a P-Asserted-Identity header field to assert the identifier that it has just verified in the From header field. If this procedure has taken place, there may be grounds for placing a higher level of trust in the P-Asserted-Identity URI, but how does the UA know that this has taken place? One possibility would be for the inbound proxy always to remove invalid Identity header fields, so that on receipt of request containing an Identity header field the UA can assume that it has been verified by the inbound proxy (assuming the request can be shown to have arrived via the inbound proxy). Similar considerations apply to callee identifiers. Additional considerations arise for calls from PSTN via a gateway. The gateway cannot authenticate the caller or callee identifier received from the PSTN, and strictly speaking should not assert such an identifier using P-Asserted-Identity or SIP Identity. It can, of course, assert its own identity, e.g.: sip:gateway1@example.com By asserting: sip:+123456789@example.com;user=phone Elwell Expires April 4, 2009 [Page 8] Internet-Draft Identity Handling at a SIP UA October 2008 it at least makes it clear that the call has been delivered via example.com, but example.com cannot have claimed to have authenticated the telephone number. Unfortunately there is no mechanism available at present whereby the UA can know that such an assertion is being made by a PSTN gateway. An assertion of: tel:+123456789 is even more misleading, since it does not even convey a domain name. Unfortunately assertions of telephone numbers by PSTN gateways is common practice. This undermines the reliability of caller identifiers based on telephone numbers (identifier types 1 and 2). 2.5. Message integrity There is limited benefit in trusting the source identifier of a SIP request if other parts of the message could have been tampered with en route. In particular, for an INVITE request conveying a Session Description Protocol (SDP) offer, modifying the SDP can benefit an attacker, e.g., by forcing all media to terminate at a device chosen by the attacker rather than the device that has originated the request, by downgrading security capabilities(e.g., removing any option of using SRTP) or by downgrading a codec (e.g., to one that makes breaking SRTP encryption easier). The Identity header field signature provides integrity protection over a considerable part of a request, including the entire body (and therefore any SDP body part) and certain the header fields, but omitting header fields that normally would be changed by proxies (e.g., Via, Record-Route) and header fields of lesser importance (e.g., Call-Info, User-Agent). Also the display-name part of the From header field is omitted from the signature. By including the Date, Call-Id and CSeq header fields in the signature, a measure of protection against replay attack is also provided. It has been argued that the Identity header field signs too much, and does not cater for the legitimate needs of B2BUAs (such as session border controllers, SBCs) that need to perform media steering (e.g., to force media onto a high quality route) and therefore need to alter IP addresses and ports in SDP. Also B2BUAs often change the Call-Id, CSeq and Contact header fields. This may prevent the deployment of SIP Identity in certain environments. In the absence of any solution to this at present, this document assumes SIP Identity, as specified in [RFC4474], as the means for delivering an authenticated caller identifier along with message integrity protection. Elwell Expires April 4, 2009 [Page 9] Internet-Draft Identity Handling at a SIP UA October 2008 Note that one work-around could be for B2BUAs that break the Identity header field signature in this way to re-sign the request, but this would no longer provide end-to-end integrity protection and authentication. Also it would involve using the B2BUA's own domain certificate, and since the domain name in the certificate must match that in the domain part of the SIP/SIPS URI (according to [RFC4474]), this might involve changing the domain part of the SIP/SIPS URI, which is possible only if the user part is globally unique (as, for example, in the case of a fully qualified E.164 number). In the absence of the Identity header field, message integrity protection is achievable only on a hop-by-hop basis, by using a secure transport (e.g., TLS) on each hop. Even if a received request has been delivered over TLS and has a SIPS Request-URI, the UA can never be sure that a secure transport has been used on all signalling hops. Also it cannot be sure that a malicious intermediary has not altered parts of the message that should not have been altered. P-Asserted-Identity provides no form of message integrity protection, but instead relies on hop-by-hop assertions that integrity has not been compromised. 2.6. Media security Knowing that a SIP INVITE request comes from a given user is not particularly useful unless the recipient can be sure that media it transmits and receives is transported to and from that same user. To some extent the use of SIP Identity helps, because it provides integrity protection over ports and IP addresses in SDP. However, that does not help against attacks that spoof IP addresses or intercept media. Often the user's needs are met only by authentication, integrity protection and encryption of media. For the purposes of this document, only real-time media (e.g., audio, video) transported over the Real-time Transport Protocol (RTP) [RFC3550] are considered, but similar considerations apply to other types of media. With RTP, these security properties can be obtained using the Secure Real-time Transport Protocol (SRTP) [RFC3711]. In order to use SRTP, a security context, including master keys and salts, has to be negotiated between UAs. There are several standardised ways of doing this, each with various advantages and disadvantages. The most recent mechanism standardised by the IETF (and having superior security properties compared with earlier mechanisms) is based on Datagram TLS (DTLS) [RFC4347] and is known as DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework]. With DTLS-SRTP, authentication of the SRTP streams depends on mutual authentication of the UAs during the DTLS handshake, which agrees the security Elwell Expires April 4, 2009 [Page 10] Internet-Draft Identity Handling at a SIP UA October 2008 context. This in turn depends on certificates held by the UAs. Although these can be issued by a PKI, deployment of PKI-based certificates to UAs can be problematic, as already noted (this being the reason why S/MIME has not been deployed). Self-signed certificates alone provide no means of authentication, but if used in conjunction with SIP Identity, they can suffice. This is achieved by including a fingerprint (hash) of the certificate in SDP, which therefore gets signed as part of the Identity header field signature and is therefore integrity protected. This effectively binds the certificate to the signed From URI, and hence binds the media streams to that same identifier. Consequently, a UA using DTLS-SRTP needs to submit a fingerprint of its own certificate in the SDP it sends, and needs to check the fingerprint in the SDP it receives to ensure that it matches the fingerprint of the certificate received during DTLS handshake. If this check fails (or if any other aspect of DTLS-SRTP negotiation fails, the media concerned cannot be considered secure. The calling UA can submit its fingerprint in the SDP offer sent in the INVITE request. The callee UA can submit its fingerprint in the SDP answer in a response to the INVITE request, but there is no way of using the Identity header field in a response. Therefore to provide authentication and integrity protection, the callee's UA must send a further SDP offer, including its fingerprint, in a new request in accordance with [RFC4916]. Until this has been received and validated, the caller's UA cannot consider the media fully secure. All this depends on the integrity of the Identity header field signature being preserved. As observed in Section 2.5, some B2BUAs (such as SBCs) on the signalling path can alter parts of the request and hence break the signature in certain circumstances. In such situations the security properties of the media are diminished. Additional considerations arise for calls from and to PSTN. Media security is known about only as far as the gateway. Even if the PSTN is considered secure, there may be insecure hops beyond the PSTN. 2.7. Considerations when presenting a received caller identifier to the user When a UA receives a caller identifier, careful consideration needs to be given to what information is displayed to the user. For type 1 identifiers, clearly the telephone number should be presented, but also the phone-context parameter (if present) could contain important information. Elwell Expires April 4, 2009 [Page 11] Internet-Draft Identity Handling at a SIP UA October 2008 For type 2 identifiers, both the telephone number and the domain should be presented, because either could be useful to the user. Also the phone-context parameter (if present) could contain important information, although it might just duplicate what is in the domain part. For type 3 identifiers, both the user part and the domain part should be presented, because neither is necessarily sufficient on its own. Note that for type 2 and type 3 identifiers where the domain part is an IP address, presentation of the IP address is less likely to be useful. The user should also be provided with an indication of trustworthiness, taking into account the considerations in Section 2.4. For example, an unauthenticated From URI should be distinguishable from an authenticated From URI. The degree of trust in a P-Asserted-Identity URI will be a matter of policy. Because it is impossible to distinguish a call originating from the PSTN, any identifier based on a telephone number probably has to be treated as untrusted. However, most users are not aware of the implications of security indicators and should not be overloaded by them. If a display-name is received, the general advice is not to present it to the user. Presenting an authenticated identifier along with an unauthenticated display-name would be misleading. A preferred solution is to obtain a name by phone-book look-up, based on the received authenticated identifier, and present that. If an unauthenticated identifier is presented (and indicated as not to be trusted), little additional harm would arise from also presenting the display-name. When a UA receives more than one caller identifier, the choice of which one to present to the user will be influenced by trustworthiness. Generally the most trustworthy should be chosen. When two of equal trust are received (e.g., a TEL URI and a SIP URI in the P-Asserted-Identity header field), there may be grounds for presenting each (or elements of each), if this is possible, because either or both could be of use to the user. Similar considerations apply to callee identifiers. For a call from or to PSTN via a gateway, it is possible that two identifiers are delivered: a type 3 URI identifying the gateway (as a From URI with SIP Identity) and a type 1 or type 2 identifier (as a P-Asserted-Identifier URI) giving the telephone number received from the PSTN, e.g.: Elwell Expires April 4, 2009 [Page 12] Internet-Draft Identity Handling at a SIP UA October 2008 From: sip:gateway@example.com P-Asserted-Identity: tel:+123456789 If both are presented to the user, the former could be indicated as a trusted identifier and the latter as an untrusted identifier. However, for many users this would be information overload and might lead to confusion, so careful consideration has to be given to how such information is presented. 2.8. Considerations for providing a secure call indicator to the user Users generally regarded calls over the PSTN to be secure, rightly or wrongly. Only for particularly sensitive applications were additional end-to-end security measures used. With calls over an IP network, many more service providers, at both the transport level and the session level, are potentially involved, and the basic network infrastructure is inherently insecure. By default, calls must be regarded as insecure, unless appropriate measures have been taken to secure both signalling and media. Because many calls will not have the required security properties, either because measures are not available or not requested, users need to be made aware of the security status of a call. This is analogous to accessing web pages via HTTP or HTTPS, whereby a browser will display a security icon when HTTPS is used and the server has been satisfactorily authenticated. A user interested in the security of a call will not, in general, understand the difference between signalling and media. The general expectation is that anything spoken (or transmitted in some other medium) is delivered to the remote party without eavesdropping or alteration, that anything heard (or received in some other medium) has come from the remote party without eavesdropping or alteration, and that the remote party is as expected. Although in some cases the user might rely on voice recognition (or face recognition in the case of video) to ensure that the remote party is as expected, the remote party might not be known sufficiently for this to happen. For example, the remote party might be known by name, but not by voice or sight. As another example, the remote party might not be known by name, but only by function or affiliation (e.g., an employee of a particular bank). In these cases, caller identification (or callee identification) plays an important role (or indeed the only role) in ensuring that the remote party is as expected. Therefore, to meet a user's security expectations, real-time media need to be secured using SRTP (and other media need to be similarly secured). Also media need to be bound to an authenticated caller (or callee) identifier. Assuming DTLS-SRTP is used with self-signed Elwell Expires April 4, 2009 [Page 13] Internet-Draft Identity Handling at a SIP UA October 2008 certificates for negotiating the security context for SRTP, this requires the Identity header field to be used to sign the From URI and the DTLS-SRTP certificate fingerprint. Unless a UA has verified that DTLS-SRTP is used, that a verified authenticated identifier for the remote party has been received, and that media are bound to the signalling and hence to the authenticated identifier, the call should not be indicated as secure. A call from PSTN should be indicated as insecure, unless the presented identifier is clearly that of the gateway rather than that of the PSTN caller. Where the identifier is based on a telephone number, the call probably has to be indicated as insecure. 2.9. Considerations for using a received caller identifier for other purposes When a UA receives a caller identifier, in addition to presentation to the user, it can be used for many other purposes, including those listed in Section 2.1. Whether an identifier is usable for any given purpose might depend on its trustworthiness. For example, for authorising acceptance of a call, authenticated identity will be necessary, whereas for making a return call attempt it might not be considered necessary. Some actions might depend on the type of identifier received. For example, call forwarding might apply to calls from a particular telephone number or range of telephone numbers (e.g., area code, country code) or to calls from a particular domain. In the case of a telephone number, behaviour should probably be independent of whether the number is received in a type 1 or type 2 identifier. Likewise, in the case of a domain, behaviour should be independent of whether the domain is received in a type 2 or type 3 identifier. In configuring a UA to take special action depending on the received identifier, account needs to be taken of the different forms in which the identifier can be received. Note that certain SIP service provider practices can make things difficult for a user programming a UA to take account of caller identifiers. For example, if a UA expects a URI of the form: sip:+123456789@mybank.example.com;user=phone and that gets changed by a service provider to: sip:+123456789@serviceprovider.example.net;user=phone the UA would not find a match and the desired behaviour would fail to take place. If the user is able to predict this and program the UA Elwell Expires April 4, 2009 [Page 14] Internet-Draft Identity Handling at a SIP UA October 2008 to take account of such aliases, it could be made to work, but this makes things difficult for the user and won't work when a call arrives via an unanticipated service provider. Similarly, if the UA is programmed to take a particular action on calls from example1.com, this will not work if the domain is changed to example2.net. Another issue concerns non-global telephone numbers. Even though a type 1 or type 2 identifier containing a locally-significant number should contain a phone-context to make it globally unique, tolerance of local numbers can be difficult to program at a UA. Generally, global numbers should be given, although the use of local numbers within the domain for which they are significant is generally easier to accommodate. For example, within an enterprise it might be feasible to use numbers of the form: sip:6789;phone-context=zone1.example1.com@example1.com;user=phone within zone 1 of example1.com, but outside that zone it is preferable to use global numbers. Some of these considerations apply also to callee identifiers. 2.10. Summary of considerations A UA can use received caller or callee identifiers for many purposes, including presentation to the user. A received identifier can take various forms (type 1, type 2 and type 3), and sometimes more than one identifier can be received. Furthermore an identifier can be delivered by various means, including the From and P-Asserted- Identity header fields. The trustworthiness of an identifier depends on its type, how it is delivered and, in the case of the From header field, whether it is accompanied by a valid signature using the Identity header field. Finally, the media may or may not be secured using SRTP, and if so the source/destination of media may or may not be authenticated, based on the binding of media to signalling and receipt of an authenticated identifier for the signalling. It is the UA's task to make use of all this information in a meaningful way (e.g., for purposes such as white list checking, automatic call handling, phone book look-up, etc.) and somehow present salient facts to the user. A typical user probably just wants to know the identity of the caller or callee and whether the call is secure, although this might be over-simplification of the true situation and knowledgeable users might want more information (e.g., similar to what might be obtained by clicking on the padlock icon on a web browser). Elwell Expires April 4, 2009 [Page 15] Internet-Draft Identity Handling at a SIP UA October 2008 3. UA best practice for handling received caller identifiers OPEN ISSUE. Placeholder for normative statements. 4. IANA considerations This document requires no IANA actions. 5. Security considerations Security of caller identifiers, signalling and media are discussed throughout this document. There are no additional security considerations. 6. Acknowledgements Thanks to Kai Fischer and Dan Wing for reviewing the initial draft. 7. Informative References [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, Elwell Expires April 4, 2009 [Page 16] Internet-Draft Identity Handling at a SIP UA October 2008 September 2004. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [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.ietf-sip-dtls-srtp-framework] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", draft-ietf-sip-dtls-srtp-framework-03 (work in progress), August 2008. [I-D.ietf-sip-sips] Audet, F., "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work in progress), February 2008. Author's Address John Elwell Siemens Enterprise Communications Phone: +44 115 943 4989 Email: john.elwell@siemens.com Elwell Expires April 4, 2009 [Page 17] Internet-Draft Identity Handling at a SIP UA October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Elwell Expires April 4, 2009 [Page 18]