One document matched: draft-shacham-sip-media-privacy-00.txt
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: <sip:bob@phone1.example.com>;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]
| PAFTECH AB 2003-2026 | 2026-04-23 15:08:07 |