draft-ietf-sipping-consent-format-04.txt   draft-ietf-sipping-consent-format-05.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track October 2, 2007 Intended status: Standards Track November 13, 2007
Expires: April 4, 2008 Expires: May 16, 2008
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-04.txt draft-ietf-sipping-consent-format-05.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 34 skipping to change at page 1, line 34
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 April 4, 2008. This Internet-Draft will expire on May 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an Extensible Markup Language (XML) format for This document defines an Extensible Markup Language (XML) format for
a permission document used to request consent. A permission document a permission document used to request consent. A permission document
written in this format is used by a relay to request a specific written in this format is used by a relay to request a specific
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8 3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8
3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8 3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8 3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 8 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 8
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11 6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The framework for consent-based communications in the Session The framework for consent-based communications in the Session
Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] identifies Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] identifies
the need for a format to create permission documents. Such the need for a format to create permission documents. Such
permission documents are used by SIP [RFC3261] relays to request permission documents are used by SIP [RFC3261] relays to request
permission to perform translations. A relay is defined as any SIP permission to perform translations. A relay is defined as any SIP
skipping to change at page 3, line 24 skipping to change at page 3, line 24
one or more next hop URIs to which it then delivers a request. 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 Common Policy [RFC4745], an XML document format for based on Common Policy [RFC4745], an XML document format for
expressing privacy preferences. expressing privacy preferences.
2. Definitions and Terminology 2. Definitions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terms defined in This document uses the terms defined in
[I-D.ietf-sip-consent-framework]. For completeness, these terms are [I-D.ietf-sip-consent-framework]. For completeness, these terms are
repeated here. Figure 1 of [I-D.ietf-sip-consent-framework] shows repeated here. Figure 1 of [I-D.ietf-sip-consent-framework] shows
the relationship between target and recipient URIs in a translation the relationship between target and recipient URIs in a translation
operation. operation.
Recipient URI: Recipient URI:
The Request-URI of an outgoing request sent by an entity (e.g., a The Request-URI of an outgoing request sent by an entity (e.g., a
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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 [RFC4474], as described in Section 5.6.1.1 of SIP Identity [RFC4474], as described in Section 5.6.1.1 of
[I-D.ietf-sip-consent-framework]. For PUBLISH requests that are [I-D.ietf-sip-consent-framework]. 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.
P-Asserted-Identity [RFC3325], as described in Section 5.6.1.2 of P-Asserted-Identity [RFC3325] (which can only be used in closed
network environments) as described in Section 5.6.1.2 of
[I-D.ietf-sip-consent-framework]. For PUBLISH requests that are [I-D.ietf-sip-consent-framework]. For PUBLISH requests that are
authenticated using the P-Asserted-Identity mechanism, the authenticated using the P-Asserted-Identity mechanism, the
identity of the sender of the PUBLISH request is equal to the identity of the sender of the PUBLISH request is equal to the
P-Asserted-Identity header field of the request. P-Asserted-Identity header field of the request.
Return Routability Test, as described in Section 5.6.1.3 of Return Routability Test, as described in Section 5.6.1.3 of
[I-D.ietf-sip-consent-framework]. It can be used for SIP PUBLISH [I-D.ietf-sip-consent-framework]. It can be used for SIP PUBLISH
and HTTP GET requests. No authentication is expected to be used and HTTP GET requests. No authentication is expected to be used
with return routability tests and, therefore, no identity matching with return routability tests and, therefore, no identity matching
procedures are defined. procedures are defined.
skipping to change at page 6, line 12 skipping to change at page 6, line 13
user@domain, present in the 'id' attribute of the <one> and <except> user@domain, present in the 'id' attribute of the <one> and <except>
elements, into a URI. elements, into a URI.
3.1.2.1. Acceptable Means of Authentication 3.1.2.1. Acceptable Means of Authentication
When used with SIP, a request sent by a sender is considered When used with SIP, a request sent by a sender is considered
authenticated if one of the following techniques is used: authenticated if one of the following techniques is used:
SIP Digest: the relay authenticates the sender using SIP digest SIP Digest: the relay authenticates the sender using SIP digest
authentication [RFC2617]. However, if the anonymous authentication [RFC2617]. However, if the anonymous
authentication described on page 194 of RFC 3261 [RFC3261] is authentication described on page 194 of [RFC3261] is used, the
used, the sender is not considered authenticated. sender is not considered authenticated.
Asserted Identity: if a request contains a P-Asserted-ID header Asserted Identity: if a request contains a P-Asserted-ID header
field [RFC3325] and the request is coming from a trusted element, field [RFC3325] and the request is coming from a trusted element,
the sender is considered authenticated. the sender is considered authenticated.
Cryptographically Verified Identity: if a request contains an Cryptographically Verified Identity: if a request contains an
Identity header field as defined in [RFC4474], and it validates Identity header field as defined in [RFC4474], and it validates
the From header field of the request, the request is considered to the From header field of the request, the request is considered to
be authenticated. Note that this is true even if the request be 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
skipping to change at page 6, line 46 skipping to change at page 6, line 47
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 [RFC3325], the For requests that are authenticated using [RFC3325], the identity of
identity of the sender is equal to the SIP URI in the P-Asserted-ID the sender is equal to the SIP URI in the P-Asserted-ID header field.
header field. If there are multiple values for the P-Asserted-ID If there are multiple values for the P-Asserted-ID header field
header field (there can be one sip URI and one tel URI [RFC3966]), (there can be one sip URI and one tel URI [RFC3966]), then each of
then each of them is used for the comparisons outlined in [RFC4745], them is used for the comparisons outlined in [RFC4745], and if either
and if either of them match a <one> or <except> element, it is of them match a <one> or <except> element, it is considered a match.
considered a match.
For requests that are authenticated using the SIP Identity mechanism For requests that are authenticated using the SIP Identity mechanism
[RFC4474], identity of the sender is equal to the SIP URI in the From [RFC4474], 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
<identity> condition. If a request is anonymous because it contains <identity> condition. If a request is anonymous because it contains
skipping to change at page 8, line 10 skipping to change at page 8, line 10
When performing a translation, a relay matches the target condition When performing a translation, a relay matches the target condition
against the destination of the incoming request, which is typically against the destination of the incoming request, which is typically
contained in the Request-URI. contained in the Request-URI.
3.1.4. Validity Condition 3.1.4. Validity Condition
The <validity> element is not applicable to this document. Each The <validity> element is not applicable to this document. Each
permission element has an infinite lifetime and can be revoked using permission element has an infinite lifetime and can be revoked using
an independent mechanism, as described in Section 5.8 of an independent mechanism, as described in Section 5.8 of
[I-D.ietf-sip-consent-framework]. [I-D.ietf-sip-consent-framework]. In any case, as discussed in
Section 4.1 of [I-D.ietf-sip-consent-framework], permissions are only
valid as long as the context where they were granted is valid.
3.1.5. Sphere Condition 3.1.5. Sphere Condition
The <sphere> element is not applicable to this document and therefore The <sphere> element is not applicable to this document and therefore
is not used. is not used.
3.2. Actions 3.2. Actions
The actions in a permission document provide URIs to grant or deny The actions in a permission document provide URIs to grant or deny
permission to perform the translation described in the document. permission to perform the translation described in the document.
skipping to change at page 12, line 39 skipping to change at page 12, line 39
URI: urn:ietf:params:xml:schema:consent-rules URI: urn:ietf:params:xml:schema:consent-rules
Registrant Contact: IETF SIPPING working group, Registrant Contact: IETF SIPPING working group,
<sipping@ietf.org>, Gonzalo Camarillo <sipping@ietf.org>, Gonzalo Camarillo
<Gonzalo.Camarillo@ericsson.com> <Gonzalo.Camarillo@ericsson.com>
XML: The XML schema to be registered is contained in Section 5. XML: The XML schema to be registered is contained in Section 5.
7. Security Considerations 7. Security Considerations
Permission documents can reveal sensitive information. Additionally, The framework for consent-based communications in the Session
attackers may attempt to modify them in order to have clients grant Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses
or deny permissions different to the ones they think are granting or security-related issues, such as how to authenticate SIP and HTTP
denying. For this reason, it is RECOMMENDED that relays use strong requests granting permissions and how to transport permission
means for information integrity protection and confidentiality when documents between relays and recipients, that are directly related to
sending permission documents to clients. this specification.
The mechanism used for conveying information to clients SHOULD ensure
the integrity and confidentially of the information. In order to
achieve these, an end-to-end SIP encryption mechanism, such as
S/MIME, as described in RFC 3261 [RFC3261], SHOULD be used.
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
URIs, as described in [RFC3261], is used.
8. Acknowledgements 8. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Hannes Jonathan Rosenberg provided useful ideas on this document. Hannes
Tschofenig helped align this document with common policy. Ben Tschofenig helped align this document with common policy. Ben
Campbell and Mary Barnes performed a thorough review of this Campbell and Mary Barnes performed a thorough review of this
document. document.
9. References 9. References
skipping to change at page 13, line 36 skipping to change at page 13, line 27
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[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.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
skipping to change at page 14, line 17 skipping to change at page 13, line 50
Rosenberg, J., "A Framework for Consent-Based Rosenberg, J., "A Framework for Consent-Based
Communications in the Session Initiation Protocol (SIP)", Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-01 (work in progress), draft-ietf-sip-consent-framework-01 (work in progress),
November 2006. November 2006.
9.2. Informative References 9.2. Informative References
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
Author's Address Author's Address
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
 End of changes. 13 change blocks. 
38 lines changed or deleted 31 lines changed or added

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