SIPPING Working Group H. Kaplan Internet Draft Acme Packet Intended status: Informational Expires: May 29, 2009 November 29, 2008 Updates to the Updates to Asserted Identity in the Session Initiation Protocol (SIP) draft-kaplan-sipping-pai-responses-00 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/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 May 29, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract An update to the [RFC3325] is currently being defined in [draft- update-pai], to add additional request method types and use-cases for P-Asserted-Identity applicability. The update does not, however, apply to SIP responses, ACK or CANCEL requests. This draft proposes an update to the update, to add SIP response, ACK and CANCEL support. Kaplan Expires May 29, 2009 [Page 1] Updates to the Update for PAI in SIP November 2008 Table of Contents 1. Terminology.................................................2 2. Introduction................................................2 3. Discussion..................................................3 3.1. PAI and PPI in Responses...............................3 3.2. Inclusion of P-Asserted-Identity by a UAS..............4 3.3. Inclusion of P-Asserted-Identity in any response.......4 3.4. Dialog implications....................................6 4. Applicability...............................................6 5. Behavior....................................................6 5.1. UAC Behavior...........................................7 5.2. UAS Behavior...........................................7 5.3. Proxy Behavior.........................................7 5.4. Registrar Behavior.....................................8 5.5. General Handling.......................................8 6. Security Considerations.....................................9 7. IANA Considerations........................................10 8. Acknowledgments............................................10 9. References.................................................10 9.1. Normative References..................................10 9.2. Informative References................................11 Author's Address.................................................11 Intellectual Property Statement..................................12 Full Copyright Statement.........................................12 Acknowledgment...................................................12 1. 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 RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 2. Introduction The Session Initiation Protocol (SIP) is specified in RFC 3261 [RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying within a Trust Domain the asserted identity of the originator of a SIP request. This is achieved by means of the P-Asserted-Identity header field, which is specified for use in requests using a number of SIP methods, in particular the INVITE method. RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a UAC in the same Trust Domain as the first proxy. RFC 3325 does not specify the use of the P-Asserted-Identity and P- Kaplan Expires - May 2009 [Page 2] Updates to the Update for PAI in SIP November 2008 Preferred-Identity header fields with certain SIP methods such as UPDATE [RFC3311], REGISTER, MESSAGE [RFC3428], PUBLISH [RFC3903] and ACK. Furthermore, RFC 3325 is restrictive in the number and types of URIs the P-Asserted-Identity and P-Preferred-Identity header fields can contain. A draft updating RFC 3325, [draft-update-pai] extends RFC 3325 by allowing inclusion of the P-Asserted-Identity header field by a UAC in the same Trust Domain as the first proxy, relaxing the URI requirements, and allowing use of P-Asserted-Identity and P- Preferred-Identity header fields in any request. The update does not, however, update the support for PAI or PPI in SIP responses, ACK or CANCEL requests, despite the fact that section 5 "Proxy Behavior" of RFC 3325 allowed for such use. The concern expressed by some members of the SIPPING Working Group for updating response support revolves around the inability to authenticate or reject responses, ACKs or CANCELs. This draft provides a justification for updating support for such messages, the rules for handling such cases, and the security properties of doing so. 3. Discussion 3.1. PAI and PPI in Responses The inclusion of PAI and PPI header fields in SIP responses already exists: it is allowed in RFC 3325. Section 5 of RFC 3325 states: "If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P- Asserted-Identity header field, if any, as if it had authenticated the user itself." It then goes on to discuss the ability of a Proxy to add, remove, or modify the header fields in a SIP "message", not only a request. The confusion, I believe, arises from an earlier paragraph: "When a proxy receives a message from a node it does not trust and it wishes to add a P-Asserted-Identity header field, the proxy MUST authenticate the originator of the message, and use the identity which results from this authentication to insert a P-Asserted- Identity header field into the message." Note that the paragraph is only about *adding* a PAI, and only for messages from a node it does not trust. A Proxy is entirely able to modify or remove a PAI in a response from a node it does *not* trust. And a Proxy is entirely able to add a PAI to SIP responses from a node it *does* trust. Kaplan Expires - May 2009 [Page 3] Updates to the Update for PAI in SIP November 2008 A Proxy is also able to authenticate the originator of the response, for nodes it does not trust. The problem is there is no way to explicitly authenticate responses in SIP using digest-challenge techniques; however, that does not mean the Proxy cannot authenticate the originator. One way to authenticate it, for example, is if the response was received over a TLS connection from the UAS, where the UAS had previously authenticated its identity to the Proxy when Registering over the same TLS connection, using either digest-challenge or a certificate the Proxy trusts. 3.2. Inclusion of P-Asserted-Identity by a UAS RFC 3325 and [draft-update-pai] do not include procedures for a UAS to include the P-Asserted-Identity header field in a response. This can be meaningful if the UAS is in the same Trust Domain as the first upstream SIP entity. Examples of types of UAS that are often suitable for inclusion in a Trust Domain are: o PSTN gateways; o media servers; o application servers (or B2BUAs) that act as URI list servers [I-D.ietf-sipping-uri-services]; o application servers (or B2BUAs) that perform third party call control. In the particular case of a PSTN gateway, the PSTN gateway might be able to assert an identity received from the PSTN, the proxy itself having no means to authenticate such an identity. Likewise, in the case of certain application server or B2BUA arrangements, the application server or B2BUA may be in a position to assert an identity of a user on the other side of that application server or B2BUA. In accordance with RFC 3325, nodes within a Trust Domain must behave in accordance with a Spec(T), and this principle needs to apply between a UAS and its proxy as part of the condition for consideration. This update to RFC 3325 clarifies that a UAS may include a P- Asserted-Identity header field in a response in certain circumstances. 3.3. Inclusion of P-Asserted-Identity in any response Kaplan Expires - May 2009 [Page 4] Updates to the Update for PAI in SIP November 2008 There are several use cases that would benefit from the use of the P-Asserted-Identity header field in responses. These use cases apply within a Trust Domain where the use of asserted identity is appropriate (see RFC 3325). In one example, an established call passes through a gateway to the PSTN. The gateway becomes aware that the remote party in the PSTN has changed, e.g., due to call transfer. By including the P- Asserted-Identity header field in a provisional or final response, the gateway can convey the identity of the new remote party to the peer SIP UA. Note that the (re-)INVITE or UPDATE method could be used in this situation. However, this forces an additional request-response exchange, which typically is not required in this situation. In another example, a B2BUA that provides third party call control (3PCC) [RFC3725] wishes to join two calls together, one of which is still waiting to be answered and potentially is forked to different UAs. At this point in time it is not possible to trigger the normal offer-answer exchange between the two joined parties, because of the mismatch between a single dialog on the one side and potentially multiple early dialogs on the other side, so this action must wait until one of the called UAs answers. However, it would be useful to give an early indication to each user concerned of the identity of the user to which they will become connected when the call is answered. In other words, it would provide the calling UA with the identity of the new called user. This can be achieved by the B2BUA sending a P-Asserted-Identity header field in any provisional responses on the dialogs concerned. Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a REGISTER response between the registrar that has authenticated the source of the request and an edge proxy. Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a MESSAGE response to assert the receiver of a page mode instant message. This would complement its use in an INVITE response to assert the receiver of an instant message session or any other form of session. Similarly, between a UAS and first proxy that are not within the same Trust Domain, a P-Preferred- Identity header field could be used in a MESSAGE response to express a preference when the receiving user has several identities. Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a PUBLISH response to assert the receiver of published state information. This would complement its use in SUBSCRIBE and NOTIFY responses. Similarly, between a UAS and first proxy that are not within the same Trust Domain, a P-Preferred- Kaplan Expires - May 2009 [Page 5] Updates to the Update for PAI in SIP November 2008 Identity header field could be used in a PUBLISH response to express a preference when the receiving user has several identities. Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in an ACK or CANCEL request. Considering the 3PCC scenario in Flow I of [RFC3725], the asserted identity of user B may not be known when the B2BUA (controller) sends the initial INVITE request to UA A, but might be known when the B2BUA sends the ACK or CANCEL request to UA A. Thus there are several examples where P-Asserted-Identity could be used in requests or responses for methods that are not provided for in RFC 3325 or any other RFC. This leaves a few methods for which use cases are less obvious, but the inclusion of P-Asserted Identity would not cause any harm. In any response, the header field would simply assert the source of that response, whether or not this is of any use to the UAC. Similarly there are examples where P-Preferred- Identity could be used in responses for methods that are not provided for in RFC 3325 or any other RFC. This update to the update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-Identity header field to be included in any response, and the ACK and CANCEL request. 3.4. Dialog implications A P-Asserted-Identity header field in a received response or request asserts the identity of the source of that message and says nothing about the source of subsequent received messages claiming to relate to the same dialog. The recipient can make its own deductions about the source of subsequent messages not containing a P-Asserted- Identity header field. This document does not change RFC 3325 in this respect. 4. Applicability This draft updates [draft-update-pai], and thus [RFC 3325]. 5. Behavior This document updates [draft-update-pai] and [RFC 3325] by allowing a P-Asserted-Identity header field to be included by a UAS within the same Trust Domain and by allowing a P-Asserted-Identity or P- Preferred-Identity header field to appear in any response from a UAS, and the ACK and CANCEL requests from a UAC. Kaplan Expires - May 2009 [Page 6] Updates to the Update for PAI in SIP November 2008 5.1. UAC Behavior A UAC MAY include a P-Asserted-Identity header field in an ACK or CANCEL request to report the identity of the user on behalf of which the UAC is acting and whose identity the UAC is in a position to assert. A UAC SHOULD do so only in cases where it believes it is in the same Trust Domain as the SIP entity to which it sends the request and is connected to that SIP entity in accordance with the security requirements of RFC 3325. A UAC SHOULD NOT do so in other circumstances and might instead use the P-Preferred-Identity header field. A UAC MUST NOT include both header fields. A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity header field in any request, i.e., not limited to the methods allowed in RFC 3325 or [draft-update-pai]. 5.2. UAS Behavior A UAS MAY include a P-Asserted-Identity header field in any response to report the identity of the user on behalf of which the UAS is acting and whose identity the UAS is in a position to assert. A UAS SHOULD do so only in cases where it believes it is in the same Trust Domain as the SIP entity to which it sends the response and is connected to that SIP entity in accordance with the security requirements of RFC 3325. A UAS SHOULD NOT do so in other circumstances and might instead use the P-Preferred-Identity header field. A UAS MUST NOT include both header fields. A UAS MAY include a P-Asserted-Identity or P-Preferred-Identity header field in any response, i.e., not limited to the methods allowed in RFC 3325. 5.3. Proxy Behavior If a proxy receives an ACK or CANCEL request containing a P- Asserted-Identity header field from any UAC, it MUST process and forward the request following the rules of [RFC 3261]. If the UAC is within the Trust Domain, and the request is received over a secure connection per [RFC 3324], the Proxy SHOULD leave the P- Asserted-Identity header intact when it forwards the request. If a proxy receives a response for any method containing a P- Asserted-Identity header field from any UAS, it MUST process and forward the response following the rules of [RFC 3261]. If the UAS is within the Trust Domain, and the response is received over a secure connection per [RFC 3324], the Proxy SHOULD leave the P- Asserted-Identity header intact when it forwards the response. Kaplan Expires - May 2009 [Page 7] Updates to the Update for PAI in SIP November 2008 Note that the above statements imply that the proxy must have previously authenticated the sender of the request/response in accordance with the Spec(T) in force for the Trust Domain and determined that the sender is indeed part of the Trust Domain. If Spec(T) requires all messages from nodes within the Trust Domain to be challenged, for example, then clearly a response, ACK or CANCEL cannot be trusted for PAI assertion and the rules for such a case are defined later. If a Proxy receives an ACK or CANCEL request from a UAC, or any response for any method from a UAS, and the sending UA is not within the Trust Domain, the Proxy MUST remove the received P-Asserted- Identity header field in the message. If a Proxy receives an ACK or CANCEL request from a UAC, or any response for any method from a UAS, and the message does not contain a P-Asserted-Identity header field, the Proxy MAY insert the header field, if it has knowledge of the UA's identity per [RFC 3325]. This would require the Proxy to have previously authenticated the UA's identity over the same secure transport as the response was received from. If the message has a P-Preferred-Identity header value, the Proxy MAY use this information as a hint for P-Asserted- Identity generation, per the rules in [RFC 3325]. The Proxy MUST remove any P-Preferred-Identity from any message it forwards, per [RFC 3325]. In all cases, the ACK, CANCEL, or response MUST be forwarded on per [RFC 3261] rules, after removal, insertion, or acceptance of the P- Asserted-Identity header. There is no means to reject a response, ACK, or CANCEL, and discarding them would cause protocol failure. 5.4. Registrar Behavior A Registrar MAY include a P-Asserted-Identity header field in a response to the REGISTER request, if and only if the UAC has authenticated the UA identity or the P-Asserted-Identity header field was received in the REGISTER request over a secure transport from a node within the Trust Domain. Otherwise, the Registrar MUST NOT include the header field in its response. Note that this implies the P-Asserted-Identity field will only ever be included in 2xx class responses, after either the Registrar has successfully challenged the UA, or a previous Proxy has, or the Registrar trusts the UA implicitly. 5.5. General Handling If an entity receives a response, ACK or CANCEL containing a P- Asserted-Identity or P-Preferred-Identity header field containing an Kaplan Expires - May 2009 [Page 8] Updates to the Update for PAI in SIP November 2008 unexpected number of URIs or unexpected URI schemes it MUST act as follows: o ignore any URI with an unexpected URI scheme; o ignore any URI for which the expected maximum number of URIs with the same scheme occurred earlier in the header field; and o ignore any URI whose scheme is not expected to occur in combination with a scheme that occurred earlier in the header field. This document does not change the RFC 3325 requirement that allows each of these header fields to contain at most two URIs, where one is a SIP or SIPS URI and the other is a TEL URI, but future updates to this document may relax that requirement. In the absence of such a relaxation, the requirement above means that an entity receiving a response, ACK or CANCEL containing a P-Asserted-Identity or P- Preferred-Identity header field must act as follows: o ignore any URI with a scheme other than SIP, SIPS or TEL; o ignore a second or subsequent SIP URI, a second or subsequent SIPS URI or a second or subsequent TEL URI; and o ignore a SIP URI if a SIPS URI occurred earlier in the header field and vice versa. A Proxy MUST remove a URI when forwarding a response, ACK or CANCEL if that URI is to be ignored in accordance with the requirement above. 6. Security Considerations The use of asserted identity raises a number of security considerations, which are discussed fully in [RFC3325] and [draft- update-pai]. This document raises the following additional security considerations. When receiving a response, ACK, or CANCEL from a node outside the Trust Domain, a proxy has no standardized SIP means to authenticate the node. Therefore, this draft requires a Proxy to remove such an assertion from a node outside the Trust Domain. The only exception to this requirement is when the node outside the Trust Domain is using a secure transport and the Proxy has previously authenticated and authorized the node to use the same identity over that same transport connection. Kaplan Expires - May 2009 [Page 9] Updates to the Update for PAI in SIP November 2008 When receiving a response, ACK or CANCEL from a node within the Trust Domain, this draft allows the identity assertion to be maintained and passed-on without further authorization. Therefore, a node within the Trust Domain has the ability to falsify its identity in such messages. Such is the nature of a Trust Domain, and the same issue exists for P-Asserted-Identity in requests in [RFC 3325] as well. 7. IANA Considerations This document makes no request of IANA. 8. Acknowledgments Thanks to John Elwell for most of this document's text, since this document is a shameless s/request/response/g of [draft-update-pai], with a few other changes. 9. References 9.1. Normative 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. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 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. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. Kaplan Expires - May 2009 [Page 10] Updates to the Update for PAI in SIP November 2008 [draft-update-pai] Elwell, J., "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", draft-ietf-sipping-update- pai-07, October 2008. 9.2. Informative References [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [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-sipping-uri-services] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-07 (work in progress), November 2007. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - May 2009 [Page 11] Updates to the Update for PAI in SIP November 2008 Intellectual Property Statement 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - May 2009 [Page 12]