idnits 2.17.1 draft-rosenberg-sipping-acr-code-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 232. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... A UAS MAY generate a 433 (Anonymity...' RFC 2119 keyword, line 126: '...ity Disallowed) response MAY retry the...' RFC 2119 keyword, line 127: '...g anonymity. It SHOULD only do so if ...' RFC 2119 keyword, line 130: '...policy. The UAC SHOULD NOT retry the ...' RFC 2119 keyword, line 159: '... it is, a UAS SHOULD reject the requ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 193 has weird spacing: '...ort for the E...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2005) is 6737 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '3') == Outdated reference: A later version (-04) exists of draft-jesske-sipping-tispan-requirements-02 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: May 12, 2006 November 8, 2005 6 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) 7 draft-rosenberg-sipping-acr-code-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 12, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Session Initiation Protocol (SIP) allows for users to make 41 anonymous calls. However, users receiving such calls have the right 42 to reject them because they are anonymous. SIP has no way to 43 indicate to the caller that the reason for call rejection was that 44 the call was anonymous. Such an indication is useful to allow the 45 call to be retried without anonymity. This specification defines a 46 new SIP response code for this purpose. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. 433 (Anonymity Disallowed) Definition . . . . . . . . . . . . 4 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 8.1 Normative References . . . . . . . . . . . . . . . . . . . 5 59 8.2 Informative References . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . 7 63 1. Introduction 65 The Session Initiation Protocol (SIP) [1] allows for users to make 66 anonymous calls. In RFC 3261, this is done by including a From 67 header field whose display name has the value of "Anonymous". 68 Greater levels of anonymity were subsequently defined in RFC 3323 69 [2], which introduces the Privacy header field. The Privacy header 70 field allows a requesting UA to ask for various levels of anonymity, 71 including user level anonymity, header level anonymity, and session 72 level anonymity. RFC 3325 [3] additionally defined the P-Asserted-ID 73 header field, used to contain an asserted identity. RFC 3325 also 74 defined the 'id' value for the Privacy header field, which is used to 75 request the network to remove the P-Asserted-ID header field. 77 Though users need to be able to make anonymous calls, users that 78 receive such calls retain the right to reject the call because it is 79 anonymous. SIP does not provide a response code that allows the UAS 80 to explicitly to indicate that the request was rejected because it 81 was anonymous. The closest response code is 403 (Forbidden), which 82 doesn't convey a specific reason. While it is possible to include a 83 reason phrase in a 403 response that indicates to the human user that 84 the call was rejected because it was anonymous, that reason phrase is 85 not useful for automata. An indication that can be understood by an 86 automata would allow for programmatic handling, including user 87 interface prompts, automatic retries, or conversion to equivalent 88 error codes in the Public Switched Telephone Network (PSTN) when the 89 client is a gateway. 91 To remedy this, this specification defines the 433 (Anonymity 92 Disallowed) response code. 94 2. UAS Behavior 96 A UAS MAY generate a 433 (Anonymity Disallowed) response when it 97 receives an anonymous request, and the UAS refuses to fulfill the 98 request because the requestor is anonymous. A request is considered 99 anonymous when the identity of the originator of the request has been 100 explicitly witheld by the originator. This occurs in several cases: 102 o The From header field contains a display name of anonymous or a 103 URI within the anonymous.invalid domain. 105 o The request contained a Privacy header field whose value was 'id' 106 [3] or 'user'. This explicitly excludes the 'header' and 107 'session' privacy services, since those do not directly convey the 108 identity of the requestor. 110 o The From or P-Asserted-ID header field contains a URI which has 111 an explicit indication that it is anonymous. One such example of 112 a mechanism that would meet this criteria is [4]. 114 It is important to note that lack of a P-Asserted-ID header field, in 115 and of itself, is not an indication of anonymity. Even though a 116 Privacy header field value of 'id' will cause the removal of the 117 P-Asserted-ID header field, there is no way to differentiate this 118 case from one in which P-Asserted-ID was not supported by the 119 originating domain. As a consequence, a request without a 120 P-Asserted-ID is considered anonymous only when there is some other 121 indication of this, such as a From header field with a display name 122 of 'Anonymous'. 124 3. UAC Behavior 126 A UAC receiving a 433 (Anonymity Disallowed) response MAY retry the 127 request without requesting anonymity. It SHOULD only do so if it 128 obtains confirmation that the user that this is desirable. Such 129 confirmation could be obtained through the user interface, or by 130 accessing user defined policy. The UAC SHOULD NOT retry the request 131 if it continues to request anonymity. 133 A UAC the does not understand or care about the specific semantics of 134 the 433 response will treat it as a 400 response. 136 4. 433 (Anonymity Disallowed) Definition 138 This response indicates that the UAS refused the fulfill the request 139 because the requestor was anonymous. Its default reason phrase is 140 "Anonymity Disallowed". 142 5. IANA Considerations 144 This section registers a new SIP response code according to the 145 procedures of RFC 3261. 147 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC 148 number of this specification]] 150 Response Code Number: 433 152 Default Reason Phrase: Anonymity Disallowed 154 6. Security Considerations 156 The fact that an request was rejected because it was anonymous does 157 reveal information about the called party - that they do not accept 158 anonymous calls. This information may or may not be sensitive. If 159 it is, a UAS SHOULD reject the request with a 403 instead. 161 7. Acknowledgements 163 This draft was motivated based on the requirements in [6], and has 164 benefitted from the concepts in [5]. 166 8. References 168 8.1 Normative References 170 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 171 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 172 Session Initiation Protocol", RFC 3261, June 2002. 174 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 175 Protocol (SIP)", RFC 3323, November 2002. 177 [3] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 178 to the Session Initiation Protocol (SIP) for Asserted Identity 179 within Trusted Networks", RFC 3325, November 2002. 181 8.2 Informative References 183 [4] Rosenberg, J., "Identity Privacy in the Session Initiation 184 Protocol (SIP)", draft-rosenberg-sip-identity-privacy-00 (work 185 in progress), July 2005. 187 [5] Hautakorpi, J. and G. Camarillo, "Extending the Session 188 Initiation Protocol Reason Header with Warning Codes", 189 draft-hautakorpi-reason-header-for-warnings-00 (work in 190 progress), October 2005. 192 [6] Jesske, R., "Input Requirements for the Session Initiation 193 Protocol (SIP) in support for the European Telecommunications 194 Standards Institute", 195 draft-jesske-sipping-tispan-requirements-02 (work in progress), 196 October 2005. 198 Author's Address 200 Jonathan Rosenberg 201 Cisco Systems 202 600 Lanidex Plaza 203 Parsippany, NJ 07054 204 US 206 Phone: +1 973 952-5000 207 Email: jdrosen@cisco.com 208 URI: http://www.jdrosen.net 210 Intellectual Property Statement 212 The IETF takes no position regarding the validity or scope of any 213 Intellectual Property Rights or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; nor does it represent that it has 217 made any independent effort to identify any such rights. Information 218 on the procedures with respect to rights in RFC documents can be 219 found in BCP 78 and BCP 79. 221 Copies of IPR disclosures made to the IETF Secretariat and any 222 assurances of licenses to be made available, or the result of an 223 attempt made to obtain a general license or permission for the use of 224 such proprietary rights by implementers or users of this 225 specification can be obtained from the IETF on-line IPR repository at 226 http://www.ietf.org/ipr. 228 The IETF invites any interested party to bring to its attention any 229 copyrights, patents or patent applications, or other proprietary 230 rights that may cover technology that may be required to implement 231 this standard. Please address the information to the IETF at 232 ietf-ipr@ietf.org. 234 Disclaimer of Validity 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Copyright Statement 246 Copyright (C) The Internet Society (2005). This document is subject 247 to the rights, licenses and restrictions contained in BCP 78, and 248 except as set forth therein, the authors retain all their rights. 250 Acknowledgment 252 Funding for the RFC Editor function is currently provided by the 253 Internet Society.