draft-ietf-sipping-consent-format-00.txt   draft-ietf-sipping-consent-format-01.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: March 21, 2007 September 17, 2006 Expires: May 29, 2007 November 25, 2006
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-00.txt draft-ietf-sipping-consent-format-01.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 32 skipping to change at page 1, line 32
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 March 21, 2007. This Internet-Draft will expire on May 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines an Extensible Markup Language (XML) format for This document defines an Extensible Markup Language (XML) format for
requesting consent. A permission document written in this format a permission document used to request consent. A permission document
asks a recipient for permission to perform a particular translation, written in this format is used by a relay to request the permission,
which is described in the document. of a specific recipient, to perform a particular routing translation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
3. Permission Document Structure . . . . . . . . . . . . . . . . 3 3. Permission Document Structure . . . . . . . . . . . . . . . . 3
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Identity Condition . . . . . . . . . . . . . . . . . . 4 3.1.1. Identity Condition . . . . . . . . . . . . . . . . . . 4
3.1.2. Sender Condition . . . . . . . . . . . . . . . . . . . 5 3.1.2. Sender Condition . . . . . . . . . . . . . . . . . . . 5
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7 3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 7 skipping to change at page 3, line 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The framework for consent-based communications in SIP [9] identifies The framework for consent-based communications in the Session
the need for a format to create permission documents. Such Initiation Protocol (SIP) [9] identifies the need for a format to
permission documents are used by SIP [3] relays to request permission create permission documents. Such permission documents are used by
to perform translations. A relay is defined as any SIP server, be it SIP [3] relays to request permission to perform translations. A
a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, which relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-
receives a request and translates the request URI into one or more Back User Agent), or some hybrid, which receives a request and
next hop URIs to which it then delivers a request. translates the request URI into one or more next hop URIs to which it
then delivers a request.
The format for permission documents specified in this document is The format for permission documents specified in this document is
based on the XML document format for expressing Privacy Preferences based on the XML document format for expressing Privacy Preferences
[8]. [8].
2. Definitions and Terminology 2. Definitions and Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
skipping to change at page 3, line 49 skipping to change at page 3, line 50
Translation operation: Operation by which an entity (e.g., a proxy) Translation operation: Operation by which an entity (e.g., a proxy)
translates the request URI of an incoming request (i.e., the translates the request URI of an incoming request (i.e., the
target URI) into one or more URIs (i.e., recipient URIs) which are target URI) into one or more URIs (i.e., recipient URIs) which are
used as the request URIs of one or more outgoing requests. used as the request URIs of one or more outgoing requests.
3. Permission Document Structure 3. Permission Document Structure
A permission document is an XML document, formatted according to the A permission document is an XML document, formatted according to the
schema defined in [8]. Permission documents inherit the MIME type of schema defined in [8]. Permission documents inherit the MIME type of
common policy documents, 'application/auth-policy+xml'. As described common policy documents, 'application/auth-policy+xml'. As described
in [8], this document is composed of three parts: conditions, in [8], this type of document is composed of three parts: conditions,
actions, and transformations. actions, and transformations. However, even though permission
documents need to have a transformation part to comply to the common
policy syntax, effectively, permission documents do not make any use
of transformations.
This section defines the new conditions and actions defined by this This section defines the new conditions and actions defined by this
specification. This specification does not define any new specification. This specification does not define any new
transformation. transformation.
3.1. Conditions 3.1. Conditions
Note that, as discussed in [8], a permission document applies to a Note that, as discussed in [8], a permission document applies to a
translation if all the expressions in its conditions part evaluate to translation if all the expressions in its conditions part evaluate to
TRUE. TRUE.
skipping to change at page 4, line 34 skipping to change at page 4, line 38
PUBLISH request as described in [9]), the relay matches the identity PUBLISH request as described in [9]), the relay matches the identity
condition of the permission document that was used to request condition of the permission document that was used to request
permission against the identity of the entity granting or denying permission against the identity of the entity granting or denying
permissions (i.e., the sender of the PUBLISH request). permissions (i.e., the sender of the PUBLISH request).
The <identity> element is defined in [8], which indicates that the The <identity> element is defined in [8], which indicates that the
specific usages of the framework document need to define details that specific usages of the framework document need to define details that
are protocol and usage specific. In particular, this section defines are protocol and usage specific. In particular, this section defines
acceptable means of authentication. acceptable means of authentication.
The elements <one> and <except> MUST contain a scheme when they The 'id' attribute in the elements <one> and <except> MUST contain a
appear in a permission document. scheme when these elements appear in a permission document.
When used with SIP, a recipient granting or denying a relay When used with SIP, a recipient granting or denying a relay
permissions is considered authenticated if one of the following permissions is considered authenticated if one of the following
techniques is used: techniques is used:
SIP Identity [7], as described in [9]. For PUBLISH requests that are SIP Identity [7], as described in [9]. For PUBLISH requests that are
authenticated using the SIP Identity mechanism, the identity of authenticated using the SIP Identity mechanism, the identity of
the sender of the PUBLISH request is equal to the SIP URI in the the sender of the PUBLISH request is equal to the SIP URI in the
From header field of the request, assuming that the signature in From header field of the request, assuming that the signature in
the Identity header field has been validated. the Identity header field has been validated.
skipping to change at page 5, line 50 skipping to change at page 6, line 8
header field of the request, the request is considered to be header field of the request, the request is considered to be
authenticated. Note that this is true even if the request authenticated. Note that this is true even if the request
contained a From header field of the form contained a From header field of the form
sip:anonymous@example.com. As long as the signature verifies that sip:anonymous@example.com. As long as the signature verifies that
the request legitimately came from this identity, it is considered the request legitimately came from this identity, it is considered
authenticated. authenticated.
3.1.2.2. Computing a URI for the Sender 3.1.2.2. Computing a URI for the Sender
For requests that are authenticated using SIP Digest, the identity of For requests that are authenticated using SIP Digest, the identity of
the sender is set equal to the user and domain part of the SIP the sender is set equal to the SIP Address of Record (AOR) for the
Address of Record (AOR) for the user that has authenticated user that has authenticated themselves. For example, consider the
themselves. For example, consider the following "user record" in a following "user record" in a database:
database:
SIP AOR: sip:alice@example.com SIP AOR: sip:alice@example.com
digest username: ali digest username: ali
digest password: f779ajvvh8a6s6 digest password: f779ajvvh8a6s6
digest realm: example.com digest realm: example.com
If the relay receives a request, challenges it with the realm set to If the relay receives a request, challenges it with the realm set to
"example.com", and the subsequent request contains an Authorization "example.com", and the subsequent request contains an Authorization
header field with a username of "ali" and a digest response generated header field with a username of "ali" and a digest response generated
with the password "f779ajvvh8a6s6", the identity used in matching with the password "f779ajvvh8a6s6", the identity used in matching
operations is "sip:alice@example.com". operations is "sip:alice@example.com".
For requests that are authenticated using RFC 3325 [5], the identity For requests that are authenticated using RFC 3325 [5], the identity
of the sender is equal to the username and domain parts of the SIP of the sender is equal to the SIP URI in the P-Asserted-ID header
URI in the P-Asserted-ID header field. If there are multiple values field. If there are multiple values for the P-Asserted-ID header
for the P-Asserted-ID header field (there can be one sip URI and one field (there can be one sip URI and one tel URI [10]), then each of
tel URI [10]), then each of them is used for the comparisons outlined them is used for the comparisons outlined in [8], and if either of
in [8], and if either of them match a <one> or <except> element, it them match a <one> or <except> element, it is considered a match.
is considered a match.
For requests that are authenticated using the SIP Identity mechanism For requests that are authenticated using the SIP Identity mechanism
[7], identity of the sender is equal to the SIP URI in the From [7], identity of the sender is equal to the SIP URI in the From
header field of the request, assuming that the signature in the header field of the request, assuming that the signature in the
Identity header field has been validated. Identity header field has been validated.
SIP also allows for anonymous requests. If a request is anonymous SIP also allows for anonymous requests. If a request is anonymous
because the digest challenge/response used the "anonymous" username, because the digest challenge/response used the "anonymous" username,
the request is considered unauthenticated and will not match the the request is considered unauthenticated and will not match the
<sender> condition. If a request is anonymous because it contains a <sender> condition. If a request is anonymous because it contains a
skipping to change at page 8, line 15 skipping to change at page 8, line 15
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset <cr: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"
xsi:schemaLocation="urn:ietf:params:xml:ns:consent-rules xsi:schemaLocation="urn:ietf:params:xml:ns:consent-rules
consent-rules.xsd"> consent-rules.xsd">
<cp:rule id="1"> <cp:rule id="1">
<cp:conditions> <cp:conditions>
<cp:identity> <cp:identity>
<cp:id entity="bob@example.org" scheme="sip"/> <cp:one id="sip:bob@example.org"/>
</cp:identity> </cp:identity>
<target> <target>
<cp:id entity="alices-friends@example.com" scheme="sip"/> <cp:one id="sip:alices-friends@example.com""/>
</target> </target>
<sender> <sender>
<cp:any/> <cp:any/>
</sender> </sender>
</cp:conditions> </cp:conditions>
<cp:actions> <cp:actions>
<trans-handling <trans-handling
perm-uri="sip:foo@example.com">grant</trans-handling> perm-uri="sip:foo@example.com">grant</trans-handling>
<trans-handling <trans-handling
perm-uri="sip:bar@example.com">deny</trans-handling> perm-uri="sip:bar@example.com">deny</trans-handling>
skipping to change at page 11, line 11 skipping to change at page 11, line 11
the integrity and confidentially of the information. In order to the integrity and confidentially of the information. In order to
achieve these, an end-to-end SIP encryption mechanism, such as achieve these, an end-to-end SIP encryption mechanism, such as
S/MIME, as described in RFC 3261 [3], SHOULD be used. S/MIME, as described in RFC 3261 [3], SHOULD be used.
If strong end-to-end security means (such as above) is not available, If strong end-to-end security means (such as above) is not available,
it is RECOMMENDED that hop-by-hop security based on TLS and SIPS it is RECOMMENDED that hop-by-hop security based on TLS and SIPS
URIs, as described in [3], is used. URIs, as described in [3], is used.
8. Acknowledgements 8. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Jonathan Rosenberg provided useful ideas on this document. Ben
Campbell and Mary Barnes performed a thorough review of this
document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
 End of changes. 12 change blocks. 
30 lines changed or deleted 34 lines changed or added

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