Session Initiation Protocol R. Shacham Internet-Draft H. Schulzrinne Expires: December 29, 2005 Columbia University W. Kellerer S. Thakolsri DoCoMo Eurolabs June 27, 2005 Specifying Media Privacy Requirements in the Session Initiation Protocol (SIP) draft-shacham-sip-media-privacy-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/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 December 29, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Participants in a normal phone conversation can assume that, given the appropriate measures are taken against network eavesdropping, what they say is only heard by the other participant. The use of speakerphones or visual output devices displaying video or messaging Shacham, et al. Expires December 29, 2005 [Page 1] Internet-Draft Media Privacy in SIP June 2005 removes this assumption. In the Session Initiation Protocol (SIP), a call may also be transfered to another device, suddenly compromising the other participant's privacy. Therefore, this document proposes SDP and SIP protocol extensions that allow participants to specify their privacy requirements for the other party's device, and discusses how they may be used in different session scenarios. It also defines an SDP extension for allowing or disallowing the recording of the session. 1. Overview Participants in a normal phone conversation can assume that what they say is only heard by the other participant. The use of speakerphones or visual output devices displaying video or messaging removes this assumption. In the Session Initiation Protocol (SIP) [1], a call may also be transfered to another device, as specified in [4], suddenly compromising the other participant's privacy. This document proposes two protocol extensions to be used in SIP sessions that allow participants to specify their privacy requirements: an extension to Caller Preferences [2] and two new attributes in the Session Description Protocol [3]. The two methods, together, aim to support privacy in a number of ways during a session. These ways apply either during call setup or in the middle of a call. During call setup, the call will only be set up on devices that satisfy the privacy requirements of each party. Although a device may support a certain level of privacy, a specific use of the device, such as a mobile phone's speakerphone capability, may compromise this privacy. Therefore, the device that processes the request should disallow such use, or at least warn its user that the other party has requested a private conversation. Once a session has been established, a user may try to alter it in ways that compromise the intended privacy. For instance, he may choose to turn on the speakerphone or transfer the audio to a speaker system in the room. The information ascertained in the call setup must govern the entire session, so that such changes are disallowed. If the device does not exercise such control on the user, the remote device may still block undesirable changes in the session. While it will have no recourse if the device allows the speakerphone to be activated, it can block attempted session transfer. If the content of the session becomes more private, a participant may wish to update the privacy restrictions. For instance, he may need to give private information such as a credit card number, and would like to ensure that only the other user can hear. If the other device currently provides sufficient privacy, the update serves to notify the other device of the change, so that future changes will be Shacham, et al. Expires December 29, 2005 [Page 2] Internet-Draft Media Privacy in SIP June 2005 disallowed. If the other device is currently not private enough, the remote participant is taking an active role in ensuring that the other participant is using an appropriate device. It may remotely force the other user's device to retrieve a session currently on another device, or output audio to the user's earpiece which is currently being heard on the phone's speaker. In addition to the level of privacy of a session, a participant may also be concerned about its recording. This document proposes a way for a user to allow or disallow recording of the session. 2. Device privacy levels This document proposes a three-level system for characterizing the privacy of a device based on who can see or hear its output. The levels, in descending order of privacy are "user", "organization", "public". The privacy level "user" indicates that the communication between the participants cannot be heard or seen by any other person. A loudspeaker may still be on if the user is in the room alone. The level "organization" means that the communication may only be perceived by those with whom the device user shares an affiliation, such as a company, an institution or a group of friends. The other participant need not have any affiliation with the organization. The level "public" indicates that there are no restrictions on privacy. The device may change its level based on circumstances in its environment. For instance, a speakerphone in a company conference room may have privacy level "user" as long as nobody besides the user is present. Once other users are detected through a mechanism such as an identification card reader (which detects specific users) or a sensor at the door (which simply detects traffic), the phone would update its privacy level to "organization". If, after the change, the device no longer provides a level of privacy sufficient for the session, based on previously conveyed information as described in Section 1, it should either take the proper action to make itself more private, notify its user, or notify the other participant. 3. Caller preferences for privacy Caller preferences [2] are a set of extensions to SIP which allow a caller to specify how his request should be handled by a server. The extensions consist of three headers, "Request-Disposition", "Reject- Contact", "Accept-Contact". "Request-Disposition" is used to specify the process by which the server should choose the contact of the recipient to which to route the call, while the other two headers are used to require specific attributes in the chosen contact or give preference to contacts with certain attributes. This document proposes extending the framework to include a new feature preference called "privacy" which may take any of the three values mentioned Shacham, et al. Expires December 29, 2005 [Page 3] Internet-Draft Media Privacy in SIP June 2005 above in Section 2. The caller may include this parameter in the "Reject-Contact" header to disallow the call being routed to any device with a privacy level lower than or equal to that specified. For example, including the following header would keep the request from being routed to any device which would allow others to see or hear the output: Reject-Contact: *;privacy="organization" Alternatively, the use of the "Accept-Contact" header can be used to give preference to a device higher than or equal to a given privacy level. Using the "require" parameter will ensure that the call will only be proxied to such a device. The same selection criteria conveyed in the above header can be conveyed as follows: The registration of a user's contact must include the privacy level of the device using the specifications in [5] in order to allow the proxy to match the correct contact with the caller's request. A device which has multiple modes with different privacy levels, such as a phone with a speakerphone capability, should specify the highest privacy level that it provides. Once it has received the request, it should limit the use of the device in accordance with the information contained therein. For example, the registration sent for a user on an IP phone that has a speakerphone capability would include the following header: Contact: ;privacy="user" 4. SDP attributes for privacy We specify an extension to SDP to allow a session to be negotiated based on privacy requirements. Two attributes are defined, "provided-privacy" and "required-privacy", each a value attribute which may take any of the values specified in Section 2. An SDP description may include either or both of the attributes. We currently define this attribute as being only session-level, for the sake of simplicity and since that granularity is likely to suffice for most uses. An example fragment of an SDP body follows: c=IN IP4 212.78.32.6 a=provided-privacy:user a=required-privacy:user Here, the sender notifies the other party that he is able to provide user-level privacy, and requires the same level from the other device in order to establish a session. This attribute is treated as any other in the offer/answer exchange, in that the recipient must be Shacham, et al. Expires December 29, 2005 [Page 4] Internet-Draft Media Privacy in SIP June 2005 able to provide privacy at least at the specified level in order to establish the session. 5. Providing privacy The two extensions described may be used concurrently to provide the privacy services in Section 1. Including the "Reject-Contact" or "Accept-Contact" headers in a request will route the call to an appropriate device. Since caller preferences are only defined for the initiator of a session, the callee must use, in its response, the SDP extensions described in order to require that the caller use a device that is sufficiently private. Once the two user devices have established a session between them, the information exchanged during call setup is also used to limit the use of the device. If a device has received a request with either the "Reject-Contact" header, the "Accept-Contact" header or a response that includes a "a=required-privacy" line, it must not, for the duration of the session, allow the user to make any adjustments to the session that violate whatever privacy requirements are contained therein. If the other participant has required "user" level privacy, the device must not allow the user to turn on the speakerphone at any time unless it has a way of knowing that there is no other user in the area. Likewise, it must not allow the user to transfer the call to a device where the media may be seen or heard by others. If a device still allows the user to attempt a transfer, the remote device may stop it from taking place. There are two session transfer modes mentioned in [4], Mobile Node Control (MNC) mode and Session Handoff (SH) mode. In both, the flows involve a request/response interaction with the remote user's device. The remote device may specify in the body of its response that it will only allow sessions with devices that have a specific level of privacy, thereby not allowing the session transfer to take place otherwise. If either party wishes to update the privacy of the call, the SDP attribute must be used, since caller preferences are not defined for mid-call messages. As described in Section 1, this may simply make the other device aware of the increased privacy of the session or may actually remotely force a change on the other device. For example, in order to update the session privacy to "user" level, a participant sends an INVITE request with the SDP "required-privacy" attribute set to "user". If the call is currently on the user's own device, the device responds with its own SDP parameters, as it normally would. If the user is currently using the speakerphone, the device redirects the output to the earpiece. If the user currently has part of the call on an external device which may be perceived by other users, his Shacham, et al. Expires December 29, 2005 [Page 5] Internet-Draft Media Privacy in SIP June 2005 own device must retrieve the session in order to comply with the session update. It responds with an acceptable SDP body, namely its own parameters, and subsequently terminates its own session with the local audio device in order to remove the remote participant's media from there. 6. SDP attribures for recording Since the recording of a session is not an intrinsic attribute of a device and does not effect call routing, it is not useful to express it as a caller preference. Rather, this document defines two SDP attributes that may be used to express information about session recording. As in Section 4, we only define these attributes at the session level for the sake of simplicity. An SDP description containing the "record" attribute conveys to the other participant that he would like to allow recording of the session, which is likely to mean that he will, in fact, record it. The SDP may also contain the "norecord" attribute to convey that the user is requesting to disallow recording of the session. These attributes may be used during call setup or in mid-call. 7. Security Considerations This document, itself, is concerned with providing SIP session participants with their desired level of privacy. It is only concerned with conveying to the other participant requirements for handling media streams once they are received. It does not provide for the confidentiality or integrity of media streams, which are provided by the Secure Real-time Transport Protocol (SRTP) [6]. 8. IANA Considerations This document defines a new feature parameter called "privacy" whose use is governed by [2]. It must take one of the following values: "user", "organization", "public". It also defines four SDP attributes. Two of these attributes serve to allow for negotiation based on the privacy level of the devices. The attributes, "required-privacy" and "provided-privacy", are session-level value attributes which must take one of the values listed above. The other two attributes, "record" and "norecord" serve to allow and disallow the recording of the session. They are session-level property attributes. 9. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Sparks, R., Handley, A., and E. Schooler, "SIP: Session Shacham, et al. Expires December 29, 2005 [Page 6] Internet-Draft Media Privacy in SIP June 2005 Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [4] Shacham, R., Schulzrinne, H., Thakolsri, S., and W. Kellerer, "Session Initiation Protocol (SIP) Session Mobility, IETF Internet Draft (Work in Progress)", February 2005. [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Authors' Addresses Ron Shacham Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: rs2194@cs.columbia.edu Henning Schulzrinne Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: hgs@cs.columbia.edu Shacham, et al. Expires December 29, 2005 [Page 7] Internet-Draft Media Privacy in SIP June 2005 Wolfgang Kellerer DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: kellerer@docomolab-euro.com Srisakul Thakolsri DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: thakolsri@docomolab-euro.com Shacham, et al. Expires December 29, 2005 [Page 8] Internet-Draft Media Privacy in SIP June 2005 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shacham, et al. Expires December 29, 2005 [Page 9]