< draft-ietf-sip-consent-framework-03.txt   draft-ietf-sip-consent-framework-04.txt >
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Camarillo, Ed. Intended status: Standards Track G. Camarillo, Ed.
Expires: May 16, 2008 Ericsson Expires: August 3, 2008 Ericsson
D. Willis D. Willis
Unaffiliated Unaffiliated
November 13, 2007 January 31, 2008
A Framework for Consent-based Communications in the Session Initiation A Framework for Consent-based Communications in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sip-consent-framework-03.txt draft-ietf-sip-consent-framework-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2008. This Internet-Draft will expire on August 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Session Initiation Protocol (SIP) supports communications across The Session Initiation Protocol (SIP) supports communications for
many media types, including real-time audio, video, text, instant several services, including, real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including amplification, and DoS (Denial of for malicious purposes, including amplification, and DoS (Denial of
Service) attacks. This document identifies a framework for consent- Service) attacks. This document identifies a framework for consent-
based communications in SIP. based communications in SIP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4
3. Relays and Translations . . . . . . . . . . . . . . . . . . . 5 3. Relays and Translations . . . . . . . . . . . . . . . . . . . 5
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 7 4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 7
4.2. Consenting Manipulations on a Relay's Transaction Logic . 8 4.2. Consenting Manipulations on a Relay's Transaction Logic . 8
4.3. Store-and-forward Servers . . . . . . . . . . . . . . . . 9 4.3. Store-and-forward Servers . . . . . . . . . . . . . . . . 9
4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 10 4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 10
4.5. Entities Implementing this Framework . . . . . . . . . . . 10 4.5. Entities Implementing this Framework . . . . . . . . . . . 10
5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 10 5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 12 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 12
5.1.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 12 5.1.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13
5.2. Subscription to the Permission Status . . . . . . . . . . 12 5.2. Subscription to the Permission Status . . . . . . . . . . 13
5.2.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13 5.2.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 14
5.3. Request for Permission . . . . . . . . . . . . . . . . . . 13 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 14
5.3.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13 5.3.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 14
5.4. Permission Document Structure . . . . . . . . . . . . . . 15 5.4. Permission Document Structure . . . . . . . . . . . . . . 16
5.5. Permission Requested Notification . . . . . . . . . . . . 17 5.5. Permission Requested Notification . . . . . . . . . . . . 17
5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 17 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 18
5.6.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 17 5.6.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 18
5.7. Permission Granted Notification . . . . . . . . . . . . . 19 5.7. Permission Granted Notification . . . . . . . . . . . . . 20
5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 19 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 20
5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 20 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 21
5.9.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 21 5.9.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 22
5.9.2. Definition of the 470 Response Code . . . . . . . . . 21 5.9.2. Definition of the 470 Response Code . . . . . . . . . 22
5.9.3. Definition of the Permission-Missing Header Field . . 21 5.9.3. Definition of the Permission-Missing Header Field . . 23
5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 22 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 23
5.11. Relays Generating Traffic towards Recipients . . . . . . . 24 5.11. Relays Generating Traffic towards Recipients . . . . . . . 26
5.11.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 24 5.11.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 26
5.11.2. Definition of the Trigger-Consent Header Field . . . . 24 5.11.2. Definition of the Trigger-Consent Header Field . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. Registration of the 470 Response Code . . . . . . . . . . 25 6.1. Registration of the 470 Response Code . . . . . . . . . . 27
6.2. Registration of the Trigger-Consent Header Field . . . . . 25 6.2. Registration of the Trigger-Consent Header Field . . . . . 27
6.3. Registration of the Permission-Missing Header Field . . . 26 6.3. Registration of the Permission-Missing Header Field . . . 27
6.4. Registration of the target-uri Header Field Parameter . . 26 6.4. Registration of the target-uri Header Field Parameter . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] supports The Session Initiation Protocol (SIP) [RFC3261] supports
communications across many media types, including real-time audio, communications for several services, including, real-time audio,
video, text, instant messaging, and presence. This communication is video, text, instant messaging, and presence. This communication is
established by the transmission of various SIP requests (such as established by the transmission of various SIP requests (such as
INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with
whom communication is desired. Although a recipient of such a SIP whom communication is desired. Although a recipient of such a SIP
request can reject the request, and therefore decline the session, a request can reject the request, and therefore decline the session, a
network of SIP proxy servers will deliver a SIP request to its network of SIP proxy servers will deliver a SIP request to its
recipients without their explicit consent. recipients without their explicit consent.
Receipt of these requests without explicit consent can cause a number Receipt of these requests without explicit consent can cause a number
of problems. These include amplification and DoS (Denial of Service) of problems. These include amplification and DoS (Denial of Service)
skipping to change at page 5, line 15 skipping to change at page 5, line 15
3. Relays and Translations 3. Relays and Translations
Relays play a key role in this framework. A relay is defined as any Relays play a key role in this framework. A relay is defined as any
SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some
hybrid, which receives a request, translates its Request-URI into one hybrid, which receives a request, translates its Request-URI into one
or more next hop URIs, and delivers the request to those URIs. The or more next hop URIs, and delivers the request to those URIs. The
Request-URI of the incoming request is referred to as 'target URI' Request-URI of the incoming request is referred to as 'target URI'
and the destination URIs of the outgoing requests are referred to as and the destination URIs of the outgoing requests are referred to as
'recipient URIs', as shown in Figure 1. 'recipient URIs', as shown in Figure 1.
+---------------+ +---------------+ recipient URI
| | recipient URI
| |---------------->
target URI | Translation |
-------------->| Operation | recipient URI
| |----------------> | |---------------->
| | | |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+ +---------------+
Figure 1: Translation operation Figure 1: Translation operation
Thus, an essential aspect of a relay is that of translation. When a Thus, an essential aspect of a relay is that of translation. When a
relay receives a request, it translates the Request-URI (target URI) relay receives a request, it translates the Request-URI (target URI)
into one or more additional URIs (recipient URIs). Through this into one or more additional URIs (recipient URIs). Through this
translation operation, the relay can create outgoing requests to one translation operation, the relay can create outgoing requests to one
or more additional recipient URIs, thus creating the consent problem. or more additional recipient URIs, thus creating the consent problem.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
(User Agent) of that user without having access to the registration (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 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, user is present. Thus, it is the usage of this registration data,
and more generally, the translation logic, which is expected to be and more generally, the translation logic, which is expected to be
authorized in order to prevent undesired communications. Of course, authorized in order to prevent undesired communications. Of course,
if the spammer knows the address of the user agent, it will be able if the spammer knows the address of the user agent, it will be able
to deliver requests directly to it. to deliver requests directly to it.
Translation operations that result in more than one recipient URI are Translation operations that result in more than one recipient URI are
a source of amplification. Servers that do not perform translations, a source of amplification. Servers that do not perform translations,
such as outbound proxy servers, do not cause amplification. such as outbound proxy servers, do not cause amplification. On the
other hand, servers that perform translations (e.g., inbound proxies
authoritatively responsible for a SIP domain) may cause amplification
if the user can be reached at multiple endpoints (thereby resulting
in multiple recipient URIs.)
Figure 2 shows a relay that performs translations. The user agent Figure 2 shows a relay that performs translations. The user agent
client in the figure sends a SIP request to a URI representing a client in the figure sends a SIP request to a URI representing a
resource in the domain 'example.com' (sip:resource@example.com). resource in the domain 'example.com' (sip:resource@example.com).
This request can pass through a local outbound proxy (not shown), but This request can pass through a local outbound proxy (not shown), but
eventually arrives at a server authoritative for the domain eventually arrives at a server authoritative for the domain
'example.com'. This server, which acts as a relay, performs a 'example.com'. This server, which acts as a relay, performs a
translation operation, translating the target URI into one or more translation operation, translating the target URI into one or more
recipient URIs, which can but need not belong to the domain recipient URIs, which can but need not belong to the domain
'example.com'. This relay can be, for instance, a proxy server or a 'example.com'. This relay can be, for instance, a proxy server or a
skipping to change at page 8, line 12 skipping to change at page 8, line 18
or is otherwise terminated, the registrar deletes the permissions or is otherwise terminated, the registrar deletes the permissions
related to that contact address. related to that contact address.
It is also RECOMMENDED that relays request recipients to refresh It is also RECOMMENDED that relays request recipients to refresh
their permissions periodically. If a recipient fails to refresh its their permissions periodically. If a recipient fails to refresh its
permissions for a given period of time, the relay SHOULD delete the permissions for a given period of time, the relay SHOULD delete the
permissions related to that recipient. permissions related to that recipient.
This framework does not provide any guidance for the values of the This framework does not provide any guidance for the values of the
refreshment intervals because different applications can have refreshment intervals because different applications can have
different requirements to set those values. different requirements to set those values. For example, a relay
dealing with recipients that do not implement this framework may
choose to use longer intervals between refreshes. The refresh
process in such recipients has to be performed manually by their
users (since the recipients do not implement this framework) and
having too short refresh intervals may become too heavy a burden
for those users.
4.2. Consenting Manipulations on a Relay's Transaction Logic 4.2. Consenting Manipulations on a Relay's Transaction Logic
This framework aims to ensure that any particular relay only performs This framework aims to ensure that any particular relay only performs
translations towards destinations that have given the relay translations towards destinations that have given the relay
permission to perform such a translation. Consequently, when the permission to perform such a translation. Consequently, when the
translation logic of a relay is manipulated (e.g., a new recipient translation logic of a relay is manipulated (e.g., a new recipient
URI is added), the relay obtains permission from the new recipient in URI is added), the relay obtains permission from the new recipient in
order to install the new translation logic. Relays ask recipients order to install the new translation logic. Relays ask recipients
for permission using MESSAGE [RFC3428] requests. for permission using MESSAGE [RFC3428] requests.
skipping to change at page 9, line 13 skipping to change at page 9, line 30
In any case, relays implementing this framework SHOULD have a means In any case, relays implementing this framework SHOULD have a means
to indicate that a particular recipient URI is in the states to indicate that a particular recipient URI is in the states
specified in [I-D.ietf-sipping-pending-additions] (i.e., pending, specified in [I-D.ietf-sipping-pending-additions] (i.e., pending,
waiting, error, denied, or granted). waiting, error, denied, or granted).
4.3. Store-and-forward Servers 4.3. Store-and-forward Servers
When a MESSAGE request with a permission document arrives to the When a MESSAGE request with a permission document arrives to the
recipient URI to which it was sent by the relay, the receiving user recipient URI to which it was sent by the relay, the receiving user
can grant or deny the permission needed to perform the translation. can grant or deny the permission needed to perform the translation.
However, users are not on-line all the time and, so, sometimes are However, the receiving user may not be available when the MESSAGE
not able to receive MESSAGE requests. request arrives, or it may have expressed preferences to block all
incoming requests for a certain time period. In such cases, a store-
This issue is also found in presence, where a user's status is and-forward server can act as a substitute for the user and buffer
reported by a presence server instead of by the user's user agents, the incoming MESSAGE requests, which are subsequently delivered to
which can go on and off line. Similarly, store-and-forward servers the user when he or she is available again.
are elements that act as SIP user agents and handle MESSAGE requests
for a user. A store-and-forward server stores incoming MESSAGE
requests when the user is unavailable and delivers them when the user
is available again.
There are several mechanisms to implement store-and-forward message There are several mechanisms to implement store-and-forward message
services (e.g., with an instant message to email gateway). Any of services (e.g., with an instant message to email gateway). Any of
these mechanisms can be used between a user agent and its store-and- these mechanisms can be used between a user agent and its store-and-
forward server as long as they agree on which mechanism to use. forward server as long as they agree on which mechanism to use.
Therefore, this framework does not make any provision for the Therefore, this framework does not make any provision for the
interface between user agents and their store-and-forward servers. interface between user agents and their store-and-forward servers.
Note that the same store-and-forward message service can handle Note that the same store-and-forward message service can handle
all incoming MESSAGE requests for a user while this is off line, all incoming MESSAGE requests for a user while this is off line,
not only those MESSAGE requests with a permission document in not only those MESSAGE requests with a permission document in
their bodies. their bodies.
Even though store-and-forward servers perform a useful function and Even though store-and-forward servers perform a useful function and
they are expected to be deployed in most domains, some domains will they are expected to be deployed in most domains, some domains will
not deploy them from day one. However, user agents and relays in not deploy them from the outset. However, user agents and relays in
domains without store-and-forward servers can still use this consent domains without store-and-forward servers can still use this consent
framework. framework.
When a relay requests permissions from an off-line user agent that When a relay requests permissions from an off-line user agent that
does not have an associated store-and-forward server, the relay will does not have an associated store-and-forward server, the relay will
obtain an error response indicating that its MESSAGE request could obtain an error response indicating that its MESSAGE request could
not be delivered. The client that attempted to add the off-line user not be delivered. The client that attempted to add the off-line user
to the relay's translation logic will be notified about the error to the relay's translation logic will be notified about the error
(e.g., using the Pending Additions event package (e.g., using the Pending Additions event package
[I-D.ietf-sipping-pending-additions]). This client MAY attempt to [I-D.ietf-sipping-pending-additions]). This client MAY attempt to
add the same user at a later point, hopefully when the user is on- add the same user at a later point, hopefully when the user is on-
line. Clients can discover whether or not a user is on-line by using line. Clients can discover whether or not a user is on-line by using
a presence service, for instance. a presence service, for instance.
4.4. Recipients Grant Permissions 4.4. Recipients Grant Permissions
Relays include in the permission documents they generate URIs that Permission documents generated by a relay include URIs that can be
can be used by the recipient of the document to grant or deny the used by the recipient of the document to grant or deny the relay the
relay the permission described in the document. Relays always permission described in the document. Relays always include SIP URIs
include SIP URIs and can include HTTP [RFC2616] URIs for this and can include HTTP [RFC2616] URIs for this purpose. Consequently,
purpose. Consequently, recipients provide relays with permissions recipients provide relays with permissions using SIP PUBLISH requests
using SIP PUBLISH requests or HTTP GET requests. or HTTP GET requests.
4.5. Entities Implementing this Framework 4.5. Entities Implementing this Framework
The goal of this framework is to keep relays from executing The goal of this framework is to keep relays from executing
translations towards unwilling recipients. Therefore, all relays translations towards unwilling recipients. Therefore, all relays
MUST implement this framework in order to avoid being used to perform MUST implement this framework in order to avoid being used to perform
attacks (e.g., amplification attacks). attacks (e.g., amplification attacks).
This framework has been designed with backwards compatibility in mind This framework has been designed with backwards compatibility in mind
so that legacy user agents (i.e., user agents that do not implement so that legacy user agents (i.e., user agents that do not implement
skipping to change at page 10, line 34 skipping to change at page 10, line 46
acceptable level of functionality. However, it is RECOMMENDED that acceptable level of functionality. However, it is RECOMMENDED that
user agents implement this framework, which includes supporting the user agents implement this framework, which includes supporting the
Pending Additions event package specified in Pending Additions event package specified in
[I-D.ietf-sipping-pending-additions], the format for permission [I-D.ietf-sipping-pending-additions], the format for permission
documents specified in [I-D.ietf-sipping-consent-format], and the documents specified in [I-D.ietf-sipping-consent-format], and the
header fields and response code specified in this document, in order header fields and response code specified in this document, in order
to achieve full functionality. to achieve full functionality.
The only requirement that this framework places on store-and-forward The only requirement that this framework places on store-and-forward
servers is that they need to be able to deliver encrypted and servers is that they need to be able to deliver encrypted and
integrity- protected messages to their user agents, as discussed in integrity-protected messages to their user agents, as discussed in
Section 7. However, this is not a requirement specific to this Section 7. However, this is not a requirement specific to this
framework but a general requirement for store-and-forward servers. framework but a general requirement for store-and-forward servers.
5. Framework Operations 5. Framework Operations
This section specifies this consent framework using an example of the This section specifies this consent framework using an example of the
prototypical call flow. The elements described in Section 4 (i.e., prototypical call flow. The elements described in Section 4 (i.e.,
relays, translations, and store-and-forward servers) play an relays, translations, and store-and-forward servers) play an
essential role in this call flow. essential role in this call flow.
skipping to change at page 11, line 38 skipping to change at page 12, line 36
|--------------->| | | |--------------->| | |
| | | |User B goes | | | |User B goes
| | | | on line | | | | on line
| | |(9) Request for | | | |(9) Request for |
| | | stored messages | | | stored messages
| | |<---------------| | | |<---------------|
| | |(10) Delivery of| | | |(10) Delivery of|
| | | stored messages | | | stored messages
| | |--------------->| | | |--------------->|
| |(11) PUBLISH uri-up | | |(11) PUBLISH uri-up |
| | Permission Document |
| |<--------------------------------| | |<--------------------------------|
| |(12) 200 OK | | | |(12) 200 OK | |
| |-------------------------------->| | |-------------------------------->|
|(13) NOTIFY | | | |(13) NOTIFY | | |
|<---------------| | | |<---------------| | |
|(14) 200 OK | | | |(14) 200 OK | | |
|--------------->| | | |--------------->| | |
Figure 4: Prototypical call flow Figure 4: Prototypical call flow
skipping to change at page 13, line 32 skipping to change at page 14, line 24
5.3. Request for Permission 5.3. Request for Permission
A relay requests permissions from potential recipients to add them to A relay requests permissions from potential recipients to add them to
its translation logic using MESSAGE requests. In our example, on its translation logic using MESSAGE requests. In our example, on
receiving the request to add User B to the translation logic of the receiving the request to add User B to the translation logic of the
relay (1), the relay generates a MESSAGE request (3) towards relay (1), the relay generates a MESSAGE request (3) towards
'sip:B@example.com'. This MESSAGE request carries a permission 'sip:B@example.com'. This MESSAGE request carries a permission
document, which describes the translation that needs to be authorized document, which describes the translation that needs to be authorized
and carries a set of URIs to be used by the recipient to grant or to and carries a set of URIs to be used by the recipient to grant or to
deny the relay permission to perform that translation. User B will deny the relay permission to perform that translation. Since User B
authorize the translation by using one of those URIs, as described in is off line, the MESSAGE request will be buffered by User B's store-
Section 5.6. The MESSAGE request also carries a body part that and-forward server. User B will later go on line and authorize the
contains the same information as the permission document but in a translation by using one of those URIs, as described in Section 5.6.
human-readable format. The MESSAGE request also carries a body part that contains the same
information as the permission document but in a human-readable
format.
When User B uses one of the URIs in the permission document to grant When User B uses one of the URIs in the permission document to grant
or deny permissions, the relay needs to make sure that it was or deny permissions, the relay needs to make sure that it was
actually User B the one using that URI, and not an attacker. The actually User B the one using that URI, and not an attacker. The
relay can use any of the methods described in Section 5.6 to relay can use any of the methods described in Section 5.6 to
authenticate the permission document. authenticate the permission document.
5.3.1. Relay's Behavior 5.3.1. Relay's Behavior
Relays that implement this framework MUST obtain permissions from Relays that implement this framework MUST obtain permissions from
skipping to change at page 14, line 43 skipping to change at page 15, line 38
If you consent to receive traffic sent to If you consent to receive traffic sent to
<sip:alices-friends@example.com>, please use one of the following <sip:alices-friends@example.com>, please use one of the following
URIs: <sips:grant-1awdch5Fasddfce34@example.com> or URIs: <sips:grant-1awdch5Fasddfce34@example.com> or
<https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of <https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of
the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or
<https://example.com/deny-23rCsdfgvdT5sdfgye>. <https://example.com/deny-23rCsdfgvdT5sdfgye>.
--boundary1 --boundary1
Content-Type: application/auth-policy+xml Content-Type: application/auth-policy+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset <cp:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules" xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cp:rule id="f1">
<cp:rule id="1">
<cp:conditions> <cp:conditions>
<cp:identity> <cp:identity>
<cp:many/> <cp:many/>
</cp:identity> </cp:identity>
<recipient> <recipient>
<cp:one id="sip:bob@example.org"/> <cp:one id="sip:bob@example.org"/>
</recipient> </recipient>
<target> <target>
<cp:one id="sip:alices-friends@example.com""/> <cp:one id="sip:alices-friends@example.com"/>
</target>
</target>
</cp:conditions> </cp:conditions>
<cp:actions> <cp:actions>
<trans-handling <trans-handling
perm-uri="sips:grant-1awdch5Fasddfce34@example.com"> perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
grant</trans-handling> grant</trans-handling>
<trans-handling <trans-handling
perm-uri="https://example.com/grant-1awdch5Fasddfce34"> perm-uri="https://example.com/grant-1awdch5Fasddfce34">
grant</trans-handling> grant</trans-handling>
<trans-handling <trans-handling
perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com"> perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com">
deny</trans-handling> deny</trans-handling>
<trans-handling <trans-handling
perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye"> perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye">
deny</trans-handling> deny</trans-handling>
</cp:actions> </cp:actions>
<cp:transformations/> <cp:transformations/>
</cp:rule> </cp:rule>
</cp:ruleset> </cp:ruleset>
--boundary1-- --boundary1--
5.4. Permission Document Structure 5.4. Permission Document Structure
A permission document is the representation (e.g., encoded in XML) of A permission document is the representation (e.g., encoded in XML) of
a permission. A permission document contains several pieces of data: a permission. A permission document contains several pieces of data:
Identity of the Sender: A URI representing the identity of the Identity of the Sender: A URI representing the identity of the
sender for whom permissions are granted. sender for whom permissions are granted.
skipping to change at page 16, line 7 skipping to change at page 16, line 46
translation operation. This is also called the target URI. translation operation. This is also called the target URI.
Identity of the Final Recipient: A URI representing the result of Identity of the Final Recipient: A URI representing the result of
the translation. The permission grants ability for the sender to the translation. The permission grants ability for the sender to
send requests to the target URI, and for a relay receiving those send requests to the target URI, and for a relay receiving those
requests to forward them to this URI. This is also called the requests to forward them to this URI. This is also called the
recipient URI. recipient URI.
URIs to Grant Permission: URIs that recipients can use to grant the URIs to Grant Permission: URIs that recipients can use to grant the
relay permission to perform the translation described in the relay permission to perform the translation described in the
document. At least one of these URIs MUST be a SIP or SIPS URI. document. Relays MUST support the use of SIP and SIPS URIs in
HTTP and HTTPS URIs MAY also be used. permission documents and MAY support the use of HTTP and HTTPS
URIs.
URIs to Deny Permission: URIs that recipients can use to deny the URIs to Deny Permission: URIs that recipients can use to deny the
relay permission to perform the translation described in the relay permission to perform the translation described in the
document. At least one of these URIs MUST be a SIP or SIPS URI. document. Relays MUST support the use of SIP and SIPS URIs in
HTTP and HTTPS URIs MAY also be used. permission documents and MAY support the use of HTTP and HTTPS
URIs.
Permission documents can contain wildcards. For example, a Permission documents can contain wildcards. For example, a
permission document can request permission for any relay to forward permission document can request permission for any relay to forward
requests coming from a particular sender to a particular recipient. requests coming from a particular sender to a particular recipient.
Such a permission document would apply to any target URI. That is, Such a permission document would apply to any target URI. That is,
the field containing the identity of the original recipient would the field containing the identity of the original recipient would
match any URI. However, the recipient URI MUST NOT be wildcarded. match any URI. However, the recipient URI MUST NOT be wildcarded.
Entities implementing this framework MUST support the format for Entities implementing this framework MUST support the format for
permission documents defined in [I-D.ietf-sipping-consent-format] and permission documents defined in [I-D.ietf-sipping-consent-format] and
skipping to change at page 17, line 14 skipping to change at page 18, line 7
5.5. Permission Requested Notification 5.5. Permission Requested Notification
On receiving the MESSAGE request (3), User B's store-and-forward On receiving the MESSAGE request (3), User B's store-and-forward
server stores it because User B is off line at that point. When User server stores it because User B is off line at that point. When User
B goes on line, User B fetches all the requests its store-and-forward B goes on line, User B fetches all the requests its store-and-forward
server has stored (9). server has stored (9).
5.6. Permission Grant 5.6. Permission Grant
A client gives a relay permission to execute the translation A recipient gives a relay permission to execute the translation
described in a permission document by sending a SIP PUBLISH or an described in a permission document by sending a SIP PUBLISH or an
HTTP GET request to one of the URIs to grant permissions contained in HTTP GET request to one of the URIs to grant permissions contained in
the document. Similarly, a client denies a relay permission to the document. Similarly, a recipient denies a relay permission to
execute the translation described in a permission document by sending execute the translation described in a permission document by sending
a SIP PUBLISH or an HTTP GET request to one of the URIs to deny a SIP PUBLISH or an HTTP GET request to one of the URIs to deny
permissions contained in the document. Requests to grant or deny permissions contained in the document. Requests to grant or deny
permissions contain an empty body. permissions contain an empty body.
In our example, User B obtains the permission document (10) that was In our example, User B obtains the permission document (10) that was
received earlier by its store-and-forward server in the MESSAGE received earlier by its store-and-forward server in the MESSAGE
request (3). User B authorizes the translation described in the request (3). User B authorizes the translation described in the
permission document received by sending a PUBLISH request (11) to the permission document received by sending a PUBLISH request (11) to the
SIP URI to grant permissions contained in the permission document. SIP URI to grant permissions contained in the permission document.
skipping to change at page 17, line 39 skipping to change at page 18, line 32
5.6.1. Relay's Behavior 5.6.1. Relay's Behavior
Relays MUST ensure that the SIP PUBLISH or the HTTP GET request Relays MUST ensure that the SIP PUBLISH or the HTTP GET request
received was generated by the recipient of the translation and not by received was generated by the recipient of the translation and not by
an attacker. Relays can use four methods to authenticate those an attacker. Relays can use four methods to authenticate those
requests. SIP identity, P-Asserted-Identity [RFC3325], a return requests. SIP identity, P-Asserted-Identity [RFC3325], a return
routability test, or SIP digest. While return routability tests can routability test, or SIP digest. While return routability tests can
be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP
identity, P-Asserted-Identity, and SIP digest can only be used to identity, P-Asserted-Identity, and SIP digest can only be used to
authenticate SIP PUBLISH requests. SIP digest can only be used to authenticate SIP PUBLISH requests. SIP digest can only be used to
authenticate clients that share a secret with the relay (e.g., authenticate recipients that share a secret with the relay (e.g.,
clients that are in the same domain as the relay). recipients that are in the same domain as the relay).
5.6.1.1. SIP Identity 5.6.1.1. SIP Identity
The SIP identity [RFC4474] mechanism can be used to authenticate the The SIP identity [RFC4474] mechanism can be used to authenticate the
sender of a PUBLISH request. The relay MUST check that the sender of a PUBLISH request. The relay MUST check that the
originator of the PUBLISH request is the owner of the recipient URI originator of the PUBLISH request is the owner of the recipient URI
in the permission document. Otherwise, the PUBLISH request SHOULD be in the permission document. Otherwise, the PUBLISH request SHOULD be
responded with a 401 (Unauthorized) response and MUST NOT be responded with a 401 (Unauthorized) response and MUST NOT be
processed further. processed further.
skipping to change at page 20, line 43 skipping to change at page 21, line 43
translation logic of a relay. However, the relay does not perform translation logic of a relay. However, the relay does not perform
translations towards those recipient URIs until permissions are translations towards those recipient URIs until permissions are
obtained. obtained.
URI-list services using request-contained URI lists are a special URI-list services using request-contained URI lists are a special
case because the selection of recipient URIs is performed at the same case because the selection of recipient URIs is performed at the same
time as the communication attempt. A user places a set of recipient 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 URIs in a request and sends it to a relay so that the relay sends a
similar request to all those recipient URIs. similar request to all those recipient URIs.
Relays implementing this framework and providing this type of URI- Relays implementing this consent framework and providing request-
list services behave in a slightly different way as the relays contained URI-list services behave in a slightly different way than
described so far. This type of relay also maintains a list of the relays described so far. This type of relay also maintains a
recipient URIs for which permissions have been received. Clients list of recipient URIs for which permissions have been received.
also manipulate this list using a manipulation mechanism (e.g., Clients also manipulate this list using a manipulation mechanism
XCAP). Nevertheless, this list does not represent the recipient URIs (e.g., XCAP). Nevertheless, this list does not represent the
of every translation performed by the relay. This list just recipient URIs of every translation performed by the relay. This
represents all the recipient URIs for which permissions have been list just represents all the recipient URIs for which permissions
received. That is, the set of URIs that will be accepted if a have been received. That is, the set of URIs that will be accepted
request containing a URI-list arrives to the relay. This set of URIs if a request containing a URI-list arrives to the relay. This set of
is a super set of the recipient URIs of any particular translation URIs is a super set of the recipient URIs of any particular
the relay performs. translation the relay performs.
5.9.1. Relay's Behavior 5.9.1. Relay's Behavior
On receiving a request-contained URI-list, the relay checks whether On receiving a request-contained URI-list, the relay checks whether
or not it has permissions for all the URIs contained in the incoming or not it has permissions for all the URIs contained in the incoming
URI-list. If it does, the relay performs the translation. If it URI-list. If it does, the relay performs the translation. If it
lacks permissions for one of more URIs, the relay MUST NOT perform lacks permissions for one of more URIs, the relay MUST NOT perform
the translation and SHOULD return an error response. the translation and SHOULD return an error response.
A relay that receives a request-contained URI-list with a URI for A relay that receives a request-contained URI-list with a URI for
which the relay has no permissions SHOULD return a 470 (Consent which the relay has no permissions SHOULD return a 470 (Consent
Needed) response. The relay SHOULD add a Permission-Missing header Needed) response. The relay SHOULD add a Permission-Missing header
field with the URIs for which the relay has no permissions. field with the URIs for which the relay has no permissions.
Figure 6 shows a relay that receives a request (1) that contains URIs
for which the relay does not have permission (the INVITE carries the
recipient URIs in its message body). The relay rejects the request
with a 470 (Consent Needed) response (2). That response contains a
Permission-Missing header field with the URIs for which there was no
permission.
A@example.com Relay
|(1) INVITE |
| sip:B@example.com |
| sip:C@example.com |
|---------------------->|
|(2) 470 Consent Needed |
| Permission-Missing: sip:C@example.com
|<----------------------|
|(3) ACK |
|---------------------->|
Figure 6: INVITE with a URI list in its body
5.9.2. Definition of the 470 Response Code 5.9.2. Definition of the 470 Response Code
A 470 (Consent Needed) response indicates that the request that A 470 (Consent Needed) response indicates that the request that
triggered the response contained a URI-list with at least a URI for triggered the response contained a URI-list with at least a URI for
which the relay had no permissions. The URI or URIs for which the which the relay had no permissions. A user agent server generating a
relay had not permissions are listed in a Permission-Missing header 470 (Consent Needed) response SHOULD include a Permission-Missing
field, should the response carry one. header field in it. This header field carries the URI or URIs for
which the relay had no permissions.
A user agent client receiving a 470 (Consent Needed) response without
a Permission-Missing header field needs to use an alternative
mechanism (e.g., XCAP) to discover for which URI or URIs there were
no permissions.
A client receiving a 470 (Consent Needed) response uses a A client receiving a 470 (Consent Needed) response uses a
manipulation mechanism (e.g., XCAP) to add those URIs to the relay's manipulation mechanism (e.g., XCAP) to add those URIs to the relay's
list of URIs. The relay will obtain permissions for those URIs as list of URIs. The relay will obtain permissions for those URIs as
usual. usual.
5.9.3. Definition of the Permission-Missing Header Field 5.9.3. Definition of the Permission-Missing Header Field
Permission-Missing header fields carry URIs for which a relay did not Permission-Missing header fields carry URIs for which a relay did not
have permissions. The following is the augmented Backus-Naur Form have permissions. The following is the augmented Backus-Naur Form
skipping to change at page 21, line 49 skipping to change at page 23, line 29
Permission-Missing = "Permission-Missing" HCOLON per-miss-spec Permission-Missing = "Permission-Missing" HCOLON per-miss-spec
*( COMMA per-miss-spec ) *( COMMA per-miss-spec )
per-miss-spec = ( name-addr / addr-spec ) per-miss-spec = ( name-addr / addr-spec )
*( SEMI generic-param ) *( SEMI generic-param )
The following is an example of a Permission-Missing header field: The following is an example of a Permission-Missing header field:
Permission-Missing: sip:C@example.com Permission-Missing: sip:C@example.com
Figure 6 shows a relay that receives a request (1) that contains URIs
for which the relay does not have permission. The relay rejects the
request with a 470 (Consent Needed) response (2). That response
contains a Permission-Missing header field with the URIs for which
there was no permission.
A@example.com Relay
|(1) INVITE |
| sip:B@example.com |
| sip:C@example.com |
|---------------------->|
|(2) 470 Consent Needed |
| Permission-Missing: sip:C@example.com
|<----------------------|
|(3) ACK |
|---------------------->|
Figure 6: INVITE with a URI list in its body
5.10. Registrations 5.10. Registrations
Even though the example used to specify this framework has been a Even though the example used to specify this framework has been a
URI-list service, this framework applies to any type of translation URI-list service, this framework applies to any type of translation
(i.e., not only to URI-list services). Registrations are a different (i.e., not only to URI-list services). Registrations are a different
type of translations that deserve discussion. type of translations that deserve discussion.
Registrations are a special type of translations. The user Registrations are a special type of translations. The user
registering has a trust relationship with the registrar in its home registering has a trust relationship with the registrar in its home
domain. This is not the case when a user gives any type of domain. This is not the case when a user gives any type of
skipping to change at page 23, line 18 skipping to change at page 24, line 24
Since the relay does not have permission from Since the relay does not have permission from
'sip:a@ws123.example.com' to perform translations towards that 'sip:a@ws123.example.com' to perform translations towards that
recipient URI, the relay places 'sip:a@ws123.example.com' in the recipient URI, the relay places 'sip:a@ws123.example.com' in the
'pending' state. Once 'sip:a@ws123.example.com' is in the 'pending' state. Once 'sip:a@ws123.example.com' is in the
'Permission Pending' state, the registrar needs to ask 'Permission Pending' state, the registrar needs to ask
'sip:a@ws123.example.com' for permission by sending a MESSAGE request 'sip:a@ws123.example.com' for permission by sending a MESSAGE request
(3). (3).
After receiving the response from the relay (2), user A subscribes to After receiving the response from the relay (2), user A subscribes to
the Pending Additions event package at the registrar (4). This the Pending Additions event package at the registrar (5). This
subscription keeps the user informed about the status of the subscription keeps the user informed about the status of the
permissions (e.g., granted or denied) the registrar will obtain. The permissions (e.g., granted or denied) the registrar will obtain. The
rest of the process is similar to the one described in Section 5. rest of the process is similar to the one described in Section 5.
A@example.com Registrar a@ws123.example.com A@example.com Registrar a@ws123.example.com
|(1) REGISTER | | |(1) REGISTER | |
| Contact: sip:a@ws123.example.com | | Contact: sip:a@ws123.example.com |
|------------------>| | |------------------>| |
|(2) 202 Accepted OK| | |(2) 202 Accepted OK| |
skipping to change at page 26, line 39 skipping to change at page 28, line 24
Trigger-Consent target-uri No [RFCxxxx] Trigger-Consent target-uri No [RFCxxxx]
Note to the RFC editor: substitute xxxx with the RFC number of this Note to the RFC editor: substitute xxxx with the RFC number of this
document. document.
7. Security Considerations 7. Security Considerations
Security has been discussed throughout the whole document. However, Security has been discussed throughout the whole document. However,
there are some issues that deserve special attention. there are some issues that deserve special attention.
The specifications of mechanisms to manipulate translation logic at Relays generally implement several security mechanisms that relate to
relays usually stress the importance of client authentication and client authentication and authorization. Clients are typically
authorization. Having relays authenticate and authorize clients authenticated before they can manipulate a relay's translation logic.
manipulating their translation logic keeps unauthorized clients from Additionally, clients are typically also authenticated and sometimes
adding recipients to a translation. However, this does not prevent need to perform SPAM prevention tasks [RFC5039] when they send
authorized clients to add recipients to a translation without their traffic to a relay. It is important that relays implement these
consent. Additionally, some relays provide web interfaces for any types of security mechanisms. However, they fall out of the scope of
client to add new recipients to the translation (e.g., many email this framework. Even with these mechanisms in place, there is still
mailing lists are operated in this way). In this situation, every a need for relays to implement this framework because the use of
client is considered authorized to manipulate the translation logic these mechanisms do not prevent authorized clients to add recipients
at the relay. This makes the use of this framework even more to a translation without their consent. Consequently, relays
important. Therefore, relays performing translations MUST implement performing translations MUST implement this framework.
this framework.
Note that, as indicated previously, user agents using the same
connection to register and to receive traffic from the registrar,
as described in [I-D.ietf-sip-outbound] do not need to use this
framework. Therefore, a registrars that did not accept third-
party registrations would not need to implement this framework.
As pointed out in Section 5.6.1.3, when return routability tests are As pointed out in Section 5.6.1.3, when return routability tests are
used to authenticate recipients granting or denying permissions, the used to authenticate recipients granting or denying permissions, the
URIs used to grant or deny permissions need to be protected from URIs used to grant or deny permissions need to be protected from
attackers. SIPS URIs provide a good tool to meet this requirement, attackers. SIPS URIs provide a good tool to meet this requirement,
as described in [I-D.ietf-sipping-consent-format]. When store-and- as described in [I-D.ietf-sipping-consent-format]. When store-and-
forward servers are used, the interface between a user agent and its forward servers are used, the interface between a user agent and its
store-and-forward server is frequently not based on SIP. In such store-and-forward server is frequently not based on SIP. In such
case, SIPS cannot be used to secure those URIs. Implementations of case, SIPS cannot be used to secure those URIs. Implementations of
store-and-forward servers MUST provide a mechanism for delivering store-and-forward servers MUST provide a mechanism for delivering
skipping to change at page 29, line 20 skipping to change at page 31, line 6
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007. for Representing Resource Lists", RFC 4826, May 2007.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-08 (work in progress), March 2007. draft-ietf-sip-outbound-08 (work in progress), March 2007.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
skipping to change at page 30, line 4 skipping to change at page 31, line 33
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Gonzalo Camarillo (editor) Gonzalo Camarillo (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Dean Willis Dean Willis
Unaffiliated Unaffiliated
3100 Independence Pkwy #311-164 3100 Independence Pkwy #311-164
Plano, TX 75075 Plano, TX 75075
USA USA
Email: dean.willis@softarmor.com Email: dean.willis@softarmor.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 42 change blocks. 
150 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/