From nobody Mon Jun 3 14:30:46 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAC312004A; Mon, 3 Jun 2019 14:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: sipcore@ietf.org, draft-ietf-sipcore-rejected.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ines Robles Message-ID: <155959743193.24804.13536348952609913643@ietfa.amsl.com> Date: Mon, 03 Jun 2019 14:30:32 -0700 Archived-At: Subject: [sipcore] Genart last call review of draft-ietf-sipcore-rejected-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 21:30:32 -0000 Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sipcore-rejected-08 Reviewer: Ines Robles Review Date: 2019-06-03 IETF LC End Date: 2019-06-04 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written. The document defines the 608 (Rejected) SIP response code, that enables calling parties to learn that an intermediary rejected their call attempt. I have some minor questions. Major issues: none Minor issues: none Nits/editorial comments: Section 1- I think it would be nice to expand SIP and add a reference to RFC3261 the first time that SIP is mentioned in the Introduction. Comments/Questions: 1- Section 1. "...a user (human)..." A user could be as well a smart device, right?. For example, in a smart home scenario, we have Alexa rejecting a call from a supermarket. The call rejection is ordered by a human or ordered by another device (e.g. a fridge with temporal calling-management functions that can send commands to Alexa to accept, reject calls from supermarket ). In the latter case the user is not a human, but a smart device. In this case, Alexa would be the UAS? 2- In Figure 2 is not clear to me if the INVITE command goes as well to the "call analytics engine" entity, since the arrow goes directly to the UAS. Should this image indicate arrows to the "call analytics engine" entity, to be aligned with figure 1? 3- Figure 5: +-+--+-+ +---+ +-----+ +---+ +-----+ +-----+ |Called| |UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party | +---+ +-----+ +---+ +-----+ +-----+ |Proxy | +------+ 3.1- The arrows of the UAC to the Called Party Proxy are unidirectional. Should be bidirectional? Since there are messages from the Called Party Proxy entity to the SBC, and then to the UAC. 3.2- Should the "Proxy" entities be identified for example with Proxy A, Proxy B and Proxy C, to indicate that they are different Proxy entities? 3.3- Should be added in the figure the flow of messages that the "Proxy" entities goes through, or at least mentioned when explaining figure 5. Thank you for this draft, Ines. From nobody Wed Jun 5 12:00:02 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9E120250; Wed, 5 Jun 2019 12:00:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155976120021.22406.17255305238999687007.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2019 12:00:00 -0700 Archived-At: Subject: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-rejected-08=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 19:00:00 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) A couple of remarks on this sentence in Sec 3.1: “If an intermediary issues a 608 code and there are not indicators the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), the intermediary MUST include a Call-Info header field in the response.” a) -> s/not/no/ b) Maybe also add a “that” as it would make this long easier to read: “If an intermediary issues a 608 code and there are no indicators that the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), … c) After having read Section 6, I find this MUST rather strong. I was expecting more “concrete” instructions. I understand why you want to have a MUST here, but section 6 reads very much like a SHOULD. 2) Editorial: In this sentence in 3.4 I also think a “that” would help: “The degenerate case is the intermediary is the only element that understands the semantics of the 608 response code.“ 3) One more purely editorial comment: Short title is “Status Reject”, however, to be closer to the long title I would rather recommend something like “SIP Response Code for Rejected Calls”. From nobody Thu Jun 6 11:44:45 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AFC1200C3 for ; Thu, 6 Jun 2019 11:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eN0v9Hemou1 for ; Thu, 6 Jun 2019 11:44:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19DB120094 for ; Thu, 6 Jun 2019 11:44:41 -0700 (PDT) Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x56Iie7I046266 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 6 Jun 2019 13:44:40 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559846681; bh=JdcXNV4qq1NvYtWEZp7uDDEy90GDy/x6f4XrTUDk+9E=; h=Subject:To:References:From:Date:In-Reply-To; b=SaxYlZi/UkJjXt/2bBTJedPJiMp5zHdXVN3lvu5BdZJYfOTpM8cfLGZJPS4OmZsWO g4sps3NFrVDljT70X3yOJF1dJ3bxl0pf7GkxU3bMp1YT736E4LT6X8IdQtO40bSN9X ybLKhR9sJeSWz8AVhXiXG+tZvX58/hpxO/+PENFM= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local To: sipcore@ietf.org References: <88cb2638-07fa-7be7-d3c6-242c4f5e2387@nostrum.com> From: "A. Jean Mahoney" Message-ID: <2175e5d4-b1a8-4a2d-70c1-e00169e6b84f@nostrum.com> Date: Thu, 6 Jun 2019 13:44:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <88cb2638-07fa-7be7-d3c6-242c4f5e2387@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] WG session for IETF 105? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 18:44:44 -0000 Hi all, The chairs didn't hear from anyone regarding potential meeting topics, so it doesn't appear that SIPCORE needs a session in Montreal. Thanks! Jean On 5/22/19 2:39 PM, A. Jean Mahoney wrote: > Hi all, > > Does SIPCORE need a session at IETF 105? If you have a topic that you > want to discuss at a WG session in Montreal, please respond by > Wednesday, June 5. > > Thanks! > > Jean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jun 7 12:20:52 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B3120129; Fri, 7 Jun 2019 12:20:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sipcore@ietf.org, adam@nostrum.com, mahoney@nostrum.com, sipcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155993524043.27472.6680415461797745350.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2019 12:20:40 -0700 Archived-At: Subject: [sipcore] sipcore - Not having a session at IETF 105 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 19:20:41 -0000 Jean Mahoney, a chair of the sipcore working group, indicated that the sipcore working group does not plan to hold a session at IETF 105. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Jun 10 16:36:33 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC012010D; Mon, 10 Jun 2019 16:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156020977718.32191.639235669349496797.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2019 16:36:17 -0700 Archived-At: Subject: [sipcore] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sipcore-rejected-08=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 23:36:17 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this document. I have 2 comments below == COMMENTS == -- Section 1 -- The last paragraph of the introduction describes an attack that should probably be better located in the security section. -- Section 4.1 -- In the example, I wonder whether the IPv6 syntax of "Via: SIP/2.0/UDP [2001:db8::177:60012];branch=z9hG4bK-524287-1" is correct. I would have expected "Via: SIP/2.0/UDP [2001:db8::17]:760012;branch=z9hG4bK-524287-1" but I am not a SIP expert. From nobody Tue Jun 11 08:34:04 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 247AB1201D8; Tue, 11 Jun 2019 08:33:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156026723506.30840.16326010263298224705.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2019 08:33:55 -0700 Archived-At: Subject: [sipcore] Adam Roach's Yes on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 15:33:56 -0000 Adam Roach has entered the following ballot position for draft-ietf-sipcore-rejected-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- See also the coments posted by Brian Campbell at https://mailarchive.ietf.org/arch/msg/jwt-reg-review/k7z9wnZ0Ee7a65TiWxueJLFfFgg From nobody Tue Jun 11 09:17:08 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED912012C; Tue, 11 Jun 2019 09:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156026982076.30851.9180244619877071155.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2019 09:17:00 -0700 Archived-At: Subject: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 16:17:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. = Section 3 = I'm wondering about the case where I have an AI-driven assistant on my client that listens for me to say "Please take me off your call list" and blocks all future calls from that caller. It seems like the 608 use case would apply (for the case of false positive voice recognition), but since the definition here limits the intermediary to an entity "in the network," this scenario is out of scope. Should it be? = Section 3.5 = "It is important to note the network element should be mindful of the media type requested by the UAC as it formulates the announcement. For example, it would make sense for an INVITE that only indicated audio codecs in the Session Description Protocol (SDP) [RFC4566] to result in an audio announcement. However, if the INVITE only indicated a real-time text codec and the network element can render the information in the requested media format, the network element MUST send the information in a text format, not an audio format." I think the normative guidance here could be crisper, e.g., replacing the first sentence with "The network element SHOULD use a media format for its announcement for which the caller indicates support, if possible." I also don't understand why the second example uses normative MUST but the first example doesn't use normative language at all. = Section 4.1 = Using "bitbucket" in the examples seems like it sends the wrong message about the utility of the contact address. From nobody Tue Jun 11 09:17:54 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADB8120150; Tue, 11 Jun 2019 09:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HQuLa/jQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qT6ynRBD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeHGnTyrDLRY; Tue, 11 Jun 2019 09:17:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6412C12012A; Tue, 11 Jun 2019 09:17:42 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 95AA3220DB; Tue, 11 Jun 2019 12:17:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 11 Jun 2019 12:17:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=F tXt+phJReRj6EptM0G1EcuxiePz79L3igWX4S+CiG4=; b=HQuLa/jQDGP8htImc kTz6T1cFr1cf018b3D40hr0TjXITlNeZ+cDKurtJbfdMehnSicR40ocmtDU+Mtph A9C0lE3ZkNJGpUjVC988tk6R4lLsmsCEebSQNjNfRet+MPVU1SJpnAq34LiVAhJC R+983cSN3X/pBh+wQ5LUlwiM8LDAi5vO/KklLZbcBh87ohhfirgzm2hGx9LvzDJL A+8Ho7IKU0QXFSppIwCLUmVQZ/b6MMSEYmO14s0e02OT7z+ZsOmgT2TsZ4VKRac+ 91V5RGRgY/6VVeuXhMgjVBnN83gsvBE38ajn7IVuhq0exsk5ZIZEUe215sNj7ENi gfJMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=FtXt+phJReRj6EptM0G1EcuxiePz79L3igWX4S+Ci G4=; b=qT6ynRBDUi0/qbftpplGyS9BNBXf6KjsM80CYRef6RoU0zXZOQFBbmFgK cmZcvhq4um867h8gt6pCsgBxilb0KL05GxQBWjKHfogvBc43t3KjkuWyUti+PP7e +BmSRvJk+9FbSKemUNPPr13ewlO7g31exKK/kC00a+SN20nkhe1hllUYzqnMOf98 eKa68kAcbNi06c8Z0UIxQR3oB5OaV6c5WXNFb4mpIiInDn8CIEgrNEswy7Y7ug7X TWnN3d7rbvRVBEc+rlq4IBrogZWM554ZeFG8Nil/63ohGyQUlyS1U6TEFNu1aFxc 3h6HjffcuNXNTUxPSlmSTdCHvKPOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehhedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 99FAD380089; Tue, 11 Jun 2019 12:17:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155959743193.24804.13536348952609913643@ietfa.amsl.com> Date: Tue, 11 Jun 2019 12:17:39 -0400 Cc: gen-art@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-rejected.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155959743193.24804.13536348952609913643@ietfa.amsl.com> To: Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [sipcore] [Gen-art] Genart last call review of draft-ietf-sipcore-rejected-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 16:17:48 -0000 Ines, thanks for your review, which I pointed to in my No Objection = ballot. Alissa > On Jun 3, 2019, at 5:30 PM, Ines Robles via Datatracker = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sipcore-rejected-08 > Reviewer: Ines Robles > Review Date: 2019-06-03 > IETF LC End Date: 2019-06-04 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > I believe the draft is technically good. This document is well = written. >=20 > The document defines the 608 (Rejected) SIP response code, that = enables > calling parties to learn that an intermediary rejected their call = attempt. >=20 > I have some minor questions. >=20 > Major issues: none >=20 > Minor issues: none >=20 > Nits/editorial comments: >=20 > Section 1- I think it would be nice to expand SIP and add a reference = to > RFC3261 the first time that SIP is mentioned in the Introduction. >=20 > Comments/Questions: >=20 > 1- Section 1. "...a user (human)..." >=20 > A user could be as well a smart device, right?. For example, in a = smart home > scenario, we have Alexa rejecting a call from a supermarket. The call > rejection is ordered by a human or ordered by another device (e.g. a = fridge > with temporal calling-management functions that can send commands to = Alexa to > accept, reject calls from supermarket ). In the latter case the user = is not a > human, but a smart device. In this case, Alexa would be the UAS? >=20 > 2- In Figure 2 is not clear to me if the INVITE command goes as well = to the > "call analytics engine" entity, since the arrow goes directly to the = UAS. >=20 > Should this image indicate arrows to the "call analytics engine" = entity, to > be aligned with figure 1? >=20 > 3- Figure 5: >=20 > = +-+--+-+ > +---+ +-----+ +---+ +-----+ +-----+ = =20 > |Called| |UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party | = +---+ =20 > +-----+ +---+ +-----+ +-----+ = |Proxy | > = +------+ >=20 > 3.1- The arrows of the UAC to the Called Party Proxy are = unidirectional. > Should be bidirectional? Since there are messages from the Called = Party Proxy > entity to the SBC, and then to the UAC. >=20 > 3.2- Should the "Proxy" entities be identified for example with Proxy = A, > Proxy B and Proxy C, to indicate that they are different Proxy = entities? >=20 > 3.3- Should be added in the figure the flow of messages that the = "Proxy" > entities goes through, or at least mentioned when explaining figure = 5. >=20 > Thank you for this draft, >=20 > Ines. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jun 11 17:58:34 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23A2120098; Tue, 11 Jun 2019 17:58:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156030110472.5972.1062340244094112710.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2019 17:58:24 -0700 Archived-At: Subject: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 00:58:25 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we want to give any references/examples for "some jurisdictions" or "many jurisdictions"? Section 1 An algorithm can be vulnerable to an algorithm subject to the base rate fallacy [BaseRate] rejecting the call. [...] nit: It sounds like these are different algorithms, so that "One algorithm can be vulnerable to a separate algorithm, subject to the base rate fallacy, erroneously rejecting the call" would be more clear. Section 3.1 If there is a Call-Info header field, it MUST have the 'purpose' parameter of 'jwscard'. The value of the Call-Info header field MUST refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a jCard [RFC7095] object. Do we need to say anything about what entity('s key) generates the signature and/or what affects signature algorithm selection (e.g., a forward reference to Sections 3.2.x)? Section 3.2.2 The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks. nit(?): Perhaps this protection is only "outside the scope of a narrow window of time corresponding to the allowed RTT and any permitted time skew", per Section 3.3. Call originators (at the UAC) can use the information returned by the jCard to contact the intermediary that rejected the call to appeal the intermediary's blocking of the call attempt. What the intermediary does if the blocked caller contacts the intermediary is outside the scope of this document. It seems like it is permissible for the intermediary to reject this new call as well; can we get into some sort of recursion-like situation? Section 3.5 However, if the INVITE only indicated a real-time text codec and the network element can render the information in the requested media format, the network element MUST send the information in a text format, not an audio format. This usage of 2119 language seems odd to me, like it's calling out a single special case for normative treatment but ignoring the general case. Section 4.1 As such, implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info SIP header. These (especially the MUST NOT) seem to just be restating requirements from elsewhere and would not ordinarily need normative language to do so. Section 6 Another risk is for an attacker to flood a proxy that supports the sip.608 feature with INVITE requests that lack the sip.608 feature capability to direct the SDP to a victim's device. [...] This sentence is pretty long/convoluted and could probably be reworded for clarity. Yet another risk is a malicious intermediary that generates a malicious 608 response with a jCard referring to a malicious agent. For example, the recipient of a 608 may receive a TEL URI in the vCard. When the recipient calls that address, the malicious agent could ask for personally identifying information. However, instead of using that information to verify the recipient's identity, they are phishing the information for nefarious ends. As such, we strongly recommend the recipient validates to whom they are communicating with if asking to adjudicate an erroneously rejected call attempt. Since we may also be concerned about intermediate nodes modifying contact information, we can address both issues with a single solution. The remediation is to require the intermediary to sign the jCard. [...] The signature is not a panacea -- the recipient needs to verify that the signature comes from a trustworthy (in some sense) entity, and that the person they contact based on the jCard is the same entity or affiliated with the entity that generated the signature. I think this is not quite the same thing as the SHAKEN/SHAKEN-like mechanisms for validating that the signing entity matches the called entity that are mentioned in the subsequent text. However, if the intermediary does go that route, the intermediary MUST use a non-deterministic reference mechanism and be prepared to return dummy responses so that attackers attempting to glean call metadata by guessing calls will not get any actionable information from the HTTPS GET. Thanks for mentioning this side channel! I'd suggest to clarify that the dummy responses are in response to URIs that might be (but are not) URIs that would be found in the "url" field of the jCard. (Assuming I'm understanding the attack correctly, of course.) From nobody Tue Jun 11 18:28:58 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8FC12009C; Tue, 11 Jun 2019 18:28:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156030292885.5865.4435712492554038582.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2019 18:28:48 -0700 Archived-At: Subject: [sipcore] Roman Danyliw's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 01:28:49 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Per Section 6 (Security Considerations), the risks of TEL URIs in the jCard given a malicious intermediary is helpful. I’d recommend adding language around comparable risks with the url in the jcard (e.g., that this url could point to malicious content) (2) Per Section 1, Nit. [RFC7340] is referred to a technology. However, specific draft is a requirements document. From nobody Wed Jun 12 10:07:00 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D56120089; Wed, 12 Jun 2019 10:06:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <156035921069.14103.10047256808594559317.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2019 10:06:50 -0700 Archived-At: Subject: [sipcore] Warren Kumari's Yes on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 17:06:51 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sipcore-rejected-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I generally approach SIP documents with a sense of foreboding — they are often long, expect a large amount of knowledge outside my area of expertise, and require lots of reference chasing — but this was a really good read. It describes the problem well, it lays out the protocol clearly, and contains enough humor / snark to make reading it actually enjoyable. Nits: "Another value of the 607 rejection is presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender." I found this sentence really hard to parse -- I think adding a comma after "is" fixes it. "An algorithm can be vulnerable to an algorithm subject to the base rate fallacy [BaseRate] rejecting the call." Unparsable -- duplication? Perhaps just " An algorithm can be vulnerable to the base rate fallacy [BaseRate] rejecting the call."? From nobody Wed Jun 12 11:25:13 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF751201C8 for ; Wed, 12 Jun 2019 11:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRuA3Znt9-RK for ; Wed, 12 Jun 2019 11:25:04 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF464120182 for ; Wed, 12 Jun 2019 11:25:03 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5CIP0GC006824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 12 Jun 2019 14:25:01 -0400 To: sipcore@ietf.org References: <156035921069.14103.10047256808594559317.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <59af2c4b-9f9b-92e1-68bb-384847b077e3@alum.mit.edu> Date: Wed, 12 Jun 2019 14:25:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <156035921069.14103.10047256808594559317.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Warren Kumari's Yes on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 18:25:12 -0000 On 6/12/19 1:06 PM, Warren Kumari via Datatracker wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-sipcore-rejected-08: Yes > Nits: > "Another value of the 607 rejection is presuming the proxy forwards > the response code to the User Agent Client (UAC), the calling UAC or > intervening proxies will also learn the user is not interested in > receiving calls from that sender." > I found this sentence really hard to parse -- I think adding a comma after "is" > fixes it. I still find that hard to follow. Here is another possibility: If the 607 rejection is forwarded all the way to the User Agent Client (UAC) then, like 608, it informs the UAC and any other intervening proxies that the user is not interested in receiving calls from that sender. Thanks, Paul From nobody Wed Jun 12 19:53:54 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C76612008B; Wed, 12 Jun 2019 19:53:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156039442630.27114.12426178875353647803.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2019 19:53:46 -0700 Archived-At: Subject: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 02:53:47 -0000 Barry Leiba has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have only some editorial comments: — Section 1 — Here and in other sections you use “As such,” several times and always in a way that seems quite odd. I suggest removing it (or maybe sometimes replacing it with “therefore” or “thus”). Some call blocking services may return responses such as 604 There needs to be a hyphen in “call-blocking”. However, other network elements might also interpret this to mean the user truly does not exist and might result in the user not being able to receive calls from anyone, even if wanted. The “and” is wrong because the things it conjoins aren’t parallel. Change “exist and” to “exist, which” to fix that. I would also say, “even if the calls are wanted,” to make that clearer. Another value of the 607 rejection is presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender. I found that odd and hard to understand until I realized that there’s a comma missing before “presuming”. But I think a better fix is to change “presuming” to “that if”. downstream from the intermediary might interpret the 607 as coming from a user (human) that has marked the call as unwanted We customarily refer to a human as “who”, rather than “that”. Integrity protecting the jCard with a cryptographic signature Hyphenate “integrity-protecting”. — Section 3 — For clarity, this section uses the term 'intermediary' I don’t understand why the term adds clarity. Whyso? the user's UAS (colloquially, but not necessarily, their phone). I don’t thunk you mean “colloquially” here. Maybe “commonly” or “usually”? — Section 3.4 — life is good as the UAC will receive You need a comma after “good”. — Section 6 — remediation for this is for devices that insert a sip.608 feature capability only transmit media to what is highly likely to be the Either change “is for” to “is that” or insert “to” before “only”. media in response to a STIR [RFC8224]-signed INVITE It seems really weird to have a citation in the middle of the hyphenated compound “STIR-signed”. Given that you cite “STIR [RFC8224]” in the previous paragraph, I would just remove the citation here. Presumably if the target did not request the media, the check will fail. Why “presumably”? Is the statement true or not? (If the word stays, it needs a comma after it.) From nobody Thu Jun 13 03:09:25 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB61200F3; Thu, 13 Jun 2019 03:09:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156042055576.12704.13389098547973162381.idtracker@ietfa.amsl.com> Date: Thu, 13 Jun 2019 03:09:15 -0700 Archived-At: Subject: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 10:09:16 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sipcore-rejected-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well written document. I have one nit I would like to discuss: 4.1. Full Exchange Given an INVITE (shamelessly taken from [SHAKEN]): INVITE sip:+12155550113@tel.one.example.net SIP/2.0 Max-Forwards: 69 Contact: To: From: "Alice" ;tag=614bdb40 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI P-Asserted-Identity: "Alice", CSeq: 2 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp Date: Tue, 16 Aug 2016 19:23:38 GMT Feature-Caps: *;+sip.608 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I This is not syntactically valid. Either you need a space in front of the above line, or maybe it would be better if you change the above 2 lines to read: Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I If the base64 encoded value is one line with no line breaks, you should consider pointing this out. joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC A;info=;alg=ES256 Content-Length: 153 From nobody Thu Jun 13 09:15:15 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DEC12015F; Thu, 13 Jun 2019 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcMbuPY9rSn2; Thu, 13 Jun 2019 09:15:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21ED1201DA; Thu, 13 Jun 2019 09:15:08 -0700 (PDT) Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x5DGF6jP047920 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Jun 2019 11:15:07 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1560442508; bh=W3lUj28Hw9+2TqgFlIUlNTzVeqQQOlm3QBjmlNsgEh0=; h=To:From:Subject:Cc:Date; b=j9/MUhnfWrPlM5XnIb0ETJ0YA+tQGKfZbQBw8TQUvm3U2ZYDxD9cb9hfjMrvUGJY4 kSdAt5nLjwUWtWLj+Z5l37i7XwQjmLoUTI+XfNmmVKksMI3/v8PQ3cwAvuvqjwgy2u tOnLsj0T8CYYJSLFNTrPb4zJ+qYAyUJJojA0YhzI= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local To: SIPCORE From: "A. Jean Mahoney" Cc: draft-ietf-sipcore-digest-scheme@ietf.org Message-ID: <255cce62-0ccb-6de7-a2f2-06fb8ffc1f4f@nostrum.com> Date: Thu, 13 Jun 2019 11:15:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] draft-ietf-sipcore-digest-scheme - Implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 16:15:13 -0000 Hi all, While working on the Doc Shepherd writeup for draft-ietf-sipcore-digest-scheme, I perused the comments on the earlier versions of the draft. More than once, testing of implementations came up - that it needed to happen, that there needed to be guidance to implementers, etc. Has anyone implemented draft-ietf-sipcore-digest-scheme? Has anyone tested interoperability between two implementations of this draft? Between an implementation of this draft and a legacy implementation? Thanks! Jean From nobody Mon Jun 17 14:03:59 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919161200A1; Mon, 17 Jun 2019 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acCghFjY3Dyv; Mon, 17 Jun 2019 14:03:55 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30066.outbound.protection.outlook.com [40.107.3.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BA112004F; Mon, 17 Jun 2019 14:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=udkSZv91ScD6y7AMl/+zRNdXSQmIikZAqpRc+Jx5fiU=; b=PndCEuYqjEIeHI6cygNrFEkpYcGnSz+2q0eVyPq3hfFipKSXN0PXWRPD10rokjqcs4ANU1KAlk4dbW8FdFe1AZqZRW4hqtqkct32FkOqOOGoMSB//txaLd5cTftrEWMhFW7GeTCLfTXSFvOaTU3TKTi5Rnq6LAyP6XfIuru0DAo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4235.eurprd07.prod.outlook.com (20.176.166.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.7; Mon, 17 Jun 2019 21:03:52 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.007; Mon, 17 Jun 2019 21:03:52 +0000 From: Christer Holmberg To: "A. Jean Mahoney" , SIPCORE CC: "draft-ietf-sipcore-digest-scheme@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-digest-scheme - Implementation Thread-Index: AQHVIgM3BiKhGG/L2Eam0iZJw841xaagfdSA Date: Mon, 17 Jun 2019 21:03:52 +0000 Message-ID: <93BC97C0-BB81-4D36-9935-55AA4A9FA418@ericsson.com> References: <255cce62-0ccb-6de7-a2f2-06fb8ffc1f4f@nostrum.com> In-Reply-To: <255cce62-0ccb-6de7-a2f2-06fb8ffc1f4f@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.219.58.167] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d7c0983-fc3a-40e6-3170-08d6f3674d8d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4235; x-ms-traffictypediagnostic: HE1PR07MB4235: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(376002)(39860400002)(366004)(199004)(189003)(18543002)(53754006)(33656002)(478600001)(256004)(66476007)(14454004)(76176011)(186003)(6306002)(6512007)(53936002)(36756003)(2906002)(4326008)(99286004)(5660300002)(25786009)(110136005)(58126008)(316002)(6246003)(6506007)(68736007)(71200400001)(3846002)(6116002)(71190400001)(64756008)(102836004)(6436002)(229853002)(44832011)(486006)(26005)(7736002)(305945005)(446003)(8936002)(2616005)(11346002)(66556008)(73956011)(8676002)(81166006)(966005)(476003)(81156014)(6486002)(66446008)(66946007)(76116006)(66066001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4235; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Tip+VNyp8epElpQuCvj07bHaU/r08zx1+dRdkM4k/H/hher6ML7ZZhFJUxziZbLVCcfkrTERiSHIa3221gohM6YZFuNmtDusGpYm38biPJDJfro1JJPrTrNByui78QImZ4E/0UhBVKJekp7K1bX1hyt4i/v8T6Ptw7x5CGWJEEsRPmqqYtgTwRMVRnUEu0/YV5AfOGDE5fJGZTMDGPIXhyL3rwx0F6mWRT8drqt2jW9dzLymGUgDg5T9igMfkCPKd/l3lW87/giM+sTG5Vy/jf1TWqCPcg2UxZA/tU5X694Tjjq2v4xUH81WtWm7IFQ9mPQVnnH1UFBu8LQ15JgsEQ+eWgAhJr+aR7QEmvgbiVwZRDACH20ERBysTo6i/P9XHqmVOpIGGP5MiSAWIMNiQbtoA9MuqrwTXI5dCMGKBRo= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d7c0983-fc3a-40e6-3170-08d6f3674d8d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 21:03:52.6554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4235 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-digest-scheme - Implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 21:03:57 -0000 SGksDQoNCkkgYW0gYXdhcmUgb2YgaW1wbGVtZW50YXRpb25zIHRoYXQgaW1wbGVtZW50IHRoZSBt b2RpZmljYXRpb25zIGluIHRoZSBkcmFmdC4NCg0KQW5kLCBzaW5jZSB0aGUgbW9kaWZpY2F0aW9u cyBpbiB0aGUgZHJhZnQgYXJlIGRlcGxveWVkIGluIG11bHRpLXZlbmRvciBuZXR3b3JrcyBJIHdv dWxkIGFzc3VtZSB0aGVyZSBpcyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gaW1wbGVtZW50YXRp b25zLiBBdCBsZWFzdCBJIGhhdmUgbm90IGJlZW4gaW5mb3JtZWQgYWJvdXQgYW55IGludGVyb3Bl cmFiaWxpdHkgaXNzdWVzLCBhbmQgbXkgY29sbGVhZ3VlcyBtb3JlIGZhbWlsaWFyIHdpdGggdGhl IGRlcGxveW1lbnRzIHdlcmUgbm90IGF3YXJlIG9mIGFueSBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vl cyBlaXRoZXIuIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCu+7v09uIDEzLzA2LzIwMTks IDE4LjE1LCAic2lwY29yZSBvbiBiZWhhbGYgb2YgQS4gSmVhbiBNYWhvbmV5IiA8c2lwY29yZS1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYWhvbmV5QG5vc3RydW0uY29tPiB3cm90ZToN Cg0KICAgIEhpIGFsbCwNCiAgICANCiAgICBXaGlsZSB3b3JraW5nIG9uIHRoZSBEb2MgU2hlcGhl cmQgd3JpdGV1cCBmb3IgDQogICAgZHJhZnQtaWV0Zi1zaXBjb3JlLWRpZ2VzdC1zY2hlbWUsIEkg cGVydXNlZCB0aGUgY29tbWVudHMgb24gdGhlIGVhcmxpZXIgDQogICAgdmVyc2lvbnMgb2YgdGhl IGRyYWZ0LiBNb3JlIHRoYW4gb25jZSwgdGVzdGluZyBvZiBpbXBsZW1lbnRhdGlvbnMgY2FtZSAN CiAgICB1cCAtIHRoYXQgaXQgbmVlZGVkIHRvIGhhcHBlbiwgdGhhdCB0aGVyZSBuZWVkZWQgdG8g YmUgZ3VpZGFuY2UgdG8gDQogICAgaW1wbGVtZW50ZXJzLCBldGMuDQogICAgDQogICAgSGFzIGFu eW9uZSBpbXBsZW1lbnRlZCBkcmFmdC1pZXRmLXNpcGNvcmUtZGlnZXN0LXNjaGVtZT8gSGFzIGFu eW9uZSANCiAgICB0ZXN0ZWQgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHR3byBpbXBsZW1lbnRh dGlvbnMgb2YgdGhpcyBkcmFmdD8gDQogICAgQmV0d2VlbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0 aGlzIGRyYWZ0IGFuZCBhIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbj8NCiAgICANCiAgICBUaGFua3Mh DQogICAgDQogICAgSmVhbg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3Jl QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQogICAgDQoNCg== From nobody Mon Jun 17 15:43:14 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C3D12045C; Mon, 17 Jun 2019 15:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3KHVmPUNxMI; Mon, 17 Jun 2019 15:42:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269D0120336; Mon, 17 Jun 2019 15:42:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3D962B80D5C; Mon, 17 Jun 2019 15:42:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190617224235.3D962B80D5C@rfc-editor.org> Date: Mon, 17 Jun 2019 15:42:35 -0700 (PDT) Archived-At: Subject: [sipcore] =?utf-8?q?RFC_8606_on_ISDN_User_Part_=28ISUP=29_Cause_?= =?utf-8?q?Location_Parameter_for_the_SIP_Reason_Header_Field?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 22:43:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8606 Title: ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field Author: R. Jesske Status: Standards Track Stream: IETF Date: June 2019 Mailbox: r.jesske@telekom.de Pages: 7 Characters: 14090 Updates: RFC 3326 I-D Tag: draft-ietf-sipcore-reason-q850-loc-07.txt URL: https://www.rfc-editor.org/info/rfc8606 DOI: 10.17487/RFC8606 The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jun 19 01:34:25 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED44120391; Wed, 19 Jun 2019 01:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVUTsQ4oPPQz; Wed, 19 Jun 2019 01:34:21 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60060.outbound.protection.outlook.com [40.107.6.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F11B12002F; Wed, 19 Jun 2019 01:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8bDw9Ex8LL2INFcLRBB4/rce/pT0g5bHnc2a/gZayEY=; b=BAZq+SxP2DcqvC2BV7oR0ikdKbtNUDQgVyBRFkABM0Wj7qewZu+edR7Hluv/i3jVbuJ3HeUtQN/PXNguxMUW0dHWTn0u5o0FzqOxAabg9de/b3bh4JVSSiUorOv3uTsPBc7362w6Kj6X6rUOyffsDW4R0zvNhjwjzYAzWmUZhv8= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0956.eurprd07.prod.outlook.com (10.162.27.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Wed, 19 Jun 2019 08:34:17 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.007; Wed, 19 Jun 2019 08:34:17 +0000 From: Christer Holmberg To: "A. Jean Mahoney" , SIPCORE CC: "draft-ietf-sipcore-digest-scheme@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-digest-scheme - Implementation Thread-Index: AQHVIgM3BiKhGG/L2Eam0iZJw841xaagfdSAgAJj/wA= Date: Wed, 19 Jun 2019 08:34:17 +0000 Message-ID: References: <255cce62-0ccb-6de7-a2f2-06fb8ffc1f4f@nostrum.com> <93BC97C0-BB81-4D36-9935-55AA4A9FA418@ericsson.com> In-Reply-To: <93BC97C0-BB81-4D36-9935-55AA4A9FA418@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14b8:1829:11:453d:9d99:b302:7441] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b97d450-a740-44aa-4451-08d6f490eb39 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB0956; x-ms-traffictypediagnostic: HE1PR07MB0956: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0073BFEF03 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(39860400002)(376002)(18543002)(53754006)(189003)(199004)(33656002)(6512007)(86362001)(478600001)(186003)(6306002)(14454004)(102836004)(76176011)(99286004)(66476007)(76116006)(6246003)(6116002)(73956011)(66946007)(66446008)(5660300002)(25786009)(966005)(71200400001)(71190400001)(53936002)(68736007)(486006)(4326008)(2906002)(44832011)(446003)(11346002)(2616005)(476003)(6486002)(81156014)(8676002)(64756008)(66556008)(7736002)(305945005)(81166006)(8936002)(6436002)(46003)(36756003)(6506007)(256004)(316002)(229853002)(58126008)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0956; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tRd4/nLpNginXpuOf/pO9744/4ODtub09J6BASftIhIXwakOiPr0exG4YYUU9B+vlFyl1ZEaMMB6XXuJU5CisJJaWHdnLo0GNh/i8AaY8LSJPicKuxwN9nfgE0Gp4SpXYtVhEY59EvkV487ywFNjmgKD9jHLOVagDuuXY4mG8+6A59e3EjJ5uZ0zJYKoqw01NWNPmK0NHTKWpHy/IOmeEIClQLmeteeTSnV6A30Uqo2ZUZcmKQXf8pu7IRFB6Py21j4PGQ7Y1wTnQQm4PyuQ6QoV4e/0LnJM47LzsmxUm2DXPpacQ6je09KwaEYFEJF7zh+8vS136yhkYtVAZqEHYG2bxibJIWroEC/snlKAFzIsepJJ9xI9ZyHCcYwh90BoxKyrihWY5Zh6FDHbSV/7AwrdFgWUqDGbmldUxr+2fIc= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b97d450-a740-44aa-4451-08d6f490eb39 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2019 08:34:17.6261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0956 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-digest-scheme - Implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 08:34:24 -0000 SGksDQoNCkFuZCB0byBiZSBhIGxpdHRsZSBtb3JlIHNwZWNpZmljLCB0aGUgbW9kaWZpY2F0aW9u cyBpbiB0aGUgZHJhZnQgaGF2ZSBiZWVuIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBpbiBtb2Jp bGUgSU1TIG5ldHdvcmtzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCu+7v09uIDE4LzA2 LzIwMTksIDAuMDQsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyIgPHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgYW0gYXdhcmUgb2YgaW1w bGVtZW50YXRpb25zIHRoYXQgaW1wbGVtZW50IHRoZSBtb2RpZmljYXRpb25zIGluIHRoZSBkcmFm dC4NCiAgICANCiAgICBBbmQsIHNpbmNlIHRoZSBtb2RpZmljYXRpb25zIGluIHRoZSBkcmFmdCBh cmUgZGVwbG95ZWQgaW4gbXVsdGktdmVuZG9yIG5ldHdvcmtzIEkgd291bGQgYXNzdW1lIHRoZXJl IGlzIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuIEF0IGxlYXN0IEkg aGF2ZSBub3QgYmVlbiBpbmZvcm1lZCBhYm91dCBhbnkgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMs IGFuZCBteSBjb2xsZWFndWVzIG1vcmUgZmFtaWxpYXIgd2l0aCB0aGUgZGVwbG95bWVudHMgd2Vy ZSBub3QgYXdhcmUgb2YgYW55IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGVpdGhlci4gDQogICAg DQogICAgUmVnYXJkcywNCiAgICANCiAgICBDaHJpc3Rlcg0KICAgIA0KICAgIA0KICAgIE9uIDEz LzA2LzIwMTksIDE4LjE1LCAic2lwY29yZSBvbiBiZWhhbGYgb2YgQS4gSmVhbiBNYWhvbmV5IiA8 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYWhvbmV5QG5vc3RydW0uY29t PiB3cm90ZToNCiAgICANCiAgICAgICAgSGkgYWxsLA0KICAgICAgICANCiAgICAgICAgV2hpbGUg d29ya2luZyBvbiB0aGUgRG9jIFNoZXBoZXJkIHdyaXRldXAgZm9yIA0KICAgICAgICBkcmFmdC1p ZXRmLXNpcGNvcmUtZGlnZXN0LXNjaGVtZSwgSSBwZXJ1c2VkIHRoZSBjb21tZW50cyBvbiB0aGUg ZWFybGllciANCiAgICAgICAgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0LiBNb3JlIHRoYW4gb25jZSwg dGVzdGluZyBvZiBpbXBsZW1lbnRhdGlvbnMgY2FtZSANCiAgICAgICAgdXAgLSB0aGF0IGl0IG5l ZWRlZCB0byBoYXBwZW4sIHRoYXQgdGhlcmUgbmVlZGVkIHRvIGJlIGd1aWRhbmNlIHRvIA0KICAg ICAgICBpbXBsZW1lbnRlcnMsIGV0Yy4NCiAgICAgICAgDQogICAgICAgIEhhcyBhbnlvbmUgaW1w bGVtZW50ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLWRpZ2VzdC1zY2hlbWU/IEhhcyBhbnlvbmUgDQog ICAgICAgIHRlc3RlZCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdHdvIGltcGxlbWVudGF0aW9u cyBvZiB0aGlzIGRyYWZ0PyANCiAgICAgICAgQmV0d2VlbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0 aGlzIGRyYWZ0IGFuZCBhIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbj8NCiAgICAgICAgDQogICAgICAg IFRoYW5rcyENCiAgICAgICAgDQogICAgICAgIEplYW4NCiAgICAgICAgDQogICAgICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIHNpcGNv cmUgbWFpbGluZyBsaXN0DQogICAgICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAgICAgIA0KICAgIA0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg c2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAgDQoNCg== From nobody Wed Jun 19 19:41:52 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18C1202BE for ; Wed, 19 Jun 2019 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VseR-AO0rWb for ; Wed, 19 Jun 2019 19:41:47 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF66120134 for ; Wed, 19 Jun 2019 19:41:47 -0700 (PDT) Received: from [68.100.196.217] (port=51227 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hdn1F-005iOD-8s; Wed, 19 Jun 2019 19:41:46 -0700 From: Eric Burger Message-Id: <3A619D5C-A8D9-4574-9FC2-2E5AE8BE53F6@standardstrack.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0631C744-F63E-4C0A-94E3-3C3064F9F544"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 19 Jun 2019 22:41:43 -0400 In-Reply-To: <156026982076.30851.9180244619877071155.idtracker@ietfa.amsl.com> Cc: sipcore@ietf.org To: Cooper Alissa References: <156026982076.30851.9180244619877071155.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:41:50 -0000 --Apple-Mail=_0631C744-F63E-4C0A-94E3-3C3064F9F544 Content-Type: multipart/alternative; boundary="Apple-Mail=_97F1CBE2-E0C2-4873-B04A-9AE93EE9F3E6" --Apple-Mail=_97F1CBE2-E0C2-4873-B04A-9AE93EE9F3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 inline > On Jun 11, 2019, at 12:17 PM, Alissa Cooper via Datatracker = wrote: >=20 > Please respond to the Gen-ART review. >=20 > =3D Section 3 =3D >=20 > I'm wondering about the case where I have an AI-driven assistant on my = client > that listens for me to say "Please take me off your call list" and = blocks all > future calls from that caller. It seems like the 608 use case would = apply (for > the case of false positive voice recognition), but since the = definition here > limits the intermediary to an entity "in the network," this scenario = is out of > scope. Should it be? The key is =E2=80=9Con my client.=E2=80=9D In that case, the AI is = acting directly on your behalf, so I could argue 607 is OK. I seriously = doubt an average user would want to block a call and then say, =E2=80=9CEv= en though my AI agent just blocked you, if you really want to get me, = here=E2=80=99s my real phone number.=E2=80=9D I could imagine a developer pointing callers to the developer=E2=80=99s = helpline if they thought the AI rejected them in error, which is not a = possibility with 607. On the face of it, that sounds like a great idea. = Who would not want to find out their application is not working well? = However, I would think the privacy implications of such behavior would = be beyond untenable. As a thought experiment, let us say that you put an = AI on your phone from company G. Company G =E2=80=98innocently=E2=80=99 = issues 608=E2=80=99s instead of 607=E2=80=99s, because if they get the = speech recognition wrong, they would like to know about it. However, = this results in a front-page article in The Intercept talking about how = company G is pervasively monitoring user=E2=80=99s rejected calls by = sending company G beacons every time a user=E2=80=99s call gets = rejected, or at least when the calling party tries to remediate. Yuck. So, even though in theory since a machine rejected the call (normally a = 608), it is totally under your control. So, I=E2=80=99d offer 607 is = still the right thing. Do we need text to talk about this? It seems to be a way-out-there = corner case that could have bad repercussions if implemented poorly. [snip] > =3D Section 4.1 =3D >=20 > Using "bitbucket" in the examples seems like it sends the wrong = message about > the utility of the contact address. On the one hand, I might offer it is sending the reality message :-) However, I=E2=80=99ll take my cynical hat off and fix it. Thanks! --Apple-Mail=_97F1CBE2-E0C2-4873-B04A-9AE93EE9F3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 inline

On Jun 11, 2019, at 12:17 PM, = Alissa Cooper via Datatracker <noreply@ietf.org> wrote:

Please respond to the Gen-ART review.

=3D Section 3 =3D

I'm wondering about the case where I have an AI-driven = assistant on my client
that listens for me to say "Please = take me off your call list" and blocks all
future calls = from that caller. It seems like the 608 use case would apply (for
the case of false positive voice recognition), but since the = definition here
limits the intermediary to an entity "in = the network," this scenario is out of
scope. Should it = be?

The key is =E2=80=9Con my client.=E2=80=9D In that = case, the AI is acting directly on your behalf, = so I could argue 607 is OK. I seriously doubt an average user would want = to block a call and then say, =E2=80=9CEven though my AI agent just = blocked you, if you really want to get me, here=E2=80=99s my real phone = number.=E2=80=9D

I could imagine = a developer pointing callers to the developer=E2=80=99s = helpline if they thought the AI rejected them in error, which is not a = possibility with 607. On the face of it, that sounds like a great idea. = Who would not want to find out their application is not working well? = However, I would think the privacy implications of such behavior would = be beyond untenable. As a thought experiment, let us say that you put an = AI on your phone from company G. Company G =E2=80=98innocently=E2=80=99 = issues 608=E2=80=99s instead of 607=E2=80=99s, because if they get the = speech recognition wrong, they would like to know about it. However, = this results in a front-page article in The Intercept talking about how = company G is pervasively monitoring user=E2=80=99s rejected calls by = sending company G beacons every time a user=E2=80=99s call gets = rejected, or at least when the calling party tries to remediate. = Yuck.

So, even though in theory = since a machine rejected the call (normally a 608), it = is totally under your control. So, I=E2=80=99d offer 607 is still the = right thing.

Do we need text to talk = about this? It seems to be a way-out-there corner case that could have = bad repercussions if implemented poorly.

[snip]

=3D Section 4.1 = =3D

Using "bitbucket" in the examples seems = like it sends the wrong message about
the utility of the = contact address.

On = the one hand, I might offer it is sending the reality message = :-)
However, I=E2=80=99ll take my cynical hat off and fix it. = Thanks!

= --Apple-Mail=_97F1CBE2-E0C2-4873-B04A-9AE93EE9F3E6-- --Apple-Mail=_0631C744-F63E-4C0A-94E3-3C3064F9F544 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl0K8mcACgkQDDCGh758 rsnKmhAAgcxl+wP+00iJckt61KikygKfrV0NjrOlBFYg6vOs2vsfPJA2yW0EGmOa soayA/trUCwd9oI62kZonuZMUTwbRNQwfYsoQBAuhLNk/Nrf6qezsfqjh6HyDQ47 BKykTZT12ywzuGnCK0dKEI5028l3EnrsQ596lXTJWq1bxSCTaNStUq6qhTJlS0Q0 7xaLtdq9j0p1SX91b355PCIPMApAfpaARMHJyMTXkTfka0+yEzdUiruErOqN6d7y NyJ+idI7B1qlC8N186MGNjcz6I0mLK9lMWU49kbAqKQ+njfSMHItDfser2StkjRl HLs21uXGW5qZJEJL3EApe+n0ZzPCNI4nsQtJvwU1jB48ndpn5mIdja8W4SwF8HJC 4kxsG3QSdWax3/Uf4kfVEyoaw9UQV+MtTk01B3/1oEpLdNNaGYE4dFKX5RKR+XoB S8S6tWKvVS5TOoDW0a7ksc92rwCtuauPA0OmqA3tIxPn8aSXi9pXAptE9cEJwJm2 k2/joQTmJsj9ESvl81crCojXE2FvMlP8Le34a7IKmFPBmK7RRqPwlbSaOG6MQz1v KXT3h+ircUonAjFykfb+g4dCoIzhrZzqtDy7V9ms3xgPbYTkk0W+DwC2NxVN+mjj s4PDEyWaiP3qpFjkyODj79iXeb0dK6wXmdARLBa8gzowLXE4oeY= =O6MS -----END PGP SIGNATURE----- --Apple-Mail=_0631C744-F63E-4C0A-94E3-3C3064F9F544-- From nobody Wed Jun 19 19:50:51 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD5120301; Wed, 19 Jun 2019 19:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rOKKjNDlgk5; Wed, 19 Jun 2019 19:50:47 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65151202C5; Wed, 19 Jun 2019 19:50:47 -0700 (PDT) Received: from [68.100.196.217] (port=51354 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hdn9t-005wEK-MH; Wed, 19 Jun 2019 19:50:43 -0700 From: Eric Burger Message-Id: <8ABA9BE7-8516-4F10-9E58-ED6D23A352B1@standardstrack.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4A3632C5-12E5-44D3-BA09-7B07CED67F80"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 19 Jun 2019 22:50:40 -0400 In-Reply-To: <156030110472.5972.1062340244094112710.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-sipcore-rejected@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org To: Benjamin Kaduk References: <156030110472.5972.1062340244094112710.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:50:49 -0000 --Apple-Mail=_4A3632C5-12E5-44D3-BA09-7B07CED67F80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 11, 2019, at 8:58 PM, Benjamin Kaduk via Datatracker = wrote: [snip] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Do we want to give any references/examples for "some jurisdictions" or > "many jurisdictions=E2=80=9D? I would prefer not to put it into an archival document. One might think = the U.S. and Canada would be examples, but I cannot speak on behalf of = the U.S. Government, Canadian Government, or any governmental = department, agency, or commission. [snip] > Section 3.2.2 >=20 > The payload contains two JSON values. The first JSON Web Token = (JWT) > claim that MUST be present is the iat (issued at) claim [RFC7519]. > The "iat" MUST be set to the date and time of the issuance of the = 608 > response. This mandatory component protects the response from = replay > attacks. >=20 > nit(?): Perhaps this protection is only "outside the scope of a narrow > window of time corresponding to the allowed RTT and any permitted time > skew", per Section 3.3. Given the ubiquity of using iat for just this purpose, I would offer it = would be redundant to reiterate it here. Would it be OK with you to not = go there here? > Call originators (at the UAC) can > use the information returned by the jCard to contact the = intermediary > that rejected the call to appeal the intermediary's blocking of the > call attempt. What the intermediary does if the blocked caller > contacts the intermediary is outside the scope of this document. >=20 > It seems like it is permissible for the intermediary to reject this = new > call as well; can we get into some sort of recursion-like situation? That would be a major fail on the part of the intermediary. However, I = do not think there is anything we can do about it. We certainly do not = want to tell the intermediary operator they cannot protect themselves = from, in this case, a TDoS attack. On the other hand, I do not think we = can possibly require the intermediary operator to accept the call. That = would be some magic Protocol Policing(tm) if we could! Because of the = risks, I am not sure we even want to give guidance - such an operational = issue seems outside the scope of the IETF. However, if the IESG or = SIPCORE folks think otherwise, I can put in some language to that = effect. [snip] I edited most all of your other comments in. Thanks! --Apple-Mail=_4A3632C5-12E5-44D3-BA09-7B07CED67F80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl0K9IAACgkQDDCGh758 rskwoA//dteYflHmEU1O15u3BEEVKHz1WmJvoQH9/Fau7bfPY5oDMpasNtT/lPdY v1qhkGUBMfYi4K+cx31ZXVl+o4LuoWVgenwze++kRBBFXiRtJ1g6PQIiVyylhJqv zv7196jvKk2yabBBEB61Fefql6yiWGRY1Q/yyLF3WSdw6ypqO+nnkSOrOX5hr7rT Z09KWXBb4Yv7xw9LdidmTiMN4VvoRAtbc5eUafozn5TSPj0RmDJ4L/k4BBiN/DvB D/VaxQjmOWSLlDX/UwLZVtyk6Bb2RC5jMkW48rlSY+qZaK346QZlP7+bXsGEiJfC xCoOdhDHPMD+IXzecZR506lvgYvjd/9qccC70HnGQNBqD+EmIyN2AuiDGrLxtS4b iaptzOW6/11Lnpdm5yG88Fn2ahsIBGM9pk9cma9GjE8kHfgOSg9qwbUIJORRCKwg YOsExwSkiAUrlg8iZHldUcLNS8s+5S+JAfy2fvaoBvGRUSBDVxhjuzVnQlsx7h9u NP4POS29RGUSDLjwLd8q7eQMyT6WGUJpeG7K+ugay0gmCKtp4dubSRmDrebQaJlq 1ZYZOdV04LL3kOrbFC1fIRiUgvh59aBpHNWrw/2yqdEezfeoQNW5gLhjCnanty/o ffjNS6tyW8IRKuUSkZYHfvg8s80Z0tDe5BatAbDJllZ5cbD0zEk= =3wKi -----END PGP SIGNATURE----- --Apple-Mail=_4A3632C5-12E5-44D3-BA09-7B07CED67F80-- From nobody Wed Jun 19 19:51:56 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8471202BE; Wed, 19 Jun 2019 19:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kZMdhAM-fIs; Wed, 19 Jun 2019 19:51:44 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE594120134; Wed, 19 Jun 2019 19:51:44 -0700 (PDT) Received: from [68.100.196.217] (port=51354 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hdnAs-005wEK-SR; Wed, 19 Jun 2019 19:51:44 -0700 From: Eric Burger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_58169B3F-3AE5-445E-8124-C4CA108B4810"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 19 Jun 2019 22:51:42 -0400 In-Reply-To: <3A619D5C-A8D9-4574-9FC2-2E5AE8BE53F6@standardstrack.com> Cc: The IESG , draft-ietf-sipcore-rejected@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org To: Cooper Alissa References: <156026982076.30851.9180244619877071155.idtracker@ietfa.amsl.com> <3A619D5C-A8D9-4574-9FC2-2E5AE8BE53F6@standardstrack.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:51:47 -0000 --Apple-Mail=_58169B3F-3AE5-445E-8124-C4CA108B4810 Content-Type: multipart/alternative; boundary="Apple-Mail=_FBB09E33-6821-4468-86C8-E191E3CA7489" --Apple-Mail=_FBB09E33-6821-4468-86C8-E191E3CA7489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My bad - I forgot all the CC=E2=80=99s. > On Jun 19, 2019, at 10:41 PM, Eric Burger = wrote: >=20 > inline >=20 >> On Jun 11, 2019, at 12:17 PM, Alissa Cooper via Datatracker = > wrote: >>=20 >> Please respond to the Gen-ART review. >>=20 >> =3D Section 3 =3D >>=20 >> I'm wondering about the case where I have an AI-driven assistant on = my client >> that listens for me to say "Please take me off your call list" and = blocks all >> future calls from that caller. It seems like the 608 use case would = apply (for >> the case of false positive voice recognition), but since the = definition here >> limits the intermediary to an entity "in the network," this scenario = is out of >> scope. Should it be? >=20 > The key is =E2=80=9Con my client.=E2=80=9D In that case, the AI is = acting directly on your behalf, so I could argue 607 is OK. I seriously = doubt an average user would want to block a call and then say, =E2=80=9CEv= en though my AI agent just blocked you, if you really want to get me, = here=E2=80=99s my real phone number.=E2=80=9D >=20 > I could imagine a developer pointing callers to the developer=E2=80=99s = helpline if they thought the AI rejected them in error, which is not a = possibility with 607. On the face of it, that sounds like a great idea. = Who would not want to find out their application is not working well? = However, I would think the privacy implications of such behavior would = be beyond untenable. As a thought experiment, let us say that you put an = AI on your phone from company G. Company G =E2=80=98innocently=E2=80=99 = issues 608=E2=80=99s instead of 607=E2=80=99s, because if they get the = speech recognition wrong, they would like to know about it. However, = this results in a front-page article in The Intercept talking about how = company G is pervasively monitoring user=E2=80=99s rejected calls by = sending company G beacons every time a user=E2=80=99s call gets = rejected, or at least when the calling party tries to remediate. Yuck. >=20 > So, even though in theory since a machine rejected the call (normally = a 608), it is totally under your control. So, I=E2=80=99d offer 607 is = still the right thing. >=20 > Do we need text to talk about this? It seems to be a way-out-there = corner case that could have bad repercussions if implemented poorly. >=20 > [snip] >=20 >> =3D Section 4.1 =3D >>=20 >> Using "bitbucket" in the examples seems like it sends the wrong = message about >> the utility of the contact address. >=20 > On the one hand, I might offer it is sending the reality message :-) > However, I=E2=80=99ll take my cynical hat off and fix it. Thanks! >=20 --Apple-Mail=_FBB09E33-6821-4468-86C8-E191E3CA7489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = bad - I forgot all the CC=E2=80=99s.

On Jun = 19, 2019, at 10:41 PM, Eric Burger <eburger@standardstrack.com> wrote:

inline

On Jun 11, 2019, at 12:17 PM, Alissa Cooper = via Datatracker <noreply@ietf.org> wrote:

Please respond to the Gen-ART review.

=3D Section 3 =3D

I'm wondering about the case where I have an AI-driven = assistant on my client
that listens for me to say "Please = take me off your call list" and blocks all
future calls = from that caller. It seems like the 608 use case would apply (for
the case of false positive voice recognition), but since the = definition here
limits the intermediary to an entity "in = the network," this scenario is out of
scope. Should it = be?

The key is =E2=80=9Con my client.=E2=80=9D= In that case, the AI is acting directly on your = behalf, so I could argue 607 is OK. I seriously doubt an average user = would want to block a call and then say, =E2=80=9CEven though my AI = agent just blocked you, if you really want to get me, here=E2=80=99s my = real phone number.=E2=80=9D

I could = imagine a developer pointing callers to the developer=E2=80=99= s helpline if they thought the AI rejected them in error, which is not a = possibility with 607. On the face of it, that sounds like a great idea. = Who would not want to find out their application is not working well? = However, I would think the privacy implications of such behavior would = be beyond untenable. As a thought experiment, let us say that you put an = AI on your phone from company G. Company G =E2=80=98innocently=E2=80=99 = issues 608=E2=80=99s instead of 607=E2=80=99s, because if they get the = speech recognition wrong, they would like to know about it. However, = this results in a front-page article in The Intercept talking about how = company G is pervasively monitoring user=E2=80=99s rejected calls by = sending company G beacons every time a user=E2=80=99s call gets = rejected, or at least when the calling party tries to remediate. = Yuck.

So, even = though in theory since a machine rejected the call = (normally a 608), it is totally under your control. So, I=E2=80=99d = offer 607 is still the right thing.

Do we need text to talk about this? It = seems to be a way-out-there corner case that could have bad = repercussions if implemented poorly.

[snip]

=3D Section 4.1 =3D

Using "bitbucket" in the examples seems like it sends the = wrong message about
the utility of the contact = address.

On = the one hand, I might offer it is sending the reality message = :-)
However, I=E2=80=99ll take my cynical hat off = and fix it. Thanks!

= --Apple-Mail=_FBB09E33-6821-4468-86C8-E191E3CA7489-- --Apple-Mail=_58169B3F-3AE5-445E-8124-C4CA108B4810 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl0K9L4ACgkQDDCGh758 rsnkrA/+JQ02oRJuqwluToRUvRvT2o8rmWvHdHe5BjYHPK08XWBo/C/dxNjbhAQA wV3tcu7VP2ISvr3oRnAKqacIQg3M33tU8ZvHuna1pXPNc4/LUQrnZfzKBM9iO7Ec Ck7R+yjBwR5Uv/m7u5CJ50AYykiUtJpqEzExUlnfW+PAn7aX2ouoHF3y1Val379U 1Rv7K4p2OVTD4FPzPyttOC9rhIHkfs5M0NJHfZqrXKt3VpHpG6JZVVv4R9dxFLIH JJ/WMDwq4xQ1iUfKbp8GQJsrmUEXSnpurxZMnb63OBmPnV6vfgxoxlm132ww0eY+ xGcjAMzGRCLfZ9DyWRgZdNTX8Da2w1Gmnme0h7pY7e7kJnqm0QpQ+eMCY/pnFzC0 3IF7PYZ2Yf6qQ/z3EDil1hv2ui6RJTEL35bj8TJA3K9lJ8zDzoQPvEAuo/dYPuk+ hgwEf6U8wIr8szBwbprHG3vPEAXbi+qdckYEnjpkOMJpJjg0NpgAyKckieSFKyx+ DiQiXdS5EKrCGosn3H/lXhWO9Y0dPpNfEFIX34wY/OLFwlcOZZKQB76Xy2TYZ1is +GUmzopPbW6VoqW7gmFBOwNouAXQS86pvyS5H/sElxjaBGdKcBFEbvVbsz4+fofu qbV34a6tgh4zxJeXAVmcWVcfRE//7RqeAGdrBAeLPlq15OABQxo= =W4fu -----END PGP SIGNATURE----- --Apple-Mail=_58169B3F-3AE5-445E-8124-C4CA108B4810-- From nobody Wed Jun 19 19:54:29 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60221120134; Wed, 19 Jun 2019 19:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdYYa68vsGuO; Wed, 19 Jun 2019 19:54:18 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33342120072; Wed, 19 Jun 2019 19:54:18 -0700 (PDT) Received: from [68.100.196.217] (port=51403 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hdnDI-0062LX-R5; Wed, 19 Jun 2019 19:54:17 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Eric Burger In-Reply-To: <156035921069.14103.10047256808594559317.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2019 22:54:11 -0400 Cc: The IESG , draft-ietf-sipcore-rejected@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, sipcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156035921069.14103.10047256808594559317.idtracker@ietfa.amsl.com> To: Kumari Warren X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] Warren Kumari's Yes on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:54:21 -0000 Your suggestion for my bizarre Base Rate Fallacy language makes is much = clearer and also fixes similar issues raised by others. Thanks! > On Jun 12, 2019, at 1:06 PM, Warren Kumari via Datatracker = wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-sipcore-rejected-08: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I generally approach SIP documents with a sense of foreboding =E2=80=94 = they are often > long, expect a large amount of knowledge outside my area of expertise, = and > require lots of reference chasing =E2=80=94 but this was a really good = read. It > describes the problem well, it lays out the protocol clearly, and = contains > enough humor / snark to make reading it actually enjoyable. >=20 > Nits: > "Another value of the 607 rejection is presuming the proxy forwards > the response code to the User Agent Client (UAC), the calling UAC or > intervening proxies will also learn the user is not interested in > receiving calls from that sender." > I found this sentence really hard to parse -- I think adding a comma = after "is" > fixes it. >=20 > "An algorithm can be vulnerable to an algorithm subject to the base = rate > fallacy [BaseRate] rejecting the call." Unparsable -- duplication? = Perhaps just > " An algorithm can be vulnerable to the base rate fallacy [BaseRate] = rejecting > the call."? >=20 >=20 From nobody Wed Jun 19 20:14:39 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B33120072; Wed, 19 Jun 2019 20:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfmHj2MocDlG; Wed, 19 Jun 2019 20:14:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FBF120134; Wed, 19 Jun 2019 20:14:28 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5K3EOa6027100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jun 2019 23:14:26 -0400 Date: Wed, 19 Jun 2019 22:14:23 -0500 From: Benjamin Kaduk To: Eric Burger Cc: The IESG , draft-ietf-sipcore-rejected@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org Message-ID: <20190620031423.GC52381@kduck.mit.edu> References: <156030110472.5972.1062340244094112710.idtracker@ietfa.amsl.com> <8ABA9BE7-8516-4F10-9E58-ED6D23A352B1@standardstrack.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8ABA9BE7-8516-4F10-9E58-ED6D23A352B1@standardstrack.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 03:14:31 -0000 On Wed, Jun 19, 2019 at 10:50:40PM -0400, Eric Burger wrote: > > > > On Jun 11, 2019, at 8:58 PM, Benjamin Kaduk via Datatracker wrote: > [snip] > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Do we want to give any references/examples for "some jurisdictions" or > > "many jurisdictions”? > > I would prefer not to put it into an archival document. One might think the U.S. and Canada would be examples, but I cannot speak on behalf of the U.S. Government, Canadian Government, or any governmental department, agency, or commission. Understood. > [snip] > > Section 3.2.2 > > > > The payload contains two JSON values. The first JSON Web Token (JWT) > > claim that MUST be present is the iat (issued at) claim [RFC7519]. > > The "iat" MUST be set to the date and time of the issuance of the 608 > > response. This mandatory component protects the response from replay > > attacks. > > > > nit(?): Perhaps this protection is only "outside the scope of a narrow > > window of time corresponding to the allowed RTT and any permitted time > > skew", per Section 3.3. > > Given the ubiquity of using iat for just this purpose, I would offer it would be redundant to reiterate it here. Would it be OK with you to not go there here? That would be okay, yes. > > Call originators (at the UAC) can > > use the information returned by the jCard to contact the intermediary > > that rejected the call to appeal the intermediary's blocking of the > > call attempt. What the intermediary does if the blocked caller > > contacts the intermediary is outside the scope of this document. > > > > It seems like it is permissible for the intermediary to reject this new > > call as well; can we get into some sort of recursion-like situation? > > That would be a major fail on the part of the intermediary. However, I do not think there is anything we can do about it. We certainly do not want to tell the intermediary operator they cannot protect themselves from, in this case, a TDoS attack. On the other hand, I do not think we can possibly require the intermediary operator to accept the call. That would be some magic Protocol Policing(tm) if we could! Because of the risks, I am not sure we even want to give guidance - such an operational issue seems outside the scope of the IETF. However, if the IESG or SIPCORE folks think otherwise, I can put in some language to that effect. Mostly I just wanted to check that I was understanding things properly; I agree that would be a major fail by the intermediary. So please don't add any guidance solely on my account! > [snip] > I edited most all of your other comments in. Thanks! > Thanks! -Ben From nobody Mon Jun 24 00:46:20 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E224F120088; Mon, 24 Jun 2019 00:46:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156136237184.17571.3756644280885220431@ietfa.amsl.com> Date: Mon, 24 Jun 2019 00:46:11 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 07:46:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Authors : Christer Holmberg Steve Donovan Jonathan Rosenberg Filename : draft-ietf-sipcore-rfc4028bis-01.txt Pages : 26 Date : 2019-06-24 Abstract: This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 24 08:50:02 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB812019F for ; Mon, 24 Jun 2019 08:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppXlT86ewD9b for ; Mon, 24 Jun 2019 08:49:58 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED0E12008D for ; Mon, 24 Jun 2019 08:49:58 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5OFnuR5001884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Jun 2019 11:49:57 -0400 To: sipcore@ietf.org References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> Date: Mon, 24 Jun 2019 11:49:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <156136237184.17571.3756644280885220431@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:50:01 -0000 Somehow I never noticed the publication of the -00 of this. Looking back, I now see that it was published and adopted as a wg draft back in December. But I don't see any discussion of it at all. And looking at the diff between -01 and rfc4028 I don't see any changes that would explain why it is being issued. The only changes I see seem to be artifacts of reformatting it according to current conventions. What is then intent in making this update? Thanks, Paul On 6/24/19 3:46 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : Session Timers in the Session Initiation Protocol (SIP) > Authors : Christer Holmberg > Steve Donovan > Jonathan Rosenberg > Filename : draft-ietf-sipcore-rfc4028bis-01.txt > Pages : 26 > Date : 2019-06-24 > > Abstract: > This document defines an extension to the Session Initiation Protocol > (SIP). This extension allows for a periodic refresh of SIP sessions > through a re-INVITE or UPDATE request. The refresh allows both user > agents and proxies to determine whether the SIP session is still > active. The extension defines two new header fields: Session- > Expires, which conveys the lifetime of the session, and Min-SE, which > conveys the minimum allowed value for the session timer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 24 09:03:49 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42512046E for ; Mon, 24 Jun 2019 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPlQVwz5Tryj for ; Mon, 24 Jun 2019 09:03:46 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F7612019B for ; Mon, 24 Jun 2019 09:03:45 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5OG3iEL002853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Jun 2019 12:03:44 -0400 To: sipcore@ietf.org References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Mon, 24 Jun 2019 12:03:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 16:03:48 -0000 On 6/24/19 11:49 AM, Paul Kyzivat wrote: > Somehow I never noticed the publication of the -00 of this. > Looking back, I now see that it was published and adopted as a wg draft > back in December. But I don't see any discussion of it at all. Sorry. After further looking I did find some discussion. But it was all procedural. No mention of *why* that I could see. > And looking at the diff between -01 and rfc4028 I don't see any changes > that would explain why it is being issued. The only changes I see seem > to be artifacts of reformatting it according to current conventions. > > What is then intent in making this update? This is still the question. Thanks, Paul >     Thanks, >     Paul > > On 6/24/19 3:46 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Core WG >> of the IETF. >> >>          Title           : Session Timers in the Session Initiation >> Protocol (SIP) >>          Authors         : Christer Holmberg >>                            Steve Donovan >>                            Jonathan Rosenberg >>     Filename        : draft-ietf-sipcore-rfc4028bis-01.txt >>     Pages           : 26 >>     Date            : 2019-06-24 >> >> Abstract: >>     This document defines an extension to the Session Initiation Protocol >>     (SIP).  This extension allows for a periodic refresh of SIP sessions >>     through a re-INVITE or UPDATE request.  The refresh allows both user >>     agents and proxies to determine whether the SIP session is still >>     active.  The extension defines two new header fields: Session- >>     Expires, which conveys the lifetime of the session, and Min-SE, which >>     conveys the minimum allowed value for the session timer. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jun 24 09:34:15 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B662120668 for ; Mon, 24 Jun 2019 09:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DItwE3zWlGpt for ; Mon, 24 Jun 2019 09:34:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54F7120616 for ; Mon, 24 Jun 2019 09:34:04 -0700 (PDT) Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x5OGXwpw010122 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Jun 2019 11:33:59 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1561394040; bh=rzmcSB7QjNXGKJ1LxO/M1D783eYBCmfgGjs/cUNF31Q=; h=Subject:To:References:From:Date:In-Reply-To; b=UuKFRAmudfUb9pXH1MnxyyPTbSPYFBjapyhAkhs/eJVIFB9O0Ffj8ssLfoU33B8WQ FG6P9fbgHvNW/yK6tTZ9UXpehiZAPxA+Egw1Vtw4+kq0eVctAwAh7TC+pmZC1H+jKv qHw1e4Vrbn6Z305xsdeCUXcM+PNfBh5UueWKmuMs= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local To: Paul Kyzivat , sipcore@ietf.org References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> From: "A. Jean Mahoney" Message-ID: Date: Mon, 24 Jun 2019 11:33:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 16:34:14 -0000 Hi Paul, Given the draft name changes, it is hard to follow what happened if you are searching through mailarchive (When neither email subjects nor bodies contain full draft names, mailarchive can't pull them up.) On 6/24/19 11:03 AM, Paul Kyzivat wrote: > On 6/24/19 11:49 AM, Paul Kyzivat wrote: >> Somehow I never noticed the publication of the -00 of this. >> Looking back, I now see that it was published and adopted as a wg >> draft back in December. But I don't see any discussion of it at all. The adoption discussion was originally for draft-holmberg-sipcore-sessiontimer-race: https://mailarchive.ietf.org/arch/msg/sipcore/f0OPMCcrWWil7w2CeHVP-ywwyaU That draft became draft-ietf-sipcore-sessiontimer-race. > > Sorry. After further looking I did find some discussion. But it was all > procedural. No mention of *why* that I could see. Then at IETF 103, it was discussed that perhaps a bis of 4028 would be better: https://mailarchive.ietf.org/arch/msg/sipcore/ubJIdvR76g3_i9dcwsxFEQLdawk And that was followed up with a call to replace draft-ietf-sipcore-sessiontimer-race with 4028bis: https://mailarchive.ietf.org/arch/msg/sipcore/6J41DcyYfdTG9ZvwAtms1lhFc74 > >> And looking at the diff between -01 and rfc4028 I don't see any >> changes that would explain why it is being issued. The only changes I >> see seem to be artifacts of reformatting it according to current >> conventions. draft-ietf-sipcore-rfc4028bis-00 was just a formatting update while waiting for responses from RFC 4028 co-authors to see if they wanted to remain as co-authors of the bis draft (discussion occurred off-list). Then the draft just expired. Thanks! Jean >> >> What is then intent in making this update? > > This is still the question. > >     Thanks, >     Paul > >>      Thanks, >>      Paul >> >> On 6/24/19 3:46 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Core WG >>> of the IETF. >>> >>>          Title           : Session Timers in the Session Initiation >>> Protocol (SIP) >>>          Authors         : Christer Holmberg >>>                            Steve Donovan >>>                            Jonathan Rosenberg >>>     Filename        : draft-ietf-sipcore-rfc4028bis-01.txt >>>     Pages           : 26 >>>     Date            : 2019-06-24 >>> >>> Abstract: >>>     This document defines an extension to the Session Initiation >>> Protocol >>>     (SIP).  This extension allows for a periodic refresh of SIP sessions >>>     through a re-INVITE or UPDATE request.  The refresh allows both user >>>     agents and proxies to determine whether the SIP session is still >>>     active.  The extension defines two new header fields: Session- >>>     Expires, which conveys the lifetime of the session, and Min-SE, >>> which >>>     conveys the minimum allowed value for the session timer. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-01 >>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-01 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-01 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 24 09:54:42 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4314312003E; Mon, 24 Jun 2019 09:54:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156139527419.17457.15161486253539766732@ietfa.amsl.com> Date: Mon, 24 Jun 2019 09:54:34 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 16:54:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-01.txt Pages : 11 Date : 2019-06-24 Abstract: This document defines a mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the delegation of the user authentication and SIP registration authorization to a dedicated third-party entity that is separate from the SIP network elements that provide the SIP service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 24 09:58:25 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA20712063B for ; Mon, 24 Jun 2019 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqRmd0l_w4C2 for ; Mon, 24 Jun 2019 09:58:20 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4710B1200B2 for ; Mon, 24 Jun 2019 09:58:20 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u19so2631430ior.9 for ; Mon, 24 Jun 2019 09:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=W3bRo5lug0Q7XExuhLcqlq6yFVXwRJVi/v3wUDr6PFs=; b=Yjjcv+urTXjxy0Dy4YS8RMUDOwGA0RdWAKOCFpRxfjPp5NifgpqaHu3zaGGrwwO6Ff m7bVvbBPOt9s0y8vNICuMnMeYFMw7Is8m14/ZRP8bziNYv/wjrOlRdN5Ibq0QutrY5vR F7UtBvqfnOCBYOa9IeqXccez5ki6N+IELrbjcnBnV1bjxx4zhQIaJGYlaqwxTE3b956N 5t1nO12DSffD9QVl8x35JNhWbG0MzO7ofYBncD1MrhS6UR52tSfjTWQvObkeLycQ7N3i rZGtuaex8/6WVR2c7U+/NOboR6DPzuvPj56rlT1SIthGE66QIxNHt6/ouxOvPUzUsBRN ESUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=W3bRo5lug0Q7XExuhLcqlq6yFVXwRJVi/v3wUDr6PFs=; b=fJLHI5PxOpdkiAkENvF4SryTMjWJyrOwdoYvuNUJXkH7Q2YEFZ6PyO6O+PeTP+65KZ OG+FA1pcnc43E7VWddOkt3x+cZbuPMWxc5lvNQAlSjZc38YaZPeuWKa7yENCpwaP/SH1 bUZWz2iO6UOoQM1fJz2aMOWsmg97w0j/dLXNRGNeCz3Kjdq5r3SAb/74ob9k0Wd7q3pJ F7/HLFUc8uPGbJu4xZ5zAC6AxzXe0yR9HW2IY3dFt2UhF3XkwC/tDa2si/W06Tj00xlf cJbt+9gT+G4MITeZF4OK/XS6esK7qA01TjVr8CQSuWBVambHXro8okMV4z06NpqMh0B1 QHHQ== X-Gm-Message-State: APjAAAUCaaRUQ2VT9bpbI3KMzjJgAGdwpYkJu5mFevfinclOU6Y68c4I z46MtzaSg7UAGp8Mm2VDnAxLvhz2TtYEky3qE+E2hkNGZ6I= X-Google-Smtp-Source: APXvYqz/HrsLKEFHAFWazRU2nXWgu77GbaK+8ojeSfC7yUT43iGKNP5zF6MaD5LBSYaM/zfEzu203RZIXeQ6i5/NbCk= X-Received: by 2002:a6b:e608:: with SMTP id g8mr39087883ioh.88.1561395499245; Mon, 24 Jun 2019 09:58:19 -0700 (PDT) MIME-Version: 1.0 References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> In-Reply-To: <156139527419.17457.15161486253539766732@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Mon, 24 Jun 2019 12:58:08 -0400 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary="000000000000162477058c14b876" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 16:58:23 -0000 --000000000000162477058c14b876 Content-Type: text/plain; charset="UTF-8" All, We have submitted a new version of the draft that adds more details and we believe address the comments provided so far. Please, take a look and let us know what you think. Regards, Rifaat On Mon, Jun 24, 2019 at 12:55 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG of > the IETF. > > Title : Third-Party Token-based Authentication and > Authorization for Session Initiation Protocol (SIP) > Authors : Rifaat Shekh-Yusef > Christer Holmberg > Victor Pascual > Filename : draft-ietf-sipcore-sip-token-authnz-01.txt > Pages : 11 > Date : 2019-06-24 > > Abstract: > This document defines a mechanism for SIP, that is based on the OAuth > 2.0 and OpenID Connect Core 1.0 specifications, to enable the > delegation of the user authentication and SIP registration > authorization to a dedicated third-party entity that is separate from > the SIP network elements that provide the SIP service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000162477058c14b876 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have submitted a new version of= the draft that adds more details and we believe address the comments provi= ded so far.
Please, take a look and let us know what you think.

Regards,
=C2=A0Rifaat


On Mon, Jun 24, 2019 at 12:55 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core WG of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Third-Party Token-based Authentication and Authorization for Session Initi= ation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rifa= at Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Victor Pascual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-sip-token-authnz-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-06-24

Abstract:
=C2=A0 =C2=A0This document defines a mechanism for SIP, that is based on th= e OAuth
=C2=A0 =C2=A02.0 and OpenID Connect Core 1.0 specifications, to enable the<= br> =C2=A0 =C2=A0delegation of the user authentication and SIP registration
=C2=A0 =C2=A0authorization to a dedicated third-party entity that is separa= te from
=C2=A0 =C2=A0the SIP network elements that provide the SIP service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-sipcore-sip-token-authnz-01
https://datatracker.ietf= .org/doc/html/draft-ietf-sipcore-sip-token-authnz-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-sipcore-sip-token-authnz-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000162477058c14b876-- From nobody Mon Jun 24 10:38:56 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E201200A1 for ; Mon, 24 Jun 2019 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yvwnecZk7G0 for ; Mon, 24 Jun 2019 10:38:52 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B9D12003E for ; Mon, 24 Jun 2019 10:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s+JCHdgPjTI/MP5B1GNXf0RBijaq39MU99xog6w3RR8=; b=Bp17pcHJygA/stRoEFIKGalaHCy4mS/trrUUhd+jjcn9EGYCr+LDgEqxR5/utDWw2OsGW7jkoZJ86UoCxMBwf8o/+ghPUGkfLYfGPguktfOxS2kaNBafJyi8TFCfdww9Sq0y+RJBB3qAdKBv+GEXzEL/0PUbtKETn2P4Vq600Lw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3177.eurprd07.prod.outlook.com (10.170.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Mon, 24 Jun 2019 17:38:46 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 17:38:46 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt Thread-Index: AQHVKmEFvyFpYHLlwEWxtjQeSyBOPaaq9C4AgABQsoA= Date: Mon, 24 Jun 2019 17:38:46 +0000 Message-ID: References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> In-Reply-To: <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c042f1b-c529-4ccb-da42-08d6f8cacf4b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3177; x-ms-traffictypediagnostic: HE1PR07MB3177: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(136003)(346002)(39860400002)(366004)(199004)(189003)(66446008)(8676002)(476003)(66476007)(33656002)(66556008)(7736002)(64756008)(2501003)(66066001)(66946007)(66574012)(305945005)(76116006)(36756003)(44832011)(99286004)(8936002)(73956011)(71200400001)(2906002)(966005)(86362001)(71190400001)(446003)(58126008)(68736007)(6506007)(26005)(6512007)(2616005)(6306002)(3846002)(25786009)(11346002)(6116002)(316002)(6436002)(6486002)(102836004)(53546011)(110136005)(2171002)(5660300002)(486006)(186003)(53936002)(256004)(14444005)(14454004)(229853002)(81156014)(478600001)(81166006)(6246003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3177; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5bEACXV+Lx8tzdsfHoCSxJulstah5RnZbe5/qM3J7gyVUjyW9pQkQP3ZotRjsDumUgBjrDAv6e7V9FTxIuVVz5+fDckMKy7zp6GghDR/ASPjsNpy4lZcQH00An9dfx/JxkBh8lO07lpc+YukeSvME393GFZLTzV494SDz8ukKEn0WkpoZFVwKNhVAE65NpvrKOQTc7j9mkLZf7VYcPruFf42dc8nH+ucSRpaL8bUagnZCFqTGgCYa+gpfpxNbkgvVT6cnkZkmudELhex9jLT1n+L36OHfmB7pa1ONoLUqdLLSe5rMzRijwBUbohJVQqxisFM/E2pZPW5OT6AWfR3JOfOrmPSHapVS72EVgcQwWcxFQ7KzRU9Y4TRZCZmRNCBVdR2V5OAahssIECQid6p3EGRdx+lOwGjLDr78AG+ZXg= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c042f1b-c529-4ccb-da42-08d6f8cacf4b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 17:38:46.3151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3177 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 17:38:55 -0000 SGksDQoNClNvcnJ5LCBJIGZvcmdvdCB0byBzZW5kIHRoZSBmb2xsb3ctdXAgZS1tYWlsIGFmdGVy IHN1Ym1pdHRpbmcgdGhlIC0wMSB2ZXJzaW9uLg0KDQpUaGVyZSBhcmUgbm8gY2hhbmdlcyBpbiB0 aGUgLTAxIHZlcnNpb24uIEl0IHdhcyBzdWJtaXR0ZWQgZHVlIHRvIGV4cGlyYXRpb24gb2YgdGhl IHByZXZpb3VzIHZlcnNpb24uDQoNCkkgaW50ZW5kIHRvIHB1dCBiYWNrIG15IGZvY3VzIG9uIHRo aXMgZHJhZnQgYWZ0ZXIgdGhlIHN1bW1lciB2YWN0aW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQrvu79PbiAyNC8wNi8yMDE5LCAxOC41MCwgInNpcGNvcmUgb24gYmVoYWxmIG9mIFBhdWwg S3l6aXZhdCIgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcGt5eml2YXRA YWx1bS5taXQuZWR1PiB3cm90ZToNCg0KICAgIFNvbWVob3cgSSBuZXZlciBub3RpY2VkIHRoZSBw dWJsaWNhdGlvbiBvZiB0aGUgLTAwIG9mIHRoaXMuDQogICAgTG9va2luZyBiYWNrLCBJIG5vdyBz ZWUgdGhhdCBpdCB3YXMgcHVibGlzaGVkIGFuZCBhZG9wdGVkIGFzIGEgd2cgZHJhZnQgDQogICAg YmFjayBpbiBEZWNlbWJlci4gQnV0IEkgZG9uJ3Qgc2VlIGFueSBkaXNjdXNzaW9uIG9mIGl0IGF0 IGFsbC4NCiAgICANCiAgICBBbmQgbG9va2luZyBhdCB0aGUgZGlmZiBiZXR3ZWVuIC0wMSBhbmQg cmZjNDAyOCBJIGRvbid0IHNlZSBhbnkgY2hhbmdlcyANCiAgICB0aGF0IHdvdWxkIGV4cGxhaW4g d2h5IGl0IGlzIGJlaW5nIGlzc3VlZC4gVGhlIG9ubHkgY2hhbmdlcyBJIHNlZSBzZWVtIA0KICAg IHRvIGJlIGFydGlmYWN0cyBvZiByZWZvcm1hdHRpbmcgaXQgYWNjb3JkaW5nIHRvIGN1cnJlbnQg Y29udmVudGlvbnMuDQogICAgDQogICAgV2hhdCBpcyB0aGVuIGludGVudCBpbiBtYWtpbmcgdGhp cyB1cGRhdGU/DQogICAgDQogICAgCVRoYW5rcywNCiAgICAJUGF1bA0KICAgIA0KICAgIE9uIDYv MjQvMTkgMzo0NiBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4gDQog ICAgPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSBXRyBvZiB0aGUgSUVU Ri4NCiAgICA+IA0KICAgID4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogU2Vzc2lvbiBUaW1l cnMgaW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KICAgID4gICAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogQ2hyaXN0ZXIgSG9sbWJlcmcNCiAgICA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN0ZXZlIERvbm92YW4NCiAgICA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEpvbmF0aGFuIFJvc2VuYmVyZw0KICAgID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtc2lwY29yZS1yZmM0MDI4YmlzLTAxLnR4dA0KICAgID4gCVBhZ2VzICAgICAgICAgICA6 IDI2DQogICAgPiAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0wNi0yNA0KICAgID4gDQogICAgPiBB YnN0cmFjdDoNCiAgICA+ICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRv IHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCiAgICA+ICAgICAoU0lQKS4gIFRoaXMg ZXh0ZW5zaW9uIGFsbG93cyBmb3IgYSBwZXJpb2RpYyByZWZyZXNoIG9mIFNJUCBzZXNzaW9ucw0K ICAgID4gICAgIHRocm91Z2ggYSByZS1JTlZJVEUgb3IgVVBEQVRFIHJlcXVlc3QuICBUaGUgcmVm cmVzaCBhbGxvd3MgYm90aCB1c2VyDQogICAgPiAgICAgYWdlbnRzIGFuZCBwcm94aWVzIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBTSVAgc2Vzc2lvbiBpcyBzdGlsbA0KICAgID4gICAgIGFjdGl2 ZS4gIFRoZSBleHRlbnNpb24gZGVmaW5lcyB0d28gbmV3IGhlYWRlciBmaWVsZHM6IFNlc3Npb24t DQogICAgPiAgICAgRXhwaXJlcywgd2hpY2ggY29udmV5cyB0aGUgbGlmZXRpbWUgb2YgdGhlIHNl c3Npb24sIGFuZCBNaW4tU0UsIHdoaWNoDQogICAgPiAgICAgY29udmV5cyB0aGUgbWluaW11bSBh bGxvd2VkIHZhbHVlIGZvciB0aGUgc2Vzc2lvbiB0aW1lci4NCiAgICA+IA0KICAgID4gDQogICAg PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAg ICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1y ZmM0MDI4YmlzLw0KICAgID4gDQogICAgPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQogICAgPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zaXBjb3JlLXJmYzQwMjhiaXMtMDENCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJmYzQwMjhiaXMtMDENCiAgICA+IA0K ICAgID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K ICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lwY29y ZS1yZmM0MDI4YmlzLTAxDQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAgID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgID4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQog ICAgPiBzaXBjb3JlQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUNCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAg ICBzaXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQogICAgDQoNCg== From nobody Mon Jun 24 11:35:57 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7D12006B for ; Mon, 24 Jun 2019 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-jM3775swoV for ; Mon, 24 Jun 2019 11:35:52 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CF4120059 for ; Mon, 24 Jun 2019 11:35:51 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5OIZkru013991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Jun 2019 14:35:47 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> From: Paul Kyzivat Message-ID: <993c4ac8-e65d-aef1-f4f6-4e4fdc2cdf4e@alum.mit.edu> Date: Mon, 24 Jun 2019 14:35:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 18:35:55 -0000 On 6/24/19 1:38 PM, Christer Holmberg wrote: > Hi, > > Sorry, I forgot to send the follow-up e-mail after submitting the -01 version. > > There are no changes in the -01 version. It was submitted due to expiration of the previous version. > > I intend to put back my focus on this draft after the summer vaction. Ah. So this is *intended* to be functionally equivalent to RFC4028, and a starting point for the revisions to come. OK. Thanks, Paul > Regards, > > Christer > > On 24/06/2019, 18.50, "sipcore on behalf of Paul Kyzivat" wrote: > > Somehow I never noticed the publication of the -00 of this. > Looking back, I now see that it was published and adopted as a wg draft > back in December. But I don't see any discussion of it at all. > > And looking at the diff between -01 and rfc4028 I don't see any changes > that would explain why it is being issued. The only changes I see seem > to be artifacts of reformatting it according to current conventions. > > What is then intent in making this update? > > Thanks, > Paul > > On 6/24/19 3:46 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > > > Title : Session Timers in the Session Initiation Protocol (SIP) > > Authors : Christer Holmberg > > Steve Donovan > > Jonathan Rosenberg > > Filename : draft-ietf-sipcore-rfc4028bis-01.txt > > Pages : 26 > > Date : 2019-06-24 > > > > Abstract: > > This document defines an extension to the Session Initiation Protocol > > (SIP). This extension allows for a periodic refresh of SIP sessions > > through a re-INVITE or UPDATE request. The refresh allows both user > > agents and proxies to determine whether the SIP session is still > > active. The extension defines two new header fields: Session- > > Expires, which conveys the lifetime of the session, and Min-SE, which > > conveys the minimum allowed value for the session timer. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-01 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From nobody Mon Jun 24 11:40:00 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976691200E5 for ; Mon, 24 Jun 2019 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2s71tovnTjd for ; Mon, 24 Jun 2019 11:39:56 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::611]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD86120059 for ; Mon, 24 Jun 2019 11:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJnjgRtWIRj1j0orlqg00e/Dj5L7hu45XnZy3/TuAm4=; b=DJNFwp28dQ4Ams5nybcmQ2IzgsS+Sk5/hlqWKQeHeyKOhhAF9y3RhrT1trMh89pc+simIQxEL7WtwiKVpv0nn1hpFhJB70c3ml14R1SIcgG2R219cH04fbpvQwyaSVhv5jqQ0+5moaWXAaXovMrW4i/+KkuDwtlsPN7in/0UR6Y= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4345.eurprd07.prod.outlook.com (20.176.167.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Mon, 24 Jun 2019 18:39:53 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 18:39:53 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt Thread-Index: AQHVKmEFvyFpYHLlwEWxtjQeSyBOPaaq9C4AgABQsoD//92kAIAAM28A Date: Mon, 24 Jun 2019 18:39:52 +0000 Message-ID: References: <156136237184.17571.3756644280885220431@ietfa.amsl.com> <86574eb2-d99f-7957-670d-1e90a4879568@alum.mit.edu> <993c4ac8-e65d-aef1-f4f6-4e4fdc2cdf4e@alum.mit.edu> In-Reply-To: <993c4ac8-e65d-aef1-f4f6-4e4fdc2cdf4e@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c322ec37-1eed-49ee-ed56-08d6f8d358ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4345; x-ms-traffictypediagnostic: HE1PR07MB4345: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(136003)(366004)(189003)(199004)(3846002)(86362001)(305945005)(6116002)(26005)(6512007)(966005)(44832011)(229853002)(68736007)(102836004)(7736002)(186003)(99286004)(6306002)(53546011)(66574012)(76176011)(53936002)(2501003)(2906002)(25786009)(6436002)(2171002)(5660300002)(478600001)(14454004)(66556008)(71190400001)(73956011)(33656002)(11346002)(446003)(91956017)(81156014)(14444005)(81166006)(66476007)(76116006)(66946007)(256004)(6506007)(71200400001)(6486002)(66446008)(64756008)(8676002)(66066001)(316002)(476003)(2616005)(36756003)(8936002)(6246003)(110136005)(58126008)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4345; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qKDXJXxi+kX2mzxMqyVlHrv7k3C1lhHPHoJdALxZ5DPcn+8ZHX+DDk7efcgjIXvTh8YSzDfIrPoCB3zsZbC6Q62c3+jgIg4XQzOVpmKgcxb7Vdk/WhHxGgLuHvPMaezsOqUuWiku+5b1cTLHLs68bfCaCd7hQYpOdkDK97rzCKKUt1Lh3gDPDi8QEb4/V0F5dEwTUppD+7iIWo+NSBSsTcT+YRgqAuKJj5YDcdAtBV7Vgxw9aLlS20bZO/+KtVkE/yAbsOKVlF/aNuK4DJLY1nAN3SAuXdt6vPrnp2lcYKW3Lsw7sw4v33Ia4MlY9Bk82P8EpKLsMF6jJ6CooGIsDZvmso6YS9nnuEmLOjHyoQdlfypBT/Elug0F3hQKOqlsLDJJXajP61tN3LlGmaAysJnR7drv6XXpEaE4KXA6EG0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c322ec37-1eed-49ee-ed56-08d6f8d358ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 18:39:52.9566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4345 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 18:39:59 -0000 SGksDQoNCj4+IEkgaW50ZW5kIHRvIHB1dCBiYWNrIG15IGZvY3VzIG9uIHRoaXMgZHJhZnQgYWZ0 ZXIgdGhlIHN1bW1lciB2YWN0aW9uLg0KPiAgICANCj4gQWguIFNvIHRoaXMgaXMgKmludGVuZGVk KiB0byBiZSBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB0byBSRkM0MDI4LCBhbmQgDQo+IGEgc3Rh cnRpbmcgcG9pbnQgZm9yIHRoZSByZXZpc2lvbnMgdG8gY29tZS4gT0suDQoNCkNvcnJlY3QuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCiAgIA0KDQoNCg0KICAgID4gT24gMjQvMDYvMjAxOSwg MTguNTAsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBQYXVsIEt5eml2YXQiIDxzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQog ICAgPiANCiAgICA+ICAgICAgU29tZWhvdyBJIG5ldmVyIG5vdGljZWQgdGhlIHB1YmxpY2F0aW9u IG9mIHRoZSAtMDAgb2YgdGhpcy4NCiAgICA+ICAgICAgTG9va2luZyBiYWNrLCBJIG5vdyBzZWUg dGhhdCBpdCB3YXMgcHVibGlzaGVkIGFuZCBhZG9wdGVkIGFzIGEgd2cgZHJhZnQNCiAgICA+ICAg ICAgYmFjayBpbiBEZWNlbWJlci4gQnV0IEkgZG9uJ3Qgc2VlIGFueSBkaXNjdXNzaW9uIG9mIGl0 IGF0IGFsbC4NCiAgICA+ICAgICAgDQogICAgPiAgICAgIEFuZCBsb29raW5nIGF0IHRoZSBkaWZm IGJldHdlZW4gLTAxIGFuZCByZmM0MDI4IEkgZG9uJ3Qgc2VlIGFueSBjaGFuZ2VzDQogICAgPiAg ICAgIHRoYXQgd291bGQgZXhwbGFpbiB3aHkgaXQgaXMgYmVpbmcgaXNzdWVkLiBUaGUgb25seSBj aGFuZ2VzIEkgc2VlIHNlZW0NCiAgICA+ICAgICAgdG8gYmUgYXJ0aWZhY3RzIG9mIHJlZm9ybWF0 dGluZyBpdCBhY2NvcmRpbmcgdG8gY3VycmVudCBjb252ZW50aW9ucy4NCiAgICA+ICAgICAgDQog ICAgPiAgICAgIFdoYXQgaXMgdGhlbiBpbnRlbnQgaW4gbWFraW5nIHRoaXMgdXBkYXRlPw0KICAg ID4gICAgICANCiAgICA+ICAgICAgCVRoYW5rcywNCiAgICA+ICAgICAgCVBhdWwNCiAgICA+ICAg ICAgDQogICAgPiAgICAgIE9uIDYvMjQvMTkgMzo0NiBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIHdyb3RlOg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KICAgID4gICAgICA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlc3Np b24gSW5pdGlhdGlvbiBQcm90b2NvbCBDb3JlIFdHIG9mIHRoZSBJRVRGLg0KICAgID4gICAgICA+ DQogICAgPiAgICAgID4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogU2Vzc2lvbiBUaW1lcnMg aW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KICAgID4gICAgICA+ICAg ICAgICAgIEF1dGhvcnMgICAgICAgICA6IENocmlzdGVyIEhvbG1iZXJnDQogICAgPiAgICAgID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RldmUgRG9ub3Zhbg0KICAgID4gICAgICA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmF0aGFuIFJvc2VuYmVyZw0KICAgID4gICAgICA+ IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNpcGNvcmUtcmZjNDAyOGJpcy0wMS50eHQN CiAgICA+ICAgICAgPiAJUGFnZXMgICAgICAgICAgIDogMjYNCiAgICA+ICAgICAgPiAJRGF0ZSAg ICAgICAgICAgIDogMjAxOS0wNi0yNA0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gQWJzdHJh Y3Q6DQogICAgPiAgICAgID4gICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24g dG8gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbA0KICAgID4gICAgICA+ICAgICAoU0lQ KS4gIFRoaXMgZXh0ZW5zaW9uIGFsbG93cyBmb3IgYSBwZXJpb2RpYyByZWZyZXNoIG9mIFNJUCBz ZXNzaW9ucw0KICAgID4gICAgICA+ICAgICB0aHJvdWdoIGEgcmUtSU5WSVRFIG9yIFVQREFURSBy ZXF1ZXN0LiAgVGhlIHJlZnJlc2ggYWxsb3dzIGJvdGggdXNlcg0KICAgID4gICAgICA+ICAgICBh Z2VudHMgYW5kIHByb3hpZXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIFNJUCBzZXNzaW9uIGlz IHN0aWxsDQogICAgPiAgICAgID4gICAgIGFjdGl2ZS4gIFRoZSBleHRlbnNpb24gZGVmaW5lcyB0 d28gbmV3IGhlYWRlciBmaWVsZHM6IFNlc3Npb24tDQogICAgPiAgICAgID4gICAgIEV4cGlyZXMs IHdoaWNoIGNvbnZleXMgdGhlIGxpZmV0aW1lIG9mIHRoZSBzZXNzaW9uLCBhbmQgTWluLVNFLCB3 aGljaA0KICAgID4gICAgICA+ICAgICBjb252ZXlzIHRoZSBtaW5pbXVtIGFsbG93ZWQgdmFsdWUg Zm9yIHRoZSBzZXNzaW9uIHRpbWVyLg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4NCiAgICA+ ICAgICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCiAgICA+ICAgICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNpcGNvcmUtcmZjNDAyOGJpcy8NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IFRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+ICAgICAgPiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJmYzQwMjhiaXMt MDENCiAgICA+ICAgICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtc2lwY29yZS1yZmM0MDI4YmlzLTAxDQogICAgPiAgICAgID4NCiAgICA+ICAgICAg PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAg PiAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lw Y29yZS1yZmM0MDI4YmlzLTAxDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPg0KICAgID4gICAg ICA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+ICAgICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4g ICAgICA+DQogICAgPiAgICAgID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgID4gICAgICA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgICA+IHNpcGNvcmUgbWFp bGluZyBsaXN0DQogICAgPiAgICAgID4gc2lwY29yZUBpZXRmLm9yZw0KICAgID4gICAgICA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgID4gICAgICA+ DQogICAgPiAgICAgIA0KICAgID4gICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4gICAgICBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICAgID4g ICAgICBzaXBjb3JlQGlldGYub3JnDQogICAgPiAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgID4gICAgICANCiAgICA+IA0KICAgIA0KICAgIA0K DQo= From nobody Mon Jun 24 13:37:34 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD61200B2 for ; Mon, 24 Jun 2019 13:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDMBkiQb24nn for ; Mon, 24 Jun 2019 13:37:30 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251D0120041 for ; Mon, 24 Jun 2019 13:37:29 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5OKbRop022958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Jun 2019 16:37:28 -0400 To: sipcore@ietf.org References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> Date: Mon, 24 Jun 2019 16:37:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 20:37:33 -0000 On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > All, > > We have submitted a new version of the draft that adds more details and > we believe address the comments provided so far. > Please, take a look and let us know what you think. I think this still has things a bit backwards. Step [07] in 2.1.2 seems out of place. Why would the UA know to prompt the user at this point, and if it did, how would the user know *which* credentials to provide. With Digest, you would never prompt for credentials until you have received a 401 with WWW-Authenticate. The Realm in that is then displayed to the user as indication of which credentials he should supply. I would expect something similar with Bearer. Presumably this will tell me "Google", or "Facebook", or whatever. In your case these may be alternatives that the user can choose among. So I think you need more explanation about how the alternatives are presented. Don't just pass the buck to 3261 on the WWW-Authenticate parameters. You have ones that aren't mentioned there, and the usage is probably somewhat different. After this has been done once, the UA can then cache the credentials for while and preemptively supply them in future registration requests. With Digest there are some guidelines on when to preemptively try them and when not. I would expect something similar for Bearer. There are probably some security reasons not to preemptively send the credentials to every server the UA attempts to connect to. As long as credentials are only being used for REGISTER this probably isn't a problem. But it certainly is possible for server to request credentials for requests other than REGISTER. I'd like to see a discussion of that too. Thanks, Paul > Regards, >  Rifaat > > > On Mon, Jun 24, 2019 at 12:55 PM > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG > of the IETF. > >         Title           : Third-Party Token-based Authentication > and Authorization for Session Initiation Protocol (SIP) >         Authors         : Rifaat Shekh-Yusef >                           Christer Holmberg >                           Victor Pascual >         Filename        : draft-ietf-sipcore-sip-token-authnz-01.txt >         Pages           : 11 >         Date            : 2019-06-24 > > Abstract: >    This document defines a mechanism for SIP, that is based on the > OAuth >    2.0 and OpenID Connect Core 1.0 specifications, to enable the >    delegation of the user authentication and SIP registration >    authorization to a dedicated third-party entity that is separate > from >    the SIP network elements that provide the SIP service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 > https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 25 06:06:02 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB81120168 for ; Tue, 25 Jun 2019 06:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or8q90qwexBK for ; Tue, 25 Jun 2019 06:05:59 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F6412012A for ; Tue, 25 Jun 2019 06:05:59 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id r185so2805395iod.6 for ; Tue, 25 Jun 2019 06:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1gBtNcieMRNt/DxADId2YxBNNk1M6Ou2Z/RDKcpsfHs=; b=JuWTWlatlukp3n0T9nJ2+bU9E2GqQC9GJO8z7KUslaDbqQCYerD5Jgeuya5G8YTROQ XfC+DVadTCLV3w6d6kIuWXvp35cC/JJvzdrbilnM0HhMI5Fw8Ucq2omDHHDyMZ/93Q9c 3M7LfnbGUPKyVlgODEj57cyOn9mwLEJ4o3sr85w+VYoiSewZnPeW6PCJZqYSNer8j69O qRzM1mVao6uu46h0Y2yzW3627l6171epBwYAcYRVNp7WW0+CtAofathkbGVkrTiUxGE0 Fx4/+sGHKtOpXaq2XHpkioa1M9vaiFo1Ao1d18zsbjDoWDuZtfaZ0LCW9/ZWF3iV934G UTKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gBtNcieMRNt/DxADId2YxBNNk1M6Ou2Z/RDKcpsfHs=; b=UlMrFK+61mQjdjTxRg6fQPdvYalCJl4CVgkosMtis41jJom1Nguo59xY7vJmXqOF0Y 6akglNtBupJHusQ8k1D5JSK0VVAAOw1/B2KG9U2mDY7jDF+FosoQppRj/j9IzWLmQruR Cx5/0y5ALd25F2TkdI+ci8NdCHK1hpiATTh5R0IO39WEwcDeLu8dHBpCuD0aMO0dYq76 WlOzXX+HmnXjVnpMrNc3Px4EvMbDmc4FhYz8WxCnGNRbESCkee3wYaGDUzgJq36SF54h r9wfjSTqDUNBFoxIaGtD+YqBJIT87rvkjlGYM77W9jaBC79TdMxYxpCfvQAa1KhzeTmO 2nPg== X-Gm-Message-State: APjAAAWe36LEEFFyrzXmPNBG2UIfOBxLrZQTmNzMRMOzvusTTwW539bw C+q41Itdg2NXqsNtkIPSzYA76098APbXbEELQVE= X-Google-Smtp-Source: APXvYqzsiKMXV/LZoNGuVC43c4VnlTCQuLaJyNTC5gha7bJfUmAv7vdkryWg5rSClb83wdnsE68FYt5LDCvPx+hG5Po= X-Received: by 2002:a6b:9257:: with SMTP id u84mr42782125iod.278.1561467958228; Tue, 25 Jun 2019 06:05:58 -0700 (PDT) MIME-Version: 1.0 References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> In-Reply-To: <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> From: Rifaat Shekh-Yusef Date: Tue, 25 Jun 2019 09:05:46 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000fa7d38058c2596f5" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 13:06:01 -0000 --000000000000fa7d38058c2596f5 Content-Type: text/plain; charset="UTF-8" Thanks Paul! Please, see my replies inline. Regards, Rifaat On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat wrote: > On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > > All, > > > > We have submitted a new version of the draft that adds more details and > > we believe address the comments provided so far. > > Please, take a look and let us know what you think. > > I think this still has things a bit backwards. Step [07] in 2.1.2 seems > out of place. Why would the UA know to prompt the user at this point, > and if it did, how would the user know *which* credentials to provide. > > Yeah, this was a copy and paste from the previous flow. I agree that the prompt should happen after the 401 response. I will fix that. > With Digest, you would never prompt for credentials until you have > received a 401 with WWW-Authenticate. The Realm in that is then > displayed to the user as indication of which credentials he should supply. > > I would expect something similar with Bearer. Presumably this will tell > me "Google", or "Facebook", or whatever. In your case these may be > alternatives that the user can choose among. So I think you need more > explanation about how the alternatives are presented. Don't just pass > the buck to 3261 on the WWW-Authenticate parameters. You have ones that > aren't mentioned there, and the usage is probably somewhat different. > > The UA gets redirected to an *Authorization Server (AS)*, which could in theory redirect the UA to an *IdP *server to authenticate the user. But, this is completely out of scope for this document, as this follows a well-defined HTTP-based OAuth mechanism. > After this has been done once, the UA can then cache the credentials for > while and preemptively supply them in future registration requests. With > Digest there are some guidelines on when to preemptively try them and > when not. I would expect something similar for Bearer. There are > probably some security reasons not to preemptively send the credentials > to every server the UA attempts to connect to. As long as credentials > are only being used for REGISTER this probably isn't a problem. But it > certainly is possible for server to request credentials for requests > other than REGISTER. I'd like to see a discussion of that too. > > The UA never sends any credentials to the registrar, only to the AS/IdP. The UA will only send the *Access Token *to the registrar which will be able to validate that the token was issued by a trusted AS. Regards, Rifaat > Thanks, > Paul > > > > Regards, > > Rifaat > > > > > > On Mon, Jun 24, 2019 at 12:55 PM > > wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session Initiation Protocol Core WG > > of the IETF. > > > > Title : Third-Party Token-based Authentication > > and Authorization for Session Initiation Protocol (SIP) > > Authors : Rifaat Shekh-Yusef > > Christer Holmberg > > Victor Pascual > > Filename : draft-ietf-sipcore-sip-token-authnz-01.txt > > Pages : 11 > > Date : 2019-06-24 > > > > Abstract: > > This document defines a mechanism for SIP, that is based on the > > OAuth > > 2.0 and OpenID Connect Core 1.0 specifications, to enable the > > delegation of the user authentication and SIP registration > > authorization to a dedicated third-party entity that is separate > > from > > the SIP network elements that provide the SIP service. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 > > https://datatracker.ietf. > .org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > < > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org > > . > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000fa7d38058c2596f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Paul!

Please, s= ee my replies inline.

Regards,
=C2=A0Rif= aat


On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:=
On 6/24/19 12:5= 8 PM, Rifaat Shekh-Yusef wrote:
> All,
>
> We have submitted a new version of the draft that adds more details an= d
> we believe address the comments provided so far.
> Please, take a look and let us know what you think.

I think this still has things a bit backwards. Step [07] in 2.1.2 seems out of place. Why would the UA know to prompt the user at this point,
and if it did, how would the user know *which* credentials to provide.

Yeah, this was a copy and paste from the previous flo= w.
I agree that the prompt should happen after the 401 response. = I will fix that.

=C2=A0
With Digest, you would never prompt for credentials until you have
received a 401 with WWW-Authenticate. The Realm in that is then
displayed to the user as indication of which credentials he should supply.<= br>
I would expect something similar with Bearer. Presumably this will tell me "Google", or "Facebook", or whatever. In your case t= hese may be
alternatives that the user can choose among. So I think you need more
explanation about how the alternatives are presented. Don't just pass <= br> the buck to 3261 on the WWW-Authenticate parameters. You have ones that aren't mentioned there, and the usage is probably somewhat different.

The UA gets redirected to an Author= ization Server (AS), which could in theory redirect the UA to an IdP= server to authenticate the user.
But, this is completely out= of scope for this document, as this follows a well-defined HTTP-based OAut= h mechanism.

=C2=A0
After this has been done once, the UA can then cache the credentials for while and preemptively supply them in future registration requests. With Digest there are some guidelines on when to preemptively try them and
when not. I would expect something similar for Bearer. There are
probably some security reasons not to preemptively send the credentials to every server the UA attempts to connect to. As long as credentials
are only being used for REGISTER this probably isn't a problem. But it =
certainly is possible for server to request credentials for requests
other than REGISTER. I'd like to see a discussion of that too.


The UA never sends any credentials to = the registrar, only to the AS/IdP.
The UA will only send the A= ccess Token to the registrar which will be able to validate that the to= ken was issued by a trusted AS.

Regards,
=C2=A0Rifaat

=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
> On Mon, Jun 24, 2019 at 12:55 PM <internet-drafts@ietf.org
> <mailto:internet-drafts@ietf.org>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0A New Internet-Draft is available from the on-line = Internet-Drafts
>=C2=A0 =C2=A0 =C2=A0directories.
>=C2=A0 =C2=A0 =C2=A0This draft is a work item of the Session Initiation= Protocol Core WG
>=C2=A0 =C2=A0 =C2=A0of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Third-Party Token-based Authentication
>=C2=A0 =C2=A0 =C2=A0and Authorization for Session Initiation Protocol (= SIP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: Rifaat Shekh-Yusef
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer Holmberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Victor Pascual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 = =C2=A0 =C2=A0 : draft-ietf-sipcore-sip-token-authnz-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : 2019-06-24
>
>=C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines a mechanism for= SIP, that is based on the
>=C2=A0 =C2=A0 =C2=A0OAuth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.0 and OpenID Connect Core 1.0 speci= fications, to enable the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delegation of the user authentication= and SIP registration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authorization to a dedicated third-pa= rty entity that is separate
>=C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the SIP network elements that provide= the SIP service.
>
>
>=C2=A0 =C2=A0 =C2=A0The IETF datatracker status page for this draft is:=
>=C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
>
>=C2=A0 =C2=A0 =C2=A0There are also htmlized versions available at:
>=C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01
>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf..org/doc/html/draft-ie= tf-sipcore-sip-token-authnz-01
>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-auth= nz-01>
>
>=C2=A0 =C2=A0 =C2=A0A diff from the previous version is available at: >=C2=A0 =C2=A0 =C2=A0ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-token-authnz-01
>
>
>=C2=A0 =C2=A0 =C2=A0Please note that it may take a couple of minutes fr= om the time of
>=C2=A0 =C2=A0 =C2=A0submission
>=C2=A0 =C2=A0 =C2=A0until the htmlized version and diff are available a= t to= ols.ietf.org
>=C2=A0 =C2=A0 =C2=A0<http://tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0Internet-Drafts are also available by anonymous FTP= at:
>=C2=A0 =C2=A0 =C2=A0ftp://ftp.ietf.org/internet-drafts/ >
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore<= br> >

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000fa7d38058c2596f5-- From nobody Tue Jun 25 07:48:08 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9401D12033C for ; Tue, 25 Jun 2019 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LzM4A5roU9e for ; Tue, 25 Jun 2019 07:48:02 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE87712031C for ; Tue, 25 Jun 2019 07:47:39 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5PElaix029052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Jun 2019 10:47:37 -0400 To: Rifaat Shekh-Yusef Cc: SIPCORE References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> From: Paul Kyzivat Message-ID: <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> Date: Tue, 25 Jun 2019 10:47:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 14:48:06 -0000 On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote: > Thanks Paul! > > Please, see my replies inline. > > Regards, >  Rifaat > > > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat > wrote: > > On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > > All, > > > > We have submitted a new version of the draft that adds more > details and > > we believe address the comments provided so far. > > Please, take a look and let us know what you think. > > I think this still has things a bit backwards. Step [07] in 2.1.2 seems > out of place. Why would the UA know to prompt the user at this point, > and if it did, how would the user know *which* credentials to provide. > > Yeah, this was a copy and paste from the previous flow. > I agree that the prompt should happen after the 401 response. I will fix > that. Thx > With Digest, you would never prompt for credentials until you have > received a 401 with WWW-Authenticate. The Realm in that is then > displayed to the user as indication of which credentials he should > supply. > > I would expect something similar with Bearer. Presumably this will tell > me "Google", or "Facebook", or whatever. In your case these may be > alternatives that the user can choose among. So I think you need more > explanation about how the alternatives are presented. Don't just pass > the buck to 3261 on the WWW-Authenticate parameters. You have ones that > aren't mentioned there, and the usage is probably somewhat different. > > > The UA gets redirected to an *Authorization Server (AS)*, which could in > theory redirect the UA to an *IdP *server to authenticate the user. > But, this is completely out of scope for this document, as this follows > a well-defined HTTP-based OAuth mechanism. OK, as long as it somehow takes account of the server that requires authentication and the type(s) of authentication it is willing to accept. You can't rely on the UAC being psychic about what credentials are required. > After this has been done once, the UA can then cache the credentials > for > while and preemptively supply them in future registration requests. > With > Digest there are some guidelines on when to preemptively try them and > when not. I would expect something similar for Bearer. There are > probably some security reasons not to preemptively send the credentials > to every server the UA attempts to connect to. As long as credentials > are only being used for REGISTER this probably isn't a problem. But it > certainly is possible for server to request credentials for requests > other than REGISTER. I'd like to see a discussion of that too. > > > The UA never sends any credentials to the registrar, only to the AS/IdP. > The UA will only send the *Access Token *to the registrar which will be > able to validate that the token was issued by a trusted AS. That is details. What the UA provides to the registrar are credentials in a functional sense, even if they are passed in an indirect way. It still requires a security analysis, though the conclusions might be somewhat different. I *guess* that it is still a bad idea to hand out the access token indiscriminately to everyone you connect to. Thanks, Paul > Regards, >  Rifaat > >         Thanks, >         Paul > > > > Regards, > >   Rifaat > > > > > > On Mon, Jun 24, 2019 at 12:55 PM > > >> wrote: > > > > > >     A New Internet-Draft is available from the on-line > Internet-Drafts > >     directories. > >     This draft is a work item of the Session Initiation Protocol > Core WG > >     of the IETF. > > > >              Title           : Third-Party Token-based Authentication > >     and Authorization for Session Initiation Protocol (SIP) > >              Authors         : Rifaat Shekh-Yusef > >                                Christer Holmberg > >                                Victor Pascual > >              Filename        : > draft-ietf-sipcore-sip-token-authnz-01.txt > >              Pages           : 11 > >              Date            : 2019-06-24 > > > >     Abstract: > >         This document defines a mechanism for SIP, that is based > on the > >     OAuth > >         2.0 and OpenID Connect Core 1.0 specifications, to enable the > >         delegation of the user authentication and SIP registration > >         authorization to a dedicated third-party entity that is > separate > >     from > >         the SIP network elements that provide the SIP service. > > > > > >     The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > >     There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 > > > https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > >   > > > >     A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 > > > > > >     Please note that it may take a couple of minutes from the time of > >     submission > >     until the htmlized version and diff are available at > tools.ietf.org > >     . > > > >     Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > >     _______________________________________________ > >     sipcore mailing list > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 25 10:32:22 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FF5120133 for ; Tue, 25 Jun 2019 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQmzG46K9mdV for ; Tue, 25 Jun 2019 10:32:17 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6EE120075 for ; Tue, 25 Jun 2019 10:32:16 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id u19so985935ior.9 for ; Tue, 25 Jun 2019 10:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Di10n3IBUVPFWUp+LCqnbHK5u4RcUC35vAwGcatgnIc=; b=JncO5zGT5fJKDBB2+jMzZG2RpJSLxJOXYgxSCTXLWvlBJpVgSFhecPWHptQyN5OFhk g+hKcR9tRSXHH6Aqfj2a4lgwbIIB8XM3tYhAT6eRjix8NnHleNDy6hCPFzJQHe28MrtF N/2JEUGdU3b01g4kz9OaUs5HmVgcN5FwyzKYY7O4O3Ptkf9KJ5R1HNnJKrNyRurCxpE3 YYdehSm36fjX3zMEti3AKZGTim4G02VXTGfLq4eh6gFZL3WJLeZNjcKlk7uxEKXgMpuh oGkpdJ5B/TWSz7IcdRhSstmz/tBAUAonbmc7DIBzDhdIeNZZXQn1ZNCcOIzIS81VUpgH 1EEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Di10n3IBUVPFWUp+LCqnbHK5u4RcUC35vAwGcatgnIc=; b=f9xfrDxLuSJF2l/MaW+PUdu0Tu0FAo84vPNRuA2Fv5k5JzMvdK293uFBZg8kPa3634 H/nVg+0FwFkScbXBLlo4XLeImlb4UIr8q2aJDXuuG7Nds8XEw8i9GvUkeoOOPl0srEnd ZXfVMAErNS6vAwCfnvzpOQT1mkFoHhENdUs4Jf2vcXVRYAoz3qpJYEGgsl2zA7CloOzx bEZ5PxA+gAFVrb/jmkBLr+ef6b5Ewb01r5D2E6o7vct4RSHh0ejSrDkX4/reXlSSSneR UO8DjshI4E0H1WIOheVQU7hmdQZF7CifKpNrIZgJU9Zda1/kIVCZNrrwnQxNEFkl7wZr l3DQ== X-Gm-Message-State: APjAAAU1oi/w3CSDMdccelJgaQ+/2Tj/5qEhZ/axlv1Jb1L2p1XRPftX aToG1xqrSVCj3PiI+J3q79MTNQMeinm1tpD003k= X-Google-Smtp-Source: APXvYqw4kTB5WQNRJ3mCup8C9XfntVCN4pOVQdGfe6UxGDDgdUYD1kVuf7zAZCXNWKsNHdABcAB8dj0cJ8rJwPZaGzg= X-Received: by 2002:a6b:9257:: with SMTP id u84mr44053211iod.278.1561483936076; Tue, 25 Jun 2019 10:32:16 -0700 (PDT) MIME-Version: 1.0 References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> In-Reply-To: <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> From: Rifaat Shekh-Yusef Date: Tue, 25 Jun 2019 13:32:04 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000551a8c058c294f1f" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 17:32:21 -0000 --000000000000551a8c058c294f1f Content-Type: text/plain; charset="UTF-8" On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat wrote: > On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote: > > Thanks Paul! > > > > Please, see my replies inline. > > > > Regards, > > Rifaat > > > > > > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat > > wrote: > > > > On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > > > All, > > > > > > We have submitted a new version of the draft that adds more > > details and > > > we believe address the comments provided so far. > > > Please, take a look and let us know what you think. > > > > I think this still has things a bit backwards. Step [07] in 2.1.2 > seems > > out of place. Why would the UA know to prompt the user at this point, > > and if it did, how would the user know *which* credentials to > provide. > > > > Yeah, this was a copy and paste from the previous flow. > > I agree that the prompt should happen after the 401 response. I will fix > > that. > > Thx > > > With Digest, you would never prompt for credentials until you have > > received a 401 with WWW-Authenticate. The Realm in that is then > > displayed to the user as indication of which credentials he should > > supply. > > > > I would expect something similar with Bearer. Presumably this will > tell > > me "Google", or "Facebook", or whatever. In your case these may be > > alternatives that the user can choose among. So I think you need more > > explanation about how the alternatives are presented. Don't just pass > > the buck to 3261 on the WWW-Authenticate parameters. You have ones > that > > aren't mentioned there, and the usage is probably somewhat different. > > > > > > The UA gets redirected to an *Authorization Server (AS)*, which could in > > theory redirect the UA to an *IdP *server to authenticate the user. > > But, this is completely out of scope for this document, as this follows > > a well-defined HTTP-based OAuth mechanism. > > OK, as long as it somehow takes account of the server that requires > authentication and the type(s) of authentication it is willing to > accept. You can't rely on the UAC being psychic about what credentials > are required. > > Notice that the challenge provided in the WWW-Authenticate response, defined in section 3, includes many details that could be used by the UAC to prompt the user for the right credentials. Is there anything missing that should be added to help the UAC? > > After this has been done once, the UA can then cache the credentials > > for > > while and preemptively supply them in future registration requests. > > With > > Digest there are some guidelines on when to preemptively try them and > > when not. I would expect something similar for Bearer. There are > > probably some security reasons not to preemptively send the > credentials > > to every server the UA attempts to connect to. As long as credentials > > are only being used for REGISTER this probably isn't a problem. But > it > > certainly is possible for server to request credentials for requests > > other than REGISTER. I'd like to see a discussion of that too. > > > > > > The UA never sends any credentials to the registrar, only to the AS/IdP. > > The UA will only send the *Access Token *to the registrar which will be > > able to validate that the token was issued by a trusted AS. > > That is details. What the UA provides to the registrar are credentials > in a functional sense, even if they are passed in an indirect way. Fair enough > It still requires a security analysis, though the conclusions might be > somewhat different. I *guess* that it is still a bad idea to hand out > the access token indiscriminately to everyone you connect to. > > Yeah, this will be covered by the security consideration section. In general, the UAC must always make sure that it is communicating with the right registrar using TLS and proper validation of the server certificate and the identity in that certificate. Regards, Rifaat > Thanks, > Paul > > > Regards, > > Rifaat > > > > Thanks, > > Paul > > > > > > > Regards, > > > Rifaat > > > > > > > > > On Mon, Jun 24, 2019 at 12:55 PM > > > > > >> wrote: > > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > directories. > > > This draft is a work item of the Session Initiation Protocol > > Core WG > > > of the IETF. > > > > > > Title : Third-Party Token-based > Authentication > > > and Authorization for Session Initiation Protocol (SIP) > > > Authors : Rifaat Shekh-Yusef > > > Christer Holmberg > > > Victor Pascual > > > Filename : > > draft-ietf-sipcore-sip-token-authnz-01.txt > > > Pages : 11 > > > Date : 2019-06-24 > > > > > > Abstract: > > > This document defines a mechanism for SIP, that is based > > on the > > > OAuth > > > 2.0 and OpenID Connect Core 1.0 specifications, to enable > the > > > delegation of the user authentication and SIP registration > > > authorization to a dedicated third-party entity that is > > separate > > > from > > > the SIP network elements that provide the SIP service. > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01 > > > > > https://datatracker.ietf. > .org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > > > > < > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01 > > > > > > > > A diff from the previous version is available at: > > > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-01 > > > > > > > > > Please note that it may take a couple of minutes from the > time of > > > submission > > > until the htmlized version and diff are available at > > tools.ietf.org > > > . > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > --000000000000551a8c058c294f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 25, 2019 at 10:47 AM Paul= Kyzivat <pkyzivat@alum.mit.edu= > wrote:
= On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote:
> Thanks Paul!
>
> Please, see my replies inline.
>
> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
> On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:= pkyzivat@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote:
>=C2=A0 =C2=A0 =C2=A0 > All,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > We have submitted a new version of the draft = that adds more
>=C2=A0 =C2=A0 =C2=A0details and
>=C2=A0 =C2=A0 =C2=A0 > we believe address the comments provided so f= ar.
>=C2=A0 =C2=A0 =C2=A0 > Please, take a look and let us know what you = think.
>
>=C2=A0 =C2=A0 =C2=A0I think this still has things a bit backwards. Step= [07] in 2.1.2 seems
>=C2=A0 =C2=A0 =C2=A0out of place. Why would the UA know to prompt the u= ser at this point,
>=C2=A0 =C2=A0 =C2=A0and if it did, how would the user know *which* cred= entials to provide.
>
> Yeah, this was a copy and paste from the previous flow.
> I agree that the prompt should happen after the 401 response. I will f= ix
> that.

Thx

>=C2=A0 =C2=A0 =C2=A0With Digest, you would never prompt for credentials= until you have
>=C2=A0 =C2=A0 =C2=A0received a 401 with WWW-Authenticate. The Realm in = that is then
>=C2=A0 =C2=A0 =C2=A0displayed to the user as indication of which creden= tials he should
>=C2=A0 =C2=A0 =C2=A0supply.
>
>=C2=A0 =C2=A0 =C2=A0I would expect something similar with Bearer. Presu= mably this will tell
>=C2=A0 =C2=A0 =C2=A0me "Google", or "Facebook", or = whatever. In your case these may be
>=C2=A0 =C2=A0 =C2=A0alternatives that the user can choose among. So I t= hink you need more
>=C2=A0 =C2=A0 =C2=A0explanation about how the alternatives are presente= d. Don't just pass
>=C2=A0 =C2=A0 =C2=A0the buck to 3261 on the WWW-Authenticate parameters= . You have ones that
>=C2=A0 =C2=A0 =C2=A0aren't mentioned there, and the usage is probab= ly somewhat different.
>
>
> The UA gets redirected to an *Authorization Server (AS)*, which could = in
> theory redirect the UA to an *IdP *server to authenticate the user. > But, this is completely out of scope for this document, as this follow= s
> a well-defined HTTP-based OAuth mechanism.

OK, as long as it somehow takes account of the server that requires
authentication and the type(s) of authentication it is willing to
accept. You can't rely on the UAC being psychic about what credentials =
are required.


Notice that the challenge provided in = the WWW-Authenticate response, defined in section 3, includes many details = that could be used by the UAC to prompt the user for the right credentials.=
Is there anything missing that should be added to help the UAC?<= /div>


=C2=A0
>=C2=A0 =C2=A0 =C2=A0After this has been done once, the UA can then cach= e the credentials
>=C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0while and preemptively supply them in future regist= ration requests.
>=C2=A0 =C2=A0 =C2=A0With
>=C2=A0 =C2=A0 =C2=A0Digest there are some guidelines on when to preempt= ively try them and
>=C2=A0 =C2=A0 =C2=A0when not. I would expect something similar for Bear= er. There are
>=C2=A0 =C2=A0 =C2=A0probably some security reasons not to preemptively = send the credentials
>=C2=A0 =C2=A0 =C2=A0to every server the UA attempts to connect to. As l= ong as credentials
>=C2=A0 =C2=A0 =C2=A0are only being used for REGISTER this probably isn&= #39;t a problem. But it
>=C2=A0 =C2=A0 =C2=A0certainly is possible for server to request credent= ials for requests
>=C2=A0 =C2=A0 =C2=A0other than REGISTER. I'd like to see a discussi= on of that too.
>
>
> The UA never sends any credentials to the registrar, only to the AS/Id= P.
> The UA will only send the *Access Token *to the registrar which will b= e
> able to validate that the token was issued by a trusted AS.

That is details. What the UA provides to the registrar are credentials
in a functional sense, even if they are passed in an indirect way.

Fair enough
=C2=A0
It still requires a security analysis, th= ough the conclusions might be
somewhat different. I *guess* that it is still a bad idea to hand out
the access token indiscriminately to everyone you connect to.

Yeah, this will be covered by the security considerat= ion section.
In general, the UAC must always make sure that it is= communicating with the right registrar using TLS and proper validation of = the server certificate and the identity in that certificate.

=
Regards,
=C2=A0Rifaat

=C2=A0<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> Regards,
>=C2=A0 =C2=A0Rifaat
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
>
>
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Rifaat
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Mon, Jun 24, 2019 at 12:55 PM <internet-drafts@ietf= .org
>=C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A New Internet-Draft is av= ailable from the on-line
>=C2=A0 =C2=A0 =C2=A0Internet-Drafts
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0directories.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0This draft is a work item = of the Session Initiation Protocol
>=C2=A0 =C2=A0 =C2=A0Core WG
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of the IETF.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Third-Party Token-based= Authentication
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and Authorization for Sess= ion Initiation Protocol (SIP)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rifaat Shekh-Yusef
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer= Holmberg
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Victor P= ascual
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 :
>=C2=A0 =C2=A0 =C2=A0draft-ietf-sipcore-sip-token-authnz-01.txt
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 11
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2019-06-24
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This documen= t defines a mechanism for SIP, that is based
>=C2=A0 =C2=A0 =C2=A0on the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0OAuth
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.0 and Open= ID Connect Core 1.0 specifications, to enable the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delegation o= f the user authentication and SIP registration
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authorizatio= n to a dedicated third-party entity that is
>=C2=A0 =C2=A0 =C2=A0separate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the SIP netw= ork elements that provide the SIP service.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The IETF datatracker statu= s page for this draft is:
>=C2=A0 =C2=A0 =C2=A0 > h= ttps://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0There are also htmlized ve= rsions available at:
>=C2=A0 =C2=A0 =C2=A0 > http= s://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-01
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf..org/doc/html/draft-ie= tf-sipcore-sip-token-authnz-01
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-to= ken-authnz-01>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A diff from the previous v= ersion is available at:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-token-authnz-01
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Please note that it may ta= ke a couple of minutes from the time of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0submission
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0until the htmlized version= and diff are available at
>=C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://tools.ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<http://tools.ietf.org&= gt;.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Internet-Drafts are also a= vailable by anonymous FTP at:
>=C2=A0 =C2=A0 =C2=A0 > ftp://ftp.ietf.org/internet-drafts/=
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0__________________________= _____________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0 > sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mail= man/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0 > sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mail= man/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>

--000000000000551a8c058c294f1f-- From nobody Tue Jun 25 12:04:40 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17E41206D4 for ; Tue, 25 Jun 2019 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id0VXuQjfyth for ; Tue, 25 Jun 2019 12:04:36 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on062e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD3012018D for ; Tue, 25 Jun 2019 12:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99RRQlGl5iTv8z8HF2+pAa123eh6YKs2GB5Lx4o+fAI=; b=JG2xNAi+rBbvOzgcIop4ek/EGXWbj+764ojrgqqWbvn4HcYSfBF5lBsye+czO6hBojpZwh/BmBXehUpMQ53x2eHCRUGYPzaHynKx0DJ6qebYSjSsxvnv+fcdg7wakbTyRDFaJhl368GlfcNUrklT0tMThAYKHOi+AGaLIJDaLWM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3417.eurprd07.prod.outlook.com (10.170.247.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.13; Tue, 25 Jun 2019 19:04:33 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.014; Tue, 25 Jun 2019 19:04:33 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt Thread-Index: AQHVKq2VsyOy4sob90miFwLZxwfdy6arBqMAgAA9R4CAARQiAIAAHHQAgAAt8wCAAEwgAA== Date: Tue, 25 Jun 2019 19:04:33 +0000 Message-ID: <2F5486FD-C55A-4696-AA36-B9D9F8DFE549@ericsson.com> References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c34d237f-6abf-4e4f-b89f-08d6f99ff5b5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3417; x-ms-traffictypediagnostic: HE1PR07MB3417: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(199004)(189003)(14454004)(25786009)(86362001)(66446008)(6116002)(3846002)(6512007)(53936002)(66476007)(229853002)(64756008)(66556008)(33656002)(76116006)(71200400001)(14444005)(8676002)(71190400001)(66946007)(44832011)(73956011)(81166006)(256004)(186003)(2616005)(8936002)(446003)(476003)(5660300002)(11346002)(81156014)(486006)(68736007)(6506007)(2906002)(66066001)(6246003)(99286004)(36756003)(4326008)(316002)(2171002)(58126008)(110136005)(6436002)(76176011)(6486002)(7736002)(26005)(305945005)(102836004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3417; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TZZka7Fv9ds2iq9W5jZN9BzD1CQFFqGwwZPsZgBcHEqw4YIb74hyIFBeIQODBiRx9nC83mmQ0qJoeSctGv1c1OmjOcPvqh5KVePUv6zp6x6RnES6Xc16lvpXh5GmpSMVAwCLuIs3xJ+lEAkTWW3KzcW6+AuW0kFD6AEqK4ZbmzLEeJfQXjz7Pst4ODnULDDbm58JSo+3/qndzAVynw7m+3JNVE05MF5xgO8m1XljmTo/Tm8ilIopki8EDXEaz+iQnzcTLsE7YSRCltrpN8HPHMImnhygBvbHstU0SFVz2xHJ2lvmMCjALR3YnGRJL5u0pETIuM7VRH1CXYQkV3SN0kyXylT/cKY0ATjQ0mxR6Vebp3WAducNEhljbF8kxiIRaKouUj1lqYuX7fVaT5fBtUUEWsVQU2DZv6wGM99tKWM= Content-Type: text/plain; charset="utf-8" Content-ID: <2CE86D148085804FBCB103F70FE81736@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c34d237f-6abf-4e4f-b89f-08d6f99ff5b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 19:04:33.5448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3417 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 19:04:39 -0000 SGksDQoNCi4uLg0KDQo+Pj4gVGhlIFVBIG5ldmVyIHNlbmRzIGFueSBjcmVkZW50aWFscyB0byB0 aGUgcmVnaXN0cmFyLCBvbmx5IHRvIHRoZSBBUy9JZFAuDQo+Pj4gVGhlIFVBIHdpbGwgb25seSBz ZW5kIHRoZSAqQWNjZXNzIFRva2VuICp0byB0aGUgcmVnaXN0cmFyIHdoaWNoIHdpbGwgYmUgDQo+ Pj4+IGFibGUgdG8gdmFsaWRhdGUgdGhhdCB0aGUgdG9rZW4gd2FzIGlzc3VlZCBieSBhIHRydXN0 ZWQgQVMuDQo+Pg0KPj4gVGhhdCBpcyBkZXRhaWxzLiBXaGF0IHRoZSBVQSBwcm92aWRlcyB0byB0 aGUgcmVnaXN0cmFyIGFyZSBjcmVkZW50aWFscyANCj4+IGluIGEgZnVuY3Rpb25hbCBzZW5zZSwg ZXZlbiBpZiB0aGV5IGFyZSBwYXNzZWQgaW4gYW4gaW5kaXJlY3Qgd2F5LiANCj4NCj4gRmFpciBl bm91Z2gNCj7CoA0KPj4gSXQgc3RpbGwgcmVxdWlyZXMgYSBzZWN1cml0eSBhbmFseXNpcywgdGhv dWdoIHRoZSBjb25jbHVzaW9ucyBtaWdodCBiZSANCj4+IHNvbWV3aGF0IGRpZmZlcmVudC4gSSAq Z3Vlc3MqIHRoYXQgaXQgaXMgc3RpbGwgYSBiYWQgaWRlYSB0byBoYW5kIG91dCANCj4+IHRoZSBh Y2Nlc3MgdG9rZW4gaW5kaXNjcmltaW5hdGVseSB0byBldmVyeW9uZSB5b3UgY29ubmVjdCB0by4N Cj4+DQo+IFllYWgsIHRoaXMgd2lsbCBiZSBjb3ZlcmVkIGJ5IHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIHNlY3Rpb24uDQo+IEluIGdlbmVyYWwsIHRoZSBVQUMgbXVzdCBhbHdheXMgbWFrZSBz dXJlIHRoYXQgaXQgaXMgY29tbXVuaWNhdGluZyB3aXRoIHRoZSByaWdodCByZWdpc3RyYXIgdXNp bmcgVExTIGFuZCBwcm9wZXIgdmFsaWRhdGlvbiBvZiB0aGUgc2VydmVyIGNlcnRpZmljYXRlIGFu ZCB0aGUgaWRlbnRpdHkgaW4gdGhhdCBjZXJ0aWZpY2F0ZS4NCg0KQ29ycmVjdC4NCg0KQW5kLCAg d2hlbiBpdCBjb21lcyB0byB0aGUgU0lQIHNpZ25hbGluZywgSSB0aGluayB0aGlzIGlzIHNpbWls YXIgdG8gb3RoZXIgY2FzZXMgd2hlcmUgeW91IHNlbmQgc2Vuc2l0aXZlIGluZm9ybWF0aW9uOiBp ZiB5b3UgY29tbXVuaWNhdGUgd2l0aCB1bnRydXN0ZWQgZW50aXRpZXMgeW91IG5lZWQgdG8gbWFr ZSBzdXJlIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIHByb3RlY3RlZCAoZW5jcnlwdGVkKS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCiANCg0K From nobody Tue Jun 25 14:01:46 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909C012047D for ; Tue, 25 Jun 2019 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cGI5u_fE99S for ; Tue, 25 Jun 2019 14:01:35 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59805120628 for ; Tue, 25 Jun 2019 14:01:35 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5PL1WeR024020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Jun 2019 17:01:33 -0400 To: Rifaat Shekh-Yusef Cc: SIPCORE References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Tue, 25 Jun 2019 17:01:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 21:01:45 -0000 Inline... On 6/25/19 1:32 PM, Rifaat Shekh-Yusef wrote: > > > On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat > wrote: > > On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote: > > Thanks Paul! > > > > Please, see my replies inline. > > > > Regards, > >   Rifaat > > > > > > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat > > > >> wrote: > > > >     On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > >      > All, > >      > > >      > We have submitted a new version of the draft that adds more > >     details and > >      > we believe address the comments provided so far. > >      > Please, take a look and let us know what you think. > > > >     I think this still has things a bit backwards. Step [07] in > 2.1.2 seems > >     out of place. Why would the UA know to prompt the user at > this point, > >     and if it did, how would the user know *which* credentials to > provide. > > > > Yeah, this was a copy and paste from the previous flow. > > I agree that the prompt should happen after the 401 response. I > will fix > > that. > > Thx > > >     With Digest, you would never prompt for credentials until you > have > >     received a 401 with WWW-Authenticate. The Realm in that is then > >     displayed to the user as indication of which credentials he > should > >     supply. > > > >     I would expect something similar with Bearer. Presumably this > will tell > >     me "Google", or "Facebook", or whatever. In your case these > may be > >     alternatives that the user can choose among. So I think you > need more > >     explanation about how the alternatives are presented. Don't > just pass > >     the buck to 3261 on the WWW-Authenticate parameters. You have > ones that > >     aren't mentioned there, and the usage is probably somewhat > different. > > > > > > The UA gets redirected to an *Authorization Server (AS)*, which > could in > > theory redirect the UA to an *IdP *server to authenticate the user. > > But, this is completely out of scope for this document, as this > follows > > a well-defined HTTP-based OAuth mechanism. > > OK, as long as it somehow takes account of the server that requires > authentication and the type(s) of authentication it is willing to > accept. You can't rely on the UAC being psychic about what credentials > are required. > > > Notice that the challenge provided in the WWW-Authenticate response, > defined in section 3, includes many details that could be used by the > UAC to prompt the user for the right credentials. > Is there anything missing that should be added to help the UAC? Yes, there is quite a bit, and scant information about what the significance is of each bit of it. IMO some explanation is needed of these items and how they are expected to be used. And a more fleshed out example that shows who puts up the UI to gather the needed info, what is included in the prompt, what comes back, and what is done with it then. Enough to relate it to real world experience. (AFAIK most real world experience is with web interfaces. For instance when hitting restricted web sites that require a login from Google, Facebook, Discus, etc. IIUC this could be much like that, including the choice of which of those to use. So a use case like that would be great. > >     After this has been done once, the UA can then cache the > credentials > >     for > >     while and preemptively supply them in future registration > requests. > >     With > >     Digest there are some guidelines on when to preemptively try > them and > >     when not. I would expect something similar for Bearer. There are > >     probably some security reasons not to preemptively send the > credentials > >     to every server the UA attempts to connect to. As long as > credentials > >     are only being used for REGISTER this probably isn't a > problem. But it > >     certainly is possible for server to request credentials for > requests > >     other than REGISTER. I'd like to see a discussion of that too. > > > > > > The UA never sends any credentials to the registrar, only to the > AS/IdP. > > The UA will only send the *Access Token *to the registrar which > will be > > able to validate that the token was issued by a trusted AS. > > That is details. What the UA provides to the registrar are credentials > in a functional sense, even if they are passed in an indirect way. > > > Fair enough > > It still requires a security analysis, though the conclusions might be > somewhat different. I *guess* that it is still a bad idea to hand out > the access token indiscriminately to everyone you connect to. > > Yeah, this will be covered by the security consideration section. > In general, the UAC must always make sure that it is communicating with > the right registrar using TLS and proper validation of the server > certificate and the identity in that certificate. Again, while it is probably true that SIP authentication is mostly used with registrars, it is also possible for other servers to require authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can send a challenge. So the UA needs to be prepared for this and do the right thing. Doing that right includes caching credentials and providing them appropriately to avoid unnecessarily prompting the user too often. And then preemptively sending credentials becomes an optimization to avoid extra round trips. This of course is very important for REGISTER since it at times is used very frequently as a keep-alive. But at the same time one needs to have some security guidance on when it is appropriate to send preemptively and when not. One answer might be that you should only preemptively send this stuff when you have previously (and recently?) been challenged by the "same" server, and then send only the credentials that resulted from that challenge. But even then there is a question of what "same" means. So this needs some explanatory text. The writeup for Digest give some of this, though it could probably stand to be improved. This gets more complex if you consider use with Proxy-Authenticate. This mostly gets into the theoretical since I have never heard of it being used in practice. It makes things complicated since in theory there could be multiple proxies on the path, and they of necessity challenge one at a time. To complete the request you then must supply a suitable credential for each of the proxies on the path. AFAIK that has never been satisfactorily explained. So I guess I would give you a pass if you put in a disclaimer that using this for Proxy-Authenticate is outside the scope of this document. Thanks, Paul From nobody Wed Jun 26 12:26:33 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75A01202B4 for ; Wed, 26 Jun 2019 12:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNrizx4YGPpD for ; Wed, 26 Jun 2019 12:26:25 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A3A12060C for ; Wed, 26 Jun 2019 12:26:25 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id j6so5927285ioa.5 for ; Wed, 26 Jun 2019 12:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HxK4N32/2SiSWpRUFfDDqdzmgZm8tysL560buruSvT0=; b=Sj0jNH8ZZo7meNXO79kQFR/SBAILuoHBxtRaKqa5pedCB0sS3BA8d+TYIyqiw4dD1Z m9dVmdIKcIqH/wAMr/O6Ce8qqEdhof93tKyL+u3mBcxrsbn2SJxxwO3FffvUiyRqLvZ5 9YWtV7QDHS2XOlBpMJY0Hz54OKZ8IKGptZUCZ051Bd5kG3NnbB3qotKlFqviJg1OCeUJ UNwfqUmr14ABqUbqU7ogXIZt/OvgSpjlf/c8IlOVzHPafKXQ9ft7a9W5jXs1Xm+vXZv2 O1PMCLMRIqHHgFRCo29G3k0cbTMzOZfZ/+CQVBmreJlBHXA23bFfCxT36ss//nZX04RZ CcSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HxK4N32/2SiSWpRUFfDDqdzmgZm8tysL560buruSvT0=; b=DmNXUKeSJM8a3J0yFf+AM1kCNUXH1P+8uGyf5CeHssJEFiAPdD8+dvnomwLqIKnHki jBSfg30vFI141q+8IOHVL7LqzOphOm7Zfg8AoIULMjrlY3J55/67SOLoZVsDpDGFRtUI MIM8XrJ8NyjXPd7e5KxZVCV05xD6y4w34REIE+eZW2yJMuyekzWvsQ+tLb2B+sT+1J/M gEQnDXuRqlkzwU4Cu1J69zsE77ZXLkP+SCUaxKYb6rf42sE4V/TRnppI+PCgGg4Hs+FP r7zeIX6RaeMLji+ZTVmi7FQqOcY+plCVA59omH34+J17GLDjzXkjziqxVs0UP7DRy/UE bfeg== X-Gm-Message-State: APjAAAUDqbGFib3D7L5kVq87WlXJ6stCYQJ3U6/9Xbh2tcCx915pLGkE QY4rRMsh8YsjXF/o9/Cuumo9YuhQ6jSsJYy21hv3ph3hbZQ= X-Google-Smtp-Source: APXvYqw8xqfRa0ErvTNWDGOup+VLTRMTN4LAlb67/UB5/mBh4tmP3dqWlsbDB7n5VjlxpozQQLSDKooDU/koO9QlJlI= X-Received: by 2002:a6b:ed01:: with SMTP id n1mr3504378iog.255.1561577184336; Wed, 26 Jun 2019 12:26:24 -0700 (PDT) MIME-Version: 1.0 References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 26 Jun 2019 15:26:13 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000005c9e83058c3f0540" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 19:26:33 -0000 --0000000000005c9e83058c3f0540 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 25, 2019 at 5:01 PM Paul Kyzivat wrote: > Inline... > > On 6/25/19 1:32 PM, Rifaat Shekh-Yusef wrote: > > > > > > On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat > > wrote: > > > > On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote: > > > Thanks Paul! > > > > > > Please, see my replies inline. > > > > > > Regards, > > > Rifaat > > > > > > > > > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat > > > > > >> > wrote: > > > > > > On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote: > > > > All, > > > > > > > > We have submitted a new version of the draft that adds more > > > details and > > > > we believe address the comments provided so far. > > > > Please, take a look and let us know what you think. > > > > > > I think this still has things a bit backwards. Step [07] in > > 2.1.2 seems > > > out of place. Why would the UA know to prompt the user at > > this point, > > > and if it did, how would the user know *which* credentials to > > provide. > > > > > > Yeah, this was a copy and paste from the previous flow. > > > I agree that the prompt should happen after the 401 response. I > > will fix > > > that. > > > > Thx > > > > > With Digest, you would never prompt for credentials until you > > have > > > received a 401 with WWW-Authenticate. The Realm in that is > then > > > displayed to the user as indication of which credentials he > > should > > > supply. > > > > > > I would expect something similar with Bearer. Presumably this > > will tell > > > me "Google", or "Facebook", or whatever. In your case these > > may be > > > alternatives that the user can choose among. So I think you > > need more > > > explanation about how the alternatives are presented. Don't > > just pass > > > the buck to 3261 on the WWW-Authenticate parameters. You have > > ones that > > > aren't mentioned there, and the usage is probably somewhat > > different. > > > > > > > > > The UA gets redirected to an *Authorization Server (AS)*, which > > could in > > > theory redirect the UA to an *IdP *server to authenticate the > user. > > > But, this is completely out of scope for this document, as this > > follows > > > a well-defined HTTP-based OAuth mechanism. > > > > OK, as long as it somehow takes account of the server that requires > > authentication and the type(s) of authentication it is willing to > > accept. You can't rely on the UAC being psychic about what > credentials > > are required. > > > > > > Notice that the challenge provided in the WWW-Authenticate response, > > defined in section 3, includes many details that could be used by the > > UAC to prompt the user for the right credentials. > > Is there anything missing that should be added to help the UAC? > > Yes, there is quite a bit, and scant information about what the > significance is of each bit of it. IMO some explanation is needed of > these items and how they are expected to be used. Sure > And a more fleshed out > example that shows who puts up the UI to gather the needed info, what is > included in the prompt, what comes back, and what is done with it then. > Enough to relate it to real world experience. > > (AFAIK most real world experience is with web interfaces. For instance > when hitting restricted web sites that require a login from Google, > Facebook, Discus, etc. IIUC this could be much like that, including the > choice of which of those to use. So a use case like that would be great. > > I think UI related issues and authentication using 3rd party IdPs are really out of scope of this document. > > > After this has been done once, the UA can then cache the > > credentials > > > for > > > while and preemptively supply them in future registration > > requests. > > > With > > > Digest there are some guidelines on when to preemptively try > > them and > > > when not. I would expect something similar for Bearer. There > are > > > probably some security reasons not to preemptively send the > > credentials > > > to every server the UA attempts to connect to. As long as > > credentials > > > are only being used for REGISTER this probably isn't a > > problem. But it > > > certainly is possible for server to request credentials for > > requests > > > other than REGISTER. I'd like to see a discussion of that too. > > > > > > > > > The UA never sends any credentials to the registrar, only to the > > AS/IdP. > > > The UA will only send the *Access Token *to the registrar which > > will be > > > able to validate that the token was issued by a trusted AS. > > > > That is details. What the UA provides to the registrar are > credentials > > in a functional sense, even if they are passed in an indirect way. > > > > > > Fair enough > > > > It still requires a security analysis, though the conclusions might > be > > somewhat different. I *guess* that it is still a bad idea to hand out > > the access token indiscriminately to everyone you connect to. > > > > Yeah, this will be covered by the security consideration section. > > In general, the UAC must always make sure that it is communicating with > > the right registrar using TLS and proper validation of the server > > certificate and the identity in that certificate. > > Again, while it is probably true that SIP authentication is mostly used > with registrars, it is also possible for other servers to require > authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can > send a challenge. So the UA needs to be prepared for this and do the > right thing. > > Doing that right includes caching credentials and providing them > appropriately to avoid unnecessarily prompting the user too often. And > then preemptively sending credentials becomes an optimization to avoid > extra round trips. This of course is very important for REGISTER since > it at times is used very frequently as a keep-alive. But at the same > time one needs to have some security guidance on when it is appropriate > to send preemptively and when not. > > I will add text around this to indicate that non-REGISTER requests should always include the Access Token in the request. One answer might be that you should only preemptively send this stuff > when you have previously (and recently?) been challenged by the "same" > server, and then send only the credentials that resulted from that > challenge. But even then there is a question of what "same" means. So > this needs some explanatory text. The writeup for Digest give some of > this, though it could probably stand to be improved. > > This gets more complex if you consider use with Proxy-Authenticate. This > mostly gets into the theoretical since I have never heard of it being > used in practice. It makes things complicated since in theory there > could be multiple proxies on the path, and they of necessity challenge > one at a time. To complete the request you then must supply a suitable > credential for each of the proxies on the path. AFAIK that has never > been satisfactorily explained. So I guess I would give you a pass if you > put in a disclaimer that using this for Proxy-Authenticate is outside > the scope of this document. > Ok. Regards, Rifaat > > Thanks, > Paul > --0000000000005c9e83058c3f0540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 25, 2019 at 5:01 PM Paul = Kyzivat <pkyz= ivat@alum.mit.edu> wrote:
Inline...

On 6/25/19 1:32 PM, Rifaat Shekh-Yusef wrote:
>
>
> On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:= pkyzivat@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote:
>=C2=A0 =C2=A0 =C2=A0 > Thanks Paul!
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Please, see my replies inline.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Rifaat
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat<= br> >=C2=A0 =C2=A0 =C2=A0<pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>= >> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 6/24/19 12:58 PM, Rifaa= t Shekh-Yusef wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > All,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > We have submitted a = new version of the draft that adds more
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0details and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > we believe address t= he comments provided so far.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Please, take a look = and let us know what you think.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I think this still has thi= ngs a bit backwards. Step [07] in
>=C2=A0 =C2=A0 =C2=A02.1.2 seems
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0out of place. Why would th= e UA know to prompt the user at
>=C2=A0 =C2=A0 =C2=A0this point,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and if it did, how would t= he user know *which* credentials to
>=C2=A0 =C2=A0 =C2=A0provide.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Yeah, this was a copy and paste from the prev= ious flow.
>=C2=A0 =C2=A0 =C2=A0 > I agree that the prompt should happen after t= he 401 response. I
>=C2=A0 =C2=A0 =C2=A0will fix
>=C2=A0 =C2=A0 =C2=A0 > that.
>
>=C2=A0 =C2=A0 =C2=A0Thx
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0With Digest, you would nev= er prompt for credentials until you
>=C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0received a 401 with WWW-Au= thenticate. The Realm in that is then
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0displayed to the user as i= ndication of which credentials he
>=C2=A0 =C2=A0 =C2=A0should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0supply.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I would expect something s= imilar with Bearer. Presumably this
>=C2=A0 =C2=A0 =C2=A0will tell
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0me "Google", or = "Facebook", or whatever. In your case these
>=C2=A0 =C2=A0 =C2=A0may be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0alternatives that the user= can choose among. So I think you
>=C2=A0 =C2=A0 =C2=A0need more
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0explanation about how the = alternatives are presented. Don't
>=C2=A0 =C2=A0 =C2=A0just pass
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the buck to 3261 on the WW= W-Authenticate parameters. You have
>=C2=A0 =C2=A0 =C2=A0ones that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0aren't mentioned there= , and the usage is probably somewhat
>=C2=A0 =C2=A0 =C2=A0different.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The UA gets redirected to an *Authorization S= erver (AS)*, which
>=C2=A0 =C2=A0 =C2=A0could in
>=C2=A0 =C2=A0 =C2=A0 > theory redirect the UA to an *IdP *server to = authenticate the user.
>=C2=A0 =C2=A0 =C2=A0 > But, this is completely out of scope for this= document, as this
>=C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 > a well-defined HTTP-based OAuth mechanism. >
>=C2=A0 =C2=A0 =C2=A0OK, as long as it somehow takes account of the serv= er that requires
>=C2=A0 =C2=A0 =C2=A0authentication and the type(s) of authentication it= is willing to
>=C2=A0 =C2=A0 =C2=A0accept. You can't rely on the UAC being psychic= about what credentials
>=C2=A0 =C2=A0 =C2=A0are required.
>
>
> Notice that the challenge provided in the WWW-Authenticate response, <= br> > defined in section 3, includes many details that could be used by the =
> UAC to prompt the user for the right credentials.
> Is there anything missing that should be added to help the UAC?

Yes, there is quite a bit, and scant information about what the
significance is of each bit of it. IMO some explanation is needed of
these items and how they are expected to be used.

Sure

=C2=A0
And a more fleshed out
example that shows who puts up the UI to gather the needed info, what is included in the prompt, what comes back, and what is done with it then. Enough to relate it to real world experience.

(AFAIK most real world experience is with web interfaces. For instance
when hitting restricted web sites that require a login from Google,
Facebook, Discus, etc. IIUC this could be much like that, including the choice of which of those to use. So a use case like that would be great.

I think UI related issues and authenti= cation using 3rd party IdPs are really out of scope of this document.
=


=C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0After this has been done o= nce, the UA can then cache the
>=C2=A0 =C2=A0 =C2=A0credentials
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0while and preemptively sup= ply them in future registration
>=C2=A0 =C2=A0 =C2=A0requests.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0With
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Digest there are some guid= elines on when to preemptively try
>=C2=A0 =C2=A0 =C2=A0them and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0when not. I would expect s= omething similar for Bearer. There are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0probably some security rea= sons not to preemptively send the
>=C2=A0 =C2=A0 =C2=A0credentials
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to every server the UA att= empts to connect to. As long as
>=C2=A0 =C2=A0 =C2=A0credentials
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0are only being used for RE= GISTER this probably isn't a
>=C2=A0 =C2=A0 =C2=A0problem. But it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0certainly is possible for = server to request credentials for
>=C2=A0 =C2=A0 =C2=A0requests
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0other than REGISTER. I'= ;d like to see a discussion of that too.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The UA never sends any credentials to the reg= istrar, only to the
>=C2=A0 =C2=A0 =C2=A0AS/IdP.
>=C2=A0 =C2=A0 =C2=A0 > The UA will only send the *Access Token *to t= he registrar which
>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0 > able to validate that the token was issued by= a trusted AS.
>
>=C2=A0 =C2=A0 =C2=A0That is details. What the UA provides to the regist= rar are credentials
>=C2=A0 =C2=A0 =C2=A0in a functional sense, even if they are passed in a= n indirect way.
>
>
> Fair enough
>
>=C2=A0 =C2=A0 =C2=A0It still requires a security analysis, though the c= onclusions might be
>=C2=A0 =C2=A0 =C2=A0somewhat different. I *guess* that it is still a ba= d idea to hand out
>=C2=A0 =C2=A0 =C2=A0the access token indiscriminately to everyone you c= onnect to.
>
> Yeah, this will be covered by the security consideration section.
> In general, the UAC must always make sure that it is communicating wit= h
> the right registrar using TLS and proper validation of the server
> certificate and the identity in that certificate.

Again, while it is probably true that SIP authentication is mostly used with registrars, it is also possible for other servers to require
authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can
send a challenge. So the UA needs to be prepared for this and do the
right thing.

Doing that right includes caching credentials and providing them
appropriately to avoid unnecessarily prompting the user too often. And
then preemptively sending credentials becomes an optimization to avoid
extra round trips. This of course is very important for REGISTER since
it at times is used very frequently as a keep-alive. But at the same
time one needs to have some security guidance on when it is appropriate to send preemptively and when not.


I will add text around this to indicat= e that non-REGISTER requests should always include the Access Token in the = request.


One answer might be that you should only preemptively send this stuff
when you have previously (and recently?) been challenged by the "same&= quot;
server, and then send only the credentials that resulted from that
challenge. But even then there is a question of what "same" means= . So
this needs some explanatory text. The writeup for Digest give some of
this, though it could probably stand to be improved.

This gets more complex if you consider use with Proxy-Authenticate. This mostly gets into the theoretical since I have never heard of it being
used in practice. It makes things complicated since in theory there
could be multiple proxies on the path, and they of necessity challenge
one at a time. To complete the request you then must supply a suitable
credential for each of the proxies on the path. AFAIK that has never
been satisfactorily explained. So I guess I would give you a pass if you put in a disclaimer that using this for Proxy-Authenticate is outside
the scope of this document.


<= div>Ok.

Regards,
=C2=A0Rifaat
=
=C2=A0
Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156175745354.21927.11392411225086543366@ietfa.amsl.com> Date: Fri, 28 Jun 2019 14:30:53 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-rejected-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 21:30:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : A Session Initiation Protocol (SIP) Response Code for Rejected Calls Authors : Eric W. Burger Bhavik Nagda Filename : draft-ietf-sipcore-rejected-09.txt Pages : 25 Date : 2019-06-28 Abstract: This document defines the 608 (Rejected) SIP response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus no one will answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code, which a human at the target User Agent Server indicated the user did not want the call. In some jurisdictions this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-rejected-09 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 29 06:47:41 2019 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6DF12000E for ; Sat, 29 Jun 2019 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmWTN6qy5_hB for ; Sat, 29 Jun 2019 06:47:38 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130055.outbound.protection.outlook.com [40.107.13.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA35120019 for ; Sat, 29 Jun 2019 06:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRbItSsksRU72/StQIB+cK1nbW1GfuzaOxM/P8iNzEs=; b=IzlC7R5CzFeLiJw2lIcIOlMQ2VJ2hzCI1XBciVY2IihtKEJ3Z4fimYX//4pn7tMImwEAQzLKGDFu1Lg99LOPd/yPfFlG0qyBXnni8fa/L0ACkXqVzoBlbLejiqheXJpDu2u9yi08mxOchV01zYR4XkTa3geG6PSD26pPT+vSP4U= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3433.eurprd07.prod.outlook.com (10.170.247.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.12; Sat, 29 Jun 2019 13:47:35 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2052.010; Sat, 29 Jun 2019 13:47:34 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt Thread-Index: AQHVKq2VsyOy4sob90miFwLZxwfdy6arBqMAgAA9R4CAARQiAIAAHHQAgAAt8wCAADqGAIABd7SAgARUXlA= Date: Sat, 29 Jun 2019 13:47:33 +0000 Message-ID: References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [94.66.125.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43c52831-0b37-4877-9c67-08d6fc985746 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3433; x-ms-traffictypediagnostic: HE1PR07MB3433: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0083A7F08A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(189003)(199004)(476003)(3846002)(6116002)(486006)(52536014)(64756008)(2906002)(316002)(186003)(446003)(76116006)(66946007)(73956011)(11346002)(478600001)(66446008)(110136005)(14454004)(55016002)(33656002)(71190400001)(66476007)(66556008)(44832011)(86362001)(71200400001)(9686003)(8936002)(76176011)(7696005)(305945005)(68736007)(6436002)(6246003)(6506007)(14444005)(74316002)(2171002)(81166006)(53936002)(102836004)(25786009)(99286004)(5660300002)(7736002)(26005)(256004)(229853002)(8676002)(81156014)(4326008)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3433; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JnNYT/HviLz19MlCT9ahgHnX5LqOOmJdzvfNxU5//UPpWxxDfUlTg7gkTs2tkD3i1uZV56X4jjy2CIC/YT0gE7DuV+a9goxo0G/EjdxvFWXOfQzhyOjlB79hOTYzr0RDWcySTWPPxlVJFtpjohwVZVXRczVunax5nrBUsRk3uJVhQylxbcNP3eUSxUPgaPHWu4hL55Fa1WRnV3UPfYZLNIgvtkFT5HR0/EqKoscHvA+M+LhCWEnuE72IhE7cd0r00zvCKJLX25YNyykzkE/FBfV3hSsV+0FDz9oeiQz6zfZWQlL6ffQl7MxQE4+Ut4nW4f/uHAXubLMe1DoNWDD5vGGvMxMZuAc79RigPYKs0Cm9cMg0tjegG6ehOhamo43F6ZjlL8VFKA1jLCPw2ZosDmZu12VkubDZRpcrMk1Tkbw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43c52831-0b37-4877-9c67-08d6fc985746 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2019 13:47:34.0382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 13:47:40 -0000 DQpIaSwNCsKgDQouLi4NCg0KPj4gQW5kIGEgbW9yZSBmbGVzaGVkIG91dCANCj4+IGV4YW1wbGUg dGhhdCBzaG93cyB3aG8gcHV0cyB1cCB0aGUgVUkgdG8gZ2F0aGVyIHRoZSBuZWVkZWQgaW5mbywg d2hhdCBpcyANCj4+IGluY2x1ZGVkIGluIHRoZSBwcm9tcHQsIHdoYXQgY29tZXMgYmFjaywgYW5k IHdoYXQgaXMgZG9uZSB3aXRoIGl0IHRoZW4uIA0KPj4gRW5vdWdoIHRvIHJlbGF0ZSBpdCB0byBy ZWFsIHdvcmxkIGV4cGVyaWVuY2UuDQo+Pg0KPj4gKEFGQUlLIG1vc3QgcmVhbCB3b3JsZCBleHBl cmllbmNlIGlzIHdpdGggd2ViIGludGVyZmFjZXMuIEZvciBpbnN0YW5jZSANCj4+IHdoZW4gaGl0 dGluZyByZXN0cmljdGVkIHdlYiBzaXRlcyB0aGF0IHJlcXVpcmUgYSBsb2dpbiBmcm9tIEdvb2ds ZSwgDQo+PiBGYWNlYm9vaywgRGlzY3VzLCBldGMuIElJVUMgdGhpcyBjb3VsZCBiZSBtdWNoIGxp a2UgdGhhdCwgaW5jbHVkaW5nIHRoZSANCj4+IGNob2ljZSBvZiB3aGljaCBvZiB0aG9zZSB0byB1 c2UuIFNvIGEgdXNlIGNhc2UgbGlrZSB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KPg0KPiBJIHRoaW5r IFVJIHJlbGF0ZWQgaXNzdWVzIGFuZCBhdXRoZW50aWNhdGlvbiB1c2luZyAzcmQgcGFydHkgSWRQ cyBhcmUgcmVhbGx5IG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJIGFncmVlLg0K DQouLi4NCg0KPj4gQWdhaW4sIHdoaWxlIGl0IGlzIHByb2JhYmx5IHRydWUgdGhhdCBTSVAgYXV0 aGVudGljYXRpb24gaXMgbW9zdGx5IHVzZWQgDQo+PiB3aXRoIHJlZ2lzdHJhcnMsIGl0IGlzIGFs c28gcG9zc2libGUgZm9yIG90aGVyIHNlcnZlcnMgdG8gcmVxdWlyZSANCj4+IGF1dGhlbnRpY2F0 aW9uLCBmb3IgU1VCU0NSSUJFLCBOT1RJRlksIG9yIGV2ZW4gSU5WSVRFLiBBbnkgc2VydmVyIGNh biANCj4+IHNlbmQgYSBjaGFsbGVuZ2UuIFNvIHRoZSBVQSBuZWVkcyB0byBiZSBwcmVwYXJlZCBm b3IgdGhpcyBhbmQgZG8gdGhlIA0KPj4gcmlnaHQgdGhpbmcuDQo+Pg0KPj4gRG9pbmcgdGhhdCBy aWdodCBpbmNsdWRlcyBjYWNoaW5nIGNyZWRlbnRpYWxzIGFuZCBwcm92aWRpbmcgdGhlbSANCj4+ IGFwcHJvcHJpYXRlbHkgdG8gYXZvaWQgdW5uZWNlc3NhcmlseSBwcm9tcHRpbmcgdGhlIHVzZXIg dG9vIG9mdGVuLiBBbmQgDQo+PiB0aGVuIHByZWVtcHRpdmVseSBzZW5kaW5nIGNyZWRlbnRpYWxz IGJlY29tZXMgYW4gb3B0aW1pemF0aW9uIHRvIGF2b2lkIA0KPj4gZXh0cmEgcm91bmQgdHJpcHMu IFRoaXMgb2YgY291cnNlIGlzIHZlcnkgaW1wb3J0YW50IGZvciBSRUdJU1RFUiBzaW5jZSANCj4+ IGl0IGF0IHRpbWVzIGlzIHVzZWQgdmVyeSBmcmVxdWVudGx5IGFzIGEga2VlcC1hbGl2ZS4gQnV0 IGF0IHRoZSBzYW1lIA0KPj4gdGltZSBvbmUgbmVlZHMgdG8gaGF2ZSBzb21lIHNlY3VyaXR5IGd1 aWRhbmNlIG9uIHdoZW4gaXQgaXMgYXBwcm9wcmlhdGUgDQo+PiB0byBzZW5kIHByZWVtcHRpdmVs eSBhbmQgd2hlbiBub3QuDQo+DQo+IEkgd2lsbCBhZGQgdGV4dCBhcm91bmQgdGhpcyB0byBpbmRp Y2F0ZSB0aGF0IG5vbi1SRUdJU1RFUiByZXF1ZXN0cyBzaG91bGQgYWx3YXlzIGluY2x1ZGUgdGhl IEFjY2VzcyBUb2tlbiBpbiB0aGUgcmVxdWVzdC4NCg0KSSBkb24ndCB0aGluayB3ZSBzaGFsbCBk byB0aGF0Lg0KDQpJIHRoaW5rIHRoZSB0b2tlbiBzaGFsbCBvbmx5IGJlIGluY2x1ZGVkIGluIG5v bi1SRUdJU1RFUiByZXF1ZXN0cyBvbmx5IGlmIHN1Y2ggcmVxdWVzdHMgYXJlIGJlaW5nIGNoYWxs ZW5nZWQgKG9yLCBwZXJoYXBzIGFsc28gYmFzZWQgb24gbG9jYWwgY29uZmlndXJhdGlvbiksIGJl Y2F1c2Ugb3RoZXJ3aXNlIHRoZSB0b2tlbiBtYXkgYmUgc2VudCB0byBhIG5vbi10cnVzdGVkIHJl bW90ZSBwZWVyLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo=