SIPPING J. Rosenberg
Internet-Draft Cisco Systems
Expires: January 19, 2006 G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
July 18, 2005
A Framework for Consent-Based Communications in the Session Initiation
Protocol (SIP)
draft-ietf-sipping-consent-framework-02.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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered
Rosenberg, et al. Expires January 19, 2006 [Page 1]
Internet-Draft Consent Framework July 2005
from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks.
This document identifies a framework for consent-based communications
in SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consent between User Agents . . . . . . . . . . . . . . . . 3
4. Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Structure of a Permission . . . . . . . . . . . . . . . . . 5
6. Two-party Scenario . . . . . . . . . . . . . . . . . . . . . 7
7. Permission Servers . . . . . . . . . . . . . . . . . . . . . 8
8. Relay Scenario . . . . . . . . . . . . . . . . . . . . . . . 10
9. Relays Obtaining Permissions . . . . . . . . . . . . . . . . 11
9.1 Permission Document Authentication . . . . . . . . . . . . 12
9.2 Amplification Prevention . . . . . . . . . . . . . . . . . 12
10. Attemping Communication . . . . . . . . . . . . . . . . . . 13
11. Registrations . . . . . . . . . . . . . . . . . . . . . . . 15
12. Permission Revocation . . . . . . . . . . . . . . . . . . . 18
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.1 Normative References . . . . . . . . . . . . . . . . . . 19
15.2 Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 21
Rosenberg, et al. Expires January 19, 2006 [Page 2]
Internet-Draft Consent Framework July 2005
1. Introduction
The Session Initiation Protocol (SIP) [1] supports communications
across many media types, including real-time audio, video, text,
instant messaging and presence. This communication is established by
the transmission of various SIP requests (such as INVITE and MESSAGE
[2]) from an initiator to the recipient, with whom communication is
desired. Although a recipient of such a SIP request can reject the
request, and therefore decline the session, a SIP network will
deliver a SIP request to the recipient without their explicit
consent.
Receipt of these requests without explicit consent can cause a number
of problems in SIP networks. These include spam and DoS (Denial of
Service) attacks. These problems are described in more detail in a
companion requirements document [5].
This specification defines a basic framework for adding consent-based
communication to SIP.
2. Definitions
Recipient URI: The request-URI of an outgoing request sent by an
entity (e.g., a user agent or a proxy). The sending of such
request may have been the result of a translation operation.
Target URI: The request-URI of an incoming request that arrives to an
entity (e.g., a proxy) that will perform a translation operation.
Translation operation: Operation by which an entity (e.g., a proxy)
translates the request URI of an incoming request (i.e., the
target URI) into one or more URIs (i.e., recipient URIs) which are
used as the request URIs of one or more outgoing requests.
3. Consent between User Agents
The simplest type of consent occurs between user agents. Given a set
of user agents using consent-based communications, any particular
user agent needs to obtain permission to communicate with any other
user agent. That is, if user agent A wants to communicate with user
agent B, user agent A needs to obtain permission from user agent B in
order to do so.
This situation can be found in many current instant messaging
systems, which do not allow sending an instant message unless the
receiving user has explicitly given permission to the sender.
Rosenberg, et al. Expires January 19, 2006 [Page 3]
Internet-Draft Consent Framework July 2005
4. Relays
In addition to the simple scenario described in Section 3 where user
agents obtain permissions to communicate directly between them. this
framework covers scenarios that involve relays between the user
agents.
A relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-
Back User Agent), or some hybrid, which receives a request and
translates the request URI into one or more next hop URIs to which it
then delivers a request. The request URI of the incoming request is
referred to as 'target URI' and the destination URI of the outgoing
requests is referred to as 'recipient URIs', as shown in Figure 1.
+---------------+
| | recipient URI
| |---------------->
target URI | Translation |
-------------->| Operation | recipient URI
| |---------------->
| |
+---------------+
Figure 1: Translation operation
Thus, an essential aspect of a relay is that of translation. When a
relay receives a request, it translates the request URI into one or
more additional URIs. Or, more generally, it can create outgoing
requests to one or more additional URIs. The translation operation
is what creates the consent problem.
Additionally, since the translation operation can result in more than
one URI, it is also the source of amplification. Servers that do not
perform translations, such as outbound proxy servers, do not cause
amplification.
Since the translation operation is based on local policy or local
data (such as registrations), it is the vehicle by which a request is
delivered directly to an endpoint, when it would not otherwise be
possible to. In other words, if a spammer has the address of a user,
'sip:user@example.com', it cannot deliver a MESSAGE request to the UA
(User Agent) of that user without having access to the registration
data that maps 'sip:user@example.com' to the user agent on which that
user is present. Thus, it is the usage of this registration data,
and more generally, the translation logic, which must be authorized
in order to prevent undesired communications.
Rosenberg, et al. Expires January 19, 2006 [Page 4]
Internet-Draft Consent Framework July 2005
The reference architecture is shown in Figure 2. In this
architecture, a user agent client (UAC) wishes to send a message to a
request URI representing a resource in domain A (sip:resource@A).
This request may pass through a local outbound proxy (not shown), but
eventually arrives at a server authoritative for domain A. This
server, which acts as a relay, performs a translation operation,
translating the target URI into one or more recipient URIs, which may
or may not belong to domain A. This relay may be, for instance, a
proxy server or a URI-list service [7].
+-------+
| |
>| UAS |
+-------------+ / | |
| Translation | / +-------+
| Rules | /
+-------------+ /
| /
V /
+-----+ +-------+ / +-------+
| | | |/ | |
| UAC |------>| Relay |-------->| Proxy |
| | | |\ | |
+-----+ +-------+ \ +-------+
\
\ [...]
\
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
Figure 2: Relay performing a translation
5. Structure of a Permission
This framework centers on the idea that a relay will only perform a
translation if a permission is in place authorizing that translation.
Thus, the translation rules associated to a translation include a set
of recipient URIs and the permissions associated with each of these
URIs. For example, one recipient may have given permission for the
translation while another recipient may not have given it. In this
case, the relay would only be authorized to perform the translation
towards the recipient that gave permission.
Rosenberg, et al. Expires January 19, 2006 [Page 5]
Internet-Draft Consent Framework July 2005
A permission is an object, represented in XML, that contains several
pieces of data:
Identity of the Sender: A URI representing the identity of the sender
for whom permissions are granted.
Identity of the Original Recipient: A URI representing the identity
of the original recipient, which is used as the input for the
translation operation. This is also called the target URI.
Identity of the Final Recipient: A URI representing the result of the
translation. The permission grants ability for the sender to send
requests to the target URI, and for a relay receiving those
requests to forward them to this URI. This is also called the
recipient URI.
Operations Permitted: A set of specific methods or qualifiers for
which the permission applies. For example, the permission may
only grant relaying for INVITE requests and not for MESSAGE
requests.
Signature: A digital signature over the rest of the permission,
signed by an entity that can identify itself as the recipient URI.
The signature is not always present.
Permission documents may contain wildcards. For example, a
permission document may authorize any relay to forward INVITE
requests coming from a particular sender to a particular recipient.
Such a permission document would apply to any target URI. That is,
the field containing the identity of the original recipient would
match any URI.
The format for permission documents is defined in...
OPEN ISSUE: the common policy format [3] has elements that we may
want to reuse (e.g., identity). However, we probably want to define
our own format instead of extending that one because we do not need
actions or transformations, and we need more than one identity per
document. The new format would be something like the one in
Figure 3.
Figure 3 contains an example of a permission document that authorizes
the relay handling the URI list 'sip:bobs-friends@example.com' to
relay INVITE requests to Alice no matter who the sender is.
Rosenberg, et al. Expires January 19, 2006 [Page 6]
Internet-Draft Consent Framework July 2005
<target>
<identity>
<id>bobs-friends@example.com</id>
</identity>
</target>
<sender>
<identity>
<any-identity/>
</identity>
</sender>
<recipient>
<identity>
<id>alice@example.com</id>
</identity>
</recipient>
<operations>
<method>INVITE</method>
</operations>
Figure 3: Permission document
6. Two-party Scenario
This section describes the fundamental operations of this framework
in a two-party scenario. The descriptions are illustrated with an
example (see Figure 4).
A@example.com B@example.com
| |
|(1) CONSENT B@example |
|Permission-Upload: uri-up |
|Permission Document |
|-------------------------->|
|(2) 202 Accepted |
|<--------------------------|
| |
|(3) PUBLISH uri-up |
|Permission Document |
|<--------------------------|
|(4) 200 OK |
|-------------------------->|
Figure 4: Two-party Scenario
A creates a CONSENT request which contains the permission document in
Figure 5 in its body:
Rosenberg, et al. Expires January 19, 2006 [Page 7]
Internet-Draft Consent Framework July 2005
<target>
<identity>
<any-identity/>
</identity>
</target>
<sender>
<identity>
<id>A@example.com</id>
</identity>
</sender>
<recipient>
<identity>
<id>B@example.com</id>
</identity>
</recipient>
<operations>
<method>INVITE</method>
</operations>
Figure 5: Permission document
This document describes the permissions that A is requesting from B.
Note that the permission applies to any target URI. Therefore, the
permission is not specific to any particular relay.
Additionally, the CONSENT request contains the URI where B is
requested to upload the permission document. This URI is carried in
a Permission-Upload header field.
On receiving the CONSENT request, B signs the permission document and
uploads it to the URI in the Permission-Upload header field using a
PUBLISH request. At this point, A has permission to send INVITE
requests to B.
7. Permission Servers
Section 6 described how a user agent receiving a CONSENT request can
use a PUBLISH request to grant certain permissions. Nevertheless,
users are not on-line all the time and, so, sometimes are not able to
receive CONSENT requests.
This issue is also found in presence, where a user's status is
reported by a presence server instead of by the user's user agents,
which can go on and off-line. Similarly, we define permission
servers. Permission servers are network elements that act as SIP
user agents and handle CONSENT requests for a user.
Permission servers inform users about new CONSENT requests using the
Rosenberg, et al. Expires January 19, 2006 [Page 8]
Internet-Draft Consent Framework July 2005
"grant-permission" event package. Figure Figure 6 illustrates this
point.
The user associated with the target URI SUBSCRIBEs (1) to the "grant-
permission" event package at the permission server. This event
package models the state of all pending CONSENT requests for a
particular resource, for which permissions do not yet exist. When a
new CONSENT request (3) arrives for which permissions have not been
granted, a NOTIFY (5) is sent to the user. This informs them that
permission is needed for a particular sender. The NOTIFY contains
the permissions requested and the URI to upload the document.
There is a strong similarity between the watcherinfo event package
and the grant-permission event package. Indeed, the grant-
permission package is effectively a superset of watcherinfo. Once
in place, presentities could use the grant-permission event
package for presence in addition to all other services for which
opt-in is being provided.
When a user is notified of a new pending CONSENT request, the user
follows regular procedures to upload the permissions that were
requested (7).
Rosenberg, et al. Expires January 19, 2006 [Page 9]
Internet-Draft Consent Framework July 2005
A B's Permission B
Server
| | |
| |(1) SUBSCRIBE |
| |Event: grant-permission
| |<------------------|
| |(2) 200 OK |
| |------------------>|
|(3) CONSENT B@example |
|Permission-Upload: uri-up |
|Permission Document| |
|------------------>| |
|(4) 202 Accepted | |
|<------------------| |
| |(5) NOTIFY |
| |uri-up |
| |Permission Document|
| |------------------>|
| |(6) 200 OK |
| |<------------------|
|(7) PUBLISH uri-up | |
|Permission Document| |
|<--------------------------------------|
|(8) 200 OK | |
|-------------------------------------->|
Figure 6: Permission server operation
8. Relay Scenario
Manipulating translation rules at a relay may involve obtaining
permissions from some users. For example, if a new recipient URI is
added to a URI-list service, the URI-list service will need to obtain
permission to send request to that URI. Thus, when a new recipient
URI is added to a set of translation rules, the URI will be in the
"Permission Pending" state until permissions are obtained for it.
Relays do not send requests to recipient URIs in this state.
Therefore, effectively, adding a new recipient URI to a set of
translation rules involves two operations: adding the new URI to the
list of recipient URIs and obtaining permissions to send requests to
it.
The addition of the new recipient URI can be performed using
different methods (e.g., XCAP). All these methods provide the entity
adding the recipient URI with a URI to upload the permission document
associated with the new recipient URI. Such an entity can go off
Rosenberg, et al. Expires January 19, 2006 [Page 10]
Internet-Draft Consent Framework July 2005
obtain the permissions and then upload them into the relay. Figure 7
shows an example of this process. A adds B's URI to the relay's list
of recipient URIs, obtains permissions from B, and uploads them to
the relay.
A@example.com Relay B@example.com
| | |
|(1) Add Recipient B@example.com |
|------------------>| |
|(2) Permission Pending |
|uri-up-relay | |
|<------------------| |
| | |
|(3) CONSENT B@example |
|Permission-Upload: uri-up |
|Permission Document| |
|-------------------------------------->|
|(4) 202 Accepted | |
|<--------------------------------------|
|(5) PUBLISH uri-up | |
|Permission Document| |
|<--------------------------------------|
|(6) 200 OK | |
|-------------------------------------->|
| | |
|(7) PUBLISH uri-up-relay |
|Permission Document| |
|------------------>| |
|(8) 200 OK | |
|<------------------| |
Figure 7: Relay Scenario
9. Relays Obtaining Permissions
Section 8 shows how a user can add a recipient URI to a relay's
translation rules, obtain permissions to send requests to it, and
upload them to the relay. This works well when there is an
infrastructure that allows users to sign permission documents. This
way, the relay knows that the permission document was generated by
the owner of the recipient URI. However, such infrastructure is not
always available.
Additionally, some architectures prevent users from communicating
directly between them forcing them to always communicate via a relay.
Rosenberg, et al. Expires January 19, 2006 [Page 11]
Internet-Draft Consent Framework July 2005
In this case, a user cannot contact directly the owner of the
recipient URI to obtain permissions to send requests to the URI.
This framework handles the previous situations by having relays
request permissions directly from the recipient URIs. The relay
sends a CONSENT request to the recipient URI. As usual, the CONSENT
request carries a permission document describing the permissions
being requested and a URI where the permission document needs to be
uploaded. The recipient uses a PUBLISH request to upload the
permission document to that URI.
9.1 Permission Document Authentication
A relay obtaining permissions from a recipient needs to make sure
that the permission document received was generated by the recipient.
If the infrastructure does not allow signing permission documents,
the relay can use two methods to authenticate the permission
document: SIP identity or a return routability test.
The SIP identity mechanism can be used to authenticate the sender of
the PUBLISH request uploading the permission document. This way, the
relay ensures that the entity uploading the permission document is
the owner of the recipient URI.
Return routability tests do not provide the same level of security as
SIP identity, but they provide a good-enough security level in
architectures where the SIP identity mechanism is not available. The
relay generates an unguessable URI (e.g., with a long and random-
looking user part) and places it in the CONSENT request. The
recipient needs to upload the permission document to that URI.
Using unguessable URIs ensures that the entities that have handled
the CONSENT request are the only ones that know the URI. If the
CONSENT request is sent to a SIPS URI, the only entities able to
upload a forged permission document are the proxies that may handle
the CONSENT request between the relay and the recipient.
9.2 Amplification Prevention
Having relays contact directly recipients to obtain documents creates
a potential amplification attack. A user adds a large number of URIs
to a relay's translation rules and has the relay request permissions
for all of them. In this case, the relay would generate a large
number of CONSENT requests and send them to the URIs provided by the
user. These URIs are the victims of the attack.
To prevent this attack, a user adding URIs to a relays translation
rules is requested to generate an amount of bandwidth that is
Rosenberg, et al. Expires January 19, 2006 [Page 12]
Internet-Draft Consent Framework July 2005
comparable with the bandwidth the relay will generate to request
permissions for those URIs. The user needs to send a REFER request
to the relay for each recipient URI. Each REFER request requests the
relay to generate a CONSENT request towards one of the recipient
URIs. Figure 8 illustrates this mechanism. Note that the sender of
the REFER request uses the norefersub extension, which supreses the
implicit subscription that is associated with REFER tranl
A@example.com Relay B@example.com
| | |
|(1) Add Recipient B@example.com |
|------------------>| |
|(2) Permission Pending |
|<------------------| |
| | |
|(3) REFER | |
|Refer-To: B@example.com?method=CONSENT |
|------------------>| |
|(4) 200 OK | |
|<------------------| |
| |(5) CONSENT B@example
| |Permission-Upload: uri-up-relay
| |Permission Document|
| |------------------>|
| |(6) 202 Accepted |
| |<------------------|
| |(7) PUBLISH uri-up-relay
| |Permission Document|
| |<------------------|
| |(8) 200 OK |
| |------------------>|
Figure 8: Amplification Attack Prevention
Generally, the mechanism to add new recipient URIs provides the user
adding the new recipients with information on the status of the
recipient URIs (i.e., whether or not permissions have been obtained
for them). This way, the user knows when all the permissions have
been successfully uploaded to the relay by the recipients. One
mechanism to provide such information is the wait-permission event
package.
10. Attemping Communication
In the scenarios described so far, a user adds recipient URIs to the
translation rules of a relay. However, the relay does not perform
translations towards those URIs until permissions are obtained. If a
Rosenberg, et al. Expires January 19, 2006 [Page 13]
Internet-Draft Consent Framework July 2005
user wants to know which recipient URIs are active at a given point,
the user contacts the relay to obtain this information.
URI-list services using request-contained URI lists are a special
case because the addition of recipient URIs is performed at the same
time as the communication attempt. A user places a set of recipient
URIs in a request and sends it to a relay so that the relay sends a
similar request to all those recipient URIs. If the relay cannot
send the request to a URI because it does not have permission to do
so, the user needs to be informed.
The relay can inform the user with a 470 (Consent Needed) response.
Such a response contains the URIs for which there is not permission
and a URI where the user can subscribe to get information about the
status of the permissions for those URIs. On receiving such a
response, the user sends a REFER for each URI for which there is no
permission. Figure 9 illustrates the use of 470 (Consent Needed)
responses.
Rosenberg, et al. Expires January 19, 2006 [Page 14]
Internet-Draft Consent Framework July 2005
A@example.com Relay B@example.com
| | |
|(1) INVITE | |
|B@example.com | |
|C@example.com | |
|------------------>| |
|(2) 470 Consent Needed |
|Consent-Needed: B@example.com |
|Call-Info: 123@Relay;purpose=wait-permission
|<------------------| |
|(3) ACK | |
|------------------>| |
| | |
|(4) SUBSCRIBE 123@Relay |
|Event: wait-permission |
|------------------>| |
|(5) 200 OK | |
|<------------------| |
|(6) REFER | |
|Refer-To: B@example.com?method=CONSENT |
|------------------>| |
|(7) 200 OK | |
|<------------------| |
| |(8) CONSENT B@example
| |Permission-Upload: uri-up-relay
| |Permission Document|
| |------------------>|
| |(9) 202 Accepted |
| |<------------------|
| |(10) PUBLISH uri-up-relay
| |Permission Document|
| |<------------------|
| |(11) 200 OK |
| |------------------>|
|(12) NOTIFY | |
|<------------------| |
|(13) 200 OK | |
|------------------>| |
Figure 9: Communication attempt
11. Registrations
Registrations are a special type of translations. The user
registering has a trust relationship with the registrar in its home
domain. This is not the case when a user gives any type of
permissions to a relay in a different domain.
Rosenberg, et al. Expires January 19, 2006 [Page 15]
Internet-Draft Consent Framework July 2005
Traditionally, REGISTER transactions have performed two operations at
the same time: setting up a translation and authorizing the use of
that translation. For example, a user registering its current
contact URI is giving permission to the registrar to forward traffic
sent to the user's AoR (Address of Records) to the registered contact
URI. This works fine when the entity registering is the same as the
one that will be receiving traffic at a later point (e.g., over the
same connection as the registration). However, this schema creates
some potential attacks which relate to third-party registrations.
An attacker binds, via a registration, his or her AoR with the
contact URI of a victim. Now, the victim will receive unsolicited
traffic that was originally addressed to the attacker.
The process of authorizing registration is shown in Figure 10.
Rosenberg, et al. Expires January 19, 2006 [Page 16]
Internet-Draft Consent Framework July 2005
A@example.com Registrar a@ws123.example.com
| | |
|(1) REGISTER | |
|Contact: a@ws123.example.com |
|Supported: consent-reg |
|------------------>| |
|(2) 200 OK | |
|Required: consent-reg |
|Consent-Needed: a@ws123.example.com |
|<------------------| |
| | |
|(3) SUBSCRIBE example.com |
|Event: reg-event | |
|------------------>| |
|(4) 200 OK | |
|<------------------| |
|(5) REFER | |
|Refer-To: a@ws123.example.com?method=CONSENT
|------------------>| |
|(6) 200 OK | |
|<------------------| |
| |(7) CONSENT a@ws123.example
| |Permission-Upload: uri-up
| |Permission Document|
| |------------------>|
| |(8) 202 Accepted |
| |<------------------|
| |(9) PUBLISH uri-up |
| |Permission Document|
| |<------------------|
| |(10) 200 OK |
| |------------------>|
|(11) NOTIFY | |
|<------------------| |
|(12) 200 OK | |
|------------------>| |
Figure 10: Registration
The permission document uploaded to the registrar in (9) is shown in
Figure 11. Note that this permission document is very general. That
is, it authorizes the registrar to forward any request from any
sender. This is the type of granularity that this framework intends
to provide for registrations. Users who want to define how incoming
requests are treated with a finer granularity should use other
mechanisms such as CPL.
Rosenberg, et al. Expires January 19, 2006 [Page 17]
Internet-Draft Consent Framework July 2005
<target>
<identity>
<id>A@example.com</id>
</identity>
</target>
<sender>
<identity>
<any-identity/>
</identity>
</sender>
<recipient>
<identity>
<id>a@ws123.example.com</id>
</identity>
</recipient>
<operations>
<any-method/>
</operations>
Figure 11: Permission document uploaded to the registrar
12. Permission Revocation
A user that wants to revoke a permission needs to wait until it
receives a new request using that permission. Such request which
will contain a Permission-Used header field. The Permission-Used
header field contains a URI where the permission document used for
the translation can be downloaded and a URI where the user can upload
a new permission document (e.g., a permission document that does not
allow a particular translation any longer).
When permission document authorization is based on a return
routability test, requests with Permission-Used header fields need to
be sent to a SIPS URI.
OPEN ISSUE: do we want to force all the traffic from the translation
to be sent using TLS so that every request carries a Permission-USer
header field or do we want to come up with a mechanism whereby the
client can request the relay to send it a TLS-protected request with
the URI to upload the new permission document? In the latter case,
regular traffic from the relay to the user needs not be TLS-
protected.
OPEN ISSUE: we may want to define a validity element so that
permission documents are not valid for ever.
Rosenberg, et al. Expires January 19, 2006 [Page 18]
Internet-Draft Consent Framework July 2005
13. IANA Considerations
TBD.
14. Security Considerations
TBD.
Editor's note: we have to avoid that attackers provide permissions
for translations that apply to other users (e.g., allow everyone to
send traffic to a victim) and that attackers provide permissions for
a translation that apply to them but routes to a victim (e.g., 3rd
party registration that binds attacker@relay to victim@somewhere).
For the former we need authentication (e.g., SIP identity) and for
the latter we relay on the routing infrastructure to route CONSENTs
to the same place the traffic will be sent to once permissions are
obtained (i.e., a return routability test).
15. References
15.1 Normative References
[1] 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.
[2] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
15.2 Informative References
[3] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-04 (work in
progress), February 2005.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05 (work in progress), May 2005.
[5] Rosenberg, J., "Requirements for Consent-Based Communications in
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-consent-reqs-00 (work in progress),
October 2004.
[6] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-02 (work in progress),
February 2005.
Rosenberg, et al. Expires January 19, 2006 [Page 19]
Internet-Draft Consent Framework July 2005
[7] Camarillo, G. and A. Roach, "Requirements and Framework for
Session Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-03 (work
in progress), April 2005.
Authors' Addresses
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Gonzalo Camarillo (editor)
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Dean Willis
Cisco Systems
2200 E. Pres. George Bush Turnpike
Richardson, TX 75082
USA
Email: dean.willis@softarmor.com
Rosenberg, et al. Expires January 19, 2006 [Page 20]
Internet-Draft Consent Framework July 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.
Rosenberg, et al. Expires January 19, 2006 [Page 21]