draft-ietf-sipcore-refer-explicit-subscription-00.txt   draft-ietf-sipcore-refer-explicit-subscription-01.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track November 21, 2014 Intended status: Standards Track March 3, 2015
Expires: May 25, 2015 Expires: September 4, 2015
Explicit Subscriptions for the REFER Method Explicit Subscriptions for the REFER Method
draft-ietf-sipcore-refer-explicit-subscription-00 draft-ietf-sipcore-refer-explicit-subscription-01
Abstract Abstract
The Session Initiation Protocol (SIP) REFER request, as defined by The Session Initiation Protocol (SIP) REFER request, as defined by
RFC3515, triggers an implicit SIP-Specific Event Notification RFC3515, triggers an implicit SIP-Specific Event Notification
framework subscription. Conflating the start of the subscription framework subscription. Conflating the start of the subscription
with handling the REFER request makes negotiating SUBSCRIBE with handling the REFER request makes negotiating SUBSCRIBE
extensions impossible, and complicates avoiding SIP dialog sharing. extensions impossible, and complicates avoiding SIP dialog sharing.
This document defines extensions to REFER to remove the implicit This document defines extensions to REFER to remove the implicit
subscription and, if desired, replace it with an explicit one. subscription and, if desired, replace it with an explicit one.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 25, 2015. This Internet-Draft will expire on September 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 35
5.2. Processing a REFER Response . . . . . . . . . . . . . . . 9 5.2. Processing a REFER Response . . . . . . . . . . . . . . . 9
5.3. Processing a Received REFER . . . . . . . . . . . . . . . 9 5.3. Processing a Received REFER . . . . . . . . . . . . . . . 9
6. The 'explicitsub' and 'nosub' Option Tags . . . . . . . . . . 9 6. The 'explicitsub' and 'nosub' Option Tags . . . . . . . . . . 9
7. Updates to RFC 3515 . . . . . . . . . . . . . . . . . . . . . 10 7. Updates to RFC 3515 . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11 9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11
9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11 9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11
9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 12 9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 12
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12 10.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 12 10.2. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12
10.3. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13 10.3. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 13
10.4. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Conventions and Definitions 1. Conventions and Definitions
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 11, line 5 skipping to change at page 11, line 5
This document allows an element to accept an initial SUBSCRIBE This document allows an element to accept an initial SUBSCRIBE
request based on having a Request-URI that identifies existing refer request based on having a Request-URI that identifies existing refer
event state. (Such a URI will have previously been sent in the event state. (Such a URI will have previously been sent in the
Refer-Events-At header field in a successful REFER response). The Refer-Events-At header field in a successful REFER response). The
element retrieving that URI from the response, and any elements that element retrieving that URI from the response, and any elements that
element shares the URI with are authorized to SUBSCRIBE to the event element shares the URI with are authorized to SUBSCRIBE to the event
state. Consequently, the URI should be constructed so that it is not state. Consequently, the URI should be constructed so that it is not
easy to guess, and should be protected against eavesdroppers when easy to guess, and should be protected against eavesdroppers when
transmitted. For instance, SIP messages containing this URI SHOULD transmitted. For instance, SIP messages containing this URI SHOULD
be sent using TLS or DTLS. An event server receiving a REFER request be sent using TLS or DTLS (see the security considerations section of
over an unprotected transport can redirect the requester to use a [RFC3261] for considerations when using other security mechanisms).
protected transport before accepting the request. A good way to An event server receiving a REFER request over an unprotected
ensure that subscriptions use a protected transport is to only transport can redirect the requester to use a protected transport
construct sips: URIs. The event server can also require any of the before accepting the request. A good way to ensure that
additional authorization mechanisms allowed for any SIP request. For subscriptions use a protected transport is to only construct sips:
example, the event server could require a valid assertion of the URIs. The event server can also require any of the additional
subscriber's identity using [RFC4474]. authorization mechanisms allowed for any SIP request. For example,
the event server could require a valid assertion of the subscriber's
identity using [RFC4474].
The URI provided in a 'Refer-Events-At' header field will be used as The URI provided in a 'Refer-Events-At' header field will be used as
the Request-URI of SUBSCRIBE requests. A malicious agent could take the Request-URI of SUBSCRIBE requests. A malicious agent could take
advantage of being able to choose this URI in ways similar to the advantage of being able to choose this URI in ways similar to the
ways an agent sending a REFER request can take advantage of the ways an agent sending a REFER request can take advantage of the
Refer-To URI, as described in the security considerations section of Refer-To URI, as described in the security considerations section of
RFC 3515. In particular, the malicious agent could cause a SIP RFC 3515. In particular, the malicious agent could cause a SIP
SUBSCRIBE to be sent as raw traffic towards a victim. If the victim SUBSCRIBE to be sent as raw traffic towards a victim. If the victim
is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at
most) a factor of 11 amplification due to retransmissions of the most) a factor of 11 amplification due to retransmissions of the
skipping to change at page 12, line 27 skipping to change at page 12, line 30
compact: (none: the entry in this column should be blank) compact: (none: the entry in this column should be blank)
Reference: (this document) Reference: (this document)
10. Changelog 10. Changelog
RFC Editor - please remove this section when formatting this document RFC Editor - please remove this section when formatting this document
as an RFC. as an RFC.
10.1. -sparks- 02 to -ietf- 00 10.1. -00 to -01
1. Added pointer to rfc3261 for considerations when using security
mechanisms other than TLS or DTLS.
10.2. -sparks- 02 to -ietf- 00
1. Incorporated the change to section 6 discussed on list 1. Incorporated the change to section 6 discussed on list
2. Changed "only meaningful in 200" to "only meaningful in 2xx- 2. Changed "only meaningful in 200" to "only meaningful in 2xx-
class" class"
3. Explicitly stated that the RFC6665 rules on populating Contact 3. Explicitly stated that the RFC6665 rules on populating Contact
when becoming a notifier do not apply to the message accepting a when becoming a notifier do not apply to the message accepting a
REFER request requiring either of these extensions REFER request requiring either of these extensions
4. Pointed out that _temporary_ GRUUs are what have the good 4. Pointed out that _temporary_ GRUUs are what have the good
security property discussed in the security considerations security property discussed in the security considerations
section section
10.2. -sparks- 01 to 02 10.3. -sparks- 01 to 02
1. Added the 'nosub' option tag 1. Added the 'nosub' option tag
2. Added text calling out the limitations on explicitsub when the 2. Added text calling out the limitations on explicitsub when the
REFER might be accepted in more than one place. REFER might be accepted in more than one place.
10.3. -sparks- 00 to 01 10.4. -sparks- 00 to 01
1. Replaced strawman proposal with a formal definition of the 1. Replaced strawman proposal with a formal definition of the
mechanism. Added an overview, and detailed security mechanism. Added an overview, and detailed security
considerations. considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 9 change blocks. 
19 lines changed or deleted 27 lines changed or added

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