From nobody Thu Jun 2 07:57:30 2016 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 9E86712D1CD; Thu, 2 Jun 2016 07:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602145727.8871.21329.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 07:57:27 -0700 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - New Meeting Session Request for IETF 96 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:57:28 -0000 A new meeting session request has just been submitted by Adam Roach, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: netvc xrblock webpush stir mmusic rtcweb avtext perc avtcore dispatch Special Requests: Cannot conflict with interledger bof. --------------------------------------------------------- From nobody Tue Jun 7 12:31:22 2016 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 0DFF312B02B for ; Tue, 7 Jun 2016 12:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 VwuA_7LRuUBk for ; Tue, 7 Jun 2016 12:31:20 -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 0B31F12D14D for ; Tue, 7 Jun 2016 12:31:20 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u57JVIi4054964 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 7 Jun 2016 14:31:19 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: <2e5542bf-69ae-9d01-6273-afc7dc5cfab8@nostrum.com> Date: Tue, 7 Jun 2016 14:31:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Meeting in Berlin X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:31:22 -0000 [as chair] We've requested a short slot (one hour) at the upcoming IETF 96 meeting in Berlin for SIPCORE. We hope to help move along the AuthNZ discussion, and might have some conversations about the next steps for Happy Eyeballs. I would strongly encourage on-list discussion of these topics over the next few weeks. If you have any additional topics that you hope to discuss at the face-to-face meeting, please let me and Jean know as soon as possible. /a From nobody Tue Jun 7 12:34:10 2016 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 059D312B02B for ; Tue, 7 Jun 2016 12:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 TLluBkZOHqtJ for ; Tue, 7 Jun 2016 12:34:08 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 20D0012D6A7 for ; Tue, 7 Jun 2016 12:34:04 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 0AE586D09; Tue, 7 Jun 2016 21:34:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <2e5542bf-69ae-9d01-6273-afc7dc5cfab8@nostrum.com> Date: Tue, 7 Jun 2016 21:33:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97F73618-15DD-4DF1-8C7C-FD4EB07C80BE@edvina.net> References: <2e5542bf-69ae-9d01-6273-afc7dc5cfab8@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Meeting in Berlin X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:34:10 -0000 > On 07 Jun 2016, at 21:31, Adam Roach wrote: >=20 > [as chair] >=20 > We've requested a short slot (one hour) at the upcoming IETF 96 = meeting in Berlin for SIPCORE. We hope to help move along the AuthNZ = discussion, and might have some conversations about the next steps for = Happy Eyeballs. I would strongly encourage on-list discussion of these = topics over the next few weeks. >=20 > If you have any additional topics that you hope to discuss at the = face-to-face meeting, please let me and Jean know as soon as possible. I would like to start a discussion on half-legged SIP Outbound. This has = been discussed in relation to SipConnect 2.0 and a few earlier mails to this group. I will try to summarize my thoughts and the = feedback I=E2=80=99ve seen so far very soon to prepare for a list discussion prior to the meeting. /O= From nobody Tue Jun 7 13:48:45 2016 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 D8F0D12D14D for ; Tue, 7 Jun 2016 13:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 PWdmoaNyMqxJ for ; Tue, 7 Jun 2016 13:48:36 -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 7861612D68A for ; Tue, 7 Jun 2016 13:48:36 -0700 (PDT) Received: from unnumerable.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u57KmXue061472 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 7 Jun 2016 15:48:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be unnumerable.local To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> <56FE7E1C.50304@alum.mit.edu> <56FFC2ED.5030509@nostrum.com> From: Robert Sparks Message-ID: Date: Tue, 7 Jun 2016 15:48:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <56FFC2ED.5030509@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:48:41 -0000 I took a stab at writing the document discussed in this thread. The result is at https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/ Let me know where it's horribly broken. RjS On 4/2/16 8:02 AM, Robert Sparks wrote: > > > On 4/1/16 10:56 AM, Paul Kyzivat wrote: >> On 3/31/16 6:08 PM, Robert Sparks wrote: >>> Again, I don't think errata is the right way to skin this. >>> >>> >> >> I agree that when in doubt a draft is the better path. >> >> But in this case, I don't think a revision to 3261 would cover all >> the other documents out there that define header fields with this >> problem. It would still be necessary to update each of those >> documents to adopt the change. >> >> But we could do one document that updates 3261 *and* each of the >> other affected documents. > That's what my message said. >> Then, in the future, any new header field where this should apply >> could simply normatively reference this document. >> >> Thanks, >> Paul >> >>> RjS >>> >>> On 3/31/16 4:48 PM, Dale R. Worley wrote: >>>> Brett Tate writes: >>>>> I agree; that was why I sent the following email in October 2013 >>>>> while >>>>> sipcore was working on similar errata for RFC 3325. I used that >>>>> email and >>>>> aspects of the RFC 3325 errata to produce the recent errata for RFC >>>>> 3515, >>>>> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any >>>>> headers >>>>> register with IANA since October 2013. >>>>> >>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html >>>> Why don't we put in an erratum that edits RFC 3261 section 20.10. The >>>> old text is: >>>> >>>> Even if the "display-name" is empty, the "name-addr" form MUST be >>>> used if the "addr-spec" contains a comma, semicolon, or question >>>> mark. There may or may not be LWS between the display-name and >>>> the >>>> "<". >>>> >>>> The new text adds: >>>> >>>> In any header field whose value syntax is >>>> (name-addr / addr-spec) *(SEMI generic-param) >>>> or >>>> (name-addr / addr-spec) *(SEMI generic-param) >>>> *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) >>>> the "addr-spec" alternative may not be used if its value would >>>> contain a comma, semicolon, or question mark. >>>> >>>> In a sense, that's what everybody *thinks* RFC 3261 requires. >>>> >>>> Dale >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jun 8 06:15:00 2016 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 E9C9012D932 for ; Wed, 8 Jun 2016 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 gW_PYJrlKK0T for ; Wed, 8 Jun 2016 06:14:55 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 5104212D92B for ; Wed, 8 Jun 2016 06:14:55 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-01v.sys.comcast.net with SMTP id AdIrbm5TZkzylAdJtbIk9C; Wed, 08 Jun 2016 13:14:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465391693; bh=RBRp5YPMnYrKfczq/rmWcgTDypUWzhExIQ8bgiDSNkM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Krlk8EJPoAwXUCKA81erEuURxOzok4H2BqiEug077kViy5CkRLnsxlnnRxXq4DC2j rKmC0LU8jsWiLfZKlrYQu1MXJDHgmF9t7xLzq34KTA9f5NZva/URKbz7byrKXouxe6 IE55V0rhI0ucjBl6AOLI9cCmfPaC7lnpOJICyLTlUxhDF2cajn3ytaMVRw2s/pmG2a D/Gau352hbQi3ohA/xyC3pX1c6NVll53NIld6GFLeYKJ9uMfR+5KiEd2RVIE6IS61I NUDxKDd8jUVbaOvllS8Tl60A6SM+JkaqJORtk/mluQ6SaOqT6/rrR8C5sMzh+Zd+qg 1+vBXaTwW0b1A== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-15v.sys.comcast.net with comcast id 4DEt1t0083KdFy101DEt0t; Wed, 08 Jun 2016 13:14:53 +0000 To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> <56FE7E1C.50304@alum.mit.edu> <56FFC2ED.5030509@nostrum.com> From: Paul Kyzivat Message-ID: <9909848d-5035-2d46-f9e4-2e8e72a343b6@alum.mit.edu> Date: Wed, 8 Jun 2016 09:14:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:14:58 -0000 On 6/7/16 4:48 PM, Robert Sparks wrote: > I took a stab at writing the document discussed in this thread. > > The result is at > https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/ > > Let me know where it's horribly broken. It seems to do the job. Do you think that the updates in section 3 can get away with not saying *where* that text is to be added in each of the documents? Thanks, Paul > RjS > > On 4/2/16 8:02 AM, Robert Sparks wrote: >> >> >> On 4/1/16 10:56 AM, Paul Kyzivat wrote: >>> On 3/31/16 6:08 PM, Robert Sparks wrote: >>>> Again, I don't think errata is the right way to skin this. >>>> >>>> >>> >>> I agree that when in doubt a draft is the better path. >>> >>> But in this case, I don't think a revision to 3261 would cover all >>> the other documents out there that define header fields with this >>> problem. It would still be necessary to update each of those >>> documents to adopt the change. >>> >>> But we could do one document that updates 3261 *and* each of the >>> other affected documents. >> That's what my message said. >>> Then, in the future, any new header field where this should apply >>> could simply normatively reference this document. >>> >>> Thanks, >>> Paul >>> >>>> RjS >>>> >>>> On 3/31/16 4:48 PM, Dale R. Worley wrote: >>>>> Brett Tate writes: >>>>>> I agree; that was why I sent the following email in October 2013 >>>>>> while >>>>>> sipcore was working on similar errata for RFC 3325. I used that >>>>>> email and >>>>>> aspects of the RFC 3325 errata to produce the recent errata for RFC >>>>>> 3515, >>>>>> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any >>>>>> headers >>>>>> register with IANA since October 2013. >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html >>>>> Why don't we put in an erratum that edits RFC 3261 section 20.10. The >>>>> old text is: >>>>> >>>>> Even if the "display-name" is empty, the "name-addr" form MUST be >>>>> used if the "addr-spec" contains a comma, semicolon, or question >>>>> mark. There may or may not be LWS between the display-name and >>>>> the >>>>> "<". >>>>> >>>>> The new text adds: >>>>> >>>>> In any header field whose value syntax is >>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>> or >>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>> *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) >>>>> the "addr-spec" alternative may not be used if its value would >>>>> contain a comma, semicolon, or question mark. >>>>> >>>>> In a sense, that's what everybody *thinks* RFC 3261 requires. >>>>> >>>>> Dale >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 Wed Jun 8 06:40:56 2016 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 6447812D59D for ; Wed, 8 Jun 2016 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ExFhLLEadDOT for ; Wed, 8 Jun 2016 06:40:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A5812D5C2 for ; Wed, 8 Jun 2016 06:40:52 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-06-575820623a79 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.5A.27088.26028575; Wed, 8 Jun 2016 15:40:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 15:40:48 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 Thread-Index: AQHRwP3+tTcgY2t210CSZdISPavKCJ/fpmYA Date: Wed, 8 Jun 2016 13:40:48 +0000 Message-ID: References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> <56FE7E1C.50304@alum.mit.edu> <56FFC2ED.5030509@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2BBBBE27DA257F43BE87B62163505B32@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7mW6SQkS4we6l0hbX5jSyWXz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mo4tPENW0GrXMWl13PZGhh3SXQxcnJICJhI nLvwnxHCFpO4cG89WxcjF4eQwBFGictzpzJDOIsZJSau/8vaxcjBwSZgIdH9TxukQUQgUGLh pCUsILawgKPEuXtnmCHiThKfjm5ggrCNJN6smgBWwyKgIjFl7gl2EJtXwEqid+tcdoj5xxkl Js37zgqS4BSwl2g//xisiBHoou+n1oANYhYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+B9YrKqAn 8eXePKhvFCXanzYwQvTqSdyYOoUNwraWaFz0kx3C1pZYtvA1M8RBghInZz5hmcAoPgvJullI 2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQIj7uCW3wY7GF8+dzzE KMDBqMTD+8A5PFyINbGsuDL3EKMEB7OSCK+OTES4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/ l4rhQgLpiSWp2ampBalFMFkmDk6pBkaxB6+4awula26tLzL5Ncnrok7rqSOyJ+X+rUxiWWNv PXXFlJu/F5vLff3wuYD5T/HCSR/ro3bLJ1VvKIjQ4y9dJMXKpbL0s1cSa/3Ez8/3PAtcKuK1 QmbuiUdMEjYJrufCt21rMPTN29d/pkyKJ/7y899L8499CUiqvfI3sp6j9M4N8Qm54iuVWIoz Eg21mIuKEwHYcDkJtAIAAA== Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:40:54 -0000 Hi, If we want to be really clear, we should say *UNESCAPED* comma, question mark or semicolon. Because, the characters could appear escaped in most parts of a SIP-URI, but I don=B9t think we should mandate usage of name-adde in such cases. Regards, Christer On 07/06/16 23:48, "sipcore on behalf of Robert Sparks" wrote: >I took a stab at writing the document discussed in this thread. > >The result is at=20 >https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/ > >Let me know where it's horribly broken. > >RjS > >On 4/2/16 8:02 AM, Robert Sparks wrote: >> >> >> On 4/1/16 10:56 AM, Paul Kyzivat wrote: >>> On 3/31/16 6:08 PM, Robert Sparks wrote: >>>> Again, I don't think errata is the right way to skin this. >>>>=20 >>>>>>>qE>=20 >>>> >>> >>> I agree that when in doubt a draft is the better path. >>> >>> But in this case, I don't think a revision to 3261 would cover all >>> the other documents out there that define header fields with this >>> problem. It would still be necessary to update each of those >>> documents to adopt the change. >>> >>> But we could do one document that updates 3261 *and* each of the >>> other affected documents. >> That's what my message said. >>> Then, in the future, any new header field where this should apply >>> could simply normatively reference this document. >>> >>> Thanks, >>> Paul >>> >>>> RjS >>>> >>>> On 3/31/16 4:48 PM, Dale R. Worley wrote: >>>>> Brett Tate writes: >>>>>> I agree; that was why I sent the following email in October 2013 >>>>>> while >>>>>> sipcore was working on similar errata for RFC 3325. I used that >>>>>> email and >>>>>> aspects of the RFC 3325 errata to produce the recent errata for RFC >>>>>> 3515, >>>>>> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any >>>>>> headers >>>>>> register with IANA since October 2013. >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html >>>>> Why don't we put in an erratum that edits RFC 3261 section 20.10. >>>>>The >>>>> old text is: >>>>> >>>>> Even if the "display-name" is empty, the "name-addr" form MUST be >>>>> used if the "addr-spec" contains a comma, semicolon, or question >>>>> mark. There may or may not be LWS between the display-name and >>>>> the >>>>> "<". >>>>> >>>>> The new text adds: >>>>> >>>>> In any header field whose value syntax is >>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>> or >>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>> *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) >>>>> the "addr-spec" alternative may not be used if its value would >>>>> contain a comma, semicolon, or question mark. >>>>> >>>>> In a sense, that's what everybody *thinks* RFC 3261 requires. >>>>> >>>>> Dale >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 Wed Jun 8 14:15:30 2016 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 4348712D736 for ; Wed, 8 Jun 2016 14:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 HwiP5VDYIm5A for ; Wed, 8 Jun 2016 14:15:27 -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 AC67512D7DD for ; Wed, 8 Jun 2016 14:15:27 -0700 (PDT) Received: from unnumerable.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58LFQ53004643 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 8 Jun 2016 16:15:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be unnumerable.local To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> <56FE7E1C.50304@alum.mit.edu> <56FFC2ED.5030509@nostrum.com> <9909848d-5035-2d46-f9e4-2e8e72a343b6@alum.mit.edu> From: Robert Sparks Message-ID: <56b3c715-acb3-fa51-fa64-7fc4b7cf2fa2@nostrum.com> Date: Wed, 8 Jun 2016 16:15:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <9909848d-5035-2d46-f9e4-2e8e72a343b6@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 21:15:29 -0000 On 6/8/16 8:14 AM, Paul Kyzivat wrote: > On 6/7/16 4:48 PM, Robert Sparks wrote: >> I took a stab at writing the document discussed in this thread. >> >> The result is at >> https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/ >> >> >> Let me know where it's horribly broken. > > It seems to do the job. > > Do you think that the updates in section 3 can get away with not > saying *where* that text is to be added in each of the documents? Yes. I see nothing but trouble in trying to place them more specifically given what they do, and I don't see how they can be misinterpreted without such placement. > > Thanks, > Paul > >> RjS >> >> On 4/2/16 8:02 AM, Robert Sparks wrote: >>> >>> >>> On 4/1/16 10:56 AM, Paul Kyzivat wrote: >>>> On 3/31/16 6:08 PM, Robert Sparks wrote: >>>>> Again, I don't think errata is the right way to skin this. >>>>> >>>>> >>>>> >>>> >>>> I agree that when in doubt a draft is the better path. >>>> >>>> But in this case, I don't think a revision to 3261 would cover all >>>> the other documents out there that define header fields with this >>>> problem. It would still be necessary to update each of those >>>> documents to adopt the change. >>>> >>>> But we could do one document that updates 3261 *and* each of the >>>> other affected documents. >>> That's what my message said. >>>> Then, in the future, any new header field where this should apply >>>> could simply normatively reference this document. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> RjS >>>>> >>>>> On 3/31/16 4:48 PM, Dale R. Worley wrote: >>>>>> Brett Tate writes: >>>>>>> I agree; that was why I sent the following email in October 2013 >>>>>>> while >>>>>>> sipcore was working on similar errata for RFC 3325. I used that >>>>>>> email and >>>>>>> aspects of the RFC 3325 errata to produce the recent errata for RFC >>>>>>> 3515, >>>>>>> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any >>>>>>> headers >>>>>>> register with IANA since October 2013. >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html >>>>>> Why don't we put in an erratum that edits RFC 3261 section >>>>>> 20.10. The >>>>>> old text is: >>>>>> >>>>>> Even if the "display-name" is empty, the "name-addr" form >>>>>> MUST be >>>>>> used if the "addr-spec" contains a comma, semicolon, or question >>>>>> mark. There may or may not be LWS between the display-name and >>>>>> the >>>>>> "<". >>>>>> >>>>>> The new text adds: >>>>>> >>>>>> In any header field whose value syntax is >>>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>>> or >>>>>> (name-addr / addr-spec) *(SEMI generic-param) >>>>>> *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) >>>>>> the "addr-spec" alternative may not be used if its value would >>>>>> contain a comma, semicolon, or question mark. >>>>>> >>>>>> In a sense, that's what everybody *thinks* RFC 3261 requires. >>>>>> >>>>>> Dale >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 Thu Jun 9 10:59:27 2016 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 61EB512D793 for ; Thu, 9 Jun 2016 10:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 clQoypddWuzl for ; Thu, 9 Jun 2016 10:59:18 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 DAA0A12D75A for ; Thu, 9 Jun 2016 10:59:17 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d64so65899422vkb.0 for ; Thu, 09 Jun 2016 10:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c179JyR6NpqEEt6D+l8XZFCRVyM9IxpCeZU+RoAiwnM=; b=kiiHFwxWJPcDWvtSOMRh8B9BP3P+4N4dvJHnS61eILrB4qe7Y9GFjvEwDKyWvo8CHF dlN5wufwbqepcqcXaU1igTAxvhyzY8Nh3vc0/IcjhV8a/2UDhAKBRasrKNcL7Kx6sII5 dzVPyGxmbg5CYQ6szWaQ6JXBq2vth5YdpIYTU9QxOHFG8nibTIeO6wqQ8qiWZs4gxI1t K7j18bSNU+46eCU4TlpJRgC+BC2rlvwagEUM6K+mUY17k+uZIT2AJvMpzrN4pyi+gZDI m13VCmjJwD0gkJawJNW4bR40nL387uybTONjGTiatvICWOtBNDc/OvFqoJaWvESluPum Uqjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c179JyR6NpqEEt6D+l8XZFCRVyM9IxpCeZU+RoAiwnM=; b=SU81UqhJKlYMrirb0uCQ6BsxlVgBaDCSM+3k2Ryg5apd0uh2VHdzkVWrFsU8HLar+U fE3AsccpXsprNXWOAlut5Lkm8F+OjgeYulWDyteyKH2KQVke2FodGm+BAGUkuBMH3o0n HlswrTJ8diwjKGKz18256fJc1ASbRaZz4w2BI8pkbUYMiaguYQH/ejduNYQlUIKZVu+0 cYaBPX25a9blIJZXdhYE5J/UWZlPMG75rsPH4/Xn2YkB+prxHX+N00WqfhxAArnwPp0E tDOCz6ol68b07N9wTUpFyV8DRHpR6n5tkG/T4lI5TRt+HgNLafcP2TvFdFHNL2BjIxc1 tlZA== X-Gm-Message-State: ALyK8tLe0O5jtKq7J8ANyyxDunH2c9T5S97lVG3N5KwW74csarsQu54fw+shusr1R54kRaztKELaZHw7fnH4GA== X-Received: by 10.31.13.70 with SMTP id 67mr5303466vkn.9.1465495156948; Thu, 09 Jun 2016 10:59:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 9 Jun 2016 10:59:15 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Thu, 9 Jun 2016 13:59:15 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a114413c04003c80534dc2e30 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:59:26 -0000 --001a114413c04003c80534dc2e30 Content-Type: text/plain; charset=UTF-8 Hi Jon, Sorry for the delayed reply. Let's take the video conference example, and discuss the possible ways for the conference server to provide service. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Possible solutions: 1. Conference Server acts as an AuthN and AuthZ server. Requests to the server must provide an identity and credentials, and services will be provided based on locally stored information associated with the identity provided in the request. 2. Conference Server acts as an AuthZ server, but delegates the AuthN part. Requests to the server must provide an identity token, and services will be provided based on locally stored information associated with the identity provided in the token. 3. Conference Server delegates both AuthN and AuthZ parts. Requests to the server must provide an access token, which might or might not include information about the user requesting the service, and services will be provided based on information provided in the access token or as a result of an introspection step using the access token. Now, let's look at the 3rd option a bit more, and assume that the server provides the following types of conference services: 1. audio conference 2. audio/video conference 3. web conference or some combination of the above. Let's also assume that the server allows control over the number of participants allowed in each one of these conference types or combinations. Here is one way that I envisioned we could use to address this use case: When an enterprise user in the 1st trust domain wants to register with the SIP Proxy, it will have to authenticate to the IdP and as a result either the UA or the Proxy (depends on the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step to allow only the proxy to get access to the tokens, or the tokens could be sent to the UA which will then use them to communicate with the proxy. The AuthN token is the identity of the user, and the AuthZ token has all the services granted to the user by the IdP/AuthZ Service. When the enterprise user needs access to the conference service, the UA will send an INVITE to the Proxy, and will include the AuthZ token if it is in possession of the tokens; otherwise, the proxy will add the appropriate token to the outgoing INVITE sent to the conference server. The scope of the AuthZ token might grant the user access to multiple services; to avoid sending that AuthZ token to all servers providing services granted to the user, the proxy could obtain a different token with limited scope that is specific to the service being provided (conference services in this case); there is a standard Token Exchange mechanism for that. The AuthZ token will include information about the type of service allowed (audio, audio/video, etc), and the limit on the number of participants. The AuthZ token might or might not have any information about the user requesting the service, which depends on the level of privacy needed. When the conference server receives this token in the SIP INVITE, all it has to do is validate that the token was signed by an IdP that it has a trust relationship with, and provide the service requested by the AuthZ token. The conference server does not need the AuthN token to be able to provide a service. Regards, Rifaat On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon wrote: > > Also, if we decided to separate the AuthN and AuthZ, then we might need to > carry more than one token. > > > I could see an argument that there is a need to carry the identity of the > user in one header, and a reference to a place where you can get attributes > about the originating user in another header, say. That's more or less what > we envisioned the last time we went down this path, which led to the > RFC4484 requirements, largely informed by SAML (which I seem to recall 3GPP > was interested in at the time). > > But it's no accident that the work on RFC4484 never went beyond > requirements. Today, I think that much of the useful work that could be > done on the authorization question is in identifying which SIP > authorization policies are likely to depend on attributes as opposed to > just the identity of the end user. While we can readily conceive of > applications adjunct to communications that would require attributes, the > challenge has been justifying why you would invoke those applications with > SIP rather than, say, HTTP. The fundamental semantics of a SIP INVITE have > remained pretty close to those of placing a telephone call. The > authorization policies of a telephone call are really different than that > of a web service, say, both in terms of how and why they are invoked, what > kinds of parties are involved, what forms redirection or cross-domain > interaction can occur. With appropriate caveats for other methods (notably > MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy > requirements that look a lot like call treatment policies. > > That much said, I am kind of interested in call treatment policies, and > their interaction with identity information. But just saying that there > might be a video conference service in the cloud, say, doesn't shed a lot > of light for me. If there's a video conference, I'd ordinarily think you > just call into it. If the user who opens the conference bridge needs to be > charged, that's identity information - which in its usual form will convey > the individual user and their domain, like user@domain. If you need more > complex semantics than that, it's probably because you're doing something > more complicated than just calling in to the conference. But it's less > clear to me why you'd use SIP for such cases. Drilling down deeper into > these use cases would help me understand where we're going, anyway - the > use cases in RFC4484 Section 4, which largely involve billing (including > when dealing with various protocol gateways) and resource management (both > preemption and priority), ultimately didn't seem sufficient to motivate > protocol work. > > Another issues in the need, in some cases, to avoid sending the token to > the UA; in this case there is a need for an interim step to get the > token(s) to the SIP proxy. > > > If this information is carried in headers, then presumably it could be > added, consumed, subtracted, or whatever by any relevant intermediaries. > > Jon Peterson > Neustar, Inc. > --001a114413c04003c80534dc2e30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon,

Sorry for the delayed reply.

Let&#= 39;s take the video conference example, and discuss the possible ways for= =C2=A0the conference= server to provide service.


=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2= =A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=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: =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 +--------+ =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 =C2=A0 =C2=A0 | IdP =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 +-------------| AuthZ =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 =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 =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 =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 =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 =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 =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| SIP =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 | SIP App|=
=C2=A0 =C2=A0 | =C2=A0 UA = =C2=A0 |--------| Proxy =C2=A0|-----:-----------------:-----| Video =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 | Conference
=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 =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 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :

Possible solutions:

1. Confere= nce Server acts as an AuthN and AuthZ server. Requests to the=C2=A0server m= ust provide an identity and credentials, and services will be=C2=A0provided= based on locally stored information associated with the=C2=A0identity prov= ided in the request.
<= br>
2. Conference Serv= er acts as an AuthZ server, but delegates the AuthN part.=C2=A0Requests to = the server must provide an identity token, and services will=C2=A0be provid= ed based on locally stored information associated with the=C2=A0identity pr= ovided in the token.
<= br>
3. Conference Serv= er delegates both AuthN and AuthZ parts. Requests to the=C2=A0server must p= rovide an access token, which might or might not include=C2=A0information a= bout the user requesting the service, and services will=C2=A0be provided ba= sed on information provided in the access token or as a=C2=A0result of an i= ntrospection step using the access token.


Now, let's= look at the 3rd option a bit more, and assume that the server=C2=A0provide= s the following types of conference services:
1. audio conference
2. audio/video conference
3. web conference

or some=C2=A0combination=C2=A0of the above.

Let's also assume that the server allows control over the= number of=C2=A0participants allowed in each one of these conference types = or combinations.

<= /font>

= Here is one way that I envisioned we co= uld use to address this use case:

When an enterprise user in the 1st trust domain wants to register w= ith the=C2=A0SIP Proxy, it will have to authenticate to the IdP and as a re= sult either=C2=A0the UA or the Proxy (depends on the UA's capabilities)= will be provided=C2=A0with an AuthN and AuthZ tokens. This process could i= nvolve an interim step=C2=A0to allow only the proxy to get access to the to= kens, or the tokens could be=C2=A0sent to the UA which will then use them t= o communicate with the proxy.

Regards,
=C2= =A0Rifaat

<= /div>

On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the ident= ity of the user in one header, and a reference to a place where you can get= attributes about the originating user in another header, say. That's m= ore or less what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond re= quirements. Today, I think that much of the useful work that could be done = on the authorization question is in identifying which SIP authorization pol= icies are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP. =C2=A0The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.=C2=A0 The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lo= t of light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user wh= o opens the conference bridge needs to be charged, that's identity info= rmation - which in its usual form will convey the individual user and their= domain, like user@domain. If you need more complex semantics than that, it's probably because you're doing so= mething more complicated than just calling in to the conference. But it'= ;s less clear to me why you'd use SIP for such cases. Drilling down dee= per into these use cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which = largely involve billing (including when dealing with various protocol gatew= ays) and resource management (both preemption and priority), ultimately did= n't seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it c= ould be added, consumed, subtracted, or whatever by any relevant intermedia= ries.=C2=A0

Jon Peterson
Neustar, Inc.

--001a114413c04003c80534dc2e30-- From nobody Fri Jun 10 02:46:58 2016 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 0CB3B12D190 for ; Fri, 10 Jun 2016 02:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1IEjT624jYFH for ; Fri, 10 Jun 2016 02:46:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 11C7C12D159 for ; Fri, 10 Jun 2016 02:46:21 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 3CB4F42E3; Fri, 10 Jun 2016 11:46:17 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2016 11:46:16 +0200 Message-Id: To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:46:50 -0000 Friends, I=E2=80=99ve tried to collect my thoughts about TLS and Outbound in a = small brainstorm-presentation. http://www.slideshare.net/oej/sip-half-outbound-random-notes The chairs have alerted me to the fact that this may not be a SIPcore = issue which I agree with, but I think this is the proper starting point = for a general discussion between SIP people before we either drop the = issue or drag it into dispatch. My apologies to the chairs for using = this attractive forum :-) In short: - very few seems to implement full outbound - some parts of outbound seems used - which parts is not documented - TLS between UA and server has a clear problem if outbound is not used I am toying with an idea for a simple extension that puts the = connection/flow management on the UA, allows the server to reuse the inbound TLS connection (without a client = cert) after auth for outbound requests and also allows the server to remove associations in the = location database at connection close. I think this documents what=E2=80=99s in use and formalises it with an = extension tag. Please check my presentation and give me feedback. Thanks! /O From nobody Fri Jun 10 02:52:22 2016 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 75B0712D878 for ; Fri, 10 Jun 2016 02:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EjoI8S1MAQp4 for ; Fri, 10 Jun 2016 02:52:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 D222412D15E for ; Fri, 10 Jun 2016 02:52:16 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id E4C286C34; Fri, 10 Jun 2016 11:52:13 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2016 11:52:13 +0200 Message-Id: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:52:20 -0000 Friends, I think it=E2=80=99s time to kill the SIPS: uri. I know that some of you = thought it was dead, but it is not the case. It doesn=E2=80=99t add anything, personally I don=E2=80=99t see it in = use anywhere and it confuses a lot of discussions about TLS usage in = SIP. We need to see what happens if we remove SIPS: from the SIP playground - = what=E2=80=99s missing? Questions arise: - Can we live without SIPS: and without =E2=80=9C;transport=3DTLS=E2=80=9D= or do we need to take the transport parameter back? - Can my TLS connection reuse idea (previous mail) solve UA to edge = proxy issues? - Do we need TLS transport in VIA headers? - Are we going to have to prepare for DTLS transport too? (See Dale = Worley=E2=80=99s previous emails) ? I think it=E2=80=99s time to spend some time with TLS in SIPcore again. = What do you think? /O From nobody Fri Jun 10 03:10:35 2016 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 B6CE512B05C for ; Fri, 10 Jun 2016 03:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yWpKE0vgtB1w for ; Fri, 10 Jun 2016 03:10:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936AC12B01A for ; Fri, 10 Jun 2016 03:10:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-49-575a92158d35 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.96.12516.5129A575; Fri, 10 Jun 2016 12:10:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 12:10:28 +0200 From: Christer Holmberg To: "Olle E. Johansson" , SIPCORE Thread-Topic: [sipcore] Half-outbound thoughts Thread-Index: AQHRwv0JFSQKTaaM9k2nbWwzhDIm2p/ijFUA Date: Fri, 10 Jun 2016 10:10:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <983E7F0E8C07FE41B2287807AFA6372D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7ga7opKhwg4enhCxerj7EbPH1xyY2 ByaPaWtXsnosWfKTKYApissmJTUnsyy1SN8ugSvj3MbnTAWX+CsmHr/K3sB4lqeLkZNDQsBE 4knjXjYIW0ziwr31YLaQwBFGiSn3VbsYuYDsJYwSkzd0sHYxcnCwCVhIdP/TBqkREXCRONp9 kh0kLCygK/HwZTBEWE9i15KrjBC2kcSBbXdYQWwWAVWJ1ScaWEBsXgEriT1f17BArLKVeLZn BTuIzSlgJ/Hq5VewOCPQOd9PrWECsZkFxCVuPZnPBHGmgMSSPeeZIWxRiZeP/4HNFwXa++Xe PEaIuKLEx1f7GCF69SRuTJ3CBmFbS8z7cY0ZwtaWWLbwNTPEPYISJ2c+YZnAKD4LybpZSNpn IWmfhaR9FpL2BYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECY+3glt+6OxhXv3Y8xCjA wajEw/vgWWS4EGtiWXFl7iFGCQ5mJRFei76ocCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8V w4UE0hNLUrNTUwtSi2CyTBycUg2MWRdOBjR8ilD4FcLNJbty+xL++JSP25SqfJ7dTu+KnJV6 f/FjYc/pn94+Nr+/3phn7UPxSyv3vtaRO/dH/usSg/tGi6v/3Jop7jexKYrVifO88IX8t9uf H5pxYvbsfQVfj1h9WSQzc62husrbV0JTWSx7Z98Sb/pc3vaVoTLngFaZOWPRfgtJBSWW4oxE Qy3mouJEAOv4j16xAgAA Archived-At: Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:10:34 -0000 Hi O, A couple of questions on the slides: Q1: Number of flows You claim that Outbound mandates at least two flows. I can find text saying that a UA must, as a minimum, support a set of two outbound proxy URIs, and while the whole idea of Outbound is having multiple flows I don=B9t find any text saying that one must configure two (or more) outbound proxy URIs. Q2: Flow-management Slide #14 says =B3No flow-management=B2. What is meant by that? That the keep-olives aren=B9t needed? Regards, Christer On 10/06/16 12:46, "sipcore on behalf of Olle E. Johansson" wrote: >Friends, >I=B9ve tried to collect my thoughts about TLS and Outbound in a small >brainstorm-presentation. > >http://www.slideshare.net/oej/sip-half-outbound-random-notes > >The chairs have alerted me to the fact that this may not be a SIPcore >issue which I agree with, but I think this is the proper starting point >for a general discussion between SIP people before we either drop the >issue or drag it into dispatch. My apologies to the chairs for using this >attractive forum :-) > >In short: > >- very few seems to implement full outbound >- some parts of outbound seems used >- which parts is not documented >- TLS between UA and server has a clear problem if outbound is not used > >I am toying with an idea for a simple extension that puts the >connection/flow management on the UA, >allows the server to reuse the inbound TLS connection (without a client >cert) after auth for outbound >requests and also allows the server to remove associations in the >location database at connection close. > >I think this documents what=B9s in use and formalises it with an extension >tag. > >Please check my presentation and give me feedback. > >Thanks! >/O > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jun 10 04:04:57 2016 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 3283912D0A0 for ; Fri, 10 Jun 2016 04:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yLwg0FdQlKzL for ; Fri, 10 Jun 2016 04:04:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 9CDDC12D09C for ; Fri, 10 Jun 2016 04:04:53 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 71EB0428B; Fri, 10 Jun 2016 13:04:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 10 Jun 2016 13:04:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53B14A35-EBF0-4FB1-A20A-59B5E0F7F63A@edvina.net> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:04:56 -0000 > On 10 Jun 2016, at 12:10, Christer Holmberg = wrote: >=20 > Hi O, >=20 > A couple of questions on the slides: >=20 > Q1: Number of flows >=20 > You claim that Outbound mandates at least two flows. >=20 > I can find text saying that a UA must, as a minimum, support a set of = two > outbound proxy URIs, and while the whole idea of Outbound is having > multiple flows I don=C4=85t find any text saying that one must = configure two > (or more) outbound proxy URIs. We=E2=80=99ve discussed this many times at SIPit and have parsed TWO as = a=20 must. I think you may be right though, that two is not required to run, but the client must support using it. My failure. Additional quote: "If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the default outbound proxies from the set. =E2=80=9C I will update the slides >=20 >=20 > Q2: Flow-management >=20 > Slide #14 says =C5=82No flow-management=CB=9B. What is meant by that? = That the > keep-olives aren=C4=85t needed? >=20 That=E2=80=99s very badly written by me. We need flow management, but = not in the outbound-style, with flow tokens and all that. Will update. Thank you for very good feedback! /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 10/06/16 12:46, "sipcore on behalf of Olle E. Johansson" > wrote: >=20 >> Friends, >> I=C4=85ve tried to collect my thoughts about TLS and Outbound in a = small >> brainstorm-presentation. >>=20 >> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>=20 >> The chairs have alerted me to the fact that this may not be a SIPcore >> issue which I agree with, but I think this is the proper starting = point >> for a general discussion between SIP people before we either drop the >> issue or drag it into dispatch. My apologies to the chairs for using = this >> attractive forum :-) >>=20 >> In short: >>=20 >> - very few seems to implement full outbound >> - some parts of outbound seems used >> - which parts is not documented >> - TLS between UA and server has a clear problem if outbound is not = used >>=20 >> I am toying with an idea for a simple extension that puts the >> connection/flow management on the UA, >> allows the server to reuse the inbound TLS connection (without a = client >> cert) after auth for outbound >> requests and also allows the server to remove associations in the >> location database at connection close. >>=20 >> I think this documents what=C4=85s in use and formalises it with an = extension >> tag. >>=20 >> Please check my presentation and give me feedback. >>=20 >> Thanks! >> /O >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jun 10 05:44:31 2016 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 3F05312D911 for ; Fri, 10 Jun 2016 05:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 sxZx55d3xMTY for ; Fri, 10 Jun 2016 05:44:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 76D5A12D0CC for ; Fri, 10 Jun 2016 05:44:26 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 37DBA428B; Fri, 10 Jun 2016 14:44:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <53B14A35-EBF0-4FB1-A20A-59B5E0F7F63A@edvina.net> Date: Fri, 10 Jun 2016 14:44:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B14A35-EBF0-4FB1-A20A-59B5E0F7F63A@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 12:44:30 -0000 > On 10 Jun 2016, at 13:04, Olle E. Johansson wrote: >=20 >=20 >> On 10 Jun 2016, at 12:10, Christer Holmberg = wrote: >>=20 >> Hi O, >>=20 >> A couple of questions on the slides: >>=20 >> Q1: Number of flows >>=20 >> You claim that Outbound mandates at least two flows. >>=20 >> I can find text saying that a UA must, as a minimum, support a set of = two >> outbound proxy URIs, and while the whole idea of Outbound is having >> multiple flows I don=C4=85t find any text saying that one must = configure two >> (or more) outbound proxy URIs. > We=E2=80=99ve discussed this many times at SIPit and have parsed TWO = as a=20 > must. I think you may be right though, that two is not required to = run, > but the client must support using it. My failure. >=20 > Additional quote: >=20 > "If the set has more than > one URI, the UAC MUST send a REGISTER request to at least two of the > default outbound proxies from the set. =E2=80=9C >=20 > I will update the slides An updated version (v1.1) is now available at http://www.slideshare.net/oej/sip-half-outbound-random-notes /O >>=20 >>=20 >> Q2: Flow-management >>=20 >> Slide #14 says =C5=82No flow-management=CB=9B. What is meant by that? = That the >> keep-olives aren=C4=85t needed? >>=20 > That=E2=80=99s very badly written by me. We need flow management, but = not in > the outbound-style, with flow tokens and all that. Will update. >=20 > Thank you for very good feedback! >=20 > /O >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> On 10/06/16 12:46, "sipcore on behalf of Olle E. Johansson" >> wrote: >>=20 >>> Friends, >>> I=C4=85ve tried to collect my thoughts about TLS and Outbound in a = small >>> brainstorm-presentation. >>>=20 >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>>=20 >>> The chairs have alerted me to the fact that this may not be a = SIPcore >>> issue which I agree with, but I think this is the proper starting = point >>> for a general discussion between SIP people before we either drop = the >>> issue or drag it into dispatch. My apologies to the chairs for using = this >>> attractive forum :-) >>>=20 >>> In short: >>>=20 >>> - very few seems to implement full outbound >>> - some parts of outbound seems used >>> - which parts is not documented >>> - TLS between UA and server has a clear problem if outbound is not = used >>>=20 >>> I am toying with an idea for a simple extension that puts the >>> connection/flow management on the UA, >>> allows the server to reuse the inbound TLS connection (without a = client >>> cert) after auth for outbound >>> requests and also allows the server to remove associations in the >>> location database at connection close. >>>=20 >>> I think this documents what=C4=85s in use and formalises it with an = extension >>> tag. >>>=20 >>> Please check my presentation and give me feedback. >>>=20 >>> Thanks! >>> /O >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From nobody Fri Jun 10 11:03:36 2016 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 E804312D8A5 for ; Fri, 10 Jun 2016 11:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 FPl2wxfyJq1D for ; Fri, 10 Jun 2016 11:03:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F2FCC12D777 for ; Fri, 10 Jun 2016 11:03:33 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E3B7E6AAA64BA; Fri, 10 Jun 2016 18:03:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5AI3Vvl031534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 18:03:31 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5AI3Rxi027577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jun 2016 20:03:31 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 10 Jun 2016 20:03:27 +0200 From: "Drage, Keith (Nokia - GB)" To: "Olle E. Johansson" , SIPCORE Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRwv3REQdB19tCFkq/OxaVh7fUFZ/i/Kfg Date: Fri, 10 Jun 2016 18:03:26 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF1354F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> In-Reply-To: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:03:36 -0000 SSBhZ3JlZSB0aGF0IHRoZSBTSVBTIFVSSSBpcyBub3QgZGVhZCwgYnV0IGl0IGlzIGNsZWFybHkg c3RhdGVkIGluIFJGQyA1NjMwICh3aGljaCB1cGRhdGVzIFJGQyAzMjYxKSB0aGF0IGEgc3VjY2Vz c2Z1bCBjYWxsIHVzaW5nIGEgU0lQUyBVUkkgcmVxdWlyZXMgdGhlIHVzZSBvZiBUTFMgb24gZWFj aCBob3AuIFJlcXVlc3RzIHdoZXJlIHRoaXMgY2Fubm90IGJlIGZ1bGZpbGxlZCBoYXZlIHRvIGJl IHJlamVjdGVkLg0KDQpUaGF0IGlzIHN1cmVseSBhIGJpZyBlbm91Z2ggaGludCB0byBvbmx5IHVz ZSBpdCB3aGVyZSB0aGF0IGlzIHdoYXQgeW91IHdhbnQuDQoNCktlaXRoDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgT2xsZSBFLiBKb2hhbnNzb24NClNlbnQ6IDEwIEp1bmUgMjAx NiAxMDo1Mg0KVG86IFNJUENPUkUNCkNjOiBPbGxlIEUgSm9oYW5zc29uDQpTdWJqZWN0OiBbc2lw Y29yZV0gU0lQUyBtdXN0IGRpZSwgZGllLCBkaWUNCg0KRnJpZW5kcywNCg0KSSB0aGluayBpdOKA mXMgdGltZSB0byBraWxsIHRoZSBTSVBTOiB1cmkuIEkga25vdyB0aGF0IHNvbWUgb2YgeW91IHRo b3VnaHQgaXQgd2FzIGRlYWQsIGJ1dCBpdCBpcyBub3QgdGhlIGNhc2UuDQoNCkl0IGRvZXNu4oCZ dCBhZGQgYW55dGhpbmcsIHBlcnNvbmFsbHkgSSBkb27igJl0IHNlZSBpdCBpbiB1c2UgYW55d2hl cmUgYW5kIGl0IGNvbmZ1c2VzIGEgbG90IG9mIGRpc2N1c3Npb25zIGFib3V0IFRMUyB1c2FnZSBp biBTSVAuDQoNCldlIG5lZWQgdG8gc2VlIHdoYXQgaGFwcGVucyBpZiB3ZSByZW1vdmUgU0lQUzog ZnJvbSB0aGUgU0lQIHBsYXlncm91bmQgLSB3aGF04oCZcyBtaXNzaW5nPw0KDQpRdWVzdGlvbnMg YXJpc2U6DQoNCi0gQ2FuIHdlIGxpdmUgd2l0aG91dCBTSVBTOiBhbmQgd2l0aG91dCDigJw7dHJh bnNwb3J0PVRMU+KAnSBvciBkbyB3ZSBuZWVkIHRvIHRha2UgdGhlIHRyYW5zcG9ydCBwYXJhbWV0 ZXIgYmFjaz8NCi0gQ2FuIG15IFRMUyBjb25uZWN0aW9uIHJldXNlIGlkZWEgKHByZXZpb3VzIG1h aWwpIHNvbHZlIFVBIHRvIGVkZ2UgcHJveHkgaXNzdWVzPw0KLSBEbyB3ZSBuZWVkIFRMUyB0cmFu c3BvcnQgaW4gVklBIGhlYWRlcnM/DQotIEFyZSB3ZSBnb2luZyB0byBoYXZlIHRvIHByZXBhcmUg Zm9yIERUTFMgdHJhbnNwb3J0IHRvbz8gKFNlZSBEYWxlIFdvcmxleeKAmXMgcHJldmlvdXMgZW1h aWxzKSA/DQoNCkkgdGhpbmsgaXTigJlzIHRpbWUgdG8gc3BlbmQgc29tZSB0aW1lIHdpdGggVExT IGluIFNJUGNvcmUgYWdhaW4uIFdoYXQgZG8geW91IHRoaW5rPw0KDQovTw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0K From nobody Fri Jun 10 13:00:16 2016 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 72A3A12D8EF for ; Fri, 10 Jun 2016 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 dx2EPmSSS7cd for ; Fri, 10 Jun 2016 13:00:03 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 6E19E12D8ED for ; Fri, 10 Jun 2016 13:00:03 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with SMTP id BSZ7bi9S3E8zeBSb4bjJqI; Fri, 10 Jun 2016 20:00:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465588802; bh=959XG1kHBHLhsJtiFr+9GkwkjPJNjkMnVmzku3m/Kkc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Y+e2edDeyxGLph832pP2XvDzGxKLBVev3KOSeqAzTvtY5Dzd0syVUA+bVSAN3aovX UKjkH4HX/yyCe54Te20gANUGNPZkejaQbVvvxxy+U90mjfRDqm05AAHMYnK4SEo4rR uP7osbZy1+MaoG6aFoGPC5RSdfVVdtUHqTZdkK8fCH9qU8SvKK0K6BzFt6vCiE2J0/ AJxLg/qjFKJHzbZdEEWAcDcicx8yzo57TerhVBxM0Q1xQPqiXOBjFwVj4hOC7YuYoF ZkWm5MbrafZx6u2BArIV4scI+rlpPhROFjn4IAvpgCXcOjKAcqzJCGCgrQulGovTUI jNbYYZoB9wUCA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id 58021t00T3KdFy101802Hj; Fri, 10 Jun 2016 20:00:02 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <7ce65691-dae3-4521-7c5a-bb66f4cff63a@alum.mit.edu> Date: Fri, 10 Jun 2016 16:00:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:00:04 -0000 On 6/10/16 6:10 AM, Christer Holmberg wrote: > Hi O, > > A couple of questions on the slides: > > Q1: Number of flows > > You claim that Outbound mandates at least two flows. > > I can find text saying that a UA must, as a minimum, support a set of two > outbound proxy URIs, and while the whole idea of Outbound is having > multiple flows I don¹t find any text saying that one must configure two > (or more) outbound proxy URIs. +1. I just recently had occasion to review outbound for use in a specialized context, and also reached this conclusion. I think it can be used as-is for cases with only one flow. The key is that you must *support* multiple flows, but the use of them is governed by the number of addresses that are configured. If only one is configured then you only have one flow. Thanks, Paul From nobody Fri Jun 10 15:07:13 2016 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 4661512D986 for ; Fri, 10 Jun 2016 15:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 WWOoxRkWYnYs for ; Fri, 10 Jun 2016 15:07:11 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 6776912D985 for ; Fri, 10 Jun 2016 15:07:11 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with SMTP id BUZbbPWR3EFCNBUa6bKKOO; Fri, 10 Jun 2016 22:07:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465596430; bh=8UFR+2Gr5mKYqbXlBVWtO0zK5sYcXk5oilzADaGCQNg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=uSp4EOs+thil8PFfUSoiLlI+Mm7OzfiiOadT0Xyp7gsbDzf0+HBeezNqK1irztCDH ZXtPBE21Dt4f+4kZSxXvbgpwkuZewfTbF6BfEZjX8mZag0ghYKhycCOgpFVztCPdBa asbgcA0UOHrEFcIMPr6w/JRrEL+b9PH6B9Y+G2uRnfgZ3G9KI7JUsuNlh5sUT64yyl ZdCiiabKJbMxqfVA6O3ey0CFOJ8lD8sLFcaMiIwAWdgruPk49kYr8IVmGIpYHfrT/B MyamIX1GZtbrYYw9aRwrSZEmi7OxD808R3cQdKtIYT4LsXqUBp0QD435GJyu/+Ad+O Y7jGn3f0NAM5w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id 5A791t00M1nMCLR01A79iz; Fri, 10 Jun 2016 22:07:10 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5AM79EM024973; Fri, 10 Jun 2016 18:07:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5AM78Mb024969; Fri, 10 Jun 2016 18:07:08 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 10 Jun 2016 18:07:08 -0400 Message-ID: <87d1no3dgz.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 22:07:12 -0000 "Olle E. Johansson" writes: > I think it's time to spend some time with TLS in SIPcore again. What > do you think? My memory is that the latest revision decided, as Keith says, that if you make a call to a sips: URI, you are guaranteed that every signaling step is covered by TLS, or the call is rejected -- and "transport=TLS" doesn't have that guarantee. Dale From nobody Fri Jun 10 23:47:56 2016 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 65E3112DA83 for ; Fri, 10 Jun 2016 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dwkHh511nhQJ for ; Fri, 10 Jun 2016 23:47:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6B912DA78 for ; Fri, 10 Jun 2016 23:47:52 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-43-575bb417e53a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.55.27088.714BB575; Sat, 11 Jun 2016 08:47:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 08:47:50 +0200 From: Christer Holmberg To: "Dale R. Worley" , "Olle E. Johansson" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtAcjdwYYWLUaapNCZA/0nQZ/j0xww Date: Sat, 11 Jun 2016 06:47:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) <87d1no3dgz.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d1no3dgz.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7oK74luhwg78fBCxerj7EbPH1xyY2 i5cnyhyYPSbv/8rsMW3tSlaPJUt+MgUwR3HZpKTmZJalFunbJXBlPDj8g7FgB3PFll/P2RsY zzJ1MXJySAiYSMz9c5MdwhaTuHBvPVsXIxeHkMARRon/K+eyQDhLGCU2rOkEcjg42AQsJLr/ aYM0iAgESnQtWgk2iFlAU+LRzr1gtrCAnsSUE2dZIWr0Jf4u+M8E0ioiYCSx46cSSJhFQFVi wsRPjCA2r4CvxIPF98FsIYFyicZ179hAbE4BY4npN2aDxRmBbvt+ag3UKnGJW0/mQ90vILFk z3lmCFtU4uXjf6wQtpLE2sPbWSDqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ2FpKW WUhaZiFpWcDIsopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMJ4ObvltsIPx5XPHQ4wCHIxK PLwJFtHhQqyJZcWVuYcYJTiYlUR4uTcBhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJI TyxJzU5NLUgtgskycXBKNTDG+Gzt49u1/gjrs4ynRfcN5xg5d35oUzi0UfzaHzERza15chpH 6uLDj56Quf2+a3LQBMXyOQzqsrsUPOsZSzqK5Z0cDZL/K617dvGg4HYt7huK0z685vOL1r20 esKsrcueyJVl3G4/KNMfcDjJp7HSN0ymdE/StpJFnZI6rm+ZbgUfXPlr6U0lluKMREMt5qLi RABkFtZyowIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 06:47:55 -0000 Hi, >> I think it's time to spend some time with TLS in SIPcore again. What=20 >> do you think? > > My memory is that the latest revision decided, as Keith says, that if you= make a call to a sips: URI, you > are guaranteed that every signaling step= is covered by TLS, or the call is rejected ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reali= ty there is no guarantee. Regards, Christer From nobody Fri Jun 10 23:54:37 2016 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 789C112DA90 for ; Fri, 10 Jun 2016 23:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EOtv78XX_UvK for ; Fri, 10 Jun 2016 23:54:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1527412DA83 for ; Fri, 10 Jun 2016 23:54:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-d1-575bb5a66b39 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.2A.12516.6A5BB575; Sat, 11 Jun 2016 08:54:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 08:54:30 +0200 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [sipcore] Half-outbound thoughts Thread-Index: AQHRwv0JFSQKTaaM9k2nbWwzhDIm2p/ijFUA///b+ACAABvOgIABUVtg Date: Sat, 11 Jun 2016 06:54:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804B420@ESESSMB209.ericsson.se> References: <53B14A35-EBF0-4FB1-A20A-59B5E0F7F63A@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9SnfZ1uhwg/krDC1erj7EbPH1xyY2 ByaPaWtXsnosWfKTKYApissmJTUnsyy1SN8ugSvjSLt1QZ92xZGZtQ2MDVpdjJwcEgImEpun TWeGsMUkLtxbz9bFyMUhJHCEUeLCt4MsEM4SRomVt/+xdjFycLAJWEh0/9MGaRAR0JC48OUK G4jNLCAncf3DRjBbWEBX4tTaN4wQNXoSu5ZchbLdJJY8WQc2hkVAVeLbXGmQMK+Ar8Smvy8Y IVZdY5R4tGUlE0iCU8BO4uXaQ2AzGYGO+35qDRPELnGJW0/mM0EcLSCxZM95qAdEJV4+BjkT xFaSWHt4OwvILmYBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlW MYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTGzcEtv3V3MK5+7XiIUYCDUYmHN8EiOlyINbGs uDL3EKMEB7OSCC/3JqAQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUw WSYOTqkGxq4126+oGvs7aMuWX8k/uPPBlMNXtp9lddbr0woyKgvXf+La/OJ9zloPxhD18zof TeXErtzJqVW4/SXxmkfrtK9St14dmr610TigdoX7Q9VNNydXuOw+XjdbjKvv+/W9Pjne+z4b 9r/Kfbl6j8fbebGG4TYcM2efOPZ6/Y+p206zzpj4euGmA8uVWIozEg21mIuKEwF4WdPylwIA AA== Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 06:54:35 -0000 SGksDQoNCkFub3RoZXIgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24uDQoNClEzOg0KDQpTbGlk ZSAjMiB0YWxrcyBhYm91dCAib3V0Ym91bmQgcmVxdWVzdHMiLiBXaGF0IGRvZXMgIm91dGJvdW5k IiByZWZlciB0bz8gUmVxdWVzdHMgc29tZWhvdyBhc3NvY2lhdGVkIHdpdGggdGhlIG91dGJvdW5k IG1lY2hhbmlzbSwgb3IgdGhlIGRpcmVjdGlvbiBvZiB0aGUgcmVxdWVzdHM/DQoNCklmIGl0J3Mg YWJvdXQgdGhlIGRpcmVjdGlvbiwgc2hvdWxkbid0IGl0IHRoZW4gbWUgImluYm91bmQiLCBhcyB0 aGUgcmVxdWVzdHMgaXMgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBVQT8NCg0KSWYgaXQncyBhYm91 dCByZXF1ZXN0cyBhc3NvY2lhdGVkIHdpdGggdGhlIG91dGJvdW5kIG1lY2hhbmlzbSwgSSB0aGlu ayB5b3UgbmVlZCB0byBjbGFyaWZ5IGEgYml0IHdoYXQgZXhhY3RseSB5b3UgbWVhbiBieSB0aGF0 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBbbWFpbHRvOm9lakBlZHZpbmEubmV0XSANClNlbnQ6 IDEwIEp1bmUgMjAxNiAxNTo0NA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+ OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBIYWxm LW91dGJvdW5kIHRob3VnaHRzDQoNCg0KPiBPbiAxMCBKdW4gMjAxNiwgYXQgMTM6MDQsIE9sbGUg RS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4+IE9uIDEwIEp1 biAyMDE2LCBhdCAxMjoxMCwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIE8sDQo+PiANCj4+IEEgY291cGxlIG9mIHF1 ZXN0aW9ucyBvbiB0aGUgc2xpZGVzOg0KPj4gDQo+PiBRMTogTnVtYmVyIG9mIGZsb3dzDQo+PiAN Cj4+IFlvdSBjbGFpbSB0aGF0IE91dGJvdW5kIG1hbmRhdGVzIGF0IGxlYXN0IHR3byBmbG93cy4N Cj4+IA0KPj4gSSBjYW4gZmluZCB0ZXh0IHNheWluZyB0aGF0IGEgVUEgbXVzdCwgYXMgYSBtaW5p bXVtLCBzdXBwb3J0IGEgc2V0IG9mIA0KPj4gdHdvIG91dGJvdW5kIHByb3h5IFVSSXMsIGFuZCB3 aGlsZSB0aGUgd2hvbGUgaWRlYSBvZiBPdXRib3VuZCBpcyANCj4+IGhhdmluZyBtdWx0aXBsZSBm bG93cyBJIGRvbsSFdCBmaW5kIGFueSB0ZXh0IHNheWluZyB0aGF0IG9uZSBtdXN0IA0KPj4gY29u ZmlndXJlIHR3byAob3IgbW9yZSkgb3V0Ym91bmQgcHJveHkgVVJJcy4NCj4gV2XigJl2ZSBkaXNj dXNzZWQgdGhpcyBtYW55IHRpbWVzIGF0IFNJUGl0IGFuZCBoYXZlIHBhcnNlZCBUV08gYXMgYSAN Cj4gbXVzdC4gSSB0aGluayB5b3UgbWF5IGJlIHJpZ2h0IHRob3VnaCwgdGhhdCB0d28gaXMgbm90 IHJlcXVpcmVkIHRvIA0KPiBydW4sIGJ1dCB0aGUgY2xpZW50IG11c3Qgc3VwcG9ydCB1c2luZyBp dC4gTXkgZmFpbHVyZS4NCj4gDQo+IEFkZGl0aW9uYWwgcXVvdGU6DQo+IA0KPiAiSWYgdGhlIHNl dCBoYXMgbW9yZSB0aGFuDQo+ICAgb25lIFVSSSwgdGhlIFVBQyBNVVNUIHNlbmQgYSBSRUdJU1RF UiByZXF1ZXN0IHRvIGF0IGxlYXN0IHR3byBvZiB0aGUNCj4gICBkZWZhdWx0IG91dGJvdW5kIHBy b3hpZXMgZnJvbSB0aGUgc2V0LiDigJwNCj4gDQo+IEkgd2lsbCB1cGRhdGUgdGhlIHNsaWRlcw0K QW4gdXBkYXRlZCB2ZXJzaW9uICh2MS4xKSAgaXMgbm93IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3 LnNsaWRlc2hhcmUubmV0L29lai9zaXAtaGFsZi1vdXRib3VuZC1yYW5kb20tbm90ZXMNCg0KL08N Cj4+IA0KPj4gDQo+PiBRMjogRmxvdy1tYW5hZ2VtZW50DQo+PiANCj4+IFNsaWRlICMxNCBzYXlz IMWCTm8gZmxvdy1tYW5hZ2VtZW50y5suIFdoYXQgaXMgbWVhbnQgYnkgdGhhdD8gVGhhdCB0aGUg DQo+PiBrZWVwLW9saXZlcyBhcmVuxIV0IG5lZWRlZD8NCj4+IA0KPiBUaGF04oCZcyB2ZXJ5IGJh ZGx5IHdyaXR0ZW4gYnkgbWUuIFdlIG5lZWQgZmxvdyBtYW5hZ2VtZW50LCBidXQgbm90IGluIA0K PiB0aGUgb3V0Ym91bmQtc3R5bGUsIHdpdGggZmxvdyB0b2tlbnMgYW5kIGFsbCB0aGF0LiBXaWxs IHVwZGF0ZS4NCj4gDQo+IFRoYW5rIHlvdSBmb3IgdmVyeSBnb29kIGZlZWRiYWNrIQ0KPiANCj4g L08NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0ZXINCj4+IA0KPj4gDQo+PiANCj4+ IE9uIDEwLzA2LzE2IDEyOjQ2LCAic2lwY29yZSBvbiBiZWhhbGYgb2YgT2xsZSBFLiBKb2hhbnNz b24iDQo+PiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBvZWpAZWR2aW5h Lm5ldD4gd3JvdGU6DQo+PiANCj4+PiBGcmllbmRzLA0KPj4+IEnEhXZlIHRyaWVkIHRvIGNvbGxl Y3QgbXkgdGhvdWdodHMgYWJvdXQgVExTIGFuZCBPdXRib3VuZCBpbiBhIHNtYWxsIA0KPj4+IGJy YWluc3Rvcm0tcHJlc2VudGF0aW9uLg0KPj4+IA0KPj4+IGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5u ZXQvb2VqL3NpcC1oYWxmLW91dGJvdW5kLXJhbmRvbS1ub3Rlcw0KPj4+IA0KPj4+IFRoZSBjaGFp cnMgaGF2ZSBhbGVydGVkIG1lIHRvIHRoZSBmYWN0IHRoYXQgdGhpcyBtYXkgbm90IGJlIGEgDQo+ Pj4gU0lQY29yZSBpc3N1ZSB3aGljaCBJIGFncmVlIHdpdGgsIGJ1dCBJIHRoaW5rIHRoaXMgaXMg dGhlIHByb3BlciANCj4+PiBzdGFydGluZyBwb2ludCBmb3IgYSBnZW5lcmFsIGRpc2N1c3Npb24g YmV0d2VlbiBTSVAgcGVvcGxlIGJlZm9yZSB3ZSANCj4+PiBlaXRoZXIgZHJvcCB0aGUgaXNzdWUg b3IgZHJhZyBpdCBpbnRvIGRpc3BhdGNoLiBNeSBhcG9sb2dpZXMgdG8gdGhlIA0KPj4+IGNoYWly cyBmb3IgdXNpbmcgdGhpcyBhdHRyYWN0aXZlIGZvcnVtIDotKQ0KPj4+IA0KPj4+IEluIHNob3J0 Og0KPj4+IA0KPj4+IC0gdmVyeSBmZXcgc2VlbXMgdG8gaW1wbGVtZW50IGZ1bGwgb3V0Ym91bmQN Cj4+PiAtIHNvbWUgcGFydHMgb2Ygb3V0Ym91bmQgc2VlbXMgdXNlZA0KPj4+IC0gd2hpY2ggcGFy dHMgaXMgbm90IGRvY3VtZW50ZWQNCj4+PiAtIFRMUyBiZXR3ZWVuIFVBIGFuZCBzZXJ2ZXIgaGFz IGEgY2xlYXIgcHJvYmxlbSBpZiBvdXRib3VuZCBpcyBub3QgDQo+Pj4gdXNlZA0KPj4+IA0KPj4+ IEkgYW0gdG95aW5nIHdpdGggYW4gaWRlYSBmb3IgYSBzaW1wbGUgZXh0ZW5zaW9uIHRoYXQgcHV0 cyB0aGUgDQo+Pj4gY29ubmVjdGlvbi9mbG93IG1hbmFnZW1lbnQgb24gdGhlIFVBLCBhbGxvd3Mg dGhlIHNlcnZlciB0byByZXVzZSB0aGUgDQo+Pj4gaW5ib3VuZCBUTFMgY29ubmVjdGlvbiAod2l0 aG91dCBhIGNsaWVudA0KPj4+IGNlcnQpIGFmdGVyIGF1dGggZm9yIG91dGJvdW5kDQo+Pj4gcmVx dWVzdHMgYW5kIGFsc28gYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gcmVtb3ZlIGFzc29jaWF0aW9ucyBp biB0aGUgDQo+Pj4gbG9jYXRpb24gZGF0YWJhc2UgYXQgY29ubmVjdGlvbiBjbG9zZS4NCj4+PiAN Cj4+PiBJIHRoaW5rIHRoaXMgZG9jdW1lbnRzIHdoYXTEhXMgaW4gdXNlIGFuZCBmb3JtYWxpc2Vz IGl0IHdpdGggYW4gDQo+Pj4gZXh0ZW5zaW9uIHRhZy4NCj4+PiANCj4+PiBQbGVhc2UgY2hlY2sg bXkgcHJlc2VudGF0aW9uIGFuZCBnaXZlIG1lIGZlZWRiYWNrLg0KPj4+IA0KPj4+IFRoYW5rcyEN Cj4+PiAvTw0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+PiBzaXBjb3JlQGlldGYub3Jn DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+PiAN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBz aXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+IA0KDQo= From nobody Sat Jun 11 06:53:54 2016 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 EF51312D124 for ; Sat, 11 Jun 2016 06:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 Zg-tvB_BIP-3 for ; Sat, 11 Jun 2016 06:53:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 551AA12D1C1 for ; Sat, 11 Jun 2016 06:53:51 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id ACF43C06A7231; Sat, 11 Jun 2016 13:53:46 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5BDrmAo021096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jun 2016 13:53:48 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5BDrjQ3029744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jun 2016 15:53:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 11 Jun 2016 15:53:45 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , "Dale R. Worley" , "Olle E. Johansson" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/j0xwwgABl9+A= Date: Sat, 11 Jun 2016 13:53:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 13:53:53 -0000 The current status of the RFCs is clear. While this behaviour may occur, it is non-conformant with the current requi= rements of the RFCs, and IETF cannot be the protocol police. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 11 June 2016 07:48 To: Dale R. Worley; Olle E. Johansson Cc: sipcore@ietf.org Subject: Re: [sipcore] SIPS must die, die, die Hi, >> I think it's time to spend some time with TLS in SIPcore again. What=20 >> do you think? > > My memory is that the latest revision decided, as Keith says, that if=20 > you make a call to a sips: URI, you > are guaranteed that every=20 > signaling step is covered by TLS, or the call is rejected ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reali= ty there is no guarantee. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Jun 11 07:11:51 2016 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 250AE12D9A9 for ; Sat, 11 Jun 2016 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nG9qa0MJryya for ; Sat, 11 Jun 2016 07:11:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CD612D0C4 for ; Sat, 11 Jun 2016 07:11:46 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-da-575c1c203f60 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.48.12926.02C1C575; Sat, 11 Jun 2016 16:11:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 16:11:31 +0200 From: Christer Holmberg To: "Drage, Keith (Nokia - GB)" , "Dale R. Worley" , "Olle E. Johansson" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtAcjdwYYWLUaapNCZA/0nQZ/j0xwwgABV6gCAACZ/7Q== Date: Sat, 11 Jun 2016 14:11:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804BAA0@ESESSMB209.ericsson.se> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se>, <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3804BAA0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2J7iK6iTEy4wZ57LBYbthxnsXi5+hCz xdcfm9gsXp4oc2DxmLz/K7PHtLUrWT2WLPnJ5HH31iWmAJYoLpuU1JzMstQifbsEroyrf1oZ C/6oVzx+tYu1gfGEUhcjJ4eEgInE+d1T2CBsMYkL99aD2UICRxglfs0S72LkArKXMEosmv6Q qYuRg4NNwEKi+582SI2IQBujxPQjpSA2s4CmxKOde5lAbGEBPYkpJ86yQtToS/xd8J8JwnaS 2H1hP5jNIqAqcbpvBTOIzSvgKzF563tWiF09TBKn764Ea+YUiJVoXfYDrIER6Ljvp9YwQSwT l2j6AlEjISAgsWTPeWYIW1Ti5eN/rCB3MgvkS5zZKwQxX1Di5MwnLBMYRWYh6Z6FUDULSRVE iYHEl/e3oWxtiWULXzND2PoS3e9PMyGLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokR GHkHt/xW3cF4+Y3jIUYBDkYlHt4Ei+hwIdbEsuLK3EOMEhzMSiK8igIx4UK8KYmVValF+fFF pTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoYVTYIfar2rprp0tvJvvvlL4bk ntZLaWvO9X/ceGW6B5/ISY2bv2/vTpymnPHgXRf3kzLWJSfNT7Wtrn43e9c5ruZMUQn9P5PM GFsKGZ8tfbvnQctTpo7ExrLFD4ysvvr4zPM8z3H++774Bg81t/V1X1lf9u7uKV78y+uw3I/K 37EM1Ul3Evy/K7EUZyQaajEXFScCAJKWfym4AgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 14:11:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3804BAA0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I don't disagree. Regards, Christer Sent from my Windows Phone ________________________________ From: Drage, Keith (Nokia - GB) Sent: =FD11/=FD06/=FD2016 16:53 To: Christer Holmberg; Dale R. Worle= y; Olle E. Johansson Cc: sipcore@ietf.org Subject: RE: [sipcore] SIPS must die, die, die The current status of the RFCs is clear. While this behaviour may occur, it is non-conformant with the current requi= rements of the RFCs, and IETF cannot be the protocol police. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 11 June 2016 07:48 To: Dale R. Worley; Olle E. Johansson Cc: sipcore@ietf.org Subject: Re: [sipcore] SIPS must die, die, die Hi, >> I think it's time to spend some time with TLS in SIPcore again. What >> do you think? > > My memory is that the latest revision decided, as Keith says, that if > you make a call to a sips: URI, you > are guaranteed that every > signaling step is covered by TLS, or the call is rejected ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reali= ty there is no guarantee. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B3804BAA0ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I don't disag= ree.

Regards,

Christer

Sent from my Windows Phone
From: Drage, Keith (Nokia - GB) Sent: =FD11= /=FD06/=FD2016 16:53
To: Christer Holmberg; Dale R. Worley; Olle E. Johansson
Cc: sipcore@ietf.org
Subject: RE: [= sipcore] SIPS must die, die, die

The current status of the RFCs is clear.

While this behaviour may occur, it is non-conformant with the current requi= rements of the RFCs, and IETF cannot be the protocol police.

Keith

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 11 June 2016 07:48
To: Dale R. Worley; Olle E. Johansson
Cc: sipcore@ietf.org
Subject: Re: [sipcore] SIPS must die, die, die

Hi,

>> I think it's time to spend some time with TLS in SIPcore again. Wh= at
>> do you think?
>
> My memory is that the latest revision decided, as Keith says, that if =
> you make a call to a sips: URI, you > are guaranteed that every > signaling step is covered by TLS, or the call is rejected

...or the SIPS URI is "converted" to a SIP URI by an intermediary= . In reality there is no guarantee.

Regards,

Christer


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B3804BAA0ESESSMB209erics_-- From nobody Sat Jun 11 07:12:58 2016 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 ABD8612D0C4 for ; Sat, 11 Jun 2016 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 44w4cusjY_xA for ; Sat, 11 Jun 2016 07:12:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2586E12B048 for ; Sat, 11 Jun 2016 07:12:55 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5BE9DHN017906; Sat, 11 Jun 2016 10:12:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 23ge7cdsat-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Jun 2016 10:12:39 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5BECb6V004066; Sat, 11 Jun 2016 10:12:38 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5BECNho003997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jun 2016 10:12:33 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 11 Jun 2016 14:12:10 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.208]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 10:12:10 -0400 From: "DOLLY, MARTIN C" To: "Drage, Keith (Nokia - GB)" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/kFpuAgAB3AAD//8IYDQ== Date: Sat, 11 Jun 2016 14:12:09 +0000 Message-ID: <90C4C693-0F1C-4CD6-8826-9AB85C2A358E@att.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se>, <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606110166 Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 14:12:56 -0000 God forbid real life implementation gets considered.... I could continue = but considering the last discussion that shut down, I'll leave it at that Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Jun 11, 2016, at 9:54 AM, Drage, Keith (Nokia - GB) wrote: >=20 > The current status of the RFCs is clear. >=20 > While this behaviour may occur, it is non-conformant with the current req= uirements of the RFCs, and IETF cannot be the protocol police. >=20 > Keith >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Hol= mberg > Sent: 11 June 2016 07:48 > To: Dale R. Worley; Olle E. Johansson > Cc: sipcore@ietf.org > Subject: Re: [sipcore] SIPS must die, die, die >=20 > Hi, >=20 >>> I think it's time to spend some time with TLS in SIPcore again. What=20 >>> do you think? >>=20 >> My memory is that the latest revision decided, as Keith says, that if=20 >> you make a call to a sips: URI, you > are guaranteed that every=20 >> signaling step is covered by TLS, or the call is rejected >=20 > ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In rea= lity there is no guarantee. >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Jun 11 09:53:16 2016 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 15C8E12D0CF for ; Sat, 11 Jun 2016 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 JO60fJAx3Ibp for ; Sat, 11 Jun 2016 09:53:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C725212D56F for ; Sat, 11 Jun 2016 09:53:12 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 88E29C084AB14; Sat, 11 Jun 2016 16:53:07 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5BGrAIQ029839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jun 2016 16:53:10 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5BGr7Lf000468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jun 2016 18:53:07 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 11 Jun 2016 18:53:07 +0200 From: "Drage, Keith (Nokia - GB)" To: "DOLLY, MARTIN C" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/j0xwwgABl9+D///UYgIAAS7Fw Date: Sat, 11 Jun 2016 16:53:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF13D8F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> (oej@edvina.net) <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se>, <949EF20990823C4C85C18D59AA11AD8BADF13CD7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <90C4C693-0F1C-4CD6-8826-9AB85C2A358E@att.com> In-Reply-To: <90C4C693-0F1C-4CD6-8826-9AB85C2A358E@att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 16:53:15 -0000 5630 was there to make a precise statement about what the use of SIPS URI v= ersus transport=3Dtls meant. The former means the user wants TLS on every h= op between the endpoints, the latter applies only to the current hop, with = possibly some implication I trust my provider to do the rest. Now you might argue there is space in there for "give me TLS on these bits,= and I'll trust the rest to be secure" but that would seem to be getting a = bit complicated to define. Otherwise I would argue that deployments should respect the requirements of= what a SIPS URI means, and only seek to improve on transport=3DTLS. Keith -----Original Message----- From: DOLLY, MARTIN C [mailto:md3135@att.com]=20 Sent: 11 June 2016 15:12 To: Drage, Keith (Nokia - GB) Cc: Christer Holmberg; Dale R. Worley; Olle E. Johansson; sipcore@ietf.org Subject: Re: [sipcore] SIPS must die, die, die God forbid real life implementation gets considered.... I could continue = but considering the last discussion that shut down, I'll leave it at that Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: 609-903-3360 Email: md3135@att.com > On Jun 11, 2016, at 9:54 AM, Drage, Keith (Nokia - GB) wrote: >=20 > The current status of the RFCs is clear. >=20 > While this behaviour may occur, it is non-conformant with the current req= uirements of the RFCs, and IETF cannot be the protocol police. >=20 > Keith >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 11 June 2016 07:48 > To: Dale R. Worley; Olle E. Johansson > Cc: sipcore@ietf.org > Subject: Re: [sipcore] SIPS must die, die, die >=20 > Hi, >=20 >>> I think it's time to spend some time with TLS in SIPcore again. What=20 >>> do you think? >>=20 >> My memory is that the latest revision decided, as Keith says, that if=20 >> you make a call to a sips: URI, you > are guaranteed that every=20 >> signaling step is covered by TLS, or the call is rejected >=20 > ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In rea= lity there is no guarantee. >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Jun 11 09:59:53 2016 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 70BF612D0AA for ; Sat, 11 Jun 2016 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 8AKXfLZ_nCKG for ; Sat, 11 Jun 2016 09:59:50 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 8864212B050 for ; Sat, 11 Jun 2016 09:59:50 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-09v.sys.comcast.net with SMTP id BmG9b2HFyrlQrBmGEb0ifn; Sat, 11 Jun 2016 16:59:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465664390; bh=CSFnIk2Pm+RzICeOVqcVTg7qBGdfwjRqQoWvJZ/Y/iE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RbE+t5dbOw4GQ0Jec8RXN6tui9qda65rWC2eqSJf8rIq6uKfNpB8m3/0eEEO5hMg0 /7Si8weQoeThdn/VMCi7hzuVXHfk4Lg0Fs/JqURzM105mcJd3JBOs/9mHRIWH1yU42 tiyXqJEKz507/b//Dh8QAakOz63u9lQo0pXT+cadrQQsVDKXop6P/5P1i0FuxmmZ0g Fd1o3kHAczkCK1UerAPnksJcvnWDh1mAPcUd4ErOLG+7QeKTPe8N7MY1hkgWAK3pt0 rNmbkCVbiFsyoTOnXEbYyNdB+AQSXjKsN92vgFW0QJllbdQuItMA7KqulxW/0SMDrn QFMGjBpQ6RapA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-20v.sys.comcast.net with comcast id 5Uzp1t00C3KdFy101UzpMc; Sat, 11 Jun 2016 16:59:49 +0000 To: sipcore@ietf.org References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Sat, 11 Jun 2016 12:59:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 16:59:52 -0000 On 6/11/16 2:47 AM, Christer Holmberg wrote: > Hi, > >>> I think it's time to spend some time with TLS in SIPcore again. What >>> do you think? >> >> My memory is that the latest revision decided, as Keith says, that if you make a call to a sips: URI, you > are guaranteed that every signaling step is covered by TLS, or the call is rejected > > ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reality there is no guarantee. So the choices are: 1) use SIPS as defined, meeting all the constraints 2) use SIPS but cheat when convenient 3) don't use SIPS Can anyone cite are real deployments that meet (1)? I suspect there are none. I hope nobody here is advocating (2). It has no useful security properties. Hence ISTM that (3) is the only deployable alternative. Thanks, Paul From nobody Sun Jun 12 01:03:08 2016 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 2473B12D0FC for ; Sun, 12 Jun 2016 01:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 UK4jY8Kx9SEh for ; Sun, 12 Jun 2016 01:03:03 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 477BC12D094 for ; Sun, 12 Jun 2016 01:03:03 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5C7xjJl016705; Sun, 12 Jun 2016 04:03:00 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 23guepqm80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Jun 2016 04:03:00 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5C830OG004198; Sun, 12 Jun 2016 04:03:00 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5C82rtT004154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jun 2016 04:02:57 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 12 Jun 2016 08:02:40 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.208]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0294.000; Sun, 12 Jun 2016 04:02:40 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/kFpuAgACq/ACAALkzRA== Date: Sun, 12 Jun 2016 08:02:39 +0000 Message-ID: <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-12_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606120096 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 08:03:07 -0000 I vote 3, don't use SIPS Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Jun 11, 2016, at 1:00 PM, Paul Kyzivat wrote: >=20 >> On 6/11/16 2:47 AM, Christer Holmberg wrote: >> Hi, >>=20 >>>> I think it's time to spend some time with TLS in SIPcore again. What >>>> do you think? >>>=20 >>> My memory is that the latest revision decided, as Keith says, that if y= ou make a call to a sips: URI, you > are guaranteed that every signaling st= ep is covered by TLS, or the call is rejected >>=20 >> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In re= ality there is no guarantee. >=20 > So the choices are: >=20 > 1) use SIPS as defined, meeting all the constraints > 2) use SIPS but cheat when convenient > 3) don't use SIPS >=20 > Can anyone cite are real deployments that meet (1)? I suspect there are n= one. >=20 > I hope nobody here is advocating (2). It has no useful security propertie= s. >=20 > Hence ISTM that (3) is the only deployable alternative. >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Jun 12 03:03:24 2016 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 3E76A12D544 for ; Sun, 12 Jun 2016 03:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ElD3npaRCqCj for ; Sun, 12 Jun 2016 03:03:21 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 99B4512B02A for ; Sun, 12 Jun 2016 03:03:19 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id C7B8E4281; Sun, 12 Jun 2016 12:03:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804B420@ESESSMB209.ericsson.se> Date: Sun, 12 Jun 2016 12:03:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C7FA7F2-0BC8-4333-8E7E-975F0A0EFC15@edvina.net> References: <53B14A35-EBF0-4FB1-A20A-59B5E0F7F63A@edvina.net> <7594FB04B1934943A5C02806D1A2204B3804B420@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Half-outbound thoughts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 10:03:23 -0000 > On 11 Jun 2016, at 08:54, Christer Holmberg = wrote: >=20 > Hi, >=20 > Another question for clarification. >=20 > Q3: >=20 > Slide #2 talks about "outbound requests". What does "outbound" refer = to? Requests somehow associated with the outbound mechanism, or the = direction of the requests? >=20 > If it's about the direction, shouldn't it then me "inbound", as the = requests is from the server to the UA? >=20 > If it's about requests associated with the outbound mechanism, I think = you need to clarify a bit what exactly you mean by that. Ok, I=E2=80=99ll take a look. Thank you! /O >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Olle E. Johansson [mailto:oej@edvina.net]=20 > Sent: 10 June 2016 15:44 > To: Christer Holmberg > Cc: Olle E Johansson ; SIPCORE > Subject: Re: [sipcore] Half-outbound thoughts >=20 >=20 >> On 10 Jun 2016, at 13:04, Olle E. Johansson wrote: >>=20 >>=20 >>> On 10 Jun 2016, at 12:10, Christer Holmberg = wrote: >>>=20 >>> Hi O, >>>=20 >>> A couple of questions on the slides: >>>=20 >>> Q1: Number of flows >>>=20 >>> You claim that Outbound mandates at least two flows. >>>=20 >>> I can find text saying that a UA must, as a minimum, support a set = of=20 >>> two outbound proxy URIs, and while the whole idea of Outbound is=20 >>> having multiple flows I don=C4=85t find any text saying that one = must=20 >>> configure two (or more) outbound proxy URIs. >> We=E2=80=99ve discussed this many times at SIPit and have parsed TWO = as a=20 >> must. I think you may be right though, that two is not required to=20 >> run, but the client must support using it. My failure. >>=20 >> Additional quote: >>=20 >> "If the set has more than >> one URI, the UAC MUST send a REGISTER request to at least two of the >> default outbound proxies from the set. =E2=80=9C >>=20 >> I will update the slides > An updated version (v1.1) is now available at = http://www.slideshare.net/oej/sip-half-outbound-random-notes >=20 > /O >>>=20 >>>=20 >>> Q2: Flow-management >>>=20 >>> Slide #14 says =C5=82No flow-management=CB=9B. What is meant by = that? That the=20 >>> keep-olives aren=C4=85t needed? >>>=20 >> That=E2=80=99s very badly written by me. We need flow management, but = not in=20 >> the outbound-style, with flow tokens and all that. Will update. >>=20 >> Thank you for very good feedback! >>=20 >> /O >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> On 10/06/16 12:46, "sipcore on behalf of Olle E. Johansson" >>> wrote: >>>=20 >>>> Friends, >>>> I=C4=85ve tried to collect my thoughts about TLS and Outbound in a = small=20 >>>> brainstorm-presentation. >>>>=20 >>>> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>>>=20 >>>> The chairs have alerted me to the fact that this may not be a=20 >>>> SIPcore issue which I agree with, but I think this is the proper=20 >>>> starting point for a general discussion between SIP people before = we=20 >>>> either drop the issue or drag it into dispatch. My apologies to the=20= >>>> chairs for using this attractive forum :-) >>>>=20 >>>> In short: >>>>=20 >>>> - very few seems to implement full outbound >>>> - some parts of outbound seems used >>>> - which parts is not documented >>>> - TLS between UA and server has a clear problem if outbound is not=20= >>>> used >>>>=20 >>>> I am toying with an idea for a simple extension that puts the=20 >>>> connection/flow management on the UA, allows the server to reuse = the=20 >>>> inbound TLS connection (without a client >>>> cert) after auth for outbound >>>> requests and also allows the server to remove associations in the=20= >>>> location database at connection close. >>>>=20 >>>> I think this documents what=C4=85s in use and formalises it with an=20= >>>> extension tag. >>>>=20 >>>> Please check my presentation and give me feedback. >>>>=20 >>>> Thanks! >>>> /O >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Jun 12 03:09:01 2016 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 D903612D579 for ; Sun, 12 Jun 2016 03:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AIdV2EEremxx for ; Sun, 12 Jun 2016 03:08:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 64F0812D58C for ; Sun, 12 Jun 2016 03:08:59 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 9A4A54281; Sun, 12 Jun 2016 12:08:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF1354F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Sun, 12 Jun 2016 12:09:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <949EF20990823C4C85C18D59AA11AD8BADF1354F@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 10:09:01 -0000 > On 10 Jun 2016, at 20:03, Drage, Keith (Nokia - GB) = wrote: >=20 > I agree that the SIPS URI is not dead, but it is clearly stated in RFC = 5630 (which updates RFC 3261) that a successful call using a SIPS URI = requires the use of TLS on each hop. Requests where this cannot be = fulfilled have to be rejected. >=20 > That is surely a big enough hint to only use it where that is what you = want. That=E2=80=99s the theory. But where=E2=80=99s the practise? I=E2=80=99ve = seen old SIPura/linksys/cisco phones where you could add a prefix to the = phone number and request a SIPS call. I guess zero calls was made using = that feature And even if the RFC says that TLS must be used in each hop, there=E2=80=99= s no guarantee of anything, especially if the call is routed over = another technology somewhere, like ISDN. Is that even allowed for SIPS? We struggled with this for a while in Asterisk, which is a multiprotocol = b2bua and did not find any good solution on how to handle SIPS in the dialplan or at all. And there was nothing to test with. For me, I haven=E2=80=99t seen any use of SIPS anywhere. I do see a lot = of TLS, used in default mode or opportunistic mode. But with SIP:=20 URI schemes. What=E2=80=99s the use case here? Is anyone really using SIPS anywhere = and is that use-case not possible to handle without SIPS: in the URI? /O >=20 > Keith >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson > Sent: 10 June 2016 10:52 > To: SIPCORE > Cc: Olle E Johansson > Subject: [sipcore] SIPS must die, die, die >=20 > Friends, >=20 > I think it=E2=80=99s time to kill the SIPS: uri. I know that some of = you thought it was dead, but it is not the case. >=20 > It doesn=E2=80=99t add anything, personally I don=E2=80=99t see it in = use anywhere and it confuses a lot of discussions about TLS usage in = SIP. >=20 > We need to see what happens if we remove SIPS: from the SIP playground = - what=E2=80=99s missing? >=20 > Questions arise: >=20 > - Can we live without SIPS: and without =E2=80=9C;transport=3DTLS=E2=80=9D= or do we need to take the transport parameter back? > - Can my TLS connection reuse idea (previous mail) solve UA to edge = proxy issues? > - Do we need TLS transport in VIA headers? > - Are we going to have to prepare for DTLS transport too? (See Dale = Worley=E2=80=99s previous emails) ? >=20 > I think it=E2=80=99s time to spend some time with TLS in SIPcore = again. What do you think? >=20 > /O >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 13 06:56:37 2016 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 85E6612D7A4 for ; Mon, 13 Jun 2016 06:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 TomPaDqb-vl6 for ; Mon, 13 Jun 2016 06:56:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8CD1A12D7B7 for ; Mon, 13 Jun 2016 06:56:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 401D9B1D14A67; Mon, 13 Jun 2016 13:56:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5DDuUPC028248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2016 13:56:30 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5DDuQFZ024044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jun 2016 15:56:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 13 Jun 2016 15:56:26 +0200 From: "Drage, Keith (Nokia - GB)" To: "DOLLY, MARTIN C" , Paul Kyzivat Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/kFpuAgACq/ACAALkzRIAB89MA Date: Mon, 13 Jun 2016 13:56:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se>, <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> In-Reply-To: <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 13:56:36 -0000 That option was clearly understood by the SIP WG when we did RFC 5630. Howe= ver it was decided to very clearly state what it meant so that both service= providers and users could decide whether to use it or not, and they still = have that freedom. I suspect the majority have chosen not to, but the optio= n is still there. Given that we spent so much time on providing RFC 5630 to update RFC 3261 i= n this area, I am reluctant to change the direction now - this achieved IET= F consensus. Keith P.S. I also take this opportunity to remember Francois Audet, who did such = a lot of work driving this document to completion. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: 12 June 2016 09:03 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] SIPS must die, die, die I vote 3, don't use SIPS Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: 609-903-3360 Email: md3135@att.com > On Jun 11, 2016, at 1:00 PM, Paul Kyzivat wrote: >=20 >> On 6/11/16 2:47 AM, Christer Holmberg wrote: >> Hi, >>=20 >>>> I think it's time to spend some time with TLS in SIPcore again.=20 >>>> What do you think? >>>=20 >>> My memory is that the latest revision decided, as Keith says, that=20 >>> if you make a call to a sips: URI, you > are guaranteed that every=20 >>> signaling step is covered by TLS, or the call is rejected >>=20 >> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In re= ality there is no guarantee. >=20 > So the choices are: >=20 > 1) use SIPS as defined, meeting all the constraints > 2) use SIPS but cheat when convenient > 3) don't use SIPS >=20 > Can anyone cite are real deployments that meet (1)? I suspect there are n= one. >=20 > I hope nobody here is advocating (2). It has no useful security propertie= s. >=20 > Hence ISTM that (3) is the only deployable alternative. >=20 > Thanks, > Paul >=20 > _______________________________________________ > 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 13 11:24:49 2016 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 8C32312D905 for ; Mon, 13 Jun 2016 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 g8jO5oY0WUhu for ; Mon, 13 Jun 2016 11:24:23 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 C38B312D11B for ; Mon, 13 Jun 2016 11:24:20 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u5DINcZb000463; Mon, 13 Jun 2016 14:24:17 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23geyamcu5-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 14:24:16 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 13 Jun 2016 14:24:15 -0400 From: "Peterson, Jon" To: "Drage, Keith (Nokia - GB)" , "DOLLY, MARTIN C" , Paul Kyzivat Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtJJyRZYItSEGGroXfIB854p/kFpuAgACq/ACAAPxBgIAB9SyA///VhwA= Date: Mon, 13 Jun 2016 18:24:14 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606130204 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 18:24:34 -0000 On the question of "cheating," the SIPS mechanism was originally intended to be used in concert with DNS records that advertised SIPS as a service: see the security considerations of RFC3263, for example. I'm not aware that RFC5630 overwrote any of that guidance. In some scenarios, this could make it possible to detect an intermediary downgrade from SIPS to SIP, as both the endpoints - the UAC that originally targeted a SIPS URI and the UAS or destination proxy advertising the URI - can collaborate to make sure SIPS is requested and expected. In highly mediated networks where SIP requests transit many hops, I'm sure SIPS is at best a nuisance. Its design optimized more for a trapezoid, or something close to it, than a PSTN-like network. I'd hesitate though to eliminate a signaling confidentiality mode for SIP that has some possibility of preventing pervasive metadata collection, even if we know there are some environments where that protection will not be provided. HTTPS is a nuisance in many highly mediated parts of the web, too. Jon Peterson Neustar, Inc. On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)" wrote: >That option was clearly understood by the SIP WG when we did RFC 5630. >However it was decided to very clearly state what it meant so that both >service providers and users could decide whether to use it or not, and >they still have that freedom. I suspect the majority have chosen not to, >but the option is still there. > >Given that we spent so much time on providing RFC 5630 to update RFC 3261 >in this area, I am reluctant to change the direction now - this achieved >IETF consensus. > >Keith > >P.S. I also take this opportunity to remember Francois Audet, who did >such a lot of work driving this document to completion. > >-----Original Message----- >From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >MARTIN C >Sent: 12 June 2016 09:03 >To: Paul Kyzivat >Cc: sipcore@ietf.org >Subject: Re: [sipcore] SIPS must die, die, die > >I vote 3, don't use SIPS > >Martin C Dolly >Lead Member of Technical Staff >Core & Government/Regulatory Standards >AT&T >Cell: 609-903-3360 >Email: md3135@att.com > >> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat wrote: >>=20 >>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>> Hi, >>>=20 >>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>> What do you think? >>>>=20 >>>> My memory is that the latest revision decided, as Keith says, that >>>> if you make a call to a sips: URI, you > are guaranteed that every >>>> signaling step is covered by TLS, or the call is rejected >>>=20 >>> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In >>>reality there is no guarantee. >>=20 >> So the choices are: >>=20 >> 1) use SIPS as defined, meeting all the constraints >> 2) use SIPS but cheat when convenient >> 3) don't use SIPS >>=20 >> Can anyone cite are real deployments that meet (1)? I suspect there are >>none. >>=20 >> I hope nobody here is advocating (2). It has no useful security >>properties. >>=20 >> Hence ISTM that (3) is the only deployable alternative. >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> 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 13 12:36:41 2016 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 5E00A12D977 for ; Mon, 13 Jun 2016 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ntVzYaQhsoOg for ; Mon, 13 Jun 2016 12:36:24 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 7B99412D99C for ; Mon, 13 Jun 2016 12:36:24 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5DJX8Lr027428; Mon, 13 Jun 2016 15:36:20 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23gd9ucfve-12 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 15:36:20 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Mon, 13 Jun 2016 15:36:09 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoA Date: Mon, 13 Jun 2016 19:36:08 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3842CA219BA97jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606130214 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 19:36:40 -0000 --_000_D3842CA219BA97jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to play back the general problem statement, I think we'd agree that of= your three numbered possible solutions, #1 is more or less the assumed bas= eline SIP behavior - cases where, for example, the server would send a Dige= st challenge in the backwards direction to authenticate the user agent and = then make any authorization decision based on its own ACLs or what have you= . Your solutions #2 and #3 cover the two cases I think are interesting: SSO= -like ones where relying parties trust an identity assertion provided by an= IdP of some sort (#2) and cases where the identity information is not incl= uded at all (or is at least optional) and instead the relying party trusts = traits or attributes or what have you provided by the IdP. I've argued that= SIP has always been able to do #1, that we at least already have some ways= to do #2, and that we've already done requirements for #3 (RFC4484) but to= date have gone no farther, and that it would be new work if we were to spe= cify protocol for #3. So yes, the third option is where we need to focus. But the point of my las= t mail was to say that what we need to narrow our discussion down to what t= he attributes are that we imagine applications in these use cases will requ= ire to process SIP requests, primarily SIP INVITE requests. You say some hi= gh-level things below like that your third-option token "might grant the us= er access to multiple services" on the conference service which is your rel= ying party. In terms of concrete authorization traits for this use case, to= wards the very end you suggest attributes of a conference like the number o= f participants or the media types permitted in the conference. Radhika sent a helpful summary of conference control protocols to the list = which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actuall= y let you manage attributes of a conference like the number of participants= and media types allowed. The interesting thing about protocols like CCMP i= s that they are not, you know, actually transported by SIP. CCMP is transpo= rted by HTTP. Why? Because the semantics of conference control doesn't actu= ally map onto SIP INVITE transactions very well. They map quite aptly to HT= TP, and in the HTTP context, you can certainly use OAuth if you like. You e= ven will find some text about Role-Based Access Control in the XCON (RFC650= 3) security consideration. Although you can use SIP and SDP to set up a BFC= P connection (RFC4583), the security of BFCP relies on mutual TLS between i= ts own endpoints. It is unclear to me what carrying attribute information a= round in a SIP INVITE would accomplish with regards to authorizing CCMP or = BFCP transactions. So again, the point of my last mail was that the problem of authorizing SIP= INVITEs is actually different from the problem of authorizing generic appl= ication transactions. SIP INVITEs still have more or less the semantics of = a call setup message: they are requesting that a session be initiated. Conf= erence control is not managed with SIP transactions, and the security of co= nference control protocols does not devolve to authorizing SIP transactions= . I suspect we'll find that most of the other security attributes that "app= lications" need to do their jobs similarly don't map onto the semantics of = a SIP INVITE - but, I'm still open to entertaining examples that might cast= doubt on that suspicion. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, June 9, 2016 at 10:59 AM To: Jon Peterson = > Cc: Christer Holmberg >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Hi Jon, Sorry for the delayed reply. Let's take the video conference example, and discuss the possible ways for = the conference server to provide service. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Possible solutions: 1. Conference Server acts as an AuthN and AuthZ server. Requests to the ser= ver must provide an identity and credentials, and services will be provided= based on locally stored information associated with the identity provided = in the request. 2. Conference Server acts as an AuthZ server, but delegates the AuthN part.= Requests to the server must provide an identity token, and services will b= e provided based on locally stored information associated with the identity= provided in the token. 3. Conference Server delegates both AuthN and AuthZ parts. Requests to the = server must provide an access token, which might or might not include infor= mation about the user requesting the service, and services will be provided= based on information provided in the access token or as a result of an int= rospection step using the access token. Now, let's look at the 3rd option a bit more, and assume that the server pr= ovides the following types of conference services: 1. audio conference 2. audio/video conference 3. web conference or some combination of the above. Let's also assume that the server allows control over the number of partici= pants allowed in each one of these conference types or combinations. Here is one way that I envisioned we could use to address this use case: When an enterprise user in the 1st trust domain wants to register with the = SIP Proxy, it will have to authenticate to the IdP and as a result either t= he UA or the Proxy (depends on the UA's capabilities) will be provided with= an AuthN and AuthZ tokens. This process could involve an interim step to a= llow only the proxy to get access to the tokens, or the tokens could be sen= t to the UA which will then use them to communicate with the proxy. The AuthN token is the identity of the user, and the AuthZ token has all th= e services granted to the user by the IdP/AuthZ Service. When the enterprise user needs access to the conference service, the UA wil= l send an INVITE to the Proxy, and will include the AuthZ token if it is in= possession of the tokens; otherwise, the proxy will add the appropriate to= ken to the outgoing INVITE sent to the conference server. The scope of the AuthZ token might grant the user access to multiple servic= es; to avoid sending that AuthZ token to all servers providing services gra= nted to the user, the proxy could obtain a different token with limited sco= pe that is specific to the service being provided (conference services in t= his case); there is a standard Token Exchange mechanism for that. The AuthZ token will include information about the type of service allowed = (audio, audio/video, etc), and the limit on the number of participants. The= AuthZ token might or might not have any information about the user request= ing the service, which depends on the level of privacy needed. When the conference server receives this token in the SIP INVITE, all it ha= s to do is validate that the token was signed by an IdP that it has a trust= relationship with, and provide the service requested by the AuthZ token. T= he conference server does not need the AuthN token to be able to provide a = service. Regards, Rifaat On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon > wrote: Also, if we decided to separate the AuthN and AuthZ, then we might need to = carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to th= e UA; in this case there is a need for an interim step to get the token(s) = to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries. Jon Peterson Neustar, Inc. --_000_D3842CA219BA97jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Just to play back the general problem statement, I think we'd agree th= at of your three numbered possible solutions, #1 is more or less the assume= d baseline SIP behavior - cases where, for example, the server would send a= Digest challenge in the backwards direction to authenticate the user agent and then make any authorization d= ecision based on its own ACLs or what have you. Your solutions #2 and #3 co= ver the two cases I think are interesting: SSO-like ones where relying part= ies trust an identity assertion provided by an IdP of some sort (#2) and cases where the identity informat= ion is not included at all (or is at least optional) and instead the relyin= g party trusts traits or attributes or what have you provided by the IdP. I= 've argued that SIP has always been able to do #1, that we at least already have some ways to do #2, and that = we've already done requirements for #3 (RFC4484) but to date have gone no f= arther, and that it would be new work if we were to specify protocol for #3= .

So yes, the third option is where we need to focus. But the point of m= y last mail was to say that what we need to narrow our discussion down to w= hat the attributes are that we imagine applications in these use cases will= require to process SIP requests, primarily SIP INVITE requests. You say some high-level things below like t= hat your third-option token "might grant the user access to multiple s= ervices" on the conference service which is your relying party. In ter= ms of concrete authorization traits for this use case, towards the very end you suggest attributes of a conference like= the number of participants or the media types permitted in the conference.=

Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed. The interesting thing about protocols like CCMP is that they are not, you know= , actually transported by SIP. CCMP is transported by HTTP. Why? Because th= e semantics of conference control doesn't actually map onto SIP INVITE tran= sactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OAuth if you= like. You even will find some text about Role-Based Access Control in the = XCON (RFC6503) security consideration. Although you can use SIP and SDP to = set up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS between its own endpoints. It is= unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

So again, the point of my last mail was that the problem of authorizin= g SIP INVITEs is actually different from the problem of authorizing generic= application transactions. SIP INVITEs still have more or less the semantic= s of a call setup message: they are requesting that a session be initiated. Conference control is not mana= ged with SIP transactions, and the security of conference control protocols= does not devolve to authorizing SIP transactions. I suspect we'll find tha= t most of the other security attributes that "applications" need to do their jobs similarly don't map on= to the semantics of a SIP INVITE - but, I'm still open to entertaining exam= ples that might cast doubt on that suspicion. 

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Thursday, June 9, 2016 at 10:= 59 AM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@ietf.org"= ; <sipcore@ietf.org>
Subject: Re: [sipcore] SIP AuthNZ P= roblem Statement - v3

Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference exa= mple, and discuss the possible ways for the conference server to provide service.


         T= rust Domain 1              :   &nbs= p;Internet     :  Trust Domain 2
          =                      = ;      :               &n= bsp; :
          =             +--------+     = :                 :
          =             | IdP    |    = ; :                 :
        +--= -----------| AuthZ  |     :         &nbs= p;       :
        |  = ;           |        |   =   :                 :
        |  = ;           +--------+     : &nb= sp;               :
        |  = ;               |       &= nbsp;  :                 :
        |  = ;               |       &= nbsp;  :                 :
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
    |      = ;  |        | SIP    |     : &= nbsp;               :     | SI= P App|
    |   UA   |-= -------| Proxy  |-----:-----------------:-----| Video  |
    |      = ;  |        |        |   =   :                 :   &= nbsp; | Conference
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
          =                      = ;      :               &n= bsp; :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the server must provide an identity a= nd credentials, and services will be provided based on locally stored = information associated with the identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part. Requests to the server must p= rovide an identity token, and services will be provided based on local= ly stored information associated with the identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the server must provide an access = token, which might or might not include information about the user req= uesting the service, and services will be provided based on information provided in the access token or as a result of a= n introspection step using the access token.


Now, let's look at the 3rd option a= bit more, and assume that the server provides the following types of = conference services:
1. audio conference
2. audio/video conference
3. web conference

or some combination of th= e above.

Let's also assume that the server a= llows control over the number of participants allowed in each one of t= hese conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the SIP Proxy, it will have to authenti= cate to the IdP and as a result either the UA or the Proxy (depends on= the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step = ;to allow only the proxy to get access to the tokens, or the tokens could b= e sent to the UA which will then use them to communicate with the prox= y.

The AuthN token is the identity of the user, and the AuthZ token has all&nb= sp;the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA&nbs= p;will send an INVITE to the Proxy, and will include the AuthZ token if it = is in possession of the tokens; otherwise, the proxy will add the appr= opriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple s= ervices; to avoid sending that AuthZ token to all servers providing se= rvices granted to the user, the proxy could obtain a different token with&n= bsp;limited scope that is specific to the service being provided (conference services in this case); there is a standar= d Token Exchange mechanism for that.

The AuthZ token will include information about the type of service allowed&= nbsp;(audio, audio/video, etc), and the limit on the number of participants= . The AuthZ token might or might not have any information about the us= er requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it&nb= sp;has to do is validate that the token was signed by an IdP that it has a&= nbsp;trust relationship with, and provide the service requested by the Auth= Z token. The conference server does not need the AuthN token to be able to provide a service.

Regards,
 Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or less= what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond requir= ements. Today, I think that much of the useful work that could be done on t= he authorization question is in identifying which SIP authorization policie= s are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.  The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lot of= light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who op= ens the conference bridge needs to be charged, that's identity information = - which in its usual form will convey the individual user and their domain,= like user@domain. If you need more complex semantics than that, it's probably because you're doing something = more complicated than just calling in to the conference. But it's less clea= r to me why you'd use SIP for such cases. Drilling down deeper into these u= se cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which larg= ely involve billing (including when dealing with various protocol gateways)= and resource management (both preemption and priority), ultimately didn't = seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.&n= bsp;

Jon Peterson
Neustar, Inc.

 --_000_D3842CA219BA97jonpetersonneustarbiz_-- From nobody Mon Jun 13 13:24:42 2016 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 0189112D9D8 for ; Mon, 13 Jun 2016 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 J-nk6FZp83Wx for ; Mon, 13 Jun 2016 13:24:29 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id AC15812D9D2 for ; Mon, 13 Jun 2016 13:23:29 -0700 (PDT) Received: (qmail 7817 invoked by uid 0); 13 Jun 2016 20:23:28 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 13 Jun 2016 20:23:28 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 6LPN1t00t1MNPNq01LPRhe; Mon, 13 Jun 2016 14:23:26 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=fGh7L_e3oJcA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=9qxNCY_qAAAA:8 a=zQP7CpKOAAAA:8 a=r_gBzHlu8Kee2iCqSr4A:9 a=czYnZLJg6BYG85Zj:21 a=9YohuJi0uE6oPp45:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Q-ofuW86YyylptHqTH-7:22 a=A2X48xt2e1hG9NJDz63Y:22 a=obGFCI3_7AGB19sD6zJV:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=YdmEddH0TcwESMI2ekuFLFARMkohKSK/+9NqZ3y+U7A=; b=WHKyhZuUJZEldC0Yedvkd1yJMt 1+h56Ksv8mENBbJu0+SsUgEDkwZWgdVYBtAt1zv5ULnntqYjzAD3juxKjMPZ3ZjMpEi0CJlDVEQ23 GNAs7Mh7dHm4Ok0zK/SN0q3jp; Received: from [100.36.21.178] (port=60680 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bCYOK-0001yi-2z; Mon, 13 Jun 2016 14:23:24 -0600 User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Mon, 13 Jun 2016 16:23:15 -0400 From: Richard Shockey To: "Peterson, Jon" , "Drage, Keith (Nokia - GB)" , "DOLLY, MARTIN C" , Paul Kyzivat Message-ID: Thread-Topic: [sipcore] SIPS must die, die, die References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.21.178 authed with richard+shockey.us} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-Source-IP: 100.36.21.178 X-Exim-ID: 1bCYOK-0001yi-2z X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.152]) [100.36.21.178]:60680 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 20:24:41 -0000 On 6/13/16, 2:24 PM, "sipcore on behalf of Peterson, Jon" wrote: > >On the question of "cheating," the SIPS mechanism was originally intended >to be used in concert with DNS records that advertised SIPS as a service: >see the security considerations of RFC3263, for example. I'm not aware >that RFC5630 overwrote any of that guidance. In some scenarios, this could >make it possible to detect an intermediary downgrade from SIPS to SIP, as >both the endpoints - the UAC that originally targeted a SIPS URI and the >UAS or destination proxy advertising the URI - can collaborate to make >sure SIPS is requested and expected. > >In highly mediated networks where SIP requests transit many hops, I'm sure >SIPS is at best a nuisance.=20 RS> That is an understatement. SIPS is not used in virtually any component= of the carrier based Public SIP Networks that rely on E.164 naming that I k= now of. Though it is specified as MUST support in the SIP Forum SIPConnect p= rofiles for PBX to SP on the wire integration to my knowledge it has never b= een implemented by any vendor or SSP. In short SIPS is a total Pain in the = Ass. Given the appalling track record the IETF has in designing implementab= le security protocols, I question whether this effort is worth the time. Bu= t that=E2=80=99s OK ..if people want to tilt at windmills, be my guest. What I wa= nt to know is does anyone really care?=20 Its design optimized more for a trapezoid, or >something close to it, than a PSTN-like network. I'd hesitate though to >eliminate a signaling confidentiality mode for SIP that has some >possibility of preventing pervasive metadata collection, even if we know >there are some environments where that protection will not be provided. >HTTPS is a nuisance in many highly mediated parts of the web, too. > >Jon Peterson >Neustar, Inc. > >On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)" > wrote: > >>That option was clearly understood by the SIP WG when we did RFC 5630. >>However it was decided to very clearly state what it meant so that both >>service providers and users could decide whether to use it or not, and >>they still have that freedom. I suspect the majority have chosen not to, >>but the option is still there. >> >>Given that we spent so much time on providing RFC 5630 to update RFC 3261 >>in this area, I am reluctant to change the direction now - this achieved >>IETF consensus. >> >>Keith >> >>P.S. I also take this opportunity to remember Francois Audet, who did >>such a lot of work driving this document to completion. >> >>-----Original Message----- >>From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >>MARTIN C >>Sent: 12 June 2016 09:03 >>To: Paul Kyzivat >>Cc: sipcore@ietf.org >>Subject: Re: [sipcore] SIPS must die, die, die >> >>I vote 3, don't use SIPS >> >>Martin C Dolly >>Lead Member of Technical Staff >>Core & Government/Regulatory Standards >>AT&T >>Cell: 609-903-3360 >>Email: md3135@att.com >> >>> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat wrote= : >>>=20 >>>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>>> What do you think? >>>>>=20 >>>>> My memory is that the latest revision decided, as Keith says, that >>>>> if you make a call to a sips: URI, you > are guaranteed that every >>>>> signaling step is covered by TLS, or the call is rejected >>>>=20 >>>> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In >>>>reality there is no guarantee. >>>=20 >>> So the choices are: >>>=20 >>> 1) use SIPS as defined, meeting all the constraints >>> 2) use SIPS but cheat when convenient >>> 3) don't use SIPS >>>=20 >>> Can anyone cite are real deployments that meet (1)? I suspect there are >>>none. >>>=20 >>> I hope nobody here is advocating (2). It has no useful security >>>properties. >>>=20 >>> Hence ISTM that (3) is the only deployable alternative. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> 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 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 00:36:56 2016 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 D788212DB5F for ; Tue, 14 Jun 2016 00:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rKFK5t2PhGP1 for ; Tue, 14 Jun 2016 00:36:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 C0FAA12DB55 for ; Tue, 14 Jun 2016 00:36:51 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 5785D4281; Tue, 14 Jun 2016 09:36:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Jun 2016 09:36:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 07:36:55 -0000 > On 13 Jun 2016, at 20:24, Peterson, Jon = wrote: >=20 >=20 > On the question of "cheating," the SIPS mechanism was originally = intended > to be used in concert with DNS records that advertised SIPS as a = service: > see the security considerations of RFC3263, for example. I'm not aware > that RFC5630 overwrote any of that guidance. In some scenarios, this = could > make it possible to detect an intermediary downgrade from SIPS to SIP, = as > both the endpoints - the UAC that originally targeted a SIPS URI and = the > UAS or destination proxy advertising the URI - can collaborate to make > sure SIPS is requested and expected. >=20 > In highly mediated networks where SIP requests transit many hops, I'm = sure > SIPS is at best a nuisance. Its design optimized more for a trapezoid, = or > something close to it, than a PSTN-like network. I'd hesitate though = to > eliminate a signaling confidentiality mode for SIP that has some > possibility of preventing pervasive metadata collection, even if we = know > there are some environments where that protection will not be = provided. > HTTPS is a nuisance in many highly mediated parts of the web, too. >=20 I think we need to start with =E2=80=9Cwhat if we remove SIPS=E2=80=9D = and go back and see what=E2=80=99s missing and how we can fix that. A lot of people = point to SIPS as the solution - but no one is implementing or using it.=20 What is the problem it solves? Is there another way? What=E2=80=99s the = status for=20 S/MIME. I don=E2=80=99t think we=E2=80=99ll find that the answer is SIPS: as a = URI scheme, but the SIP over TLS transport is still very much needed, discovered by = NAPTR/SRV and supported by DANE or some other PKI structure. /O > Jon Peterson > Neustar, Inc. >=20 > On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)" > wrote: >=20 >> That option was clearly understood by the SIP WG when we did RFC = 5630. >> However it was decided to very clearly state what it meant so that = both >> service providers and users could decide whether to use it or not, = and >> they still have that freedom. I suspect the majority have chosen not = to, >> but the option is still there. >>=20 >> Given that we spent so much time on providing RFC 5630 to update RFC = 3261 >> in this area, I am reluctant to change the direction now - this = achieved >> IETF consensus. >>=20 >> Keith >>=20 >> P.S. I also take this opportunity to remember Francois Audet, who did >> such a lot of work driving this document to completion. >>=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >> MARTIN C >> Sent: 12 June 2016 09:03 >> To: Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] SIPS must die, die, die >>=20 >> I vote 3, don't use SIPS >>=20 >> Martin C Dolly >> Lead Member of Technical Staff >> Core & Government/Regulatory Standards >> AT&T >> Cell: 609-903-3360 >> Email: md3135@att.com >>=20 >>> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat = wrote: >>>=20 >>>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>>> What do you think? >>>>>=20 >>>>> My memory is that the latest revision decided, as Keith says, that >>>>> if you make a call to a sips: URI, you > are guaranteed that every >>>>> signaling step is covered by TLS, or the call is rejected >>>>=20 >>>> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. = In >>>> reality there is no guarantee. >>>=20 >>> So the choices are: >>>=20 >>> 1) use SIPS as defined, meeting all the constraints >>> 2) use SIPS but cheat when convenient >>> 3) don't use SIPS >>>=20 >>> Can anyone cite are real deployments that meet (1)? I suspect there = are >>> none. >>>=20 >>> I hope nobody here is advocating (2). It has no useful security >>> properties. >>>=20 >>> Hence ISTM that (3) is the only deployable alternative. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 00:43:44 2016 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 C9C6012DB5E for ; Tue, 14 Jun 2016 00:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 04wy4VBbsS5l for ; Tue, 14 Jun 2016 00:43:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 54FD012DB4F for ; Tue, 14 Jun 2016 00:43:41 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id E45694281; Tue, 14 Jun 2016 09:43:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Jun 2016 09:43:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Richard Shockey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 07:43:44 -0000 > On 13 Jun 2016, at 22:23, Richard Shockey wrote: >=20 >=20 > On 6/13/16, 2:24 PM, "sipcore on behalf of Peterson, Jon" = wrote: >=20 >>=20 >> On the question of "cheating," the SIPS mechanism was originally = intended >> to be used in concert with DNS records that advertised SIPS as a = service: >> see the security considerations of RFC3263, for example. I'm not = aware >> that RFC5630 overwrote any of that guidance. In some scenarios, this = could >> make it possible to detect an intermediary downgrade from SIPS to = SIP, as >> both the endpoints - the UAC that originally targeted a SIPS URI and = the >> UAS or destination proxy advertising the URI - can collaborate to = make >> sure SIPS is requested and expected. >>=20 >> In highly mediated networks where SIP requests transit many hops, I'm = sure >> SIPS is at best a nuisance.=20 >=20 > RS> That is an understatement. SIPS is not used in virtually any = component of the carrier based Public SIP Networks that rely on E.164 = naming that I know of. Though it is specified as MUST support in the SIP = Forum SIPConnect profiles for PBX to SP on the wire integration to my = knowledge it has never been implemented by any vendor or SSP. In short = SIPS is a total Pain in the Ass. Given the appalling track record the = IETF has in designing implementable security protocols, I question = whether this effort is worth the time. But that=E2=80=99s OK ..if = people want to tilt at windmills, be my guest. What I want to know is = does anyone really care?=20 My point is that a lot of people falsely believe that SIPS: is the way = to go for SIP security and do not do=20 anything and certainly doesn=E2=80=99t even try to understand the = complexity of SIPS: We can start with removing SIPS: or start in the other end with SIP = security. Media seems to be the target of SIPBRANDY but my feeling is that SIP is an issue. As stated many times, this was a problem we discovered hard at SIPit - = where implementations registred contacts using =E2=80=9C;transport=3DTLS=E2=80=9D and not using SIPS: - = and did not have any client certificates. It=E2=80=99s a mess and I feel that we need to clean this up in orders = for developers to know where to go. /O >=20 >=20 > Its design optimized more for a trapezoid, or >> something close to it, than a PSTN-like network. I'd hesitate though = to >> eliminate a signaling confidentiality mode for SIP that has some >> possibility of preventing pervasive metadata collection, even if we = know >> there are some environments where that protection will not be = provided. >> HTTPS is a nuisance in many highly mediated parts of the web, too. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)" >> wrote: >>=20 >>> That option was clearly understood by the SIP WG when we did RFC = 5630. >>> However it was decided to very clearly state what it meant so that = both >>> service providers and users could decide whether to use it or not, = and >>> they still have that freedom. I suspect the majority have chosen not = to, >>> but the option is still there. >>>=20 >>> Given that we spent so much time on providing RFC 5630 to update RFC = 3261 >>> in this area, I am reluctant to change the direction now - this = achieved >>> IETF consensus. >>>=20 >>> Keith >>>=20 >>> P.S. I also take this opportunity to remember Francois Audet, who = did >>> such a lot of work driving this document to completion. >>>=20 >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >>> MARTIN C >>> Sent: 12 June 2016 09:03 >>> To: Paul Kyzivat >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] SIPS must die, die, die >>>=20 >>> I vote 3, don't use SIPS >>>=20 >>> Martin C Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T >>> Cell: 609-903-3360 >>> Email: md3135@att.com >>>=20 >>>> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat = wrote: >>>>=20 >>>>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>>>> What do you think? >>>>>>=20 >>>>>> My memory is that the latest revision decided, as Keith says, = that >>>>>> if you make a call to a sips: URI, you > are guaranteed that = every >>>>>> signaling step is covered by TLS, or the call is rejected >>>>>=20 >>>>> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. = In >>>>> reality there is no guarantee. >>>>=20 >>>> So the choices are: >>>>=20 >>>> 1) use SIPS as defined, meeting all the constraints >>>> 2) use SIPS but cheat when convenient >>>> 3) don't use SIPS >>>>=20 >>>> Can anyone cite are real deployments that meet (1)? I suspect there = are >>>> none. >>>>=20 >>>> I hope nobody here is advocating (2). It has no useful security >>>> properties. >>>>=20 >>>> Hence ISTM that (3) is the only deployable alternative. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 01:49:03 2016 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 40DB412D0F3 for ; Tue, 14 Jun 2016 01:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 ZCd0Iizil3_N for ; Tue, 14 Jun 2016 01:49:01 -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 2F9E312D0EF for ; Tue, 14 Jun 2016 01:49:01 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.162]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5E8mkMi091770 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Jun 2016 03:48:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.162] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Olle E. Johansson" Date: Tue, 14 Jun 2016 09:48:44 +0100 Message-ID: In-Reply-To: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 08:49:02 -0000 On 14 Jun 2016, at 8:43, Olle E. Johansson wrote: > RS> That is an understatement. SIPS is not used in virtually any > component of the carrier based Public SIP Networks that rely on E.164 > naming that I know of. Though it is specified as MUST support in the > SIP Forum SIPConnect profiles for PBX to SP on the wire integration to > my knowledge it has never been implemented by any vendor or SSP. In > short SIPS is a total Pain in the Ass. Given the appalling track > record the IETF has in designing implementable security protocols, I > question whether this effort is worth the time. But that’s OK ..if > people want to tilt at windmills, be my guest. What I want to know is > does anyone really care? > > > My point is that a lot of people falsely believe that SIPS: is the way > to go for SIP security and do not do > anything and certainly doesn’t even try to understand the complexity > of SIPS: > > We can start with removing SIPS: or start in the other end with SIP > security. Media seems to be > the target of SIPBRANDY but my feeling is that SIP is an issue. SIPBRANDY will target SIP-signaled media. SIP security certainly matters for that. Whether or not the group has anything to say about SIPS is up to the group to decide. (But my guess from the work so far is that the group will focus more on using STIR/4474bis to protect fingerprints, etc.) > > As stated many times, this was a problem we discovered hard at SIPit - > where implementations registred > contacts using “;transport=TLS†and not using SIPS: - and did not > have any client certificates. > > It’s a mess and I feel that we need to clean this up in orders for > developers to know where to go. From nobody Tue Jun 14 01:49:15 2016 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 E4BF312D0EC for ; Tue, 14 Jun 2016 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ONUm2C0vb7cI for ; Tue, 14 Jun 2016 01:49:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEB012D0EF for ; Tue, 14 Jun 2016 01:49:03 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-8d-575fc4fde06a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 61.A3.12926.DF4CF575; Tue, 14 Jun 2016 10:49:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 10:48:59 +0200 From: Christer Holmberg To: "Olle E. Johansson" , "Peterson, Jon" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtAcjdwYYWLUaapNCZA/0nQZ/j0xwwgACJ5gCAAPxBgIAB9SyAgABK1ACAAN1wgIAAR26A Date: Tue, 14 Jun 2016 08:48:59 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> In-Reply-To: <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3B6453A0E035E74EB2CC5EA350B29BB4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7tO7fI/HhBg2PdCzONFhaHHrwlN3i 5epDzBZff2xic2DxeNk/h9Fj2tqVrB5Llvxk8tjR8Jw5gCWKyyYlNSezLLVI3y6BK2P93tds BYflK258aGZqYLwh2cXIySEhYCJxs/s5I4QtJnHh3nq2LkYuDiGBI4wSd/pnM0M4SxglGp7f Ye9i5OBgE7CQ6P6nDdIgIhAmcfD4L7BmZgFfiQVHXzKD2MICehITVq5khajRl/i74D8ThB0l seNtDzuIzSKgKrGq/wpYPa+AlcT5mx+gdh1lltjc8g1sKKeAncTlKcfAGhiBrvt+ag0TxDJx iVtP5jNBXC0gsWTPeWYIW1Ti5eN/YItFgY74cm8e1GeKEjvPtjND9OpJ3Jg6BehLdiDbWmJh OERUW2LZwtdQ5whKnJz5hGUCo8QsJMtmIWmeBdc8C0nzLCTNCxhZVzGKFqcWJ+WmGxnrpRZl JhcX5+fp5aWWbGIExunBLb9VdzBefuN4iFGAg1GJh/eBTny4EGtiWXFl7iFGCQ5mJRFejYNA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYyTvIrqjpxe VDhfyKLfRXGjSuDrOYFT467Gt7pZnn5SPfstfyjntp5nNg7hvN/qHzzL+bQgKzbyzrmI1ifN Z2Qr0ziWbahO0u78F1T05Hhlfv4x9bvWvUFd02pyn2u1vF1WmrMtb9mJPw9mbVffPqUi3DVn 6gemHv37tXcSVGK7Q2ZKH097YKjEUpyRaKjFXFScCABgxpsZzwIAAA== Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 08:49:06 -0000 Hi, ... >I think we need to start with =B3what if we remove SIPS=B2 and go back and >see what=B9s missing and how we can fix that. A lot of people point to SIP= S >as >the solution - but no one is implementing or using it. > >What is the problem it solves? Is there another way? What=B9s the status >for=20 >S/MIME. Nobody does that either. And, it wouldn=B9t guarantee anything either, woul= d it? >I don=B9t think we=B9ll find that the answer is SIPS: as a URI scheme, but= the >SIP over TLS transport is still very much needed, discovered by NAPTR/SRV >and supported by DANE or some other PKI structure. You can already do SIP over TLS using the SIP: scheme - just establish a TLS connection and send your message :) Regards, Christer >> Jon Peterson >> Neustar, Inc. >>=20 >> On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)" >> wrote: >>=20 >>> That option was clearly understood by the SIP WG when we did RFC 5630. >>> However it was decided to very clearly state what it meant so that both >>> service providers and users could decide whether to use it or not, and >>> they still have that freedom. I suspect the majority have chosen not >>>to, >>> but the option is still there. >>>=20 >>> Given that we spent so much time on providing RFC 5630 to update RFC >>>3261 >>> in this area, I am reluctant to change the direction now - this >>>achieved >>> IETF consensus. >>>=20 >>> Keith >>>=20 >>> P.S. I also take this opportunity to remember Francois Audet, who did >>> such a lot of work driving this document to completion. >>>=20 >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >>> MARTIN C >>> Sent: 12 June 2016 09:03 >>> To: Paul Kyzivat >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] SIPS must die, die, die >>>=20 >>> I vote 3, don't use SIPS >>>=20 >>> Martin C Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T >>> Cell: 609-903-3360 >>> Email: md3135@att.com >>>=20 >>>> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat >>>>wrote: >>>>=20 >>>>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>>>> What do you think? >>>>>>=20 >>>>>> My memory is that the latest revision decided, as Keith says, that >>>>>> if you make a call to a sips: URI, you > are guaranteed that every >>>>>> signaling step is covered by TLS, or the call is rejected >>>>>=20 >>>>> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In >>>>> reality there is no guarantee. >>>>=20 >>>> So the choices are: >>>>=20 >>>> 1) use SIPS as defined, meeting all the constraints >>>> 2) use SIPS but cheat when convenient >>>> 3) don't use SIPS >>>>=20 >>>> Can anyone cite are real deployments that meet (1)? I suspect there >>>>are >>>> none. >>>>=20 >>>> I hope nobody here is advocating (2). It has no useful security >>>> properties. >>>>=20 >>>> Hence ISTM that (3) is the only deployable alternative. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> 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 14 02:03:44 2016 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 35F5F12D119 for ; Tue, 14 Jun 2016 02:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KplwWuK9vXM0 for ; Tue, 14 Jun 2016 02:03:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 0980512D131 for ; Tue, 14 Jun 2016 02:03:34 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1E73C4281; Tue, 14 Jun 2016 11:03:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Jun 2016 11:03:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F843EF2-152D-495D-B28E-05B13DA7C556@edvina.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 09:03:42 -0000 > On 14 Jun 2016, at 10:48, Ben Campbell wrote: >=20 >=20 >=20 > On 14 Jun 2016, at 8:43, Olle E. Johansson wrote: >=20 >> RS> That is an understatement. SIPS is not used in virtually any = component of the carrier based Public SIP Networks that rely on E.164 = naming that I know of. Though it is specified as MUST support in the SIP = Forum SIPConnect profiles for PBX to SP on the wire integration to my = knowledge it has never been implemented by any vendor or SSP. In short = SIPS is a total Pain in the Ass. Given the appalling track record the = IETF has in designing implementable security protocols, I question = whether this effort is worth the time. But that=E2=80=99s OK ..if = people want to tilt at windmills, be my guest. What I want to know is = does anyone really care? >>=20 >>=20 >> My point is that a lot of people falsely believe that SIPS: is the = way to go for SIP security and do not do >> anything and certainly doesn=E2=80=99t even try to understand the = complexity of SIPS: >>=20 >> We can start with removing SIPS: or start in the other end with SIP = security. Media seems to be >> the target of SIPBRANDY but my feeling is that SIP is an issue. >=20 > SIPBRANDY will target SIP-signaled media. SIP security certainly = matters for that. Whether or not the group has anything to say about = SIPS is up to the group to decide. (But my guess from the work so far = is that the group will focus more on using STIR/4474bis to protect = fingerprints, etc.) That was my guess too :-) /O >=20 >>=20 >> As stated many times, this was a problem we discovered hard at SIPit = - where implementations registred >> contacts using =E2=80=9C;transport=3DTLS=E2=80=9D and not using SIPS: = - and did not have any client certificates. >>=20 >> It=E2=80=99s a mess and I feel that we need to clean this up in = orders for developers to know where to go. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 02:05:10 2016 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 304A012D122 for ; Tue, 14 Jun 2016 02:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 p3kJfvonUJEv for ; Tue, 14 Jun 2016 02:05:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 A406C12D119 for ; Tue, 14 Jun 2016 02:05:03 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 67BA14281; Tue, 14 Jun 2016 11:05:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Jun 2016 11:05:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 09:05:08 -0000 > On 14 Jun 2016, at 10:48, Christer Holmberg = wrote: >=20 > Hi, >=20 > ... >=20 >> I think we need to start with =C2=B3what if we remove SIPS=C2=B2 and = go back and >> see what=C2=B9s missing and how we can fix that. A lot of people = point to SIPS >> as >> the solution - but no one is implementing or using it. >>=20 >> What is the problem it solves? Is there another way? What=C2=B9s the = status >> for=20 >> S/MIME. >=20 > Nobody does that either. And, it wouldn=C2=B9t guarantee anything = either, would > it? Well, it would get end2end security - but no one has thought about = b2bua=E2=80=99s and all those middleboxes in that scenario.=20 Right, I have only seen a bit of code in resiprocate but no usage. >=20 >> I don=C2=B9t think we=C2=B9ll find that the answer is SIPS: as a URI = scheme, but the >> SIP over TLS transport is still very much needed, discovered by = NAPTR/SRV >> and supported by DANE or some other PKI structure. >=20 > You can already do SIP over TLS using the SIP: scheme - just establish = a > TLS connection and send your message :) Right. But the problem is getting the inbound request. Only Outbound = solves that and no one wants outbound right? So that puts us back to my other proposal about half-outbound. /O >=20 > Regards, >=20 > Christer >=20 >=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - = GB)" >>> wrote: >>>=20 >>>> That option was clearly understood by the SIP WG when we did RFC = 5630. >>>> However it was decided to very clearly state what it meant so that = both >>>> service providers and users could decide whether to use it or not, = and >>>> they still have that freedom. I suspect the majority have chosen = not >>>> to, >>>> but the option is still there. >>>>=20 >>>> Given that we spent so much time on providing RFC 5630 to update = RFC >>>> 3261 >>>> in this area, I am reluctant to change the direction now - this >>>> achieved >>>> IETF consensus. >>>>=20 >>>> Keith >>>>=20 >>>> P.S. I also take this opportunity to remember Francois Audet, who = did >>>> such a lot of work driving this document to completion. >>>>=20 >>>> -----Original Message----- >>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, >>>> MARTIN C >>>> Sent: 12 June 2016 09:03 >>>> To: Paul Kyzivat >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] SIPS must die, die, die >>>>=20 >>>> I vote 3, don't use SIPS >>>>=20 >>>> Martin C Dolly >>>> Lead Member of Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T >>>> Cell: 609-903-3360 >>>> Email: md3135@att.com >>>>=20 >>>>> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat >>>>> wrote: >>>>>=20 >>>>>> On 6/11/16 2:47 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>>=20 >>>>>>>> I think it's time to spend some time with TLS in SIPcore again. >>>>>>>> What do you think? >>>>>>>=20 >>>>>>> My memory is that the latest revision decided, as Keith says, = that >>>>>>> if you make a call to a sips: URI, you > are guaranteed that = every >>>>>>> signaling step is covered by TLS, or the call is rejected >>>>>>=20 >>>>>> ...or the SIPS URI is "converted" to a SIP URI by an = intermediary. In >>>>>> reality there is no guarantee. >>>>>=20 >>>>> So the choices are: >>>>>=20 >>>>> 1) use SIPS as defined, meeting all the constraints >>>>> 2) use SIPS but cheat when convenient >>>>> 3) don't use SIPS >>>>>=20 >>>>> Can anyone cite are real deployments that meet (1)? I suspect = there >>>>> are >>>>> none. >>>>>=20 >>>>> I hope nobody here is advocating (2). It has no useful security >>>>> properties. >>>>>=20 >>>>> Hence ISTM that (3) is the only deployable alternative. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 06:33:26 2016 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 74A2F12D668 for ; Tue, 14 Jun 2016 06:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 zU_L3vnWHWlg for ; Tue, 14 Jun 2016 06:33:22 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 1627C12D128 for ; Tue, 14 Jun 2016 06:33:22 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id d185so96967363vkg.0 for ; Tue, 14 Jun 2016 06:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oR6g3rSGw3kTewW9vuAyB/FUylpGZ1HtzNXPGBOEF9E=; b=XSmExXZ/i9viYet3B4zzrBHrWLQhfpPasgWu59n4XjpfGz8XObw1AIzg852oVsfPEV 9HqXRCAvvpTNjfppunTOgaMxN0kjusb0iIa04BV/+dpEEWDm+KQvUrC9XGqGt6wGze5K kiQ9ptlKGFTtJoGCkD4dqs39bbAw1e9VMw1Hks2f8e+C4fMYokKDJWWF7/Kb5p+Wi3k0 FDDsgFUskEmT1BFbc8dhXNubgeJt4yJMJ3POidv8Fs6K035SrqMQJHJJK4UbxoIzyWxg +GTYqQsHMJLN47Mu+DLOhcrxg8L17rmF7gvm4rNR1I8KHO32O0YMaXwKx9q/YKT3Cez0 NLZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oR6g3rSGw3kTewW9vuAyB/FUylpGZ1HtzNXPGBOEF9E=; b=XLoC7jincr8Cs4XQPoRMx0u4vshtmC0wdykbh0F4P0vQAswfosU4CH8rINXJOdyZ2Q djag69gS14PL7daAarmYnTpz6GVNUkFrsTLFk6OoyU54ysfI+ErTAFboRfgWuAgkZfjt F3rSEoZ5ZCUjr7LvOL9KE0dcAD1sZqlbC/ZhFVtR3R7JT07dhOuKLenaC+PKEgbwImeu WYAqNu5/5Rz5Xp8Xw8s/ifq6A2FfHG3SlRNP0pm0SncXCSgJ8CJo/A17v4mzwr+HZIea T3aropd0eP549ZZxOKf7gK7a9W+N90OIMUF3ranrKn6Ni/keV3dVsCR/jCWaNVraoIcK J9eg== X-Gm-Message-State: ALyK8tKhYQVyAcT3h8N/TaWNLIB9Hmvudx8XqaKzZ2+v1yZ/cRczUBONzijJEPzI0pcgyoUOBZG4bN2ThMxpIw== X-Received: by 10.31.164.129 with SMTP id n123mr9165014vke.21.1465911201041; Tue, 14 Jun 2016 06:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Tue, 14 Jun 2016 06:33:19 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Tue, 14 Jun 2016 09:33:19 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a11415d8669129205353d0cd6 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:33:25 -0000 --001a11415d8669129205353d0cd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 3:36 PM, Peterson, Jon wrote: > > Just to play back the general problem statement, I think we'd agree that > of your three numbered possible solutions, #1 is more or less the assumed > baseline SIP behavior - cases where, for example, the server would send a > Digest challenge in the backwards direction to authenticate the user agen= t > and then make any authorization decision based on its own ACLs or what ha= ve > you. Your solutions #2 and #3 cover the two cases I think are interesting= : > SSO-like ones where relying parties trust an identity assertion provided = by > an IdP of some sort (#2) and cases where the identity information is not > included at all (or is at least optional) and instead the relying party > trusts traits or attributes or what have you provided by the IdP. I've > argued that SIP has always been able to do #1, that we at least already > have some ways to do #2, and that we've already done requirements for #3 > (RFC4484) but to date have gone no farther, and that it would be new work > if we were to specify protocol for #3. > > So yes, the third option is where we need to focus. But the point of my > last mail was to say that what we need to narrow our discussion down to > what the attributes are that we imagine applications in these use cases > will require to process SIP requests, primarily SIP INVITE requests. You > say some high-level things below like that your third-option token "might > grant the user access to multiple services" on the conference service whi= ch > is your relying party. In terms of concrete authorization traits for this > use case, towards the very end you suggest attributes of a conference lik= e > the number of participants or the media types permitted in the conference= . > > Radhika sent a helpful summary of conference control protocols to the lis= t > which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which > actually let you manage attributes of a conference like the number of > participants and media types allowed. > This conference use case was an example for a SIP-based conference server (RFC4579), just to describe the idea around the delegation of AuthNZ. If the server is a CCMP-based conference, then you would obviously use that to control and manage the conference server. > The interesting thing about protocols like CCMP is that they are not, you > know, actually transported by SIP. CCMP is transported by HTTP. Why? > Because the semantics of conference control doesn't actually map onto SIP > INVITE transactions very well. They map quite aptly to HTTP, and in the > HTTP context, you can certainly use OAuth if you like. > Help me understand this part. Why can an HTTP request transport a token to a resource server to be able to access a specific resource, while SIP request cannot transport a similar token to a SIP server to access a service? > You even will find some text about Role-Based Access Control in the XCON > (RFC6503) security consideration. Although you can use SIP and SDP to set > up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS > between its own endpoints. It is unclear to me what carrying attribute > information around in a SIP INVITE would accomplish with regards to > authorizing CCMP or BFCP transactions. > SIP INVITE will carry attributes to authorize that specific SIP request; there is nothing in proposal #3 that suggest that SIP will carry authorization for CCMP or any other protocol. > > So again, the point of my last mail was that the problem of authorizing > SIP INVITEs is actually different from the problem of authorizing generic > application transactions. SIP INVITEs still have more or less the semanti= cs > of a call setup message: they are requesting that a session be initiated. > Conference control is not managed with SIP transactions, and the security > of conference control protocols does not devolve to authorizing SIP > transactions. > Well, RFC4579 defines a SIP Conference Control mechanism that allows you to initiate and control a conference server using only SIP requests; so I am not sure I understand this statement, unless we have different definitions for the term =E2=80=9Cconference control=E2=80=9D. In any case, my point was not to discuss conference servers specifically, but to discuss the general idea of delegating both AuthN and AuthZ in a SIP network. Regards, Rifaat > I suspect we'll find that most of the other security attributes that > "applications" need to do their jobs similarly don't map onto the semanti= cs > of a SIP INVITE - but, I'm still open to entertaining examples that might > cast doubt on that suspicion. > > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Thursday, June 9, 2016 at 10:59 AM > To: Jon Peterson > Cc: Christer Holmberg , "sipcore@ietf.org= " > > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 > > Hi Jon, > > Sorry for the delayed reply. > > Let's take the video conference example, and discuss the possible ways fo= r the > conference server to provide service. > > > Trust Domain 1 : Internet : Trust Domain 2 > : : > +--------+ : : > | IdP | : : > +-------------| AuthZ | : : > | | | : : > | +--------+ : : > | | : : > | | : : > +--------+ +--------+ : : +--------+ > | | | SIP | : : | SIP App| > | UA |--------| Proxy |-----:-----------------:-----| Video | > | | | | : : | Conference > +--------+ +--------+ : : +--------+ > : : > > Possible solutions: > > 1. Conference Server acts as an AuthN and AuthZ server. Requests to > the server must provide an identity and credentials, and services will > be provided based on locally stored information associated with > the identity provided in the request. > > 2. Conference Server acts as an AuthZ server, but delegates the AuthN > part. Requests to the server must provide an identity token, and services > will be provided based on locally stored information associated with > the identity provided in the token. > > 3. Conference Server delegates both AuthN and AuthZ parts. Requests to > the server must provide an access token, which might or might not > include information about the user requesting the service, and services > will be provided based on information provided in the access token or as > a result of an introspection step using the access token. > > > Now, let's look at the 3rd option a bit more, and assume that the > server provides the following types of conference services: > 1. audio conference > 2. audio/video conference > 3. web conference > > or some combination of the above. > > Let's also assume that the server allows control over the number > of participants allowed in each one of these conference types or > combinations. > > > Here is one way that I envisioned we could use to address this use case: > > When an enterprise user in the 1st trust domain wants to register with > the SIP Proxy, it will have to authenticate to the IdP and as a result > either the UA or the Proxy (depends on the UA's capabilities) will be > provided with an AuthN and AuthZ tokens. This process could involve an > interim step to allow only the proxy to get access to the tokens, or the > tokens could be sent to the UA which will then use them to communicate wi= th > the proxy. > > The AuthN token is the identity of the user, and the AuthZ token has > all the services granted to the user by the IdP/AuthZ Service. > > When the enterprise user needs access to the conference service, the > UA will send an INVITE to the Proxy, and will include the AuthZ token if = it > is in possession of the tokens; otherwise, the proxy will add the > appropriate token to the outgoing INVITE sent to the conference server. > > The scope of the AuthZ token might grant the user access to > multiple services; to avoid sending that AuthZ token to all servers > providing services granted to the user, the proxy could obtain a differen= t > token with limited scope that is specific to the service being provided > (conference services in this case); there is a standard Token Exchange > mechanism for that. > > The AuthZ token will include information about the type of service > allowed (audio, audio/video, etc), and the limit on the number of > participants. The AuthZ token might or might not have any information abo= ut > the user requesting the service, which depends on the level of privacy > needed. > > When the conference server receives this token in the SIP INVITE, all > it has to do is validate that the token was signed by an IdP that it has > a trust relationship with, and provide the service requested by the > AuthZ token. The conference server does not need the AuthN token to be ab= le > to provide a service. > > Regards, > Rifaat > > > On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon > wrote: > >> >> Also, if we decided to separate the AuthN and AuthZ, then we might need >> to carry more than one token. >> >> >> I could see an argument that there is a need to carry the identity of th= e >> user in one header, and a reference to a place where you can get attribu= tes >> about the originating user in another header, say. That's more or less w= hat >> we envisioned the last time we went down this path, which led to the >> RFC4484 requirements, largely informed by SAML (which I seem to recall 3= GPP >> was interested in at the time). >> >> But it's no accident that the work on RFC4484 never went beyond >> requirements. Today, I think that much of the useful work that could be >> done on the authorization question is in identifying which SIP >> authorization policies are likely to depend on attributes as opposed to >> just the identity of the end user. While we can readily conceive of >> applications adjunct to communications that would require attributes, th= e >> challenge has been justifying why you would invoke those applications wi= th >> SIP rather than, say, HTTP. The fundamental semantics of a SIP INVITE h= ave >> remained pretty close to those of placing a telephone call. The >> authorization policies of a telephone call are really different than tha= t >> of a web service, say, both in terms of how and why they are invoked, wh= at >> kinds of parties are involved, what forms redirection or cross-domain >> interaction can occur. With appropriate caveats for other methods (notab= ly >> MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy >> requirements that look a lot like call treatment policies. >> >> That much said, I am kind of interested in call treatment policies, and >> their interaction with identity information. But just saying that there >> might be a video conference service in the cloud, say, doesn't shed a lo= t >> of light for me. If there's a video conference, I'd ordinarily think you >> just call into it. If the user who opens the conference bridge needs to = be >> charged, that's identity information - which in its usual form will conv= ey >> the individual user and their domain, like user@domain. If you need more >> complex semantics than that, it's probably because you're doing somethin= g >> more complicated than just calling in to the conference. But it's less >> clear to me why you'd use SIP for such cases. Drilling down deeper into >> these use cases would help me understand where we're going, anyway - the >> use cases in RFC4484 Section 4, which largely involve billing (including >> when dealing with various protocol gateways) and resource management (bo= th >> preemption and priority), ultimately didn't seem sufficient to motivate >> protocol work. >> >> Another issues in the need, in some cases, to avoid sending the token to >> the UA; in this case there is a need for an interim step to get the >> token(s) to the SIP proxy. >> >> >> If this information is carried in headers, then presumably it could be >> added, consumed, subtracted, or whatever by any relevant intermediaries. >> >> Jon Peterson >> Neustar, Inc. >> > > --001a11415d8669129205353d0cd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 13, 2016 at 3:36 PM, Peterson, Jon <jon.peterson@neusta= r.biz> wrote:

Just to play back the general problem statement, I think we'd agre= e that of your three numbered possible solutions, #1 is more or less the as= sumed baseline SIP behavior - cases where, for example, the server would se= nd a Digest challenge in the backwards direction to authenticate the user agent and then make any authorization d= ecision based on its own ACLs or what have you. Your solutions #2 and #3 co= ver the two cases I think are interesting: SSO-like ones where relying part= ies trust an identity assertion provided by an IdP of some sort (#2) and cases where the identity informat= ion is not included at all (or is at least optional) and instead the relyin= g party trusts traits or attributes or what have you provided by the IdP. I= 've argued that SIP has always been able to do #1, that we at least already have some ways to do #2, and that = we've already done requirements for #3 (RFC4484) but to date have gone = no farther, and that it would be new work if we were to specify protocol fo= r #3.

So yes, the third option is where we need to focus. But the point of m= y last mail was to say that what we need to narrow our discussion down to w= hat the attributes are that we imagine applications in these use cases will= require to process SIP requests, primarily SIP INVITE requests. You say some high-level things below like t= hat your third-option token "might grant the user access to multiple s= ervices" on the conference service which is your relying party. In ter= ms of concrete authorization traits for this use case, towards the very end you suggest attributes of a conference like= the number of participants or the media types permitted in the conference.=

Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed.

If the server is a CCMP-based conference, then you would obviously use that to control and manage the conference server.


=C2=A0
The interesting thing about protocols like CCMP is that they are not, you know= , actually transported by SIP. CCMP is transported by HTTP. Why? Because th= e semantics of conference control doesn't actually map onto SIP INVITE = transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OAuth if you= like.
=C2=A0

Help me understand this part.

Why can an HTTP request transport a token to a resource server to be able to access a speci= fic resource, while SIP request cannot transport a similar token to a SIP server to acces= s a service?


=C2=A0
=
You even will find some text about Role-Based = Access Control in the XCON (RFC6503) security consideration. Although you c= an use SIP and SDP to set up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS between its own endpoints. It is= unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes to authorize that specific SIP request; there is nothing in prop= osal #3 that suggest that SIP will carry authorization for CCMP or any other protocol.

=C2=A0
Well, RFC4579 defines a SIP Conference Control mechanism that allows you to initiate and control = a conference server using only SIP requests; so I am not sure I understand th= is statement, unless we have different definitions for the term =E2=80=9Cconfe= rence control=E2=80=9D.

=C2=A0

In any case, my point was not to discuss conference servers specifically, but to discuss the gene= ral idea of delegating both AuthN and AuthZ in a SIP network.

=C2=A0

Regards,

=C2=A0Rifaat


=C2=A0

Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference= example, and discuss the possible ways for=C2=A0the conference server to provide service.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= rust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2= =A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=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: =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 +--------+ =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 =C2=A0 =C2=A0 | IdP =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 +------= -------| AuthZ =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 =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 =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 =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 =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= =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 =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| SIP =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 | = SIP App|
=C2=A0 =C2=A0 | =C2=A0 UA =C2=A0 |-= -------| Proxy =C2=A0|-----:-----------------:-----| Video =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 | Conference
=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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the=C2=A0server must provide an identity a= nd credentials, and services will be=C2=A0provided based on locally stored = information associated with the=C2=A0identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part.=C2=A0Requests to the server must p= rovide an identity token, and services will=C2=A0be provided based on local= ly stored information associated with the=C2=A0identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the=C2=A0server must provide an access = token, which might or might not include=C2=A0information about the user req= uesting the service, and services will=C2=A0be provided based on information provided in the access token or as a=C2=A0result of a= n introspection step using the access token.


Now, let's look at the 3rd opti= on a bit more, and assume that the server=C2=A0provides the following types= of conference services:
1. audio conference
2. audio/video conference
3. web conference

or some=C2=A0combination=C2=A0of th= e above.

Let's also assume that the serv= er allows control over the number of=C2=A0participants allowed in each one = of these conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the=C2=A0SIP Proxy, it will have to authenti= cate to the IdP and as a result either=C2=A0the UA or the Proxy (depends on= the UA's capabilities) will be provided=C2=A0with an AuthN and AuthZ tokens. This process could involve an interim step=C2= =A0to allow only the proxy to get access to the tokens, or the tokens could= be=C2=A0sent to the UA which will then use them to communicate with the pr= oxy.

The AuthN token is the identity of the user, and the AuthZ token has all=C2= =A0the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA=C2= =A0will send an INVITE to the Proxy, and will include the AuthZ token if it= is=C2=A0in possession of the tokens; otherwise, the proxy will add the app= ropriate=C2=A0token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple=C2=A0s= ervices; to avoid sending that AuthZ token to all servers providing=C2=A0se= rvices granted to the user, the proxy could obtain a different token with= =C2=A0limited scope that is specific to the service being provided (conference=C2=A0services in this case); there is a standar= d Token Exchange mechanism for=C2=A0that.

The AuthZ token will include information about the type of service allowed= =C2=A0(audio, audio/video, etc), and the limit on the number of participant= s.=C2=A0The AuthZ token might or might not have any information about the u= ser=C2=A0requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it=C2= =A0has to do is validate that the token was signed by an IdP that it has a= =C2=A0trust relationship with, and provide the service requested by the Aut= hZ=C2=A0token. The conference server does not need the AuthN token to be able to=C2=A0provide a service.

Regards,
=C2=A0Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or = less what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond re= quirements. Today, I think that much of the useful work that could be done = on the authorization question is in identifying which SIP authorization pol= icies are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP. =C2=A0The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.=C2=A0 The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lo= t of light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user wh= o opens the conference bridge needs to be charged, that's identity info= rmation - which in its usual form will convey the individual user and their= domain, like user@domain. If you need more complex semantics than that, it's probably because you're doing so= mething more complicated than just calling in to the conference. But it'= ;s less clear to me why you'd use SIP for such cases. Drilling down dee= per into these use cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which = largely involve billing (including when dealing with various protocol gatew= ays) and resource management (both preemption and priority), ultimately did= n't seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.= =C2=A0

Jon Peterson
Neustar, Inc.


--001a11415d8669129205353d0cd6-- From nobody Tue Jun 14 08:51:16 2016 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 6AB6F12D549 for ; Tue, 14 Jun 2016 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 GUbFWvFUCX4H for ; Tue, 14 Jun 2016 08:51:14 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5B112D51B for ; Tue, 14 Jun 2016 08:51:13 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 7328823F0485; Tue, 14 Jun 2016 17:51:12 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 17:51:12 +0200 From: "Hutton, Andrew" To: Richard Shockey , "Peterson, Jon" , "Drage, Keith (Nokia - GB)" , "DOLLY, MARTIN C" , Paul Kyzivat Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/jsgaAgACq/ACAAPxBgIAB9SyAgABK1ACAACFBgIABZYQA Date: Tue, 14 Jun 2016 15:51:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:51:16 -0000 T046IDEzIEp1bmUgMjAxNiBSaWNoYXJkIFNob2NrZXkgDQoNCj4gVGhvdWdoIGl0IGlzIHNwZWNp ZmllZCBhcyBNVVNUIHN1cHBvcnQgaW4gdGhlDQo+IFNJUCBGb3J1bSBTSVBDb25uZWN0IHByb2Zp bGVzIGZvciBQQlggdG8gU1Agb24gdGhlIHdpcmUgaW50ZWdyYXRpb24gdG8NCj4gbXkga25vd2xl ZGdlIGl0IGhhcyBuZXZlciBiZWVuIGltcGxlbWVudGVkIGJ5IGFueSB2ZW5kb3Igb3IgU1NQLiAg SW4NCj4gc2hvcnQgU0lQUyBpcyBhIHRvdGFsIFBhaW4gaW4gdGhlIEFzcw0KDQpTSVBTIGlzIGFj dHVhbGx5IG5vdCByZXF1aXJlZCBieSBTSVBjb25uZWN0IGFsdGhvdWdoIFRMUyBpcyBhIE1VU1Qg cmVxdWlyZW1lbnQgaGVuY2UgdGhlIGNvbmZ1c2lvbi4NCg0KV2hlbmV2ZXIgSSBoYXZlIHNlZW4g U0lQUyB1c2VkIGl0IGhhcyByZXN1bHRlZCBpbiBzb21lIGtpbmQgb2YgYnVnIHJlcG9ydCBiZWlu ZyBnZW5lcmF0ZWQgYW5kIEkgaGF2ZSB0byBzYXkgSSBoYXZlIG5vdCBoZWFyZCBvZiBpdCBiZWlu ZyB1c2VkIGZvciBzb21lIHRpbWUuICBJdCBuZWVkcyB0byBkZXByZWNhdGVkIGFuZCB0aGUgdXNl IG9mIFRMUyBjbGFyaWZpZWQuDQogDQo= From nobody Tue Jun 14 08:57:53 2016 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 D34E012D5A3 for ; Tue, 14 Jun 2016 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] 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 Pjn1ETcOy24s for ; Tue, 14 Jun 2016 08:57:51 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B8812D193 for ; Tue, 14 Jun 2016 08:57:50 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E55F41EB8430; Tue, 14 Jun 2016 17:57:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 17:57:48 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , Christer Holmberg Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRxhvdEQdB19tCFkq/OxaVh7fUFZ/pHY+Q Date: Tue, 14 Jun 2016 15:57:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26140354@MCHP04MSX.global-ad.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:57:52 -0000 T246IDE0IEp1bmUgMjAxNiAxMDowNSBPbGxlIEUuSm9oYW5zc29uIHdyb3RlOg0KPiA+DQo+ID4g WW91IGNhbiBhbHJlYWR5IGRvIFNJUCBvdmVyIFRMUyB1c2luZyB0aGUgU0lQOiBzY2hlbWUgLSBq dXN0DQo+IGVzdGFibGlzaCBhDQo+ID4gVExTIGNvbm5lY3Rpb24gYW5kIHNlbmQgeW91ciBtZXNz YWdlIDopDQoNCg0KPiBSaWdodC4gQnV0IHRoZSBwcm9ibGVtIGlzIGdldHRpbmcgdGhlIGluYm91 bmQgcmVxdWVzdC4gT25seSBPdXRib3VuZA0KPiBzb2x2ZXMNCj4gdGhhdCBhbmQgbm8gb25lIHdh bnRzIG91dGJvdW5kIHJpZ2h0Pw0KPiBTbyB0aGF0IHB1dHMgdXMgYmFjayB0byBteSBvdGhlciBw cm9wb3NhbCBhYm91dCBoYWxmLW91dGJvdW5kLg0KDQpBZ3JlZWQgd2UgZGlzY3Vzc2VkIHRoaXMg YSBsb3QgaW4gdGhlIFNJUGNvbm5lY3QyLjAgd29yayBjbGVhcmx5IHRoZXJlIGFyZSBsb3RzIG9m IFNJUCBvdmVyIFRMUyBpbXBsZW1lbnRhdGlvbnMgYnV0IGFjdHVhbGx5IHRoZXJlIGlzIG5vIFJG QyB0aGF0IGFjdHVhbGx5IGRlc2NyaWJlZCB3aGF0IHRoZXNlIGltcGxlbWVudGF0aW9ucyBhcmUg ZG9pbmcuIFRoZSBoYWxmLW91dGJvdW5kIGxvb2tzIGxpa2UgYSB3b3JrYWJsZSBzb2x1dGlvbiB0 aGF0IHdvdWxkIGNvdWxkIGZpeCB0aGF0Lg0KDQoNCg0KIA0K From nobody Tue Jun 14 09:04:08 2016 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 66C9E12D5A3 for ; Tue, 14 Jun 2016 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 C1bpXdlZ_woP for ; Tue, 14 Jun 2016 09:04:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 5BAAD12D180 for ; Tue, 14 Jun 2016 09:04:05 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1585BC248784B; Tue, 14 Jun 2016 16:04:01 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5EG43Gh017008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2016 16:04:03 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5EG423x004561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jun 2016 18:04:03 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 14 Jun 2016 18:04:03 +0200 From: "Drage, Keith (Nokia - GB)" To: "sipcore@ietf.org" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/kFpuAgACq/ACAALkzRIAB89MAgAAqpgCAACFBgIABRlGAgAAi36A= Date: Tue, 14 Jun 2016 16:04:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Hutton, Andrew" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:04:07 -0000 UGxlYXNlIGNvbmZpcm0gd2hldGhlciBSRkMgNTYzMCAoaW5jbHVkaW5nIGFubmV4IEEpIGlzIGNs ZWFyIGluIHRoaXMgcmVzcGVjdCBvciBub3QsIGFuZCBiZSBzcGVjaWZpYyBhYm91dCB3aGVyZSBp dCBpcyBub3QuIFlvdSBzaG91bGQgbm90IGJlIGltcGxlbWVudGluZyBSRkMgMzI2MSB3aXRob3V0 IGFsc28gaW1wbGVtZW50aW5nIFJGQyA1NjMwLCBhcyBvbmUgdXBkYXRlcyB0aGUgb3RoZXIuDQoN CkFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgdGhhdCBkb2N1bWVudCBpcyBjbGVhciBhYm91dCB3 aGF0IGlzIG5lZWRlZCB0byBzdXBwb3J0IFNJUFMsIGFuZCB3aGF0IGlzIG5lZWRlZCB0byBzdXBw b3J0IHRyYW5zcG9ydD1UTFMuDQoNClRoZSB1c2Ugb2YgU0lQUyBzaG91bGQgbm90IGdlbmVyYXRl IGEgYnVnIHJlcG9ydCwgYmVjYXVzZSBpdCBpcyBub3QgYW4gZXJyb3IuIFlvdSBtYXkgbmVlZCB0 byByZWplY3QgdGhlIGNhbGwgYmVjYXVzZSB5b3UgY2Fubm90IHN1cHBvcnQgdGhlIGNhcGFiaWxp dHksIGJ1dCB0aGF0IGlzIG5vIGRpZmZlcmVudCB0byBtYW55IG90aGVyIHJlYXNvbnMgZm9yIHJl amVjdGlvbi4NCg0KV2UgZG8gbm90IG5vcm1hbGx5IGRlcHJlY2F0ZSBSRkNzIGp1c3QgYmVjYXVz ZSBwZW9wbGUgaGF2ZSBmYWlsZWQgdG8gcmVhZCB0aGUgZG9jdW1lbnQsIG9mIGZhaWxlZCB0byBw cm92aWRlIHRoZWlyIGltcGxlbWVudGF0aW9ucyBpbiBjb25mb3JtYW5jZSB3aXRoIHRoZSBkb2N1 bWVudCwgb3IgZXZlbiBqdXN0IGZhaWxlZCB0byBpbXBsZW1lbnQgYSBwYXJ0aWN1bGFyIGNhcGFi aWxpdHkuDQoNCklmIHlvdSBkb24ndCB3YW50IHRvIHN1cHBvcnQgU0lQUywgdGhlbiBmaW5lLCB0 aGF0IGlzIGFuIGFjY2VwdGFibGUgcG9zaXRpb24sIGJ1dCB5b3UgbmVlZCBtb3JlIGV2aWRlbmNl IHRvIHRlbGwgdGhlIHdvcmxkIG5vdCB0byB1c2UgaXQuDQoNCktlaXRoDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIdXR0b24sIEFuZHJldyBbbWFpbHRvOmFuZHJldy5odXR0 b25AdW5pZnkuY29tXSANClNlbnQ6IDE0IEp1bmUgMjAxNiAxNjo1MQ0KVG86IFJpY2hhcmQgU2hv Y2tleTsgUGV0ZXJzb24sIEpvbjsgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgRE9MTFksIE1B UlRJTiBDOyBQYXVsIEt5eml2YXQNCkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3NpcGNvcmVdIFNJUFMgbXVzdCBkaWUsIGRpZSwgZGllDQoNCk9OOiAxMyBKdW5lIDIwMTYgUmlj aGFyZCBTaG9ja2V5IA0KDQo+IFRob3VnaCBpdCBpcyBzcGVjaWZpZWQgYXMgTVVTVCBzdXBwb3J0 IGluIHRoZSBTSVAgRm9ydW0gU0lQQ29ubmVjdCANCj4gcHJvZmlsZXMgZm9yIFBCWCB0byBTUCBv biB0aGUgd2lyZSBpbnRlZ3JhdGlvbiB0byBteSBrbm93bGVkZ2UgaXQgaGFzIA0KPiBuZXZlciBi ZWVuIGltcGxlbWVudGVkIGJ5IGFueSB2ZW5kb3Igb3IgU1NQLiAgSW4gc2hvcnQgU0lQUyBpcyBh IHRvdGFsIA0KPiBQYWluIGluIHRoZSBBc3MNCg0KU0lQUyBpcyBhY3R1YWxseSBub3QgcmVxdWly ZWQgYnkgU0lQY29ubmVjdCBhbHRob3VnaCBUTFMgaXMgYSBNVVNUIHJlcXVpcmVtZW50IGhlbmNl IHRoZSBjb25mdXNpb24uDQoNCldoZW5ldmVyIEkgaGF2ZSBzZWVuIFNJUFMgdXNlZCBpdCBoYXMg cmVzdWx0ZWQgaW4gc29tZSBraW5kIG9mIGJ1ZyByZXBvcnQgYmVpbmcgZ2VuZXJhdGVkIGFuZCBJ IGhhdmUgdG8gc2F5IEkgaGF2ZSBub3QgaGVhcmQgb2YgaXQgYmVpbmcgdXNlZCBmb3Igc29tZSB0 aW1lLiAgSXQgbmVlZHMgdG8gZGVwcmVjYXRlZCBhbmQgdGhlIHVzZSBvZiBUTFMgY2xhcmlmaWVk Lg0KIA0K From nobody Tue Jun 14 09:09:33 2016 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 28ABA12D7D3 for ; Tue, 14 Jun 2016 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 o6pBnVHyXWpF for ; Tue, 14 Jun 2016 09:09:21 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 37F2912D758 for ; Tue, 14 Jun 2016 09:09:21 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id u64so116493286vkf.3 for ; Tue, 14 Jun 2016 09:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jga0JzUAwQao6D+1q1jfQDzvwk8S4SFWbiIzX+fDtiw=; b=b0VaZ8eHCvIvPiuTTiaNCnwkInE95h7Q39XeQeJFbaJtPmWTweeriJlp86S6CpybUU 4h5kcUYhnHThoHNT/P7jg9uC0d2ApwM8Ni5keKkwblMX40qNJvAB4uSvAHvA2jZvGMk4 0whZL1aw8EboMfMP9iLrxozgVxyelzzUcYi4dqZeYO8ORQ+PkvUNPnM+wFsbX262JY1h UClyYlkay0pt0UeGc3NSKY7/mm4Yod8LnbneiWdZTmTsZnsrIfYEzkFjYUsC8b55T/sn ffnWjFoy0tA8bG8KildeVCY2Gkt5m6Mu+yF2O4uDGsIfLGK+RoWPdNQ4KzzD6Wwko3Y7 uVUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jga0JzUAwQao6D+1q1jfQDzvwk8S4SFWbiIzX+fDtiw=; b=X8EXSVQHFWwXLjpqruOunei4fJz6BfeaBHknoCCt2sifT/PlfmGY6dsoiX5IN0YblB 22KCaJMIUce++xMgCbHYwfLod/+/3n2vrnWiwfTlTNI5bE4Jb6qW594QrTpFZZEL3L5u wgNxbZ7dhJu50l0l0/MIdVdjrYqy3Yhi8jV1S/ymC39IRLHESIR0wI2jhc+pWzLjlhtB Y3dXpuxYnupJhMg6Dr5frZ95Gqx55yDZ9lWp1EwbW39J/aRljIRDUTywHPjIjTVZD3lK HK2H8DQLLqtsWqTh8xMO1hc42Tk1Wk99ufVOGir2kht/xoOSHbsc84+Dlm6NNBmgV2r+ dWJg== X-Gm-Message-State: ALyK8tIfGsVkz8T5Fa2nChbD0YcL0Bc/skmcrQIWU16ehZnqsKZs5qlkzRnw0SbguIVymHQZWATq1Lqfbj5D0w== X-Received: by 10.159.37.175 with SMTP id 44mr7297226uaf.66.1465920560236; Tue, 14 Jun 2016 09:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Tue, 14 Jun 2016 09:09:19 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Rifaat Shekh-Yusef Date: Tue, 14 Jun 2016 12:09:19 -0400 Message-ID: To: "Drage, Keith (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a1135192443111905353f3a6a Archived-At: Cc: "Hutton, Andrew" , "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:09:23 -0000 --001a1135192443111905353f3a6a Content-Type: text/plain; charset=UTF-8 I am with Keith here. There is no problem with the SIPS recommendations as defined in the RFC, so I am not sure on what basis we would deprecate that. If you do not like it, do not implement it. Regards, Rifaat On Tue, Jun 14, 2016 at 12:04 PM, Drage, Keith (Nokia - GB) < keith.drage@nokia.com> wrote: > Please confirm whether RFC 5630 (including annex A) is clear in this > respect or not, and be specific about where it is not. You should not be > implementing RFC 3261 without also implementing RFC 5630, as one updates > the other. > > As far as I am concerned, that document is clear about what is needed to > support SIPS, and what is needed to support transport=TLS. > > The use of SIPS should not generate a bug report, because it is not an > error. You may need to reject the call because you cannot support the > capability, but that is no different to many other reasons for rejection. > > We do not normally deprecate RFCs just because people have failed to read > the document, of failed to provide their implementations in conformance > with the document, or even just failed to implement a particular capability. > > If you don't want to support SIPS, then fine, that is an acceptable > position, but you need more evidence to tell the world not to use it. > > Keith > > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@unify.com] > Sent: 14 June 2016 16:51 > To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, > MARTIN C; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: RE: [sipcore] SIPS must die, die, die > > ON: 13 June 2016 Richard Shockey > > > Though it is specified as MUST support in the SIP Forum SIPConnect > > profiles for PBX to SP on the wire integration to my knowledge it has > > never been implemented by any vendor or SSP. In short SIPS is a total > > Pain in the Ass > > SIPS is actually not required by SIPconnect although TLS is a MUST > requirement hence the confusion. > > Whenever I have seen SIPS used it has resulted in some kind of bug report > being generated and I have to say I have not heard of it being used for > some time. It needs to deprecated and the use of TLS clarified. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1135192443111905353f3a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am with Keith here.
There is no problem with the SIP= S recommendations as defined in the RFC, so I am not sure on what basis we = would deprecate that.=C2=A0
If you do not like it, do not impleme= nt it.

Regards,
=C2=A0Rifaat
<= br>

On= Tue, Jun 14, 2016 at 12:04 PM, Drage, Keith (Nokia - GB) <keith.drage= @nokia.com> wrote:
Please c= onfirm whether RFC 5630 (including annex A) is clear in this respect or not= , and be specific about where it is not. You should not be implementing RFC= 3261 without also implementing RFC 5630, as one updates the other.

As far as I am concerned, that document is clear about what is needed to su= pport SIPS, and what is needed to support transport=3DTLS.

The use of SIPS should not generate a bug report, because it is not an erro= r. You may need to reject the call because you cannot support the capabilit= y, but that is no different to many other reasons for rejection.

We do not normally deprecate RFCs just because people have failed to read t= he document, of failed to provide their implementations in conformance with= the document, or even just failed to implement a particular capability.
If you don't want to support SIPS, then fine, that is an acceptable pos= ition, but you need more evidence to tell the world not to use it.

Keith

-----Original Message-----
From: Hutton, Andrew [mailto:and= rew.hutton@unify.com]
Sent: 14 June 2016 16:51
To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, MARTI= N C; Paul Kyzivat
Cc: sipcore@ietf.org
Subject: RE: [sipcore] SIPS = must die, die, die

ON: 13 June 2016 Richard Shockey

> Though it is specified as MUST support in the SIP Forum SIPConnect
> profiles for PBX to SP on the wire integration to my knowledge it has<= br> > never been implemented by any vendor or SSP.=C2=A0 In short SIPS is a = total
> Pain in the Ass

SIPS is actually not required by SIPconnect although TLS is a MUST requirem= ent hence the confusion.

Whenever I have seen SIPS used it has resulted in some kind of bug report b= eing generated and I have to say I have not heard of it being used for some= time.=C2=A0 It needs to deprecated and the use of TLS clarified.

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a1135192443111905353f3a6a-- From nobody Tue Jun 14 09:32:23 2016 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 851E212D80C for ; Tue, 14 Jun 2016 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 zjMuVCWnJmLz for ; Tue, 14 Jun 2016 09:32:20 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29B812D13E for ; Tue, 14 Jun 2016 09:26:38 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id A6FC71EB84F1; Tue, 14 Jun 2016 18:26:37 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 18:26:37 +0200 From: "Hutton, Andrew" To: Rifaat Shekh-Yusef , "Drage, Keith (Nokia - GB)" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtEQdB19tCFkq/OxaVh7fUFZ/jsgaAgACq/ACAAPxBgIAB9SyAgABK1ACAACFBgIABZYQA///kZACAAAF6gIAAI9FQ Date: Tue, 14 Jun 2016 16:26:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26140451@MCHP04MSX.global-ad.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF26140451MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:32:21 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF26140451MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2sgbXkgc3RhdGVtZW50IHJlZ2FyZGluZyBkZXByZWNhdGlvbiB3YXMgcHJvYmFibHkgYSBiaXQg cmFzaCBhbmQgbWF5YmUgU0lQUyBhcyBzcGVjaWZpZWQgaW4gUkZDIDU2MzAgY291bGQgYmUgbWFk ZSB0byB3b3JrIGJ1dCBhdCBsZWFzdCBpbiB0aGUgU0lQIFRydW5raW5nIHdvcmxkIEkgZG9u4oCZ dCB0aGluayBhbnlib2R5IGhhcyBpbXBsZW1lbnRlZCBpdCB0aGlzIHdheSBhcyB0aGUgU0lQIHRy dW5raW5nIHRyYW5zcG9ydCBpcyBoYXJkIHdpcmVkIGFuZCBTSVBTIGlzIG5vdCB1c2VmdWwuDQoN CkFuZHkNCg0KDQoNCkZyb206IFJpZmFhdCBTaGVraC1ZdXNlZiBbbWFpbHRvOnJpZmFhdC5pZXRm QGdtYWlsLmNvbV0NClNlbnQ6IDE0IEp1bmUgMjAxNiAxNzowOQ0KVG86IERyYWdlLCBLZWl0aCAo Tm9raWEgLSBHQikNCkNjOiBzaXBjb3JlQGlldGYub3JnOyBIdXR0b24sIEFuZHJldw0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSBTSVBTIG11c3QgZGllLCBkaWUsIGRpZQ0KDQpJIGFtIHdpdGggS2Vp dGggaGVyZS4NClRoZXJlIGlzIG5vIHByb2JsZW0gd2l0aCB0aGUgU0lQUyByZWNvbW1lbmRhdGlv bnMgYXMgZGVmaW5lZCBpbiB0aGUgUkZDLCBzbyBJIGFtIG5vdCBzdXJlIG9uIHdoYXQgYmFzaXMg d2Ugd291bGQgZGVwcmVjYXRlIHRoYXQuDQpJZiB5b3UgZG8gbm90IGxpa2UgaXQsIGRvIG5vdCBp bXBsZW1lbnQgaXQuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gVHVlLCBKdW4gMTQsIDIw MTYgYXQgMTI6MDQgUE0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5v a2lhLmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29tPj4gd3JvdGU6DQpQbGVhc2UgY29u ZmlybSB3aGV0aGVyIFJGQyA1NjMwIChpbmNsdWRpbmcgYW5uZXggQSkgaXMgY2xlYXIgaW4gdGhp cyByZXNwZWN0IG9yIG5vdCwgYW5kIGJlIHNwZWNpZmljIGFib3V0IHdoZXJlIGl0IGlzIG5vdC4g WW91IHNob3VsZCBub3QgYmUgaW1wbGVtZW50aW5nIFJGQyAzMjYxIHdpdGhvdXQgYWxzbyBpbXBs ZW1lbnRpbmcgUkZDIDU2MzAsIGFzIG9uZSB1cGRhdGVzIHRoZSBvdGhlci4NCg0KQXMgZmFyIGFz IEkgYW0gY29uY2VybmVkLCB0aGF0IGRvY3VtZW50IGlzIGNsZWFyIGFib3V0IHdoYXQgaXMgbmVl ZGVkIHRvIHN1cHBvcnQgU0lQUywgYW5kIHdoYXQgaXMgbmVlZGVkIHRvIHN1cHBvcnQgdHJhbnNw b3J0PVRMUy4NCg0KVGhlIHVzZSBvZiBTSVBTIHNob3VsZCBub3QgZ2VuZXJhdGUgYSBidWcgcmVw b3J0LCBiZWNhdXNlIGl0IGlzIG5vdCBhbiBlcnJvci4gWW91IG1heSBuZWVkIHRvIHJlamVjdCB0 aGUgY2FsbCBiZWNhdXNlIHlvdSBjYW5ub3Qgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eSwgYnV0IHRo YXQgaXMgbm8gZGlmZmVyZW50IHRvIG1hbnkgb3RoZXIgcmVhc29ucyBmb3IgcmVqZWN0aW9uLg0K DQpXZSBkbyBub3Qgbm9ybWFsbHkgZGVwcmVjYXRlIFJGQ3MganVzdCBiZWNhdXNlIHBlb3BsZSBo YXZlIGZhaWxlZCB0byByZWFkIHRoZSBkb2N1bWVudCwgb2YgZmFpbGVkIHRvIHByb3ZpZGUgdGhl aXIgaW1wbGVtZW50YXRpb25zIGluIGNvbmZvcm1hbmNlIHdpdGggdGhlIGRvY3VtZW50LCBvciBl dmVuIGp1c3QgZmFpbGVkIHRvIGltcGxlbWVudCBhIHBhcnRpY3VsYXIgY2FwYWJpbGl0eS4NCg0K SWYgeW91IGRvbid0IHdhbnQgdG8gc3VwcG9ydCBTSVBTLCB0aGVuIGZpbmUsIHRoYXQgaXMgYW4g YWNjZXB0YWJsZSBwb3NpdGlvbiwgYnV0IHlvdSBuZWVkIG1vcmUgZXZpZGVuY2UgdG8gdGVsbCB0 aGUgd29ybGQgbm90IHRvIHVzZSBpdC4NCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEh1dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5j b208bWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tPl0NClNlbnQ6IDE0IEp1bmUgMjAxNiAx Njo1MQ0KVG86IFJpY2hhcmQgU2hvY2tleTsgUGV0ZXJzb24sIEpvbjsgRHJhZ2UsIEtlaXRoIChO b2tpYSAtIEdCKTsgRE9MTFksIE1BUlRJTiBDOyBQYXVsIEt5eml2YXQNCkNjOiBzaXBjb3JlQGll dGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBT SVBTIG11c3QgZGllLCBkaWUsIGRpZQ0KDQpPTjogMTMgSnVuZSAyMDE2IFJpY2hhcmQgU2hvY2tl eQ0KDQo+IFRob3VnaCBpdCBpcyBzcGVjaWZpZWQgYXMgTVVTVCBzdXBwb3J0IGluIHRoZSBTSVAg Rm9ydW0gU0lQQ29ubmVjdA0KPiBwcm9maWxlcyBmb3IgUEJYIHRvIFNQIG9uIHRoZSB3aXJlIGlu dGVncmF0aW9uIHRvIG15IGtub3dsZWRnZSBpdCBoYXMNCj4gbmV2ZXIgYmVlbiBpbXBsZW1lbnRl ZCBieSBhbnkgdmVuZG9yIG9yIFNTUC4gIEluIHNob3J0IFNJUFMgaXMgYSB0b3RhbA0KPiBQYWlu IGluIHRoZSBBc3MNCg0KU0lQUyBpcyBhY3R1YWxseSBub3QgcmVxdWlyZWQgYnkgU0lQY29ubmVj dCBhbHRob3VnaCBUTFMgaXMgYSBNVVNUIHJlcXVpcmVtZW50IGhlbmNlIHRoZSBjb25mdXNpb24u DQoNCldoZW5ldmVyIEkgaGF2ZSBzZWVuIFNJUFMgdXNlZCBpdCBoYXMgcmVzdWx0ZWQgaW4gc29t ZSBraW5kIG9mIGJ1ZyByZXBvcnQgYmVpbmcgZ2VuZXJhdGVkIGFuZCBJIGhhdmUgdG8gc2F5IEkg aGF2ZSBub3QgaGVhcmQgb2YgaXQgYmVpbmcgdXNlZCBmb3Igc29tZSB0aW1lLiAgSXQgbmVlZHMg dG8gZGVwcmVjYXRlZCBhbmQgdGhlIHVzZSBvZiBUTFMgY2xhcmlmaWVkLg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF26140451MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFt ZTpob2VuemI7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5PayBteSBzdGF0ZW1lbnQgcmVnYXJkaW5nIGRlcHJlY2F0aW9uIHdhcyBwcm9iYWJs eSBhIGJpdCByYXNoIGFuZCBtYXliZSBTSVBTIGFzIHNwZWNpZmllZCBpbiBSRkMgNTYzMCBjb3Vs ZCBiZSBtYWRlIHRvIHdvcmsgYnV0IGF0IGxlYXN0IGluIHRoZSBTSVAgVHJ1bmtpbmcNCiB3b3Js ZCBJIGRvbuKAmXQgdGhpbmsgYW55Ym9keSBoYXMgaW1wbGVtZW50ZWQgaXQgdGhpcyB3YXkgYXMg dGhlIFNJUCB0cnVua2luZyB0cmFuc3BvcnQgaXMgaGFyZCB3aXJlZCBhbmQgU0lQUyBpcyBub3Qg dXNlZnVsLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUmlmYWF0IFNoZWtoLVl1c2VmIFtt YWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEp1bmUg MjAxNiAxNzowOTxicj4NCjxiPlRvOjwvYj4gRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTxicj4N CjxiPkNjOjwvYj4gc2lwY29yZUBpZXRmLm9yZzsgSHV0dG9uLCBBbmRyZXc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBTSVBTIG11c3QgZGllLCBkaWUsIGRpZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHdpdGggS2Vp dGggaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBpcyBubyBwcm9ibGVtIHdpdGggdGhlIFNJUFMgcmVjb21tZW5kYXRpb25zIGFzIGRlZmluZWQg aW4gdGhlIFJGQywgc28gSSBhbSBub3Qgc3VyZSBvbiB3aGF0IGJhc2lzIHdlIHdvdWxkIGRlcHJl Y2F0ZSB0aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgeW91IGRvIG5vdCBsaWtlIGl0LCBkbyBub3QgaW1wbGVtZW50IGl0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBKdW4gMTQsIDIwMTYgYXQgMTI6MDQgUE0sIERyYWdlLCBLZWl0 aCAoTm9raWEgLSBHQikgJmx0OzxhIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBub2tpYS5jb20i IHRhcmdldD0iX2JsYW5rIj5rZWl0aC5kcmFnZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBjb25maXJtIHdoZXRoZXIg UkZDIDU2MzAgKGluY2x1ZGluZyBhbm5leCBBKSBpcyBjbGVhciBpbiB0aGlzIHJlc3BlY3Qgb3Ig bm90LCBhbmQgYmUgc3BlY2lmaWMgYWJvdXQgd2hlcmUgaXQgaXMgbm90LiBZb3Ugc2hvdWxkIG5v dCBiZSBpbXBsZW1lbnRpbmcgUkZDIDMyNjEgd2l0aG91dCBhbHNvIGltcGxlbWVudGluZyBSRkMg NTYzMCwgYXMgb25lIHVwZGF0ZXMgdGhlIG90aGVyLjxicj4NCjxicj4NCkFzIGZhciBhcyBJIGFt IGNvbmNlcm5lZCwgdGhhdCBkb2N1bWVudCBpcyBjbGVhciBhYm91dCB3aGF0IGlzIG5lZWRlZCB0 byBzdXBwb3J0IFNJUFMsIGFuZCB3aGF0IGlzIG5lZWRlZCB0byBzdXBwb3J0IHRyYW5zcG9ydD1U TFMuPGJyPg0KPGJyPg0KVGhlIHVzZSBvZiBTSVBTIHNob3VsZCBub3QgZ2VuZXJhdGUgYSBidWcg cmVwb3J0LCBiZWNhdXNlIGl0IGlzIG5vdCBhbiBlcnJvci4gWW91IG1heSBuZWVkIHRvIHJlamVj dCB0aGUgY2FsbCBiZWNhdXNlIHlvdSBjYW5ub3Qgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eSwgYnV0 IHRoYXQgaXMgbm8gZGlmZmVyZW50IHRvIG1hbnkgb3RoZXIgcmVhc29ucyBmb3IgcmVqZWN0aW9u Ljxicj4NCjxicj4NCldlIGRvIG5vdCBub3JtYWxseSBkZXByZWNhdGUgUkZDcyBqdXN0IGJlY2F1 c2UgcGVvcGxlIGhhdmUgZmFpbGVkIHRvIHJlYWQgdGhlIGRvY3VtZW50LCBvZiBmYWlsZWQgdG8g cHJvdmlkZSB0aGVpciBpbXBsZW1lbnRhdGlvbnMgaW4gY29uZm9ybWFuY2Ugd2l0aCB0aGUgZG9j dW1lbnQsIG9yIGV2ZW4ganVzdCBmYWlsZWQgdG8gaW1wbGVtZW50IGEgcGFydGljdWxhciBjYXBh YmlsaXR5Ljxicj4NCjxicj4NCklmIHlvdSBkb24ndCB3YW50IHRvIHN1cHBvcnQgU0lQUywgdGhl biBmaW5lLCB0aGF0IGlzIGFuIGFjY2VwdGFibGUgcG9zaXRpb24sIGJ1dCB5b3UgbmVlZCBtb3Jl IGV2aWRlbmNlIHRvIHRlbGwgdGhlIHdvcmxkIG5vdCB0byB1c2UgaXQuPGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPktlaXRoPC9zcGFu Pjxicj4NCjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+RnJvbTogSHV0dG9uLCBBbmRyZXcg W21haWx0bzo8YSBocmVmPSJtYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20iPmFuZHJldy5o dXR0b25AdW5pZnkuY29tPC9hPl08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5TZW50OiAx NCBKdW5lIDIwMTYgMTY6NTE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5UbzogUmljaGFy ZCBTaG9ja2V5OyBQZXRlcnNvbiwgSm9uOyBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpOyBET0xM WSwgTUFSVElOIEM7IFBhdWwgS3l6aXZhdDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkNj OiA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN1YmplY3Q6IFJFOiBbc2lwY29yZV0gU0lQUyBtdXN0IGRpZSwgZGllLCBkaWU8YnI+DQo8YnI+ DQpPTjogMTMgSnVuZSAyMDE2IFJpY2hhcmQgU2hvY2tleTxicj4NCjxicj4NCiZndDsgVGhvdWdo IGl0IGlzIHNwZWNpZmllZCBhcyBNVVNUIHN1cHBvcnQgaW4gdGhlIFNJUCBGb3J1bSBTSVBDb25u ZWN0PGJyPg0KJmd0OyBwcm9maWxlcyBmb3IgUEJYIHRvIFNQIG9uIHRoZSB3aXJlIGludGVncmF0 aW9uIHRvIG15IGtub3dsZWRnZSBpdCBoYXM8YnI+DQomZ3Q7IG5ldmVyIGJlZW4gaW1wbGVtZW50 ZWQgYnkgYW55IHZlbmRvciBvciBTU1AuJm5ic3A7IEluIHNob3J0IFNJUFMgaXMgYSB0b3RhbDxi cj4NCiZndDsgUGFpbiBpbiB0aGUgQXNzPGJyPg0KPGJyPg0KU0lQUyBpcyBhY3R1YWxseSBub3Qg cmVxdWlyZWQgYnkgU0lQY29ubmVjdCBhbHRob3VnaCBUTFMgaXMgYSBNVVNUIHJlcXVpcmVtZW50 IGhlbmNlIHRoZSBjb25mdXNpb24uPGJyPg0KPGJyPg0KV2hlbmV2ZXIgSSBoYXZlIHNlZW4gU0lQ UyB1c2VkIGl0IGhhcyByZXN1bHRlZCBpbiBzb21lIGtpbmQgb2YgYnVnIHJlcG9ydCBiZWluZyBn ZW5lcmF0ZWQgYW5kIEkgaGF2ZSB0byBzYXkgSSBoYXZlIG5vdCBoZWFyZCBvZiBpdCBiZWluZyB1 c2VkIGZvciBzb21lIHRpbWUuJm5ic3A7IEl0IG5lZWRzIHRvIGRlcHJlY2F0ZWQgYW5kIHRoZSB1 c2Ugb2YgVExTIGNsYXJpZmllZC48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF26140451MCHP04MSXglobal_-- From nobody Tue Jun 14 09:37:38 2016 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 8704312D6AD for ; Tue, 14 Jun 2016 09:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 d0wwJnA1KGCX for ; Tue, 14 Jun 2016 09:37:35 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 DD5E712D12F for ; Tue, 14 Jun 2016 09:37:34 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-04v.sys.comcast.net with SMTP id CrKzbcddK8RcDCrLKbqOUt; Tue, 14 Jun 2016 16:37:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465922254; bh=yfgYJFGheA965iuAexWaagxIg1+SFk1iwE0wohU/LN8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SntUpOTdMiRjoZOxHFJOqlVeG8hZ6sORd3P+PRIa+ztBfu0JaHA07HPtopjkbOpok mnXv3uLELrfkrnmt+FpftWvFK6VK+WCiVjApAx4W8w+bv9FbxrBVSO6y3Vz/qnEBNO yLtoa203m0miMQ/M7N/R6Du1jKVNX41UVlAjzd9Z8IiXJGAQmvPWnGsbQPCEzo1eXI Z6lcPy/+v3+b0lD+9C27QJU3WhTUEEsvcbkLLdbk1n4VeDBcQhxveHdkRat2lgy1my Ll69uYWXaG3tLanfYjeDFAOcVDwPen6vJaxQi8pVZHtwq/6Ry37W4aWqb1lLL2NjKw FWu00chJMzoZA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id 6gdZ1t00W3KdFy101gdZG7; Tue, 14 Jun 2016 16:37:33 +0000 To: sipcore@ietf.org References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Tue, 14 Jun 2016 12:37:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:37:36 -0000 On 6/14/16 12:04 PM, Drage, Keith (Nokia - GB) wrote: > Please confirm whether RFC 5630 (including annex A) is clear in this respect or not, and be specific about where it is not. You should not be implementing RFC 3261 without also implementing RFC 5630, as one updates the other. > > As far as I am concerned, that document is clear about what is needed to support SIPS, and what is needed to support transport=TLS. I just looked at it. An area that I would be concerned with is in topologies including SBCs. They aren't explicitly addressed, but that isn't surprising since almost none of the sip specs do. They do seem to be covered by section 5.1.1.3 on Derived Dialogs. But I don't know if those implementing or deploying SBCs would agree on that. If somebody doesn't think this applies to SBCs, they they might be treated as a "get out of jail free" card to stop using TLS. Another possible concern is calls that transition from SIPS to some non-SIP protocol. E.g., is it permissible to terminate a SIPS call on a PSTN gateway? I can't find anything in 5630 that considers these. On one had, I might really want the SIPS level security all the way to the gateway. On the other hand, if that works I might be deluded in thinking I have more security than is delivered by the PSTN. > The use of SIPS should not generate a bug report, because it is not an error. You may need to reject the call because you cannot support the capability, but that is no different to many other reasons for rejection. > > We do not normally deprecate RFCs just because people have failed to read the document, of failed to provide their implementations in conformance with the document, or even just failed to implement a particular capability. > > If you don't want to support SIPS, then fine, that is an acceptable position, but you need more evidence to tell the world not to use it. I have mixed feelings about this. ISTM the main problem is that you can't accurately claim that you support 3261 unless you build in code paths to support SIPS. But you are free to restrict your code to deployments that don't *use* SIPS. You might not ever test the SIPS paths (or even have a way to test them). What is the point of this? And if you are building UAC that connects via registration you will never be able to use SIPS unless you also implement and use Outbound. But Outbound support is optional. Perhaps the answer is to remove the mandatory to implement aspect of SIPS. Thanks, Paul > Keith > > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@unify.com] > Sent: 14 June 2016 16:51 > To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, MARTIN C; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: RE: [sipcore] SIPS must die, die, die > > ON: 13 June 2016 Richard Shockey > >> Though it is specified as MUST support in the SIP Forum SIPConnect >> profiles for PBX to SP on the wire integration to my knowledge it has >> never been implemented by any vendor or SSP. In short SIPS is a total >> Pain in the Ass > > SIPS is actually not required by SIPconnect although TLS is a MUST requirement hence the confusion. > > Whenever I have seen SIPS used it has resulted in some kind of bug report being generated and I have to say I have not heard of it being used for some time. It needs to deprecated and the use of TLS clarified. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 14 09:39:56 2016 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 BA37612D6AD for ; Tue, 14 Jun 2016 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 FQuZMdhhBaSd for ; Tue, 14 Jun 2016 09:39:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 F25DB12D811 for ; Tue, 14 Jun 2016 09:39:40 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1DEA6428B; Tue, 14 Jun 2016 18:39:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 14 Jun 2016 18:39:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82D3DF29-A60F-45A0-A4BE-4244D91435D4@edvina.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Hutton, Andrew" , "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:39:45 -0000 > On 14 Jun 2016, at 18:04, Drage, Keith (Nokia - GB) = wrote: >=20 > Please confirm whether RFC 5630 (including annex A) is clear in this = respect or not, and be specific about where it is not. You should not be = implementing RFC 3261 without also implementing RFC 5630, as one updates = the other. >=20 > As far as I am concerned, that document is clear about what is needed = to support SIPS, and what is needed to support transport=3DTLS. Yes, it points clearly to SIP Outbound (RFC 5626). Which also has very = few implementations. As an alternative it points to use of SIP client certs - which I can=E2=80= =99t find any clear specification of. >=20 > The use of SIPS should not generate a bug report, because it is not an = error. You may need to reject the call because you cannot support the = capability, but that is no different to many other reasons for = rejection. Agree. >=20 > We do not normally deprecate RFCs just because people have failed to = read the document, of failed to provide their implementations in = conformance with the document, or even just failed to implement a = particular capability. >=20 > If you don't want to support SIPS, then fine, that is an acceptable = position, but you need more evidence to tell the world not to use it. I think the fact that it still there blocks usage of TLS. But let=E2=80=99= s focus on proper use of TLS and how we can help that, because it seems like most people agree we need to look into that again. /O >=20 > Keith >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@unify.com]=20 > Sent: 14 June 2016 16:51 > To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, = MARTIN C; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: RE: [sipcore] SIPS must die, die, die >=20 > ON: 13 June 2016 Richard Shockey=20 >=20 >> Though it is specified as MUST support in the SIP Forum SIPConnect=20 >> profiles for PBX to SP on the wire integration to my knowledge it has=20= >> never been implemented by any vendor or SSP. In short SIPS is a = total=20 >> Pain in the Ass >=20 > SIPS is actually not required by SIPconnect although TLS is a MUST = requirement hence the confusion. >=20 > Whenever I have seen SIPS used it has resulted in some kind of bug = report being generated and I have to say I have not heard of it being = used for some time. It needs to deprecated and the use of TLS = clarified. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 09:41:44 2016 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 6A03412D826 for ; Tue, 14 Jun 2016 09:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xo-vRuwYfUqH for ; Tue, 14 Jun 2016 09:41:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 A6EB212D6AD for ; Tue, 14 Jun 2016 09:41:41 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A9AD4428B; Tue, 14 Jun 2016 18:41:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Jun 2016 18:41:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <582804FD-4C1E-47AE-8BAB-41B71D8285A2@edvina.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:41:43 -0000 > On 14 Jun 2016, at 18:37, Paul Kyzivat wrote: >=20 > On 6/14/16 12:04 PM, Drage, Keith (Nokia - GB) wrote: >> Please confirm whether RFC 5630 (including annex A) is clear in this = respect or not, and be specific about where it is not. You should not be = implementing RFC 3261 without also implementing RFC 5630, as one updates = the other. >>=20 >> As far as I am concerned, that document is clear about what is needed = to support SIPS, and what is needed to support transport=3DTLS. >=20 > I just looked at it. >=20 > An area that I would be concerned with is in topologies including = SBCs. They aren't explicitly addressed, but that isn't surprising since = almost none of the sip specs do. They do seem to be covered by section = 5.1.1.3 on Derived Dialogs. But I don't know if those implementing or = deploying SBCs would agree on that. If somebody doesn't think this = applies to SBCs, they they might be treated as a "get out of jail free" = card to stop using TLS. >=20 > Another possible concern is calls that transition from SIPS to some = non-SIP protocol. E.g., is it permissible to terminate a SIPS call on a = PSTN gateway? I can't find anything in 5630 that considers these. On one = had, I might really want the SIPS level security all the way to the = gateway. On the other hand, if that works I might be deluded in thinking = I have more security than is delivered by the PSTN. >=20 >> The use of SIPS should not generate a bug report, because it is not = an error. You may need to reject the call because you cannot support the = capability, but that is no different to many other reasons for = rejection. >>=20 >> We do not normally deprecate RFCs just because people have failed to = read the document, of failed to provide their implementations in = conformance with the document, or even just failed to implement a = particular capability. >>=20 >> If you don't want to support SIPS, then fine, that is an acceptable = position, but you need more evidence to tell the world not to use it. >=20 > I have mixed feelings about this. ISTM the main problem is that you = can't accurately claim that you support 3261 unless you build in code = paths to support SIPS. But you are free to restrict your code to = deployments that don't *use* SIPS. You might not ever test the SIPS = paths (or even have a way to test them). What is the point of this? That=E2=80=99s a good point. If we remove SIPS: it=E2=80=99s no longer = part of any requirements. >=20 > And if you are building UAC that connects via registration you will = never be able to use SIPS unless you also implement and use Outbound. = But Outbound support is optional. Well, the option is client certs) and mutual TLS auth, also discussed = (and dismissed=E2=80=A6) in 5630 ;-) >=20 > Perhaps the answer is to remove the mandatory to implement aspect of = SIPS. Yes. /O >=20 > Thanks, > Paul >=20 >> Keith >>=20 >> -----Original Message----- >> From: Hutton, Andrew [mailto:andrew.hutton@unify.com] >> Sent: 14 June 2016 16:51 >> To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, = MARTIN C; Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: RE: [sipcore] SIPS must die, die, die >>=20 >> ON: 13 June 2016 Richard Shockey >>=20 >>> Though it is specified as MUST support in the SIP Forum SIPConnect >>> profiles for PBX to SP on the wire integration to my knowledge it = has >>> never been implemented by any vendor or SSP. In short SIPS is a = total >>> Pain in the Ass >>=20 >> SIPS is actually not required by SIPconnect although TLS is a MUST = requirement hence the confusion. >>=20 >> Whenever I have seen SIPS used it has resulted in some kind of bug = report being generated and I have to say I have not heard of it being = used for some time. It needs to deprecated and the use of TLS = clarified. >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 14 09:48:23 2016 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 AB0D112D838 for ; Tue, 14 Jun 2016 09:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IXCAJUVpxsBB for ; Tue, 14 Jun 2016 09:48:21 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 4F93212D09B for ; Tue, 14 Jun 2016 09:48:21 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EGhABO023868; Tue, 14 Jun 2016 12:48:08 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23gerqs88d-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 12:48:08 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 12:48:07 -0400 From: "Rosen, Brian" To: Olle E Johansson Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRxlyG/SY16wE6P0aRRFbmNnyxmw== Date: Tue, 14 Jun 2016 16:48:06 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <582804FD-4C1E-47AE-8BAB-41B71D8285A2@edvina.net> In-Reply-To: <582804FD-4C1E-47AE-8BAB-41B71D8285A2@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.47] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:48:23 -0000 VGhlIGdvYWwgb2Ygc2lwcyBpcyB0aGF0IHlvdSBnZXQgYSBzZXNzaW9uIGVzdGFibGlzaGVkIHRo YXQgaGFzIFRMUyBlbmQgdG8gZW5kLCBob3AgYnkgaG9wLCBvciB5b3UgZG9u4oCZdCBnZXQgYSBz ZXNzaW9uIGVzdGFibGlzaGVkLg0KDQpUaGF0IHNlZW1zIHRvIG1lIHRvIGJlIGEgd29ydGh5IGdv YWwsIGFsdGhvdWdoIGl0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8ganVzdCBrbm93IGlmIGVhY2gg aG9wIHdhcyBUTFMgcHJvdGVjdGVkLg0KDQpBc2tpbmcgZm9yIFRMUyBpcyBuaWNlLCBrbm93aW5n IGl04oCZcyBoYXBwZW5lZCBpcyBtdWNoIGJldHRlci4gIFllcywgbHlpbmcgaXMgYWx3YXlzIHBv c3NpYmxlLg0KDQpJZiB3ZSBkZXByZWNhdGUgU0lQUywgd2hhdCBkbyB3ZSByZXBsYWNlIGl0IHdp dGggdGhhdCBnZXRzIHVzIHNvbWUga25vd2xlZGdlIG9mIFRMUyBpbiBldmVyeSBob3A/DQoNCkni gJltIGdlbmVyYWxseSBub3QgaW4gZmF2b3Igb2YgZGVwcmVjYXRpbmcgYSB1c2VmdWwgY2FwYWJp bGl0eSBqdXN0IGJlY2F1c2UgaW1wbGVtZW50YXRpb25zIGFyZSBsYWNraW5nLiAgSWYgaXQgZG9l c27igJl0IHdvcmssIHRoYXTigJlzIG9uZSB0aGluZy4gSWYgaW1wbGVtZW50b3JzIGNob3NlIG5v dCB0byBkbyBpdCwgYW5kIGRpZG7igJl0IHByb3ZpZGUgYW4gZWZmZWN0aXZlIGFsdGVybmF0aXZl LCB0aGVuIEkgaGF2ZSBzb21lIGhvcGUgdGhleSB3aWxsIGZpZ3VyZSBpdCBvdXQsIHVzdWFsbHkg d2hlbiBzb21ldGhpbmcgZ29lcyBob3JyaWJseSB3cm9uZy4NCg0KQnJpYW4NCj4gT24gSnVuIDE0 LCAyMDE2LCBhdCAxMjo0MSBQTSwgT2xsZSBFLiBKb2hhbnNzb24gPG9lakBlZHZpbmEubmV0PiB3 cm90ZToNCj4gDQo+IA0KPj4gT24gMTQgSnVuIDIwMTYsIGF0IDE4OjM3LCBQYXVsIEt5eml2YXQg PHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+PiANCj4+IE9uIDYvMTQvMTYgMTI6MDQg UE0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgd3JvdGU6DQo+Pj4gUGxlYXNlIGNvbmZpcm0g d2hldGhlciBSRkMgNTYzMCAoaW5jbHVkaW5nIGFubmV4IEEpIGlzIGNsZWFyIGluIHRoaXMgcmVz cGVjdCBvciBub3QsIGFuZCBiZSBzcGVjaWZpYyBhYm91dCB3aGVyZSBpdCBpcyBub3QuIFlvdSBz aG91bGQgbm90IGJlIGltcGxlbWVudGluZyBSRkMgMzI2MSB3aXRob3V0IGFsc28gaW1wbGVtZW50 aW5nIFJGQyA1NjMwLCBhcyBvbmUgdXBkYXRlcyB0aGUgb3RoZXIuDQo+Pj4gDQo+Pj4gQXMgZmFy IGFzIEkgYW0gY29uY2VybmVkLCB0aGF0IGRvY3VtZW50IGlzIGNsZWFyIGFib3V0IHdoYXQgaXMg bmVlZGVkIHRvIHN1cHBvcnQgU0lQUywgYW5kIHdoYXQgaXMgbmVlZGVkIHRvIHN1cHBvcnQgdHJh bnNwb3J0PVRMUy4NCj4+IA0KPj4gSSBqdXN0IGxvb2tlZCBhdCBpdC4NCj4+IA0KPj4gQW4gYXJl YSB0aGF0IEkgd291bGQgYmUgY29uY2VybmVkIHdpdGggaXMgaW4gdG9wb2xvZ2llcyBpbmNsdWRp bmcgU0JDcy4gVGhleSBhcmVuJ3QgZXhwbGljaXRseSBhZGRyZXNzZWQsIGJ1dCB0aGF0IGlzbid0 IHN1cnByaXNpbmcgc2luY2UgYWxtb3N0IG5vbmUgb2YgdGhlIHNpcCBzcGVjcyBkby4gVGhleSBk byBzZWVtIHRvIGJlIGNvdmVyZWQgYnkgc2VjdGlvbiA1LjEuMS4zIG9uIERlcml2ZWQgRGlhbG9n cy4gQnV0IEkgZG9uJ3Qga25vdyBpZiB0aG9zZSBpbXBsZW1lbnRpbmcgb3IgZGVwbG95aW5nIFNC Q3Mgd291bGQgYWdyZWUgb24gdGhhdC4gSWYgc29tZWJvZHkgZG9lc24ndCB0aGluayB0aGlzIGFw cGxpZXMgdG8gU0JDcywgdGhleSB0aGV5IG1pZ2h0IGJlIHRyZWF0ZWQgYXMgYSAiZ2V0IG91dCBv ZiBqYWlsIGZyZWUiIGNhcmQgdG8gc3RvcCB1c2luZyBUTFMuDQo+PiANCj4+IEFub3RoZXIgcG9z c2libGUgY29uY2VybiBpcyBjYWxscyB0aGF0IHRyYW5zaXRpb24gZnJvbSBTSVBTIHRvIHNvbWUg bm9uLVNJUCBwcm90b2NvbC4gRS5nLiwgaXMgaXQgcGVybWlzc2libGUgdG8gdGVybWluYXRlIGEg U0lQUyBjYWxsIG9uIGEgUFNUTiBnYXRld2F5PyBJIGNhbid0IGZpbmQgYW55dGhpbmcgaW4gNTYz MCB0aGF0IGNvbnNpZGVycyB0aGVzZS4gT24gb25lIGhhZCwgSSBtaWdodCByZWFsbHkgd2FudCB0 aGUgU0lQUyBsZXZlbCBzZWN1cml0eSBhbGwgdGhlIHdheSB0byB0aGUgZ2F0ZXdheS4gT24gdGhl IG90aGVyIGhhbmQsIGlmIHRoYXQgd29ya3MgSSBtaWdodCBiZSBkZWx1ZGVkIGluIHRoaW5raW5n IEkgaGF2ZSBtb3JlIHNlY3VyaXR5IHRoYW4gaXMgZGVsaXZlcmVkIGJ5IHRoZSBQU1ROLg0KPj4g DQo+Pj4gVGhlIHVzZSBvZiBTSVBTIHNob3VsZCBub3QgZ2VuZXJhdGUgYSBidWcgcmVwb3J0LCBi ZWNhdXNlIGl0IGlzIG5vdCBhbiBlcnJvci4gWW91IG1heSBuZWVkIHRvIHJlamVjdCB0aGUgY2Fs bCBiZWNhdXNlIHlvdSBjYW5ub3Qgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eSwgYnV0IHRoYXQgaXMg bm8gZGlmZmVyZW50IHRvIG1hbnkgb3RoZXIgcmVhc29ucyBmb3IgcmVqZWN0aW9uLg0KPj4+IA0K Pj4+IFdlIGRvIG5vdCBub3JtYWxseSBkZXByZWNhdGUgUkZDcyBqdXN0IGJlY2F1c2UgcGVvcGxl IGhhdmUgZmFpbGVkIHRvIHJlYWQgdGhlIGRvY3VtZW50LCBvZiBmYWlsZWQgdG8gcHJvdmlkZSB0 aGVpciBpbXBsZW1lbnRhdGlvbnMgaW4gY29uZm9ybWFuY2Ugd2l0aCB0aGUgZG9jdW1lbnQsIG9y IGV2ZW4ganVzdCBmYWlsZWQgdG8gaW1wbGVtZW50IGEgcGFydGljdWxhciBjYXBhYmlsaXR5Lg0K Pj4+IA0KPj4+IElmIHlvdSBkb24ndCB3YW50IHRvIHN1cHBvcnQgU0lQUywgdGhlbiBmaW5lLCB0 aGF0IGlzIGFuIGFjY2VwdGFibGUgcG9zaXRpb24sIGJ1dCB5b3UgbmVlZCBtb3JlIGV2aWRlbmNl IHRvIHRlbGwgdGhlIHdvcmxkIG5vdCB0byB1c2UgaXQuDQo+PiANCj4+IEkgaGF2ZSBtaXhlZCBm ZWVsaW5ncyBhYm91dCB0aGlzLiBJU1RNIHRoZSBtYWluIHByb2JsZW0gaXMgdGhhdCB5b3UgY2Fu J3QgYWNjdXJhdGVseSBjbGFpbSB0aGF0IHlvdSBzdXBwb3J0IDMyNjEgdW5sZXNzIHlvdSBidWls ZCBpbiBjb2RlIHBhdGhzIHRvIHN1cHBvcnQgU0lQUy4gQnV0IHlvdSBhcmUgZnJlZSB0byByZXN0 cmljdCB5b3VyIGNvZGUgdG8gZGVwbG95bWVudHMgdGhhdCBkb24ndCAqdXNlKiBTSVBTLiBZb3Ug bWlnaHQgbm90IGV2ZXIgdGVzdCB0aGUgU0lQUyBwYXRocyAob3IgZXZlbiBoYXZlIGEgd2F5IHRv IHRlc3QgdGhlbSkuIFdoYXQgaXMgdGhlIHBvaW50IG9mIHRoaXM/DQo+IFRoYXTigJlzIGEgZ29v ZCBwb2ludC4gSWYgd2UgcmVtb3ZlIFNJUFM6IGl04oCZcyBubyBsb25nZXIgcGFydCBvZiBhbnkg cmVxdWlyZW1lbnRzLg0KPj4gDQo+PiBBbmQgaWYgeW91IGFyZSBidWlsZGluZyBVQUMgdGhhdCBj b25uZWN0cyB2aWEgcmVnaXN0cmF0aW9uIHlvdSB3aWxsIG5ldmVyIGJlIGFibGUgdG8gdXNlIFNJ UFMgdW5sZXNzIHlvdSBhbHNvIGltcGxlbWVudCBhbmQgdXNlIE91dGJvdW5kLiBCdXQgT3V0Ym91 bmQgc3VwcG9ydCBpcyBvcHRpb25hbC4NCj4gV2VsbCwgdGhlIG9wdGlvbiBpcyBjbGllbnQgY2Vy dHMpIGFuZCBtdXR1YWwgVExTIGF1dGgsIGFsc28gZGlzY3Vzc2VkIChhbmQgZGlzbWlzc2Vk4oCm KSBpbiA1NjMwICA7LSkNCj4+IA0KPj4gUGVyaGFwcyB0aGUgYW5zd2VyIGlzIHRvIHJlbW92ZSB0 aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBhc3BlY3Qgb2YgU0lQUy4NCj4gWWVzLg0KPiANCj4g L08NCj4+IA0KPj4gCVRoYW5rcywNCj4+IAlQYXVsDQo+PiANCj4+PiBLZWl0aA0KPj4+IA0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSHV0dG9uLCBBbmRyZXcgW21h aWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbV0NCj4+PiBTZW50OiAxNCBKdW5lIDIwMTYgMTY6 NTENCj4+PiBUbzogUmljaGFyZCBTaG9ja2V5OyBQZXRlcnNvbiwgSm9uOyBEcmFnZSwgS2VpdGgg KE5va2lhIC0gR0IpOyBET0xMWSwgTUFSVElOIEM7IFBhdWwgS3l6aXZhdA0KPj4+IENjOiBzaXBj b3JlQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBTSVBTIG11c3QgZGllLCBk aWUsIGRpZQ0KPj4+IA0KPj4+IE9OOiAxMyBKdW5lIDIwMTYgUmljaGFyZCBTaG9ja2V5DQo+Pj4g DQo+Pj4+IFRob3VnaCBpdCBpcyBzcGVjaWZpZWQgYXMgTVVTVCBzdXBwb3J0IGluIHRoZSBTSVAg Rm9ydW0gU0lQQ29ubmVjdA0KPj4+PiBwcm9maWxlcyBmb3IgUEJYIHRvIFNQIG9uIHRoZSB3aXJl IGludGVncmF0aW9uIHRvIG15IGtub3dsZWRnZSBpdCBoYXMNCj4+Pj4gbmV2ZXIgYmVlbiBpbXBs ZW1lbnRlZCBieSBhbnkgdmVuZG9yIG9yIFNTUC4gIEluIHNob3J0IFNJUFMgaXMgYSB0b3RhbA0K Pj4+PiBQYWluIGluIHRoZSBBc3MNCj4+PiANCj4+PiBTSVBTIGlzIGFjdHVhbGx5IG5vdCByZXF1 aXJlZCBieSBTSVBjb25uZWN0IGFsdGhvdWdoIFRMUyBpcyBhIE1VU1QgcmVxdWlyZW1lbnQgaGVu Y2UgdGhlIGNvbmZ1c2lvbi4NCj4+PiANCj4+PiBXaGVuZXZlciBJIGhhdmUgc2VlbiBTSVBTIHVz ZWQgaXQgaGFzIHJlc3VsdGVkIGluIHNvbWUga2luZCBvZiBidWcgcmVwb3J0IGJlaW5nIGdlbmVy YXRlZCBhbmQgSSBoYXZlIHRvIHNheSBJIGhhdmUgbm90IGhlYXJkIG9mIGl0IGJlaW5nIHVzZWQg Zm9yIHNvbWUgdGltZS4gIEl0IG5lZWRzIHRvIGRlcHJlY2F0ZWQgYW5kIHRoZSB1c2Ugb2YgVExT IGNsYXJpZmllZC4NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4gc2lwY29yZUBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K Pj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWls aW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From nobody Tue Jun 14 09:53:03 2016 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 A19A712B022 for ; Tue, 14 Jun 2016 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 oI3SEe8f1eun for ; Tue, 14 Jun 2016 09:52:58 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 3BDA912D0E6 for ; Tue, 14 Jun 2016 09:52:58 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EGqqYn005177; Tue, 14 Jun 2016 12:52:52 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23gdejjdph-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 12:52:51 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 12:52:47 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8JcAA== Date: Tue, 14 Jun 2016 16:52:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3856F1719BE76jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140184 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:53:01 -0000 --_000_D3856F1719BE76jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Radhika sent a helpful summary of conference control protocols to the list = which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actuall= y let you manage attributes of a conference like the number of participants= and media types allowed. This conference use case was an example for a SIP-based conference server (= RFC4579), just to describe the idea around the delegation of AuthNZ. If the server is a CCMP-based conference, then you would obviously use that= to control and manage the conference server. While RFC4579 (an implementation of the RFC4353 framework) provides means t= o do conference control from within SIP, the kinds of control primitives it= specifies are totally decoupled from the sorts of policies that the attrib= utes you proposed would constrain. Those policies fall under what RFC4353 c= alls "conference policy." Neither RFC4579 nor its requirements (RFC4245) re= ally say anything about how conference policy is set or distributed. Authorizing SIP requests is misaligned with setting conference policy, espe= cially in consideration of the sorts of attributes you seem to have in mind= - even when we're considering controlling conferences compliant with the R= FC4353 framework. That's because the conference in RFC4579 isn't "created" when a user agent = sends an INVITE request to the conference bridge - it is created when the c= onference URI is created, which is necessarily beforehand. Conferences in t= he RF4353 framework are associated with conference policies, The example of CCMP shows that you can do conference control with OAuth ove= r in the HTTP realm without needing to add anything whatsoever to SIP. The interesting thing about protocols like CCMP is that they are not, you k= now, actually transported by SIP. CCMP is transported by HTTP. Why? Because= the semantics of conference control doesn't actually map onto SIP INVITE t= ransactions very well. They map quite aptly to HTTP, and in the HTTP contex= t, you can certainly use OAuth if you like. Help me understand this part. Why can an HTTP request transport a token to a resource server to be able t= o access a specific resource, while SIP request cannot transport a similar = token to a SIP server to access a service? Of course both SIP and HTTP can carry arbitrary chunks of data, including a= ny sort of token we can imagine. My point is that the semantics of an INVIT= E are really different from the semantics of a POST - and that is why, ulti= mately, protocols like CCMP don't use SIP as a transport but instead use HT= TP. INVITEs are sent by a user agent when it is trying to set up a media s= ession between itself and some remote resource on the Internet. While RFC45= 79 has a way to set up a conference as a side effect of sending an INVITE t= o connect to the conference, must of the subsequent control work happens to= tally outside the context of that dialog, and the authorization of those op= erations is completely disconnected from the authorization of the conferenc= e-opening INVITE. And of course, SIP can support faux-HTTP semantics with mechanisms like PUB= LISH and NOTIFY. But I think the interesting question about standardizing a= n approach to authorization of SIP requests is about INVITE. You even will find some text about Role-Based Access Control in the XCON (R= FC6503) security consideration. Although you can use SIP and SDP to set up = a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS betw= een its own endpoints. It is unclear to me what carrying attribute informat= ion around in a SIP INVITE would accomplish with regards to authorizing CCM= P or BFCP transactions. SIP INVITE will carry attributes to authorize that specific SIP request; th= ere is nothing in proposal #3 that suggest that SIP will carry authorizatio= n for CCMP or any other protocol. That is where I think you and I have a disconnect. The SIP INVITE in the co= nference control (RFC4579) case would not carry attributes like the ones yo= u've identified in order to authorize that specific SIP request. The attrib= utes that you identified, the media types the conference allows and the num= ber of participants permitted simultaneously in a conference, have nothing = to do with the SIP INVITE that opens the conference bridge. Those attribute= s apply to authorization decisions regarding later participants that will b= e added to the conference. We can imagine that the So again, the point of my last mail was that the problem of authorizing SIP= INVITEs is actually different from the problem of authorizing generic appl= ication transactions. SIP INVITEs still have more or less the semantics of = a call setup message: they are requesting that a session be initiated. Conf= erence control is not managed with SIP transactions, and the security of co= nference control protocols does not devolve to authorizing SIP transactions= . Well, RFC4579 defines a SIP Conference Control mechanism that allows you to= initiate and control a conference server using only SIP requests; so I am = not sure I understand this statement, unless we have different definitions = for the term =93conference control=94. In any case, my point was not to discuss conference servers specifically, b= ut to discuss the general idea of delegating both AuthN and AuthZ in a SIP = network. If you could furnish an example of attributes that would be carried in a SI= P iNVITE that are actually salient to the authorization of that particular = SIP request, we'd be getting a lot closer to common ground. Jon Peterson Neustar, Inc. Regards, Rifaat I suspect we'll find that most of the other security attributes that "appli= cations" need to do their jobs similarly don't map onto the semantics of a = SIP INVITE - but, I'm still open to entertaining examples that might cast d= oubt on that suspicion. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, June 9, 2016 at 10:59 AM To: Jon Peterson = > Cc: Christer Holmberg >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Hi Jon, Sorry for the delayed reply. Let's take the video conference example, and discuss the possible ways for = the conference server to provide service. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Possible solutions: 1. Conference Server acts as an AuthN and AuthZ server. Requests to the ser= ver must provide an identity and credentials, and services will be provided= based on locally stored information associated with the identity provided = in the request. 2. Conference Server acts as an AuthZ server, but delegates the AuthN part.= Requests to the server must provide an identity token, and services will b= e provided based on locally stored information associated with the identity= provided in the token. 3. Conference Server delegates both AuthN and AuthZ parts. Requests to the = server must provide an access token, which might or might not include infor= mation about the user requesting the service, and services will be provided= based on information provided in the access token or as a result of an int= rospection step using the access token. Now, let's look at the 3rd option a bit more, and assume that the server pr= ovides the following types of conference services: 1. audio conference 2. audio/video conference 3. web conference or some combination of the above. Let's also assume that the server allows control over the number of partici= pants allowed in each one of these conference types or combinations. Here is one way that I envisioned we could use to address this use case: When an enterprise user in the 1st trust domain wants to register with the = SIP Proxy, it will have to authenticate to the IdP and as a result either t= he UA or the Proxy (depends on the UA's capabilities) will be provided with= an AuthN and AuthZ tokens. This process could involve an interim step to a= llow only the proxy to get access to the tokens, or the tokens could be sen= t to the UA which will then use them to communicate with the proxy. The AuthN token is the identity of the user, and the AuthZ token has all th= e services granted to the user by the IdP/AuthZ Service. When the enterprise user needs access to the conference service, the UA wil= l send an INVITE to the Proxy, and will include the AuthZ token if it is in= possession of the tokens; otherwise, the proxy will add the appropriate to= ken to the outgoing INVITE sent to the conference server. The scope of the AuthZ token might grant the user access to multiple servic= es; to avoid sending that AuthZ token to all servers providing services gra= nted to the user, the proxy could obtain a different token with limited sco= pe that is specific to the service being provided (conference services in t= his case); there is a standard Token Exchange mechanism for that. The AuthZ token will include information about the type of service allowed = (audio, audio/video, etc), and the limit on the number of participants. The= AuthZ token might or might not have any information about the user request= ing the service, which depends on the level of privacy needed. When the conference server receives this token in the SIP INVITE, all it ha= s to do is validate that the token was signed by an IdP that it has a trust= relationship with, and provide the service requested by the AuthZ token. T= he conference server does not need the AuthN token to be able to provide a = service. Regards, Rifaat On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon > wrote: Also, if we decided to separate the AuthN and AuthZ, then we might need to = carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to th= e UA; in this case there is a need for an interim step to get the token(s) = to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries. Jon Peterson Neustar, Inc. --_000_D3856F1719BE76jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <994E14D110FDD74780CA130274BD6076@neustar.biz> Content-Transfer-Encoding: quoted-printable
Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed.

This conference use case was an e= xample for a SIP-based conference server (RFC4579), just to describe the id= ea around the delegation of AuthNZ.

If the server is a CCMP-based con= ference, then you would obviously use that to control and manage the confer= ence server.

While RFC4579 (an implementation of the RFC4353 framework) provides me= ans to do conference control from within SIP, the kinds of control primitiv= es it specifies are totally decoupled from the sorts of policies that the a= ttributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy."= ; Neither RFC4579 nor its requirements (RFC4245) really say anything about = how conference policy is set or distributed.


Authorizing SIP requests is misaligned with setting conference policy,= especially in consideration of the sorts of attributes you seem to have in= mind - even when we're considering controlling conferences compliant with = the RFC4353 framework. 

That's because the conference in RFC4579 isn't "created" whe= n a user agent sends an INVITE request to the conference bridge - it is cre= ated when the conference URI is created, which is necessarily beforehand. C= onferences in the RF4353 framework are associated with conference policies, 



The example of CCMP shows that you can do conference control with OAut= h over in the HTTP realm without needing to add anything whatsoever to SIP.=  


 
The interesting thing about protocols like CCMP is that they are not, = you know, actually transported by SIP. CCMP is transported by HTTP. Why? Be= cause the semantics of conference control doesn't actually map onto SIP INV= ITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OA= uth if you like.
 

Help me understand this part.

Why can an HTTP request transport= a token to a resource server to be able to access a specific resource, whi= le SIP request cannot transport a similar token to a SIP server to access a= service?

Of course both SIP and HTTP can carry arbitrary chunks of data, includ= ing any sort of token we can imagine. My point is that the semantics of an = INVITE are really different from the semantics of a POST - and that is why,= ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent = by a user agent when it is trying to set up a media session between itself = and some remote resource on the Internet. While RFC4579 has a way to set up= a conference as a side effect of sending an INVITE to connect to the conference, must of the subsequent control wor= k happens totally outside the context of that dialog, and the authorization= of those operations is completely disconnected from the authorization of t= he conference-opening INVITE.

And of course, SIP can support faux-HTTP semantics with mechanisms lik= e PUBLISH and NOTIFY. But I think the interesting question about standardiz= ing an approach to authorization of SIP requests is about INVITE.


You even will find some text about Role-Based Access Control in the XC= ON (RFC6503) security consideration. Although you can use SIP and SDP to se= t up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS= between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes = to authorize that specific SIP request; there is nothing in proposal #3 tha= t suggest that SIP will carry authorization for CCMP or any other protocol.=


That is where I think you and I have a disconnect. The SIP INVITE in t= he conference control (RFC4579) case would not carry attributes like the on= es you've identified in order to authorize that specific SIP request. The a= ttributes that you identified, the media types the conference allows and the number of participants permitted= simultaneously in a conference, have nothing to do with the SIP INVITE tha= t opens the conference bridge. Those attributes apply to authorization deci= sions regarding later participants that will be added to the conference.

We can imagine that the 



So again, the point of my last mail was that the problem of authorizin= g SIP INVITEs is actually different from the problem of authorizing generic= application transactions. SIP INVITEs still have more or less the semantic= s of a call setup message: they are requesting that a session be initiated. Conference control is not mana= ged with SIP transactions, and the security of conference control protocols= does not devolve to authorizing SIP transactions.

Well, RFC4579 defines a SIP Confe= rence Control mechanism that allows you to initiate and control a conferenc= e server using only SIP requests; so I am not sure I understand this statem= ent, unless we have different definitions for the term =93conference control=94.

 

In any case, my point was not to = discuss conference servers specifically, but to discuss the general idea of= delegating both AuthN and AuthZ in a SIP network.

If you could furnish an example of attributes that would be carried in= a SIP iNVITE that are actually salient to the authorization of that partic= ular SIP request, we'd be getting a lot closer to common ground.

Jon Peterson
Neustar, Inc.

 

Regards,

 Rifaat



 
I suspect we'll find that most of the other security attributes that &= quot;applications" need to do their jobs similarly don't map onto the = semantics of a SIP INVITE - but, I'm still open to entertaining examples th= at might cast doubt on that suspicion. 

Jon Peterson
Neustar, Inc.


Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference exa= mple, and discuss the possible ways for the conference server to provide service.


         T= rust Domain 1              :   &nbs= p;Internet     :  Trust Domain 2
          =                      = ;      :               &n= bsp; :
          =             +--------+     = :                 :
          =             | IdP    |    = ; :                 :
        +--= -----------| AuthZ  |     :         &nbs= p;       :
        |  = ;           |        |   =   :                 :
        |  = ;           +--------+     : &nb= sp;               :
        |  = ;               |       &= nbsp;  :                 :
        |  = ;               |       &= nbsp;  :                 :
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
    |      = ;  |        | SIP    |     : &= nbsp;               :     | SI= P App|
    |   UA   |-= -------| Proxy  |-----:-----------------:-----| Video  |
    |      = ;  |        |        |   =   :                 :   &= nbsp; | Conference
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
          =                      = ;      :               &n= bsp; :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the server must provide an identity a= nd credentials, and services will be provided based on locally stored = information associated with the identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part. Requests to the server must p= rovide an identity token, and services will be provided based on local= ly stored information associated with the identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the server must provide an access = token, which might or might not include information about the user req= uesting the service, and services will be provided based on information provided in the access token or as a result of a= n introspection step using the access token.


Now, let's look at the 3rd option a= bit more, and assume that the server provides the following types of = conference services:
1. audio conference
2. audio/video conference
3. web conference

or some combination of th= e above.

Let's also assume that the server a= llows control over the number of participants allowed in each one of t= hese conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the SIP Proxy, it will have to authenti= cate to the IdP and as a result either the UA or the Proxy (depends on= the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step = ;to allow only the proxy to get access to the tokens, or the tokens could b= e sent to the UA which will then use them to communicate with the prox= y.

The AuthN token is the identity of the user, and the AuthZ token has all&nb= sp;the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA&nbs= p;will send an INVITE to the Proxy, and will include the AuthZ token if it = is in possession of the tokens; otherwise, the proxy will add the appr= opriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple s= ervices; to avoid sending that AuthZ token to all servers providing se= rvices granted to the user, the proxy could obtain a different token with&n= bsp;limited scope that is specific to the service being provided (conference services in this case); there is a standar= d Token Exchange mechanism for that.

The AuthZ token will include information about the type of service allowed&= nbsp;(audio, audio/video, etc), and the limit on the number of participants= . The AuthZ token might or might not have any information about the us= er requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it&nb= sp;has to do is validate that the token was signed by an IdP that it has a&= nbsp;trust relationship with, and provide the service requested by the Auth= Z token. The conference server does not need the AuthN token to be able to provide a service.

Regards,
 Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or less= what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond requir= ements. Today, I think that much of the useful work that could be done on t= he authorization question is in identifying which SIP authorization policie= s are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.  The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lot of= light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who op= ens the conference bridge needs to be charged, that's identity information = - which in its usual form will convey the individual user and their domain,= like user@domain. If you need more complex semantics than that, it's probably because you're doing something = more complicated than just calling in to the conference. But it's less clea= r to me why you'd use SIP for such cases. Drilling down deeper into these u= se cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which larg= ely involve billing (including when dealing with various protocol gateways)= and resource management (both preemption and priority), ultimately didn't = seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.&n= bsp;

Jon Peterson
Neustar, Inc.


 --_000_D3856F1719BE76jonpetersonneustarbiz_-- From nobody Tue Jun 14 09:57:10 2016 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 2CF7312D855 for ; Tue, 14 Jun 2016 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 zB7M3DrN6JvL for ; Tue, 14 Jun 2016 09:57:06 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 8E0D512D80C for ; Tue, 14 Jun 2016 09:57:06 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EGqraA005189; Tue, 14 Jun 2016 12:57:01 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23gdejjean-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 12:57:01 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 12:56:59 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8JcAIAAAS8A Date: Tue, 14 Jun 2016 16:56:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D38584BD19C0DFjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140184 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:57:09 -0000 --_000_D38584BD19C0DFjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Um, sorry, this mail got sent accidentally well before it was completed. Le= t me try to repair it and resend. Jon Peterson Neustar, Inc. From: Jon Peterson > Date: Tuesday, June 14, 2016 at 9:52 AM To: Rifaat Shekh-Yusef = > Cc: Christer Holmberg >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Radhika sent a helpful summary of conference control protocols to the list = which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actuall= y let you manage attributes of a conference like the number of participants= and media types allowed. This conference use case was an example for a SIP-based conference server (= RFC4579), just to describe the idea around the delegation of AuthNZ. If the server is a CCMP-based conference, then you would obviously use that= to control and manage the conference server. While RFC4579 (an implementation of the RFC4353 framework) provides means t= o do conference control from within SIP, the kinds of control primitives it= specifies are totally decoupled from the sorts of policies that the attrib= utes you proposed would constrain. Those policies fall under what RFC4353 c= alls "conference policy." Neither RFC4579 nor its requirements (RFC4245) re= ally say anything about how conference policy is set or distributed. Authorizing SIP requests is misaligned with setting conference policy, espe= cially in consideration of the sorts of attributes you seem to have in mind= - even when we're considering controlling conferences compliant with the R= FC4353 framework. That's because the conference in RFC4579 isn't "created" when a user agent = sends an INVITE request to the conference bridge - it is created when the c= onference URI is created, which is necessarily beforehand. Conferences in t= he RF4353 framework are associated with conference policies, The example of CCMP shows that you can do conference control with OAuth ove= r in the HTTP realm without needing to add anything whatsoever to SIP. The interesting thing about protocols like CCMP is that they are not, you k= now, actually transported by SIP. CCMP is transported by HTTP. Why? Because= the semantics of conference control doesn't actually map onto SIP INVITE t= ransactions very well. They map quite aptly to HTTP, and in the HTTP contex= t, you can certainly use OAuth if you like. Help me understand this part. Why can an HTTP request transport a token to a resource server to be able t= o access a specific resource, while SIP request cannot transport a similar = token to a SIP server to access a service? Of course both SIP and HTTP can carry arbitrary chunks of data, including a= ny sort of token we can imagine. My point is that the semantics of an INVIT= E are really different from the semantics of a POST - and that is why, ulti= mately, protocols like CCMP don't use SIP as a transport but instead use HT= TP. INVITEs are sent by a user agent when it is trying to set up a media s= ession between itself and some remote resource on the Internet. While RFC45= 79 has a way to set up a conference as a side effect of sending an INVITE t= o connect to the conference, must of the subsequent control work happens to= tally outside the context of that dialog, and the authorization of those op= erations is completely disconnected from the authorization of the conferenc= e-opening INVITE. And of course, SIP can support faux-HTTP semantics with mechanisms like PUB= LISH and NOTIFY. But I think the interesting question about standardizing a= n approach to authorization of SIP requests is about INVITE. You even will find some text about Role-Based Access Control in the XCON (R= FC6503) security consideration. Although you can use SIP and SDP to set up = a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS betw= een its own endpoints. It is unclear to me what carrying attribute informat= ion around in a SIP INVITE would accomplish with regards to authorizing CCM= P or BFCP transactions. SIP INVITE will carry attributes to authorize that specific SIP request; th= ere is nothing in proposal #3 that suggest that SIP will carry authorizatio= n for CCMP or any other protocol. That is where I think you and I have a disconnect. The SIP INVITE in the co= nference control (RFC4579) case would not carry attributes like the ones yo= u've identified in order to authorize that specific SIP request. The attrib= utes that you identified, the media types the conference allows and the num= ber of participants permitted simultaneously in a conference, have nothing = to do with the SIP INVITE that opens the conference bridge. Those attribute= s apply to authorization decisions regarding later participants that will b= e added to the conference. We can imagine that the So again, the point of my last mail was that the problem of authorizing SIP= INVITEs is actually different from the problem of authorizing generic appl= ication transactions. SIP INVITEs still have more or less the semantics of = a call setup message: they are requesting that a session be initiated. Conf= erence control is not managed with SIP transactions, and the security of co= nference control protocols does not devolve to authorizing SIP transactions= . Well, RFC4579 defines a SIP Conference Control mechanism that allows you to= initiate and control a conference server using only SIP requests; so I am = not sure I understand this statement, unless we have different definitions = for the term =93conference control=94. In any case, my point was not to discuss conference servers specifically, b= ut to discuss the general idea of delegating both AuthN and AuthZ in a SIP = network. If you could furnish an example of attributes that would be carried in a SI= P iNVITE that are actually salient to the authorization of that particular = SIP request, we'd be getting a lot closer to common ground. Jon Peterson Neustar, Inc. Regards, Rifaat I suspect we'll find that most of the other security attributes that "appli= cations" need to do their jobs similarly don't map onto the semantics of a = SIP INVITE - but, I'm still open to entertaining examples that might cast d= oubt on that suspicion. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, June 9, 2016 at 10:59 AM To: Jon Peterson = > Cc: Christer Holmberg >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Hi Jon, Sorry for the delayed reply. Let's take the video conference example, and discuss the possible ways for = the conference server to provide service. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Possible solutions: 1. Conference Server acts as an AuthN and AuthZ server. Requests to the ser= ver must provide an identity and credentials, and services will be provided= based on locally stored information associated with the identity provided = in the request. 2. Conference Server acts as an AuthZ server, but delegates the AuthN part.= Requests to the server must provide an identity token, and services will b= e provided based on locally stored information associated with the identity= provided in the token. 3. Conference Server delegates both AuthN and AuthZ parts. Requests to the = server must provide an access token, which might or might not include infor= mation about the user requesting the service, and services will be provided= based on information provided in the access token or as a result of an int= rospection step using the access token. Now, let's look at the 3rd option a bit more, and assume that the server pr= ovides the following types of conference services: 1. audio conference 2. audio/video conference 3. web conference or some combination of the above. Let's also assume that the server allows control over the number of partici= pants allowed in each one of these conference types or combinations. Here is one way that I envisioned we could use to address this use case: When an enterprise user in the 1st trust domain wants to register with the = SIP Proxy, it will have to authenticate to the IdP and as a result either t= he UA or the Proxy (depends on the UA's capabilities) will be provided with= an AuthN and AuthZ tokens. This process could involve an interim step to a= llow only the proxy to get access to the tokens, or the tokens could be sen= t to the UA which will then use them to communicate with the proxy. The AuthN token is the identity of the user, and the AuthZ token has all th= e services granted to the user by the IdP/AuthZ Service. When the enterprise user needs access to the conference service, the UA wil= l send an INVITE to the Proxy, and will include the AuthZ token if it is in= possession of the tokens; otherwise, the proxy will add the appropriate to= ken to the outgoing INVITE sent to the conference server. The scope of the AuthZ token might grant the user access to multiple servic= es; to avoid sending that AuthZ token to all servers providing services gra= nted to the user, the proxy could obtain a different token with limited sco= pe that is specific to the service being provided (conference services in t= his case); there is a standard Token Exchange mechanism for that. The AuthZ token will include information about the type of service allowed = (audio, audio/video, etc), and the limit on the number of participants. The= AuthZ token might or might not have any information about the user request= ing the service, which depends on the level of privacy needed. When the conference server receives this token in the SIP INVITE, all it ha= s to do is validate that the token was signed by an IdP that it has a trust= relationship with, and provide the service requested by the AuthZ token. T= he conference server does not need the AuthN token to be able to provide a = service. Regards, Rifaat On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon > wrote: Also, if we decided to separate the AuthN and AuthZ, then we might need to = carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to th= e UA; in this case there is a need for an interim step to get the token(s) = to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries. Jon Peterson Neustar, Inc. --_000_D38584BD19C0DFjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8D7F9C30B4770246AA28A0F67096FDC4@neustar.biz> Content-Transfer-Encoding: quoted-printable

Um, sorry, this mail got sent accidentally well before it was complete= d. Let me try to repair it and resend.

Jon Peterson
Neustar, Inc.

From: Jon Peterson <jon.peterson@neustar.biz>
Date: Tuesday, June 14, 2016 at 9:5= 2 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@ietf.org"= ; <sipcore@ietf.org>
Subject: Re: [sipcore] SIP AuthNZ P= roblem Statement - v3

Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed.

This conference use case was an e= xample for a SIP-based conference server (RFC4579), just to describe the id= ea around the delegation of AuthNZ.

If the server is a CCMP-based con= ference, then you would obviously use that to control and manage the confer= ence server.

While RFC4579 (an implementation of the RFC4353 framework) provides me= ans to do conference control from within SIP, the kinds of control primitiv= es it specifies are totally decoupled from the sorts of policies that the a= ttributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy."= ; Neither RFC4579 nor its requirements (RFC4245) really say anything about = how conference policy is set or distributed.


Authorizing SIP requests is misaligned with setting conference policy,= especially in consideration of the sorts of attributes you seem to have in= mind - even when we're considering controlling conferences compliant with = the RFC4353 framework. 

That's because the conference in RFC4579 isn't "created" whe= n a user agent sends an INVITE request to the conference bridge - it is cre= ated when the conference URI is created, which is necessarily beforehand. C= onferences in the RF4353 framework are associated with conference policies, 



The example of CCMP shows that you can do conference control with OAut= h over in the HTTP realm without needing to add anything whatsoever to SIP.=  


 
The interesting thing about protocols like CCMP is that they are not, = you know, actually transported by SIP. CCMP is transported by HTTP. Why? Be= cause the semantics of conference control doesn't actually map onto SIP INV= ITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OA= uth if you like.
 

Help me understand this part.

Why can an HTTP request transport= a token to a resource server to be able to access a specific resource, whi= le SIP request cannot transport a similar token to a SIP server to access a= service?

Of course both SIP and HTTP can carry arbitrary chunks of data, includ= ing any sort of token we can imagine. My point is that the semantics of an = INVITE are really different from the semantics of a POST - and that is why,= ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent = by a user agent when it is trying to set up a media session between itself = and some remote resource on the Internet. While RFC4579 has a way to set up= a conference as a side effect of sending an INVITE to connect to the conference, must of the subsequent control wor= k happens totally outside the context of that dialog, and the authorization= of those operations is completely disconnected from the authorization of t= he conference-opening INVITE.

And of course, SIP can support faux-HTTP semantics with mechanisms lik= e PUBLISH and NOTIFY. But I think the interesting question about standardiz= ing an approach to authorization of SIP requests is about INVITE.


You even will find some text about Role-Based Access Control in the XC= ON (RFC6503) security consideration. Although you can use SIP and SDP to se= t up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS= between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes = to authorize that specific SIP request; there is nothing in proposal #3 tha= t suggest that SIP will carry authorization for CCMP or any other protocol.=


That is where I think you and I have a disconnect. The SIP INVITE in t= he conference control (RFC4579) case would not carry attributes like the on= es you've identified in order to authorize that specific SIP request. The a= ttributes that you identified, the media types the conference allows and the number of participants permitted= simultaneously in a conference, have nothing to do with the SIP INVITE tha= t opens the conference bridge. Those attributes apply to authorization deci= sions regarding later participants that will be added to the conference.

We can imagine that the 



So again, the point of my last mail was that the problem of authorizin= g SIP INVITEs is actually different from the problem of authorizing generic= application transactions. SIP INVITEs still have more or less the semantic= s of a call setup message: they are requesting that a session be initiated. Conference control is not mana= ged with SIP transactions, and the security of conference control protocols= does not devolve to authorizing SIP transactions.

Well, RFC4579 defines a SIP Confe= rence Control mechanism that allows you to initiate and control a conferenc= e server using only SIP requests; so I am not sure I understand this statem= ent, unless we have different definitions for the term =93conference control=94.

 

In any case, my point was not to = discuss conference servers specifically, but to discuss the general idea of= delegating both AuthN and AuthZ in a SIP network.

If you could furnish an example of attributes that would be carried in= a SIP iNVITE that are actually salient to the authorization of that partic= ular SIP request, we'd be getting a lot closer to common ground.

Jon Peterson
Neustar, Inc.

 

Regards,

 Rifaat



 
I suspect we'll find that most of the other security attributes that &= quot;applications" need to do their jobs similarly don't map onto the = semantics of a SIP INVITE - but, I'm still open to entertaining examples th= at might cast doubt on that suspicion. 

Jon Peterson
Neustar, Inc.


Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference exa= mple, and discuss the possible ways for the conference server to provide service.


         T= rust Domain 1              :   &nbs= p;Internet     :  Trust Domain 2
          =                      = ;      :               &n= bsp; :
          =             +--------+     = :                 :
          =             | IdP    |    = ; :                 :
        +--= -----------| AuthZ  |     :         &nbs= p;       :
        |  = ;           |        |   =   :                 :
        |  = ;           +--------+     : &nb= sp;               :
        |  = ;               |       &= nbsp;  :                 :
        |  = ;               |       &= nbsp;  :                 :
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
    |      = ;  |        | SIP    |     : &= nbsp;               :     | SI= P App|
    |   UA   |-= -------| Proxy  |-----:-----------------:-----| Video  |
    |      = ;  |        |        |   =   :                 :   &= nbsp; | Conference
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
          =                      = ;      :               &n= bsp; :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the server must provide an identity a= nd credentials, and services will be provided based on locally stored = information associated with the identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part. Requests to the server must p= rovide an identity token, and services will be provided based on local= ly stored information associated with the identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the server must provide an access = token, which might or might not include information about the user req= uesting the service, and services will be provided based on information provided in the access token or as a result of a= n introspection step using the access token.


Now, let's look at the 3rd option a= bit more, and assume that the server provides the following types of = conference services:
1. audio conference
2. audio/video conference
3. web conference

or some combination of th= e above.

Let's also assume that the server a= llows control over the number of participants allowed in each one of t= hese conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the SIP Proxy, it will have to authenti= cate to the IdP and as a result either the UA or the Proxy (depends on= the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step = ;to allow only the proxy to get access to the tokens, or the tokens could b= e sent to the UA which will then use them to communicate with the prox= y.

The AuthN token is the identity of the user, and the AuthZ token has all&nb= sp;the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA&nbs= p;will send an INVITE to the Proxy, and will include the AuthZ token if it = is in possession of the tokens; otherwise, the proxy will add the appr= opriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple s= ervices; to avoid sending that AuthZ token to all servers providing se= rvices granted to the user, the proxy could obtain a different token with&n= bsp;limited scope that is specific to the service being provided (conference services in this case); there is a standar= d Token Exchange mechanism for that.

The AuthZ token will include information about the type of service allowed&= nbsp;(audio, audio/video, etc), and the limit on the number of participants= . The AuthZ token might or might not have any information about the us= er requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it&nb= sp;has to do is validate that the token was signed by an IdP that it has a&= nbsp;trust relationship with, and provide the service requested by the Auth= Z token. The conference server does not need the AuthN token to be able to provide a service.

Regards,
 Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or less= what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond requir= ements. Today, I think that much of the useful work that could be done on t= he authorization question is in identifying which SIP authorization policie= s are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.  The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lot of= light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who op= ens the conference bridge needs to be charged, that's identity information = - which in its usual form will convey the individual user and their domain,= like user@domain. If you need more complex semantics than that, it's probably because you're doing something = more complicated than just calling in to the conference. But it's less clea= r to me why you'd use SIP for such cases. Drilling down deeper into these u= se cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which larg= ely involve billing (including when dealing with various protocol gateways)= and resource management (both preemption and priority), ultimately didn't = seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.&n= bsp;

Jon Peterson
Neustar, Inc.


 --_000_D38584BD19C0DFjonpetersonneustarbiz_-- From nobody Tue Jun 14 10:27:38 2016 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 2DD6712D87C for ; Tue, 14 Jun 2016 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wikhpOfhxvwc for ; Tue, 14 Jun 2016 10:27:34 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 8D7C912D876 for ; Tue, 14 Jun 2016 10:27:34 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EHNIJO005383; Tue, 14 Jun 2016 13:27:33 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23gd9uhw52-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 13:27:32 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 13:27:31 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAA== Date: Tue, 14 Jun 2016 17:27:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D385862C19C10Cjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140189 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:27:37 -0000 --_000_D385862C19C10Cjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This time my response should be more complete. Sorry about that! Radhika sent a helpful summary of conference control protocols to the list = which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actuall= y let you manage attributes of a conference like the number of participants= and media types allowed. This conference use case was an example for a SIP-based conference server (= RFC4579), just to describe the idea around the delegation of AuthNZ. If the server is a CCMP-based conference, then you would obviously use that= to control and manage the conference server. While RFC4579 (an implementation of the RFC4353 framework) provides a means= to do conference control from within SIP, the kinds of control primitives = it specifies are totally decoupled from the sorts of policies that the attr= ibutes you proposed would constrain. Those policies fall under what RFC4353= calls "conference policy." Neither RFC4579 nor its requirements (RFC4245) = really say anything about how conference policy is set or distributed. RFC4= 353 does, though, and what it says is (in 4.6) is "the conference policy ca= n be manipulated using web applications or voice applications [i.e. IVRs - = JFP]. It can also be manipulated with non-SIP-specific standard or propriet= ary protocols." Authorizing SIP requests is misaligned with setting conference policy, espe= cially in consideration of the sorts of attributes you seem to have in mind= - even when we're considering controlling conferences compliant with the R= FC4353 framework. That's because the conference in RFC4579 isn't "created"= when a user agent sends an INVITE request to the conference bridge - it is= created when the conference URI is created, which is necessarily beforehan= d (or at best, ad hoc through the conference factory). Conference policy is= set and disseminated in that context, not in the context of the SIP transa= ction that happens to open the bridge. Moreover, my point was that the example of CCMP shows that you can do confe= rence control with OAuth over in the HTTP realm without needing to add anyt= hing whatsoever to SIP. If you need OAuth-style controls for conferencing,= that would seem to be a quicker path to implementation. The interesting thing about protocols like CCMP is that they are not, you k= now, actually transported by SIP. CCMP is transported by HTTP. Why? Because= the semantics of conference control doesn't actually map onto SIP INVITE t= ransactions very well. They map quite aptly to HTTP, and in the HTTP contex= t, you can certainly use OAuth if you like. Help me understand this part. Why can an HTTP request transport a token to a resource server to be able t= o access a specific resource, while SIP request cannot transport a similar = token to a SIP server to access a service? Of course both SIP and HTTP can carry arbitrary chunks of data, including a= ny sort of token we can imagine. My point is that the semantics of an INVIT= E are really different from the semantics of a POST - and that is why, ulti= mately, protocols like CCMP don't use SIP as a transport but instead use HT= TP. INVITEs are sent by a user agent when it is trying to set up a media s= ession between itself and some remote resource on the Internet. While RFC45= 79 has a way to open a conference as a side effect of sending an INVITE to = connect to the conference, the policies associated with the sorts of attrib= utes you specified are set totally outside the context of that dialog, and = the execution of those policies is completely disconnected from the authori= zation of the conference-opening INVITE. More on this below. I think the interesting question about standardizing an approach to author= ization of SIP requests is about INVITE. Of course, SIP supports faux-HTTP = semantics with mechanisms like PUBLISH and NOTIFY, and we could talk about = authorizing a number of other non-dialog-forming methods as well, but if we= 're going to kick off an effort to specify authorization policy for SIP, th= e primary thing we need to worry about is INVITE. You even will find some text about Role-Based Access Control in the XCON (R= FC6503) security consideration. Although you can use SIP and SDP to set up = a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS betw= een its own endpoints. It is unclear to me what carrying attribute informat= ion around in a SIP INVITE would accomplish with regards to authorizing CCM= P or BFCP transactions. SIP INVITE will carry attributes to authorize that specific SIP request; th= ere is nothing in proposal #3 that suggest that SIP will carry authorizatio= n for CCMP or any other protocol. That is where I think you and I have a disconnect. The SIP INVITE in the co= nference control (RFC4579) case would not carry attributes like the ones yo= u've identified in order to authorize that specific SIP request. The attrib= utes that you identified - the media types the conference allows and the nu= mber of participants permitted simultaneously in a conference - have nothin= g to do with the SIP INVITE that opens the conference bridge. Instead, they= are components of conference policy. Those policies apply to authorization= decisions regarding later participants that will be added to the conferenc= e, and thus to the authorization of later SIP transactions and dialogs, suc= h as when a new participant sends an INVITE to the conference bridge after = having been sent a REFER by the conference controller, say, and the focus d= ecides to reject that INVITE because the maximum number of participants has= been exceeded. We can imagine a way to publish such a conference policy to the conference = bridge with SIP, of course, but the question is, in what sense are those po= licies actually aligned with the question of whether or not we should autho= rize the SIP request that carries them? If they are not, then we aren't rea= lly talking about authorizing SIP requests, we're talking uploading long-te= rm application policies over SIP with faux-HTTP semantics, which is pretty = far from where we started and where I think we need to go. So again, the point of my last mail was that the problem of authorizing SIP= INVITEs is actually different from the problem of authorizing generic appl= ication transactions. SIP INVITEs still have more or less the semantics of = a call setup message: they are requesting that a session be initiated. Conf= erence control is not managed with SIP transactions, and the security of co= nference control protocols does not devolve to authorizing SIP transactions= . Well, RFC4579 defines a SIP Conference Control mechanism that allows you to= initiate and control a conference server using only SIP requests; so I am = not sure I understand this statement, unless we have different definitions = for the term =93conference control=94. Yeah, I was using the term loosely - once we bring RFC4579 into the mix, we= need to distinguish "conference control" from "conference policy," and the= n say that RFC4579 and the entire RFC4353 framework is about control, not a= bout managing conference policy over SIP. The two attributes you propose be= long to that conference policy realm rather than conference control, strict= ly speaking. In any case, my point was not to discuss conference servers specifically, b= ut to discuss the general idea of delegating both AuthN and AuthZ in a SIP = network. In that case, if you could furnish a use case with attributes that would be= carried in a SIP iNVITE that are actually salient to the authorization of = that particular SIP request, we'd be getting a lot closer to common ground. Jon Peterson Neustar, Inc. Regards, Rifaat I suspect we'll find that most of the other security attributes that "appli= cations" need to do their jobs similarly don't map onto the semantics of a = SIP INVITE - but, I'm still open to entertaining examples that might cast d= oubt on that suspicion. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, June 9, 2016 at 10:59 AM To: Jon Peterson = > Cc: Christer Holmberg >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Hi Jon, Sorry for the delayed reply. Let's take the video conference example, and discuss the possible ways for = the conference server to provide service. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Possible solutions: 1. Conference Server acts as an AuthN and AuthZ server. Requests to the ser= ver must provide an identity and credentials, and services will be provided= based on locally stored information associated with the identity provided = in the request. 2. Conference Server acts as an AuthZ server, but delegates the AuthN part.= Requests to the server must provide an identity token, and services will b= e provided based on locally stored information associated with the identity= provided in the token. 3. Conference Server delegates both AuthN and AuthZ parts. Requests to the = server must provide an access token, which might or might not include infor= mation about the user requesting the service, and services will be provided= based on information provided in the access token or as a result of an int= rospection step using the access token. Now, let's look at the 3rd option a bit more, and assume that the server pr= ovides the following types of conference services: 1. audio conference 2. audio/video conference 3. web conference or some combination of the above. Let's also assume that the server allows control over the number of partici= pants allowed in each one of these conference types or combinations. Here is one way that I envisioned we could use to address this use case: When an enterprise user in the 1st trust domain wants to register with the = SIP Proxy, it will have to authenticate to the IdP and as a result either t= he UA or the Proxy (depends on the UA's capabilities) will be provided with= an AuthN and AuthZ tokens. This process could involve an interim step to a= llow only the proxy to get access to the tokens, or the tokens could be sen= t to the UA which will then use them to communicate with the proxy. The AuthN token is the identity of the user, and the AuthZ token has all th= e services granted to the user by the IdP/AuthZ Service. When the enterprise user needs access to the conference service, the UA wil= l send an INVITE to the Proxy, and will include the AuthZ token if it is in= possession of the tokens; otherwise, the proxy will add the appropriate to= ken to the outgoing INVITE sent to the conference server. The scope of the AuthZ token might grant the user access to multiple servic= es; to avoid sending that AuthZ token to all servers providing services gra= nted to the user, the proxy could obtain a different token with limited sco= pe that is specific to the service being provided (conference services in t= his case); there is a standard Token Exchange mechanism for that. The AuthZ token will include information about the type of service allowed = (audio, audio/video, etc), and the limit on the number of participants. The= AuthZ token might or might not have any information about the user request= ing the service, which depends on the level of privacy needed. When the conference server receives this token in the SIP INVITE, all it ha= s to do is validate that the token was signed by an IdP that it has a trust= relationship with, and provide the service requested by the AuthZ token. T= he conference server does not need the AuthN token to be able to provide a = service. Regards, Rifaat On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon > wrote: Also, if we decided to separate the AuthN and AuthZ, then we might need to = carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to th= e UA; in this case there is a need for an interim step to get the token(s) = to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries. Jon Peterson Neustar, Inc. --_000_D385862C19C10Cjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

This time my response should be more complete. Sorry about that!


Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed.

This conference use case was an e= xample for a SIP-based conference server (RFC4579), just to describe the id= ea around the delegation of AuthNZ.

If the server is a CCMP-based con= ference, then you would obviously use that to control and manage the confer= ence server.

While RFC4579 (an implementation of the RFC4353 framework) provides a = means to do conference control from within SIP, the kinds of control primit= ives it specifies are totally decoupled from the sorts of policies that the= attributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy."= ; Neither RFC4579 nor its requirements (RFC4245) really say anything about = how conference policy is set or distributed. RFC4353 does, though, and what= it says is (in 4.6) is "the conference policy can be manipulated using web applications or voice applications [i.e. IVRs= - JFP]. It can also be manipulated with non-SIP-specific standard or propr= ietary protocols."

Authorizing SIP requests is misaligned with setting conference policy,= especially in consideration of the sorts of attributes you seem to have in= mind - even when we're considering controlling conferences compliant with = the RFC4353 framework.  That's because the conference in RFC4579 isn't "created" when a user agent send= s an INVITE request to the conference bridge - it is created when the confe= rence URI is created, which is necessarily beforehand (or at best, ad hoc t= hrough the conference factory). Conference policy is set and disseminated in that context, not in the context of the = SIP transaction that happens to open the bridge.

Moreover, my point was that the example of CCMP shows that you can do = conference control with OAuth over in the HTTP realm without needing to add= anything whatsoever to SIP.  If you need OAuth-style controls for con= ferencing, that would seem to be a quicker path to implementation.

 

The interesting thing about protocols like CCMP is that they are not, = you know, actually transported by SIP. CCMP is transported by HTTP. Why? Be= cause the semantics of conference control doesn't actually map onto SIP INV= ITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OA= uth if you like.
 

Help me understand this part.

Why can an HTTP request transport= a token to a resource server to be able to access a specific resource, whi= le SIP request cannot transport a similar token to a SIP server to access a= service?

Of course both SIP and HTTP can carry arbitrary chunks of data, includ= ing any sort of token we can imagine. My point is that the semantics of an = INVITE are really different from the semantics of a POST - and that is why,= ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent = by a user agent when it is trying to set up a media session between itself = and some remote resource on the Internet. While RFC4579 has a way to open a= conference as a side effect of sending an INVITE to connect to the conference, the policies associated with the s= orts of attributes you specified are set totally outside the context of tha= t dialog, and the execution of those policies is completely disconnected fr= om the authorization of the conference-opening INVITE. More on this below.

 I think the interesting question about standardizing an approach= to authorization of SIP requests is about INVITE. Of course, SIP supports = faux-HTTP semantics with mechanisms like PUBLISH and NOTIFY, and we could t= alk about authorizing a number of other non-dialog-forming methods as well, but if we're going to kick off an effo= rt to specify authorization policy for SIP, the primary thing we need to wo= rry about is INVITE.


You even will find some text about Role-Based Access Control in the XC= ON (RFC6503) security consideration. Although you can use SIP and SDP to se= t up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS= between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes = to authorize that specific SIP request; there is nothing in proposal #3 tha= t suggest that SIP will carry authorization for CCMP or any other protocol.=


That is where I think you and I have a disconnect. The SIP INVITE in t= he conference control (RFC4579) case would not carry attributes like the on= es you've identified in order to authorize that specific SIP request. The a= ttributes that you identified - the media types the conference allows and the number of participants permi= tted simultaneously in a conference - have nothing to do with the SIP INVIT= E that opens the conference bridge. Instead, they are components of confere= nce policy. Those policies apply to authorization decisions regarding later participants that will be added= to the conference, and thus to the authorization of later SIP transactions= and dialogs, such as when a new participant sends an INVITE to the confere= nce bridge after having been sent a REFER by the conference controller, say, and the focus decides to reject= that INVITE because the maximum number of participants has been exceeded.<= /div>

We can imagine a way to publish such a conference policy to the confer= ence bridge with SIP, of course, but the question is, in what sense are tho= se policies actually aligned with the question of whether or not we should = authorize the SIP request that carries them? If they are not, then we aren't really talking about authorizing SIP= requests, we're talking uploading long-term application policies over SIP = with faux-HTTP semantics, which is pretty far from where we started and whe= re I think we need to go.

 

So again, the point of my last mail was that the problem of authorizin= g SIP INVITEs is actually different from the problem of authorizing generic= application transactions. SIP INVITEs still have more or less the semantic= s of a call setup message: they are requesting that a session be initiated. Conference control is not mana= ged with SIP transactions, and the security of conference control protocols= does not devolve to authorizing SIP transactions.

Well, RFC4579 defines a SIP Confe= rence Control mechanism that allows you to initiate and control a conferenc= e server using only SIP requests; so I am not sure I understand this statem= ent, unless we have different definitions for the term =93conference control=94.

Yeah, I was using the term loosely - once we bring RFC4579 into the mi= x, we need to distinguish "conference control" from "confere= nce policy," and then say that RFC4579 and the entire RFC4353 framewor= k is about control, not about managing conference policy over SIP. The two attributes you propose belong to that conference policy = realm rather than conference control, strictly speaking.

In any case, my = point was not to discuss conference servers specifically, but to discuss th= e general idea of delegating both AuthN and AuthZ in a SIP network.<= /p>


In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to common gr= ound.

Jon Peterson
Neustar, Inc.

 

Regards,

 Rifaat



 
I suspect we'll find that most of the other security attributes that &= quot;applications" need to do their jobs similarly don't map onto the = semantics of a SIP INVITE - but, I'm still open to entertaining examples th= at might cast doubt on that suspicion. 

Jon Peterson
Neustar, Inc.


Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference exa= mple, and discuss the possible ways for the conference server to provide service.


         T= rust Domain 1              :   &nbs= p;Internet     :  Trust Domain 2
          =                      = ;      :               &n= bsp; :
          =             +--------+     = :                 :
          =             | IdP    |    = ; :                 :
        +--= -----------| AuthZ  |     :         &nbs= p;       :
        |  = ;           |        |   =   :                 :
        |  = ;           +--------+     : &nb= sp;               :
        |  = ;               |       &= nbsp;  :                 :
        |  = ;               |       &= nbsp;  :                 :
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
    |      = ;  |        | SIP    |     : &= nbsp;               :     | SI= P App|
    |   UA   |-= -------| Proxy  |-----:-----------------:-----| Video  |
    |      = ;  |        |        |   =   :                 :   &= nbsp; | Conference
    +--------+ &n= bsp;      +--------+     :     &= nbsp;           :     +--------+=
          =                      = ;      :               &n= bsp; :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the server must provide an identity a= nd credentials, and services will be provided based on locally stored = information associated with the identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part. Requests to the server must p= rovide an identity token, and services will be provided based on local= ly stored information associated with the identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the server must provide an access = token, which might or might not include information about the user req= uesting the service, and services will be provided based on information provided in the access token or as a result of a= n introspection step using the access token.


Now, let's look at the 3rd option a= bit more, and assume that the server provides the following types of = conference services:
1. audio conference
2. audio/video conference
3. web conference

or some combination of th= e above.

Let's also assume that the server a= llows control over the number of participants allowed in each one of t= hese conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the SIP Proxy, it will have to authenti= cate to the IdP and as a result either the UA or the Proxy (depends on= the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step = ;to allow only the proxy to get access to the tokens, or the tokens could b= e sent to the UA which will then use them to communicate with the prox= y.

The AuthN token is the identity of the user, and the AuthZ token has all&nb= sp;the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA&nbs= p;will send an INVITE to the Proxy, and will include the AuthZ token if it = is in possession of the tokens; otherwise, the proxy will add the appr= opriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple s= ervices; to avoid sending that AuthZ token to all servers providing se= rvices granted to the user, the proxy could obtain a different token with&n= bsp;limited scope that is specific to the service being provided (conference services in this case); there is a standar= d Token Exchange mechanism for that.

The AuthZ token will include information about the type of service allowed&= nbsp;(audio, audio/video, etc), and the limit on the number of participants= . The AuthZ token might or might not have any information about the us= er requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it&nb= sp;has to do is validate that the token was signed by an IdP that it has a&= nbsp;trust relationship with, and provide the service requested by the Auth= Z token. The conference server does not need the AuthN token to be able to provide a service.

Regards,
 Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or less= what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond requir= ements. Today, I think that much of the useful work that could be done on t= he authorization question is in identifying which SIP authorization policie= s are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.  The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lot of= light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who op= ens the conference bridge needs to be charged, that's identity information = - which in its usual form will convey the individual user and their domain,= like user@domain. If you need more complex semantics than that, it's probably because you're doing something = more complicated than just calling in to the conference. But it's less clea= r to me why you'd use SIP for such cases. Drilling down deeper into these u= se cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which larg= ely involve billing (including when dealing with various protocol gateways)= and resource management (both preemption and priority), ultimately didn't = seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.&n= bsp;

Jon Peterson
Neustar, Inc.


 --_000_D385862C19C10Cjonpetersonneustarbiz_-- From nobody Tue Jun 14 10:29:35 2016 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 1FA1912D878 for ; Tue, 14 Jun 2016 10:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 K3T0VtbxLMP1 for ; Tue, 14 Jun 2016 10:29:33 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 0A9F912D09F for ; Tue, 14 Jun 2016 10:29:33 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EHNINs017229; Tue, 14 Jun 2016 13:29:27 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23gerqse5h-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 13:29:27 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 13:29:25 -0400 From: "Peterson, Jon" To: "Olle E. Johansson" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtJJyRZYItSEGGroXfIB854p/kFpuAgACq/ACAAPxBgIAB9SyA///VhwCAAVK9gIAAMDEA Date: Tue, 14 Jun 2016 17:29:24 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> In-Reply-To: <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2F05DD0F84457849BC8590E0180A8FC6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140189 Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:29:34 -0000 Just to add a bit to what Brian said... >>=20 >I think we need to start with =B3what if we remove SIPS=B2 and go back and >see what=B9s missing and how we can fix that. A lot of people point to SIP= S >as >the solution - but no one is implementing or using it. Ostensibly what would be missing is a mechanism for user agents to indicate that any intermediaries handling their request should only forward it with hop-by-hop confidentiality and integrity protections. And for SIP resources to indicate their preference to be reached in this fashion. >=20 >What is the problem it solves? Pervasive eavesdropping? > Is there another way? Maybe. >What=B9s the status for S/MIME. > >I don=B9t think we=B9ll find that the answer is SIPS: as a URI scheme, but= the >SIP over TLS transport is still very much needed, discovered by NAPTR/SRV >and supported by DANE or some other PKI structure. If your intention is that we should replace SIPS with something that provides a stronger assurance of hop-by-hop signaling confidentiality, then great, let's specify that stronger mechanism first and then we'll deprecate SIPS in favor of it. If the process is instead, let's deprecate SIPS and then hope we can invent something else to address pervasive eavesdropping later, I would probably say that's unacceptable, provided we think there are any deployment environments in which SIPS could work as advertised. And yes, I'm aware there are deployment environments in which it is just a nuisance, but coincidentally, those are also deployment environments that are not overly concerned with pervasive eavesdropping. Again, discovering via NAPTR/SRV that the resource wants to be reached over TLS was one of the primary functions for which SIPS was devised. I'm not sure how different anything we come up along those lines would realistically be from what's already in RFC3263. Jon Peterson Neustar, Inc. From nobody Tue Jun 14 10:42:09 2016 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 44E2512DBAD for ; Tue, 14 Jun 2016 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jvtuLzRfTPx5 for ; Tue, 14 Jun 2016 10:42:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A655912DB9D for ; Tue, 14 Jun 2016 10:42:05 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-dd-576041eb03a7 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.28.12926.BE140675; Tue, 14 Jun 2016 19:42:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 19:42:03 +0200 From: Christer Holmberg To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0SdPYK36JzskyA13ZRS/LYCZ+vKcgTgAG3n4CAAu+rgIADNAiAgALiX4CABPpGgIAHgLuAgAOa3oCAF4ALgIAGZGUAgAEs94CAADe5AIAAAS6AgAAtY4A= Date: Tue, 14 Jun 2016 17:42:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3805245A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7n+5rx4Rwg5bFphZnGiwtdr5oZbP4 +mMTmwOzx85Zd9k9liz5yeSxo+E5cwBzFJdNSmpOZllqkb5dAlfG0UUFBUu4K7Y8a2NrYPzO 0cXIySEhYCLxrHMZO4QtJnHh3nq2LkYuDiGBI4wSqzc2MEM4Sxgl/jxbzNLFyMHBJmAh0f1P G6RBRCBG4sfum2wgNrOApsSjnXuZQGxhoJLDN/8zQ9RYSnyfdI4dZI6IQBejxMeFRxhBEiwC qhKv3uwHK+IV8JW4t/ogO8Syn2wSnY8ngCU4Bcwl1u99yApiMwKd9/3UGiaIbeISt57MZ4I4 W0BiyZ7zzBC2qMTLx/9YIWwlibWHt7NA1OtJ3Jg6BepSbYllC19DLRaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtTBLb9VdzBefuN4iFGA g1GJh/eBTny4EGtiWXFl7iFGCQ5mJRHeY/YJ4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8q hgsJpCeWpGanphakFsFkmTg4pRoYHWLfsV/L++/GfrLEuVJb+2Dwc45l+cf+eG9YVPXu3uI3 vlMiktdMdi085de4f1fT8YaK3KdOmz9+dWGc+flU+bNraw9sDTwTsFu/wNZ25U+milBejbaj i1/47ZV/Zyd6V++uybPkglxLrtfOfwwcs69ysUzMXbn24OxZDzX1CjemR+31TNZYrcRSnJFo qMVcVJwIAFRlUomlAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:42:07 -0000 Hi, . >> Why can an HTTP request transport a token to a resource server to be abl= e to access a specific resource, while SIP request cannot transport a simil= ar token to a SIP server to access a service? > > Of course both SIP and HTTP can carry arbitrary chunks of data, including= any sort of token we can imagine. My point is that the semantics of an INV= ITE are really different from the semantics of a POST - > and that is why, = ultimately, protocols like CCMP don't use SIP as a transport but instead us= e HTTP. =A0INVITEs are sent by a user agent when it is trying to set up a m= edia session between itself and some=20 > remote resource on the Internet. While RFC4579 has a way to set up a conf= erence as a side effect of sending an INVITE to connect to the conference, = must of the subsequent control work happens=20 > totally outside the context of that dialog, and the authorization of thos= e operations is completely disconnected from the authorization of the confe= rence-opening INVITE. > > And of course, SIP can support faux-HTTP semantics with mechanisms like P= UBLISH and NOTIFY. But I think the interesting question about standardizing= an approach to authorization of SIP requests is=20 > about INVITE. Just to point out that in the IMS use-case the token needs to be carried in= the REGISTER request, and it has nothing to do with a conference server. Regards, Christer From nobody Tue Jun 14 10:57:22 2016 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 CE3FF12D60B for ; Tue, 14 Jun 2016 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 y9eWqaRXJ_lZ for ; Tue, 14 Jun 2016 10:57:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0094.outbound.protection.outlook.com [65.55.169.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E2312D884 for ; Tue, 14 Jun 2016 10:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z000LTdAVKgUuHI0E8+i8nLENJ36sSmyX7eSoWG7ldw=; b=tjE3sWlKo33LmSjmP63d+LA3kyRvjSgnLOc2w5rXe9iZZkyJUp/0eWAhQnPE/MqUCWE3gDtdt9sbu/zFF0c75sC2CaQvBWGl4yTT7zA6XguBeRpi1KXKj+gTHZ4WpUbCNUk+lh1C9kXA8xQ5losw2EUcnuvsAvPdXr3l3j+xLX8= Received: from DM2PR0301MB1213.namprd03.prod.outlook.com (10.160.219.154) by DM2PR0301MB1213.namprd03.prod.outlook.com (10.160.219.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 17:57:16 +0000 Received: from DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) by DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 17:57:16 +0000 From: "Neelakantan, Neel" To: "Olle E. Johansson" , Paul Kyzivat Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtDzmpLqILj0OZZ0rOVOH4GJ/j042AgACq/ACAAPxBgIACYbq6gAFF2ICAAA0D3oAAARUAgAAUwiA= Date: Tue, 14 Jun 2016 17:57:15 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF261402CF@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8BADF15A0C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <582804FD-4C1E-47AE-8BAB-41B71D8285A2@edvina.net> In-Reply-To: <582804FD-4C1E-47AE-8BAB-41B71D8285A2@edvina.net> 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=nneelakantan@sonusnet.com; x-originating-ip: [12.171.83.97] x-ms-office365-filtering-correlation-id: 3e808a35-3519-49bf-ee80-08d3947d5240 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB1213; 6:VVM7zfcMbrK1ANcR63l1qxCt5S7xMAqunmO5J/EyLm82Bfiu69G7wdvN8O2Uu+vWmAwJxbf9BcAe52SHi84CXhREeAjTbcwmWlRz6p8LXDe5PAeuevqUZ9v7rChH2VXIidZv9+mkc+FI8GboB6vDi2z65XG79CGlM76dlC1L5aoqXe/RyBja+d7QGfGkchzVvPCUZT+hxijcYxK1oEYq/7UPtqP/N5Ro5ImFPMbdQdCtP+Wr+amrAbVuTjqxn99v/m4WyZTnuXm5Of7N3uVwdQ==; 5:ZkY35gCihCotDtcCn7IaosNI8aQ4CAdfYlv8QPKqFCyDwm1f5ymmpAkGVRC/j3zSE9HS4nUAxxE1rXvFym4dqld/wrvncbgpNae9TTIAqHNKeubiZATOv1Ihe6ZvnL8lKNhEe82R0yKjezIY1gIy7w==; 24:4ltqRgerAIQNxw/zlqu2kwqLriAPJ6577ZPXRZWsw7UCdFiLalGZcE1p14LaCTWZJGecJAKp0dNVuPjpGEEc1P3Q2kcSRzpgHVYuMZCr54k=; 7:4/NgbFeCng7aAHHWKw2jsC9MNN9A6FYXBiEdXkZaX9lPdXrdapootGhNZBPeQg+gHTWcsLwSgA8hlpCsbEE6cwdwhiiievlgylfMZvfLNey8gkUNIgUGvMrRgb1VrRGSY0dAGilaWFtjgo/QnnyWEvBdOkfxwHZYM2vHQyQyvkYozSFkfAyLuMDyAGZRwTYveL5DnhjR15xd0CNDh3BvfA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1213; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(187470562142495); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR0301MB1213; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1213; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(24454002)(377454003)(13464003)(3660700001)(97736004)(5001770100001)(15975445007)(76576001)(3280700002)(66066001)(122556002)(5004730100002)(6116002)(586003)(68736007)(81166006)(81156014)(3846002)(102836003)(189998001)(8676002)(2900100001)(2950100001)(77096005)(5008740100001)(2906002)(4326007)(92566002)(8936002)(9686002)(105586002)(74316001)(106356001)(2171001)(19580395003)(19580405001)(87936001)(5002640100001)(50986999)(10400500002)(76176999)(54356999)(11100500001)(99286002)(101416001)(86362001)(106116001)(5003600100002)(33656002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0301MB1213; H:DM2PR0301MB1213.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 17:57:15.9460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1213 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:57:21 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZSBbbWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9sbGUgRS4NCj4gSm9oYW5z c29uDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTQsIDIwMTYgMTE6NDIgQU0NCj4gVG86IFBhdWwg S3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPiBDYzogc2lwY29yZUBpZXRmLm9yZzsg T2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+DQo+IFN1YmplY3Q6IFJlOiBbc2lwY29y ZV0gU0lQUyBtdXN0IGRpZSwgZGllLCBkaWUNCj4gDQo+IA0KPiA+IE9uIDE0IEp1biAyMDE2LCBh dCAxODozNywgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPiA+ DQo+ID4gT24gNi8xNC8xNiAxMjowNCBQTSwgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSB3cm90 ZToNCj4gPj4gUGxlYXNlIGNvbmZpcm0gd2hldGhlciBSRkMgNTYzMCAoaW5jbHVkaW5nIGFubmV4 IEEpIGlzIGNsZWFyIGluIHRoaXMNCj4gcmVzcGVjdCBvciBub3QsIGFuZCBiZSBzcGVjaWZpYyBh Ym91dCB3aGVyZSBpdCBpcyBub3QuIFlvdSBzaG91bGQgbm90IGJlDQo+IGltcGxlbWVudGluZyBS RkMgMzI2MSB3aXRob3V0IGFsc28gaW1wbGVtZW50aW5nIFJGQyA1NjMwLCBhcyBvbmUgdXBkYXRl cw0KPiB0aGUgb3RoZXIuDQo+ID4+DQo+ID4+IEFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgdGhh dCBkb2N1bWVudCBpcyBjbGVhciBhYm91dCB3aGF0IGlzIG5lZWRlZCB0bw0KPiBzdXBwb3J0IFNJ UFMsIGFuZCB3aGF0IGlzIG5lZWRlZCB0byBzdXBwb3J0IHRyYW5zcG9ydD1UTFMuDQo+ID4NCj4g PiBJIGp1c3QgbG9va2VkIGF0IGl0Lg0KPiA+DQo+ID4gQW4gYXJlYSB0aGF0IEkgd291bGQgYmUg Y29uY2VybmVkIHdpdGggaXMgaW4gdG9wb2xvZ2llcyBpbmNsdWRpbmcgU0JDcy4gVGhleQ0KPiBh cmVuJ3QgZXhwbGljaXRseSBhZGRyZXNzZWQsIGJ1dCB0aGF0IGlzbid0IHN1cnByaXNpbmcgc2lu Y2UgYWxtb3N0IG5vbmUgb2YgdGhlDQo+IHNpcCBzcGVjcyBkby4gVGhleSBkbyBzZWVtIHRvIGJl IGNvdmVyZWQgYnkgc2VjdGlvbiA1LjEuMS4zIG9uIERlcml2ZWQNCj4gRGlhbG9ncy4gQnV0IEkg ZG9uJ3Qga25vdyBpZiB0aG9zZSBpbXBsZW1lbnRpbmcgb3IgZGVwbG95aW5nIFNCQ3Mgd291bGQN Cj4gYWdyZWUgb24gdGhhdC4gSWYgc29tZWJvZHkgZG9lc24ndCB0aGluayB0aGlzIGFwcGxpZXMg dG8gU0JDcywgdGhleSB0aGV5DQo+IG1pZ2h0IGJlIHRyZWF0ZWQgYXMgYSAiZ2V0IG91dCBvZiBq YWlsIGZyZWUiIGNhcmQgdG8gc3RvcCB1c2luZyBUTFMuDQo+ID4NCj4gPiBBbm90aGVyIHBvc3Np YmxlIGNvbmNlcm4gaXMgY2FsbHMgdGhhdCB0cmFuc2l0aW9uIGZyb20gU0lQUyB0byBzb21lIG5v bi1TSVANCj4gcHJvdG9jb2wuIEUuZy4sIGlzIGl0IHBlcm1pc3NpYmxlIHRvIHRlcm1pbmF0ZSBh IFNJUFMgY2FsbCBvbiBhIFBTVE4gZ2F0ZXdheT8gSQ0KPiBjYW4ndCBmaW5kIGFueXRoaW5nIGlu IDU2MzAgdGhhdCBjb25zaWRlcnMgdGhlc2UuIE9uIG9uZSBoYWQsIEkgbWlnaHQgcmVhbGx5DQo+ IHdhbnQgdGhlIFNJUFMgbGV2ZWwgc2VjdXJpdHkgYWxsIHRoZSB3YXkgdG8gdGhlIGdhdGV3YXku IE9uIHRoZSBvdGhlciBoYW5kLCBpZg0KPiB0aGF0IHdvcmtzIEkgbWlnaHQgYmUgZGVsdWRlZCBp biB0aGlua2luZyBJIGhhdmUgbW9yZSBzZWN1cml0eSB0aGFuIGlzDQo+IGRlbGl2ZXJlZCBieSB0 aGUgUFNUTi4NCj4gPg0KPiA+PiBUaGUgdXNlIG9mIFNJUFMgc2hvdWxkIG5vdCBnZW5lcmF0ZSBh IGJ1ZyByZXBvcnQsIGJlY2F1c2UgaXQgaXMgbm90IGFuDQo+IGVycm9yLiBZb3UgbWF5IG5lZWQg dG8gcmVqZWN0IHRoZSBjYWxsIGJlY2F1c2UgeW91IGNhbm5vdCBzdXBwb3J0IHRoZQ0KPiBjYXBh YmlsaXR5LCBidXQgdGhhdCBpcyBubyBkaWZmZXJlbnQgdG8gbWFueSBvdGhlciByZWFzb25zIGZv ciByZWplY3Rpb24uDQo+ID4+DQo+ID4+IFdlIGRvIG5vdCBub3JtYWxseSBkZXByZWNhdGUgUkZD cyBqdXN0IGJlY2F1c2UgcGVvcGxlIGhhdmUgZmFpbGVkIHRvDQo+IHJlYWQgdGhlIGRvY3VtZW50 LCBvZiBmYWlsZWQgdG8gcHJvdmlkZSB0aGVpciBpbXBsZW1lbnRhdGlvbnMgaW4NCj4gY29uZm9y bWFuY2Ugd2l0aCB0aGUgZG9jdW1lbnQsIG9yIGV2ZW4ganVzdCBmYWlsZWQgdG8gaW1wbGVtZW50 IGENCj4gcGFydGljdWxhciBjYXBhYmlsaXR5Lg0KPiA+Pg0KPiA+PiBJZiB5b3UgZG9uJ3Qgd2Fu dCB0byBzdXBwb3J0IFNJUFMsIHRoZW4gZmluZSwgdGhhdCBpcyBhbiBhY2NlcHRhYmxlIHBvc2l0 aW9uLA0KPiBidXQgeW91IG5lZWQgbW9yZSBldmlkZW5jZSB0byB0ZWxsIHRoZSB3b3JsZCBub3Qg dG8gdXNlIGl0Lg0KPiA+DQo+ID4gSSBoYXZlIG1peGVkIGZlZWxpbmdzIGFib3V0IHRoaXMuIElT VE0gdGhlIG1haW4gcHJvYmxlbSBpcyB0aGF0IHlvdSBjYW4ndA0KPiBhY2N1cmF0ZWx5IGNsYWlt IHRoYXQgeW91IHN1cHBvcnQgMzI2MSB1bmxlc3MgeW91IGJ1aWxkIGluIGNvZGUgcGF0aHMgdG8N Cj4gc3VwcG9ydCBTSVBTLiBCdXQgeW91IGFyZSBmcmVlIHRvIHJlc3RyaWN0IHlvdXIgY29kZSB0 byBkZXBsb3ltZW50cyB0aGF0DQo+IGRvbid0ICp1c2UqIFNJUFMuIFlvdSBtaWdodCBub3QgZXZl ciB0ZXN0IHRoZSBTSVBTIHBhdGhzIChvciBldmVuIGhhdmUgYSB3YXkNCj4gdG8gdGVzdCB0aGVt KS4gV2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhpcz8NCj4gVGhhdOKAmXMgYSBnb29kIHBvaW50LiBJ ZiB3ZSByZW1vdmUgU0lQUzogaXTigJlzIG5vIGxvbmdlciBwYXJ0IG9mIGFueQ0KPiByZXF1aXJl bWVudHMuDQo+ID4NCj4gPiBBbmQgaWYgeW91IGFyZSBidWlsZGluZyBVQUMgdGhhdCBjb25uZWN0 cyB2aWEgcmVnaXN0cmF0aW9uIHlvdSB3aWxsIG5ldmVyIGJlDQo+IGFibGUgdG8gdXNlIFNJUFMg dW5sZXNzIHlvdSBhbHNvIGltcGxlbWVudCBhbmQgdXNlIE91dGJvdW5kLiBCdXQNCj4gT3V0Ym91 bmQgc3VwcG9ydCBpcyBvcHRpb25hbC4NCj4gV2VsbCwgdGhlIG9wdGlvbiBpcyBjbGllbnQgY2Vy dHMpIGFuZCBtdXR1YWwgVExTIGF1dGgsIGFsc28gZGlzY3Vzc2VkIChhbmQNCj4gZGlzbWlzc2Vk 4oCmKSBpbiA1NjMwICA7LSkNCj4gPg0KPiA+IFBlcmhhcHMgdGhlIGFuc3dlciBpcyB0byByZW1v dmUgdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgYXNwZWN0IG9mDQo+IFNJUFMuDQo+IFllcy4N Cj4gDQo+IC9PDQo+ID4NCg0KIFtbTmVlbF1dIFRoYXQgc3RpbGwgZG9lcyBub3Qgc29sdmUgdGhl IHByb2JsZW1zIG9mIE5BVC9GaXJld2FsbHMgcmlnaHQ/ICBBZ3JlZWQgdGhleSBhcmUgdGFuZ2Vu dGlhbCwgYnV0IHdlIG5lZWQgdG8gbG9vayBhdCBvdmVyYWxsIHJlYWxpdHkgb2YgZGVwbG95bWVu dC4NCg0KPiA+IAlUaGFua3MsDQo+ID4gCVBhdWwNCj4gPg0KPiA+PiBLZWl0aA0KPiA+Pg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBIdXR0b24sIEFuZHJldyBb bWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tXQ0KPiA+PiBTZW50OiAxNCBKdW5lIDIwMTYg MTY6NTENCj4gPj4gVG86IFJpY2hhcmQgU2hvY2tleTsgUGV0ZXJzb24sIEpvbjsgRHJhZ2UsIEtl aXRoIChOb2tpYSAtIEdCKTsgRE9MTFksDQo+ID4+IE1BUlRJTiBDOyBQYXVsIEt5eml2YXQNCj4g Pj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBTSVBT IG11c3QgZGllLCBkaWUsIGRpZQ0KPiA+Pg0KPiA+PiBPTjogMTMgSnVuZSAyMDE2IFJpY2hhcmQg U2hvY2tleQ0KPiA+Pg0KPiA+Pj4gVGhvdWdoIGl0IGlzIHNwZWNpZmllZCBhcyBNVVNUIHN1cHBv cnQgaW4gdGhlIFNJUCBGb3J1bSBTSVBDb25uZWN0DQo+ID4+PiBwcm9maWxlcyBmb3IgUEJYIHRv IFNQIG9uIHRoZSB3aXJlIGludGVncmF0aW9uIHRvIG15IGtub3dsZWRnZSBpdA0KPiA+Pj4gaGFz IG5ldmVyIGJlZW4gaW1wbGVtZW50ZWQgYnkgYW55IHZlbmRvciBvciBTU1AuICBJbiBzaG9ydCBT SVBTIGlzIGENCj4gPj4+IHRvdGFsIFBhaW4gaW4gdGhlIEFzcw0KPiA+Pg0KPiA+PiBTSVBTIGlz IGFjdHVhbGx5IG5vdCByZXF1aXJlZCBieSBTSVBjb25uZWN0IGFsdGhvdWdoIFRMUyBpcyBhIE1V U1QNCj4gcmVxdWlyZW1lbnQgaGVuY2UgdGhlIGNvbmZ1c2lvbi4NCj4gPj4NCj4gPj4gV2hlbmV2 ZXIgSSBoYXZlIHNlZW4gU0lQUyB1c2VkIGl0IGhhcyByZXN1bHRlZCBpbiBzb21lIGtpbmQgb2Yg YnVnDQo+IHJlcG9ydCBiZWluZyBnZW5lcmF0ZWQgYW5kIEkgaGF2ZSB0byBzYXkgSSBoYXZlIG5v dCBoZWFyZCBvZiBpdCBiZWluZyB1c2VkIGZvcg0KPiBzb21lIHRpbWUuICBJdCBuZWVkcyB0byBk ZXByZWNhdGVkIGFuZCB0aGUgdXNlIG9mIFRMUyBjbGFyaWZpZWQuDQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNpcGNvcmUg bWFpbGluZyBsaXN0DQo+ID4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNpcGNvcmUgbWFpbGlu ZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From nobody Tue Jun 14 11:10:44 2016 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 957BF12D883 for ; Tue, 14 Jun 2016 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FZnZ-R1zjOD7 for ; Tue, 14 Jun 2016 11:10:41 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 775FE12D7F6 for ; Tue, 14 Jun 2016 11:10:41 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5EI6qix001196; Tue, 14 Jun 2016 14:10:37 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23gd9uj34q-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 14:10:37 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 14:10:36 -0400 From: "Peterson, Jon" To: Christer Holmberg , Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8JcAIAAAS8AgACB9ID//5KcAA== Date: Tue, 14 Jun 2016 18:10:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3805245A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3805245A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BFDC9A62A25E04AB735DB9172D5B9B6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140196 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 18:10:42 -0000 But to the point - in that (very very different) use case, the REGISTER request is accepted or rejected based on the contents of the token it carries, right? Jon Peterson Neustar, Inc. On 6/14/16, 10:42 AM, "Christer Holmberg" wrote: >Hi, > >. > >>> Why can an HTTP request transport a token to a resource server to be >>>able to access a specific resource, while SIP request cannot transport >>>a similar token to a SIP server to access a service? >> >> Of course both SIP and HTTP can carry arbitrary chunks of data, >>including any sort of token we can imagine. My point is that the >>semantics of an INVITE are really different from the semantics of a POST >>- > and that is why, ultimately, protocols like CCMP don't use SIP as a >>transport but instead use HTTP. INVITEs are sent by a user agent when >>it is trying to set up a media session between itself and some >> remote resource on the Internet. While RFC4579 has a way to set up a >>conference as a side effect of sending an INVITE to connect to the >>conference, must of the subsequent control work happens >> totally outside the context of that dialog, and the authorization of >>those operations is completely disconnected from the authorization of >>the conference-opening INVITE. >> >> And of course, SIP can support faux-HTTP semantics with mechanisms like >>PUBLISH and NOTIFY. But I think the interesting question about >>standardizing an approach to authorization of SIP requests is >> about INVITE. > >Just to point out that in the IMS use-case the token needs to be carried >in the REGISTER request, and it has nothing to do with a conference >server. > >Regards, > >Christer > > From nobody Tue Jun 14 11:31:07 2016 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 DC27212D8BE for ; Tue, 14 Jun 2016 11:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FvAltlFo1uIq for ; Tue, 14 Jun 2016 11:31:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E2612D8B3 for ; Tue, 14 Jun 2016 11:31:04 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-af-57604d66036c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 57.DC.12926.66D40675; Tue, 14 Jun 2016 20:31:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 20:31:01 +0200 From: Christer Holmberg To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0SdPYK36JzskyA13ZRS/LYCZ+vKcgTgAG3n4CAAu+rgIADNAiAgALiX4CABPpGgIAHgLuAgAOa3oCAF4ALgIAGZGUAgAEs94CAADe5AIAAAS6AgAAtY4D//+ctgIAAJWOg Date: Tue, 14 Jun 2016 18:31:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380525A9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3805245A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7lG6ab0K4QfcSOYszDZYWO1+0sll8 /bGJzYHZY+esu+weS5b8ZPLY0fCcOYA5issmJTUnsyy1SN8ugStjybJ1bAWT+SquN81ibmBc y93FyMkhIWAisapxMxOELSZx4d56ti5GLg4hgSOMErcv/WGBcJYwSkz7ugfI4eBgE7CQ6P6n DdIgIhAj8WP3TTYQm1lAU+LRzr1gg4SBSg7f/M8MUWMp8X3SOXaQOSIC0xgl3pzsYwaZwyKg KjHhcDlIDa+Ar0Tjt79MELtesUs87F3JCpLgFDCXuPnzFNggRqDrvp9awwSxTFzi1pP5UFcL SCzZc54ZwhaVePn4HyuErSSx6PZnqHodiQW7P0Edqi2xbOFrZojFghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMCYOrjlt+oOxstvHA8xCnAw KvHwKrglhAuxJpYVV+YeYpTgYFYS4TX0BArxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4k kJ5YkpqdmlqQWgSTZeLglGpglL3AvTZzzYJXvRmS3z6cd7BL2qbO4G6aH/rjtdGiAD6udNGP ycVzy5kXndzeztqwSkK6/5Cw6/Y9AYZ7IhUncoiXX9kldDk6sSzyh+ekV/1F6/zagzfwn4x4 NLH/9Crhuyp9avenbuqJiHuZMPNiVtGT+kP1Rjacev/uOCyPPXLtwW9V0aRSJZbijERDLeai 4kQAXGC2k6UCAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 18:31:06 -0000 Hi, >But to the point - in that (very very different) use case, the REGISTER re= quest is accepted or rejected >based on the contents of the token it carrie= s, right? Yes. Regards, Christer On 6/14/16, 10:42 AM, "Christer Holmberg" wrote: >Hi, > >. > >>> Why can an HTTP request transport a token to a resource server to be=20 >>>able to access a specific resource, while SIP request cannot=20 >>>transport a similar token to a SIP server to access a service? >> >> Of course both SIP and HTTP can carry arbitrary chunks of data,=20 >>including any sort of token we can imagine. My point is that the=20 >>semantics of an INVITE are really different from the semantics of a=20 >>POST >>- > and that is why, ultimately, protocols like CCMP don't use SIP as=20 >>a transport but instead use HTTP. INVITEs are sent by a user agent=20 >>when it is trying to set up a media session between itself and some =20 >>remote resource on the Internet. While RFC4579 has a way to set up a=20 >>conference as a side effect of sending an INVITE to connect to the=20 >>conference, must of the subsequent control work happens totally=20 >>outside the context of that dialog, and the authorization of those=20 >>operations is completely disconnected from the authorization of the=20 >>conference-opening INVITE. >> >> And of course, SIP can support faux-HTTP semantics with mechanisms=20 >>like PUBLISH and NOTIFY. But I think the interesting question about=20 >>standardizing an approach to authorization of SIP requests is about=20 >>INVITE. > >Just to point out that in the IMS use-case the token needs to be=20 >carried in the REGISTER request, and it has nothing to do with a=20 >conference server. > >Regards, > >Christer > > From nobody Tue Jun 14 13:04:49 2016 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 5FD2E12D959 for ; Tue, 14 Jun 2016 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 vnf22cw4I_sA for ; Tue, 14 Jun 2016 13:04:46 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 4BB6312D5AE for ; Tue, 14 Jun 2016 13:04:46 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with SMTP id CuZTbGGy8AlI7CuZpb7k88; Tue, 14 Jun 2016 20:04:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465934685; bh=IarVXVaL/dIi7PCj/Cw/eOLY6U7fLP2kC+0ZKKWbyTY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pGzWZuwfAqdpI/FzQq8rs2SV4n6hNSxYxcBBfdz5lHc8r8NALRPFiVTCUAPiM1XIG wPs3twOPfRctXkOf/0u9XGEn9jMD/bX9/mAL+yk/lYphWt6XTBaH109ARwVNbGpGED RSFNECAsH4l8zdnzXMR0NhpEcLIkpOkY7e9wnpUW/jx6ll2ZDxAe0WgcHLKd1VH73F tb/sdeljQoPzpqfRXWoE/KFn8KEuggX2854NMcIlU2+l90iiibm9Amk9CJGGCDvaUc UxnThg+xImlPbOmwq+DTDsmGICdZ5F2vvf1K2csiMPEhJbX3xOkfl6LpUT9HWKyJu+ RgMZs8cnfrZPw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id 6k4k1t00B3KdFy101k4kli; Tue, 14 Jun 2016 20:04:45 +0000 To: "Peterson, Jon" , "Olle E. Johansson" References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> From: Paul Kyzivat Message-ID: <28e047ef-890c-1c9b-e280-eee39107361b@alum.mit.edu> Date: Tue, 14 Jun 2016 16:04:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 20:04:48 -0000 On 6/14/16 1:29 PM, Peterson, Jon wrote: > > Just to add a bit to what Brian said... > >>> >> I think we need to start with ³what if we remove SIPS² and go back and >> see what¹s missing and how we can fix that. A lot of people point to SIPS >> as >> the solution - but no one is implementing or using it. > > Ostensibly what would be missing is a mechanism for user agents to > indicate that any intermediaries handling their request should only > forward it with hop-by-hop confidentiality and integrity protections. And > for SIP resources to indicate their preference to be reached in this > fashion. What is the point of the hop-by-hop protections in this context? Do we really need it? Won't STIR and SIPBRANDY provide what is needed without it? >> What is the problem it solves? > > Pervasive eavesdropping? Since hop-by-hop presumes that all the intermediaries are trusted, and this rarely seems like a good assumption for preventing pervasive eavesdropping, maybe it isn't worth the trouble. Thanks, Paul >> Is there another way? > > Maybe. > >> What¹s the status for S/MIME. >> >> I don¹t think we¹ll find that the answer is SIPS: as a URI scheme, but the >> SIP over TLS transport is still very much needed, discovered by NAPTR/SRV >> and supported by DANE or some other PKI structure. > > If your intention is that we should replace SIPS with something that > provides a stronger assurance of hop-by-hop signaling confidentiality, > then great, let's specify that stronger mechanism first and then we'll > deprecate SIPS in favor of it. If the process is instead, let's deprecate > SIPS and then hope we can invent something else to address pervasive > eavesdropping later, I would probably say that's unacceptable, provided we > think there are any deployment environments in which SIPS could work as > advertised. And yes, I'm aware there are deployment environments in which > it is just a nuisance, but coincidentally, those are also deployment > environments that are not overly concerned with pervasive eavesdropping. > > Again, discovering via NAPTR/SRV that the resource wants to be reached > over TLS was one of the primary functions for which SIPS was devised. I'm > not sure how different anything we come up along those lines would > realistically be from what's already in RFC3263. > > Jon Peterson > Neustar, Inc. > > From nobody Tue Jun 14 13:45:38 2016 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 3EF4712D9B0 for ; Tue, 14 Jun 2016 13:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 t2uWOlhFKzdC for ; Tue, 14 Jun 2016 13:45:36 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 1994D12D9A0 for ; Tue, 14 Jun 2016 13:45:35 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u5EKgvEa005660; Tue, 14 Jun 2016 16:45:23 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23geyau73f-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jun 2016 16:45:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 14 Jun 2016 16:45:23 -0400 From: "Peterson, Jon" To: Paul Kyzivat , "Olle E. Johansson" Thread-Topic: [sipcore] SIPS must die, die, die Thread-Index: AQHRw2RtJJyRZYItSEGGroXfIB854p/kFpuAgACq/ACAAPxBgIAB9SyA///VhwCAAVK9gIAAMDEAgACgx4D//5YBAA== Date: Tue, 14 Jun 2016 20:45:22 +0000 Message-ID: References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> <28e047ef-890c-1c9b-e280-eee39107361b@alum.mit.edu> In-Reply-To: <28e047ef-890c-1c9b-e280-eee39107361b@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: text/plain; charset="euc-kr" Content-ID: <4F36CB295D0FCB46907B2364F8EDDB95@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140226 Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 20:45:37 -0000 DQpUaGUgdGhyZWF0IG9mIHBlcnZhc2l2ZWx5IG1vbml0b3Jpbmcgc2lnbmFsaW5nIGlzIGJhc2lj YWxseSBtZXRhZGF0YQ0KY29sbGVjdGlvbiAtIHNlZWluZyB3aG8gY2FsbGVkIHdob20gYXQgd2hh dCB0aW1lLCBhbmQgc28gb24uIE5laXRoZXIgU1RJUg0Kbm9yIFNJUEJSQU5EWSBleHBsaWNpdGx5 IGFkZHJlc3NlcyB0aGF0LiBJZiB0aGUgYXR0YWNrZXIgY2FuIGNvbXByb21pc2UNCmludGVybWVk aWFyaWVzLCBvciBvdGhlcndpc2UgcGVyc3VhZGUgdGhlbSB0byB5aWVsZCBsb2dzIG9mIHRoZSBz aWduYWxpbmcsDQp0aGVuIGFncmVlZCBTSVBTIHdvdWxkIGFkZCBsaXR0bGUgdmFsdWUuIEJ1dCB0 aGF0IGlzIGZhciBoYXJkZXIgdG8gYXJyYW5nZQ0KdGhhbiBqdXN0IHNub29waW5nIG9uIGNsZWFy dGV4dCB0cmFmZmljIG92ZXIgdGhlIHdpcmUuDQoNCkkgZG8gdGhpbmsgaXQncyBhIGRpZmZlcmVu dCB0aHJlYXQsIGFuZCBpdCByZXF1aXJlcyBkaWZmZXJlbnQNCmNvdW50ZXJtZWFzdXJlcy4gVGhv c2UgY291bnRlcm1lYXN1cmVzIHdpbGwgbm90IGJlIHVuaXZlcnNhbGx5IGF2YWlsYWJsZSwNCmJ1 dCBmb3JjaW5nIFNJUCBvdmVyIFRMUyBhcyBtdWNoIGFzIHBvc3NpYmxlIHN0aWxsIHdvdWxkIG1h a2UgbGlmZSBoYXJkZXINCmZvciB0aGVzZSBwYXNzaXZlIGF0dGFja2Vycy4NCg0KSm9uIFBldGVy c29uDQpOZXVzdGFyLCBJbmMuDQoNCk9uIDYvMTQvMTYsIDE6MDQgUE0sICJQYXVsIEt5eml2YXQi IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KDQo+T24gNi8xNC8xNiAxOjI5IFBNLCBQ ZXRlcnNvbiwgSm9uIHdyb3RlOg0KPj4NCj4+IEp1c3QgdG8gYWRkIGEgYml0IHRvIHdoYXQgQnJp YW4gc2FpZC4uLg0KPj4NCj4+Pj4NCj4+PiBJIHRoaW5rIHdlIG5lZWQgdG8gc3RhcnQgd2l0aCCp +HdoYXQgaWYgd2UgcmVtb3ZlIFNJUFOp9yBhbmQgZ28gYmFjayBhbmQNCj4+PiBzZWUgd2hhdKn2 cyBtaXNzaW5nIGFuZCBob3cgd2UgY2FuIGZpeCB0aGF0LiBBIGxvdCBvZiBwZW9wbGUgcG9pbnQg dG8NCj4+PlNJUFMNCj4+PiBhcw0KPj4+IHRoZSBzb2x1dGlvbiAtIGJ1dCBubyBvbmUgaXMgaW1w bGVtZW50aW5nIG9yIHVzaW5nIGl0Lg0KPj4NCj4+IE9zdGVuc2libHkgd2hhdCB3b3VsZCBiZSBt aXNzaW5nIGlzIGEgbWVjaGFuaXNtIGZvciB1c2VyIGFnZW50cyB0bw0KPj4gaW5kaWNhdGUgdGhh dCBhbnkgaW50ZXJtZWRpYXJpZXMgaGFuZGxpbmcgdGhlaXIgcmVxdWVzdCBzaG91bGQgb25seQ0K Pj4gZm9yd2FyZCBpdCB3aXRoIGhvcC1ieS1ob3AgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3Jp dHkgcHJvdGVjdGlvbnMuDQo+PkFuZA0KPj4gZm9yIFNJUCByZXNvdXJjZXMgdG8gaW5kaWNhdGUg dGhlaXIgcHJlZmVyZW5jZSB0byBiZSByZWFjaGVkIGluIHRoaXMNCj4+IGZhc2hpb24uDQo+DQo+ V2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhlIGhvcC1ieS1ob3AgcHJvdGVjdGlvbnMgaW4gdGhpcyBj b250ZXh0PyBEbyB3ZQ0KPnJlYWxseSBuZWVkIGl0PyBXb24ndCBTVElSIGFuZCBTSVBCUkFORFkg cHJvdmlkZSB3aGF0IGlzIG5lZWRlZCB3aXRob3V0DQo+aXQ/DQo+DQo+Pj4gV2hhdCBpcyB0aGUg cHJvYmxlbSBpdCBzb2x2ZXM/DQo+Pg0KPj4gUGVydmFzaXZlIGVhdmVzZHJvcHBpbmc/DQo+DQo+ U2luY2UgaG9wLWJ5LWhvcCBwcmVzdW1lcyB0aGF0IGFsbCB0aGUgaW50ZXJtZWRpYXJpZXMgYXJl IHRydXN0ZWQsIGFuZA0KPnRoaXMgcmFyZWx5IHNlZW1zIGxpa2UgYSBnb29kIGFzc3VtcHRpb24g Zm9yIHByZXZlbnRpbmcgcGVydmFzaXZlDQo+ZWF2ZXNkcm9wcGluZywgbWF5YmUgaXQgaXNuJ3Qg d29ydGggdGhlIHRyb3VibGUuDQo+DQo+CVRoYW5rcywNCj4JUGF1bA0KPg0KPj4+IElzIHRoZXJl IGFub3RoZXIgd2F5Pw0KPj4NCj4+IE1heWJlLg0KPj4NCj4+PiBXaGF0qfZzIHRoZSBzdGF0dXMg Zm9yIFMvTUlNRS4NCj4+Pg0KPj4+IEkgZG9uqfZ0IHRoaW5rIHdlqfZsbCBmaW5kIHRoYXQgdGhl IGFuc3dlciBpcyBTSVBTOiBhcyBhIFVSSSBzY2hlbWUsIGJ1dA0KPj4+dGhlDQo+Pj4gU0lQIG92 ZXIgVExTIHRyYW5zcG9ydCBpcyBzdGlsbCB2ZXJ5IG11Y2ggbmVlZGVkLCBkaXNjb3ZlcmVkIGJ5 DQo+Pj5OQVBUUi9TUlYNCj4+PiBhbmQgc3VwcG9ydGVkIGJ5IERBTkUgb3Igc29tZSBvdGhlciBQ S0kgc3RydWN0dXJlLg0KPj4NCj4+IElmIHlvdXIgaW50ZW50aW9uIGlzIHRoYXQgd2Ugc2hvdWxk IHJlcGxhY2UgU0lQUyB3aXRoIHNvbWV0aGluZyB0aGF0DQo+PiBwcm92aWRlcyBhIHN0cm9uZ2Vy IGFzc3VyYW5jZSBvZiBob3AtYnktaG9wIHNpZ25hbGluZyBjb25maWRlbnRpYWxpdHksDQo+PiB0 aGVuIGdyZWF0LCBsZXQncyBzcGVjaWZ5IHRoYXQgc3Ryb25nZXIgbWVjaGFuaXNtIGZpcnN0IGFu ZCB0aGVuIHdlJ2xsDQo+PiBkZXByZWNhdGUgU0lQUyBpbiBmYXZvciBvZiBpdC4gSWYgdGhlIHBy b2Nlc3MgaXMgaW5zdGVhZCwgbGV0J3MNCj4+ZGVwcmVjYXRlDQo+PiBTSVBTIGFuZCB0aGVuIGhv cGUgd2UgY2FuIGludmVudCBzb21ldGhpbmcgZWxzZSB0byBhZGRyZXNzIHBlcnZhc2l2ZQ0KPj4g ZWF2ZXNkcm9wcGluZyBsYXRlciwgSSB3b3VsZCBwcm9iYWJseSBzYXkgdGhhdCdzIHVuYWNjZXB0 YWJsZSwgcHJvdmlkZWQNCj4+d2UNCj4+IHRoaW5rIHRoZXJlIGFyZSBhbnkgZGVwbG95bWVudCBl bnZpcm9ubWVudHMgaW4gd2hpY2ggU0lQUyBjb3VsZCB3b3JrIGFzDQo+PiBhZHZlcnRpc2VkLiBB bmQgeWVzLCBJJ20gYXdhcmUgdGhlcmUgYXJlIGRlcGxveW1lbnQgZW52aXJvbm1lbnRzIGluDQo+ PndoaWNoDQo+PiBpdCBpcyBqdXN0IGEgbnVpc2FuY2UsIGJ1dCBjb2luY2lkZW50YWxseSwgdGhv c2UgYXJlIGFsc28gZGVwbG95bWVudA0KPj4gZW52aXJvbm1lbnRzIHRoYXQgYXJlIG5vdCBvdmVy bHkgY29uY2VybmVkIHdpdGggcGVydmFzaXZlIGVhdmVzZHJvcHBpbmcuDQo+Pg0KPj4gQWdhaW4s IGRpc2NvdmVyaW5nIHZpYSBOQVBUUi9TUlYgdGhhdCB0aGUgcmVzb3VyY2Ugd2FudHMgdG8gYmUg cmVhY2hlZA0KPj4gb3ZlciBUTFMgd2FzIG9uZSBvZiB0aGUgcHJpbWFyeSBmdW5jdGlvbnMgZm9y IHdoaWNoIFNJUFMgd2FzIGRldmlzZWQuDQo+PkknbQ0KPj4gbm90IHN1cmUgaG93IGRpZmZlcmVu dCBhbnl0aGluZyB3ZSBjb21lIHVwIGFsb25nIHRob3NlIGxpbmVzIHdvdWxkDQo+PiByZWFsaXN0 aWNhbGx5IGJlIGZyb20gd2hhdCdzIGFscmVhZHkgaW4gUkZDMzI2My4NCj4+DQo+PiBKb24gUGV0 ZXJzb24NCj4+IE5ldXN0YXIsIEluYy4NCj4+DQo+Pg0KPg0KDQo= From nobody Tue Jun 14 18:58:53 2016 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 56D7012DADF for ; Tue, 14 Jun 2016 18:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Yi1l9T3RshRR for ; Tue, 14 Jun 2016 18:58:51 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 6F46612DAD0 for ; Tue, 14 Jun 2016 18:58:49 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-05v.sys.comcast.net with SMTP id D03hbex0k8JCND06SbMHTM; Wed, 15 Jun 2016 01:58:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465955928; bh=g9WJDdQ7YHOi6kWjIT/iEEbrbhC2aOMYfvXx+CellIY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qIy2vpTTB38fSpcKE62PkBIdS1ZLcPGDrHXX3EzGH2ya3xIl9WupEnwLDiYNoWKLx mcYCH9nKV25iiFb8nM9nX5A6MzJZA98eeGUivmmGXbw4lOpLIldCGzzDOy3hfOETWE sJNN/PIIK1lWCdQjpncbL05o0tF2fDOjzJuNTyYtugYmmogfFtLS7sXV1zhCXDaA3e JklWc8Ft2alj1Fcjptkj3l9QEtXX+mmgWXxHHWzfAfVBGp9tDIHsUTXPZ91UmF0ePJ 8T2E2ZHTLEby5MJVZ58ubjzfMgp/2+82trqC44jJzNhfNa7xGrza0xdIEo+pdQxzi0 kZUaAcB+jH37Q== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id 6pyn1t0043KdFy101pynRs; Wed, 15 Jun 2016 01:58:48 +0000 To: "Peterson, Jon" , "Olle E. Johansson" References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> <28e047ef-890c-1c9b-e280-eee39107361b@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Tue, 14 Jun 2016 21:58:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sipcore@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 01:58:52 -0000 On 6/14/16 4:45 PM, Peterson, Jon wrote: > > The threat of pervasively monitoring signaling is basically metadata > collection - seeing who called whom at what time, and so on. Neither STIR > nor SIPBRANDY explicitly addresses that. If the attacker can compromise > intermediaries, or otherwise persuade them to yield logs of the signaling, > then agreed SIPS would add little value. But that is far harder to arrange > than just snooping on cleartext traffic over the wire. > > I do think it's a different threat, and it requires different > countermeasures. Those countermeasures will not be universally available, > but forcing SIP over TLS as much as possible still would make life harder > for these passive attackers. Agreed, but that can be achieved simply by getting TLS to be the default. That might be an easier thing to sell if we can get SIP over DTLS defined. Thanks, Paul > Jon Peterson > Neustar, Inc. > > On 6/14/16, 1:04 PM, "Paul Kyzivat" wrote: > >> On 6/14/16 1:29 PM, Peterson, Jon wrote: >>> >>> Just to add a bit to what Brian said... >>> >>>>> >>>> I think we need to start with ©øwhat if we remove SIPS©÷ and go back and >>>> see what©ös missing and how we can fix that. A lot of people point to >>>> SIPS >>>> as >>>> the solution - but no one is implementing or using it. >>> >>> Ostensibly what would be missing is a mechanism for user agents to >>> indicate that any intermediaries handling their request should only >>> forward it with hop-by-hop confidentiality and integrity protections. >>> And >>> for SIP resources to indicate their preference to be reached in this >>> fashion. >> >> What is the point of the hop-by-hop protections in this context? Do we >> really need it? Won't STIR and SIPBRANDY provide what is needed without >> it? >> >>>> What is the problem it solves? >>> >>> Pervasive eavesdropping? >> >> Since hop-by-hop presumes that all the intermediaries are trusted, and >> this rarely seems like a good assumption for preventing pervasive >> eavesdropping, maybe it isn't worth the trouble. >> >> Thanks, >> Paul >> >>>> Is there another way? >>> >>> Maybe. >>> >>>> What©ös the status for S/MIME. >>>> >>>> I don©öt think we©öll find that the answer is SIPS: as a URI scheme, but >>>> the >>>> SIP over TLS transport is still very much needed, discovered by >>>> NAPTR/SRV >>>> and supported by DANE or some other PKI structure. >>> >>> If your intention is that we should replace SIPS with something that >>> provides a stronger assurance of hop-by-hop signaling confidentiality, >>> then great, let's specify that stronger mechanism first and then we'll >>> deprecate SIPS in favor of it. If the process is instead, let's >>> deprecate >>> SIPS and then hope we can invent something else to address pervasive >>> eavesdropping later, I would probably say that's unacceptable, provided >>> we >>> think there are any deployment environments in which SIPS could work as >>> advertised. And yes, I'm aware there are deployment environments in >>> which >>> it is just a nuisance, but coincidentally, those are also deployment >>> environments that are not overly concerned with pervasive eavesdropping. >>> >>> Again, discovering via NAPTR/SRV that the resource wants to be reached >>> over TLS was one of the primary functions for which SIPS was devised. >>> I'm >>> not sure how different anything we come up along those lines would >>> realistically be from what's already in RFC3263. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> >> > From nobody Tue Jun 14 22:21:56 2016 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 A1ADB12D0CA for ; Tue, 14 Jun 2016 22:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rr_qE8bKv4Lj for ; Tue, 14 Jun 2016 22:21:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 9549612D0A1 for ; Tue, 14 Jun 2016 22:21:50 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 5BAA0428B; Wed, 15 Jun 2016 07:21:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 15 Jun 2016 07:21:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B9086B1-6B5D-459D-95DF-426C337B6946@edvina.net> References: <9C858D97-7508-483A-8823-507F7F10ADDA@edvina.net> <87d1no3dgz.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B3804B3B5@ESESSMB209.ericsson.se> <46229759-0887-4C3F-B84D-51BA591B1ED6@att.com> <949EF20990823C4C85C18D59AA11AD8BADF14B42@FR712WXCHMBA11.zeu.alcatel-lucent.com> <492A42E2-FD69-4882-B1DA-E0A9277D7125@edvina.net> <28e047ef-890c-1c9b-e280-eee39107361b@alum.mit.edu> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , "DOLLY, MARTIN C" Subject: Re: [sipcore] SIPS must die, die, die X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 05:21:55 -0000 > On 14 Jun 2016, at 22:45, Peterson, Jon = wrote: >=20 >=20 > The threat of pervasively monitoring signaling is basically metadata > collection - seeing who called whom at what time, and so on. Neither = STIR > nor SIPBRANDY explicitly addresses that. If the attacker can = compromise > intermediaries, or otherwise persuade them to yield logs of the = signaling, > then agreed SIPS would add little value. But that is far harder to = arrange > than just snooping on cleartext traffic over the wire. >=20 > I do think it's a different threat, and it requires different > countermeasures. Those countermeasures will not be universally = available, > but forcing SIP over TLS as much as possible still would make life = harder > for these passive attackers. Thank you Jon!=20 That=E2=80=99s exactly what I want to do by making implementing TLS in SIP more straightforward, better documented and easier to test. I do believe the SIPS: uri scheme has been a hindrance and by removing = it (or just discussing what will happen if we remove it) we will focus on = the right things to make both SIP over TLS in a secure context and SIP over=20= TLS in opportunistic mode more of a default than it is now. We=E2=80=99ve come far in the specification of SIPconnect 2.0 (work in = progress) but identified a few issues that needs to be solved in the IETF. One is the =E2=80=9Chalf-outbound=E2=80=9D and another is how to live = without =E2=80=9C;transport=3Dtls=E2=80=9D. I=E2=80=99m trying to summarize my view of the discussion about SIPS: = and some of the areas I think we need to look at in a separate document. /O >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/14/16, 1:04 PM, "Paul Kyzivat" wrote: >=20 >> On 6/14/16 1:29 PM, Peterson, Jon wrote: >>>=20 >>> Just to add a bit to what Brian said... >>>=20 >>>>>=20 >>>> I think we need to start with =C2=B3what if we remove SIPS=C2=B2 = and go back and >>>> see what=C2=B9s missing and how we can fix that. A lot of people = point to >>>> SIPS >>>> as >>>> the solution - but no one is implementing or using it. >>>=20 >>> Ostensibly what would be missing is a mechanism for user agents to >>> indicate that any intermediaries handling their request should only >>> forward it with hop-by-hop confidentiality and integrity = protections. >>> And >>> for SIP resources to indicate their preference to be reached in this >>> fashion. >>=20 >> What is the point of the hop-by-hop protections in this context? Do = we >> really need it? Won't STIR and SIPBRANDY provide what is needed = without >> it? >>=20 >>>> What is the problem it solves? >>>=20 >>> Pervasive eavesdropping? >>=20 >> Since hop-by-hop presumes that all the intermediaries are trusted, = and >> this rarely seems like a good assumption for preventing pervasive >> eavesdropping, maybe it isn't worth the trouble. >>=20 >> Thanks, >> Paul >>=20 >>>> Is there another way? >>>=20 >>> Maybe. >>>=20 >>>> What=C2=B9s the status for S/MIME. >>>>=20 >>>> I don=C2=B9t think we=C2=B9ll find that the answer is SIPS: as a = URI scheme, but >>>> the >>>> SIP over TLS transport is still very much needed, discovered by >>>> NAPTR/SRV >>>> and supported by DANE or some other PKI structure. >>>=20 >>> If your intention is that we should replace SIPS with something that >>> provides a stronger assurance of hop-by-hop signaling = confidentiality, >>> then great, let's specify that stronger mechanism first and then = we'll >>> deprecate SIPS in favor of it. If the process is instead, let's >>> deprecate >>> SIPS and then hope we can invent something else to address pervasive >>> eavesdropping later, I would probably say that's unacceptable, = provided >>> we >>> think there are any deployment environments in which SIPS could work = as >>> advertised. And yes, I'm aware there are deployment environments in >>> which >>> it is just a nuisance, but coincidentally, those are also deployment >>> environments that are not overly concerned with pervasive = eavesdropping. >>>=20 >>> Again, discovering via NAPTR/SRV that the resource wants to be = reached >>> over TLS was one of the primary functions for which SIPS was = devised. >>> I'm >>> not sure how different anything we come up along those lines would >>> realistically be from what's already in RFC3263. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jun 15 07:51:41 2016 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 2C10912D796 for ; Wed, 15 Jun 2016 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 DrimWA9-5-oa for ; Wed, 15 Jun 2016 07:51:37 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 E01D912D802 for ; Wed, 15 Jun 2016 07:51:36 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id j2so32837841vkg.2 for ; Wed, 15 Jun 2016 07:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxEnd9m7HkNJLVBqRLkXQvDUkJZePfwoKi4ajV91p+E=; b=yIZujm5arzq9gq3uJiP7fyVw11vPP4lVYLAWKHvSXgeH9d2c0vuJ14QVz2lg7A4LtK 6khw1kqkQ/KP1IhMU9zcT0euuhOsjGhPjAzwdDJW3mxhPGZiMgoMupabTOM/INz0i1JE +q1dql0w15a6Lh592TGkhAV7gtN+w/3RZY2O1Lx+k45DAv3vOlDtfRKRbwdKlIMSlEO6 oYXBUJ30RDmeNfuzwQfsusyluRAme6jvpASCsKfGqN7UkkbM2tGNeIk+GFq3WBJOykhz 2+GFd4jmVYjOt5x9H0GEV8clSWJv7Le5dFktXsNgtmeipq+MsIDUOogc6SdA74aiA8FK 0vNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zxEnd9m7HkNJLVBqRLkXQvDUkJZePfwoKi4ajV91p+E=; b=j+LYkZBt9SKCleKRwCv88yxh/HzRgYa+vEEV+bgNop57aQg20LlOujmw7C1JBqbeG2 g/B4xZR2ryW4qnbTwXaPhhdqds7hmrwlzGEjfWjyTnumXXHg5GbBJPahu3vX6KUooMb0 vIaLkZ5Fu2ebBcSq84SmKAqrJ0VM6WmOKxGbMqBTUFGKnFPwClFxZfHPZMa8ePvRwjB2 S/hMzPRqBPPr8NWdj8NF57aFzhLcBmkK3pzpuYehCmkwntwIdYw4Tv8K+vD9YeR+4rZ4 vaYvQxYV/hHA/eBn7ZhmEOgzx76rJ7z8SFZoIZUX+2VscrejqcB1adXItAMKCxOva378 C7UQ== X-Gm-Message-State: ALyK8tK4xdnvvLYD9xSlIGltcxDFqQuUb/eW3x1W4Idgflwb5zzu58pbnKdl3xjHqHsPFDESgAVLHms/v9nEzQ== X-Received: by 10.31.56.216 with SMTP id f207mr11269324vka.135.1466002295805; Wed, 15 Jun 2016 07:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Wed, 15 Jun 2016 07:51:34 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Wed, 15 Jun 2016 10:51:34 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a1143e6e414dcbd0535524206 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:51:40 -0000 --001a1143e6e414dcbd0535524206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2016 at 1:27 PM, Peterson, Jon wrote: > > This time my response should be more complete. Sorry about that! > > >> Radhika sent a helpful summary of conference control protocols to the >> list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which >> actually let you manage attributes of a conference like the number of >> participants and media types allowed. >> > > This conference use case was an example for a SIP-based conference server > (RFC4579), just to describe the idea around the delegation of AuthNZ. > > If the server is a CCMP-based conference, then you would obviously use > that to control and manage the conference server. > > > While RFC4579 (an implementation of the RFC4353 framework) provides a > means to do conference control from within SIP, the kinds of control > primitives it specifies are totally decoupled from the sorts of policies > that the attributes you proposed would constrain. Those policies fall und= er > what RFC4353 calls "conference policy." > I agree. This is an important distinction and clarification. > Neither RFC4579 nor its requirements (RFC4245) really say anything about > how conference policy is set or distributed. RFC4353 does, though, and wh= at > it says is (in 4.6) is "the conference policy can be manipulated using we= b > applications or voice applications [i.e. IVRs - JFP]. It can also be > manipulated with non-SIP-specific standard or proprietary protocols." > > Proposal #3 delegates this function from the conference server to the authorization server. The conference server becomes a consumer and enforcer of a policy. > Authorizing SIP requests is misaligned with setting conference policy, > especially in consideration of the sorts of attributes you seem to have i= n > mind - even when we're considering controlling conferences compliant with > the RFC4353 framework. That's because the conference in RFC4579 isn't > "created" when a user agent sends an INVITE request to the conference > bridge - it is created when the conference URI is created, which is > necessarily beforehand (or at best, ad hoc through the conference factory= ). > Conference policy is set and disseminated in that context, not in the > context of the SIP transaction that happens to open the bridge. > In the diagram I provided, I did not separate the Conference Factory from the Focus, maybe I should have. The INVITE with the token will be sent to the factory, which will create the focus and set the proper limitation on the focus based on the authorization provided in the token. How is this misaligned with settings a conference policy? > > Moreover, my point was that the example of CCMP shows that you can do > conference control with OAuth over in the HTTP realm without needing to a= dd > anything whatsoever to SIP. If you need OAuth-style controls for > conferencing, that would seem to be a quicker path to implementation. > If your conference server supports CCMP, then yes, that would be the right answer. What if your server does not support CCMP? But, again, the conference use case is an example only to drive the point, not to discuss the best way to implement conference server. > > >> The interesting thing about protocols like CCMP is that they are not, yo= u >> know, actually transported by SIP. CCMP is transported by HTTP. Why? >> Because the semantics of conference control doesn't actually map onto SI= P >> INVITE transactions very well. They map quite aptly to HTTP, and in the >> HTTP context, you can certainly use OAuth if you like. >> > > > Help me understand this part. > > Why can an HTTP request transport a token to a resource server to be able > to access a specific resource, while SIP request cannot transport a simil= ar > token to a SIP server to access a service? > > > Of course both SIP and HTTP can carry arbitrary chunks of data, including > any sort of token we can imagine. My point is that the semantics of an > INVITE are really different from the semantics of a POST - and that is wh= y, > ultimately, protocols like CCMP don't use SIP as a transport but instead > use HTTP. INVITEs are sent by a user agent when it is trying to set up a > media session between itself and some remote resource on the Internet. > Not necessarily; an INVITE is used to create a conference focus, for example. And, as Christer mentioned, the use of token is not limited to INVITEs. It will be used with a REGISTER request to allow a UA to register with the registrar, and maybe other SIP methods. > While RFC4579 has a way to open a conference as a side effect of sending > an INVITE to connect to the conference, the policies associated with the > sorts of attributes you specified are set totally outside the context of > that dialog, and the execution of those policies is completely disconnect= ed > from the authorization of the conference-opening INVITE. More on this bel= ow. > > I think the interesting question about standardizing an approach to > authorization of SIP requests is about INVITE. Of course, SIP supports > faux-HTTP semantics with mechanisms like PUBLISH and NOTIFY, and we could > talk about authorizing a number of other non-dialog-forming methods as > well, but if we're going to kick off an effort to specify authorization > policy for SIP, the primary thing we need to worry about is INVITE. > > > You even will find some text about Role-Based Access Control in the XCON >> (RFC6503) security consideration. Although you can use SIP and SDP to se= t >> up a BFCP connection (RFC4583), the security of BFCP relies on mutual TL= S >> between its own endpoints. It is unclear to me what carrying attribute >> information around in a SIP INVITE would accomplish with regards to >> authorizing CCMP or BFCP transactions. >> > > SIP INVITE will carry attributes to authorize that specific SIP request; > there is nothing in proposal #3 that suggest that SIP will carry > authorization for CCMP or any other protocol. > > > That is where I think you and I have a disconnect. The SIP INVITE in the > conference control (RFC4579) case would not carry attributes like the one= s > you've identified in order to authorize that specific SIP request. The > attributes that you identified - the media types the conference allows an= d > the number of participants permitted simultaneously in a conference - hav= e > nothing to do with the SIP INVITE that opens the conference bridge. > Well, not exactly. The first INVITE that is sent to the conference factory is exactly that. > Instead, they are components of conference policy. Those policies apply t= o > authorization decisions regarding later participants that will be added t= o > the conference, and thus to the authorization of later SIP transactions a= nd > dialogs, such as when a new participant sends an INVITE to the conference > bridge after having been sent a REFER by the conference controller, say, > and the focus decides to reject that INVITE because the maximum number of > participants has been exceeded. > Sure, the INVITE that is sent to the focus would fall under this description. Why is that a bad thing? > We can imagine a way to publish such a conference policy to the conferenc= e > bridge with SIP, of course, but the question is, in what sense are those > policies actually aligned with the question of whether or not we should > authorize the SIP request that carries them? If they are not, then we > aren't really talking about authorizing SIP requests, we're talking > uploading long-term application policies over SIP with faux-HTTP semantic= s, > which is pretty far from where we started and where I think we need to go= . > There is no "uploading long-term application policies"; the long term policies are set on the authorization server. The INVITE will carry the authorization for a specific focus targeted by the this request. > >> >> So again, the point of my last mail was that the problem of authorizing >> SIP INVITEs is actually different from the problem of authorizing generi= c >> application transactions. SIP INVITEs still have more or less the semant= ics >> of a call setup message: they are requesting that a session be initiated= . >> Conference control is not managed with SIP transactions, and the securit= y >> of conference control protocols does not devolve to authorizing SIP >> transactions. >> > > Well, RFC4579 defines a SIP Conference Control mechanism that allows you > to initiate and control a conference server using only SIP requests; so I > am not sure I understand this statement, unless we have different > definitions for the term =E2=80=9Cconference control=E2=80=9D. > > > Yeah, I was using the term loosely - once we bring RFC4579 into the mix, > we need to distinguish "conference control" from "conference policy," and > then say that RFC4579 and the entire RFC4353 framework is about control, > not about managing conference policy over SIP. The two attributes you > propose belong to that conference policy realm rather than conference > control, strictly speaking. > > In any case, my point was not to discuss conference servers specifically, > but to discuss the general idea of delegating both AuthN and AuthZ in a S= IP > network. > > > In that case, if you could furnish a use case with attributes that would > be carried in a SIP iNVITE that are actually salient to the authorization > of that particular SIP request, we'd be getting a lot closer to common > ground. > > An obvious example would be an INVITE with a token sent to a conference factory to authorize the creation of a focus. Regards, Rifaat > Jon Peterson > Neustar, Inc. > > > > Regards, > > Rifaat > > > > > >> I suspect we'll find that most of the other security attributes that >> "applications" need to do their jobs similarly don't map onto the semant= ics >> of a SIP INVITE - but, I'm still open to entertaining examples that migh= t >> cast doubt on that suspicion. >> >> Jon Peterson >> Neustar, Inc. >> >> From: Rifaat Shekh-Yusef >> Date: Thursday, June 9, 2016 at 10:59 AM >> To: Jon Peterson >> Cc: Christer Holmberg , "sipcore@ietf.or= g" >> >> Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 >> >> Hi Jon, >> >> Sorry for the delayed reply. >> >> Let's take the video conference example, and discuss the possible ways >> for the conference server to provide service. >> >> >> Trust Domain 1 : Internet : Trust Domain 2 >> : : >> +--------+ : : >> | IdP | : : >> +-------------| AuthZ | : : >> | | | : : >> | +--------+ : : >> | | : : >> | | : : >> +--------+ +--------+ : : +--------+ >> | | | SIP | : : | SIP App| >> | UA |--------| Proxy |-----:-----------------:-----| Video | >> | | | | : : | Conferenc= e >> +--------+ +--------+ : : +--------+ >> : : >> >> Possible solutions: >> >> 1. Conference Server acts as an AuthN and AuthZ server. Requests to >> the server must provide an identity and credentials, and services will >> be provided based on locally stored information associated with >> the identity provided in the request. >> >> 2. Conference Server acts as an AuthZ server, but delegates the AuthN >> part. Requests to the server must provide an identity token, and service= s >> will be provided based on locally stored information associated with >> the identity provided in the token. >> >> 3. Conference Server delegates both AuthN and AuthZ parts. Requests to >> the server must provide an access token, which might or might not >> include information about the user requesting the service, and services >> will be provided based on information provided in the access token or as >> a result of an introspection step using the access token. >> >> >> Now, let's look at the 3rd option a bit more, and assume that the >> server provides the following types of conference services: >> 1. audio conference >> 2. audio/video conference >> 3. web conference >> >> or some combination of the above. >> >> Let's also assume that the server allows control over the number >> of participants allowed in each one of these conference types or >> combinations. >> >> >> Here is one way that I envisioned we could use to address this use case: >> >> When an enterprise user in the 1st trust domain wants to register with >> the SIP Proxy, it will have to authenticate to the IdP and as a result >> either the UA or the Proxy (depends on the UA's capabilities) will be >> provided with an AuthN and AuthZ tokens. This process could involve an >> interim step to allow only the proxy to get access to the tokens, or the >> tokens could be sent to the UA which will then use them to communicate w= ith >> the proxy. >> >> The AuthN token is the identity of the user, and the AuthZ token has >> all the services granted to the user by the IdP/AuthZ Service. >> >> When the enterprise user needs access to the conference service, the >> UA will send an INVITE to the Proxy, and will include the AuthZ token if= it >> is in possession of the tokens; otherwise, the proxy will add the >> appropriate token to the outgoing INVITE sent to the conference server. >> >> The scope of the AuthZ token might grant the user access to >> multiple services; to avoid sending that AuthZ token to all servers >> providing services granted to the user, the proxy could obtain a differe= nt >> token with limited scope that is specific to the service being provided >> (conference services in this case); there is a standard Token Exchange >> mechanism for that. >> >> The AuthZ token will include information about the type of service >> allowed (audio, audio/video, etc), and the limit on the number of >> participants. The AuthZ token might or might not have any information ab= out >> the user requesting the service, which depends on the level of privacy >> needed. >> >> When the conference server receives this token in the SIP INVITE, all >> it has to do is validate that the token was signed by an IdP that it has >> a trust relationship with, and provide the service requested by the >> AuthZ token. The conference server does not need the AuthN token to be a= ble >> to provide a service. >> >> Regards, >> Rifaat >> >> >> On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon >> wrote: >> >>> >>> Also, if we decided to separate the AuthN and AuthZ, then we might need >>> to carry more than one token. >>> >>> >>> I could see an argument that there is a need to carry the identity of >>> the user in one header, and a reference to a place where you can get >>> attributes about the originating user in another header, say. That's mo= re >>> or less what we envisioned the last time we went down this path, which = led >>> to the RFC4484 requirements, largely informed by SAML (which I seem to >>> recall 3GPP was interested in at the time). >>> >>> But it's no accident that the work on RFC4484 never went beyond >>> requirements. Today, I think that much of the useful work that could be >>> done on the authorization question is in identifying which SIP >>> authorization policies are likely to depend on attributes as opposed to >>> just the identity of the end user. While we can readily conceive of >>> applications adjunct to communications that would require attributes, t= he >>> challenge has been justifying why you would invoke those applications w= ith >>> SIP rather than, say, HTTP. The fundamental semantics of a SIP INVITE = have >>> remained pretty close to those of placing a telephone call. The >>> authorization policies of a telephone call are really different than th= at >>> of a web service, say, both in terms of how and why they are invoked, w= hat >>> kinds of parties are involved, what forms redirection or cross-domain >>> interaction can occur. With appropriate caveats for other methods (nota= bly >>> MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization polic= y >>> requirements that look a lot like call treatment policies. >>> >>> That much said, I am kind of interested in call treatment policies, and >>> their interaction with identity information. But just saying that there >>> might be a video conference service in the cloud, say, doesn't shed a l= ot >>> of light for me. If there's a video conference, I'd ordinarily think yo= u >>> just call into it. If the user who opens the conference bridge needs to= be >>> charged, that's identity information - which in its usual form will con= vey >>> the individual user and their domain, like user@domain. If you need >>> more complex semantics than that, it's probably because you're doing >>> something more complicated than just calling in to the conference. But = it's >>> less clear to me why you'd use SIP for such cases. Drilling down deeper >>> into these use cases would help me understand where we're going, anyway= - >>> the use cases in RFC4484 Section 4, which largely involve billing >>> (including when dealing with various protocol gateways) and resource >>> management (both preemption and priority), ultimately didn't seem >>> sufficient to motivate protocol work. >>> >>> Another issues in the need, in some cases, to avoid sending the token t= o >>> the UA; in this case there is a need for an interim step to get the >>> token(s) to the SIP proxy. >>> >>> >>> If this information is carried in headers, then presumably it could be >>> added, consumed, subtracted, or whatever by any relevant intermediaries= . >>> >>> Jon Peterson >>> Neustar, Inc. >>> >> >> > --001a1143e6e414dcbd0535524206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 14, 2016 at 1:27 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:

This time my response should be more complete. Sorry about that!
=


Radhika sent a helpful summary of conference control protocols to the = list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which ac= tually let you manage attributes of a conference like the number of partici= pants and media types allowed.

This conference use case was an e= xample for a SIP-based conference server (RFC4579), just to describe the id= ea around the delegation of AuthNZ.

If the server is a CCMP-based con= ference, then you would obviously use that to control and manage the confer= ence server.

While RFC4579 (an implementation of the RFC4353 framework) provides a = means to do conference control from within SIP, the kinds of control primit= ives it specifies are totally decoupled from the sorts of policies that the= attributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy."= ;

I agree. This is an im= portant distinction and clarification.

=C2=A0
Neither RFC4579 nor its= requirements (RFC4245) really say anything about how conference policy is = set or distributed. RFC4353 does, though, and what it says is (in 4.6) is &= quot;the conference policy can be manipulated using web applications or voice applications [i.e. IVRs= - JFP]. It can also be manipulated with non-SIP-specific standard or propr= ietary protocols."


Proposal #3 del= egates this function from the conference server to the authorization server= . The conference server becomes a consumer and enforcer of a policy.
<= div>
=C2=A0
Authorizing SIP requests is misaligned with setting conference policy,= especially in consideration of the sorts of attributes you seem to have in= mind - even when we're considering controlling conferences compliant w= ith the RFC4353 framework.=C2=A0 That's because the conference in RFC4579 isn't "created" when a user agent = sends an INVITE request to the conference bridge - it is created when the c= onference URI is created, which is necessarily beforehand (or at best, ad h= oc through the conference factory). Conference policy is set and disseminated in that context, not in the context of the = SIP transaction that happens to open the bridge.

In the diagram I provided, I did not separate the C= onference Factory from the Focus, maybe I should have.
The INVITE= with the token will be sent to the factory, which will create the focus an= d set the proper limitation on the focus based on the authorization provide= d in the token.
How is this misaligned with settings a conference= policy?

=C2=A0

Moreover, my point was that the example of CCMP shows that you can do = conference control with OAuth over in the HTTP realm without needing to add= anything whatsoever to SIP.=C2=A0 If you need OAuth-style controls for con= ferencing, that would seem to be a quicker path to implementation.

= If your conference server supports CCMP, then yes, that would be the right = answer. What if your server does not support CCMP?
But, again= , the conference use case is an example only to drive the point, not to dis= cuss the best way to implement conference server.

= =C2=A0

=C2=A0

The interesting thing about protocols like CCMP is that they are not, = you know, actually transported by SIP. CCMP is transported by HTTP. Why? Be= cause the semantics of conference control doesn't actually map onto SIP= INVITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OA= uth if you like.
=C2=A0

Help me understand this part.

Why can an HTTP request transport= a token to a resource server to be able to access a specific resource, whi= le SIP request cannot transport a similar token to a SIP server to access a= service?

Of course both SIP and HTTP can carry arbitrary chunks of data, includ= ing any sort of token we can imagine. My point is that the semantics of an = INVITE are really different from the semantics of a POST - and that is why,= ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.=C2=A0 INVITEs are s= ent by a user agent when it is trying to set up a media session between its= elf and some remote resource on the Internet.

Not necessarily; an INVITE is used to create a confer= ence focus, for example.
And, as Christer mentioned, the use of t= oken is not limited to INVITEs. It will be used with a REGISTER request to = allow a UA to register with the registrar, and maybe other SIP methods.

=C2=A0


You even will find some text about Role-Based Access Control in the XC= ON (RFC6503) security consideration. Although you can use SIP and SDP to se= t up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS= between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE w= ould accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes = to authorize that specific SIP request; there is nothing in proposal #3 tha= t suggest that SIP will carry authorization for CCMP or any other protocol.=


That is where I think you and I have a disconnect. The SIP INVITE in t= he conference control (RFC4579) case would not carry attributes like the on= es you've identified in order to authorize that specific SIP request. T= he attributes that you identified - the media types the conference allows and the number of participants permi= tted simultaneously in a conference - have nothing to do with the SIP INVIT= E that opens the conference bridge.
Well, not exactly.
The first INVITE that is sent to t= he conference factory is exactly that.

=C2=A0
<= /div>
Instead, they are c= omponents of conference policy. Those policies apply to authorization decisions regarding later participants that will be added= to the conference, and thus to the authorization of later SIP transactions= and dialogs, such as when a new participant sends an INVITE to the confere= nce bridge after having been sent a REFER by the conference controller, say, and the focus decides to reject= that INVITE because the maximum number of participants has been exceeded.<= /div>

Sure, the INVITE that is = sent to the focus would fall under this description. Why is that a bad thin= g?
=C2=A0


We can imagine a way to publish such a conference policy to the confer= ence bridge with SIP, of course, but the question is, in what sense are tho= se policies actually aligned with the question of whether or not we should = authorize the SIP request that carries them? If they are not, then we aren't really talking about authorizing= SIP requests, we're talking uploading long-term application policies o= ver SIP with faux-HTTP semantics, which is pretty far from where we started= and where I think we need to go.

There is no "uploading long-term application policies"; the long term policies are set on the authorization server.=C2= =A0
The INVITE will carry the authorization for a specific focus = targeted by the this request.

=C2=A0

So again, the point of my last mail was that the problem of authorizin= g SIP INVITEs is actually different from the problem of authorizing generic= application transactions. SIP INVITEs still have more or less the semantic= s of a call setup message: they are requesting that a session be initiated. Conference control is not mana= ged with SIP transactions, and the security of conference control protocols= does not devolve to authorizing SIP transactions.

Well, RFC4579 defines a SIP Confe= rence Control mechanism that allows you to initiate and control a conferenc= e server using only SIP requests; so I am not sure I understand this statem= ent, unless we have different definitions for the term =E2=80=9Cconference control=E2=80=9D.

Yeah, I was using the term loosely - once we bring RFC4579 into= the mix, we need to distinguish "conference control" from "= conference policy," and then say that RFC4579 and the entire RFC4353 f= ramework is about control, not about managing conference policy over SIP. The two attributes you propose belong to that conference policy = realm rather than conference control, strictly speaking.

In any case, my poin= t was not to discuss conference servers specifically, but to discuss the ge= neral idea of delegating both AuthN and AuthZ in a SIP network.

In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious exam= ple would be an INVITE with a token sent to a conference factory to authori= ze the creation of a focus.

Regards,
=C2= =A0Rifaat

=C2=A0
Jon Peterson
Neustar, Inc.

=C2=A0

Regards,

=C2=A0Rifaat



=C2=A0
I suspect we'll find that most of the other security attributes th= at "applications" need to do their jobs similarly don't map o= nto the semantics of a SIP INVITE - but, I'm still open to entertaining= examples that might cast doubt on that suspicion.=C2=A0

Jon Peterson
Neustar, Inc.


Hi Jon,

Sorry for the delayed reply.=

Let's take the video conference= example, and discuss the possible ways for=C2=A0the conference server to provide service.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= rust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2= =A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=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: =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 +--------+ =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 =C2=A0 =C2=A0 | IdP =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 +------= -------| AuthZ =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 =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 =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 =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 =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= =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 =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| SIP =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 | = SIP App|
=C2=A0 =C2=A0 | =C2=A0 UA =C2=A0 |-= -------| Proxy =C2=A0|-----:-----------------:-----| Video =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 | Conference
=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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :

Possible solutions:

1. Conference Server acts as an Aut= hN and AuthZ server. Requests to the=C2=A0server must provide an identity a= nd credentials, and services will be=C2=A0provided based on locally stored = information associated with the=C2=A0identity provided in the request.

2. Conference Server acts as an Aut= hZ server, but delegates the AuthN part.=C2=A0Requests to the server must p= rovide an identity token, and services will=C2=A0be provided based on local= ly stored information associated with the=C2=A0identity provided in the token.

3. Conference Server delegates both= AuthN and AuthZ parts. Requests to the=C2=A0server must provide an access = token, which might or might not include=C2=A0information about the user req= uesting the service, and services will=C2=A0be provided based on information provided in the access token or as a=C2=A0result of a= n introspection step using the access token.


Now, let's look at the 3rd opti= on a bit more, and assume that the server=C2=A0provides the following types= of conference services:
1. audio conference
2. audio/video conference
3. web conference

or some=C2=A0combination=C2=A0of th= e above.

Let's also assume that the serv= er allows control over the number of=C2=A0participants allowed in each one = of these conference types or combinations.


Here is one way that I envisioned w= e could use to address this use case:

When an enterprise user in the 1st trust= domain wants to register with the=C2=A0SIP Proxy, it will have to authenti= cate to the IdP and as a result either=C2=A0the UA or the Proxy (depends on= the UA's capabilities) will be provided=C2=A0with an AuthN and AuthZ tokens. This process could involve an interim step=C2= =A0to allow only the proxy to get access to the tokens, or the tokens could= be=C2=A0sent to the UA which will then use them to communicate with the pr= oxy.

The AuthN token is the identity of the user, and the AuthZ token has all=C2= =A0the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA=C2= =A0will send an INVITE to the Proxy, and will include the AuthZ token if it= is=C2=A0in possession of the tokens; otherwise, the proxy will add the app= ropriate=C2=A0token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple=C2=A0s= ervices; to avoid sending that AuthZ token to all servers providing=C2=A0se= rvices granted to the user, the proxy could obtain a different token with= =C2=A0limited scope that is specific to the service being provided (conference=C2=A0services in this case); there is a standar= d Token Exchange mechanism for=C2=A0that.

The AuthZ token will include information about the type of service allowed= =C2=A0(audio, audio/video, etc), and the limit on the number of participant= s.=C2=A0The AuthZ token might or might not have any information about the u= ser=C2=A0requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it=C2= =A0has to do is validate that the token was signed by an IdP that it has a= =C2=A0trust relationship with, and provide the service requested by the Aut= hZ=C2=A0token. The conference server does not need the AuthN token to be able to=C2=A0provide a service.

Regards,
=C2=A0Rifaat


On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or = less what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond re= quirements. Today, I think that much of the useful work that could be done = on the authorization question is in identifying which SIP authorization pol= icies are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP. =C2=A0The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.=C2=A0 The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lo= t of light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user wh= o opens the conference bridge needs to be charged, that's identity info= rmation - which in its usual form will convey the individual user and their= domain, like user@domain. If you need more complex semantics than that, it's probably because you're doing so= mething more complicated than just calling in to the conference. But it'= ;s less clear to me why you'd use SIP for such cases. Drilling down dee= per into these use cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which = largely involve billing (including when dealing with various protocol gatew= ays) and resource management (both preemption and priority), ultimately did= n't seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.= =C2=A0

Jon Peterson
Neustar, Inc.

--001a1143e6e414dcbd0535524206-- From nobody Wed Jun 15 14:06:48 2016 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 652CE12D965 for ; Wed, 15 Jun 2016 14:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NC_VltnH57ZT for ; Wed, 15 Jun 2016 14:06:46 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 9926C12DBE0 for ; Wed, 15 Jun 2016 14:06:30 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u5FKrKff017157; Wed, 15 Jun 2016 17:06:28 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23geyb1ka5-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2016 17:06:27 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 15 Jun 2016 17:06:27 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgA= Date: Wed, 15 Jun 2016 21:06:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.34] Content-Type: multipart/alternative; boundary="_000_D386CD3B19C95Fjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606150222 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:06:47 -0000 --_000_D386CD3B19C95Fjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In that case, if you could furnish a use case with attributes that would be= carried in a SIP iNVITE that are actually salient to the authorization of = that particular SIP request, we'd be getting a lot closer to common ground. An obvious example would be an INVITE with a token sent to a conference fac= tory to authorize the creation of a focus. We're still talking past each other. My point above was that the two attrib= utes you specified - constraints on conference size and media types - have = nothing to do with the authorization of the INVITE carrying those attribute= s. Like, unless the conference size permitted is 0, then the INVITE that cr= eates an ad hoc conference and connects you to its bridge is not going to b= e rejected by the focus on the basis of that conference size attribute. If = the maximum conference size were 0, the AuthZ service just wouldn't attach = a token to an INVITE as it would never be allowed to start a conference. Sa= me goes for media types. Instead, what your two attributes constrain is what happens after the confe= rence is created: when ten users try to dial in to a conference with a perm= itted size of nine, say. That tenth INVITE would get rejected - not the con= ference-forming INVITE that you propose would carry the token. That's why w= hat you're proposing is overloading the INVITE to tunnel conference policy = constraints to the focus. I mean, maybe that's a problem space worth invest= igating, though I suspect there are good reasons why RFC4353 specified that= conference policy is not manipulated with SIP - mostly because the semanti= cs of manipulating conference policy probably don't map well onto dialog-fo= rming SIP requests. But I think that conference policy provisioning problem= space would be pretty far from where we started in this discussion. Let me reiterate what I wrote in my previous mail, which I quote here at th= e top: "furnish a use case with attributes that would be carried in a SIP i= NVITE that are actually salient to the authorization of that particular SIP= request." Again: "that particular SIP request." Not later transactions in = some broader context in which the original user agent probably isn't even a= n endpoint. The Authorization header in SIP, for example, is actually used by the UAS t= o make a decision about whether or not to authorize the request in which th= e header appears. The token that you propose a SIP INVITE would carry in t= his case is not used by the relying party to make a decision about whether = or not that INVITE is authorized. That's why I believe this conference poli= cy issue is a different problem space entirely from figuring out how to imp= lement attribute-based authorization for SIP requests. Jon Peterson Neustar, Inc. Regards, Rifaat --_000_D386CD3B19C95Fjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <4DADB8DB1059FD4DB56BC49B167136B0@neustar.biz> Content-Transfer-Encoding: quoted-printable


In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to common gr= ound.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the two a= ttributes you specified - constraints on conference size and media types - = have nothing to do with the authorization of the INVITE carrying those attr= ibutes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposing is ove= rloading the INVITE to tunnel conference policy constraints to the focus. I= mean, maybe that's a problem space worth investigating, though I suspect t= here are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map well= onto dialog-forming SIP requests. But I think that conference policy provi= sioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.  The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different pro= blem space entirely from figuring out how to implement attribute-based auth= orization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
 Rifaat

 --_000_D386CD3B19C95Fjonpetersonneustarbiz_-- From nobody Wed Jun 15 18:57:16 2016 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 B2C4B12DA9D for ; Wed, 15 Jun 2016 18:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 iCu_4D1L7RbA for ; Wed, 15 Jun 2016 18:57:13 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 E35E112DA94 for ; Wed, 15 Jun 2016 18:57:12 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-04v.sys.comcast.net with SMTP id DMXrbfNdl8RcDDMYSbw6Wc; Thu, 16 Jun 2016 01:57:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466042232; bh=DJ4yJ0EaBKZdtT54OCL3nQPmm9ZoyllXgVcsiaBhPBU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nXPyebf4IN92BiRFNfRnxshzRKTgt3LUxf4s8lIHwo5nyA/7ZVy1ZnLn1P5bL7I0e yTBybqOpvcc+XcMaykPV55i2fIgtuwd0xG7W2v4Ae0Xlle41JiBCQhLu65mUxD+pZl F8nAduPI4oCTnZ1Id5aCnauHguWtRzfxLUsDpPI6GxcDPX0+kJ/xi9bGtUq0uTkYtj TSJEMD+7xLb3m/ZXp8FcZeGmg5gfRSF1bUF+bZSu+mZ6R6TtKIuAPX82t1OkHXxa3K eRXtjqu6ndWB9isS5b8QQ74Ezs6tQ+D3hq6xJoBbSqWfUwAaXtj5AKH1xpWp8Zl5C+ KBO4vRjp156AA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id 7DxB1t00B1nMCLR01DxB3h; Thu, 16 Jun 2016 01:57:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5G1vAIp027436; Wed, 15 Jun 2016 21:57:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5G1v9Ub027427; Wed, 15 Jun 2016 21:57:09 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Sparks In-Reply-To: (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 15 Jun 2016 21:57:09 -0400 Message-ID: <877fdpuc96.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 01:57:14 -0000 This is a great step for cleaning up this mess! If I'm not mistaken, RFC 3325 (P-Asserted-Identity and P-Preferred-Identity) has a similar problem. The grammar is PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value *(COMMA PPreferredID-value) PPreferredID-value = name-addr / addr-spec Since there are no header-field-parameters, semicolon is not problematic, but comma is a problem, as is question mark. Dale From nobody Thu Jun 16 04:02:57 2016 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 0464C12D134 for ; Thu, 16 Jun 2016 04:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=broadsoft-com.20150623.gappssmtp.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 2nxRvCY-NCWn for ; Thu, 16 Jun 2016 04:02:52 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 9BC1512D0AC for ; Thu, 16 Jun 2016 04:02:52 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p10so48881929qke.3 for ; Thu, 16 Jun 2016 04:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=5oPRJBW0bsUL8uioqQl1+PGERchZSO7Ih9OZJGLRJaw=; b=slZdtA53+c3neaWJeuf2HqvvdxgFrGTXVzEKLhcioBfKdkpd5K3deuh/pFS3JlVZCK Ot67xcTI0ZYcDJZeRkIInH/ozK6bNX+niNPioB+WXjyC0wL5h6uL7/xr0PHd9PEr0VMz ikQyCCCppHHnIG7/e9kZK6J6gmmyt/jA5pbIiZ8TyogssnAmPzV7wOOF+KndBthzR6Qn UhILNeJpgJrYK6HclC4jZ6BwEllC6atnO/XVW0wIQNEJkcyjBOmt7VT0GbZrixPKCfCJ FvJEy9PzDdL9DfEUPE0bUmEKhbmZb64BA2qDxRv+Kh1rQl1K/62s4bWI9S5IWKV/6BHZ jN9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=5oPRJBW0bsUL8uioqQl1+PGERchZSO7Ih9OZJGLRJaw=; b=HZylQIJV1jZNqQJW4r1IC7uhZ6RBx6jBtX0ELSUpUmHZNsRaSagJwL9yjFs0oBCXxq cKj4+HJLJjcq7iHOgVrWXiPbOhVAmyVh/b//+i2PrWcyz2qE+Rm6za8S5gCGJUqx6vwy Q0bFYbQ+ZlSYubBOVE3rkb1LCj0CQOv0oLUMv2HHfRvme1PBWid/YGfmUxn2Rwy7BP6z INrK2uiJNH1BIuF2csXjgbmwDrF2ULwRyrivqU86yRYMS4Q8+WU+/psP+2UdsRMH35un +UqJVH/CtDbx0yrpanqBCqp6mkcofr6E2T6QCrOD9gBNXFkAKGsyYXgzcjamCptq/Mj+ 5nuw== X-Gm-Message-State: ALyK8tIuq+TcTCAKNqGkaMzghfYgYFpYG40BcfvDz9Q9nTqSoCNzowQAHWheBoSlz3Fhfs3cG+u4c1UE2UAD+MTV X-Received: by 10.200.54.110 with SMTP id n43mr3877151qtb.47.1466074971784; Thu, 16 Jun 2016 04:02:51 -0700 (PDT) From: Brett Tate References: (rjsparks@nostrum.com) <877fdpuc96.fsf@hobgoblin.ariadne.com> In-Reply-To: <877fdpuc96.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLczRentPhlI7UN3hqWLmiN4c5RvJ3V4XcQ Date: Thu, 16 Jun 2016 07:02:51 -0400 Message-ID: To: "Dale R. Worley" , Robert Sparks , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:02:55 -0000 Hi, Yes; it is discussed within RFC 3325 errata (3744 and 3894). Should it be mentioned within the draft? > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: Wednesday, June 15, 2016 9:57 PM > To: Robert Sparks > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 > > This is a great step for cleaning up this mess! > > If I'm not mistaken, RFC 3325 (P-Asserted-Identity and > P-Preferred-Identity) has a similar problem. The grammar is > > PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > PAssertedID-value = name-addr / addr-spec > PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value > *(COMMA PPreferredID-value) > PPreferredID-value = name-addr / addr-spec > > Since there are no header-field-parameters, semicolon is not problematic, but > comma is a problem, as is question mark. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jun 16 04:45:22 2016 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 C61DE12D51D for ; Thu, 16 Jun 2016 04:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 8Nu0KbiAmXff for ; Thu, 16 Jun 2016 04:45:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 01D0F12D516 for ; Thu, 16 Jun 2016 04:45:17 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C6C14F1D77C70; Thu, 16 Jun 2016 11:45:13 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5GBjEhB001739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2016 11:45:14 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5GBjAsE004486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jun 2016 13:45:12 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 16 Jun 2016 13:44:53 +0200 From: "Drage, Keith (Nokia - GB)" To: Brett Tate , "Dale R. Worley" , Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 Thread-Index: AQHRx3Jt/4Ic0iLPa0iZeenHUE17Lp/rzNOAgAAs+bA= Date: Thu, 16 Jun 2016 11:44:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF16C12@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: (rjsparks@nostrum.com) <877fdpuc96.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:45:21 -0000 A reminder that RFC 3325 is an informational document, so I am not sure whe= ther a standards track document can update an informational document. Anyon= e able to clarify? Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate Sent: 16 June 2016 12:03 To: Dale R. Worley; Robert Sparks; sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 Hi, Yes; it is discussed within RFC 3325 errata (3744 and 3894). Should it be mentioned within the draft? > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: Wednesday, June 15, 2016 9:57 PM > To: Robert Sparks > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 > > This is a great step for cleaning up this mess! > > If I'm not mistaken, RFC 3325 (P-Asserted-Identity and > P-Preferred-Identity) has a similar problem. The grammar is > > PAssertedID =3D "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > PAssertedID-value =3D name-addr / addr-spec > PPreferredID =3D "P-Preferred-Identity" HCOLON PPreferredID-value > *(COMMA PPreferredID-value) > PPreferredID-value =3D name-addr / addr-spec > > Since there are no header-field-parameters, semicolon is not problematic, but > comma is a problem, as is question mark. > > Dale > > _______________________________________________ > 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 Thu Jun 16 06:19:22 2016 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 9F69512D5BC for ; Thu, 16 Jun 2016 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 Eu7Vy_PFStCG for ; Thu, 16 Jun 2016 06:19:18 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 8801612D576 for ; Thu, 16 Jun 2016 06:19:18 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id u64so72619020vkf.3 for ; Thu, 16 Jun 2016 06:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O+2xazMlzedXwhMxWobN6WkxdXgfpdNibPUh5UMt68Y=; b=D4KFsdAGeztnGyHoxfTuL1g6Q8uqGOCyujkcsYkauxHfBgE7LHjpURFgGAgSCjqmja mrC9qMMpB5MwP4hwObipTqq6XgD//HAGYcHHoIuyHxTGs76iu+984yUqxyEvsKuYzS94 Pbl2UL4NHrjVsWS9hpxtXV+eV+XIXkFlGdwFedseyae2IcLX29XtbvRSCuS7NAAUw04X fH5rBcqz5X+8V5RJCz+j1j007R5/RFSWMbUalNuUWepkuXKdA1fmjZh9dBKtfCnZbt0K bCwLcgmPOzJVAltI/YUxl5DD62gs2cqj2Q6sazxMKKGd7FltzAAb3TwCy6CnMMo0UrZC DlPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O+2xazMlzedXwhMxWobN6WkxdXgfpdNibPUh5UMt68Y=; b=Lk/LU1vqQMI3DnoTTab15dMR8ZeGOAvH8Uy/3mOJ6C1QD5rdrYlx9bfirmEpdZWkqX GoqcjZ/y6tmTUQVLvQw/LWg08ecaUCMqZ9SLZGLjWn6eOOuahQsgUmDBEJKw9yguroSS qMse/hHHe+s+6ZAoZadcx9A8SIvRub3nVMXhscSsdYVqjx0nAbH2DTfXBhsjrbSVJwiE O/r72+R2rzWNsYLWfprOZpVxSnr+HVvAaJRR7QGujq6gmvi3P6wMb+YhgI2iOpT+gW+a xMWRNRdvYByq6OBv6Us64ontPscD+wiG3U4lPZKkNmILQjFw+nUDQLw6lZxmTTm7NkiL ucrQ== X-Gm-Message-State: ALyK8tKoNnx74pCuNUXpKSu9mFMRu65oWf0sg1rEStL3uy3ZrYm2Bqvb0AHRWqKWREv35YseK1my8zEI6DZIDg== X-Received: by 10.31.13.70 with SMTP id 67mr2013828vkn.9.1466083157589; Thu, 16 Jun 2016 06:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 16 Jun 2016 06:19:16 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Thu, 16 Jun 2016 09:19:16 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a114413c0d1c3bf0535651593 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:19:20 -0000 --001a114413c0d1c3bf0535651593 Content-Type: text/plain; charset=UTF-8 The attributes I provided are examples of attributes that might be provided in an access token; it was not meant to include all the attributes for this use case, because my intention was not to focus on conference server, but to discuss the idea in general. The following could be used with the conference factory to request a conference focus: The INVITE sent to the conference factory could include a token that has a *conference-type* attribute which could take one of the following values: *audio, video, webconference, audio-webconference, or video-webconference*. The conference factory will then issue a *conference uri* for the requested conference type, assuming the token is valid. If the *conference-type* attribute is missing, then the request would be rejected. Is that what you are looking for? Regards, Rifaat On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon wrote: > >> >> In that case, if you could furnish a use case with attributes that would >> be carried in a SIP iNVITE that are actually salient to the authorization >> of that particular SIP request, we'd be getting a lot closer to common >> ground. >> >> > An obvious example would be an INVITE with a token sent to a conference > factory to authorize the creation of a focus. > > > We're still talking past each other. My point above was that the two > attributes you specified - constraints on conference size and media types - > have nothing to do with the authorization of the INVITE carrying those > attributes. Like, unless the conference size permitted is 0, then the > INVITE that creates an ad hoc conference and connects you to its bridge is > not going to be rejected by the focus on the basis of that conference size > attribute. If the maximum conference size were 0, the AuthZ service just > wouldn't attach a token to an INVITE as it would never be allowed to start > a conference. Same goes for media types. > > Instead, what your two attributes constrain is what happens after the > conference is created: when ten users try to dial in to a conference with a > permitted size of nine, say. That tenth INVITE would get rejected - not the > conference-forming INVITE that you propose would carry the token. That's > why what you're proposing is overloading the INVITE to tunnel conference > policy constraints to the focus. I mean, maybe that's a problem space worth > investigating, though I suspect there are good reasons why RFC4353 > specified that conference policy is not manipulated with SIP - mostly > because the semantics of manipulating conference policy probably don't map > well onto dialog-forming SIP requests. But I think that conference policy > provisioning problem space would be pretty far from where we started in > this discussion. > > Let me reiterate what I wrote in my previous mail, which I quote here at > the top: "furnish a use case with attributes that would be carried in a SIP > iNVITE that are actually salient to the authorization of that particular > SIP request." Again: "that particular SIP request." Not later transactions > in some broader context in which the original user agent probably isn't > even an endpoint. > > The Authorization header in SIP, for example, is actually used by the UAS > to make a decision about whether or not to authorize the request in which > the header appears. The token that you propose a SIP INVITE would carry in > this case is not used by the relying party to make a decision about whether > or not that INVITE is authorized. That's why I believe this conference > policy issue is a different problem space entirely from figuring out how to > implement attribute-based authorization for SIP requests. > > Jon Peterson > Neustar, Inc. > > > Regards, > Rifaat > > --001a114413c0d1c3bf0535651593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The attributes I provided are examples of attributes = that might be provided in an access token; it was not meant to include all = the attributes for this use case, because my intention was not to focus on = conference server, but to discuss the idea in general.

=
The following could be used with the conference factory to reques= t a conference focus:
The INVITE sent to the conference factory c= ould include a token that has a conference-type attribute which coul= d take one of the following values: audio, video, webconference, audio-w= ebconference, or video-webconference.
The conference factory = will then issue a conference uri for the requested conference type, = assuming the token is valid. If the conference-type attribute is mis= sing, then the request would be rejected.

Is= that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed,= Jun 15, 2016 at 5:06 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was tha= t the two attributes you specified - constraints on conference size and med= ia types - have nothing to do with the authorization of the INVITE carrying= those attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

--001a114413c0d1c3bf0535651593-- From nobody Thu Jun 16 09:25:50 2016 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 0B62D12D7D2 for ; Thu, 16 Jun 2016 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 aZBwdElbwVZU for ; Thu, 16 Jun 2016 09:25:48 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 3C85712D7CF for ; Thu, 16 Jun 2016 09:25:48 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-02v.sys.comcast.net with SMTP id Da6kb6jOtBAXODa70b1af4; Thu, 16 Jun 2016 16:25:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466094346; bh=RqIA+bBwu9JJWjCkY0zneY8JnYxbgt+ILPpT9YH9rQ4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=M5R3Q6HDZYyHQ2F6woUm6LiYLo5doYPhNDHMqDIbpo3ciahl+6m5JUs6Et5l8tsK8 SdobiwW34EHi0R1HiNBUxcR7bRq1mfa6GzLulSuUNHQmKerjYDR1SSGr1f50D1ekN8 fpWtXZrnaKE8Caok3TeuZHZOs1e28yw0Iy4539g2JD5ELuRREzrSNwx+qTdiSV6XHa A3OSEod7ul5vkMBZK1reqM8hzzWpIp50U4vtzp4dpCukvjwzq7zxkr9n/20KjfDvJb 6ArFmxy7cXm0iYByRKps09uUL8D5bka4z7CcIye1PJa/5mjiarYu7k2eFOMXYNymaw aW3v7jlV3zYgw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-12v.sys.comcast.net with comcast id 7URl1t00U1nMCLR01URmkM; Thu, 16 Jun 2016 16:25:46 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5GGPjk4019481; Thu, 16 Jun 2016 12:25:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5GGPiM8019478; Thu, 16 Jun 2016 12:25:44 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Drage\, Keith \(Nokia - GB\)" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF16C12@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@nokia.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Jun 2016 12:25:44 -0400 Message-ID: <87lh25rth3.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 16:25:49 -0000 "Drage, Keith (Nokia - GB)" writes: > A reminder that RFC 3325 is an informational document, so I am not > sure whether a standards track document can update an informational > document. Anyone able to clarify? I searched, but I couldn't find much guidance on what update documents are or are not allowed to do in the BCP directory. Dale From nobody Thu Jun 16 12:39:21 2016 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 4D71912DBE1 for ; Thu, 16 Jun 2016 12:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 SmoT3_8NYk22 for ; Thu, 16 Jun 2016 12:39:18 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 69D0312DBE0 for ; Thu, 16 Jun 2016 12:39:18 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-07v.sys.comcast.net with SMTP id Dd49bpDGAa1eGDd8HbHyuL; Thu, 16 Jun 2016 19:39:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466105957; bh=zMaV3bDeo3h5c9IM4RX6aJE835K4LweVyg9kKexbZI8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FanA9Rm8KONK+g1wyT6ldz9Rdw14Ce+A/oFyDOi/4Iz00D0JlCZtN/WyNoL6GlMam RzojZxUeL6EJu/wb8ageCTzJ8MtNZXSIKGigwu13EY8poTe7DBHBHgk76zjXF0BgaH AhxC3d4QaovNEEploQiP1OUdoy1txWcTGIuwE9ZagowpekQkdq+rfgviP3/biAGkHb OKY4ivTbCppPxtPliSgGbmmGeuLUFCA2SU0QMpwg1ibUAMms7eCQCb2J6pR94JRkMI AhrI2hKIXj5caFnnlLGJKdf9zySgeAFzY94jG31u5i/ah00kRrHA2dgp0vORmxPqj1 R8jGDMw6fdJeA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-08v.sys.comcast.net with comcast id 7XfF1t0151nMCLR01XfG9B; Thu, 16 Jun 2016 19:39:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5GJdFlM007404 for ; Thu, 16 Jun 2016 15:39:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5GJdEcS007401; Thu, 16 Jun 2016 15:39:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Jun 2016 15:39:14 -0400 Message-ID: <87a8iksz31.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Are 'alert' URNs being used? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 19:39:19 -0000 Does anyone know of implementations of the 'alert' URNs in Alert-Info (RFC 7462) beyond the use of urn:alert:service:call-waiting by 3GPP? Dale From nobody Fri Jun 17 05:57:08 2016 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 3C62612D532 for ; Fri, 17 Jun 2016 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xfrP71OV0FoL for ; Fri, 17 Jun 2016 05:57:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 05E1612D516 for ; Fri, 17 Jun 2016 05:57:04 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 8F7454281; Fri, 17 Jun 2016 14:57:00 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2016 14:57:00 +0200 Message-Id: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 12:57:07 -0000 Friends, I=E2=80=99ve tried to summarise my thoughts and the feedback in a = presentation format. = http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the= -sip-protocol Feedback is welcome and I=E2=80=99ll try to keep it up-to-date. At this point, it=E2=80=99s not very well organised, as I have some more = digging to do in regards of SIP client certs and some other examples of TLS usage in related = solutions like MSRP, SIMPLE etc It seems we are here: - We have no agreement to remove SIPS: as a uri scheme, but agree that = we need to be able to use TLS without it - There are some thoughts on how to do this without outbound = (half-outbound) - We have not enough ideas on how to replace the SIPS requirement that = all hops to the UA requiers TLS - We have no suggestion on how to verify this I return to S/MIME - what happened to that? With the new thoughts about certificate handling used in WebRTC for DTLS = and in Email for S/MIME using Dane there may be some ideas to look at. Personally I think removing SIPS: from the SIP set of standards would be = a good thing. :-) /O= From nobody Fri Jun 17 06:15:57 2016 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 BC8A812D583 for ; Fri, 17 Jun 2016 06:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 XHLtzgzGGiKe for ; Fri, 17 Jun 2016 06:15:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 13CF512D572 for ; Fri, 17 Jun 2016 06:15:53 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id CFAA94281; Fri, 17 Jun 2016 15:15:50 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2016 15:15:50 +0200 Message-Id: To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:15:56 -0000 http://www.slideshare.net/oej/sip-half-outbound-random-notes Trying to summarize - am I right? - No one seems to oppose some work in this area - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop doing = alternatives As this is not an update to the core protocols, it seems like any draft = that can come out of this discussion needs to go to dispatch and follow any route that group suggests. Anyone that wants to join me in writing a first draft to start the = process? /O= From nobody Fri Jun 17 06:18:22 2016 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 8FAF212D63B for ; Fri, 17 Jun 2016 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 i81mRtGkAlNJ for ; Fri, 17 Jun 2016 06:18:18 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 9999A12D0CC for ; Fri, 17 Jun 2016 06:18:18 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d185so115382985vkg.0 for ; Fri, 17 Jun 2016 06:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EOqDyKULBb5hGSNDmrvdj2fixg5SccWeYF6gvpS8ZC8=; b=Wo/8U/dTPc9vIDmE089+lYYD8xhczcE/fVyiaMZhgo5PXT+w6RlmzjaJDWWg4a3HxP LsMhXT7H6fYnppM7B+DGnkUmZ3kKLUa6A9xyhfajBhEoWWtdAlvR6l/l+oa8/YecK8mf VB6Z81M4lfpHzzJ3G1oEFVRRXaHzHsvvUczX0fjWY1daICyxaR89f+4uBUFzx5st5EaN MQKSnL1zAmGgPl9R+BJ7+rfm+z8ioQeINXXPz/n7aamxSYx8JIFtkFmwHev4664Q9oM+ gbrkmflZP8pwn5R0Vni/ARr8Jfn/zwU6S43PZnRR68p2Hn2+aPA6XRm/iwif7P/1u1pt f7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EOqDyKULBb5hGSNDmrvdj2fixg5SccWeYF6gvpS8ZC8=; b=Q1fcbfjZmPvTBStY/XiRMDek+045/eBohY8UXY8NrE2GM4fVZHCKaBgvH7rtgxQClh NxkbMjdAR3H/Uayg2JPhP24mjUtBH9/EU8ywg9VNLE+cDyOBVc6e978DbRIFcCRhgQPC 5xjS5O9pbhHoMfoMsb3mm1wWJTWxgdbxEmTm6lc0tsBZMbUAONA9FG2kL2s/2mfurtjh SMv/wjXr4tCWQ7N5WL3N5VsEinBiYLGs4syK/dgbO+NZ17maJVI9dueX8QRh6v/qw2hC ha7bhat1L4qVjIpGrduKycceDRCjVE6n5lL9h4FgZ4MMXFJOeBQsYFefebJ0d8TvU+MC 282g== X-Gm-Message-State: ALyK8tIqOoXi/obLEs0S4uULOsGnqBwhfIQe3unHdtxeTor3gA1FW8mvk1YoNdTSJXKVZ8lZILc+UWowEFNrxA== X-Received: by 10.31.166.72 with SMTP id p69mr1123817vke.14.1466169495868; Fri, 17 Jun 2016 06:18:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Fri, 17 Jun 2016 06:18:14 -0700 (PDT) In-Reply-To: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> From: Rifaat Shekh-Yusef Date: Fri, 17 Jun 2016 09:18:14 -0400 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a1142d222fda7aa0535792fed Archived-At: Cc: SIPCORE Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:18:20 -0000 --001a1142d222fda7aa0535792fed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2016 at 8:57 AM, Olle E. Johansson wrote: > Friends, > > I=E2=80=99ve tried to summarise my thoughts and the feedback in a present= ation > format. > > http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-th= e-sip-protocol > > Feedback is welcome and I=E2=80=99ll try to keep it up-to-date. > > At this point, it=E2=80=99s not very well organised, as I have some more = digging > to do in regards > of SIP client certs and some other examples of TLS usage in related > solutions like > MSRP, SIMPLE etc > > It seems we are here: > > - We have no agreement to remove SIPS: as a uri scheme, but agree that we > need > to be able to use TLS without it > RFC5630 covers the use of SIP scheme over TLS already: https://tools.ietf.org/html/rfc5630#section-3.1.3 > > - There are some thoughts on how to do this without outbound > (half-outbound) > > - We have not enough ideas on how to replace the SIPS requirement that al= l > hops to the UA requiers TLS > Why would you do that? Regards, Rifaat > - We have no suggestion on how to verify this > > I return to S/MIME - what happened to that? > > With the new thoughts about certificate handling used in WebRTC for DTLS > and in Email for S/MIME using Dane > there may be some ideas to look at. > > Personally I think removing SIPS: from the SIP set of standards would be = a > good thing. :-) > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1142d222fda7aa0535792fed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 8:57 AM, Olle E. Johansson &l= t;oej@edvina.net>= ; wrote:
Friends,

I=E2=80=99ve tried to summarise my thoughts and the feedback in a presentat= ion format.
http://www.sl= ideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol<= /a>

Feedback is welcome and I=E2=80=99ll try to keep it up-to-date.

At this point, it=E2=80=99s not very well organised, as I have some more di= gging to do in regards
of SIP client certs and some other examples of TLS usage in related solutio= ns like
MSRP, SIMPLE etc

It seems we are here:

- We have no agreement to remove SIPS: as a uri scheme, but agree that we n= eed
=C2=A0 to be able to use TLS without it

RFC5630 covers the use of SIP scheme over TLS already:

=C2=A0
=

- There are some thoughts on how to do this without outbound (half-outbound= )

- We have not enough ideas on how to replace the SIPS requirement that all<= br> =C2=A0 =C2=A0hops to the UA requiers TLS

Why would you do that?

Regards,
=C2=A0= Rifaat
=C2=A0


- We have no suggestion on how to verify this

I return to S/MIME - what happened to that?

With the new thoughts about certificate handling used in WebRTC for DTLS an= d in Email for S/MIME using Dane
there may be some ideas to look at.

Personally I think removing SIPS: from the SIP set of standards would be a = good thing. :-)

/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a1142d222fda7aa0535792fed-- From nobody Fri Jun 17 06:19:11 2016 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 4610E12D5CD for ; Fri, 17 Jun 2016 06:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 JreNIT0CI-A7 for ; Fri, 17 Jun 2016 06:19:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C4212D647 for ; Fri, 17 Jun 2016 06:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/bGeLuj2EGhPvT6TnrOdO1IydZa7zDGmvFrHuqI18Ok=; b=m5O8H38Wx4XWpvAzQ2Uv9FSifizxQl9nIp8G92zAXJAplwrQ/Seb2jz31ZPVk7pVKpsv6MbpYiw4CG9mKm3LBMolXYEMyHm0em+7vmXQ18dPDyrB/fGKPWoNxpNoxmPkP5OZdrXYnB+bppihzQLTG0ZLKhWaWBNd/+BUK1nxtC8= Received: from DM2PR0301MB1213.namprd03.prod.outlook.com (10.160.219.154) by DM2PR0301MB1215.namprd03.prod.outlook.com (10.160.219.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 17 Jun 2016 13:18:44 +0000 Received: from DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) by DM2PR0301MB1213.namprd03.prod.outlook.com ([10.160.219.154]) with mapi id 15.01.0517.014; Fri, 17 Jun 2016 13:18:44 +0000 From: "Neelakantan, Neel" To: "Olle E. Johansson" , SIPCORE Thread-Topic: [sipcore] Half outbound Thread-Index: AQHRyJplEfAAoCR6k0ygogyei4KZv5/tpEpw Date: Fri, 17 Jun 2016 13:18:44 +0000 Message-ID: References: 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=nneelakantan@sonusnet.com; x-originating-ip: [12.171.83.97] x-ms-office365-filtering-correlation-id: 82bdcd37-1390-4107-71cd-08d396b1e8bf x-microsoft-exchange-diagnostics: 1; DM2PR0301MB1215; 6:bP+cEnAyKSj/KoFFUCVL84qVKFMC2JDr60P0NhE0G8ZKE9imthiVD7Fa36IYxgHomRucPHZ9izpsC8b+Q1AuH2dmx+yF9q8hmvDCC1tPxEmdbSUjbHvYvyg++9MK/58KoromYT7JpWkjTqb/zbtKcT2qijDqgc0/G/J3nRDvJ73HUXxiJVCLq/b11Blr8AhytK5iKg5ecP0kdG3q0AAxNbXUUxWq7Ru+Xp6iuX7NDJEv2Pkbk+iqhryQ6Kax1MH8p2tW3w0wO0LM5FmyZMNFu5RyHw7NrvoB4Ja3vtQzDdI=; 5:m3NlFfnNVY/OyYvIXLPgl3OTpQXQek0l0uTsASX+QttA0h9SeG0vzZVgTrawpcIgMilPHa3KZVJnc5aGy6yKXjAv6uobNOdukrGMqTwJQBOl7BclpVZHuwTB64n8d8j2Vy3afWlIQve/WbuXyspPfA==; 24:JHLxh/qA1CnG65+esJK2EUoo/LJt93o9HtPWF9t3Z15bztPyTFYYNFRC2W1PEGV1MFw70xLArIm/MluxpUn3YIQDrxut/6mIUDnfwpnUCVw=; 7:SUSi33MfJ3NV8FPKBbR0SVzmtYYS9InHE4iVrf9fFhyHIksQb3JxxKtdJTkqlaL7IX33qRhOJZ8wXP+j5qmtdXiqblIe0FTLH9GgTYnWyIdvVmgtaLEZCVTKR/iVsihcQZvNL5ZWBa3D2luFkCTR5iAOOg2+QZhwx7DVvAEFjco77UMFKYvuuC7e+BGac7hAyXMJY1tJqO/ZhKQ5C9IwSg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1215; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(178636050973902)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR0301MB1215; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1215; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(86362001)(5004730100002)(9686002)(68736007)(5008740100001)(15975445007)(1720100001)(101416001)(6116002)(586003)(92566002)(3846002)(54356999)(2900100001)(77096005)(33656002)(76576001)(3280700002)(102836003)(3660700001)(105586002)(122556002)(2950100001)(99286002)(81156014)(97736004)(87936001)(50986999)(8676002)(10400500002)(106356001)(106116001)(81166006)(2906002)(5001770100001)(8936002)(5002640100001)(5003600100002)(107886002)(76176999)(74316001)(189998001)(11100500001)(19580395003)(66066001)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0301MB1215; H:DM2PR0301MB1213.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 13:18:44.6409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1215 Archived-At: Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:19:09 -0000 T2xsZSwNCg0KSSBhbSB3aWxsaW5nIHRvIGhlbHAgYW5kIGNvbnRyaWJ1dGUgaW4gdGhpcy4gIEkg a25vdyB3ZSBkaXNjdXNzZWQgdGhpcyBpbiBTSVAgRm9ydW1zIHdoZW4gdGhlIG91dGJvdW5kIGNh bWUgdXAuDQoNClRoYW5rcywNCk5lZWwuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE9sbGUgRS4NCj4gSm9oYW5zc29uDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAx NiA4OjE2IEFNDQo+IFRvOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KPiBDYzogT2xsZSBF IEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+DQo+IFN1YmplY3Q6IFtzaXBjb3JlXSBIYWxmIG91 dGJvdW5kDQo+IA0KPiBodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L29lai9zaXAtaGFsZi1vdXRi b3VuZC1yYW5kb20tbm90ZXMNCj4gDQo+IFRyeWluZyB0byBzdW1tYXJpemUgLSBhbSBJIHJpZ2h0 Pw0KPiANCj4gLSBObyBvbmUgc2VlbXMgdG8gb3Bwb3NlIHNvbWUgd29yayBpbiB0aGlzIGFyZWEN Cj4gLSBObyBvbmUgc2VlbXMgdG8gc2F5IOKAnFlheeKAnSBmb3IgT3V0Ym91bmQgYW5kIHN0b3Ag ZG9pbmcgYWx0ZXJuYXRpdmVzDQo+IA0KPiBBcyB0aGlzIGlzIG5vdCBhbiB1cGRhdGUgdG8gdGhl IGNvcmUgcHJvdG9jb2xzLCBpdCBzZWVtcyBsaWtlIGFueSBkcmFmdCB0aGF0IGNhbg0KPiBjb21l IG91dCBvZiB0aGlzIGRpc2N1c3Npb24gbmVlZHMgdG8gZ28gdG8gZGlzcGF0Y2ggYW5kIGZvbGxv dyBhbnkgcm91dGUgdGhhdA0KPiBncm91cCBzdWdnZXN0cy4NCj4gDQo+IEFueW9uZSB0aGF0IHdh bnRzIHRvIGpvaW4gbWUgaW4gd3JpdGluZyBhIGZpcnN0IGRyYWZ0IHRvIHN0YXJ0IHRoZSBwcm9j ZXNzPw0KPiANCj4gL08NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Fri Jun 17 06:21:29 2016 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 4B57D12D5AF for ; Fri, 17 Jun 2016 06:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mXGbSAvEhKpK for ; Fri, 17 Jun 2016 06:21:14 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 C362712B01E for ; Fri, 17 Jun 2016 06:21:10 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 31EC84281; Fri, 17 Jun 2016 15:21:08 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9EB03A36-8757-4C0C-B663-8F7C58D965F2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 17 Jun 2016 15:21:07 +0200 Message-Id: <3F3412F2-F1EC-4158-B194-4FD6706F07D5@edvina.net> References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:21:22 -0000 --Apple-Mail=_9EB03A36-8757-4C0C-B663-8F7C58D965F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Jun 2016, at 15:18, Rifaat Shekh-Yusef = wrote: >=20 >=20 >=20 > On Fri, Jun 17, 2016 at 8:57 AM, Olle E. Johansson > wrote: > Friends, >=20 > I=E2=80=99ve tried to summarise my thoughts and the feedback in a = presentation format. > = http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the= -sip-protocol = >=20 > Feedback is welcome and I=E2=80=99ll try to keep it up-to-date. >=20 > At this point, it=E2=80=99s not very well organised, as I have some = more digging to do in regards > of SIP client certs and some other examples of TLS usage in related = solutions like > MSRP, SIMPLE etc >=20 > It seems we are here: >=20 > - We have no agreement to remove SIPS: as a uri scheme, but agree that = we need > to be able to use TLS without it >=20 > RFC5630 covers the use of SIP scheme over TLS already: > https://tools.ietf.org/html/rfc5630#section-3.1.3 = >=20 And leave some gaps that I documented in my presentation=E2=80=A6 As I = say on one slide this RFC points to RFC 5626 but no one seems to want to implement it so = it=E2=80=99s not the solution. Check the presentation! > =20 >=20 > - There are some thoughts on how to do this without outbound = (half-outbound) >=20 > - We have not enough ideas on how to replace the SIPS requirement that = all > hops to the UA requiers TLS >=20 > Why would you do that? Well, some people on this list pointed that out as a feature they wanted when I said that I just wanted to remove it so I=E2=80=99ll let them = respond. /O >=20 > Regards, > Rifaat > =20 >=20 >=20 > - We have no suggestion on how to verify this >=20 > I return to S/MIME - what happened to that? >=20 > With the new thoughts about certificate handling used in WebRTC for = DTLS and in Email for S/MIME using Dane > there may be some ideas to look at. >=20 > Personally I think removing SIPS: from the SIP set of standards would = be a good thing. :-) >=20 > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = >=20 --Apple-Mail=_9EB03A36-8757-4C0C-B663-8F7C58D965F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 17 Jun 2016, at 15:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:



On Fri, Jun 17, 2016 at 8:57 AM, Olle E. Johansson = <oej@edvina.net> wrote:
Friends,

I=E2=80=99ve tried to summarise my thoughts and the feedback in a = presentation format.
http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-u= sage-in-the-sip-protocol

Feedback is welcome and I=E2=80=99ll try to keep it up-to-date.

At this point, it=E2=80=99s not very well organised, as I have some more = digging to do in regards
of SIP client certs and some other examples of TLS usage in related = solutions like
MSRP, SIMPLE etc

It seems we are here:

- We have no agreement to remove SIPS: as a uri scheme, but agree that = we need
  to be able to use TLS without it

RFC5630 covers the use = of SIP scheme over TLS already:
https://tools.ietf.org/html/rfc5630#section-3.1.3

And leave some = gaps that I documented in my presentation=E2=80=A6 As I say on one = slide
this RFC points to RFC 5626 but no one seems to want to = implement it so it=E2=80=99s not
the solution. Check the = presentation!

 

- There are some thoughts on how to do this without outbound = (half-outbound)

- We have not enough ideas on how to replace the SIPS requirement that = all
   hops to the UA requiers TLS

Why would you do = that?
Well, some people on = this list pointed that out as a feature they wanted
when I = said that I just wanted to remove it so I=E2=80=99ll let them = respond.

/O

Regards,
 Rifaat
 


- We have no suggestion on how to verify this

I return to S/MIME - what happened to that?

With the new thoughts about certificate handling used in WebRTC for DTLS = and in Email for S/MIME using Dane
there may be some ideas to look at.

Personally I think removing SIPS: from the SIP set of standards would be = a good thing. :-)

/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


= --Apple-Mail=_9EB03A36-8757-4C0C-B663-8F7C58D965F2-- From nobody Fri Jun 17 06:22:39 2016 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 4BE0C12D647 for ; Fri, 17 Jun 2016 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ENtTQr7QMH-Z for ; Fri, 17 Jun 2016 06:22:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 CE99C12D63B for ; Fri, 17 Jun 2016 06:22:32 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 2148B4281; Fri, 17 Jun 2016 15:22:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 17 Jun 2016 15:22:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CE27993-B42C-4C3D-86E0-B2529236CE31@edvina.net> References: To: "Neelakantan, Neel" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:22:38 -0000 > On 17 Jun 2016, at 15:18, Neelakantan, Neel = wrote: >=20 > Olle, >=20 > I am willing to help and contribute in this. I know we discussed this = in SIP Forums when the outbound came up. Great! Welcome to the team :-) I=E2=80=99ll start with writing an outline and committing to github and = we=E2=80=99ll can take it from there. Cheers, /O >=20 > Thanks, > Neel. >=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. >> Johansson >> Sent: Friday, June 17, 2016 8:16 AM >> To: SIPCORE >> Cc: Olle E Johansson >> Subject: [sipcore] Half outbound >>=20 >> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>=20 >> Trying to summarize - am I right? >>=20 >> - No one seems to oppose some work in this area >> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop = doing alternatives >>=20 >> As this is not an update to the core protocols, it seems like any = draft that can >> come out of this discussion needs to go to dispatch and follow any = route that >> group suggests. >>=20 >> Anyone that wants to join me in writing a first draft to start the = process? >>=20 >> /O >> _______________________________________________ >> 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 Fri Jun 17 07:48:41 2016 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 938AB12D62F for ; Fri, 17 Jun 2016 07:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 VAiWT7Hr2ux6 for ; Fri, 17 Jun 2016 07:48:38 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 7444312D625 for ; Fri, 17 Jun 2016 07:48:38 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-06v.sys.comcast.net with SMTP id Dv3Mbt70hE8zeDv4Xb4n9F; Fri, 17 Jun 2016 14:48:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466174917; bh=1XjU1bx0CyrBoIiqf3HI2FBMWAX5nsflZJFYKrSSfJs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=b2FNywyDshn6DtKdhGZ0Esj7DMXbcfBg03SKj21MgpY96HaGTN+NbuZ26MmjYFysl FvoIa4JB9MURuIeNGSUMnQxEWS/JVx+J6MZ5bF9TW0GBEA5h2KIMfItmr8P9datXd1 E9gB7prCapALGB9e88gH0UA5p2XmYQxz9NNfAg8s8apS1UnHTTCJ4wqbebt+jyJhDW fxbvNpOO+f2oCKCzq7mw1arsSa+U4Uol01jCsx2VLAvsEUdQsyf3mNjVFdiQ5bXDlh ZEjPt8FM+xsQuMiALXMXQzHJvUvhy9AVE7t5dNslM7S3ZqMIqIM2IAcqsUUVkyGm6a r4unaZp8eUChw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with comcast id 7qod1t0093KdFy101qodKJ; Fri, 17 Jun 2016 14:48:37 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> Date: Fri, 17 Jun 2016 10:48:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:48:39 -0000 On 6/17/16 9:15 AM, Olle E. Johansson wrote: > http://www.slideshare.net/oej/sip-half-outbound-random-notes > > Trying to summarize - am I right? > > - No one seems to oppose some work in this area > - No one seems to say “Yay†for Outbound and stop doing alternatives > > As this is not an update to the core protocols, it seems like any draft that > can come out of this discussion needs to go to dispatch and follow > any route that group suggests. > > Anyone that wants to join me in writing a first draft to start the process? I thought we had concluded that half-outbound isn't needed, because the existing outbound may be used with a single connection/flow if properly configured. If people still don't want to do it, then maybe what we need is research into why. Thanks, Paul From nobody Fri Jun 17 07:52:28 2016 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 995DB12D625 for ; Fri, 17 Jun 2016 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EwVuj9cI5NXc for ; Fri, 17 Jun 2016 07:52:24 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 740A412D518 for ; Fri, 17 Jun 2016 07:52:23 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 26D2A4281; Fri, 17 Jun 2016 16:52:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> Date: Fri, 17 Jun 2016 16:52:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:52:26 -0000 > On 17 Jun 2016, at 16:48, Paul Kyzivat wrote: >=20 > On 6/17/16 9:15 AM, Olle E. Johansson wrote: >> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>=20 >> Trying to summarize - am I right? >>=20 >> - No one seems to oppose some work in this area >> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop = doing alternatives >>=20 >> As this is not an update to the core protocols, it seems like any = draft that >> can come out of this discussion needs to go to dispatch and follow >> any route that group suggests. >>=20 >> Anyone that wants to join me in writing a first draft to start the = process? >=20 > I thought we had concluded that half-outbound isn't needed, because = the existing outbound may be used with a single connection/flow if = properly configured. >=20 > If people still don't want to do it, then maybe what we need is = research into why. The SIPconnect team more or less refused to add outbound regardless on how many times I pointed at it as the only solution. I hope they can = answer! So let=E2=80=99s take another round :-) /O= From nobody Fri Jun 17 08:13:48 2016 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 2180212D751 for ; Fri, 17 Jun 2016 08:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 jC-T_iGImECz for ; Fri, 17 Jun 2016 08:13:46 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 D4D7E12D756 for ; Fri, 17 Jun 2016 08:13:45 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-02v.sys.comcast.net with SMTP id DvOpbnt0DQRyhDvSrbm5m5; Fri, 17 Jun 2016 15:13:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466176425; bh=uf+OfiN2wOzXTu2rjXL6HHPd+PvWB4XeLat4zQ+ehjQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jPjv1oQg3sDXyLiVTILs6AaziLCIIHjdGUlTK5i3Z2r3SHIISPNxZ+GulTJNfq1uA 6mgNKfYCpWbmBM24gnF98GjkgUy0/bLSuapSbtkTastkHgpNU3r8I/nYR3nr+SBvQ7 rvYiXYIaIO4Q4fCEOOl5KB13cuiqscvc+8nA3aSGf2yY+Zm2txlYK2u7KCDPDGSSAV ga0faiMCAJTa+BCNK5qfBQipVRYrhK1Jb/MyqokcFzuoXuvb5AwzXb7pHRE5fgBUXb zXA/IEiQRQzbG6CAz3W8S/nUhtcG6yEhrnavQwxswV0qe9OlA+vjlgz5WpPyfxqquX 7SNc4DqXfZO+g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id 7rDk1t00J3KdFy101rDkAh; Fri, 17 Jun 2016 15:13:44 +0000 To: sipcore@ietf.org References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> From: Paul Kyzivat Message-ID: <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> Date: Fri, 17 Jun 2016 11:13:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:13:47 -0000 On 6/17/16 8:57 AM, Olle E. Johansson wrote: > Friends, > > I’ve tried to summarise my thoughts and the feedback in a presentation format. > http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol > > Feedback is welcome and I’ll try to keep it up-to-date. > > At this point, it’s not very well organised, as I have some more digging to do in regards > of SIP client certs and some other examples of TLS usage in related solutions like > MSRP, SIMPLE etc > > It seems we are here: > > - We have no agreement to remove SIPS: as a uri scheme, but agree that we need > to be able to use TLS without it > > - There are some thoughts on how to do this without outbound (half-outbound) > > - We have not enough ideas on how to replace the SIPS requirement that all > hops to the UA requiers TLS > > - We have no suggestion on how to verify this > > I return to S/MIME - what happened to that? I remember back when I was first learning about SIP (with RFC2543) I spent some effort trying to understand the S/MIME stuff. I was never able to figure out how it could possibly work. After asking a few questions I finally stopped thinking about it. > With the new thoughts about certificate handling used in WebRTC for DTLS and in Email for S/MIME using Dane > there may be some ideas to look at. > > Personally I think removing SIPS: from the SIP set of standards would be a good thing. :-) The one thing SIPS offers is a way to indicate a *requirement* by the UAC for security on every hop. Unfortunately the realization of that hasn't worked out. I suppose the same thing could be achieved using Require and Proxy-Require. But still there is no obvious way to verify it has been honored. I think I recall at one time there was a proposal for how to establish an e2e TLS association. But nothing came of it. Maybe something could be worked out that way. For instance, if webrtc can succeed in establishing an e2d DTLS connection for media, why can't the same be done for sip? And if it can be done for media, why couldn't it also be done for signaling? For instance, use SIP to establish a session, with ICE used to establish an RTCWEB data channel. Then do further signaling over the data channel. Use that to establish other media streams. Thanks, Paul From nobody Fri Jun 17 08:25:40 2016 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 1017A12D733 for ; Fri, 17 Jun 2016 08:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 r7HXBZ1g6Dx2 for ; Fri, 17 Jun 2016 08:25:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 3536712D590 for ; Fri, 17 Jun 2016 08:25:35 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 51EB74281; Fri, 17 Jun 2016 17:25:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> Date: Fri, 17 Jun 2016 17:25:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:25:39 -0000 > On 17 Jun 2016, at 17:13, Paul Kyzivat wrote: >=20 > On 6/17/16 8:57 AM, Olle E. Johansson wrote: >> Friends, >>=20 >> I=E2=80=99ve tried to summarise my thoughts and the feedback in a = presentation format. >> = http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the= -sip-protocol >>=20 >> Feedback is welcome and I=E2=80=99ll try to keep it up-to-date. >>=20 >> At this point, it=E2=80=99s not very well organised, as I have some = more digging to do in regards >> of SIP client certs and some other examples of TLS usage in related = solutions like >> MSRP, SIMPLE etc >>=20 >> It seems we are here: >>=20 >> - We have no agreement to remove SIPS: as a uri scheme, but agree = that we need >> to be able to use TLS without it >>=20 >> - There are some thoughts on how to do this without outbound = (half-outbound) >>=20 >> - We have not enough ideas on how to replace the SIPS requirement = that all >> hops to the UA requiers TLS >>=20 >> - We have no suggestion on how to verify this >>=20 >> I return to S/MIME - what happened to that? >=20 > I remember back when I was first learning about SIP (with RFC2543) I = spent some effort trying to understand the S/MIME stuff. I was never = able to figure out how it could possibly work. After asking a few = questions I finally stopped thinking about it. Oh yeah, I=E2=80=99ve been struggling with RSA lawyers and understanding = it a long time ago. The difference is that there=E2=80=99s a bit more code out there now and a little - although not much - more = experience in usage of it e-mail. >=20 >> With the new thoughts about certificate handling used in WebRTC for = DTLS and in Email for S/MIME using Dane >> there may be some ideas to look at. >>=20 >> Personally I think removing SIPS: from the SIP set of standards would = be a good thing. :-) >=20 > The one thing SIPS offers is a way to indicate a *requirement* by the = UAC for security on every hop. Unfortunately the realization of that = hasn't worked out. >=20 > I suppose the same thing could be achieved using Require and = Proxy-Require. But still there is no obvious way to verify it has been = honored. >=20 > I think I recall at one time there was a proposal for how to establish = an e2e TLS association. But nothing came of it. Yep, some sort of websocket-like upgrade - I do remember there was such = a draft too. > Maybe something could be worked out that way. For instance, if webrtc = can succeed in establishing an e2d DTLS connection for media, why can't = the same be done for sip? And if it can be done for media, why couldn't = it also be done for signaling? >=20 > For instance, use SIP to establish a session, with ICE used to = establish an RTCWEB data channel. Then do further signaling over the = data channel. Use that to establish other media streams. That=E2=80=99s one idea :-) /O= From nobody Fri Jun 17 13:03:27 2016 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 346B312DA84 for ; Fri, 17 Jun 2016 13:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 907BuJvwTacy for ; Fri, 17 Jun 2016 13:03:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA1A12DA83 for ; Fri, 17 Jun 2016 13:03:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-0e-5764578a850c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.B0.12516.A8754675; Fri, 17 Jun 2016 22:03:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Fri, 17 Jun 2016 22:03:22 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIPS must die - or at least be able to live without Thread-Index: AQHRyJfD3vwKK9cBGEOmycQtMMsMCZ/tovWAgABxkuA= Date: Fri, 17 Jun 2016 20:03:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> In-Reply-To: <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7mW5XeEq4Qe9pQ4sVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYeekJS8E7joo9l98zNTBe4Ohi5OSQEDCR 2NZ7mAnCFpO4cG89WxcjF4eQwBFGidZDN9ghnCWMEjtffmbsYuTgYBOwkOj+pw3SICIQKHF1 yQRmEFtYwEti56pJrBBxb4lJMxYyQthWEn+mr2QBsVkEVCVmvXgPVsMr4Cvx81QLWFxIoFhi 2d+/YPWcAg4S71tOgdmMQAd9P7UG7DhmAXGJW0/mQx0qILFkz3lmCFtU4uXjf6wQtpLEiu2X wM5kFtCUWL9LH6JVUWJK90N2iLWCEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRWjaHFqcXFu upGxXmpRZnJxcX6eXl5qySZGYIwc3PJbdwfj6teOhxgFOBiVeHgTFJPDhVgTy4orcw8xSnAw K4nwmgenhAvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpg 1HuqL5bmkP5TZLncwwUfve0d/gjGyc/ZazHdYMOtSb/6fd7/yeJe9+XjXa9pHz9xKrZUb7wn n/A5QS6F6bHYvwnn/sk5vGSQn9bk0O5wXs9XOkcoLlMq+sNNz9vPGo6sOpf0aafO/PXPCg8t uXj/7uZG6Z6nwpxXL29YFcvJKX2w8v45l4SHZkosxRmJhlrMRcWJADJrgziNAgAA Archived-At: Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:03:26 -0000 SGksDQoNCi4uLg0KDQo+SSB0aGluayBJIHJlY2FsbCBhdCBvbmUgdGltZSB0aGVyZSB3YXMgYSBw cm9wb3NhbCBmb3IgaG93IHRvIGVzdGFibGlzaCBhbiBlMmUgVExTIGFzc29jaWF0aW9uLiBCdXQg bm90aGluZyBjYW1lIG9mIGl0LiBNYXliZSBzb21ldGhpbmcgY291bGQgYmUgd29ya2VkIG91dCB0 aGF0IHdheS4gRm9yIGluc3RhbmNlLCBpZiB3ZWJydGMgY2FuIHN1Y2NlZWQgaW4gPmVzdGFibGlz aGluZyBhbiBlMmQgRFRMUyBjb25uZWN0aW9uIGZvciBtZWRpYSwgd2h5IGNhbid0IHRoZSBzYW1l IGJlIGRvbmUgZm9yIHNpcD8gDQo+QW5kIGlmIGl0IGNhbiBiZSBkb25lIGZvciBtZWRpYSwgd2h5 IGNvdWxkbid0IGl0IGFsc28gYmUgZG9uZSBmb3Igc2lnbmFsaW5nPw0KDQpCZWNhdXNlIFNJUCBp cyBub3QgYW4gZTJlIHByb3RvY29sOiBpbnRlcm1lZGlhcmllcyBuZWVkIHRvIGhhdmUgYWNjZXNz IChyZWFkOiBkZWNyeXB0KSBzaWduYWxsaW5nIGluZm9ybWF0aW9uLg0KDQo+Rm9yIGluc3RhbmNl LCB1c2UgU0lQIHRvIGVzdGFibGlzaCBhIHNlc3Npb24sIHdpdGggSUNFIHVzZWQgdG8gZXN0YWJs aXNoIGFuIFJUQ1dFQiBkYXRhIGNoYW5uZWwuIFRoZW4gZG8gZnVydGhlciBzaWduYWxpbmcgb3Zl ciB0aGUgZGF0YSBjaGFubmVsLiANCj5Vc2UgdGhhdCB0byBlc3RhYmxpc2ggb3RoZXIgbWVkaWEg c3RyZWFtcy4NCg0KLi4ub3IsIGFzIGl0IGl0J3MgYWxzbyBrbm93biBhczogSC4yNDUgOikNCg0K QnV0LCB0aGUgcXVlc3Rpb24gaXMgV0hBVCBpbmZvcm1hdGlvbiB5b3Ugd2FudCB0byBwcm90ZWN0 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Fri Jun 17 14:39:24 2016 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 BAE9312DB39 for ; Fri, 17 Jun 2016 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 9lwD_etzA0Z1 for ; Fri, 17 Jun 2016 14:39:21 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 A504C12B077 for ; Fri, 17 Jun 2016 14:39:21 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-02v.sys.comcast.net with SMTP id E1TSboOpPQRyhE1U0bnMaQ; Fri, 17 Jun 2016 21:39:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466199560; bh=PSLypSUXdEqy82+HLNxHfCizFyiPp97sFHgub9szyzE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LiBHesWheK/n+asQX+5wS0+aSB10B0zWGxfU6x764sfqLB0x7M6qLPogTryw7J5VQ eNPxzaP29USqG55xAgIVmTltfNCIPgcgZKeS8hmMZUeJGBpnyUGQ0/7E8G3CZV+1tD 6tDiJSPPvLUNC4AiDq5Wd6HRScbOHrVjasVxwyVyvVnhVVYEPC0xyGj43YcB52khfS gf1djDCmP3EEM7MU8akfvONz8ZcP8O/hUCr2KREoohj07uZcjDwYZsXOEfnrI58gGS afdCR2kiCdGNsruId02dWFW7Mie3fATc6SsBYxC3nuejsm7dzAIc/XSTP982teBQhy 2n4tyZ2odkDSQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id 7xfL1t0073KdFy101xfLuc; Fri, 17 Jun 2016 21:39:20 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <92ed556a-ab85-de3f-c1a0-d61469fb2282@alum.mit.edu> Date: Fri, 17 Jun 2016 17:39:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 21:39:23 -0000 On 6/17/16 4:03 PM, Christer Holmberg wrote: > Hi, > > ... > >> I think I recall at one time there was a proposal for how to establish an e2e TLS association. But nothing came of it. Maybe something could be worked out that way. For instance, if webrtc can succeed in >establishing an e2d DTLS connection for media, why can't the same be done for sip? >> And if it can be done for media, why couldn't it also be done for signaling? > > Because SIP is not an e2e protocol: intermediaries need to have access (read: decrypt) signalling information. > >> For instance, use SIP to establish a session, with ICE used to establish an RTCWEB data channel. Then do further signaling over the data channel. >> Use that to establish other media streams. > > ...or, as it it's also known as: H.245 :) > > But, the question is WHAT information you want to protect. Yes, that is important to decide. Normal users most likely want media protected, at least. Next, I suppose many people would like "call metadata" protected. Almost nothing we will do will protect that. I guess SIP over TOR perhaps. (Though it seems TOR isn't safe either.) Thanks, Paul From nobody Fri Jun 17 15:08:25 2016 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 8B01512DBA7 for ; Fri, 17 Jun 2016 15:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 NCe0F0Zf5Y38 for ; Fri, 17 Jun 2016 15:08:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 B65CF12D9EE for ; Fri, 17 Jun 2016 15:08:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f30so80215960ioj.2 for ; Fri, 17 Jun 2016 15:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Dq04jl8wkinFlsS1HasFNyO2+7OgCAKn5dQkg2A+u4=; b=I6t851J2K/MxcENDODo45cnQNVBK2Eu5jrvcFb+XC53xqo2gwgHMaZKsCopvQM4NT5 NLqH+u5brfVzpPBSskQAuC8egeVNY4MR2SeDyPmo9dXP8Sh2upthHa/4bOpMfEg6cRKG X1/21EjJ13Gpx9raiC2Nl5c2kliHQYPFXlzJCqTZQsN79epjk7q3KHgJNqLyRDILxbQu lcOpqtcEF5sDryEG/JdzeL7yBK4U2rA6hgUW3Cq4Pzg602/iwzdm4CyR0TWpgktj/vJB exqIM5HdiKfG35uovsFU8fBzaKtnVqMYGi1ZcMw9Av1hT9PFE1fzM/xz2X8PDKGiXZwF RbEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Dq04jl8wkinFlsS1HasFNyO2+7OgCAKn5dQkg2A+u4=; b=NpCXtk5Uwrgn7+aBbbXmjb3f+QaJml25+GMHkxKw2d8fHhSUBqJa5w/5XBXDe6BcI3 LSxpa/Ztl7CaMUfs31K2Y9XIl4aTNiCh8AslrCTP/GzHlyKVaaZMx5VKYr93toe3+oGP dNZTOrxRCxIvAvyPLRK+Jsjtia4ETQuaqHq3cbptoFFaB7grFWJucX9zgDvvSWUcxzF0 6qqeSfGJo80WnO/0RMeLD6wTlGUzmU5AN6WjE9bVVzGGIWTYlRCOpyYPo9Y5eAber7+L gGOUdA1XCw7+zdIWV4jo/b/mWoVo0UDXKSWorHIMdyW9bb7pi+5qHhkIVz/22KQgNKsV FxEA== X-Gm-Message-State: ALyK8tIwueFb294woBZhAbtHuAwxMw9DEct8z9yjaB05zIQ6UvDqCYLYIJr/Z6UQS8NXKA== X-Received: by 10.107.142.11 with SMTP id q11mr6776168iod.193.1466201301085; Fri, 17 Jun 2016 15:08:21 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id a23sm416035itd.2.2016.06.17.15.08.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jun 2016 15:08:20 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id e5so3320021ith.0 for ; Fri, 17 Jun 2016 15:08:20 -0700 (PDT) X-Received: by 10.36.184.130 with SMTP id m124mr1064502ite.95.1466201300182; Fri, 17 Jun 2016 15:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Fri, 17 Jun 2016 15:08:19 -0700 (PDT) In-Reply-To: <92ed556a-ab85-de3f-c1a0-d61469fb2282@alum.mit.edu> References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> <92ed556a-ab85-de3f-c1a0-d61469fb2282@alum.mit.edu> From: Roman Shpount Date: Fri, 17 Jun 2016 18:08:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c114246aaaf9e0535809788 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 22:08:23 -0000 --94eb2c114246aaaf9e0535809788 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 5:39 PM, Paul Kyzivat wrote: > On 6/17/16 4:03 PM, Christer Holmberg wrote: > >> But, the question is WHAT information you want to protect. >> > > Yes, that is important to decide. > > Normal users most likely want media protected, at least. > The best way to protect media is DTLS-SRTP. The media will be protected even if signaling is compromised (as long as it is correctly authenticated). > Next, I suppose many people would like "call metadata" protected. Almost > nothing we will do will protect that. I guess SIP over TOR perhaps. (Though > it seems TOR isn't safe either.) > There is also the issue of end-to-end authentication of signaling. It is not only important to protect the information but it is also important to make sure that session description and the user identity was not tempered with. In some sense this problem is exactly the same as identity issues which are part of WebRTC. I guess the most important issue I see with this discussion is definition of scope. SIP can be the end point communication protocol or federation protocol between service providers. SIP over TLS with certificate based authentication is perfect for communicating between different services located on public IP (federation). It will work quite well if you need to terminate a SIP call to a PSTN provider or accept a PSTN call to a VoIP service. SIP is a horrible protocol for end points with or without TLS. It tries to enable the operations of 12-button VoIP phones, but manages to be broken for almost any feature. Security, NAT traversal, presence, distinctive ringing, MWI, etc all seems to be broken in almost all practical implementations. I hope these ancient phones will die together with SIP on the end points and get replaced by WebRTC based implementations. I just do not see why would anybody at this point build a new SIP end point device instead of making something browser based. At this point I would use a push service, such as FireBase Messaging ( https://firebase.google.com/docs/cloud-messaging/) instead of registrations to notify about incoming calls or presence related updates, WebRTC for real time media and dynamic HTML for UI. This will be easier to build, will provide better feature set, scale better, be a lot more secure and use less power on mobile. Regards, _____________ Roman Shpount --94eb2c114246aaaf9e0535809788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 17, 2016 at 5:39 PM, Pa= ul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 6/17/16 4:03 PM, Christer Holmberg wrote:
But, the question is WHAT= information you want to protect.

Yes, that is important to decide.

Normal users most likely want media protected, at least.

The best way to protect media is DTLS-SRTP. The media wil= l be protected even if signaling is compromised (as long as it is correctly= authenticated).
=C2=A0
Next, I suppose many people would like "call metadata&qu= ot; protected. Almost nothing we will do will protect that. I guess SIP ove= r TOR perhaps. (Though it seems TOR isn't safe either.)

There is also the issue of end-to-end authentication o= f signaling. It is not only important to protect the information but it is = also important to make sure that session description and the user identity = was not tempered with. In some sense this problem is exactly the same as id= entity issues which are part of WebRTC.

I guess th= e most important issue I see with this discussion is definition of scope. S= IP can be the end point communication protocol or federation protocol betwe= en service providers. SIP over TLS with certificate based authentication is= perfect for communicating between different services located on public IP = (federation). It will work quite well if you need to terminate a SIP call t= o a PSTN provider or accept a PSTN call to a VoIP service.

SIP is a horrible protocol for end points with or without TLS. It = tries to enable the operations of 12-button VoIP phones, but manages to be = broken for almost any feature. Security, NAT traversal, presence, distincti= ve ringing, MWI, etc all seems to be broken in almost all practical impleme= ntations. I hope these ancient phones will die together with SIP on the end= points and get replaced by WebRTC based implementations. I just do not see= why would anybody at this point build a new SIP end point device instead o= f making something browser based. At this point I would use a push service,= such as FireBase Messaging (https://firebase.google.com/docs/cloud-messaging/) inst= ead of registrations to notify about incoming calls or presence related upd= ates, WebRTC for real time media and dynamic HTML for UI. This will be easi= er to build, will provide better feature set, scale better, be a lot more s= ecure and use less power on mobile.

Regards,
=
____= _________
Roman Shpount
=C2=A0
--94eb2c114246aaaf9e0535809788-- From nobody Fri Jun 17 20:31:46 2016 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 004E612DC1D for ; Fri, 17 Jun 2016 20:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 p79ysr2vqV_J for ; Fri, 17 Jun 2016 20:31:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680069.outbound.protection.outlook.com [40.107.68.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603B412DC28 for ; Fri, 17 Jun 2016 20:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pKx0rgWuEFEYucaJdVo2ct89hB4NJCNfAERiLN06mqU=; b=rPkmBaUiUwkAw0+X9t+S+L5re3Vzgx8TDEf2x/f4sfCjGWtsuqoYFIXLijds6Z/yfC0bjVhLZsmwyyJT1tF/JR+8sJReP0FDE8InXCJN5cw1/VZlI/mmUeFpvG1CtH0hx7BzlBTI6m5T2f5asdAXBWE8PMyc1EaQHZdD9OD2wT4= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Sat, 18 Jun 2016 03:31:40 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0517.014; Sat, 18 Jun 2016 03:31:40 +0000 From: "Asveren, Tolga" To: Roman Shpount , Paul Kyzivat Thread-Topic: [sipcore] SIPS must die - or at least be able to live without Thread-Index: AQHRyJfG8lMrajuHgUK9f+QTK2egpZ/txHyAgABQ7QCAACL3G4AAWL3A Date: Sat, 18 Jun 2016 03:31:40 +0000 Message-ID: References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> <92ed556a-ab85-de3f-c1a0-d61469fb2282@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=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 20d7f16a-8ff4-44f6-5335-08d397290fb6 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 6:MfwRwQFTJ9u1wXQ/IrkSRFsNm/iPhNszDe+gienbmPoMGITcge9uEa/M7v6kUjwrsMQfzF4ntlZEE/Lv4KI29/OAA0NXcIY2VVCznS0nufdkEwaMnpfAhphhkZ51Ch3EBzPj2mwOfETVym6iHjgBv99czYLm05aM6w44yjBmVvUa0mkMOuvHPVoJKZRht02ttTZ2n/ukiGBIpqzXZMRd65sPPgTRGRQw3rCJGpgb9iHltWN2TOeoSidfeXDc2dH2zisFCsk27dfI+RGJzxp0is4fXs1CuzFt+mUjYTw1tYA=; 5:BuXa0AQ+UdSGDhVe8Td8MDHnDiGJQUfVWKLqfrdx1efJ3Htw9Ok7lLyQHRoY3716wWyAIae3irsY3q+jNMYGAvf7sQHEWlUGX2/lxEL+hwgaoEj2uTHoxCRQkdOu3AY2dswsjFOkrM9VzeFpJoMZvw==; 24:RNUazl5Cbx96esMij2KD6V48lMrIkiLefNE9LJyggYKi2FRlSocCmX48SYiW4zsvZFk+7Ifam4FJLSDeTgdN0PhVv7CLQ/6sSfO44Y868c8=; 7:w9x2ma6QWqwSBEfPGdrEH6LG+yfDox7u0kJha7roOVQs7EvWRDpsIakJIyAFM5ENj5iHQbTvtq7PnnRoM4CPqRON/e++n0XnVZYJpwkRDnmnvxkgc4vmynbGKBpwsXiRdwG3dhealpLue5KzPGJIAP9OxFiQ9y6BuGmgi2hRBNCtPynZ2oHzRGEq2TnVxJyacONZwAk4sXiAkvl7JoXWkQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(199003)(24454002)(189002)(93886004)(77096005)(5002640100001)(15975445007)(2906002)(50986999)(189998001)(68736007)(2900100001)(4326007)(8936002)(2950100001)(99286002)(54356999)(76176999)(19617315012)(7906002)(5004730100002)(92566002)(19300405004)(19580405001)(106116001)(105586002)(19625215002)(74316001)(122556002)(7846002)(19580395003)(2171001)(3280700002)(33656002)(3660700001)(101416001)(66066001)(9686002)(8676002)(81166006)(5003600100002)(76576001)(586003)(81156014)(6116002)(3846002)(102836003)(790700001)(11100500001)(87936001)(10400500002)(106356001)(86362001)(19609705001)(16236675004)(97736004)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15513BFBF9C9674F4CDCD526B2280SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2016 03:31:40.1051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 03:31:45 -0000 --_000_SN1PR0301MB15513BFBF9C9674F4CDCD526B2280SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcVGhlcmUgaXMgYWxzbyB0aGUgaXNzdWUgb2YgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiBv ZiBzaWduYWxpbmcuIEl0IGlzIG5vdCBvbmx5IGltcG9ydGFudCB0byBwcm90ZWN0IHRoZSBpbmZv cm1hdGlvbiBidXQgaXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gbWFrZSBzdXJlIHRoYXQgc2Vzc2lv biBkZXNjcmlwdGlvbiBhbmQgdGhlIHVzZXIgaWRlbnRpdHkgd2FzIG5vdCB0ZW1wZXJlZCB3aXRo LiBJbiBzb21lIHNlbnNlIHRoaXMgcHJvYmxlbSBpcyBleGFjdGx5IHRoZSBzYW1lIGFzIGlkZW50 aXR5IGlzc3VlcyB3aGljaCBhcmUgcGFydCBvZiBXZWJSVEMu4oCdDQoNCllvdSBoaXQgdGhlIG5h aWwgb24gdGhlIGhlYWQuIFRoZSBhc3N1bXB0aW9uIG9mIOKAnHNlY3VyZSBlbmQtdG8tZW5kIHNp Z25hbGluZ+KAnSAodXNlIG9mIGZpbmdlcnByaW50IGF0dHJpYnV0ZSkgIGlzIGEgcHJlcmVxdWlz aXRlIGZvciBEVExTLVNSVFAgdG8gYmUgbWVhbmluZ2Z1bCBmcm9tIHNlY3VyaXR5IHBlcnNwZWN0 aXZlLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogRnJpZGF5 LCBKdW5lIDE3LCAyMDE2IDY6MDggUE0NClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0u bWl0LmVkdT4NCkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNJ UFMgbXVzdCBkaWUgLSBvciBhdCBsZWFzdCBiZSBhYmxlIHRvIGxpdmUgd2l0aG91dA0KDQpPbiBG cmksIEp1biAxNywgMjAxNiBhdCA1OjM5IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0u bWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQpPbiA2LzE3LzE2 IDQ6MDMgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KQnV0LCB0aGUgcXVlc3Rpb24gaXMg V0hBVCBpbmZvcm1hdGlvbiB5b3Ugd2FudCB0byBwcm90ZWN0Lg0KDQpZZXMsIHRoYXQgaXMgaW1w b3J0YW50IHRvIGRlY2lkZS4NCg0KTm9ybWFsIHVzZXJzIG1vc3QgbGlrZWx5IHdhbnQgbWVkaWEg cHJvdGVjdGVkLCBhdCBsZWFzdC4NCg0KVGhlIGJlc3Qgd2F5IHRvIHByb3RlY3QgbWVkaWEgaXMg RFRMUy1TUlRQLiBUaGUgbWVkaWEgd2lsbCBiZSBwcm90ZWN0ZWQgZXZlbiBpZiBzaWduYWxpbmcg aXMgY29tcHJvbWlzZWQgKGFzIGxvbmcgYXMgaXQgaXMgY29ycmVjdGx5IGF1dGhlbnRpY2F0ZWQp Lg0KDQpOZXh0LCBJIHN1cHBvc2UgbWFueSBwZW9wbGUgd291bGQgbGlrZSAiY2FsbCBtZXRhZGF0 YSIgcHJvdGVjdGVkLiBBbG1vc3Qgbm90aGluZyB3ZSB3aWxsIGRvIHdpbGwgcHJvdGVjdCB0aGF0 LiBJIGd1ZXNzIFNJUCBvdmVyIFRPUiBwZXJoYXBzLiAoVGhvdWdoIGl0IHNlZW1zIFRPUiBpc24n dCBzYWZlIGVpdGhlci4pDQoNClRoZXJlIGlzIGFsc28gdGhlIGlzc3VlIG9mIGVuZC10by1lbmQg YXV0aGVudGljYXRpb24gb2Ygc2lnbmFsaW5nLiBJdCBpcyBub3Qgb25seSBpbXBvcnRhbnQgdG8g cHJvdGVjdCB0aGUgaW5mb3JtYXRpb24gYnV0IGl0IGlzIGFsc28gaW1wb3J0YW50IHRvIG1ha2Ug c3VyZSB0aGF0IHNlc3Npb24gZGVzY3JpcHRpb24gYW5kIHRoZSB1c2VyIGlkZW50aXR5IHdhcyBu b3QgdGVtcGVyZWQgd2l0aC4gSW4gc29tZSBzZW5zZSB0aGlzIHByb2JsZW0gaXMgZXhhY3RseSB0 aGUgc2FtZSBhcyBpZGVudGl0eSBpc3N1ZXMgd2hpY2ggYXJlIHBhcnQgb2YgV2ViUlRDLg0KDQpJ IGd1ZXNzIHRoZSBtb3N0IGltcG9ydGFudCBpc3N1ZSBJIHNlZSB3aXRoIHRoaXMgZGlzY3Vzc2lv biBpcyBkZWZpbml0aW9uIG9mIHNjb3BlLiBTSVAgY2FuIGJlIHRoZSBlbmQgcG9pbnQgY29tbXVu aWNhdGlvbiBwcm90b2NvbCBvciBmZWRlcmF0aW9uIHByb3RvY29sIGJldHdlZW4gc2VydmljZSBw cm92aWRlcnMuIFNJUCBvdmVyIFRMUyB3aXRoIGNlcnRpZmljYXRlIGJhc2VkIGF1dGhlbnRpY2F0 aW9uIGlzIHBlcmZlY3QgZm9yIGNvbW11bmljYXRpbmcgYmV0d2VlbiBkaWZmZXJlbnQgc2Vydmlj ZXMgbG9jYXRlZCBvbiBwdWJsaWMgSVAgKGZlZGVyYXRpb24pLiBJdCB3aWxsIHdvcmsgcXVpdGUg d2VsbCBpZiB5b3UgbmVlZCB0byB0ZXJtaW5hdGUgYSBTSVAgY2FsbCB0byBhIFBTVE4gcHJvdmlk ZXIgb3IgYWNjZXB0IGEgUFNUTiBjYWxsIHRvIGEgVm9JUCBzZXJ2aWNlLg0KDQpTSVAgaXMgYSBo b3JyaWJsZSBwcm90b2NvbCBmb3IgZW5kIHBvaW50cyB3aXRoIG9yIHdpdGhvdXQgVExTLiBJdCB0 cmllcyB0byBlbmFibGUgdGhlIG9wZXJhdGlvbnMgb2YgMTItYnV0dG9uIFZvSVAgcGhvbmVzLCBi dXQgbWFuYWdlcyB0byBiZSBicm9rZW4gZm9yIGFsbW9zdCBhbnkgZmVhdHVyZS4gU2VjdXJpdHks IE5BVCB0cmF2ZXJzYWwsIHByZXNlbmNlLCBkaXN0aW5jdGl2ZSByaW5naW5nLCBNV0ksIGV0YyBh bGwgc2VlbXMgdG8gYmUgYnJva2VuIGluIGFsbW9zdCBhbGwgcHJhY3RpY2FsIGltcGxlbWVudGF0 aW9ucy4gSSBob3BlIHRoZXNlIGFuY2llbnQgcGhvbmVzIHdpbGwgZGllIHRvZ2V0aGVyIHdpdGgg U0lQIG9uIHRoZSBlbmQgcG9pbnRzIGFuZCBnZXQgcmVwbGFjZWQgYnkgV2ViUlRDIGJhc2VkIGlt cGxlbWVudGF0aW9ucy4gSSBqdXN0IGRvIG5vdCBzZWUgd2h5IHdvdWxkIGFueWJvZHkgYXQgdGhp cyBwb2ludCBidWlsZCBhIG5ldyBTSVAgZW5kIHBvaW50IGRldmljZSBpbnN0ZWFkIG9mIG1ha2lu ZyBzb21ldGhpbmcgYnJvd3NlciBiYXNlZC4gQXQgdGhpcyBwb2ludCBJIHdvdWxkIHVzZSBhIHB1 c2ggc2VydmljZSwgc3VjaCBhcyBGaXJlQmFzZSBNZXNzYWdpbmcgKGh0dHBzOi8vZmlyZWJhc2Uu Z29vZ2xlLmNvbS9kb2NzL2Nsb3VkLW1lc3NhZ2luZy8pIGluc3RlYWQgb2YgcmVnaXN0cmF0aW9u cyB0byBub3RpZnkgYWJvdXQgaW5jb21pbmcgY2FsbHMgb3IgcHJlc2VuY2UgcmVsYXRlZCB1cGRh dGVzLCBXZWJSVEMgZm9yIHJlYWwgdGltZSBtZWRpYSBhbmQgZHluYW1pYyBIVE1MIGZvciBVSS4g VGhpcyB3aWxsIGJlIGVhc2llciB0byBidWlsZCwgd2lsbCBwcm92aWRlIGJldHRlciBmZWF0dXJl IHNldCwgc2NhbGUgYmV0dGVyLCBiZSBhIGxvdCBtb3JlIHNlY3VyZSBhbmQgdXNlIGxlc3MgcG93 ZXIgb24gbW9iaWxlLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0K DQo= --_000_SN1PR0301MB15513BFBF9C9674F4CDCD526B2280SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnFRoZXJlIGlzIGFsc28gdGhlIGlzc3Vl IG9mIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gb2Ygc2lnbmFsaW5nLiBJdCBpcyBub3Qgb25s eSBpbXBvcnRhbnQgdG8gcHJvdGVjdCB0aGUgaW5mb3JtYXRpb24gYnV0IGl0IGlzIGFsc28gaW1w b3J0YW50IHRvIG1ha2Ugc3VyZQ0KIHRoYXQgc2Vzc2lvbiBkZXNjcmlwdGlvbiBhbmQgdGhlIHVz ZXIgaWRlbnRpdHkgd2FzIG5vdCB0ZW1wZXJlZCB3aXRoLiBJbiBzb21lIHNlbnNlIHRoaXMgcHJv YmxlbSBpcyBleGFjdGx5IHRoZSBzYW1lIGFzIGlkZW50aXR5IGlzc3VlcyB3aGljaCBhcmUgcGFy dCBvZiBXZWJSVEMu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Zb3UgaGl0IHRoZSBuYWlsIG9uIHRoZSBoZWFkLiBUaGUgYXNzdW1wdGlvbiBvZiDigJxzZWN1 cmUgZW5kLXRvLWVuZCBzaWduYWxpbmfigJ0gKHVzZSBvZiBmaW5nZXJwcmludCBhdHRyaWJ1dGUp ICZuYnNwO2lzIGEgcHJlcmVxdWlzaXRlIGZvciBEVExTLVNSVFAgdG8gYmUgbWVhbmluZ2Z1bA0K IGZyb20gc2VjdXJpdHkgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g c2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMTcsIDIw MTYgNjowOCBQTTxicj4NCjxiPlRvOjwvYj4gUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVt Lm1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbc2lwY29yZV0gU0lQUyBtdXN0IGRpZSAtIG9yIGF0IGxlYXN0IGJlIGFi bGUgdG8gbGl2ZSB3aXRob3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVuIDE3LCAyMDE2 IGF0IDU6MzkgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNi8xNy8xNiA0OjAzIFBNLCBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CdXQsIHRoZSBxdWVzdGlvbiBpcyBXSEFUIGluZm9ybWF0aW9uIHlvdSB3YW50IHRvIHBy b3RlY3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpZZXMsIHRoYXQgaXMgaW1wb3J0YW50IHRvIGRlY2lkZS48YnI+DQo8YnI+DQpOb3Jt YWwgdXNlcnMgbW9zdCBsaWtlbHkgd2FudCBtZWRpYSBwcm90ZWN0ZWQsIGF0IGxlYXN0LjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGJlc3Qgd2F5IHRvIHByb3RlY3QgbWVkaWEgaXMgRFRMUy1TUlRQLiBUaGUgbWVkaWEgd2ls bCBiZSBwcm90ZWN0ZWQgZXZlbiBpZiBzaWduYWxpbmcgaXMgY29tcHJvbWlzZWQgKGFzIGxvbmcg YXMgaXQgaXMgY29ycmVjdGx5IGF1dGhlbnRpY2F0ZWQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXh0LCBJIHN1cHBvc2UgbWFu eSBwZW9wbGUgd291bGQgbGlrZSAmcXVvdDtjYWxsIG1ldGFkYXRhJnF1b3Q7IHByb3RlY3RlZC4g QWxtb3N0IG5vdGhpbmcgd2Ugd2lsbCBkbyB3aWxsIHByb3RlY3QgdGhhdC4gSSBndWVzcyBTSVAg b3ZlciBUT1IgcGVyaGFwcy4gKFRob3VnaCBpdCBzZWVtcyBUT1IgaXNuJ3Qgc2FmZSBlaXRoZXIu KTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlcmUgaXMgYWxzbyB0aGUgaXNzdWUgb2YgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlv biBvZiBzaWduYWxpbmcuIEl0IGlzIG5vdCBvbmx5IGltcG9ydGFudCB0byBwcm90ZWN0IHRoZSBp bmZvcm1hdGlvbiBidXQgaXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gbWFrZSBzdXJlIHRoYXQgc2Vz c2lvbiBkZXNjcmlwdGlvbiBhbmQgdGhlIHVzZXIgaWRlbnRpdHkgd2FzIG5vdCB0ZW1wZXJlZCB3 aXRoLiBJbiBzb21lIHNlbnNlDQogdGhpcyBwcm9ibGVtIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMg aWRlbnRpdHkgaXNzdWVzIHdoaWNoIGFyZSBwYXJ0IG9mIFdlYlJUQy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyB0aGUgbW9zdCBp bXBvcnRhbnQgaXNzdWUgSSBzZWUgd2l0aCB0aGlzIGRpc2N1c3Npb24gaXMgZGVmaW5pdGlvbiBv ZiBzY29wZS4gU0lQIGNhbiBiZSB0aGUgZW5kIHBvaW50IGNvbW11bmljYXRpb24gcHJvdG9jb2wg b3IgZmVkZXJhdGlvbiBwcm90b2NvbCBiZXR3ZWVuIHNlcnZpY2UgcHJvdmlkZXJzLiBTSVAgb3Zl ciBUTFMgd2l0aCBjZXJ0aWZpY2F0ZSBiYXNlZCBhdXRoZW50aWNhdGlvbiBpcw0KIHBlcmZlY3Qg Zm9yIGNvbW11bmljYXRpbmcgYmV0d2VlbiBkaWZmZXJlbnQgc2VydmljZXMgbG9jYXRlZCBvbiBw dWJsaWMgSVAgKGZlZGVyYXRpb24pLiBJdCB3aWxsIHdvcmsgcXVpdGUgd2VsbCBpZiB5b3UgbmVl ZCB0byB0ZXJtaW5hdGUgYSBTSVAgY2FsbCB0byBhIFBTVE4gcHJvdmlkZXIgb3IgYWNjZXB0IGEg UFNUTiBjYWxsIHRvIGEgVm9JUCBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TSVAgaXMgYSBob3JyaWJsZSBwcm90b2NvbCBmb3Ig ZW5kIHBvaW50cyB3aXRoIG9yIHdpdGhvdXQgVExTLiBJdCB0cmllcyB0byBlbmFibGUgdGhlIG9w ZXJhdGlvbnMgb2YgMTItYnV0dG9uIFZvSVAgcGhvbmVzLCBidXQgbWFuYWdlcyB0byBiZSBicm9r ZW4gZm9yIGFsbW9zdCBhbnkgZmVhdHVyZS4gU2VjdXJpdHksIE5BVCB0cmF2ZXJzYWwsIHByZXNl bmNlLCBkaXN0aW5jdGl2ZSByaW5naW5nLCBNV0ksIGV0Yw0KIGFsbCBzZWVtcyB0byBiZSBicm9r ZW4gaW4gYWxtb3N0IGFsbCBwcmFjdGljYWwgaW1wbGVtZW50YXRpb25zLiBJIGhvcGUgdGhlc2Ug YW5jaWVudCBwaG9uZXMgd2lsbCBkaWUgdG9nZXRoZXIgd2l0aCBTSVAgb24gdGhlIGVuZCBwb2lu dHMgYW5kIGdldCByZXBsYWNlZCBieSBXZWJSVEMgYmFzZWQgaW1wbGVtZW50YXRpb25zLiBJIGp1 c3QgZG8gbm90IHNlZSB3aHkgd291bGQgYW55Ym9keSBhdCB0aGlzIHBvaW50IGJ1aWxkIGEgbmV3 IFNJUCBlbmQNCiBwb2ludCBkZXZpY2UgaW5zdGVhZCBvZiBtYWtpbmcgc29tZXRoaW5nIGJyb3dz ZXIgYmFzZWQuIEF0IHRoaXMgcG9pbnQgSSB3b3VsZCB1c2UgYSBwdXNoIHNlcnZpY2UsIHN1Y2gg YXMgRmlyZUJhc2UgTWVzc2FnaW5nICg8YSBocmVmPSJodHRwczovL2ZpcmViYXNlLmdvb2dsZS5j b20vZG9jcy9jbG91ZC1tZXNzYWdpbmcvIj5odHRwczovL2ZpcmViYXNlLmdvb2dsZS5jb20vZG9j cy9jbG91ZC1tZXNzYWdpbmcvPC9hPikgaW5zdGVhZCBvZiByZWdpc3RyYXRpb25zDQogdG8gbm90 aWZ5IGFib3V0IGluY29taW5nIGNhbGxzIG9yIHByZXNlbmNlIHJlbGF0ZWQgdXBkYXRlcywgV2Vi UlRDIGZvciByZWFsIHRpbWUgbWVkaWEgYW5kIGR5bmFtaWMgSFRNTCBmb3IgVUkuIFRoaXMgd2ls bCBiZSBlYXNpZXIgdG8gYnVpbGQsIHdpbGwgcHJvdmlkZSBiZXR0ZXIgZmVhdHVyZSBzZXQsIHNj YWxlIGJldHRlciwgYmUgYSBsb3QgbW9yZSBzZWN1cmUgYW5kIHVzZSBsZXNzIHBvd2VyIG9uIG1v YmlsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB15513BFBF9C9674F4CDCD526B2280SN1PR0301MB1551_-- From nobody Sat Jun 18 02:03:38 2016 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 2BFFD12B057 for ; Sat, 18 Jun 2016 02:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oTLTz4umgp2m for ; Sat, 18 Jun 2016 02:03:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE45612B02C for ; Sat, 18 Jun 2016 02:03:34 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-1d-57650e643223 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.8C.18043.46E05675; Sat, 18 Jun 2016 11:03:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Sat, 18 Jun 2016 11:02:40 +0200 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat Thread-Topic: [sipcore] Half outbound Thread-Index: AQHRyJpk0Mb2aLTbDEmMWQDBGqREhp/tm+sAgAABCQCAAVDooA== Date: Sat, 18 Jun 2016 09:02:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380DAD06@ESESSMB209.ericsson.se> References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbFdSzeFLzXcYNZ1QYuXqw8xW6zYcIDV 4uuPTWwOzB5/339g8pi2diWrx5IlP5kCmKO4bFJSczLLUov07RK4Mta8aGYr6JOquLb8O3sD 4w7JLkZODgkBE4nGaxeZIWwxiQv31rOB2EICRxglrjXkdzFyAdlLGCXONCxm72Lk4GATsJDo /qcNUiMi4CfR8WU6K4jNLKAp8WjnXiYQW1hARWLd6quMIOUiAqoSCzbzQZQ7Scw7848dxGYB Ci8/dgOsnFfAV2LWyocsEGuXM0qcuKkC0sopYCdxpocTJMwIdNn3U2uYIDaJS9x6Mp8J4mIB iSV7zkNdLyrx8vE/VghbSWLR7c9MIGNALlu/Sx+iVVFiSvdDdoitghInZz5hmcAoNgvJ1FkI HbOQdMxC0rGAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAkHdzy22oH48HnjocYBTgY lXh4HxSlhAuxJpYVV+YeYpTgYFYS4V3MlRouxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4 kEB6YklqdmpqQWoRTJaJg1OqgXFp+hEVQ1/3C/PtlE4/XRYzKz0yeeFtAfdqPt59Ens8ZF8H l63ZVB88V1DGZ+6uWIWWkP79jIc+Sfw+6OK4PfDW882rww/tlHAuCX7u/d/75P9Zv1hW/Vw2 aWH9kqXO69jlJmoyZAZcFDAX/7uDS+Dfi41FMxf+unstffe92B+nGRoLl4S15d9XYinOSDTU Yi4qTgQAz5IoRKACAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 09:03:37 -0000 DQpIaSwNCg0KSWYgeW91IHBsYW4gdG8gYnJpbmcgdGhpcyB0byBESVNQQVRDSCwgSSBzdWdnZXN0 IHRoZSBmb2xsb3dpbmc6DQoNCjEuIERvbid0IGNhbGwgaXQgIkhhbGYgT3V0Ym91bmQiLiBJdCB3 aWxsIHBlb3BsZSBmb2N1cyBvbiB0aGUgbWVjaGFuaXNtIGluc3RlYWQgb2Ygd2hhdCB5b3UgYWN0 dWFsbHkgd2FudCB0byBhY2hpZXZlLg0KDQoyLiBXcml0ZSBkb3duIGEgaGlnaC1sZXZlbCB1c2Ut Y2FzZS9jYWxsIGZsb3cuIFN0YXJ0IGJ5IHNob3dpbmcgcGVvcGxlIHdoYXQgeW91IHdhbnQgdG8g ZG8gLSBub3QgYnkgc2hvd2luZyB3aGF0IGlzIHdyb25nIHdpdGggZXhpc3RpbmcgbWVjaGFuaXNt IChPdXRib3VuZCBldGMpLg0KDQozLiBCYXNlZCBvbiB0aGUgdXNlLWNhc2UvY2FsbC1mbG93LCB3 cml0ZSBkb3duIGEgbGlzdCBvZiByZXF1aXJlbWVudHMuIEFnYWluLCBsZWF2ZSB0aGUgU0lQIHBy b3RvY29sIG1lY2hhbmlzbSBzcGVjaWZpY3Mgb3V0Lg0KDQo0LiBUSEVOIHlvdSBjYW4gc3RhcnQg dGFsa2luZyBhYm91dCBwcm90b2NvbCBtZWNoYW5pc21zLiBZb3UgY2FuIGUuZy4gcGljayB0aGUg cGFydHMgb2Ygb3V0Ym91bmQgdGhhdCB3b3VsZCBmdWxmaWwgdGhlIHJlcXVpcmVtZW50cy4gVEhB VCB5b3UgY2FuIGNhbGwgImhhbGYgb3V0Ym91bmQiLg0KDQo1LiBJZiB5b3UgYXJlIGdvaW5nIHRv IG1ha2Ugc3RhdGVtZW50cyBsaWtlICJwZW9wbGUgZG9uJ3Qgd2FudCB0byBpbXBsZW1lbnQgb3V0 Ym91bmQiLCB5b3UgcmVhbGx5IG5lZWQgc29tZSBqdXN0aWZpY2F0aW9uIGFuZCBiYWNrZ3JvdW5k IGluZm9ybWF0aW9uLiBPdGhlcndpc2UgcGVvcGxlIHdpbGwganVzdCBhc2sgImhvdyBkbyB5b3Ug a25vdyBwZW9wbGUgd2lsbCBpbXBsZW1lbnQgdGhpcyBuZXcgbWVjaGFuaXNtPyIuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog c2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9s bGUgRS4gSm9oYW5zc29uDQpTZW50OiAxNyBKdW5lIDIwMTYgMTc6NTINClRvOiBQYXVsIEt5eml2 YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCkNjOiBzaXBjb3JlQGlldGYub3JnOyBPbGxlIEUg Sm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gSGFsZiBv dXRib3VuZA0KDQoNCj4gT24gMTcgSnVuIDIwMTYsIGF0IDE2OjQ4LCBQYXVsIEt5eml2YXQgPHBr eXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+IA0KPiBPbiA2LzE3LzE2IDk6MTUgQU0sIE9s bGUgRS4gSm9oYW5zc29uIHdyb3RlOg0KPj4gaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWov c2lwLWhhbGYtb3V0Ym91bmQtcmFuZG9tLW5vdGVzDQo+PiANCj4+IFRyeWluZyB0byBzdW1tYXJp emUgLSBhbSBJIHJpZ2h0Pw0KPj4gDQo+PiAtIE5vIG9uZSBzZWVtcyB0byBvcHBvc2Ugc29tZSB3 b3JrIGluIHRoaXMgYXJlYQ0KPj4gLSBObyBvbmUgc2VlbXMgdG8gc2F5IOKAnFlheeKAnSBmb3Ig T3V0Ym91bmQgYW5kIHN0b3AgZG9pbmcgYWx0ZXJuYXRpdmVzDQo+PiANCj4+IEFzIHRoaXMgaXMg bm90IGFuIHVwZGF0ZSB0byB0aGUgY29yZSBwcm90b2NvbHMsIGl0IHNlZW1zIGxpa2UgYW55IA0K Pj4gZHJhZnQgdGhhdCBjYW4gY29tZSBvdXQgb2YgdGhpcyBkaXNjdXNzaW9uIG5lZWRzIHRvIGdv IHRvIGRpc3BhdGNoIA0KPj4gYW5kIGZvbGxvdyBhbnkgcm91dGUgdGhhdCBncm91cCBzdWdnZXN0 cy4NCj4+IA0KPj4gQW55b25lIHRoYXQgd2FudHMgdG8gam9pbiBtZSBpbiB3cml0aW5nIGEgZmly c3QgZHJhZnQgdG8gc3RhcnQgdGhlIHByb2Nlc3M/DQo+IA0KPiBJIHRob3VnaHQgd2UgaGFkIGNv bmNsdWRlZCB0aGF0IGhhbGYtb3V0Ym91bmQgaXNuJ3QgbmVlZGVkLCBiZWNhdXNlIHRoZSBleGlz dGluZyBvdXRib3VuZCBtYXkgYmUgdXNlZCB3aXRoIGEgc2luZ2xlIGNvbm5lY3Rpb24vZmxvdyBp ZiBwcm9wZXJseSBjb25maWd1cmVkLg0KPiANCj4gSWYgcGVvcGxlIHN0aWxsIGRvbid0IHdhbnQg dG8gZG8gaXQsIHRoZW4gbWF5YmUgd2hhdCB3ZSBuZWVkIGlzIHJlc2VhcmNoIGludG8gd2h5Lg0K DQpUaGUgU0lQY29ubmVjdCB0ZWFtIG1vcmUgb3IgbGVzcyByZWZ1c2VkIHRvIGFkZCBvdXRib3Vu ZCByZWdhcmRsZXNzIG9uIGhvdyBtYW55IHRpbWVzIEkgcG9pbnRlZCBhdCBpdCBhcyB0aGUgb25s eSBzb2x1dGlvbi4gSSBob3BlIHRoZXkgY2FuIGFuc3dlciENCg0KU28gbGV04oCZcyB0YWtlIGFu b3RoZXIgcm91bmQgOi0pDQoNCg0KL08NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Sat Jun 18 07:35:19 2016 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 82BB312D195 for ; Sat, 18 Jun 2016 07:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 rPlEDlgxq_KX for ; Sat, 18 Jun 2016 07:35:15 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 95DC612D54C for ; Sat, 18 Jun 2016 07:35:15 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with SMTP id EHJobpD6LQRyhEHL8bohHW; Sat, 18 Jun 2016 14:35:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466260514; bh=x3sMWOVvcVxpqP1vV2UYaNvz7NzYQxNrukvK+/asOJQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WBlk2Qy83v9wFKd1fGvaZWLIklED/4l3ChtqPr9p+NJIrWYZZQItOFcZ0bBConhW5 2q6gxic1217Cj0r4AVXtK2empGfo5NOCj3XBpR/sUMHBN6J5XI54hG0/+wo3L15ZAx adBJ7rQH+z+iygpkxTiJzBmApHMHas/mLU+8jQI9S6j8YuuidMzvfKh14dAovUZNiF tzBUoIxqz/e0vJ9KBBx2aBmD2IYr9kjpLgVPxE8uvss2u6vPlJy/D0U8TAhpFNrK1a 33+JWbZ19cAPEdT1IdDdqhGZiX+aWaHZ2LdVLZI87mvvj3X+ZCqyWR8eBO4B3Qr84v ZooOV45m9773g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id 8EbE1t00F3KdFy101EbEZ4; Sat, 18 Jun 2016 14:35:14 +0000 To: "Asveren, Tolga" , Roman Shpount References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> <92ed556a-ab85-de3f-c1a0-d61469fb2282@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Sat, 18 Jun 2016 10:35:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 14:35:16 -0000 On 6/17/16 11:31 PM, Asveren, Tolga wrote: > “There is also the issue of end-to-end authentication of signaling. It > is not only important to protect the information but it is also > important to make sure that session description and the user identity > was not tempered with. In some sense this problem is exactly the same as > identity issues which are part of WebRTC.†> > > > You hit the nail on the head. The assumption of “secure end-to-end > signaling†(use of fingerprint attribute) is a prerequisite for > DTLS-SRTP to be meaningful from security perspective. For the common telephony use cases it is going to be tricky to figure out what we mean here. It only really works e2e if the calling and called endpoints possess unique credentials known to both. Otherwise, one way or another you are relying on transitive trust. For instance, when I call the Acme Bank, I probably don't know exactly who I am calling or have a credential for them. Every worker at the bank could have the bank's credential that I know, but that is difficult to administer. Otherwise I'm relying on transitive trust between a server at the bank that has those credentials, and the worker's UA. Note that Webrtc relies on transitive trust between the two ends to relay the fingerprints, via at least one server in the middle. And just like with SIP, there is no guarantee that signaling on each leg is protected. Thanks, Paul From nobody Sat Jun 18 12:45:17 2016 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 25A9B12D81E for ; Sat, 18 Jun 2016 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 kkbGO1Pd3wal for ; Sat, 18 Jun 2016 12:45:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 8292812D83F for ; Sat, 18 Jun 2016 12:45:12 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 99223426A; Sat, 18 Jun 2016 21:45:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380DAD06@ESESSMB209.ericsson.se> Date: Sat, 18 Jun 2016 21:45:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77E332EC-C195-4FC1-A45B-50025C3FBA7F@edvina.net> References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B380DAD06@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 19:45:16 -0000 > On 18 Jun 2016, at 11:02, Christer Holmberg = wrote: >=20 >=20 > Hi, >=20 > If you plan to bring this to DISPATCH, I suggest the following: >=20 > 1. Don't call it "Half Outbound". It will people focus on the = mechanism instead of what you actually want to achieve. >=20 > 2. Write down a high-level use-case/call flow. Start by showing people = what you want to do - not by showing what is wrong with existing = mechanism (Outbound etc). >=20 > 3. Based on the use-case/call-flow, write down a list of requirements. = Again, leave the SIP protocol mechanism specifics out. >=20 > 4. THEN you can start talking about protocol mechanisms. You can e.g. = pick the parts of outbound that would fulfil the requirements. THAT you = can call "half outbound". >=20 > 5. If you are going to make statements like "people don't want to = implement outbound", you really need some justification and background = information. Otherwise people will just ask "how do you know people will = implement this new mechanism?=E2=80=9D. Great feedback, thank you! /Olle >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson > Sent: 17 June 2016 17:52 > To: Paul Kyzivat > Cc: sipcore@ietf.org; Olle E Johansson > Subject: Re: [sipcore] Half outbound >=20 >=20 >> On 17 Jun 2016, at 16:48, Paul Kyzivat wrote: >>=20 >> On 6/17/16 9:15 AM, Olle E. Johansson wrote: >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>>=20 >>> Trying to summarize - am I right? >>>=20 >>> - No one seems to oppose some work in this area >>> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop = doing alternatives >>>=20 >>> As this is not an update to the core protocols, it seems like any=20 >>> draft that can come out of this discussion needs to go to dispatch=20= >>> and follow any route that group suggests. >>>=20 >>> Anyone that wants to join me in writing a first draft to start the = process? >>=20 >> I thought we had concluded that half-outbound isn't needed, because = the existing outbound may be used with a single connection/flow if = properly configured. >>=20 >> If people still don't want to do it, then maybe what we need is = research into why. >=20 > The SIPconnect team more or less refused to add outbound regardless on = how many times I pointed at it as the only solution. I hope they can = answer! >=20 > So let=E2=80=99s take another round :-) >=20 >=20 > /O > _______________________________________________ > 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 Sat Jun 18 17:47:47 2016 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 C163212DB26 for ; Sat, 18 Jun 2016 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 f-vMXXPl1vzZ for ; Sat, 18 Jun 2016 17:47:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0664.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460A212DB23 for ; Sat, 18 Jun 2016 17:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u5GYp2tPDQOHqVHUa1oCyEaXSzKdnm9cSmcCgKjQ3Mc=; b=kHxKcXkX9tz3WWTe4hFkMASxgFHLrT8Tn1zWu6Z1fp70A9q/oz/C+AhD4jGuNRVy5xQVyUwKwdUZTqO4wWbg3ndprMHspmcaupqThzr3/II/65Pq+Fgxbqh/FWsu+O6CKndBy3vinWS9CGrSTJYJvsg5SzYAr8I606s4LoC7oEg= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Sun, 19 Jun 2016 00:47:25 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0517.014; Sun, 19 Jun 2016 00:47:25 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , Roman Shpount Thread-Topic: [sipcore] SIPS must die - or at least be able to live without Thread-Index: AQHRyJfG8lMrajuHgUK9f+QTK2egpZ/txHyAgABQ7QCAACL3G4AAWL3AgAC68oCAAJ+NQA== Date: Sun, 19 Jun 2016 00:47:25 +0000 Message-ID: References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> <92ed556a-ab85-de3f-c1a0-d61469fb2282@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=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 290dfd0e-87dd-4251-281c-08d397db487f x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 6:ktzqsymVevoYBRv1j3YWEVT6Um3Gb5FlLehghPZTgFWaIYEMwzYNSeePjOa6BmUc0Lffza9VgNo4L+yn0o4sAzyy0FJ2Tr+x7b9pgUcrXUW+RqpNJr3yzL5mfwb7q500D9/QUm8B8kyC0KLiHqkpcnC1TtFXJ9QoyVGsr/mWoxmPWoycr5bd2hh9YyUFoFxsC/FLRaS6tVy6RikvNRq+0p4yt88g7PVN1EztkpLYBwLH97o3hdF6QJKedUxFKr4OXxJaopxRSIFL19/yQlDCRpKEtLScF4z2FlqeQjoTCF0=; 5:fdsK62mL6V2UPaSoVfH9lUmU08Q+d0P2jCkQX/QXYSvBy310WlNltQf3yWkiy23CD7FuYDr8UgVqMvdFhDiLMA95Kait4F2C4W4DtPVJ/XjjrUL/4h4Eym9AHaZEXvuTgbjY+uXmLQx3PJdzEYrQ2Q==; 24:+dSldDU1sBkGVHe+MHj20uDCpOrpjMKO6vmrIrshNKuCa0vPIq9XDLkHyXkLN3GFmvWA18lGqd4RVd8EO9zmjP3N0yCFVqmnijI1ViuwEEs=; 7:mGisMla3Oz4OapRLCjMKhy/Gj4GQ55fC0EoPct1rYkNq4DFilI4JYcs1M8GaHGNoWnoogqTbLm4U55hiW1q2mtOlWi60o6b1utyyidYJmRiCB8kklGNrAGUnFx10dc9yfdY7jbYAjee7+T6BNou6Vaa92XU7FxTFVq5Iy90zwZ47Q0CnmPd4AHSGJpMnDJgMCwskqA9wO294PuM4zcUXmg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 09781D4C35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(189002)(13464003)(377454003)(74316001)(68736007)(106116001)(106356001)(99286002)(9686002)(105586002)(19580395003)(3280700002)(19580405001)(3660700001)(66066001)(102836003)(586003)(11100500001)(3846002)(5003600100002)(6116002)(54356999)(122556002)(86362001)(50986999)(10400500002)(76176999)(2950100001)(5001770100001)(77096005)(97736004)(189998001)(2900100001)(76576001)(2171001)(87936001)(101416001)(8676002)(8936002)(33656002)(2906002)(92566002)(93886004)(81166006)(81156014)(5004730100002)(4326007)(7846002)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2016 00:47:25.7595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 00:47:46 -0000 SW5saW5lLi4uDQoNClRoYW5rcywNClRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0K PiBTZW50OiBTYXR1cmRheSwgSnVuZSAxOCwgMjAxNiAxMDozNSBBTQ0KPiBUbzogQXN2ZXJlbiwg VG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IFJvbWFuIFNocG91bnQNCj4gPHJvbWFuQHRl bHVyaXguY29tPg0KPiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIFNJUFMgbXVzdCBkaWUgLSBvciBhdCBsZWFzdCBiZSBhYmxlIHRvIGxpdmUgd2l0aG91dA0K PiANCj4gT24gNi8xNy8xNiAxMTozMSBQTSwgQXN2ZXJlbiwgVG9sZ2Egd3JvdGU6DQo+ID4g4oCc VGhlcmUgaXMgYWxzbyB0aGUgaXNzdWUgb2YgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiBvZiBz aWduYWxpbmcuIEl0DQo+ID4gaXMgbm90IG9ubHkgaW1wb3J0YW50IHRvIHByb3RlY3QgdGhlIGlu Zm9ybWF0aW9uIGJ1dCBpdCBpcyBhbHNvDQo+ID4gaW1wb3J0YW50IHRvIG1ha2Ugc3VyZSB0aGF0 IHNlc3Npb24gZGVzY3JpcHRpb24gYW5kIHRoZSB1c2VyIGlkZW50aXR5DQo+ID4gd2FzIG5vdCB0 ZW1wZXJlZCB3aXRoLiBJbiBzb21lIHNlbnNlIHRoaXMgcHJvYmxlbSBpcyBleGFjdGx5IHRoZSBz YW1lDQo+ID4gYXMgaWRlbnRpdHkgaXNzdWVzIHdoaWNoIGFyZSBwYXJ0IG9mIFdlYlJUQy7igJ0N Cj4gPg0KPiA+DQo+ID4NCj4gPiBZb3UgaGl0IHRoZSBuYWlsIG9uIHRoZSBoZWFkLiBUaGUgYXNz dW1wdGlvbiBvZiDigJxzZWN1cmUgZW5kLXRvLWVuZA0KPiA+IHNpZ25hbGluZ+KAnSAodXNlIG9m IGZpbmdlcnByaW50IGF0dHJpYnV0ZSkgIGlzIGEgcHJlcmVxdWlzaXRlIGZvcg0KPiA+IERUTFMt U1JUUCB0byBiZSBtZWFuaW5nZnVsIGZyb20gc2VjdXJpdHkgcGVyc3BlY3RpdmUuDQo+IA0KPiBG b3IgdGhlIGNvbW1vbiB0ZWxlcGhvbnkgdXNlIGNhc2VzIGl0IGlzIGdvaW5nIHRvIGJlIHRyaWNr eSB0byBmaWd1cmUgb3V0DQo+IHdoYXQgd2UgbWVhbiBoZXJlLiBJdCBvbmx5IHJlYWxseSB3b3Jr cyBlMmUgaWYgdGhlIGNhbGxpbmcgYW5kIGNhbGxlZA0KPiBlbmRwb2ludHMgcG9zc2VzcyB1bmlx dWUgY3JlZGVudGlhbHMga25vd24gdG8gYm90aC4gT3RoZXJ3aXNlLCBvbmUgd2F5IG9yDQo+IGFu b3RoZXIgeW91IGFyZSByZWx5aW5nIG9uIHRyYW5zaXRpdmUgdHJ1c3QuDQo+IA0KPiBGb3IgaW5z dGFuY2UsIHdoZW4gSSBjYWxsIHRoZSBBY21lIEJhbmssIEkgcHJvYmFibHkgZG9uJ3Qga25vdyBl eGFjdGx5IHdobyBJDQo+IGFtIGNhbGxpbmcgb3IgaGF2ZSBhIGNyZWRlbnRpYWwgZm9yIHRoZW0u IEV2ZXJ5IHdvcmtlciBhdCB0aGUgYmFuayBjb3VsZCBoYXZlDQo+IHRoZSBiYW5rJ3MgY3JlZGVu dGlhbCB0aGF0IEkga25vdywgYnV0IHRoYXQgaXMgZGlmZmljdWx0IHRvIGFkbWluaXN0ZXIuDQo+ IE90aGVyd2lzZSBJJ20gcmVseWluZyBvbiB0cmFuc2l0aXZlIHRydXN0IGJldHdlZW4gYSBzZXJ2 ZXIgYXQgdGhlIGJhbmsgdGhhdA0KPiBoYXMgdGhvc2UgY3JlZGVudGlhbHMsIGFuZCB0aGUgd29y a2VyJ3MgVUEuDQo+IA0KPiBOb3RlIHRoYXQgV2VicnRjIHJlbGllcyBvbiB0cmFuc2l0aXZlIHRy dXN0IGJldHdlZW4gdGhlIHR3byBlbmRzIHRvIHJlbGF5IHRoZQ0KPiBmaW5nZXJwcmludHMsIHZp YSBhdCBsZWFzdCBvbmUgc2VydmVyIGluIHRoZSBtaWRkbGUuIEFuZCBqdXN0IGxpa2Ugd2l0aCBT SVAsIHRoZXJlDQo+IGlzIG5vIGd1YXJhbnRlZSB0aGF0IHNpZ25hbGluZyBvbiBlYWNoIGxlZyBp cyBwcm90ZWN0ZWQuDQpbVE9MR0FdIEkgZGlkbuKAmXQgbWVhbiB0byBpbXBseSB0aGF0IFdlYlJU QytEVExTL1NSVFAgc29sdmVzIGFueSBwcm9ibGVtLCB0byB0aGUgY29udHJhcnksIGl0IGRvZXMg bm90IGNoYW5nZSBhbnl0aGluZyBmdW5kYW1lbnRhbGx5IGFzIGZhciBhcyB0aGUgbmVlZCBmb3Ig ImVuZC10by1lbmQgc2VjdXJpdHkvaWRlbnRpdHkgdmVyaWZpY2F0aW9uIGZvciBzaWduYWxpbmci IGlzIGNvbmNlcm5lZC4gDQpVc2UvdHJ1c3Qgb24gImZpbmdlcnByaW50IiBkb2VzIG5vdCBuZWNl c3NhcmlseSBpbXBseSAiSWRlbnRpdHkgdmVyaWZpY2F0aW9uIiwgaXQgbWVyZWx5IHNlcnZlcyB0 aGUgcHVycG9zZSBvZiB2ZXJpZnlpbmcgdGhhdCB0aGUgY2VydGlmaWNhdGUgdXNlZCBmb3IgRFRM UyBjb25uZWN0aW9uIGNhbiBiZSB0cnVzdGVkIG9uIC1hcyBpdCBpcyBub3Qgc2lnbmVkIGJ5IGEg Q0EtLiBBbmQgYWN0dWFsbHksIGlmIG9uZSB0YWtlcyB0aGluZ3MgYSBiaXQgbW9yZSB0byBwaGls b3NvcGhpY2FsIGxldmVsLCBpc27igJl0IGV2ZW4gdXNlIG9mIGEgQ0EgImEgdHJhbnNpdGl2ZSB0 cnVzdCByZWxhdGlvbnNoaXAiPyBIb3cgY2FuIEkgKnJlYWxseSogdHJ1c3QgYSBwYXJ0aWN1bGFy IENBPyBUaGV5IG1heSAoYW5kIGFjdHVhbGx5IGl0IGlzIGEgd2VsbC1rbm93biBmYWN0IHRoYXQg dGhleSBhcmUgZG9pbmcgdGhpcyBpbiBjZXJ0YWluIGNvdW50cmllcykgaXNzdWUgY2VydGlmaWNh dGVzIGZvciBDb21wYW55LUEgdG8gYmUgdXNlZCBieSBzb21lIG90aGVyIGVudGl0eS4gSSB0aGlu ayB0aGUgb25seSB3YXkgSSBjYW4gdHJ1c3QgdGhlIGlkZW50aXR5IG9uIGEgY2VydGlmaWNhdGUg aXMgaWYgdGhlcmUgaXMgYSAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gdmVyaWZpZWQgaWRlbnRp dHkvY29ycmVzcG9uZGluZyBDQS4gRm9yIGV4YW1wbGUsIEFsZXggcHJvdmlkZXMgQm9iIGhpcyBw ZXJzb25hbCBDQSBpbmZvcm1hdGlvbiAoYnkgd2hhdGV2ZXIgc2VjdXJlIG1lYW5zLCBtYXliZSBo YW5kaW5nIGl0IG92ZXIgaW4gYSBkaW5lcikgYW5kIEJvYiBrbm93cyB0aGF0IHRoaXMgcGFydGlj dWxhciBDQSBjYW4gYmUgcmVsaWVkIG9uIG9ubHkgdG8gdmVyaWZ5IGlkZW50aXR5PUFsZXguDQpa UlRQIHdvdWxkIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IGJ1dCBzdGlsbCB3b3VsZCBuZWVkIGVu ZC10by1lbmQgc2VjdXJlIHNpZ25hbGluZyBmcm9tIGlkZW50aXR5IHBlcnNwZWN0aXZlLg0KU28s IG92ZXJhbGwsIHRoZSBwcm9ibGVtIGluIGZyb250IG9mIHVzIGlzIGEgdGhvdWdoIG51dCB0byBj cmFjay4uLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCg0K From nobody Sat Jun 18 21:23:12 2016 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 CECFB12DBF1 for ; Sat, 18 Jun 2016 21:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 KwkTrUpmkJm9 for ; Sat, 18 Jun 2016 21:23:09 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 7A4DD12D771 for ; Sat, 18 Jun 2016 21:23:08 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r201so18875238wme.1 for ; Sat, 18 Jun 2016 21:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d5hk/AfgO7v34yLPyitL9nAD/ar2b7BANUuCqIrMkGA=; b=kdwVjdFgMwVOWn7lNFlXm2+ZWRC/E6CdPezxjBGuY7qVtec+fM0WKzOL7Zhq5KwSK1 cnCcDCs0f7KI1lzSNDeFVCyJKvqSwgBXmnOmlQaf31H21e3RRUl7htG0vw21fhfFsrUd nZI05LdeyRKIynwqHOgsB+gk5sI878ykophvmMvUdEIUWMWYdEei2lmQ49fyJEgig+MQ u1Y0w1CLtaF8w0UMGqSFYkoHHkRGdYMVjeadQpCFvCEJDwQepKRT7FmMkrPqtRPypsSx I7FBFMWhxvAXzkGtR1hZix2rtD+4zroW9dW/aPvwBGFpiAEB0g83W6wTElW/N6d/Ml8T kp5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d5hk/AfgO7v34yLPyitL9nAD/ar2b7BANUuCqIrMkGA=; b=iode3qMubdsdX0ODv18srGD3ulEehQRDIwRGg2ZTnZhzU63ehIqmoYTberv4bIh3Iz SE5/FKd4+vVTYPBFkkLOf05y/81m3H0hZCzkWfdM2LqaMv7+VMsQA66EdNqA1nQWOa3b kI07tE5GKKspbERJ1L/R0M8nQioCTGQHuYiBADhPJfxiyvk2uof+kiXkFN1i37MmKANB DNDUwlKPHuDDfllXLSDeOowwfI8PzdAsOaOvHweid73aVhk5ZB/O/tRHFpYbxpcsmmyH Re/SJyK2+1sCmsV+5wpXnGuGJx8x9LPziFK7s2/hMhUBxK6dfkfpKd64b8QJdlAIgA6k jXqw== X-Gm-Message-State: ALyK8tI1jydBXaqVreAD7LUtHMR7pJDIDgCEqlpPf2VvbZMV4Mgg8SPX0PsAJfPAZmNgLqa3NOsZTcFRiROaHA== X-Received: by 10.28.4.140 with SMTP id 134mr5285309wme.91.1466310187010; Sat, 18 Jun 2016 21:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.80.100 with HTTP; Sat, 18 Jun 2016 21:23:06 -0700 (PDT) In-Reply-To: <77E332EC-C195-4FC1-A45B-50025C3FBA7F@edvina.net> References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B380DAD06@ESESSMB209.ericsson.se> <77E332EC-C195-4FC1-A45B-50025C3FBA7F@edvina.net> From: Ranjit Avasarala Date: Sat, 18 Jun 2016 23:23:06 -0500 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a1141efced3d1d1053599f1a6 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 04:23:11 -0000 --001a1141efced3d1d1053599f1a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes I agree - half outbound as a name does not sound appropriate - a more meaningful name is better Regards Ranjit On Sat, Jun 18, 2016 at 2:45 PM, Olle E. Johansson wrote: > > > On 18 Jun 2016, at 11:02, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > > > Hi, > > > > If you plan to bring this to DISPATCH, I suggest the following: > > > > 1. Don't call it "Half Outbound". It will people focus on the mechanism > instead of what you actually want to achieve. > > > > 2. Write down a high-level use-case/call flow. Start by showing people > what you want to do - not by showing what is wrong with existing mechanis= m > (Outbound etc). > > > > 3. Based on the use-case/call-flow, write down a list of requirements. > Again, leave the SIP protocol mechanism specifics out. > > > > 4. THEN you can start talking about protocol mechanisms. You can e.g. > pick the parts of outbound that would fulfil the requirements. THAT you c= an > call "half outbound". > > > > 5. If you are going to make statements like "people don't want to > implement outbound", you really need some justification and background > information. Otherwise people will just ask "how do you know people will > implement this new mechanism?=E2=80=9D. > > Great feedback, thank you! > > /Olle > > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. > Johansson > > Sent: 17 June 2016 17:52 > > To: Paul Kyzivat > > Cc: sipcore@ietf.org; Olle E Johansson > > Subject: Re: [sipcore] Half outbound > > > > > >> On 17 Jun 2016, at 16:48, Paul Kyzivat wrote: > >> > >> On 6/17/16 9:15 AM, Olle E. Johansson wrote: > >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes > >>> > >>> Trying to summarize - am I right? > >>> > >>> - No one seems to oppose some work in this area > >>> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop doi= ng alternatives > >>> > >>> As this is not an update to the core protocols, it seems like any > >>> draft that can come out of this discussion needs to go to dispatch > >>> and follow any route that group suggests. > >>> > >>> Anyone that wants to join me in writing a first draft to start the > process? > >> > >> I thought we had concluded that half-outbound isn't needed, because th= e > existing outbound may be used with a single connection/flow if properly > configured. > >> > >> If people still don't want to do it, then maybe what we need is > research into why. > > > > The SIPconnect team more or less refused to add outbound regardless on > how many times I pointed at it as the only solution. I hope they can answ= er! > > > > So let=E2=80=99s take another round :-) > > > > > > /O > > _______________________________________________ > > 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 > --001a1141efced3d1d1053599f1a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes I agree - half outbound as a name does not sound appro= priate - a more meaningful name is better

Regards
<= div>Ranjit

On Sat, Jun 18, 2016 at 2:45 PM, Olle E. Johansson &= lt;oej@edvina.net&g= t; wrote:

> On 18 Jun 2016, at 11:02, Christer Holmberg <christer.holmberg@ericsson.com> wrote: >
>
> Hi,
>
> If you plan to bring this to DISPATCH, I suggest the following:
>
> 1. Don't call it "Half Outbound". It will people focus o= n the mechanism instead of what you actually want to achieve.
>
> 2. Write down a high-level use-case/call flow. Start by showing people= what you want to do - not by showing what is wrong with existing mechanism= (Outbound etc).
>
> 3. Based on the use-case/call-flow, write down a list of requirements.= Again, leave the SIP protocol mechanism specifics out.
>
> 4. THEN you can start talking about protocol mechanisms. You can e.g. = pick the parts of outbound that would fulfil the requirements. THAT you can= call "half outbound".
>
> 5. If you are going to make statements like "people don't wan= t to implement outbound", you really need some justification and backg= round information. Otherwise people will just ask "how do you know peo= ple will implement this new mechanism?=E2=80=9D.

Great feedback, thank you!

/Olle

>
> Regards,
>
> Christer
>
>
>
> -----Original Message-----
> From: sipcore [mailto:sipc= ore-bounces@ietf.org] On Behalf Of Olle E. Johansson
> Sent: 17 June 2016 17:52
> To: Paul Kyzivat <pkyzivat= @alum.mit.edu>
> Cc: sipcore@ietf.org; Olle E J= ohansson <oej@edvina.net>
> Subject: Re: [sipcore] Half outbound
>
>
>> On 17 Jun 2016, at 16:48, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> On 6/17/16 9:15 AM, Olle E. Johansson wrote:
>>> http://www.slideshare.net/o= ej/sip-half-outbound-random-notes
>>>
>>> Trying to summarize - am I right?
>>>
>>> - No one seems to oppose some work in this area
>>> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and s= top doing alternatives
>>>
>>> As this is not an update to the core protocols, it seems like = any
>>> draft that can come out of this discussion needs to go to disp= atch
>>> and follow any route that group suggests.
>>>
>>> Anyone that wants to join me in writing a first draft to start= the process?
>>
>> I thought we had concluded that half-outbound isn't needed, be= cause the existing outbound may be used with a single connection/flow if pr= operly configured.
>>
>> If people still don't want to do it, then maybe what we need i= s research into why.
>
> The SIPconnect team more or less refused to add outbound regardless on= how many times I pointed at it as the only solution. I hope they can answe= r!
>
> So let=E2=80=99s take another round :-)
>
>
> /O
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore<= br> > _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore<= br>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a1141efced3d1d1053599f1a6-- From nobody Sun Jun 19 10:32:27 2016 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 8572112D5B4 for ; Sun, 19 Jun 2016 10:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 q-OCxrlM4LN4 for ; Sun, 19 Jun 2016 10:32:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 7C8F112D0A9 for ; Sun, 19 Jun 2016 10:32:21 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 23C13426A; Sun, 19 Jun 2016 19:32:18 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D4BAF34C-1331-4BC0-BA9D-E47C1E8CC5A9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 19 Jun 2016 19:32:17 +0200 Message-Id: <12DFDE0E-CFF8-43D3-A76A-7BEF864E1A27@edvina.net> References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B380DAD06@ESESSMB209.ericsson.se> <77E332EC-C195-4FC1-A45B-50025C3FBA7F@edvina.net> To: Ranjit Avasarala X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 17:32:25 -0000 --Apple-Mail=_D4BAF34C-1331-4BC0-BA9D-E47C1E8CC5A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Jun 2016, at 06:23, Ranjit Avasarala = wrote: >=20 > yes I agree - half outbound as a name does not sound appropriate - a = more meaningful name is better ABsolutely - but it was helpful in explaining what I wanted to do :-) =E2=80=9CSIP Client Managed Connection Reuse=E2=80=9D may work better. /O >=20 > Regards > Ranjit >=20 > On Sat, Jun 18, 2016 at 2:45 PM, Olle E. Johansson > wrote: >=20 > > On 18 Jun 2016, at 11:02, Christer Holmberg = > = wrote: > > > > > > Hi, > > > > If you plan to bring this to DISPATCH, I suggest the following: > > > > 1. Don't call it "Half Outbound". It will people focus on the = mechanism instead of what you actually want to achieve. > > > > 2. Write down a high-level use-case/call flow. Start by showing = people what you want to do - not by showing what is wrong with existing = mechanism (Outbound etc). > > > > 3. Based on the use-case/call-flow, write down a list of = requirements. Again, leave the SIP protocol mechanism specifics out. > > > > 4. THEN you can start talking about protocol mechanisms. You can = e.g. pick the parts of outbound that would fulfil the requirements. THAT = you can call "half outbound". > > > > 5. If you are going to make statements like "people don't want to = implement outbound", you really need some justification and background = information. Otherwise people will just ask "how do you know people will = implement this new mechanism?=E2=80=9D. >=20 > Great feedback, thank you! >=20 > /Olle >=20 > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of Olle E. Johansson > > Sent: 17 June 2016 17:52 > > To: Paul Kyzivat > > > Cc: sipcore@ietf.org ; Olle E Johansson = > > > Subject: Re: [sipcore] Half outbound > > > > > >> On 17 Jun 2016, at 16:48, Paul Kyzivat > wrote: > >> > >> On 6/17/16 9:15 AM, Olle E. Johansson wrote: > >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes = > >>> > >>> Trying to summarize - am I right? > >>> > >>> - No one seems to oppose some work in this area > >>> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound and stop = doing alternatives > >>> > >>> As this is not an update to the core protocols, it seems like any > >>> draft that can come out of this discussion needs to go to dispatch > >>> and follow any route that group suggests. > >>> > >>> Anyone that wants to join me in writing a first draft to start the = process? > >> > >> I thought we had concluded that half-outbound isn't needed, because = the existing outbound may be used with a single connection/flow if = properly configured. > >> > >> If people still don't want to do it, then maybe what we need is = research into why. > > > > The SIPconnect team more or less refused to add outbound regardless = on how many times I pointed at it as the only solution. I hope they can = answer! > > > > So let=E2=80=99s take another round :-) > > > > > > /O > > _______________________________________________ > > 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 = >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_D4BAF34C-1331-4BC0-BA9D-E47C1E8CC5A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19 Jun 2016, at 06:23, Ranjit Avasarala <ranjitkav0811@gmail.com> wrote:

yes I agree - half outbound as a name does not sound = appropriate - a more meaningful name is = better
ABsolutely - but it was helpful in = explaining what I wanted to do :-)

=E2=80=9CSIP Client Managed Connection Reuse=E2=80=9D= may work better.

/O

Regards
Ranjit

On Sat, = Jun 18, 2016 at 2:45 PM, Olle E. Johansson <oej@edvina.net> wrote:

> On 18 Jun 2016, at 11:02, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>
>
> Hi,
>
> If you plan to bring this to DISPATCH, I suggest the following:
>
> 1. Don't call it "Half Outbound". It will people focus on the = mechanism instead of what you actually want to achieve.
>
> 2. Write down a high-level use-case/call flow. Start by showing = people what you want to do - not by showing what is wrong with existing = mechanism (Outbound etc).
>
> 3. Based on the use-case/call-flow, write down a list of = requirements. Again, leave the SIP protocol mechanism specifics out.
>
> 4. THEN you can start talking about protocol mechanisms. You can = e.g. pick the parts of outbound that would fulfil the requirements. THAT = you can call "half outbound".
>
> 5. If you are going to make statements like "people don't want to = implement outbound", you really need some justification and background = information. Otherwise people will just ask "how do you know people will = implement this new mechanism?=E2=80=9D.

Great feedback, thank you!

/Olle

>
> Regards,
>
> Christer
>
>
>
> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson
> Sent: 17 June 2016 17:52
> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Cc: sipcore@ietf.org; Olle E Johansson <oej@edvina.net>
> Subject: Re: [sipcore] Half outbound
>
>
>> On 17 Jun 2016, at 16:48, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> On 6/17/16 9:15 AM, Olle E. Johansson wrote:
>>> http://www.slideshare.net/oej/sip-half-outbound-random-notes
>>>
>>> Trying to summarize - am I right?
>>>
>>> - No one seems to oppose some work in this area
>>> - No one seems to say =E2=80=9CYay=E2=80=9D for Outbound = and stop doing alternatives
>>>
>>> As this is not an update to the core protocols, it seems = like any
>>> draft that can come out of this discussion needs to go to = dispatch
>>> and follow any route that group suggests.
>>>
>>> Anyone that wants to join me in writing a first draft to = start the process?
>>
>> I thought we had concluded that half-outbound isn't needed, = because the existing outbound may be used with a single connection/flow = if properly configured.
>>
>> If people still don't want to do it, then maybe what we need is = research into why.
>
> The SIPconnect team more or less refused to add outbound regardless = on how many times I pointed at it as the only solution. I hope they can = answer!
>
> So let=E2=80=99s take another round :-)
>
>
> /O
> _______________________________________________
> 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

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_D4BAF34C-1331-4BC0-BA9D-E47C1E8CC5A9-- From nobody Sun Jun 19 18:28:08 2016 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 24EE412D894 for ; Sun, 19 Jun 2016 18:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 VYXT82gZTKfc for ; Sun, 19 Jun 2016 18:28:05 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 778D712D888 for ; Sun, 19 Jun 2016 18:28:05 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id z189so35288468itg.0 for ; Sun, 19 Jun 2016 18:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t3j7D8yqJNK7mC8kdi949BpdjsVm9ANZoAX9w5dF6kA=; b=fY/VEWn70H+e4DTY32aoWUJGrPo2dKJcDJ6zCmblCYN82L9yWrzJvirv/jUQmwiBhr s+6FJL56hX/6K4K1UQw251v1DhGb64Nyioq734ITukqHZ+uICq8twlxZmdAKPL8rEaxR JVQoCs1z1RIiYkcXzTvYwZ3bIicjewzdwI8SzovDVHA57GHDC01FQN6B2CZ+CVisQFYp Cd0ElVVKC3WkJ0I3ozcoGL7fJtP+z3+QPyIdxKsXYXxIfXYCLGl5pLFS8f3cL28BRuTk a58cc6NUV6m7NWKLm9EmTHu/QicvfUL+jw7/cKVdXdxM4AeNVvbYOEvNCfgv+e63FXCi IDYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t3j7D8yqJNK7mC8kdi949BpdjsVm9ANZoAX9w5dF6kA=; b=RpVkrnA7dNWo8eIEenTdu1NDPvDPmG2mGnTa7fakbMdX8zAMkHCFq2xBRQv64zP2zK z/qMgjPHP3gwoshHXLCgEu6Uhz0wmnPWncLOlvj347ISC/X+1bAQfd0utge71kp44i29 HQSLr+o8MqNETy0ZR45EfW12tGFHZ0qSDGEzJb2W2RRk4bJZjiv5GQ2kxcYCEMTQiLGH TosVY/28rpOXd/iQ8O0HjAdDH6ez7Zm5YYS6TN2m2De2vnq7IagCxxTIivwDCIQZAPqs 6OOG+VLmZH/9wCZrGHOV8SinMSggArQKtOt+iPOJXo2R4JgJj54RmHM2Nw7qe6AlSuFR pahw== X-Gm-Message-State: ALyK8tKeR6838wTnbmB+oCXuimbIkXEHGMAakT+poJC1AlA+N/4gp5r548pXmUESaFXJTw== X-Received: by 10.36.253.3 with SMTP id m3mr13092194ith.52.1466386084630; Sun, 19 Jun 2016 18:28:04 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id d15sm2039111itb.12.2016.06.19.18.28.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jun 2016 18:28:03 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id f6so24574626ith.0 for ; Sun, 19 Jun 2016 18:28:03 -0700 (PDT) X-Received: by 10.36.152.67 with SMTP id n64mr13627182itd.18.1466386083669; Sun, 19 Jun 2016 18:28:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Sun, 19 Jun 2016 18:28:02 -0700 (PDT) In-Reply-To: References: <820BAA09-D60D-46BA-BC7A-5474290FA335@edvina.net> <1a051930-ef69-9301-1d75-7b9b9fe837c6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38059B1F@ESESSMB209.ericsson.se> <92ed556a-ab85-de3f-c1a0-d61469fb2282@alum.mit.edu> From: Roman Shpount Date: Sun, 19 Jun 2016 21:28:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=94eb2c05abe89ef4b90535ab9d6b Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIPS must die - or at least be able to live without X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 01:28:07 -0000 --94eb2c05abe89ef4b90535ab9d6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2016 at 8:47 PM, Asveren, Tolga wrote: > [TOLGA] I didn=E2=80=99t mean to imply that WebRTC+DTLS/SRTP solves any p= roblem, > to the contrary, it does not change anything fundamentally as far as the > need for "end-to-end security/identity verification for signaling" is > concerned. > Use/trust on "fingerprint" does not necessarily imply "Identity > verification", it merely serves the purpose of verifying that the > certificate used for DTLS connection can be trusted on -as it is not sign= ed > by a CA-. And actually, if one takes things a bit more to philosophical > level, isn=E2=80=99t even use of a CA "a transitive trust relationship"? = How can I > *really* trust a particular CA? They may (and actually it is a well-known > fact that they are doing this in certain countries) issue certificates fo= r > Company-A to be used by some other entity. I think the only way I can tru= st > the identity on a certificate is if there is a 1:1 relationship between > verified identity/corresponding CA. For example, Alex provides Bob his > personal CA information (by whatever secure means, maybe handing it over = in > a diner) and Bob knows that this particular CA can be relied on only to > verify identity=3DAlex. > ZRTP would provide confidentiality but still would need end-to-end secure > signaling from identity perspective. > So, overall, the problem in front of us is a though nut to crack... > I just wanted to clarify what I've said earlier: There are two related but separate problems: 1. End-to-end encryption. This means end to end protection of metadata 2. End-to-end authentication. This means that signaling information, such as user metadata, destination addresses, ICE ufrags, and DTLS fingerprints have not been modified. Neither problem can be resolved without trusted third parties. If there is a third party that both clients trust and with which both can authenticate themselves, both problems can be resolved. There are some partial solutions available without trusted third parties, but they can typically be circumvented. In general, end-to-end authentication is a simpler problem to solve, since all it requires is a third party, which both end points trust that can generate a signature for the sensitive information, as well as a mechanism to pass this signature through the signaling exchanges. Regards, _____________ Roman Shpount --94eb2c05abe89ef4b90535ab9d6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 18, 2016 at 8:47 PM, Asveren, Tolga &= lt;tasveren@sonu= snet.com> wrote:
[TOLGA] I didn=E2=80=99t mean to imply that WebRTC+DTLS/SRTP sol= ves any problem, to the contrary, it does not change anything fundamentally= as far as the need for "end-to-end security/identity verification for= signaling" is concerned.
Use/trust on "fingerprint" does not necessarily imply "Ident= ity verification", it merely serves the purpose of verifying that the = certificate used for DTLS connection can be trusted on -as it is not signed= by a CA-. And actually, if one takes things a bit more to philosophical le= vel, isn=E2=80=99t even use of a CA "a transitive trust relationship&q= uot;? How can I *really* trust a particular CA? They may (and actually it i= s a well-known fact that they are doing this in certain countries) issue ce= rtificates for Company-A to be used by some other entity. I think the only = way I can trust the identity on a certificate is if there is a 1:1 relation= ship between verified identity/corresponding CA. For example, Alex provides= Bob his personal CA information (by whatever secure means, maybe handing i= t over in a diner) and Bob knows that this particular CA can be relied on o= nly to verify identity=3DAlex.
ZRTP would provide confidentiality but still would need end-to-end secure s= ignaling from identity perspective.
So, overall, the problem in front of us is a though nut to crack...

I just wanted to clarify what I've said ea= rlier: There are two related but separate problems:

1. End-to-end encryption. This means end to end protection of metadata

2. End-to-end authentication. This means that signal= ing information, such as user metadata, destination addresses, ICE ufrags, = and DTLS fingerprints have not been modified.

Neit= her problem can be resolved without trusted third parties. If there is a th= ird party that both clients trust and with which both can authenticate them= selves, both problems can be resolved. There are some partial solutions ava= ilable without trusted third parties, but they can typically be circumvente= d. In general, end-to-end authentication is a simpler problem to solve, sin= ce all it requires is a third party, which both end points trust that can g= enerate a signature for the sensitive information, as well as a mechanism t= o pass this signature through the signaling exchanges.

=
Regards,
_____________
Roman Shpount
=C2=A0
<= /div>
--94eb2c05abe89ef4b90535ab9d6b-- From nobody Mon Jun 20 08:04:14 2016 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 5561F12D146 for ; Mon, 20 Jun 2016 07:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 5LsYNuWfBcJW for ; Mon, 20 Jun 2016 07:40:22 -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 AC5B012D08E for ; Mon, 20 Jun 2016 07:40:22 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5KEdlDg042941 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 09:39:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: SIPCORE , "Paul Kyzivat" , "SIPCORE Chairs" Date: Mon, 20 Jun 2016 09:39:46 -0500 Message-ID: In-Reply-To: <20160620115508.5E452B82194@rfc-editor.org> References: <20160620115508.5E452B82194@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 08:04:12 -0700 Cc: jdrosen@cisco.com, aamelnikov@fastmail.fm, gunnar.hellstrom@omnitor.se, pkyzivat@cisco.com, alissa@cooperw.in, gonzalo.camarillo@ericsson.com Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:40:24 -0000 (adding sipcore and an updated address for Paul) Thoughts? Thanks! Ben. On 20 Jun 2016, at 6:55, RFC Errata System wrote: > The following errata report has been submitted for RFC4596, > "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller > Preferences Extension". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4596&eid=4716 > > -------------------------------------- > Type: Technical > Reported by: Gunnar Hellstrom > > Section: 3.9.2 > > Original Text > ------------- > languages= > > Corrected Text > -------------- > language= > > Notes > ----- > There are seven occurrences of this error in the sip examples of > section 3.9.2. > As comparison, section 3.16.2 has the correct spelling in its three > occurrences. > The parameter name refers to the language feature tag from RFC 2987, > named "language". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4596 (draft-ietf-sipping-callerprefs-usecases-05) > -------------------------------------- > Title : Guidelines for Usage of the Session Initiation > Protocol (SIP) Caller Preferences Extension > Publication Date : July 2006 > Author(s) : J. Rosenberg, P. Kyzivat > Category : INFORMATIONAL > Source : Session Initiation Proposal Investigation > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Mon Jun 20 08:30:35 2016 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 348F712D196 for ; Mon, 20 Jun 2016 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 eWfeccA9qW0t for ; Mon, 20 Jun 2016 08:29:07 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 F3E9412D0CC for ; Mon, 20 Jun 2016 08:29:06 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with SMTP id F17VbJHERSVL4F18Lbb8fY; Mon, 20 Jun 2016 15:29:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466436545; bh=VIbm7UfdgiiWALitTUPiZLsEouWTXNwW4jGboqPOTU0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kpGgJoFKx/8T03fMR3vXuufetrXIvsm9ctMe9yHYeIIFtDhbYQo5Xukk5aPZopbiO M25E1a1R2FxL77M/5lmejmsBE8qf5XpTV2JTC/VxerPJ+wbD+9gY6SSPaY0NKKaws8 KS1ECQ1yPzPDhJylijikglVjqkCHTgNAK2OuCY1T6Se9VJjd4PO9s2KRoLHvH6jsOB KeXmQ4i+Pq2aTRVkRKH2rcEFuXoFhODLKHyUQPA58TuhBmfphXlvQbLiy26sCxYxqx W3cCQcg9t2RMGMRVAiPfkeFW0M5FKOdi6lDlWNaU8iUxSVxf5PC59Dsg6+ZoZvYr6Z NXXj5gh0HUogQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id 93V31t0073KdFy1013V3yj; Mon, 20 Jun 2016 15:29:05 +0000 To: Ben Campbell , SIPCORE , SIPCORE Chairs References: <20160620115508.5E452B82194@rfc-editor.org> From: Paul Kyzivat Message-ID: Date: Mon, 20 Jun 2016 11:29:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 08:30:34 -0700 Cc: jdrosen@cisco.com, aamelnikov@fastmail.fm, gunnar.hellstrom@omnitor.se, pkyzivat@cisco.com, alissa@cooperw.in, gonzalo.camarillo@ericsson.com Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 15:29:08 -0000 On 6/20/16 10:39 AM, Ben Campbell wrote: > (adding sipcore and an updated address for Paul) > > Thoughts? This seems like a real error. The name of the feature tag registered in the IANA feature tag registry is "language". Thanks, Paul > Thanks! > > Ben. > > On 20 Jun 2016, at 6:55, RFC Errata System wrote: > >> The following errata report has been submitted for RFC4596, >> "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller >> Preferences Extension". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4596&eid=4716 >> >> -------------------------------------- >> Type: Technical >> Reported by: Gunnar Hellstrom >> >> Section: 3.9.2 >> >> Original Text >> ------------- >> languages= >> >> Corrected Text >> -------------- >> language= >> >> Notes >> ----- >> There are seven occurrences of this error in the sip examples of >> section 3.9.2. >> As comparison, section 3.16.2 has the correct spelling in its three >> occurrences. >> The parameter name refers to the language feature tag from RFC 2987, >> named "language". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4596 (draft-ietf-sipping-callerprefs-usecases-05) >> -------------------------------------- >> Title : Guidelines for Usage of the Session Initiation >> Protocol (SIP) Caller Preferences Extension >> Publication Date : July 2006 >> Author(s) : J. Rosenberg, P. Kyzivat >> Category : INFORMATIONAL >> Source : Session Initiation Proposal Investigation >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > From nobody Mon Jun 20 08:47:52 2016 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 92A6712D1B8 for ; Mon, 20 Jun 2016 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9RHSh87bMjqu for ; Mon, 20 Jun 2016 08:38:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B47D12D1A6 for ; Mon, 20 Jun 2016 08:38:00 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-69-57680dd61a17 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.20.27088.6DD08675; Mon, 20 Jun 2016 17:37:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Mon, 20 Jun 2016 17:37:58 +0200 From: Christer Holmberg To: Paul Kyzivat , Ben Campbell , SIPCORE , SIPCORE Chairs Thread-Topic: [sipcore] [Technical Errata Reported] RFC4596 (4716) Thread-Index: AQHRywUE8Ch/0LJ+40CeH3WCLZWP0p/yWWAAgAAkBqY= Date: Mon, 20 Jun 2016 15:37:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380EE3AE@ESESSMB209.ericsson.se> References: <20160620115508.5E452B82194@rfc-editor.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380EE3AEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUyM2K7je513oxwgyk7mCz2vz/EZDH9zF9G i/mdp9ktdrw/w2Kx/OAVZosVGw6wWtxYdIXF4tSr08wWX39sYnPg9Pj7/gOTx5TfG1k9vjx5 yeSx89QBNo8lS34yecza+YTFY+LiT8weXy5/ZgvgiOKySUnNySxLLdK3S+DKePjxMGvBX4+K qZ/nMjcwnrTvYuTkkBAwkTi69TcLhC0mceHeerYuRi4OIYEjjBLv2iYyQThLGCXuLpvE3sXI wcEmYCHR/U8bJC4iMI1R4uiNfnYQh1lgNZPExMePmEBGCQs4Svxs6mEDaRARcJI4+dkHJCwi YCXR9e4BK4jNIqAq8e7RGkaQEl4BX4mH07Ihdi1glFjb2sQMUsMp4CDxt+UDmM0IdN33U2vA xjMLiEs0fVnJCnG1gMSSPeeZIWxRiZeP/7FC1ORLnJ//mhHE5hUQlDg58wnLBEaRWUjaZyEp m4WkDCJuIPHl/W0oW1ti2cLXzBC2vkT3+9NMyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nl pZZsYgTG9sEtvw12ML587niIUYCDUYmHd8HdtHAh1sSy4srcQ4wSHMxKIrxsnBnhQrwpiZVV qUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhitlu4sW3krb/65Sb8n aYv917xUvv3Evn6/9M8Jprmdi+WmtZ7ods1b/m/NPs3DR5KuiKUlX3i0d1W4i8kTqRXTY6Yw frtmGvRRpHK61r3YS25x2U+1P641uRh13qGAUUJ86SrJ60fTN84Q61X+krb1pcxxAf7NCZGW Zc1uSuKrlfOXr73pWT1NiaU4I9FQi7moOBEAbCtjK+kCAAA= Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 08:47:50 -0700 Cc: "jdrosen@cisco.com" , "aamelnikov@fastmail.fm" , "gunnar.hellstrom@omnitor.se" , "pkyzivat@cisco.com" , "alissa@cooperw.in" , Gonzalo Camarillo Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 15:38:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380EE3AEESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable +1 Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD20/=FD06/=FD2016 18:30 To: Ben Campbell; SIPCORE;= SIPCORE Chairs Cc: jdrosen@cisco.com; aamelnikov@fastmail.fm; gunnar.hellstrom@omnitor.se; pkyzivat@cisco.com; alissa@co= operw.in; Gonzalo Camarillo Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) On 6/20/16 10:39 AM, Ben Campbell wrote: > (adding sipcore and an updated address for Paul) > > Thoughts? This seems like a real error. The name of the feature tag registered in the IANA feature tag registry is "language". Thanks, Paul > Thanks! > > Ben. > > On 20 Jun 2016, at 6:55, RFC Errata System wrote: > >> The following errata report has been submitted for RFC4596, >> "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller >> Preferences Extension". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4596&eid=3D4716 >> >> -------------------------------------- >> Type: Technical >> Reported by: Gunnar Hellstrom >> >> Section: 3.9.2 >> >> Original Text >> ------------- >> languages=3D >> >> Corrected Text >> -------------- >> language=3D >> >> Notes >> ----- >> There are seven occurrences of this error in the sip examples of >> section 3.9.2. >> As comparison, section 3.16.2 has the correct spelling in its three >> occurrences. >> The parameter name refers to the language feature tag from RFC 2987, >> named "language". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4596 (draft-ietf-sipping-callerprefs-usecases-05) >> -------------------------------------- >> Title : Guidelines for Usage of the Session Initiation >> Protocol (SIP) Caller Preferences Extension >> Publication Date : July 2006 >> Author(s) : J. Rosenberg, P. Kyzivat >> Category : INFORMATIONAL >> Source : Session Initiation Proposal Investigation >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B380EE3AEESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
+1

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD20= /=FD06/=FD2016 18:30
To: Ben Campbell; SIPCORE; SIPCORE Chairs
Cc: jdrosen@cisco.com; aamelnikov@fastmail.fm; gunnar.hellstrom@omnitor.se; pkyz= ivat@cisco.com; alissa@cooperw.in; Gonzalo Camarillo
Subject: Re: [= sipcore] [Technical Errata Reported] RFC4596 (4716)

On 6/20/16 10:39 AM, Ben Campbell wrote:
> (adding sipcore and an updated address for Paul)
>
> Thoughts?

This seems like a real error. The name of the feature tag registered in the IANA feature tag registry is "language".

        Thanks,
        Paul

> Thanks!
>
> Ben.
>
> On 20 Jun 2016, at 6:55, RFC Errata System wrote:
>
>> The following errata report has been submitted for RFC4596,
>> "Guidelines for Usage of the Session Initiation Protocol (SIP= ) Caller
>> Preferences Extension".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D4596&= eid=3D4716
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se><= br> >>
>> Section: 3.9.2
>>
>> Original Text
>> -------------
>> languages=3D
>>
>> Corrected Text
>> --------------
>> language=3D
>>
>> Notes
>> -----
>> There are seven occurrences of this error in the sip examples of >> section 3.9.2.
>> As comparison, section 3.16.2 has the correct spelling in its thre= e
>> occurrences.
>> The parameter name refers to the language feature tag from RFC 298= 7,
>> named "language".
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If neces= sary, please
>> use "Reply All" to discuss whether it should be verified= or
>> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=
>>
>> --------------------------------------
>> RFC4596 (draft-ietf-sipping-callerprefs-usecases-05)
>> --------------------------------------
>> Title          &= nbsp;    : Guidelines for Usage of the Session Initiation >> Protocol (SIP) Caller Preferences Extension
>> Publication Date    : July 2006
>> Author(s)         &nb= sp; : J. Rosenberg, P. Kyzivat
>> Category         &nbs= p;  : INFORMATIONAL
>> Source          =     : Session Initiation Proposal Investigation
>> Area          &n= bsp;     : Real-time Applications and Infrastructure >> Stream          =     : IETF
>> Verifying Party     : IESG
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B380EE3AEESESSMB209erics_-- From nobody Mon Jun 20 09:23:34 2016 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 7759312D548 for ; Mon, 20 Jun 2016 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] 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 zJayUufAWbOZ for ; Mon, 20 Jun 2016 09:23:32 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1637E12D542 for ; Mon, 20 Jun 2016 09:23:32 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 794871EB8525; Mon, 20 Jun 2016 18:23:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Mon, 20 Jun 2016 18:23:30 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , Paul Kyzivat Thread-Topic: [sipcore] Half outbound Thread-Index: AQHRyKdZuzjaHk03gESu/HZWot2145/tnNoAgATt8EA= Date: Mon, 20 Jun 2016 16:23:29 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26147AA5@MCHP04MSX.global-ad.net> References: <88a71897-e5a2-e105-4f35-cb512a1676ff@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Half outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:23:33 -0000 T246IDE3IEp1bmUgMjAxNiAxNTo1MiBPbGxlIEUuSm9oYW5zc29uIFdyb3RlOg0KPiANCj4gVGhl IFNJUGNvbm5lY3QgdGVhbSBtb3JlIG9yIGxlc3MgcmVmdXNlZCB0byBhZGQgb3V0Ym91bmQgcmVn YXJkbGVzcyBvbg0KPiBob3cgbWFueSB0aW1lcyBJIHBvaW50ZWQgYXQgaXQgYXMgdGhlIG9ubHkg c29sdXRpb24uIEkgaG9wZSB0aGV5IGNhbg0KPiBhbnN3ZXIhDQo+IA0KDQpJIGNhbm5vdCBzcGVh ayBvbiBiZWhhbGYgb2YgZXZlcnlib2R5IGluIHRoZSBTSVAgRm9ydW0ncyBTSVBjb25uZWN0IDIu MCB0YXNrIGdyb3VwIGJ1dCBJIHdhcyBhIGNvLWVkaXRvciBvZiB0aGUgc3BlYyBhbmQgaW52b2x2 ZWQgaW4gdGhlIGRpc2N1c3Npb24gdGhhdCBPbGxlIHJlZmVycyB0by4NCg0KSSBkb24ndCB0aGlu ayBpdCB3YXMgYSBjYXNlIG9mIHJlZnVzaW5nIHRvIGFkZCBvdXRib3VuZCB0aGVyZSB3YXMgYWN0 dWFsbHkgbm8gY29uc2Vuc3VzIGluIHRoZSBncm91cCB0byBhZGQgaXQgd2hpY2ggaGFzIGJlZW4g dGhlIGNhc2UgZXZlcnkgdGltZSB0aGUgaXNzdWUgaGFzIGJlZW4gcmFpc2VkIG92ZXIgYSBudW1i ZXIgb2YgeWVhcnMuIFRoZSBTSVAgRm9ydW0gdGFzayBncm91cCBhc2tlZCB0aGUgU0lQIFNlcnZp Y2UgUHJvdmlkZXJzIGFuZCB0aGUgdmVuZG9ycyB0aGF0IHBhcnRpY2lwYXRlIGlmIHRoZXkgbmVl ZGVkIFNJUCBvdXRib3VuZCBhbmQvb3IgYWN0dWFsbHkgdXNlZCBpdCBhbmQgbm9ib2R5IHNwb2tl IHVwLiAgVGhlIG9ubHkgYXJndW1lbnQgZ2l2ZW4gZm9yIGluY2x1ZGluZyBpdCB3YXMgdGhhdCBp dCBpcyB0aGUgb25seSBJRVRGL1JGQyBzcGVjaWZpZWQgYXBwcm9hY2ggdG8gdGhpcyBpc3N1ZSBi dXQgc2luY2Ugbm9ib2R5IHN0YXRlZCB0aGF0IHRoZXkgYWN0dWFsbHkgbmVlZGVkIG9yIHVzZWQg aXQgYXQgcHJlc2VudCBpdCB3YXMgbm90IGluY2x1ZGVkIGluIFNJUGNvbm5lY3QuDQoNClJlZ2Fy ZHMNCkFuZHkNCg0K From nobody Mon Jun 20 09:56:06 2016 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 EC90312D660 for ; Mon, 20 Jun 2016 09:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 6Q_Q7tQBzvnk for ; Mon, 20 Jun 2016 09:21:23 -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 65C4C12D635 for ; Mon, 20 Jun 2016 09:21:23 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5KGL8PA052136 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 11:21:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 20 Jun 2016 11:21:07 -0500 Message-ID: <1586A13D-749E-4A86-903A-81AFBE2A7202@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380EE3AE@ESESSMB209.ericsson.se> References: <20160620115508.5E452B82194@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B380EE3AE@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 09:56:06 -0700 Cc: SIPCORE Chairs , "jdrosen@cisco.com" , "aamelnikov@fastmail.fm" , "alissa@cooperw.in" , "pkyzivat@cisco.com" , SIPCORE , "gunnar.hellstrom@omnitor.se" , Gonzalo Camarillo Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:21:25 -0000 +1 from me, too. I plan to approve it. Ben. On 20 Jun 2016, at 10:37, Christer Holmberg wrote: > +1 > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Paul Kyzivat > Sent: ‎20/‎06/‎2016 18:30 > To: Ben Campbell; > SIPCORE; SIPCORE > Chairs > Cc: jdrosen@cisco.com; > aamelnikov@fastmail.fm; > gunnar.hellstrom@omnitor.se; > pkyzivat@cisco.com; > alissa@cooperw.in; Gonzalo > Camarillo > Subject: Re: [sipcore] [Technical Errata Reported] RFC4596 (4716) > > On 6/20/16 10:39 AM, Ben Campbell wrote: >> (adding sipcore and an updated address for Paul) >> >> Thoughts? > > This seems like a real error. The name of the feature tag registered > in > the IANA feature tag registry is "language". > > Thanks, > Paul > >> Thanks! >> >> Ben. >> >> On 20 Jun 2016, at 6:55, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC4596, >>> "Guidelines for Usage of the Session Initiation Protocol (SIP) >>> Caller >>> Preferences Extension". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4596&eid=4716 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Gunnar Hellstrom >>> >>> Section: 3.9.2 >>> >>> Original Text >>> ------------- >>> languages= >>> >>> Corrected Text >>> -------------- >>> language= >>> >>> Notes >>> ----- >>> There are seven occurrences of this error in the sip examples of >>> section 3.9.2. >>> As comparison, section 3.16.2 has the correct spelling in its three >>> occurrences. >>> The parameter name refers to the language feature tag from RFC 2987, >>> named "language". >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4596 (draft-ietf-sipping-callerprefs-usecases-05) >>> -------------------------------------- >>> Title : Guidelines for Usage of the Session Initiation >>> Protocol (SIP) Caller Preferences Extension >>> Publication Date : July 2006 >>> Author(s) : J. Rosenberg, P. Kyzivat >>> Category : INFORMATIONAL >>> Source : Session Initiation Proposal Investigation >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 20 12:26:23 2016 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 2E4E912D6B2 for ; Mon, 20 Jun 2016 12:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 RuFFnBYSyAEq for ; Mon, 20 Jun 2016 12:26:19 -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 07B1112D6A7 for ; Mon, 20 Jun 2016 12:26:19 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5KJQIeQ066849 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 14:26:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: draft-holmberg-dispatch-rfc7315-updates-06.all@ietf.org Date: Mon, 20 Jun 2016 14:26:18 -0500 Message-ID: <2A6BA24D-814A-4B92-A52D-7C861DB77DD7@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: SIPCORE Subject: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:26:21 -0000 (copying sipcore since, even though this is not a wg draft, sipcore probably offers the best nexus of expertise.) Hi, This is my AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06. I have one substantive comment and one editorial comment. I don't think either of these need block IETF last call. They can be handled along with any other last call feedback. Thanks! Ben. -------------- Substantive: The security considerations state that the draft removes some places that some of the P-Headers can be sent, but expands that to some other places. Further, it says that neither introduce new security considerations beyond those in 7315. I accept that for the reduction part. But I'm not sure we can state that sort of thing for the expansion part, at least without some more discussion. Since 7315 already acknowledges potential privacy issues around P-Access-Network-Info, I'd like to at least see a sentence or two about the allowance of that in ACK requests, even if they just say that this addition makes things no worse than they already are. Editorial: -5, first sentence: "The security considerations for P- header fields are defined in [RFC7315]" I assume this means 7315 discusses the security considerations for these P-Headers specifically, not P-Headers in general. Is this the intent? If so, I suggest: s/... for P-header fields.../ ... for these P-header fields... From nobody Mon Jun 20 12:27:32 2016 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 69ABA12D75D; Mon, 20 Jun 2016 12:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 E0FU5XtnRf4G; Mon, 20 Jun 2016 12:27:30 -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 3F8E112D73C; Mon, 20 Jun 2016 12:27:30 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5KJRTDJ066940 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 14:27:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: draft-holmberg-dispatch-rfc7315-updates.all@ietf.org Date: Mon, 20 Jun 2016 14:27:29 -0500 Message-ID: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: SIPCORE Subject: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:27:31 -0000 (copying sipcore since, even though this is not a wg draft, sipcore probably offers the best nexus of expertise.) Hi, This is my AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06. I have one substantive comment and one editorial comment. I don't think either of these need block IETF last call. They can be handled along with any other last call feedback. Thanks! Ben. -------------- Substantive: The security considerations state that the draft removes some places that some of the P-Headers can be sent, but expands that to some other places. Further, it says that neither introduce new security considerations beyond those in 7315. I accept that for the reduction part. But I'm not sure we can state that sort of thing for the expansion part, at least without some more discussion. Since 7315 already acknowledges potential privacy issues around P-Access-Network-Info, I'd like to at least see a sentence or two about the allowance of that in ACK requests, even if they just say that this addition makes things no worse than they already are. Editorial: -5, first sentence: "The security considerations for P- header fields are defined in [RFC7315]" I assume this means 7315 discusses the security considerations for these P-Headers specifically, not P-Headers in general. Is this the intent? If so, I suggest: s/... for P-header fields.../ ... for these P-header fields... From nobody Mon Jun 20 14:16:09 2016 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 9399712DA4E; Mon, 20 Jun 2016 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 AUmylMHUKuqm; Mon, 20 Jun 2016 14:16:05 -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 83D9C12DA4B; Mon, 20 Jun 2016 14:16:02 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5KLG1Lh075405 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 16:16:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: draft-ietf-sipcore-dns-dual-stack.all@ietf.org, SIPCORE Date: Mon, 20 Jun 2016 16:16:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-dns-dual-stack-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:16:07 -0000 Hi, This is my AD evaluation of draft-ietf-sipcore-dns-dual-stack-06. I only have a few editorial comments. None of these need to delay IETF last call, and can be handled along with any feedback from the last call. Thanks! Ben. --------- -1, 2nd paragraph, first sentence: That sentence is a bit hard to parse, please consider breaking into two or more simpler sentences. -2, definition of IPv4/IPv6 UA/UAC/UAS: This defines one term, then declares the draft will use another. Why not just define _that_ term in the first place? -4: This section kind of buries the lede, and leaves me wondering what the actual clarification was. Is the point to say not to interleave the results of the address record queries among srv records? Is there a concern that people thought they were to do something different? It would be helpful to say what misconception you intend to clarify. -5, first paragraph, last sentence: Oddly constructed sentence. The structure seems to imply a tension between the idea of optimizing performance and not introducing security considerations. Please consider something to the effect of the following: “Both of these procedures are optimization designed to improve the performance of dual-stack clients. Neither introduce new security considerations.†From nobody Mon Jun 20 14:29:03 2016 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 0068D12DA64 for ; Mon, 20 Jun 2016 14:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 EGbNqb8D9UhW for ; Mon, 20 Jun 2016 14:29:01 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 E000112DA62 for ; Mon, 20 Jun 2016 14:29:00 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with SMTP id F6kMbK6wd13YVF6kebPqZq; Mon, 20 Jun 2016 21:29:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466458140; bh=R3w2wa+MAIxn5WA5r2SXM1zkrZmV15U4qiGWTbeRQ4Q=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=kyYmuzuguTPAfalCSAcTWWUpSHyBuy8GE5FGxe7QmadCDXomZd7enk5vqDzJetbaS 5EkLksR8QNQepIdx/ERM6D+AEp9Ln5/XfWF4q1K/REuBAR3Y5T/zsu2bZYBM+kaKV8 UM4rRn0hWQZ6DzMAu4ILkLhfxfZi/7XD1u1s0+O8K9kV8q63m+0VeBJXJR1ySGB37Y 40Edc3TePY3nLYIS9Jdy7rFK+BgpSi3C9GREbrpmKFoH/u62xVqGChQhCtWB+BWt0z dCUAQayBNJoIsXZzkO3E6pZfc+uH6+Mbkwq2qyeU9WQ05r8ly9VIxX35cIqOp8+G/9 ghC+Rc1IqziiQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 99Uz1t00D1nMCLR019UzdV; Mon, 20 Jun 2016 21:28:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5KLSwTK009864 for ; Mon, 20 Jun 2016 17:28:58 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5KLSvve009857; Mon, 20 Jun 2016 17:28:57 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 20 Jun 2016 17:28:57 -0400 Message-ID: <87r3brpn1i.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Happy Eyeballs: Requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:29:02 -0000 Getting back involved here: I've gone over the discussions, and I think I can extract a good statement of the requirements we need to satisfy for Happy Eyeballs in practice. Perhaps some of these can be extracted as seperate work items, but they all are closely related. Some of them can be solved fairly simply, but I think some will involve significant new work. The major item that is outside its scope is signaling privacy. Needless to say, copious comments are invited. I'll send further messages outlining what I think are the state of solutions for various items. - Solve the "happy eyeballs" problem for INVITE, i.e., if a destination URI is advertised with both multiple targets (IPv4 and IPv6 or otherwise), but connectivity to only one target exists, usually message transmission will not be delayed unacceptably, and in particular, not by a full timeout as prescribed in 3261. Note that the solution may be decidedly different based on the transport protocol(s) for the targets. There is uncertainty about whether adding an RTT to signaling times is acceptable. For example, in practice RTT on the overall Internet is less than 1/2 second, and that is an acceptable delay in call setup times under ordinary circumstances. - The solution must approximate 3263, in that if several targets are specified by *different* SRV records and are reachable over a long period of time, the relative traffic shares sent to them must be compatible with the priorities and weights of the SRV records. (If they are alternatives that are *not* derived from different SRV records, the solution is unconstrained regarding relative traffic shares.) - The solution should be as compatible with SIP Outbound as practicable. The difficult part of this is "the solution for simple UDP (i.e., not using SIP Outbound)". There is a strong perception that in systems where an edge proxy services 10^5 or 10^6 UAs that only UDP-without-Outbound has a low enough per-flow overhead to be workable. The important requirements for simple UDP seem to be: - The per-UA state in the edge proxy must be no larger than about what is kept for a registration. - The update rate of the per-UA state in the edge proxy must be no larger than about the update rate for a registration. It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet these requirements. A substantial fraction of the UAs tested in the latest SIPit do not support TCP, TLS, or Outbound, showing that there is substantial market presence of simple-UDP-only UAs. It is possible that a "Simple Outbound" can be defined that provides the needed part of the functionality of Outbound at a sufficiently low overhead and complexity that it meets these requirements. If so, it is desirable that it be conceptually and operationally upward-compatible with Outbound. - Deal with the handoff problem, i.e., when the call (signaling and media) are being sent over one interface, and that interface becomes unavailable, but another interface has been available, the signaling and media should be rerouted via the other interface. - The primary requirement is that the signaling path is reestablished, i.e., the call is not dropped. It may take several seconds for signaling flow to be reestablished. - The media flow should be interrupted for only a "short" period of time so the user does not assume that the call has been dropped. 2 seconds seems a reasonable target. - Clients behind client-side NATs must be fully supported. - In particular, if the external address of a NAT binding changes, the UA must be able to recover, with the same requirements as an interface handoff. - Signaling privacy (e.g., "SIP over DTLS") is not in scope. Dale From nobody Mon Jun 20 14:42:33 2016 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 537D912DA7A; Mon, 20 Jun 2016 14:42:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160620214232.30095.2191.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 14:42:32 -0700 Archived-At: Cc: ben@nostrum.com, draft-ietf-sipcore-dns-dual-stack@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Last Call: (Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:42:33 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs principles to SIP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jun 21 01:27:05 2016 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 AA58F12D0E6; Tue, 21 Jun 2016 01:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1CJMAK5YwGWw; Tue, 21 Jun 2016 01:27:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B9012B050; Tue, 21 Jun 2016 01:27:01 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-33-5768fa5301ea Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.56.18043.35AF8675; Tue, 21 Jun 2016 10:26:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 10:26:58 +0200 From: Christer Holmberg To: Ben Campbell , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkA Date: Tue, 21 Jun 2016 08:26:59 +0000 Message-ID: References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> In-Reply-To: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2C78C430826F074DA057685A2A45AF2A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7qG7wr4xwg+eP9Szmd55mt1j9ehar xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxlH1tYC1aKVDxe+pO1gXGRQBcj J4eEgInEnz8TGSFsMYkL99azdTFycQgJHGGU6H/6ghUkISSwhFFix2bLLkYODjYBC4nuf9og NSICUxklXm54ywRSwywgJ3H9w0Y2EFtYwENi7uw7YHERAU+Ji783skPYRhKHv7eBzWQRUJW4 N+s3mM0rYCVx9WkbG8QuO4me0z9ZQGxOAXuJe99egPUyAh33/dQaqF3iEreezGeCOFpAYsme 88wQtqjEy8f/wGaKCuhJfLk3D+oxRYmPr/YxQvTqSdyYOoUNwraWWPd+GlRcW2LZwtfMEPcI Spyc+YRlAqPELCTrZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnE CIzIg1t+W+1gPPjc8RCjAAejEg9vQnpGuBBrYllxZe4hRgkOZiURXqWfQCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2MJb56PfPSbHnntnn+6NllLxr2 RSvX6J/eV7/dTyU+qpyS0prFy7JzxdzWjgLtVWfj7VsvMK4tmOvXrrp15nQlxV4lBqX6eZsP OAqtZSj/HH7AiHVmcc+lAxXp0rvOlDwKaQvL43vm+jqzJ7jGv/6CqF51k0CYz27njPh+cd7Y iOB5K2N+NyqxFGckGmoxFxUnAgBJlpAmxAIAAA== Archived-At: Cc: SIPCORE Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:27:04 -0000 Hi Ben, See inline. >-------------- > >Substantive: > >The security considerations state that the draft removes some places >that some of the P-Headers can be sent, but expands that to some other >places. Further, it says that neither introduce new security >considerations beyond those in 7315. > >I accept that for the reduction part. But I'm not sure we can state that >sort of thing for the expansion part, at least without some more >discussion. Since 7315 already acknowledges potential privacy issues >around P-Access-Network-Info, I'd like to at least see a sentence or two >about the allowance of that in ACK requests, even if they just say that >this addition makes things no worse than they already are. OLD: The security considerations for P- header fields are defined in [RFC7315]. This specification allows some header fields to be present in messages where they were previously not allowed, and disallow some header fields to be present in messages where they were previously allowed. That does not cause any security issues, but implementations need to be aware that implementations may not have been updated according to this document, and take proper actions if a header field occur, or does not occur, in a message where it should occur (or occurs in a message where it should not occur). NEW: The security considerations for these P- header fields are defined in [RFC7315]. This specification allows some header fields to be present in messages where they were previously not allowed, and the security considerations and assumptions (e.g. regarding only sending Information to trusted entities) also to those messages. In addition, this specification also disallow some header fields to be present in message where they were previously allowed. That does not cause any security issues, but implementations need to be aware that implementations may not have been updated according to this document, and take proper actions if a header field occur, or does not occur, in a message where it should occur (or occurs in a message where it should not occur). >Editorial: > >-5, first sentence: "The security considerations for P- header fields >are defined in > [RFC7315]" >I assume this means 7315 discusses the security considerations for these >P-Headers specifically, not P-Headers in general. Is this the intent? If >so, I suggest: > >s/... for P-header fields.../ ... for these P-header fields... I=B9ll fix as suggested (ass new text above). Regards, Christer From nobody Tue Jun 21 08:22:31 2016 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 4FBEC12D96B; Tue, 21 Jun 2016 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 g-ADxtN0SpZQ; Tue, 21 Jun 2016 08:22:29 -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 20C7912D96A; Tue, 21 Jun 2016 08:22:29 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5LFMOTs069706 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 10:22:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 21 Jun 2016 10:22:24 -0500 Message-ID: <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> In-Reply-To: References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: SIPCORE , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:22:30 -0000 That's a good start, but don't be surprised if we get questions specifically about adding NPLI to ACK requests. some language to the effect of the following might help: "This document adds the ability to include P-Access-Network-Info in ACK requests. As documented in RFC7315, P-Access-Network-Info may include privacy sensitive information, including the user's location. The security and privacy considerations for P-Access-Network-Info in ACK requests are similar to those for the other SIP requests discussed in RFC7315." Thanks! Ben. On 21 Jun 2016, at 3:26, Christer Holmberg wrote: > Hi Ben, > > See inline. > >> -------------- >> >> Substantive: >> >> The security considerations state that the draft removes some places >> that some of the P-Headers can be sent, but expands that to some >> other >> places. Further, it says that neither introduce new security >> considerations beyond those in 7315. >> >> I accept that for the reduction part. But I'm not sure we can state >> that >> sort of thing for the expansion part, at least without some more >> discussion. Since 7315 already acknowledges potential privacy issues >> around P-Access-Network-Info, I'd like to at least see a sentence or >> two >> about the allowance of that in ACK requests, even if they just say >> that >> this addition makes things no worse than they already are. > > > OLD: > > The security considerations for P- header fields are defined in > [RFC7315]. This specification allows some header fields to be > present in messages where they were previously not allowed, and > disallow some header fields to be present in messages where they > were > previously allowed. That does not cause any security issues, but > implementations need to be aware that implementations may not have > been updated according to this document, and take proper actions if > a > header field occur, or does not occur, in a message where it should > occur (or occurs in a message where it should not occur). > > > > NEW: > > The security considerations for these P- header fields are defined in > [RFC7315]. This specification allows some header fields to be > present in messages where they were previously not allowed, and the > security considerations and assumptions (e.g. regarding only sending > Information to trusted entities) also to those messages. In addition, > this specification also disallow some header fields to be present > in message where they were previously allowed. That does not cause > any security issues, but implementations need to be aware that > implementations may not have been updated according to this document, > and take proper actions if a header field occur, or does not occur, > in a message where it should occur (or occurs in a message where it > should not occur). > > > >> Editorial: >> >> -5, first sentence: "The security considerations for P- header fields >> are defined in >> [RFC7315]" >> I assume this means 7315 discusses the security considerations for >> these >> P-Headers specifically, not P-Headers in general. Is this the intent? >> If >> so, I suggest: >> >> s/... for P-header fields.../ ... for these P-header fields... > > I¹ll fix as suggested (ass new text above). > > Regards, > > Christer From nobody Tue Jun 21 09:53:02 2016 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 C5CBA12DB07; Tue, 21 Jun 2016 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RSj8A4raDtq7; Tue, 21 Jun 2016 09:52:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FF412DAC9; Tue, 21 Jun 2016 09:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4932; q=dns/txt; s=iport; t=1466527478; x=1467737078; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KziwniaBLZUt1bQHmq3OzbOmLQnRe7FajRYfSb1X2kQ=; b=YDMnPit5ToCAQdG3TLFhpYxuTthvh3J963QTElluOfavP29o5e0dIt38 lfHxFapguWbKH+jVZ81n5pIdFstfa0BmVnGBJqMOXU8QuQJNzFPhNkFWf bQZn1beHrWM/lT8O8iEjxPtIxFSnb23qt1CEk0mo6UsAjGISTTycyUeJS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBQCnbmlX/4YNJK1dgz6BUwa8aoYXA?= =?us-ascii?q?hyBGzsRAQEBAQEBAWUnhEsBAQEDASMRRQULAgEIGAICJgICAjAVEAIEDgWIKAi?= =?us-ascii?q?xLpBUAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSaBdwiCTodBK4IvBYgSkGcBj?= =?us-ascii?q?iuPI493ATQgg3BuiUl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,505,1459814400"; d="scan'208";a="115292707" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2016 16:44:37 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5LGibGY032598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 16:44:37 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 21 Jun 2016 11:44:36 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 21 Jun 2016 11:44:36 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Ben Campbell Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkAgAC2EQCAABb2gA== Date: Tue, 21 Jun 2016 16:44:36 +0000 Message-ID: <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> In-Reply-To: <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.253.122] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SIPCORE , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 16:52:58 -0000 DQo+IE9uIEp1biAyMSwgMjAxNiwgYXQgMTE6MjIgQU0sIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3Ry dW0uY29tPiB3cm90ZToNCj4gDQo+IFRoYXQncyBhIGdvb2Qgc3RhcnQsIGJ1dCBkb24ndCBiZSBz dXJwcmlzZWQgaWYgd2UgZ2V0IHF1ZXN0aW9ucyBzcGVjaWZpY2FsbHkgYWJvdXQgYWRkaW5nIE5Q TEkgdG8gQUNLIHJlcXVlc3RzLiBzb21lIGxhbmd1YWdlIHRvIHRoZSBlZmZlY3Qgb2YgdGhlIGZv bGxvd2luZyBtaWdodCBoZWxwOg0KPiANCj4gIlRoaXMgZG9jdW1lbnQgYWRkcyB0aGUgYWJpbGl0 eSB0byBpbmNsdWRlIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBpbiBBQ0sgcmVxdWVzdHMuIEFzIGRv Y3VtZW50ZWQgaW4gUkZDNzMxNSwgUC1BY2Nlc3MtTmV0d29yay1JbmZvIG1heSBpbmNsdWRlIHBy aXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgdGhlIHVzZXIncyBsb2NhdGlv bi4gVGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGZvciBQLUFjY2Vzcy1O ZXR3b3JrLUluZm8gaW4gQUNLIHJlcXVlc3RzIGFyZSBzaW1pbGFyIHRvIHRob3NlIGZvciB0aGUg b3RoZXIgU0lQIHJlcXVlc3RzIGRpc2N1c3NlZCBpbiBSRkM3MzE1LuKAnQ0KDQpJ4oCZbSBmaW5l IHdpdGggYWRkaW5nIHN1Y2ggdGV4dC4NCg0KQ2hyaXN0ZXIgLSBDYW4gd2UgYXBwZW5kIHRoaXMg dG8geW91ciBwcm9wb3NlZCB0ZXh0Pw0KDQpHb256YWxvDQoNCg0KPiANCj4gVGhhbmtzIQ0KPiAN Cj4gQmVuLg0KPiANCj4gT24gMjEgSnVuIDIwMTYsIGF0IDM6MjYsIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KPiANCj4+IEhpIEJlbiwNCj4+IA0KPj4gU2VlIGlubGluZS4NCj4+IA0KPj4+IC0t LS0tLS0tLS0tLS0tDQo+Pj4gDQo+Pj4gU3Vic3RhbnRpdmU6DQo+Pj4gDQo+Pj4gVGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHN0YXRlIHRoYXQgdGhlIGRyYWZ0IHJlbW92ZXMgc29tZSBwbGFj ZXMNCj4+PiB0aGF0IHNvbWUgb2YgdGhlIFAtSGVhZGVycyBjYW4gYmUgc2VudCwgYnV0IGV4cGFu ZHMgdGhhdCB0byBzb21lIG90aGVyDQo+Pj4gcGxhY2VzLiBGdXJ0aGVyLCBpdCBzYXlzIHRoYXQg bmVpdGhlciBpbnRyb2R1Y2UgbmV3IHNlY3VyaXR5DQo+Pj4gY29uc2lkZXJhdGlvbnMgYmV5b25k IHRob3NlIGluIDczMTUuDQo+Pj4gDQo+Pj4gSSBhY2NlcHQgdGhhdCBmb3IgdGhlIHJlZHVjdGlv biBwYXJ0LiBCdXQgSSdtIG5vdCBzdXJlIHdlIGNhbiBzdGF0ZSB0aGF0DQo+Pj4gc29ydCBvZiB0 aGluZyBmb3IgdGhlIGV4cGFuc2lvbiBwYXJ0LCBhdCBsZWFzdCB3aXRob3V0IHNvbWUgbW9yZQ0K Pj4+IGRpc2N1c3Npb24uIFNpbmNlIDczMTUgYWxyZWFkeSBhY2tub3dsZWRnZXMgcG90ZW50aWFs IHByaXZhY3kgaXNzdWVzDQo+Pj4gYXJvdW5kIFAtQWNjZXNzLU5ldHdvcmstSW5mbywgSSdkIGxp a2UgdG8gYXQgbGVhc3Qgc2VlIGEgc2VudGVuY2Ugb3IgdHdvDQo+Pj4gYWJvdXQgdGhlIGFsbG93 YW5jZSBvZiB0aGF0IGluIEFDSyByZXF1ZXN0cywgZXZlbiBpZiB0aGV5IGp1c3Qgc2F5IHRoYXQN Cj4+PiB0aGlzIGFkZGl0aW9uIG1ha2VzIHRoaW5ncyBubyB3b3JzZSB0aGFuIHRoZXkgYWxyZWFk eSBhcmUuDQo+PiANCj4+IA0KPj4gT0xEOg0KPj4gDQo+PiBUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgZm9yIFAtIGhlYWRlciBmaWVsZHMgYXJlIGRlZmluZWQgaW4NCj4+ICAgW1JGQzczMTVd LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGFsbG93cyBzb21lIGhlYWRlciBmaWVsZHMgdG8gYmUNCj4+ ICAgcHJlc2VudCBpbiBtZXNzYWdlcyB3aGVyZSB0aGV5IHdlcmUgcHJldmlvdXNseSBub3QgYWxs b3dlZCwgYW5kDQo+PiAgIGRpc2FsbG93IHNvbWUgaGVhZGVyIGZpZWxkcyB0byBiZSBwcmVzZW50 IGluIG1lc3NhZ2VzIHdoZXJlIHRoZXkgd2VyZQ0KPj4gICBwcmV2aW91c2x5IGFsbG93ZWQuIFRo YXQgZG9lcyBub3QgY2F1c2UgYW55IHNlY3VyaXR5IGlzc3VlcywgYnV0DQo+PiAgIGltcGxlbWVu dGF0aW9ucyBuZWVkIHRvIGJlIGF3YXJlIHRoYXQgaW1wbGVtZW50YXRpb25zIG1heSBub3QgaGF2 ZQ0KPj4gICBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsIGFuZCB0YWtl IHByb3BlciBhY3Rpb25zIGlmIGENCj4+ICAgaGVhZGVyIGZpZWxkIG9jY3VyLCBvciBkb2VzIG5v dCBvY2N1ciwgaW4gYSBtZXNzYWdlIHdoZXJlIGl0IHNob3VsZA0KPj4gICBvY2N1ciAob3Igb2Nj dXJzIGluIGEgbWVzc2FnZSB3aGVyZSBpdCBzaG91bGQgbm90IG9jY3VyKS4NCj4+IA0KPj4gDQo+ PiANCj4+IE5FVzoNCj4+IA0KPj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVz ZSBQLSBoZWFkZXIgZmllbGRzIGFyZSBkZWZpbmVkIGluDQo+PiAgIFtSRkM3MzE1XS4gIFRoaXMg c3BlY2lmaWNhdGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlDQo+PiAgIHByZXNl bnQgaW4gbWVzc2FnZXMgd2hlcmUgdGhleSB3ZXJlIHByZXZpb3VzbHkgbm90IGFsbG93ZWQsIGFu ZCB0aGUNCj4+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBhc3N1bXB0aW9ucyAoZS5nLiBy ZWdhcmRpbmcgb25seSBzZW5kaW5nDQo+PiBJbmZvcm1hdGlvbiB0byB0cnVzdGVkIGVudGl0aWVz KSBhbHNvIHRvIHRob3NlIG1lc3NhZ2VzLiBJbiBhZGRpdGlvbiwNCj4+IHRoaXMgc3BlY2lmaWNh dGlvbiBhbHNvIGRpc2FsbG93IHNvbWUgaGVhZGVyIGZpZWxkcyB0byBiZSBwcmVzZW50DQo+PiBp biBtZXNzYWdlIHdoZXJlIHRoZXkgd2VyZSBwcmV2aW91c2x5IGFsbG93ZWQuIFRoYXQgZG9lcyBu b3QgY2F1c2UNCj4+IGFueSBzZWN1cml0eSBpc3N1ZXMsIGJ1dCBpbXBsZW1lbnRhdGlvbnMgbmVl ZCB0byBiZSBhd2FyZSB0aGF0DQo+PiBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBoYXZlIGJlZW4g dXBkYXRlZCBhY2NvcmRpbmcgdG8gdGhpcyBkb2N1bWVudCwNCj4+IGFuZCB0YWtlIHByb3BlciBh Y3Rpb25zIGlmIGEgaGVhZGVyIGZpZWxkIG9jY3VyLCBvciBkb2VzIG5vdCBvY2N1ciwNCj4+IGlu IGEgbWVzc2FnZSB3aGVyZSBpdCBzaG91bGQgb2NjdXIgKG9yIG9jY3VycyBpbiBhIG1lc3NhZ2Ug d2hlcmUgaXQNCj4+IHNob3VsZCBub3Qgb2NjdXIpLg0KPj4gDQo+PiANCj4+IA0KPj4+IEVkaXRv cmlhbDoNCj4+PiANCj4+PiAtNSwgZmlyc3Qgc2VudGVuY2U6ICJUaGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIFAtIGhlYWRlciBmaWVsZHMNCj4+PiBhcmUgZGVmaW5lZCBpbg0KPj4+ICAg W1JGQzczMTVdIg0KPj4+IEkgYXNzdW1lIHRoaXMgbWVhbnMgNzMxNSBkaXNjdXNzZXMgdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZQ0KPj4+IFAtSGVhZGVycyBzcGVjaWZpY2Fs bHksIG5vdCBQLUhlYWRlcnMgaW4gZ2VuZXJhbC4gSXMgdGhpcyB0aGUgaW50ZW50PyBJZg0KPj4+ IHNvLCBJIHN1Z2dlc3Q6DQo+Pj4gDQo+Pj4gcy8uLi4gZm9yIFAtaGVhZGVyIGZpZWxkcy4uLi8g Li4uIGZvciB0aGVzZSBQLWhlYWRlciBmaWVsZHMuLi4NCj4+IA0KPj4gScK5bGwgZml4IGFzIHN1 Z2dlc3RlZCAoYXNzIG5ldyB0ZXh0IGFib3ZlKS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4g Q2hyaXN0ZXINCg0K From nobody Tue Jun 21 16:46:18 2016 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 8757112D857 for ; Tue, 21 Jun 2016 16:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 oOmYRlTICf_p for ; Tue, 21 Jun 2016 16:46:15 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 570E212D842 for ; Tue, 21 Jun 2016 16:46:15 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5LNglnQ006510; Tue, 21 Jun 2016 19:46:12 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23n298g6pm-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Jun 2016 19:46:12 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 21 Jun 2016 19:46:11 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSA Date: Tue, 21 Jun 2016 23:46:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.14] Content-Type: multipart/alternative; boundary="_000_D38F19C319F959jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-21_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606210256 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:46:17 -0000 --_000_D38F19C319F959jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's not really what I'm looking for, no, and after mulling this over a bit= , I fear going farther along this path would only drill down into levels of= complexity that will likely make this harder to understand rather than eas= ier. I do acknowledge that you describe the INVITE as being rejected if it doesn= 't contain a token - but that's not the same thing as saying the INVITE wil= l be rejected because the relying party makes an authorization decision bas= ed on the attributes in the token. It's more like an INVITE being rejected = because a user agent can't supply an Authorization header. I will reiterate= that I don't think the kinds of attributes you are proposing should be in = the scope of an effort that will try to address a framework for authorizing= SIP requests. I don't think the values of the attributes (as opposed to th= e mere presence of some attributes) have anything to do with authorizing th= e SIP request that you propose would carry the attributes. With regards to this whole conferencing example, it does seem a bit contriv= ed to me, like you're sketching a SIP-based way of setting conference polic= y on the fly that happens to require the kind of attributes you want, and t= hen saying that demonstrates the need for the attributes. The fact that all= of the ways to do conference policy we can point to in fact do it via the = web makes it hard for me to understand why we should create a SIP-based way= of doing this. To me, it looks like you're opening a problem space that ha= s much more to do with reshaping the way that SIP does conferences (and aga= in, as Radhika's mail pointing out, there's been a lot of thinking about th= is since the days of RFC4579) than it does with defining a framework for au= thorizing SIP requests. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, June 16, 2016 at 6:19 AM To: Jon Peterson = > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 The attributes I provided are examples of attributes that might be provided= in an access token; it was not meant to include all the attributes for thi= s use case, because my intention was not to focus on conference server, but= to discuss the idea in general. The following could be used with the conference factory to request a confer= ence focus: The INVITE sent to the conference factory could include a token that has a = conference-type attribute which could take one of the following values: aud= io, video, webconference, audio-webconference, or video-webconference. The conference factory will then issue a conference uri for the requested c= onference type, assuming the token is valid. If the conference-type attribu= te is missing, then the request would be rejected. Is that what you are looking for? Regards, Rifaat On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon > wrote: In that case, if you could furnish a use case with attributes that would be= carried in a SIP iNVITE that are actually salient to the authorization of = that particular SIP request, we'd be getting a lot closer to common ground. An obvious example would be an INVITE with a token sent to a conference fac= tory to authorize the creation of a focus. We're still talking past each other. My point above was that the two attrib= utes you specified - constraints on conference size and media types - have = nothing to do with the authorization of the INVITE carrying those attribute= s. Like, unless the conference size permitted is 0, then the INVITE that cr= eates an ad hoc conference and connects you to its bridge is not going to b= e rejected by the focus on the basis of that conference size attribute. If = the maximum conference size were 0, the AuthZ service just wouldn't attach = a token to an INVITE as it would never be allowed to start a conference. Sa= me goes for media types. Instead, what your two attributes constrain is what happens after the confe= rence is created: when ten users try to dial in to a conference with a perm= itted size of nine, say. That tenth INVITE would get rejected - not the con= ference-forming INVITE that you propose would carry the token. That's why w= hat you're proposing is overloading the INVITE to tunnel conference policy = constraints to the focus. I mean, maybe that's a problem space worth invest= igating, though I suspect there are good reasons why RFC4353 specified that= conference policy is not manipulated with SIP - mostly because the semanti= cs of manipulating conference policy probably don't map well onto dialog-fo= rming SIP requests. But I think that conference policy provisioning problem= space would be pretty far from where we started in this discussion. Let me reiterate what I wrote in my previous mail, which I quote here at th= e top: "furnish a use case with attributes that would be carried in a SIP i= NVITE that are actually salient to the authorization of that particular SIP= request." Again: "that particular SIP request." Not later transactions in = some broader context in which the original user agent probably isn't even a= n endpoint. The Authorization header in SIP, for example, is actually used by the UAS t= o make a decision about whether or not to authorize the request in which th= e header appears. The token that you propose a SIP INVITE would carry in t= his case is not used by the relying party to make a decision about whether = or not that INVITE is authorized. That's why I believe this conference poli= cy issue is a different problem space entirely from figuring out how to imp= lement attribute-based authorization for SIP requests. Jon Peterson Neustar, Inc. Regards, Rifaat --_000_D38F19C319F959jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

It's not really what I'm looking for, no, and after mulling this over = a bit, I fear going farther along this path would only drill down into leve= ls of complexity that will likely make this harder to understand rather tha= n easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying the INVIT= E will be rejected because the relying party makes an authorization decisio= n based on the attributes in the token. It's more like an INVITE being rejected because a user agent can't = supply an Authorization header. I will reiterate that I don't think the kin= ds of attributes you are proposing should be in the scope of an effort that= will try to address a framework for authorizing SIP requests. I don't think the values of the attributes (= as opposed to the mere presence of some attributes) have anything to do wit= h authorizing the SIP request that you propose would carry the attributes.<= /div>

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting conference = policy on the fly that happens to require the kind of attributes you want, = and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lot of thi= nking about this since the days of RFC4579) than it does with defining a fr= amework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Thursday, June 16, 2016 at 6:= 19 AM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] SIP AuthNZ P= roblem Statement - v3

The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
 Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to common gr= ound.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the two a= ttributes you specified - constraints on conference size and media types - = have nothing to do with the authorization of the INVITE carrying those attr= ibutes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposing is ove= rloading the INVITE to tunnel conference policy constraints to the focus. I= mean, maybe that's a problem space worth investigating, though I suspect t= here are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map well= onto dialog-forming SIP requests. But I think that conference policy provi= sioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.  The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different pro= blem space entirely from figuring out how to implement attribute-based auth= orization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
 Rifaat


 --_000_D38F19C319F959jonpetersonneustarbiz_-- From nobody Tue Jun 21 16:50:20 2016 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 A2BBE12D85B for ; Tue, 21 Jun 2016 16:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 7ZxkM7Xun_aZ for ; Tue, 21 Jun 2016 16:50:15 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 A422612D75B for ; Tue, 21 Jun 2016 16:50:15 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id a5so86991424ita.1 for ; Tue, 21 Jun 2016 16:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OQZNsIEkfJk730G4V/wjhn+AHsIkSU9KkItcAs00vqY=; b=P43jLZujR+TyLd+XL5XO+ZO7qJWcyB2DO7Q6tb37V+om846ivHQZVTy2zFSnfpvLaq vR+YV94EnRFQKcUYKLR0p5wjScga/Zt0+AeG6Qqn6LlNbRAJvDpIumqTUmGRWXqRJtOZ QTanJ1J8lC+PuaP62/rutv/xnP70+N4NSBxb2n7uR3mGOTQjwW1S9Op2GvhbmyKSizsK 5NKKuihhCE9dUcCRLuKk1GCHwX+kPNMv9jP+mb51kqufvj94ZCynyFnREnZUEFP92dG0 WUY2J1NB0dnQGJ6839Aa5AvT18my0n/NjJs2y1TtuajO7Xo6czec8lpKBamarxeSb5OQ EYwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OQZNsIEkfJk730G4V/wjhn+AHsIkSU9KkItcAs00vqY=; b=CPJ+AXNxIKWgB74dvYWNlXvymzHIN3fDy+v9kr7gDxierTNwj7q3x9j0BnWval5CDq vnHJ76srNuHqoud1Ay+kng+LAOwaIRELrHF/yZqitNqV8ZvRf63cAiQoCTSHAsNFRLDf Q778oByM9vk87NAARmzNLlUIZvUSOAVtueHe2DNTPOrVyolUClf4G2hmDGLJZsn/nyKL w69AUMXM8sq5mNUII1e2Cq8aS0DbliOkWSvyy4anvJlCva5v07UxeYMS6eW5TcqNlIzh aKzuQiN+jNRB43UIWpZoj/aw1rWgpbowbI5oowgwHK08gpYLD/5dtsxZ8TV/H8OoBT0K jjnA== X-Gm-Message-State: ALyK8tL0AcbsUvDtaAUk08voWK7fcI3T9M0b2CosuTmSatp3L8JB450FM0bOzt8fCzFabQ== X-Received: by 10.36.37.73 with SMTP id g70mr9777883itg.51.1466553014856; Tue, 21 Jun 2016 16:50:14 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id 41sm16104449iod.43.2016.06.21.16.50.14 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 16:50:14 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id h190so27419282ith.1 for ; Tue, 21 Jun 2016 16:50:14 -0700 (PDT) X-Received: by 10.36.152.67 with SMTP id n64mr10382060itd.18.1466553013941; Tue, 21 Jun 2016 16:50:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Tue, 21 Jun 2016 16:50:13 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 21 Jun 2016 19:50:13 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c05abe8711c520535d27ba0 Archived-At: Cc: "sipcore@ietf.org" , Rifaat Shekh-Yusef Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:50:17 -0000 --94eb2c05abe8711c520535d27ba0 Content-Type: text/plain; charset=UTF-8 Furthermore, reading all of this, I cannot understand why Authorization token cannot be a part of SIP URL, either as user part or URL parameter. This does not need to be anything more then service specific URL and does not require a new SIP header or authentication mechanism. _____________ Roman Shpount On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon wrote: > > It's not really what I'm looking for, no, and after mulling this over a > bit, I fear going farther along this path would only drill down into levels > of complexity that will likely make this harder to understand rather than > easier. > > I do acknowledge that you describe the INVITE as being rejected if it > doesn't contain a token - but that's not the same thing as saying the > INVITE will be rejected because the relying party makes an authorization > decision based on the attributes in the token. It's more like an INVITE > being rejected because a user agent can't supply an Authorization header. I > will reiterate that I don't think the kinds of attributes you are proposing > should be in the scope of an effort that will try to address a framework > for authorizing SIP requests. I don't think the values of the attributes > (as opposed to the mere presence of some attributes) have anything to do > with authorizing the SIP request that you propose would carry the > attributes. > > With regards to this whole conferencing example, it does seem a bit > contrived to me, like you're sketching a SIP-based way of setting > conference policy on the fly that happens to require the kind of attributes > you want, and then saying that demonstrates the need for the attributes. > The fact that all of the ways to do conference policy we can point to in > fact do it via the web makes it hard for me to understand why we should > create a SIP-based way of doing this. To me, it looks like you're opening a > problem space that has much more to do with reshaping the way that SIP does > conferences (and again, as Radhika's mail pointing out, there's been a lot > of thinking about this since the days of RFC4579) than it does with > defining a framework for authorizing SIP requests. > > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Thursday, June 16, 2016 at 6:19 AM > To: Jon Peterson > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 > > The attributes I provided are examples of attributes that might be > provided in an access token; it was not meant to include all the attributes > for this use case, because my intention was not to focus on conference > server, but to discuss the idea in general. > > The following could be used with the conference factory to request a > conference focus: > The INVITE sent to the conference factory could include a token that has a * > conference-type* attribute which could take one of the following values: *audio, > video, webconference, audio-webconference, or video-webconference*. > The conference factory will then issue a *conference uri* for the > requested conference type, assuming the token is valid. If the > *conference-type* attribute is missing, then the request would be > rejected. > > Is that what you are looking for? > > Regards, > Rifaat > > > > > > On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon > wrote: > >> >>> >>> In that case, if you could furnish a use case with attributes that would >>> be carried in a SIP iNVITE that are actually salient to the authorization >>> of that particular SIP request, we'd be getting a lot closer to common >>> ground. >>> >>> >> An obvious example would be an INVITE with a token sent to a conference >> factory to authorize the creation of a focus. >> >> >> We're still talking past each other. My point above was that the two >> attributes you specified - constraints on conference size and media types - >> have nothing to do with the authorization of the INVITE carrying those >> attributes. Like, unless the conference size permitted is 0, then the >> INVITE that creates an ad hoc conference and connects you to its bridge is >> not going to be rejected by the focus on the basis of that conference size >> attribute. If the maximum conference size were 0, the AuthZ service just >> wouldn't attach a token to an INVITE as it would never be allowed to start >> a conference. Same goes for media types. >> >> Instead, what your two attributes constrain is what happens after the >> conference is created: when ten users try to dial in to a conference with a >> permitted size of nine, say. That tenth INVITE would get rejected - not the >> conference-forming INVITE that you propose would carry the token. That's >> why what you're proposing is overloading the INVITE to tunnel conference >> policy constraints to the focus. I mean, maybe that's a problem space worth >> investigating, though I suspect there are good reasons why RFC4353 >> specified that conference policy is not manipulated with SIP - mostly >> because the semantics of manipulating conference policy probably don't map >> well onto dialog-forming SIP requests. But I think that conference policy >> provisioning problem space would be pretty far from where we started in >> this discussion. >> >> Let me reiterate what I wrote in my previous mail, which I quote here at >> the top: "furnish a use case with attributes that would be carried in a SIP >> iNVITE that are actually salient to the authorization of that particular >> SIP request." Again: "that particular SIP request." Not later transactions >> in some broader context in which the original user agent probably isn't >> even an endpoint. >> >> The Authorization header in SIP, for example, is actually used by the UAS >> to make a decision about whether or not to authorize the request in which >> the header appears. The token that you propose a SIP INVITE would carry in >> this case is not used by the relying party to make a decision about whether >> or not that INVITE is authorized. That's why I believe this conference >> policy issue is a different problem space entirely from figuring out how to >> implement attribute-based authorization for SIP requests. >> >> Jon Peterson >> Neustar, Inc. >> >> >> Regards, >> Rifaat >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --94eb2c05abe8711c520535d27ba0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Furthermore, reading all of this, I cannot understand why = Authorization token cannot be a part of SIP URL, either as user part or URL= parameter. This does not need to be anything more then service specific UR= L and does not require a new SIP header or authentication mechanism.
<= div class=3D"gmail_extra">
_____________
Roman Shpount

On Tue, Jun 21, 2016 at 7:46 PM, Peterson, J= on <jon.peterson@neustar.biz> wrote:

It's not really what I'm looking for, no, and after mulling th= is over a bit, I fear going farther along this path would only drill down i= nto levels of complexity that will likely make this harder to understand ra= ther than easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying t= he INVITE will be rejected because the relying party makes an authorization= decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent ca= n't supply an Authorization header. I will reiterate that I don't t= hink the kinds of attributes you are proposing should be in the scope of an= effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attribut= es (as opposed to the mere presence of some attributes) have anything to do= with authorizing the SIP request that you propose would carry the attribut= es.

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting confere= nce policy on the fly that happens to require the kind of attributes you wa= nt, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lo= t of thinking about this since the days of RFC4579) than it does with defin= ing a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.


The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the t= wo attributes you specified - constraints on conference size and media type= s - have nothing to do with the authorization of the INVITE carrying those = attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--94eb2c05abe8711c520535d27ba0-- From nobody Tue Jun 21 19:28:29 2016 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 C001A12D87C; Tue, 21 Jun 2016 19:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7xKYb5zF0QN3; Tue, 21 Jun 2016 19:28:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B5A12DAE9; Tue, 21 Jun 2016 19:28:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ee-5769f7c63a0d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.AA.18043.6C7F9675; Wed, 22 Jun 2016 04:28:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 04:28:22 +0200 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" , Ben Campbell Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkAgABAuACAABb4AIAAxKC3 Date: Wed, 22 Jun 2016 02:28:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com>, <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> In-Reply-To: <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380FB854ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7iu6x75nhBvf3q1rM7zzNbrH69SxW i7lT/Cy+/tjE5sDiMeX3RlaPJUt+MnnM2vmEJYA5issmJTUnsyy1SN8ugSuj45hqwfGIilP3 tjE3MB736mLk5JAQMJGY2TaXCcIWk7hwbz1bFyMXh5DAEUaJj3eXMkI4Sxglrn76y9rFyMHB JmAh0f1PG6RBRCBSYsHXbawgNcwCExklzp+cDjZJWMBD4tGhfYwQRZ4SF39vZAfpFRFwk9iy PBMkzCKgKnHuSDcLiM0r4CvxYFsnG4gtJHCVUWLh9RgQm1PAVuLnhE5WEJsR6Ljvp9aAjWcW EJdo+rKSFeJoAYkle84zQ9iiEi8f/2OFqMmXmH3zFTvEfEGJkzOfsExgFJmFpH0WkrJZSMog 4gYSX97fhrK1JZYtfM0MYetLdL8/zYQsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YMQd3PLbagfjweeOhxgFOBiVeHgf7MgMF2JNLCuuzD3EKMHBrCTCu/ITUIg3JbGyKrUoP76o NCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVANj5o4XFzNc3zpyrHzyIX6NhCan e2LSl+K32SVfP678tN9UfE/opT0+cvLvbGT5i6ME3OLMy7YViXzlDpayjis27LRiiM7ayJyS 2y1rPfWm3P/qysfWG7MSr52as1rCRKmaYcIFhj+vm95tFZj4YKvTrdueRpN2ZGxPdbtZfSX6 pFLt2YJzOXJKLMUZiYZazEXFiQC6vzRFtAIAAA== Archived-At: Cc: SIPCORE , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 02:28:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380FB854ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We can add the text. Regards, Christer Sent from my Windows Phone ________________________________ From: Gonzalo Salgueiro (gsalguei) Sent: =FD21/=FD06/=FD2016 19:44 To: Ben Campbell Cc: Christer Holmberg; draft-holmber= g-dispatch-rfc7315-updates.all@ietf.org; SIPCORE Subject: Re: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 > On Jun 21, 2016, at 11:22 AM, Ben Campbell wrote: > > That's a good start, but don't be surprised if we get questions specifica= lly about adding NPLI to ACK requests. some language to the effect of the f= ollowing might help: > > "This document adds the ability to include P-Access-Network-Info in ACK r= equests. As documented in RFC7315, P-Access-Network-Info may include privac= y sensitive information, including the user's location. The security and pr= ivacy considerations for P-Access-Network-Info in ACK requests are similar = to those for the other SIP requests discussed in RFC7315.=94 I=92m fine with adding such text. Christer - Can we append this to your proposed text? Gonzalo > > Thanks! > > Ben. > > On 21 Jun 2016, at 3:26, Christer Holmberg wrote: > >> Hi Ben, >> >> See inline. >> >>> -------------- >>> >>> Substantive: >>> >>> The security considerations state that the draft removes some places >>> that some of the P-Headers can be sent, but expands that to some other >>> places. Further, it says that neither introduce new security >>> considerations beyond those in 7315. >>> >>> I accept that for the reduction part. But I'm not sure we can state tha= t >>> sort of thing for the expansion part, at least without some more >>> discussion. Since 7315 already acknowledges potential privacy issues >>> around P-Access-Network-Info, I'd like to at least see a sentence or tw= o >>> about the allowance of that in ACK requests, even if they just say that >>> this addition makes things no worse than they already are. >> >> >> OLD: >> >> The security considerations for P- header fields are defined in >> [RFC7315]. This specification allows some header fields to be >> present in messages where they were previously not allowed, and >> disallow some header fields to be present in messages where they were >> previously allowed. That does not cause any security issues, but >> implementations need to be aware that implementations may not have >> been updated according to this document, and take proper actions if a >> header field occur, or does not occur, in a message where it should >> occur (or occurs in a message where it should not occur). >> >> >> >> NEW: >> >> The security considerations for these P- header fields are defined in >> [RFC7315]. This specification allows some header fields to be >> present in messages where they were previously not allowed, and the >> security considerations and assumptions (e.g. regarding only sending >> Information to trusted entities) also to those messages. In addition, >> this specification also disallow some header fields to be present >> in message where they were previously allowed. That does not cause >> any security issues, but implementations need to be aware that >> implementations may not have been updated according to this document, >> and take proper actions if a header field occur, or does not occur, >> in a message where it should occur (or occurs in a message where it >> should not occur). >> >> >> >>> Editorial: >>> >>> -5, first sentence: "The security considerations for P- header fields >>> are defined in >>> [RFC7315]" >>> I assume this means 7315 discusses the security considerations for thes= e >>> P-Headers specifically, not P-Headers in general. Is this the intent? I= f >>> so, I suggest: >>> >>> s/... for P-header fields.../ ... for these P-header fields... >> >> I=B9ll fix as suggested (ass new text above). >> >> Regards, >> >> Christer --_000_7594FB04B1934943A5C02806D1A2204B380FB854ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We can add the text.

Regards,

Christer

Sent from my Windows Phone
From: Gonzalo Salgueiro (gsalguei) Sent: =FD21= /=FD06/=FD2016 19:44
To: Ben Campbell
Cc: Christer Holmberg; dra= ft-holmberg-dispatch-rfc7315-updates.all@ietf.org; SIPCORE
Subject: Re: A= D Evaluation of draft-holmberg-dispatch-rfc7315-updates-06


> On Jun 21, 2016, at 11:22 AM, Ben Campbell <ben@nostrum.com> wro= te:
>
> That's a good start, but don't be surprised if we get questions specif= ically about adding NPLI to ACK requests. some language to the effect of th= e following might help:
>
> "This document adds the ability to include P-Access-Network-Info = in ACK requests. As documented in RFC7315, P-Access-Network-Info may includ= e privacy sensitive information, including the user's location. The securit= y and privacy considerations for P-Access-Network-Info in ACK requests are similar to those for the other SIP requests discussed = in RFC7315.=94

I=92m fine with adding such text.

Christer - Can we append this to your proposed text?

Gonzalo


>
> Thanks!
>
> Ben.
>
> On 21 Jun 2016, at 3:26, Christer Holmberg wrote:
>
>> Hi Ben,
>>
>> See inline.
>>
>>> --------------
>>>
>>> Substantive:
>>>
>>> The security considerations state that the draft removes some = places
>>> that some of the P-Headers can be sent, but expands that to so= me other
>>> places. Further, it says that neither introduce new security >>> considerations beyond those in 7315.
>>>
>>> I accept that for the reduction part. But I'm not sure we can = state that
>>> sort of thing for the expansion part, at least without some mo= re
>>> discussion. Since 7315 already acknowledges potential privacy = issues
>>> around P-Access-Network-Info, I'd like to at least see a sente= nce or two
>>> about the allowance of that in ACK requests, even if they just= say that
>>> this addition makes things no worse than they already are.
>>
>>
>> OLD:
>>
>> The security considerations for P- header fields are defined in >>   [RFC7315].  This specification allows some header= fields to be
>>   present in messages where they were previously not all= owed, and
>>   disallow some header fields to be present in messages = where they were
>>   previously allowed. That does not cause any security i= ssues, but
>>   implementations need to be aware that implementations = may not have
>>   been updated according to this document, and take prop= er actions if a
>>   header field occur, or does not occur, in a message wh= ere it should
>>   occur (or occurs in a message where it should not occu= r).
>>
>>
>>
>> NEW:
>>
>> The security considerations for these P- header fields are defined= in
>>   [RFC7315].  This specification allows some header= fields to be
>>   present in messages where they were previously not all= owed, and the
>> security considerations and assumptions (e.g. regarding only sendi= ng
>> Information to trusted entities) also to those messages. In additi= on,
>> this specification also disallow some header fields to be present<= br> >> in message where they were previously allowed. That does not cause=
>> any security issues, but implementations need to be aware that
>> implementations may not have been updated according to this docume= nt,
>> and take proper actions if a header field occur, or does not occur= ,
>> in a message where it should occur (or occurs in a message where i= t
>> should not occur).
>>
>>
>>
>>> Editorial:
>>>
>>> -5, first sentence: "The security considerations for P- h= eader fields
>>> are defined in
>>>   [RFC7315]"
>>> I assume this means 7315 discusses the security considerations= for these
>>> P-Headers specifically, not P-Headers in general. Is this the = intent? If
>>> so, I suggest:
>>>
>>> s/... for P-header fields.../ ... for these P-header fields...=
>>
>> I=B9ll fix as suggested (ass new text above).
>>
>> Regards,
>>
>> Christer

 --_000_7594FB04B1934943A5C02806D1A2204B380FB854ESESSMB209erics_-- From nobody Wed Jun 22 00:19:08 2016 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 1C3B412D17A; Wed, 22 Jun 2016 00:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QzpD9DC_WlaQ; Wed, 22 Jun 2016 00:19:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BC912D0E5; Wed, 22 Jun 2016 00:19:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-69-576a3be2cece Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.A8.18043.2EB3A675; Wed, 22 Jun 2016 09:18:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 09:18:58 +0200 From: Christer Holmberg To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" , Ben Campbell Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkAgABAuACAABb4AIAAxKC3gABjCAA= Date: Wed, 22 Jun 2016 07:18:57 +0000 Message-ID: References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D3901671B451christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7nO4j66xwg0WvTC3md55mt1j9ehar xdwpfhZff2xic2DxmPJ7I6vHkiU/mTxm7XzCEsAcxWWTkpqTWZZapG+XwJVx4+0k9oLl5xkr jm6+wN7A+OIkYxcjB4eEgInE0rWSXYycQKaYxIV769m6GLk4hASOMEqsarnFAuEsYZTYtmUK M0gDm4CFRPc/bZC4iEAvo8TXqRvAipgFJjJKnD85nQlklLCAh8Tc2XfAbBEBT4mLvzeyQ9h+ Em3b1rGB2CwCqhLXJ/wHi/MKWEksW9EMtW02k8TzeSuZQRKcQA3TW/aA2YxA930/tQZsKLOA uMStJ/OZIO4WkFiy5zwzhC0q8fLxP1YQW1RAT+LLvXlQbypKLO+Xg2iNl3h8fhULxF5BiZMz n7BMYBSbhWTqLCRls5CUQcS1JL782McGYStKTOl+yD4LaAOzgKbEm4e1EGFriVtbJqMoWcDI sYpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMH4PbvlttYPx4HPHQ4wCHIxKPLwPdmSGC7Em lhVX5h5ilOBgVhLhTbHMChfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUg tQgmy8TBKdXAGH/31lvr+h0Lz63f62EczBjlyjVbi6tCUPHCf45lknHqQVvOZTsf2jR5q8dv Yf+0V2l+FWGP879bel+c0ndby8lB4L6mYvjkuboBhtmRvFfyfpoYfeM9Zrbz/y+phljv9cYF /+InHeHO/Pdy/b3jobOsjxv6JM366yy9XP6NqbbOlUOZNstfKLEUZyQaajEXFScCAAVc5x3b AgAA Archived-At: Cc: SIPCORE , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 07:19:06 -0000 --_000_D3901671B451christerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCk5FVzoNCg0KICAgobFUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZXNl IFAtIGhlYWRlciBmaWVsZHMgYXJlIGRlZmluZWQgaW4NCiAgIFtSRkM3MzE1XS4gIFRoaXMgc3Bl Y2lmaWNhdGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlDQogICBwcmVzZW50IGlu IG1lc3NhZ2VzIHdoZXJlIHRoZXkgd2VyZSBwcmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQgdGhl DQogICBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgYXNzdW1wdGlvbnMgKGUuZy4gcmVnYXJk aW5nIG9ubHkgc2VuZGluZw0KICAgSW5mb3JtYXRpb24gdG8gdHJ1c3RlZCBlbnRpdGllcykgYWxz byB0byB0aG9zZSBtZXNzYWdlcy4gSW4gYWRkaXRpb24sDQogICB0aGlzIHNwZWNpZmljYXRpb24g YWxzbyBkaXNhbGxvdyBzb21lIGhlYWRlciBmaWVsZHMgdG8gYmUgcHJlc2VudA0KICAgaW4gbWVz c2FnZSB3aGVyZSB0aGV5IHdlcmUgcHJldmlvdXNseSBhbGxvd2VkLiBUaGF0IGRvZXMgbm90IGNh dXNlDQogICBhbnkgc2VjdXJpdHkgaXNzdWVzLCBidXQgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8g YmUgYXdhcmUgdGhhdA0KICAgaW1wbGVtZW50YXRpb25zIG1heSBub3QgaGF2ZSBiZWVuIHVwZGF0 ZWQgYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsDQogICBhbmQgdGFrZSBwcm9wZXIgYWN0aW9u cyBpZiBhIGhlYWRlciBmaWVsZCBvY2N1ciwgb3IgZG9lcyBub3Qgb2NjdXIsDQogICBpbiBhIG1l c3NhZ2Ugd2hlcmUgaXQgc2hvdWxkIG9jY3VyIChvciBvY2N1cnMgaW4gYSBtZXNzYWdlIHdoZXJl IGl0DQogICBzaG91bGQgbm90IG9jY3VyKS4gVGhpcyBkb2N1bWVudCBhZGRzIHRoZSBhYmlsaXR5 IHRvIGluY2x1ZGUNCiAgIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBpbiBBQ0sgcmVxdWVzdHMuIEFz IGRvY3VtZW50ZWQgaW4gIFtSRkM3MzE1XSwNCiAgIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBtYXkg aW5jbHVkZSBwcml2YWN5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nDQogICB0aGUg dXNlcidzIGxvY2F0aW9uLiBUaGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnMg Zm9yDQogICBQLUFjY2Vzcy1OZXR3b3JrLUluZm8gaW4gQUNLIHJlcXVlc3RzIGFyZSBzaW1pbGFy IHRvIHRob3NlIGZvciB0aGUgb3RoZXINCiAgIFNJUCByZXF1ZXN0cyBkaXNjdXNzZWQgaW4gIFtS RkM3MzE1XS6hsQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXkgMjIgSnVuZSAyMDE2IGF0IDA1 OjI4DQpUbzogImdzYWxndWVpQGNpc2NvLmNvbTxtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tPiIg PGdzYWxndWVpQGNpc2NvLmNvbTxtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tPj4sIEJlbiBDYW1w YmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KQ2M6ICJkcmFm dC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnPG1haWx0bzpk cmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnPiIgPGRy YWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy5hbGxAaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy5hbGxAaWV0Zi5vcmc+Piwg InNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+IiA8c2lwY29yZUBpZXRm Lm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogQUQgRXZhbHVhdGlv biBvZiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMtMDYNClJlc2VudC1G cm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWxpYXMtYm91bmNlc0BpZXRmLm9y Zz4+DQpSZXNlbnQtVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+LCBOZXZlbmth IEJpb25kaWMgPG5ldmVua2EuYmlvbmRpY0Blcmljc3Nvbi5jb208bWFpbHRvOm5ldmVua2EuYmlv bmRpY0Blcmljc3Nvbi5jb20+PiwgImdzYWxndWVpQGNpc2NvLmNvbTxtYWlsdG86Z3NhbGd1ZWlA Y2lzY28uY29tPiIgPGdzYWxndWVpQGNpc2NvLmNvbTxtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29t Pj4sIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+ PiwgIkEuIE1haG9uZXkiIDxtYWhvbmV5QG5vc3RydW0uY29tPG1haWx0bzptYWhvbmV5QG5vc3Ry dW0uY29tPj4NClJlc2VudC1EYXRlOiBXZWRuZXNkYXkgMjIgSnVuZSAyMDE2IGF0IDA1OjI4DQoN CkhpLA0KDQpXZSBjYW4gYWRkIHRoZSB0ZXh0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpT ZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSk8bWFpbHRvOmdzYWxndWVpQGNp c2NvLmNvbT4NClNlbnQ6IDIxLzA2LzIwMTYgMTk6NDQNClRvOiBCZW4gQ2FtcGJlbGw8bWFpbHRv OmJlbkBub3N0cnVtLmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11 cGRhdGVzLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMx NS11cGRhdGVzLmFsbEBpZXRmLm9yZz47IFNJUENPUkU8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1y ZmM3MzE1LXVwZGF0ZXMtMDYNCg0KDQo+IE9uIEp1biAyMSwgMjAxNiwgYXQgMTE6MjIgQU0sIEJl biBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PiB3cm90 ZToNCj4NCj4gVGhhdCdzIGEgZ29vZCBzdGFydCwgYnV0IGRvbid0IGJlIHN1cnByaXNlZCBpZiB3 ZSBnZXQgcXVlc3Rpb25zIHNwZWNpZmljYWxseSBhYm91dCBhZGRpbmcgTlBMSSB0byBBQ0sgcmVx dWVzdHMuIHNvbWUgbGFuZ3VhZ2UgdG8gdGhlIGVmZmVjdCBvZiB0aGUgZm9sbG93aW5nIG1pZ2h0 IGhlbHA6DQo+DQo+ICJUaGlzIGRvY3VtZW50IGFkZHMgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBQ LUFjY2Vzcy1OZXR3b3JrLUluZm8gaW4gQUNLIHJlcXVlc3RzLiBBcyBkb2N1bWVudGVkIGluIFJG QzczMTUsIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBtYXkgaW5jbHVkZSBwcml2YWN5IHNlbnNpdGl2 ZSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIHRoZSB1c2VyJ3MgbG9jYXRpb24uIFRoZSBzZWN1cml0 eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBmb3IgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGlu IEFDSyByZXF1ZXN0cyBhcmUgc2ltaWxhciB0byB0aG9zZSBmb3IgdGhlIG90aGVyIFNJUCByZXF1 ZXN0cyBkaXNjdXNzZWQgaW4gUkZDNzMxNS6hsQ0KDQpJoa9tIGZpbmUgd2l0aCBhZGRpbmcgc3Vj aCB0ZXh0Lg0KDQpDaHJpc3RlciAtIENhbiB3ZSBhcHBlbmQgdGhpcyB0byB5b3VyIHByb3Bvc2Vk IHRleHQ/DQoNCkdvbnphbG8NCg0KDQo+DQo+IFRoYW5rcyENCj4NCj4gQmVuLg0KPg0KPiBPbiAy MSBKdW4gMjAxNiwgYXQgMzoyNiwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+DQo+PiBIaSBC ZW4sDQo+Pg0KPj4gU2VlIGlubGluZS4NCj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+ IFN1YnN0YW50aXZlOg0KPj4+DQo+Pj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHN0YXRl IHRoYXQgdGhlIGRyYWZ0IHJlbW92ZXMgc29tZSBwbGFjZXMNCj4+PiB0aGF0IHNvbWUgb2YgdGhl IFAtSGVhZGVycyBjYW4gYmUgc2VudCwgYnV0IGV4cGFuZHMgdGhhdCB0byBzb21lIG90aGVyDQo+ Pj4gcGxhY2VzLiBGdXJ0aGVyLCBpdCBzYXlzIHRoYXQgbmVpdGhlciBpbnRyb2R1Y2UgbmV3IHNl Y3VyaXR5DQo+Pj4gY29uc2lkZXJhdGlvbnMgYmV5b25kIHRob3NlIGluIDczMTUuDQo+Pj4NCj4+ PiBJIGFjY2VwdCB0aGF0IGZvciB0aGUgcmVkdWN0aW9uIHBhcnQuIEJ1dCBJJ20gbm90IHN1cmUg d2UgY2FuIHN0YXRlIHRoYXQNCj4+PiBzb3J0IG9mIHRoaW5nIGZvciB0aGUgZXhwYW5zaW9uIHBh cnQsIGF0IGxlYXN0IHdpdGhvdXQgc29tZSBtb3JlDQo+Pj4gZGlzY3Vzc2lvbi4gU2luY2UgNzMx NSBhbHJlYWR5IGFja25vd2xlZGdlcyBwb3RlbnRpYWwgcHJpdmFjeSBpc3N1ZXMNCj4+PiBhcm91 bmQgUC1BY2Nlc3MtTmV0d29yay1JbmZvLCBJJ2QgbGlrZSB0byBhdCBsZWFzdCBzZWUgYSBzZW50 ZW5jZSBvciB0d28NCj4+PiBhYm91dCB0aGUgYWxsb3dhbmNlIG9mIHRoYXQgaW4gQUNLIHJlcXVl c3RzLCBldmVuIGlmIHRoZXkganVzdCBzYXkgdGhhdA0KPj4+IHRoaXMgYWRkaXRpb24gbWFrZXMg dGhpbmdzIG5vIHdvcnNlIHRoYW4gdGhleSBhbHJlYWR5IGFyZS4NCj4+DQo+Pg0KPj4gT0xEOg0K Pj4NCj4+IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgUC0gaGVhZGVyIGZpZWxkcyBh cmUgZGVmaW5lZCBpbg0KPj4gICBbUkZDNzMxNV0uICBUaGlzIHNwZWNpZmljYXRpb24gYWxsb3dz IHNvbWUgaGVhZGVyIGZpZWxkcyB0byBiZQ0KPj4gICBwcmVzZW50IGluIG1lc3NhZ2VzIHdoZXJl IHRoZXkgd2VyZSBwcmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQNCj4+ICAgZGlzYWxsb3cgc29t ZSBoZWFkZXIgZmllbGRzIHRvIGJlIHByZXNlbnQgaW4gbWVzc2FnZXMgd2hlcmUgdGhleSB3ZXJl DQo+PiAgIHByZXZpb3VzbHkgYWxsb3dlZC4gVGhhdCBkb2VzIG5vdCBjYXVzZSBhbnkgc2VjdXJp dHkgaXNzdWVzLCBidXQNCj4+ICAgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgYXdhcmUgdGhh dCBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBoYXZlDQo+PiAgIGJlZW4gdXBkYXRlZCBhY2NvcmRp bmcgdG8gdGhpcyBkb2N1bWVudCwgYW5kIHRha2UgcHJvcGVyIGFjdGlvbnMgaWYgYQ0KPj4gICBo ZWFkZXIgZmllbGQgb2NjdXIsIG9yIGRvZXMgbm90IG9jY3VyLCBpbiBhIG1lc3NhZ2Ugd2hlcmUg aXQgc2hvdWxkDQo+PiAgIG9jY3VyIChvciBvY2N1cnMgaW4gYSBtZXNzYWdlIHdoZXJlIGl0IHNo b3VsZCBub3Qgb2NjdXIpLg0KPj4NCj4+DQo+Pg0KPj4gTkVXOg0KPj4NCj4+IFRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlc2UgUC0gaGVhZGVyIGZpZWxkcyBhcmUgZGVmaW5lZCBp bg0KPj4gICBbUkZDNzMxNV0uICBUaGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHNvbWUgaGVhZGVy IGZpZWxkcyB0byBiZQ0KPj4gICBwcmVzZW50IGluIG1lc3NhZ2VzIHdoZXJlIHRoZXkgd2VyZSBw cmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQgdGhlDQo+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBhbmQgYXNzdW1wdGlvbnMgKGUuZy4gcmVnYXJkaW5nIG9ubHkgc2VuZGluZw0KPj4gSW5mb3Jt YXRpb24gdG8gdHJ1c3RlZCBlbnRpdGllcykgYWxzbyB0byB0aG9zZSBtZXNzYWdlcy4gSW4gYWRk aXRpb24sDQo+PiB0aGlzIHNwZWNpZmljYXRpb24gYWxzbyBkaXNhbGxvdyBzb21lIGhlYWRlciBm aWVsZHMgdG8gYmUgcHJlc2VudA0KPj4gaW4gbWVzc2FnZSB3aGVyZSB0aGV5IHdlcmUgcHJldmlv dXNseSBhbGxvd2VkLiBUaGF0IGRvZXMgbm90IGNhdXNlDQo+PiBhbnkgc2VjdXJpdHkgaXNzdWVz LCBidXQgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgYXdhcmUgdGhhdA0KPj4gaW1wbGVtZW50 YXRpb25zIG1heSBub3QgaGF2ZSBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1l bnQsDQo+PiBhbmQgdGFrZSBwcm9wZXIgYWN0aW9ucyBpZiBhIGhlYWRlciBmaWVsZCBvY2N1ciwg b3IgZG9lcyBub3Qgb2NjdXIsDQo+PiBpbiBhIG1lc3NhZ2Ugd2hlcmUgaXQgc2hvdWxkIG9jY3Vy IChvciBvY2N1cnMgaW4gYSBtZXNzYWdlIHdoZXJlIGl0DQo+PiBzaG91bGQgbm90IG9jY3VyKS4N Cj4+DQo+Pg0KPj4NCj4+PiBFZGl0b3JpYWw6DQo+Pj4NCj4+PiAtNSwgZmlyc3Qgc2VudGVuY2U6 ICJUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIFAtIGhlYWRlciBmaWVsZHMNCj4+PiBh cmUgZGVmaW5lZCBpbg0KPj4+ICAgW1JGQzczMTVdIg0KPj4+IEkgYXNzdW1lIHRoaXMgbWVhbnMg NzMxNSBkaXNjdXNzZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZQ0KPj4+ IFAtSGVhZGVycyBzcGVjaWZpY2FsbHksIG5vdCBQLUhlYWRlcnMgaW4gZ2VuZXJhbC4gSXMgdGhp cyB0aGUgaW50ZW50PyBJZg0KPj4+IHNvLCBJIHN1Z2dlc3Q6DQo+Pj4NCj4+PiBzLy4uLiBmb3Ig UC1oZWFkZXIgZmllbGRzLi4uLyAuLi4gZm9yIHRoZXNlIFAtaGVhZGVyIGZpZWxkcy4uLg0KPj4N Cj4+IEmp9mxsIGZpeCBhcyBzdWdnZXN0ZWQgKGFzcyBuZXcgdGV4dCBhYm92ZSkuDQo+Pg0KPj4g UmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KDQo= --_000_D3901671B451christerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <51DC1F3B4A4D3446B1C684DA6A3DEF7C@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5I aSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+TkVXOjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+Jm5ic3A7ICZuYnNw OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPqGxPC9zcGFu PlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlc2UgUC0gaGVhZGVyIGZpZWxkcyBh cmUgZGVmaW5lZCBpbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3Rh bmRhcmQ7Ij4mbmJzcDsmbmJzcDsgW1JGQzczMTVdLiZuYnNwOyZuYnNwO1RoaXMgc3BlY2lmaWNh dGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyZuYnNwOyBwcmVzZW50IGluIG1l c3NhZ2VzIHdoZXJlIHRoZXkgd2VyZSBwcmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQgdGhlPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyAm bmJzcDtzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgYXNzdW1wdGlvbnMgKGUuZy4gcmVnYXJk aW5nIG9ubHkgc2VuZGluZzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij4mbmJzcDsgJm5ic3A7SW5mb3JtYXRpb24gdG8gdHJ1c3RlZCBlbnRpdGllcykg YWxzbyB0byB0aG9zZSBtZXNzYWdlcy4gSW4gYWRkaXRpb24sPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyAmbmJzcDt0aGlzIHNwZWNpZmlj YXRpb24gYWxzbyBkaXNhbGxvdyBzb21lIGhlYWRlciBmaWVsZHMgdG8gYmUgcHJlc2VudDwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij4mbmJzcDsgJm5i c3A7aW4gbWVzc2FnZSB3aGVyZSB0aGV5IHdlcmUgcHJldmlvdXNseSBhbGxvd2VkLiBUaGF0IGRv ZXMgbm90IGNhdXNlPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFu ZGFyZDsiPiZuYnNwOyAmbmJzcDthbnkgc2VjdXJpdHkgaXNzdWVzLCBidXQgaW1wbGVtZW50YXRp b25zIG5lZWQgdG8gYmUgYXdhcmUgdGhhdDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij4mbmJzcDsgJm5ic3A7aW1wbGVtZW50YXRpb25zIG1heSBub3Qg aGF2ZSBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyAmbmJzcDthbmQg dGFrZSBwcm9wZXIgYWN0aW9ucyBpZiBhIGhlYWRlciBmaWVsZCBvY2N1ciwgb3IgZG9lcyBub3Qg b2NjdXIsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsi PiZuYnNwOyAmbmJzcDtpbiBhIG1lc3NhZ2Ugd2hlcmUgaXQgc2hvdWxkIG9jY3VyIChvciBvY2N1 cnMgaW4gYSBtZXNzYWdlIHdoZXJlIGl0PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPiZuYnNwOyAmbmJzcDtzaG91bGQgbm90IG9jY3VyKS4mbmJzcDs8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5UaGlzIGRvY3Vt ZW50IGFkZHMgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Jm5ic3A7ICZuYnNwO1AtQWNjZXNzLU5ldHdv cmstSW5mbyBpbiBBQ0sgcmVxdWVzdHMuIEFzIGRvY3VtZW50ZWQgaW4mbmJzcDs8L3NwYW4+Jm5i c3A7W1JGQzczMTVdPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyI+LCZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN0YW5kYXJkOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyI+Jm5ic3A7ICZuYnNwO1AtQWNjZXNzLU5ldHdvcmstSW5mbyBtYXkgaW5jbHVkZSBwcml2YWN5 IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mbmJzcDsgJm5ic3A7dGhlIHVzZXIncyBsb2NhdGlv bi4gVGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGZvciZuYnNwOzwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Jm5ic3A7ICZuYnNw O1AtQWNjZXNzLU5ldHdvcmstSW5mbyBpbiBBQ0sgcmVxdWVzdHMgYXJlIHNpbWlsYXIgdG8gdGhv c2UgZm9yIHRoZSBvdGhlciZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+Jm5ic3A7ICZuYnNwO1NJUCByZXF1ZXN0cyBkaXNjdXNzZWQgaW4mbmJz cDs8L3NwYW4+Jm5ic3A7W1JGQzczMTVdPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+LqGxPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPlJlZ2FyZHMsPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPkNocmlzdGVyPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LXNpemU6IDE0cHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsi Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5DaHJpc3RlciBI b2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAyMiBKdW5lIDIwMTYg YXQgMDU6Mjg8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4m cXVvdDs8YSBocmVmPSJtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tIj5nc2FsZ3VlaUBjaXNjby5j b208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tIj5nc2Fs Z3VlaUBjaXNjby5jb208L2E+Jmd0OywgQmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86 YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFm dC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnIj5kcmFmdC1o b2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRl cy5hbGxAaWV0Zi5vcmciPmRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy5h bGxAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRm Lm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBBRCBFdmFsdWF0aW9uIG9mIGRy YWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy0wNjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtRnJvbTogPC9zcGFuPiZsdDs8YSBocmVmPSJtYWls dG86YWxpYXMtYm91bmNlc0BpZXRmLm9yZyI+YWxpYXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1UbzogPC9zcGFuPkNo cmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OywgTmV2ZW5r YSBCaW9uZGljICZsdDs8YSBocmVmPSJtYWlsdG86bmV2ZW5rYS5iaW9uZGljQGVyaWNzc29uLmNv bSI+bmV2ZW5rYS5iaW9uZGljQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tIj5nc2FsZ3VlaUBjaXNjby5jb208L2E+JnF1b3Q7DQog Jmx0OzxhIGhyZWY9Im1haWx0bzpnc2FsZ3VlaUBjaXNjby5jb20iPmdzYWxndWVpQGNpc2NvLmNv bTwvYT4mZ3Q7LCBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5j b20iPmJlbkBub3N0cnVtLmNvbTwvYT4mZ3Q7LCAmcXVvdDtBLiBNYWhvbmV5JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bWFob25leUBub3N0cnVtLmNvbSI+bWFob25leUBub3N0cnVtLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1EYXRlOiA8 L3NwYW4+V2VkbmVzZGF5IDIyIEp1bmUgMjAxNiBhdCAwNToyODxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jv c29mdCBFeGNoYW5nZSBTZXJ2ZXIiPg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSB0ZXh0IC0tPjxzdHls ZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1sZWZ0OiA0cHQ7 IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KV2UgY2FuIGFkZCB0aGUgdGV4dC48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15 IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsg Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmdzYWxn dWVpQGNpc2NvLmNvbSI+R29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKTwvYT48L3NwYW4+PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXpl OjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjIxLzA2LzIwMTYgMTk6 NDQ8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBo cmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5CZW4gQ2FtcGJlbGw8L2E+PC9zcGFuPjxicj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+Ow0KPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy5hbGxA aWV0Zi5vcmciPmRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy5hbGxAaWV0 Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPlNJUENPUkU8L2E+ PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5S ZTogQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0 ZXMtMDY8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxmb250IHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48YnI+ DQomZ3Q7IE9uIEp1biAyMSwgMjAxNiwgYXQgMTE6MjIgQU0sIEJlbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQncyBhIGdvb2Qgc3RhcnQsIGJ1dCBkb24ndCBi ZSBzdXJwcmlzZWQgaWYgd2UgZ2V0IHF1ZXN0aW9ucyBzcGVjaWZpY2FsbHkgYWJvdXQgYWRkaW5n IE5QTEkgdG8gQUNLIHJlcXVlc3RzLiBzb21lIGxhbmd1YWdlIHRvIHRoZSBlZmZlY3Qgb2YgdGhl IGZvbGxvd2luZyBtaWdodCBoZWxwOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtUaGlzIGRv Y3VtZW50IGFkZHMgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBQLUFjY2Vzcy1OZXR3b3JrLUluZm8g aW4gQUNLIHJlcXVlc3RzLiBBcyBkb2N1bWVudGVkIGluIFJGQzczMTUsIFAtQWNjZXNzLU5ldHdv cmstSW5mbyBtYXkgaW5jbHVkZSBwcml2YWN5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgaW5jbHVk aW5nIHRoZSB1c2VyJ3MgbG9jYXRpb24uIFRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRl cmF0aW9ucyBmb3IgUC1BY2Nlc3MtTmV0d29yay1JbmZvDQogaW4gQUNLIHJlcXVlc3RzIGFyZSBz aW1pbGFyIHRvIHRob3NlIGZvciB0aGUgb3RoZXIgU0lQIHJlcXVlc3RzIGRpc2N1c3NlZCBpbiBS RkM3MzE1LqGxPGJyPg0KPGJyPg0KSaGvbSBmaW5lIHdpdGggYWRkaW5nIHN1Y2ggdGV4dC48YnI+ DQo8YnI+DQpDaHJpc3RlciAtIENhbiB3ZSBhcHBlbmQgdGhpcyB0byB5b3VyIHByb3Bvc2VkIHRl eHQ/PGJyPg0KPGJyPg0KR29uemFsbzxicj4NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBU aGFua3MhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24g MjEgSnVuIDIwMTYsIGF0IDM6MjYsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCiZndDsg PGJyPg0KJmd0OyZndDsgSGkgQmVuLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFNlZSBp bmxpbmUuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tPGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBTdWJzdGFudGl2ZTo8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBz dGF0ZSB0aGF0IHRoZSBkcmFmdCByZW1vdmVzIHNvbWUgcGxhY2VzPGJyPg0KJmd0OyZndDsmZ3Q7 IHRoYXQgc29tZSBvZiB0aGUgUC1IZWFkZXJzIGNhbiBiZSBzZW50LCBidXQgZXhwYW5kcyB0aGF0 IHRvIHNvbWUgb3RoZXI8YnI+DQomZ3Q7Jmd0OyZndDsgcGxhY2VzLiBGdXJ0aGVyLCBpdCBzYXlz IHRoYXQgbmVpdGhlciBpbnRyb2R1Y2UgbmV3IHNlY3VyaXR5PGJyPg0KJmd0OyZndDsmZ3Q7IGNv bnNpZGVyYXRpb25zIGJleW9uZCB0aG9zZSBpbiA3MzE1Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsgSSBhY2NlcHQgdGhhdCBmb3IgdGhlIHJlZHVjdGlvbiBwYXJ0LiBCdXQg SSdtIG5vdCBzdXJlIHdlIGNhbiBzdGF0ZSB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7IHNvcnQgb2Yg dGhpbmcgZm9yIHRoZSBleHBhbnNpb24gcGFydCwgYXQgbGVhc3Qgd2l0aG91dCBzb21lIG1vcmU8 YnI+DQomZ3Q7Jmd0OyZndDsgZGlzY3Vzc2lvbi4gU2luY2UgNzMxNSBhbHJlYWR5IGFja25vd2xl ZGdlcyBwb3RlbnRpYWwgcHJpdmFjeSBpc3N1ZXM8YnI+DQomZ3Q7Jmd0OyZndDsgYXJvdW5kIFAt QWNjZXNzLU5ldHdvcmstSW5mbywgSSdkIGxpa2UgdG8gYXQgbGVhc3Qgc2VlIGEgc2VudGVuY2Ug b3IgdHdvPGJyPg0KJmd0OyZndDsmZ3Q7IGFib3V0IHRoZSBhbGxvd2FuY2Ugb2YgdGhhdCBpbiBB Q0sgcmVxdWVzdHMsIGV2ZW4gaWYgdGhleSBqdXN0IHNheSB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7 IHRoaXMgYWRkaXRpb24gbWFrZXMgdGhpbmdzIG5vIHdvcnNlIHRoYW4gdGhleSBhbHJlYWR5IGFy ZS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPTEQ6PGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBQ LSBoZWFkZXIgZmllbGRzIGFyZSBkZWZpbmVkIGluPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsg W1JGQzczMTVdLiZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIHNvbWUgaGVhZGVyIGZp ZWxkcyB0byBiZTxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHByZXNlbnQgaW4gbWVzc2FnZXMg d2hlcmUgdGhleSB3ZXJlIHByZXZpb3VzbHkgbm90IGFsbG93ZWQsIGFuZDxicj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7IGRpc2FsbG93IHNvbWUgaGVhZGVyIGZpZWxkcyB0byBiZSBwcmVzZW50IGlu IG1lc3NhZ2VzIHdoZXJlIHRoZXkgd2VyZTxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHByZXZp b3VzbHkgYWxsb3dlZC4gVGhhdCBkb2VzIG5vdCBjYXVzZSBhbnkgc2VjdXJpdHkgaXNzdWVzLCBi dXQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBiZSBh d2FyZSB0aGF0IGltcGxlbWVudGF0aW9ucyBtYXkgbm90IGhhdmU8YnI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsIGFuZCB0YWtl IHByb3BlciBhY3Rpb25zIGlmIGE8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBoZWFkZXIgZmll bGQgb2NjdXIsIG9yIGRvZXMgbm90IG9jY3VyLCBpbiBhIG1lc3NhZ2Ugd2hlcmUgaXQgc2hvdWxk PGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsgb2NjdXIgKG9yIG9jY3VycyBpbiBhIG1lc3NhZ2Ug d2hlcmUgaXQgc2hvdWxkIG5vdCBvY2N1cikuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgTkVXOjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlc2UgUC0gaGVhZGVyIGZp ZWxkcyBhcmUgZGVmaW5lZCBpbjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFtSRkM3MzE1XS4m bmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGFsbG93cyBzb21lIGhlYWRlciBmaWVsZHMgdG8gYmU8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBwcmVzZW50IGluIG1lc3NhZ2VzIHdoZXJlIHRoZXkg d2VyZSBwcmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQgdGhlPGJyPg0KJmd0OyZndDsgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgYW5kIGFzc3VtcHRpb25zIChlLmcuIHJlZ2FyZGluZyBvbmx5IHNl bmRpbmc8YnI+DQomZ3Q7Jmd0OyBJbmZvcm1hdGlvbiB0byB0cnVzdGVkIGVudGl0aWVzKSBhbHNv IHRvIHRob3NlIG1lc3NhZ2VzLiBJbiBhZGRpdGlvbiw8YnI+DQomZ3Q7Jmd0OyB0aGlzIHNwZWNp ZmljYXRpb24gYWxzbyBkaXNhbGxvdyBzb21lIGhlYWRlciBmaWVsZHMgdG8gYmUgcHJlc2VudDxi cj4NCiZndDsmZ3Q7IGluIG1lc3NhZ2Ugd2hlcmUgdGhleSB3ZXJlIHByZXZpb3VzbHkgYWxsb3dl ZC4gVGhhdCBkb2VzIG5vdCBjYXVzZTxicj4NCiZndDsmZ3Q7IGFueSBzZWN1cml0eSBpc3N1ZXMs IGJ1dCBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBiZSBhd2FyZSB0aGF0PGJyPg0KJmd0OyZndDsg aW1wbGVtZW50YXRpb25zIG1heSBub3QgaGF2ZSBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRo aXMgZG9jdW1lbnQsPGJyPg0KJmd0OyZndDsgYW5kIHRha2UgcHJvcGVyIGFjdGlvbnMgaWYgYSBo ZWFkZXIgZmllbGQgb2NjdXIsIG9yIGRvZXMgbm90IG9jY3VyLDxicj4NCiZndDsmZ3Q7IGluIGEg bWVzc2FnZSB3aGVyZSBpdCBzaG91bGQgb2NjdXIgKG9yIG9jY3VycyBpbiBhIG1lc3NhZ2Ugd2hl cmUgaXQ8YnI+DQomZ3Q7Jmd0OyBzaG91bGQgbm90IG9jY3VyKS48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgRWRpdG9yaWFsOjxi cj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgLTUsIGZpcnN0IHNlbnRlbmNlOiAm cXVvdDtUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIFAtIGhlYWRlciBmaWVsZHM8YnI+ DQomZ3Q7Jmd0OyZndDsgYXJlIGRlZmluZWQgaW48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsgW1JGQzczMTVdJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgYXNzdW1lIHRoaXMgbWVhbnMg NzMxNSBkaXNjdXNzZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZTxicj4N CiZndDsmZ3Q7Jmd0OyBQLUhlYWRlcnMgc3BlY2lmaWNhbGx5LCBub3QgUC1IZWFkZXJzIGluIGdl bmVyYWwuIElzIHRoaXMgdGhlIGludGVudD8gSWY8YnI+DQomZ3Q7Jmd0OyZndDsgc28sIEkgc3Vn Z2VzdDo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IHMvLi4uIGZvciBQLWhl YWRlciBmaWVsZHMuLi4vIC4uLiBmb3IgdGhlc2UgUC1oZWFkZXIgZmllbGRzLi4uPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgSan2bGwgZml4IGFzIHN1Z2dlc3RlZCAoYXNzIG5ldyB0ZXh0 IGFib3ZlKS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7IENocmlzdGVyPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3901671B451christerholmbergericssoncom_-- From nobody Wed Jun 22 05:41:25 2016 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 C2D9B12D133 for ; Wed, 22 Jun 2016 05:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 8bvjKWWcts5G for ; Wed, 22 Jun 2016 05:41:21 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 194A912B025 for ; Wed, 22 Jun 2016 05:41:21 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id u64so60048960vkf.3 for ; Wed, 22 Jun 2016 05:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QzobsP3Ga+J9JSo6ugYwutiEuVtodrb1JXDefpkJ2Gg=; b=n2oG/oMcjAR8TFp6WotJkPlw8U21TNU849Lpoq/i+nfA9bO8sl8aIFIHZQr9L5sXeg mAiA/Nr/I+sEoCjAKoKUzHPlCPX2hq8zBd2vErEj7JeeoVB2BCoc9u8/NaAzHdyVircV 6iRABkJuqkppYWgqV68z+uTVuWbPOwRkfU4bRARsiCxRDYm0IrzPsYWFzhuW9X37kIas VtMF61/fQxm79cdeUbn1DWoSmDAUJxPGCVOeBaZjocDw8Pb9tYimGzf55e5WXi/tJd7N cs5lzbAyle8N81OBUdONzm942TZdJF298BiBDqoI/VEVHg5leOmNH6Fg0Cwv61z1WpXd 0sGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QzobsP3Ga+J9JSo6ugYwutiEuVtodrb1JXDefpkJ2Gg=; b=dyzU1R8iuxvlbz28ujkDWV5iLxdNp4Zw0dLYF4EN1Xzjr8zD6VaYktsNahm9L/718G 1A+TO+YsUyfAvYMTZS7D8oFby74IqlvtLh3ZpGYYzRb40bGOVEH1qP8UzBU13psZpd8S NyrJjVtRBP6ZXxb/AncVSHOknUUbECxrOEUoyfOrAOhSpRg/rhna6PboM01VhLmML50i YztKUlDxlvnfbSLT8FZLtIvnWQN0fkpD0G8ut6M3jPNCWhJXqBjMyB5TZiSl20A6KJ52 ZcItvCH+fPl/Htx8w0OCHZLqbjDwOJtT9keqtojCn81x2Hb0FrFJnhoYQZEGHYqSxeTt zeUg== X-Gm-Message-State: ALyK8tIwrl209lzmd8/XDq54K1NKBLRnGXZPyPf4wRSEmkSsQlBy9KPbUmnW04H8Tne75CCbhiS5UZ4WVBZUtw== X-Received: by 10.159.37.175 with SMTP id 44mr12262664uaf.66.1466599279991; Wed, 22 Jun 2016 05:41:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Wed, 22 Jun 2016 05:41:19 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Wed, 22 Jun 2016 08:41:19 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a113519241ca18d0535dd41f7 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 12:41:24 -0000 --001a113519241ca18d0535dd41f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon, I think we are still talking past each other. The token added to the INVITE is *not a policy*; it is an authorization by the AuthZ Server to allow this request to create a conference focus. The policy is created and managed in the AuthZ Server; remember that the idea is to delegate the AuthZ to a separate entity other than the server providing the service. Let=E2=80=99s continue with the conference use case: Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : Let=E2=80=99s assume that the domain in Trust Domain 1 is example.com, and = Alice needs an account with this domain and needs access to the conference server= . The administrator of the example.com domain creates an account for Alice ( alice@example.com) and sets her *conference policy* to =E2=80=9C*conference= -type **=3D audio | audio-webconference=E2=80=9D* to allow her to create either an audi= o conference or an audio-webconference. Now, Alice decides to start an audio conference; to do that, the phone obtains an access token from the AuthNZ server that allows Alice to start a conference of the type =E2=80=9C*audio=E2=80=9D*. When Alice sends the INVITE to the conference server, the phone will include that specific access token, which will be used by the conference factory to authorize the request to create a conference focus. So, the conference server has no idea what the policy is; all it knows is that it received a request with a token created by a specific AuthNZ server. If the conference server trusts the AuthNZ server and the token is valid, it authorizes the request and creates the requested conference focus; otherwise, the request is rejected. Hopefully this is clearer. Regards, Rifaat On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon wrote: > > It's not really what I'm looking for, no, and after mulling this over a > bit, I fear going farther along this path would only drill down into leve= ls > of complexity that will likely make this harder to understand rather than > easier. > > I do acknowledge that you describe the INVITE as being rejected if it > doesn't contain a token - but that's not the same thing as saying the > INVITE will be rejected because the relying party makes an authorization > decision based on the attributes in the token. It's more like an INVITE > being rejected because a user agent can't supply an Authorization header.= I > will reiterate that I don't think the kinds of attributes you are proposi= ng > should be in the scope of an effort that will try to address a framework > for authorizing SIP requests. I don't think the values of the attributes > (as opposed to the mere presence of some attributes) have anything to do > with authorizing the SIP request that you propose would carry the > attributes. > > With regards to this whole conferencing example, it does seem a bit > contrived to me, like you're sketching a SIP-based way of setting > conference policy on the fly that happens to require the kind of attribut= es > you want, and then saying that demonstrates the need for the attributes. > The fact that all of the ways to do conference policy we can point to in > fact do it via the web makes it hard for me to understand why we should > create a SIP-based way of doing this. To me, it looks like you're opening= a > problem space that has much more to do with reshaping the way that SIP do= es > conferences (and again, as Radhika's mail pointing out, there's been a lo= t > of thinking about this since the days of RFC4579) than it does with > defining a framework for authorizing SIP requests. > > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Thursday, June 16, 2016 at 6:19 AM > To: Jon Peterson > Cc: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 > > The attributes I provided are examples of attributes that might be > provided in an access token; it was not meant to include all the attribut= es > for this use case, because my intention was not to focus on conference > server, but to discuss the idea in general. > > The following could be used with the conference factory to request a > conference focus: > The INVITE sent to the conference factory could include a token that has = a * > conference-type* attribute which could take one of the following values: = *audio, > video, webconference, audio-webconference, or video-webconference*. > The conference factory will then issue a *conference uri* for the > requested conference type, assuming the token is valid. If the > *conference-type* attribute is missing, then the request would be > rejected. > > Is that what you are looking for? > > Regards, > Rifaat > > > > > > On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon > wrote: > >> >>> >>> In that case, if you could furnish a use case with attributes that woul= d >>> be carried in a SIP iNVITE that are actually salient to the authorizati= on >>> of that particular SIP request, we'd be getting a lot closer to common >>> ground. >>> >>> >> An obvious example would be an INVITE with a token sent to a conference >> factory to authorize the creation of a focus. >> >> >> We're still talking past each other. My point above was that the two >> attributes you specified - constraints on conference size and media type= s - >> have nothing to do with the authorization of the INVITE carrying those >> attributes. Like, unless the conference size permitted is 0, then the >> INVITE that creates an ad hoc conference and connects you to its bridge = is >> not going to be rejected by the focus on the basis of that conference si= ze >> attribute. If the maximum conference size were 0, the AuthZ service just >> wouldn't attach a token to an INVITE as it would never be allowed to sta= rt >> a conference. Same goes for media types. >> >> Instead, what your two attributes constrain is what happens after the >> conference is created: when ten users try to dial in to a conference wit= h a >> permitted size of nine, say. That tenth INVITE would get rejected - not = the >> conference-forming INVITE that you propose would carry the token. That's >> why what you're proposing is overloading the INVITE to tunnel conference >> policy constraints to the focus. I mean, maybe that's a problem space wo= rth >> investigating, though I suspect there are good reasons why RFC4353 >> specified that conference policy is not manipulated with SIP - mostly >> because the semantics of manipulating conference policy probably don't m= ap >> well onto dialog-forming SIP requests. But I think that conference polic= y >> provisioning problem space would be pretty far from where we started in >> this discussion. >> >> Let me reiterate what I wrote in my previous mail, which I quote here at >> the top: "furnish a use case with attributes that would be carried in a = SIP >> iNVITE that are actually salient to the authorization of that particular >> SIP request." Again: "that particular SIP request." Not later transactio= ns >> in some broader context in which the original user agent probably isn't >> even an endpoint. >> >> The Authorization header in SIP, for example, is actually used by the UA= S >> to make a decision about whether or not to authorize the request in whic= h >> the header appears. The token that you propose a SIP INVITE would carry= in >> this case is not used by the relying party to make a decision about whet= her >> or not that INVITE is authorized. That's why I believe this conference >> policy issue is a different problem space entirely from figuring out how= to >> implement attribute-based authorization for SIP requests. >> >> Jon Peterson >> Neustar, Inc. >> >> >> Regards, >> Rifaat >> >> > --001a113519241ca18d0535dd41f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Jon,

=C2=A0

I think we= are still talking past each other.

=C2=A0

The token = added to the INVITE is not a policy; it is an authorization by the AuthZ Server to allow this request to create a conference focus.

The policy= is created and managed in the AuthZ Server; remember that the idea is to deleg= ate the AuthZ to a separate entity other than the server providing the service.=

=C2=A0

=C2=A0

Let=E2=80= =99s continue with the conference use case:


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2

=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 =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 =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 | IdP =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 +-------------| AuthZ =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :<= /span>

=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 =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 =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 =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 =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 =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| SIP =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 | SIP App|

| =C2=A0 UA =C2=A0 |--------| Proxy =C2=A0|-----:-----------------:-----| Vid= eo =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 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 | Conference

+--------+ =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 =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 =C2= =A0 =C2=A0 =C2=A0 :

=C2=A0

Let=E2=80= =99s assume that the domain in Trust Domain 1 is example= .com, and Alice needs an account with this domain and needs access to the conference server.

=C2=A0

The administrator of the example.com domain = creates an account for Alice (alice@example.com) and sets her conference policy to =E2=80=9Cconference-type =3D audio | = audio-webconference=E2=80=9D to allow her to create either an audio conference or an audio-webconference.<= /font>

=C2=A0

Now, Alice decides to start an audio conference; to do that, the phone obtains an access token from the AuthNZ server that allows Alice to start a conference of the type =E2=80=9C= audio=E2=80=9D.

=C2=A0

When Alice sends the INVITE to the conference server, the phone will include that specific access token= , which will be used by the conference factory to authorize the request to cr= eate a conference focus.

=C2=A0

So, the conference server has no idea what the policy is; all it knows is that it received a request with= a token created by a specific AuthNZ server. If the conference server trusts the Au= thNZ server and the token is valid, it authorizes the request and creates the requested conference focus; otherwise, the request is rejected.

=C2=A0

Hopefully this is clearer.<= /span>

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


On Tue, Jun 21, 201= 6 at 7:46 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:

It's not really what I'm looking for, no, and after mulling th= is over a bit, I fear going farther along this path would only drill down i= nto levels of complexity that will likely make this harder to understand ra= ther than easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying t= he INVITE will be rejected because the relying party makes an authorization= decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent ca= n't supply an Authorization header. I will reiterate that I don't t= hink the kinds of attributes you are proposing should be in the scope of an= effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attribut= es (as opposed to the mere presence of some attributes) have anything to do= with authorizing the SIP request that you propose would carry the attribut= es.

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting confere= nce policy on the fly that happens to require the kind of attributes you wa= nt, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lo= t of thinking about this since the days of RFC4579) than it does with defin= ing a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.


The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the t= wo attributes you specified - constraints on conference size and media type= s - have nothing to do with the authorization of the INVITE carrying those = attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

--001a113519241ca18d0535dd41f7-- From nobody Wed Jun 22 05:48:38 2016 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 F404B12B022 for ; Wed, 22 Jun 2016 05:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 Zfm9HuYRufZ8 for ; Wed, 22 Jun 2016 05:48:34 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 056CB12B039 for ; Wed, 22 Jun 2016 05:48:32 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j2so60256255vkg.2 for ; Wed, 22 Jun 2016 05:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QsDMqZM10qutS9u1W7xKTFMjDWJc9PWaYvRVDTVSKfc=; b=mSvIezmEVrfkGkOAGQKwbxePWq+VovKPx8Oa8QlO79x9DXqr2rHCctRbgQwfy/igFp cX1DYlW/yHKyB9Z1lK2If+uVj62iJVIVna0o1XB8VqtWNbLCGklvjEUpX6aH/yizKA1f Z7xjZS7u8KvJjU5VQsnor3a91cCj/FJTE0Mz1vk9iHuWxR3XtJPVU34J0F273nL+qQDe mqF8mTDe9380mFnW8QHFna6/w/cb4rEv7Hk/YX6zOR7pxHUwvyrPYG68uuXmzXHJ30co /RX/nMcVMif3kJd8q7U08ciIvP1cuAtS0qWYsKB5t4GqWcXSq/o9mN0tRKaxgDhBWTcR ONPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QsDMqZM10qutS9u1W7xKTFMjDWJc9PWaYvRVDTVSKfc=; b=Ml5j5nsNRTYrKiU/9eFBFjTz4aiBM0ZZg5oAexeimvp1kHwoHObkK6P1InJ7B/ibgt mQF5wux0Ps0zK7lgR6tPyu43rNgTfuCOiIauIwrerusCmG7uNIfslROQrmFxv7gQjLmi gjD4lK3LL/0h/DKRE4G57Q5ip5js8TOy7UFq/x+3pfOIgCNVRzdOYELaNhAEMqCMdjsF Whm0Sx8UydCDrOCrGTJvFSlljfrfzlHBQPeI8dQEMyZSiEXJlcmtapFrbJytqOMx/W83 yA/R88y1vFUl/FXhwUUV4IunU9H4TSzd+TN7CvJIO1xKKQ9XAz+BdhkoYh4DIl4gizFZ M+PQ== X-Gm-Message-State: ALyK8tL0mtwDcDO4g/EjkH8Z/g62+xbGxN3J8FLQxkJgb3x+P3U/NRQlz6eh53O6HXMnMLeaIX2p3XuRmcpKqQ== X-Received: by 10.176.0.145 with SMTP id 17mr11974537uaj.103.1466599710938; Wed, 22 Jun 2016 05:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Wed, 22 Jun 2016 05:48:29 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Wed, 22 Jun 2016 08:48:29 -0400 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113ddfbccc5c550535dd5a56 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 12:48:37 -0000 --001a113ddfbccc5c550535dd5a56 Content-Type: text/plain; charset=UTF-8 Roman, I think that the question of how to exactly carry the token in SIP request is a minor issue *at this stage*. We are discussing the idea and concept of delegating both the AuthN and AuthZ to separate server(s) and how to achieve that. Regards, Rifaat On Tue, Jun 21, 2016 at 7:50 PM, Roman Shpount wrote: > Furthermore, reading all of this, I cannot understand why Authorization > token cannot be a part of SIP URL, either as user part or URL parameter. > This does not need to be anything more then service specific URL and does > not require a new SIP header or authentication mechanism. > > _____________ > Roman Shpount > > On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon > wrote: > >> >> It's not really what I'm looking for, no, and after mulling this over a >> bit, I fear going farther along this path would only drill down into levels >> of complexity that will likely make this harder to understand rather than >> easier. >> >> I do acknowledge that you describe the INVITE as being rejected if it >> doesn't contain a token - but that's not the same thing as saying the >> INVITE will be rejected because the relying party makes an authorization >> decision based on the attributes in the token. It's more like an INVITE >> being rejected because a user agent can't supply an Authorization header. I >> will reiterate that I don't think the kinds of attributes you are proposing >> should be in the scope of an effort that will try to address a framework >> for authorizing SIP requests. I don't think the values of the attributes >> (as opposed to the mere presence of some attributes) have anything to do >> with authorizing the SIP request that you propose would carry the >> attributes. >> >> With regards to this whole conferencing example, it does seem a bit >> contrived to me, like you're sketching a SIP-based way of setting >> conference policy on the fly that happens to require the kind of attributes >> you want, and then saying that demonstrates the need for the attributes. >> The fact that all of the ways to do conference policy we can point to in >> fact do it via the web makes it hard for me to understand why we should >> create a SIP-based way of doing this. To me, it looks like you're opening a >> problem space that has much more to do with reshaping the way that SIP does >> conferences (and again, as Radhika's mail pointing out, there's been a lot >> of thinking about this since the days of RFC4579) than it does with >> defining a framework for authorizing SIP requests. >> >> Jon Peterson >> Neustar, Inc. >> >> From: Rifaat Shekh-Yusef >> Date: Thursday, June 16, 2016 at 6:19 AM >> To: Jon Peterson >> Cc: "sipcore@ietf.org" >> Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 >> >> The attributes I provided are examples of attributes that might be >> provided in an access token; it was not meant to include all the attributes >> for this use case, because my intention was not to focus on conference >> server, but to discuss the idea in general. >> >> The following could be used with the conference factory to request a >> conference focus: >> The INVITE sent to the conference factory could include a token that has >> a * conference-type* attribute which could take one of the following >> values: *audio, video, webconference, audio-webconference, or >> video-webconference*. >> The conference factory will then issue a *conference uri* for the >> requested conference type, assuming the token is valid. If the >> *conference-type* attribute is missing, then the request would be >> rejected. >> >> Is that what you are looking for? >> >> Regards, >> Rifaat >> >> >> >> >> >> On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon >> wrote: >> >>> >>>> >>>> In that case, if you could furnish a use case with attributes that >>>> would be carried in a SIP iNVITE that are actually salient to the >>>> authorization of that particular SIP request, we'd be getting a lot closer >>>> to common ground. >>>> >>>> >>> An obvious example would be an INVITE with a token sent to a conference >>> factory to authorize the creation of a focus. >>> >>> >>> We're still talking past each other. My point above was that the two >>> attributes you specified - constraints on conference size and media types - >>> have nothing to do with the authorization of the INVITE carrying those >>> attributes. Like, unless the conference size permitted is 0, then the >>> INVITE that creates an ad hoc conference and connects you to its bridge is >>> not going to be rejected by the focus on the basis of that conference size >>> attribute. If the maximum conference size were 0, the AuthZ service just >>> wouldn't attach a token to an INVITE as it would never be allowed to start >>> a conference. Same goes for media types. >>> >>> Instead, what your two attributes constrain is what happens after the >>> conference is created: when ten users try to dial in to a conference with a >>> permitted size of nine, say. That tenth INVITE would get rejected - not the >>> conference-forming INVITE that you propose would carry the token. That's >>> why what you're proposing is overloading the INVITE to tunnel conference >>> policy constraints to the focus. I mean, maybe that's a problem space worth >>> investigating, though I suspect there are good reasons why RFC4353 >>> specified that conference policy is not manipulated with SIP - mostly >>> because the semantics of manipulating conference policy probably don't map >>> well onto dialog-forming SIP requests. But I think that conference policy >>> provisioning problem space would be pretty far from where we started in >>> this discussion. >>> >>> Let me reiterate what I wrote in my previous mail, which I quote here at >>> the top: "furnish a use case with attributes that would be carried in a SIP >>> iNVITE that are actually salient to the authorization of that particular >>> SIP request." Again: "that particular SIP request." Not later transactions >>> in some broader context in which the original user agent probably isn't >>> even an endpoint. >>> >>> The Authorization header in SIP, for example, is actually used by the >>> UAS to make a decision about whether or not to authorize the request in >>> which the header appears. The token that you propose a SIP INVITE would >>> carry in this case is not used by the relying party to make a decision >>> about whether or not that INVITE is authorized. That's why I believe this >>> conference policy issue is a different problem space entirely from figuring >>> out how to implement attribute-based authorization for SIP requests. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> >>> Regards, >>> Rifaat >>> >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > --001a113ddfbccc5c550535dd5a56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roman,

I think that the question of how= to exactly carry the token in SIP request is a minor issue at this stag= e.
We are discussing the idea and concept of delegating b= oth the AuthN and AuthZ to separate server(s) and how to achieve that.
<= /div>

Regards,
=C2=A0Rifaat


On Tue, J= un 21, 2016 at 7:50 PM, Roman Shpount <roman@telurix.com> wr= ote:
Furthermore, readin= g all of this, I cannot understand why Authorization token cannot be a part= of SIP URL, either as user part or URL parameter. This does not need to be= anything more then service specific URL and does not require a new SIP hea= der or authentication mechanism.

_____________
Roma= n Shpount

On Tue, Jun 21, 2016 = at 7:46 PM, Peterson, Jon <jon.peterson@neustar.biz> = wrote:

It's not really what I'm looking for, no, and after mulling th= is over a bit, I fear going farther along this path would only drill down i= nto levels of complexity that will likely make this harder to understand ra= ther than easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying t= he INVITE will be rejected because the relying party makes an authorization= decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent ca= n't supply an Authorization header. I will reiterate that I don't t= hink the kinds of attributes you are proposing should be in the scope of an= effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attribut= es (as opposed to the mere presence of some attributes) have anything to do= with authorizing the SIP request that you propose would carry the attribut= es.

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting confere= nce policy on the fly that happens to require the kind of attributes you wa= nt, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lo= t of thinking about this since the days of RFC4579) than it does with defin= ing a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.


The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the t= wo attributes you specified - constraints on conference size and media type= s - have nothing to do with the authorization of the INVITE carrying those = attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

__________________________________________= _____
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore



--001a113ddfbccc5c550535dd5a56-- From nobody Wed Jun 22 07:56:36 2016 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 4ABBF12D792; Wed, 22 Jun 2016 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 ee8rrRoeBsm2; Wed, 22 Jun 2016 07:56:33 -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 5299B12D876; Wed, 22 Jun 2016 07:47:10 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5MEl2YX097155 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 09:47:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 22 Jun 2016 09:47:05 -0500 Message-ID: <8D74E280-1141-469D-9627-23E38A2F9478@nostrum.com> In-Reply-To: References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: SIPCORE , Gonzalo Salgueiro , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 14:56:35 -0000 Works for me. Thanks! Ben. On 22 Jun 2016, at 2:18, Christer Holmberg wrote: > Hi, > > NEW: > > =E2=80=9DThe security considerations for these P- header fields are = > defined in > [RFC7315]. This specification allows some header fields to be > present in messages where they were previously not allowed, and the > security considerations and assumptions (e.g. regarding only = > sending > Information to trusted entities) also to those messages. In = > addition, > this specification also disallow some header fields to be present > in message where they were previously allowed. That does not cause > any security issues, but implementations need to be aware that > implementations may not have been updated according to this = > document, > and take proper actions if a header field occur, or does not occur, > in a message where it should occur (or occurs in a message where it > should not occur). This document adds the ability to include > P-Access-Network-Info in ACK requests. As documented in [RFC7315], > P-Access-Network-Info may include privacy sensitive information, = > including > the user's location. The security and privacy considerations for > P-Access-Network-Info in ACK requests are similar to those for the = > other > SIP requests discussed in [RFC7315].=E2=80=9D > > Regards, > > Christer > > > From: Christer Holmberg = > >= > Date: Wednesday 22 June 2016 at 05:28 > To: "gsalguei@cisco.com" = > >, Ben Campbell = > > > Cc: = > "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" = > >, = > "sipcore@ietf.org" = > > > Subject: RE: AD Evaluation of = > draft-holmberg-dispatch-rfc7315-updates-06 > Resent-From: > > Resent-To: Christer Holmberg = > >= , = > Nevenka Biondic = > >, = > "gsalguei@cisco.com" = > >, Ben Campbell = > >, "A. Mahoney" = > > > Resent-Date: Wednesday 22 June 2016 at 05:28 > > Hi, > > We can add the text. > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Gonzalo Salgueiro (gsalguei) > Sent: 21/06/2016 19:44 > To: Ben Campbell > Cc: Christer Holmberg; = > draft-holmberg-dispatch-rfc7315-updates.all@ietf.org; = > SIPCORE > Subject: Re: AD Evaluation of = > draft-holmberg-dispatch-rfc7315-updates-06 > > >> On Jun 21, 2016, at 11:22 AM, Ben Campbell = >> > wrote: >> >> That's a good start, but don't be surprised if we get questions = >> specifically about adding NPLI to ACK requests. some language to the = >> effect of the following might help: >> >> "This document adds the ability to include P-Access-Network-Info in = >> ACK requests. As documented in RFC7315, P-Access-Network-Info may = >> include privacy sensitive information, including the user's location. = >> The security and privacy considerations for P-Access-Network-Info in = >> ACK requests are similar to those for the other SIP requests = >> discussed in RFC7315.=E2=80=9D > > I=E2=80=99m fine with adding such text. > > Christer - Can we append this to your proposed text? > > Gonzalo > > >> >> Thanks! >> >> Ben. >> >> On 21 Jun 2016, at 3:26, Christer Holmberg wrote: >> >>> Hi Ben, >>> >>> See inline. >>> >>>> -------------- >>>> >>>> Substantive: >>>> >>>> The security considerations state that the draft removes some = >>>> places >>>> that some of the P-Headers can be sent, but expands that to some = >>>> other >>>> places. Further, it says that neither introduce new security >>>> considerations beyond those in 7315. >>>> >>>> I accept that for the reduction part. But I'm not sure we can state = >>>> that >>>> sort of thing for the expansion part, at least without some more >>>> discussion. Since 7315 already acknowledges potential privacy = >>>> issues >>>> around P-Access-Network-Info, I'd like to at least see a sentence = >>>> or two >>>> about the allowance of that in ACK requests, even if they just say = >>>> that >>>> this addition makes things no worse than they already are. >>> >>> >>> OLD: >>> >>> The security considerations for P- header fields are defined in >>> [RFC7315]. This specification allows some header fields to be >>> present in messages where they were previously not allowed, and >>> disallow some header fields to be present in messages where they = >>> were >>> previously allowed. That does not cause any security issues, but >>> implementations need to be aware that implementations may not have >>> been updated according to this document, and take proper actions = >>> if a >>> header field occur, or does not occur, in a message where it = >>> should >>> occur (or occurs in a message where it should not occur). >>> >>> >>> >>> NEW: >>> >>> The security considerations for these P- header fields are defined = >>> in >>> [RFC7315]. This specification allows some header fields to be >>> present in messages where they were previously not allowed, and = >>> the >>> security considerations and assumptions (e.g. regarding only sending >>> Information to trusted entities) also to those messages. In = >>> addition, >>> this specification also disallow some header fields to be present >>> in message where they were previously allowed. That does not cause >>> any security issues, but implementations need to be aware that >>> implementations may not have been updated according to this = >>> document, >>> and take proper actions if a header field occur, or does not occur, >>> in a message where it should occur (or occurs in a message where it >>> should not occur). >>> >>> >>> >>>> Editorial: >>>> >>>> -5, first sentence: "The security considerations for P- header = >>>> fields >>>> are defined in >>>> [RFC7315]" >>>> I assume this means 7315 discusses the security considerations for = >>>> these >>>> P-Headers specifically, not P-Headers in general. Is this the = >>>> intent? If >>>> so, I suggest: >>>> >>>> s/... for P-header fields.../ ... for these P-header fields... >>> >>> I=C2=B9ll fix as suggested (ass new text above). >>> >>> Regards, >>> >>> Christer From nobody Wed Jun 22 08:11:20 2016 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 5669512DC59; Wed, 22 Jun 2016 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ep8z52fLHdXA; Wed, 22 Jun 2016 08:11:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1D712D8B1; Wed, 22 Jun 2016 07:59:12 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-dc-576aa7beef25 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.9E.27088.EB7AA675; Wed, 22 Jun 2016 16:59:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 16:59:05 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkAgABAuACAABb4AIAAxKC3gABjCACAAEnXgIAAJODG Date: Wed, 22 Jun 2016 14:59:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380FFF70@ESESSMB209.ericsson.se> References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> , <8D74E280-1141-469D-9627-23E38A2F9478@nostrum.com> In-Reply-To: <8D74E280-1141-469D-9627-23E38A2F9478@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380FFF70ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tO6+5VnhBlu7lC3md55mt1j9ehar xdwpfhZff2xic2DxmPJ7I6vHkiU/mTxm7XzCEsAcxWWTkpqTWZZapG+XwJWxdMpVloKG+YwV k/4vZ25g7Ohg7GLk5JAQMJHoftTFBGGLSVy4t56ti5GLQ0jgCKPE1p51rBDOEkaJa/OnAmU4 ONgELCS6/2mDNIgIKEk8b97KAlLDLLCbUeLq7FfMIAlhAQ+JR4f2MUIUeUpc/L2RHcKOklg/ eysriM0ioCoxb+lpsHpeAV+JVcf7GSGW/WeS2POliRFkGaeAvUTDBSOQGkag676fWgN2KbOA uETTl5WsEFcLSCzZc54ZwhaVePn4HytETb7ErMkPWSHmC0qcnPmEZQKjyCwk7bOQlM1CUgYR N5D48v42lK0tsWzha2YIW1+i+/1pJmTxBYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC I+/glt8GOxhfPnc8xCjAwajEw/tgR2a4EGtiWXFl7iFGCQ5mJRHewqVZ4UK8KYmVValF+fFF pTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoYl30Ktg36WqOz592RrXONZ1/d cM3+0aM1zrLbJ27NvBNz+4vTTtUX6feKql5cixbbqSSnnLa4ed/ztx8k77Wr5nffLv7d6Jwz d5lzcljoZTsuzydXf965uT50YtKV8Lef89aorlnHPvGsqFj7ks1ebXpzPmuceTjpyNJbIgHf stW1jRi8vEQ/flViKc5INNRiLipOBAADcH7PuAIAAA== Archived-At: Cc: SIPCORE , Gonzalo Salgueiro , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:11:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380FFF70ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Good :) Is it ok of I submit a new version of the draft? That way the new text will= be available during IETF last call. Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD22/=FD06/=FD2016 17:47 To: Christer Holmberg Cc: Gonzalo Salgueiro; draft-holmberg-dispatch-r= fc7315-updates.all@ietf.org; SIPCORE Subject: Re: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Works for me. Thanks! Ben. On 22 Jun 2016, at 2:18, Christer Holmberg wrote: > Hi, > > NEW: > > =94The security considerations for these P- header fields are > defined in > [RFC7315]. This specification allows some header fields to be > present in messages where they were previously not allowed, and the > security considerations and assumptions (e.g. regarding only > sending > Information to trusted entities) also to those messages. In > addition, > this specification also disallow some header fields to be present > in message where they were previously allowed. That does not cause > any security issues, but implementations need to be aware that > implementations may not have been updated according to this > document, > and take proper actions if a header field occur, or does not occur, > in a message where it should occur (or occurs in a message where it > should not occur). This document adds the ability to include > P-Access-Network-Info in ACK requests. As documented in [RFC7315], > P-Access-Network-Info may include privacy sensitive information, > including > the user's location. The security and privacy considerations for > P-Access-Network-Info in ACK requests are similar to those for the > other > SIP requests discussed in [RFC7315].=94 > > Regards, > > Christer > > > From: Christer Holmberg > > > Date: Wednesday 22 June 2016 at 05:28 > To: "gsalguei@cisco.com" > >, Ben Campbell > > > Cc: > "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" > >, > "sipcore@ietf.org" > > > Subject: RE: AD Evaluation of > draft-holmberg-dispatch-rfc7315-updates-06 > Resent-From: > > Resent-To: Christer Holmberg > >, > Nevenka Biondic > >, > "gsalguei@cisco.com" > >, Ben Campbell > >, "A. Mahoney" > > > Resent-Date: Wednesday 22 June 2016 at 05:28 > > Hi, > > We can add the text. > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Gonzalo Salgueiro (gsalguei) > Sent: 21/06/2016 19:44 > To: Ben Campbell > Cc: Christer Holmberg; > draft-holmberg-dispatch-rfc7315-updates.all@ietf.org; > SIPCORE > Subject: Re: AD Evaluation of > draft-holmberg-dispatch-rfc7315-updates-06 > > >> On Jun 21, 2016, at 11:22 AM, Ben Campbell >> > wrote: >> >> That's a good start, but don't be surprised if we get questions >> specifically about adding NPLI to ACK requests. some language to the >> effect of the following might help: >> >> "This document adds the ability to include P-Access-Network-Info in >> ACK requests. As documented in RFC7315, P-Access-Network-Info may >> include privacy sensitive information, including the user's location. >> The security and privacy considerations for P-Access-Network-Info in >> ACK requests are similar to those for the other SIP requests >> discussed in RFC7315.=94 > > I=92m fine with adding such text. > > Christer - Can we append this to your proposed text? > > Gonzalo > > >> >> Thanks! >> >> Ben. >> >> On 21 Jun 2016, at 3:26, Christer Holmberg wrote: >> >>> Hi Ben, >>> >>> See inline. >>> >>>> -------------- >>>> >>>> Substantive: >>>> >>>> The security considerations state that the draft removes some >>>> places >>>> that some of the P-Headers can be sent, but expands that to some >>>> other >>>> places. Further, it says that neither introduce new security >>>> considerations beyond those in 7315. >>>> >>>> I accept that for the reduction part. But I'm not sure we can state >>>> that >>>> sort of thing for the expansion part, at least without some more >>>> discussion. Since 7315 already acknowledges potential privacy >>>> issues >>>> around P-Access-Network-Info, I'd like to at least see a sentence >>>> or two >>>> about the allowance of that in ACK requests, even if they just say >>>> that >>>> this addition makes things no worse than they already are. >>> >>> >>> OLD: >>> >>> The security considerations for P- header fields are defined in >>> [RFC7315]. This specification allows some header fields to be >>> present in messages where they were previously not allowed, and >>> disallow some header fields to be present in messages where they >>> were >>> previously allowed. That does not cause any security issues, but >>> implementations need to be aware that implementations may not have >>> been updated according to this document, and take proper actions >>> if a >>> header field occur, or does not occur, in a message where it >>> should >>> occur (or occurs in a message where it should not occur). >>> >>> >>> >>> NEW: >>> >>> The security considerations for these P- header fields are defined >>> in >>> [RFC7315]. This specification allows some header fields to be >>> present in messages where they were previously not allowed, and >>> the >>> security considerations and assumptions (e.g. regarding only sending >>> Information to trusted entities) also to those messages. In >>> addition, >>> this specification also disallow some header fields to be present >>> in message where they were previously allowed. That does not cause >>> any security issues, but implementations need to be aware that >>> implementations may not have been updated according to this >>> document, >>> and take proper actions if a header field occur, or does not occur, >>> in a message where it should occur (or occurs in a message where it >>> should not occur). >>> >>> >>> >>>> Editorial: >>>> >>>> -5, first sentence: "The security considerations for P- header >>>> fields >>>> are defined in >>>> [RFC7315]" >>>> I assume this means 7315 discusses the security considerations for >>>> these >>>> P-Headers specifically, not P-Headers in general. Is this the >>>> intent? If >>>> so, I suggest: >>>> >>>> s/... for P-header fields.../ ... for these P-header fields... >>> >>> I=B9ll fix as suggested (ass new text above). >>> >>> Regards, >>> >>> Christer --_000_7594FB04B1934943A5C02806D1A2204B380FFF70ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Works for me.

Thanks!

Ben.

On 22 Jun 2016, at 2:18, Christer Holmberg wrote:

> Hi,
>
> NEW:
>
>    =94The security considerations for these P- header f= ields are
> defined in
>    [RFC7315].  This specification allows some head= er fields to be
>    present in messages where they were previously not a= llowed, and the
>    security considerations and assumptions (e.g. regard= ing only
> sending
>    Information to trusted entities) also to those messa= ges. In
> addition,
>    this specification also disallow some header fields = to be present
>    in message where they were previously allowed. That = does not cause
>    any security issues, but implementations need to be = aware that
>    implementations may not have been updated according = to this
> document,
>    and take proper actions if a header field occur, or = does not occur,
>    in a message where it should occur (or occurs in a m= essage where it
>    should not occur). This document adds the ability to= include
>    P-Access-Network-Info in ACK requests. As documented= in  [RFC7315],
>    P-Access-Network-Info may include privacy sensitive = information,
> including
>    the user's location. The security and privacy consid= erations for
>    P-Access-Network-Info in ACK requests are similar to= those for the
> other
>    SIP requests discussed in  [RFC7315].=94
>
> Regards,
>
> Christer
>
>
> From: Christer Holmberg
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsso= n.com>>
> Date: Wednesday 22 June 2016 at 05:28
> To: "gsalguei@cisco.com<mailto:gsalguei@cisco.com>" > <gsalguei@cisco.com<mailto:gsalguei@cisco.com>>, Ben Campb= ell
> <ben@nostrum.com<mailto:ben@nostrum.com>>
> Cc:
> "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org<mailto:d= raft-holmberg-dispatch-rfc7315-updates.all@ietf.org>"
> <draft-holmberg-dispatch-rfc7315-updates.all@ietf.org<mailto:dra= ft-holmberg-dispatch-rfc7315-updates.all@ietf.org>>,
> "sipcore@ietf.org<mailto:sipcore@ietf.org>"
> <sipcore@ietf.org<mailto:sipcore@ietf.org>>
> Subject: RE: AD Evaluation of
> draft-holmberg-dispatch-rfc7315-updates-06
> Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.o= rg>>
> Resent-To: Christer Holmberg
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsso= n.com>>,
> Nevenka Biondic
> <nevenka.biondic@ericsson.com<mailto:nevenka.biondic@ericsson.co= m>>,
> "gsalguei@cisco.com<mailto:gsalguei@cisco.com>"
> <gsalguei@cisco.com<mailto:gsalguei@cisco.com>>, Ben Campb= ell
> <ben@nostrum.com<mailto:ben@nostrum.com>>, "A. Mahone= y"
> <mahoney@nostrum.com<mailto:mahoney@nostrum.com>>
> Resent-Date: Wednesday 22 June 2016 at 05:28
>
> Hi,
>
> We can add the text.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ________________________________
> From: Gonzalo Salgueiro (gsalguei)<mailto:gsalguei@cisco.com> > Sent: 21/06/2016 19:44
> To: Ben Campbell<mailto:ben@nost= rum.com>
> Cc: Christer Holmberg<mailto:christer.holmberg@ericsson.com>;
> draft-holmberg-dispatch-rfc7315-updates.all@ietf.org<mailto:draft-h= olmberg-dispatch-rfc7315-updates.all@ietf.org>;
> SIPCORE<mailto:sipcore@ietf.org= >
> Subject: Re: AD Evaluation of
> draft-holmberg-dispatch-rfc7315-updates-06
>
>
>> On Jun 21, 2016, at 11:22 AM, Ben Campbell
>> <ben@nostrum.com<mailto:ben@nostrum.com>> wrote:
>>
>> That's a good start, but don't be surprised if we get questions >> specifically about adding NPLI to ACK requests. some language to t= he
>> effect of the following might help:
>>
>> "This document adds the ability to include P-Access-Network-I= nfo in
>> ACK requests. As documented in RFC7315, P-Access-Network-Info may =
>> include privacy sensitive information, including the user's locati= on.
>> The security and privacy considerations for P-Access-Network-Info = in
>> ACK requests are similar to those for the other SIP requests
>> discussed in RFC7315.=94
>
> I=92m fine with adding such text.
>
> Christer - Can we append this to your proposed text?
>
> Gonzalo
>
>
>>
>> Thanks!
>>
>> Ben.
>>
>> On 21 Jun 2016, at 3:26, Christer Holmberg wrote:
>>
>>> Hi Ben,
>>>
>>> See inline.
>>>
>>>> --------------
>>>>
>>>> Substantive:
>>>>
>>>> The security considerations state that the draft removes s= ome
>>>> places
>>>> that some of the P-Headers can be sent, but expands that t= o some
>>>> other
>>>> places. Further, it says that neither introduce new securi= ty
>>>> considerations beyond those in 7315.
>>>>
>>>> I accept that for the reduction part. But I'm not sure we = can state
>>>> that
>>>> sort of thing for the expansion part, at least without som= e more
>>>> discussion. Since 7315 already acknowledges potential priv= acy
>>>> issues
>>>> around P-Access-Network-Info, I'd like to at least see a s= entence
>>>> or two
>>>> about the allowance of that in ACK requests, even if they = just say
>>>> that
>>>> this addition makes things no worse than they already are.=
>>>
>>>
>>> OLD:
>>>
>>> The security considerations for P- header fields are defined i= n
>>>   [RFC7315].  This specification allows some he= ader fields to be
>>>   present in messages where they were previously not= allowed, and
>>>   disallow some header fields to be present in messa= ges where they
>>> were
>>>   previously allowed. That does not cause any securi= ty issues, but
>>>   implementations need to be aware that implementati= ons may not have
>>>   been updated according to this document, and take = proper actions
>>> if a
>>>   header field occur, or does not occur, in a messag= e where it
>>> should
>>>   occur (or occurs in a message where it should not = occur).
>>>
>>>
>>>
>>> NEW:
>>>
>>> The security considerations for these P- header fields are def= ined
>>> in
>>>   [RFC7315].  This specification allows some he= ader fields to be
>>>   present in messages where they were previously not= allowed, and
>>> the
>>> security considerations and assumptions (e.g. regarding only s= ending
>>> Information to trusted entities) also to those messages. In >>> addition,
>>> this specification also disallow some header fields to be pres= ent
>>> in message where they were previously allowed. That does not c= ause
>>> any security issues, but implementations need to be aware that=
>>> implementations may not have been updated according to this >>> document,
>>> and take proper actions if a header field occur, or does not o= ccur,
>>> in a message where it should occur (or occurs in a message whe= re it
>>> should not occur).
>>>
>>>
>>>
>>>> Editorial:
>>>>
>>>> -5, first sentence: "The security considerations for = P- header
>>>> fields
>>>> are defined in
>>>>   [RFC7315]"
>>>> I assume this means 7315 discusses the security considerat= ions for
>>>> these
>>>> P-Headers specifically, not P-Headers in general. Is this = the
>>>> intent? If
>>>> so, I suggest:
>>>>
>>>> s/... for P-header fields.../ ... for these P-header field= s...
>>>
>>> I=B9ll fix as suggested (ass new text above).
>>>
>>> Regards,
>>>
>>> Christer
 --_000_7594FB04B1934943A5C02806D1A2204B380FFF70ESESSMB209erics_-- From nobody Wed Jun 22 08:16:33 2016 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 4013F12DE1D; Wed, 22 Jun 2016 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 E-GVJYXwp9bL; Wed, 22 Jun 2016 08:16:28 -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 E11BD12DB2E; Wed, 22 Jun 2016 08:04:00 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5MF3rxe099481 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 10:03:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 22 Jun 2016 10:03:56 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380FFF70@ESESSMB209.ericsson.se> References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> <8D74E280-1141-469D-9627-23E38A2F9478@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FFF70@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: SIPCORE , Gonzalo Salgueiro , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:16:31 -0000 Please go ahead. It might be worth replying to the IETF last call = announcement with a mention of the update, in case anyone has a review = in progress. Thanks! Ben. On 22 Jun 2016, at 9:59, Christer Holmberg wrote: > Good :) > > Is it ok of I submit a new version of the draft? That way the new text = > will be available during IETF last call. > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: =E2=80=8E22/=E2=80=8E06/=E2=80=8E2016 17:47 > To: Christer Holmberg > Cc: Gonzalo Salgueiro; = > draft-holmberg-dispatch-rfc7315-updates.all@ietf.org; = > SIPCORE > Subject: Re: AD Evaluation of = > draft-holmberg-dispatch-rfc7315-updates-06 > > Works for me. > > Thanks! > > Ben. > > On 22 Jun 2016, at 2:18, Christer Holmberg wrote: > >> Hi, >> >> NEW: >> >> =E2=80=9DThe security considerations for these P- header fields are= >> defined in >> [RFC7315]. This specification allows some header fields to be >> present in messages where they were previously not allowed, and = >> the >> security considerations and assumptions (e.g. regarding only >> sending >> Information to trusted entities) also to those messages. In >> addition, >> this specification also disallow some header fields to be present >> in message where they were previously allowed. That does not cause >> any security issues, but implementations need to be aware that >> implementations may not have been updated according to this >> document, >> and take proper actions if a header field occur, or does not = >> occur, >> in a message where it should occur (or occurs in a message where = >> it >> should not occur). This document adds the ability to include >> P-Access-Network-Info in ACK requests. As documented in = >> [RFC7315], >> P-Access-Network-Info may include privacy sensitive information, >> including >> the user's location. The security and privacy considerations for >> P-Access-Network-Info in ACK requests are similar to those for the >> other >> SIP requests discussed in [RFC7315].=E2=80=9D >> >> Regards, >> >> Christer >> >> >> From: Christer Holmberg >> = > >> Date: Wednesday 22 June 2016 at 05:28 >> To: "gsalguei@cisco.com" >> >, Ben Campbell >> > >> Cc: >> "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" >> >, >> "sipcore@ietf.org" >> > >> Subject: RE: AD Evaluation of >> draft-holmberg-dispatch-rfc7315-updates-06 >> Resent-From: > >> Resent-To: Christer Holmberg >> = >, >> Nevenka Biondic >> >, >> "gsalguei@cisco.com" >> >, Ben Campbell >> >, "A. Mahoney" >> > >> Resent-Date: Wednesday 22 June 2016 at 05:28 >> >> Hi, >> >> We can add the text. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Gonzalo Salgueiro (gsalguei) >> Sent: 21/06/2016 19:44 >> To: Ben Campbell >> Cc: Christer Holmberg; >> draft-holmberg-dispatch-rfc7315-updates.all@ietf.org; >> SIPCORE >> Subject: Re: AD Evaluation of >> draft-holmberg-dispatch-rfc7315-updates-06 >> >> >>> On Jun 21, 2016, at 11:22 AM, Ben Campbell >>> > wrote: >>> >>> That's a good start, but don't be surprised if we get questions >>> specifically about adding NPLI to ACK requests. some language to the >>> effect of the following might help: >>> >>> "This document adds the ability to include P-Access-Network-Info in >>> ACK requests. As documented in RFC7315, P-Access-Network-Info may >>> include privacy sensitive information, including the user's = >>> location. >>> The security and privacy considerations for P-Access-Network-Info in >>> ACK requests are similar to those for the other SIP requests >>> discussed in RFC7315.=E2=80=9D >> >> I=E2=80=99m fine with adding such text. >> >> Christer - Can we append this to your proposed text? >> >> Gonzalo >> >> >>> >>> Thanks! >>> >>> Ben. >>> >>> On 21 Jun 2016, at 3:26, Christer Holmberg wrote: >>> >>>> Hi Ben, >>>> >>>> See inline. >>>> >>>>> -------------- >>>>> >>>>> Substantive: >>>>> >>>>> The security considerations state that the draft removes some >>>>> places >>>>> that some of the P-Headers can be sent, but expands that to some >>>>> other >>>>> places. Further, it says that neither introduce new security >>>>> considerations beyond those in 7315. >>>>> >>>>> I accept that for the reduction part. But I'm not sure we can = >>>>> state >>>>> that >>>>> sort of thing for the expansion part, at least without some more >>>>> discussion. Since 7315 already acknowledges potential privacy >>>>> issues >>>>> around P-Access-Network-Info, I'd like to at least see a sentence >>>>> or two >>>>> about the allowance of that in ACK requests, even if they just say >>>>> that >>>>> this addition makes things no worse than they already are. >>>> >>>> >>>> OLD: >>>> >>>> The security considerations for P- header fields are defined in >>>> [RFC7315]. This specification allows some header fields to be >>>> present in messages where they were previously not allowed, and >>>> disallow some header fields to be present in messages where they >>>> were >>>> previously allowed. That does not cause any security issues, but >>>> implementations need to be aware that implementations may not = >>>> have >>>> been updated according to this document, and take proper actions >>>> if a >>>> header field occur, or does not occur, in a message where it >>>> should >>>> occur (or occurs in a message where it should not occur). >>>> >>>> >>>> >>>> NEW: >>>> >>>> The security considerations for these P- header fields are defined >>>> in >>>> [RFC7315]. This specification allows some header fields to be >>>> present in messages where they were previously not allowed, and >>>> the >>>> security considerations and assumptions (e.g. regarding only = >>>> sending >>>> Information to trusted entities) also to those messages. In >>>> addition, >>>> this specification also disallow some header fields to be present >>>> in message where they were previously allowed. That does not cause >>>> any security issues, but implementations need to be aware that >>>> implementations may not have been updated according to this >>>> document, >>>> and take proper actions if a header field occur, or does not occur, >>>> in a message where it should occur (or occurs in a message where it >>>> should not occur). >>>> >>>> >>>> >>>>> Editorial: >>>>> >>>>> -5, first sentence: "The security considerations for P- header >>>>> fields >>>>> are defined in >>>>> [RFC7315]" >>>>> I assume this means 7315 discusses the security considerations for >>>>> these >>>>> P-Headers specifically, not P-Headers in general. Is this the >>>>> intent? If >>>>> so, I suggest: >>>>> >>>>> s/... for P-header fields.../ ... for these P-header fields... >>>> >>>> I=C2=B9ll fix as suggested (ass new text above). >>>> >>>> Regards, >>>> >>>> Christer From nobody Wed Jun 22 09:58:30 2016 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 E081812D918; Wed, 22 Jun 2016 09:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 inI794_h3Omz; Wed, 22 Jun 2016 09:58:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1C412D95B; Wed, 22 Jun 2016 09:58:19 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-dd-576ac3aad237 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 36.1B.18043.AA3CA675; Wed, 22 Jun 2016 18:58:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 18:58:17 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 Thread-Index: AQHRyynLvjd673syp0uC1ZoRFIN0E5/zqNkAgABAuACAABb4AIAAxKC3gABjCACAAEnXgIAAJODG///f1QCAAEFt4A== Date: Wed, 22 Jun 2016 16:58:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38100825@ESESSMB209.ericsson.se> References: <87A3DCDE-B8BC-4ADE-8129-70A4C0E92C3D@nostrum.com> <54648860-7461-4A4E-948A-A1C9FAAC7FFC@nostrum.com> <83801023-F21E-417C-B49C-49820CCE4DF2@cisco.com> <7594FB04B1934943A5C02806D1A2204B380FB854@ESESSMB209.ericsson.se> <8D74E280-1141-469D-9627-23E38A2F9478@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FFF70@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7ou6qw1nhBqf+CFvM7zzNbrH69SxW i7lT/Cy+/tjE5sDiMeX3RlaPJUt+MnnM2vmEJYA5issmJTUnsyy1SN8ugSujZ+krloI5MRUn tmg1ML6J7GLk5JAQMJHo+PaHBcIWk7hwbz1bFyMXh5DAEUaJfe1PoZwljBLNc2exdjFycLAJ WEh0/9MGaRARUJJ43ryVBaSGWWA3o8TV2a+YQRLCAh4Sjw7tY4Qo8pS4+HsjO4SdJXH92RE2 EJtFQFWia8V6MJtXwFfiRtMSqGW/mCVOzb/HBJLgFLCXOLp7Mth5jEDnfT+1BizOLCAucevJ fCaIswUkluw5zwxhi0q8fPyPFcJWklh0+zMTyNHMApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywT GMVmIZk6C6FjFpKOWUg6FjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjKyDW35b7WA8 +NzxEKMAB6MSD++DHZnhQqyJZcWVuYcYJTiYlUR45x7MChfiTUmsrEotyo8vKs1JLT7EKM3B oiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAKLgg4kPvub5jR3Y/nbrpeqrajLkTHUuP7WVi rlwT9N067OnvMKmNZ7welmTbu64o+WQQ2qHB76p+1Mbuf01bT03pWbb3D7fv3lVuZnFzwRyh dwovlae/8rDdJ+vCKCa53Oec7bfPXzo3V62K0jkzl3m1UeLCx9s1TI8elgjYebCtI2/XZuUK XyWW4oxEQy3mouJEACAvLASoAgAA Archived-At: Cc: SIPCORE , Gonzalo Salgueiro , "draft-holmberg-dispatch-rfc7315-updates.all@ietf.org" Subject: Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:58:29 -0000 SGksDQoNCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0wNyksIGFuZCBJJ2xsIHJlcGx5 IHRvIHRoZSBJRVRGIGUtbWFpbC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVt LmNvbV0gDQpTZW50OiAyMiBKdW5lIDIwMTYgMTg6MDQNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IEdvbnphbG8gU2FsZ3VlaXJvIDxn c2FsZ3VlaUBjaXNjby5jb20+OyBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0 ZXMuYWxsQGlldGYub3JnOyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IEFEIEV2YWx1YXRpb24gb2YgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVz LTA2DQoNClBsZWFzZSBnbyBhaGVhZC4gSXQgbWlnaHQgYmUgd29ydGggcmVwbHlpbmcgdG8gdGhl IElFVEYgbGFzdCBjYWxsIGFubm91bmNlbWVudCB3aXRoIGEgbWVudGlvbiBvZiB0aGUgdXBkYXRl LCBpbiBjYXNlIGFueW9uZSBoYXMgYSByZXZpZXcgaW4gcHJvZ3Jlc3MuDQoNClRoYW5rcyENCg0K QmVuLg0KDQpPbiAyMiBKdW4gMjAxNiwgYXQgOTo1OSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6 DQoNCj4gR29vZCA6KQ0KPg0KPiBJcyBpdCBvayBvZiBJIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIG9m IHRoZSBkcmFmdD8gVGhhdCB3YXkgdGhlIG5ldyB0ZXh0IA0KPiB3aWxsIGJlIGF2YWlsYWJsZSBk dXJpbmcgIElFVEYgbGFzdCBjYWxsLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0K PiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBGcm9tOiBCZW4gQ2FtcGJlbGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4g U2VudDog4oCOMjIv4oCOMDYv4oCOMjAxNiAxNzo0Nw0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4gQ2M6IEdvbnphbG8gU2Fs Z3VlaXJvPG1haWx0bzpnc2FsZ3VlaUBjaXNjby5jb20+Ow0KPiBkcmFmdC1ob2xtYmVyZy1kaXNw YXRjaC1yZmM3MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1ob2xtDQo+IGJl cmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLmFsbEBpZXRmLm9yZz47DQo+IFNJUENPUkU8bWFp bHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBBRCBFdmFsdWF0aW9uIG9mDQo+ IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy0wNg0KPg0KPiBXb3JrcyBm b3IgbWUuDQo+DQo+IFRoYW5rcyENCj4NCj4gQmVuLg0KPg0KPiBPbiAyMiBKdW4gMjAxNiwgYXQg MjoxOCwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+DQo+PiBIaSwNCj4+DQo+PiBORVc6DQo+ Pg0KPj4gICAg4oCdVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZSBQLSBoZWFk ZXIgZmllbGRzIGFyZSANCj4+IGRlZmluZWQgaW4NCj4+ICAgIFtSRkM3MzE1XS4gIFRoaXMgc3Bl Y2lmaWNhdGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlDQo+PiAgICBwcmVzZW50 IGluIG1lc3NhZ2VzIHdoZXJlIHRoZXkgd2VyZSBwcmV2aW91c2x5IG5vdCBhbGxvd2VkLCBhbmQg DQo+PiB0aGUNCj4+ICAgIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBhc3N1bXB0aW9ucyAo ZS5nLiByZWdhcmRpbmcgb25seSANCj4+IHNlbmRpbmcNCj4+ICAgIEluZm9ybWF0aW9uIHRvIHRy dXN0ZWQgZW50aXRpZXMpIGFsc28gdG8gdGhvc2UgbWVzc2FnZXMuIEluIA0KPj4gYWRkaXRpb24s DQo+PiAgICB0aGlzIHNwZWNpZmljYXRpb24gYWxzbyBkaXNhbGxvdyBzb21lIGhlYWRlciBmaWVs ZHMgdG8gYmUgcHJlc2VudA0KPj4gICAgaW4gbWVzc2FnZSB3aGVyZSB0aGV5IHdlcmUgcHJldmlv dXNseSBhbGxvd2VkLiBUaGF0IGRvZXMgbm90IGNhdXNlDQo+PiAgICBhbnkgc2VjdXJpdHkgaXNz dWVzLCBidXQgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgYXdhcmUgdGhhdA0KPj4gICAgaW1w bGVtZW50YXRpb25zIG1heSBub3QgaGF2ZSBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nIHRvIHRoaXMg DQo+PiBkb2N1bWVudCwNCj4+ICAgIGFuZCB0YWtlIHByb3BlciBhY3Rpb25zIGlmIGEgaGVhZGVy IGZpZWxkIG9jY3VyLCBvciBkb2VzIG5vdCANCj4+IG9jY3VyLA0KPj4gICAgaW4gYSBtZXNzYWdl IHdoZXJlIGl0IHNob3VsZCBvY2N1ciAob3Igb2NjdXJzIGluIGEgbWVzc2FnZSB3aGVyZSANCj4+ IGl0DQo+PiAgICBzaG91bGQgbm90IG9jY3VyKS4gVGhpcyBkb2N1bWVudCBhZGRzIHRoZSBhYmls aXR5IHRvIGluY2x1ZGUNCj4+ICAgIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBpbiBBQ0sgcmVxdWVz dHMuIEFzIGRvY3VtZW50ZWQgaW4gW1JGQzczMTVdLA0KPj4gICAgUC1BY2Nlc3MtTmV0d29yay1J bmZvIG1heSBpbmNsdWRlIHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCANCj4+IGluY2x1 ZGluZw0KPj4gICAgdGhlIHVzZXIncyBsb2NhdGlvbi4gVGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5 IGNvbnNpZGVyYXRpb25zIGZvcg0KPj4gICAgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGluIEFDSyBy ZXF1ZXN0cyBhcmUgc2ltaWxhciB0byB0aG9zZSBmb3IgdGhlIA0KPj4gb3RoZXINCj4+ICAgIFNJ UCByZXF1ZXN0cyBkaXNjdXNzZWQgaW4gIFtSRkM3MzE1XS7igJ0NCj4+DQo+PiBSZWdhcmRzLA0K Pj4NCj4+IENocmlzdGVyDQo+Pg0KPj4NCj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnDQo+PiA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20NCj4+ID4+DQo+PiBEYXRlOiBXZWRuZXNkYXkgMjIgSnVuZSAyMDE2IGF0IDA1 OjI4DQo+PiBUbzogImdzYWxndWVpQGNpc2NvLmNvbTxtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29t PiINCj4+IDxnc2FsZ3VlaUBjaXNjby5jb208bWFpbHRvOmdzYWxndWVpQGNpc2NvLmNvbT4+LCBC ZW4gQ2FtcGJlbGwgDQo+PiA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+ Pg0KPj4gQ2M6DQo+PiAiZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLmFs bEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVz LmFsbEBpZXRmLm9yZz4iDQo+PiA8ZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRh dGVzLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaG8NCj4+IGxtYmVyZy1kaXNwYXRjaC1yZmM3 MzE1LXVwZGF0ZXMuYWxsQGlldGYub3JnPj4sDQo+PiAic2lwY29yZUBpZXRmLm9yZzxtYWlsdG86 c2lwY29yZUBpZXRmLm9yZz4iDQo+PiA8c2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4+DQo+PiBTdWJqZWN0OiBSRTogQUQgRXZhbHVhdGlvbiBvZg0KPj4gZHJhZnQtaG9s bWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLTA2DQo+PiBSZXNlbnQtRnJvbTogPGFsaWFz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPj4gUmVz ZW50LVRvOiBDaHJpc3RlciBIb2xtYmVyZw0KPj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tDQo+PiA+PiwNCj4+IE5l dmVua2EgQmlvbmRpYw0KPj4gPG5ldmVua2EuYmlvbmRpY0Blcmljc3Nvbi5jb208bWFpbHRvOm5l dmVua2EuYmlvbmRpY0Blcmljc3Nvbi5jb20+PiwNCj4+ICJnc2FsZ3VlaUBjaXNjby5jb208bWFp bHRvOmdzYWxndWVpQGNpc2NvLmNvbT4iDQo+PiA8Z3NhbGd1ZWlAY2lzY28uY29tPG1haWx0bzpn c2FsZ3VlaUBjaXNjby5jb20+PiwgQmVuIENhbXBiZWxsIA0KPj4gPGJlbkBub3N0cnVtLmNvbTxt YWlsdG86YmVuQG5vc3RydW0uY29tPj4sICJBLiBNYWhvbmV5Ig0KPj4gPG1haG9uZXlAbm9zdHJ1 bS5jb208bWFpbHRvOm1haG9uZXlAbm9zdHJ1bS5jb20+Pg0KPj4gUmVzZW50LURhdGU6IFdlZG5l c2RheSAyMiBKdW5lIDIwMTYgYXQgMDU6MjgNCj4+DQo+PiBIaSwNCj4+DQo+PiBXZSBjYW4gYWRk IHRoZSB0ZXh0Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiBTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IEZyb206IEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSk8bWFpbHRvOmdzYWxndWVp QGNpc2NvLmNvbT4NCj4+IFNlbnQ6IDIxLzA2LzIwMTYgMTk6NDQNCj4+IFRvOiBCZW4gQ2FtcGJl bGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4+IENjOiBDaHJpc3RlciBIb2xtYmVyZzxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsNCj4+IGRyYWZ0LWhvbG1iZXJnLWRp c3BhdGNoLXJmYzczMTUtdXBkYXRlcy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWhvbA0KPj4g bWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLmFsbEBpZXRmLm9yZz47DQo+PiBTSVBDT1JF PG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IEFEIEV2YWx1YXRpb24g b2YNCj4+IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy0wNg0KPj4NCj4+ DQo+Pj4gT24gSnVuIDIxLCAyMDE2LCBhdCAxMToyMiBBTSwgQmVuIENhbXBiZWxsIA0KPj4+IDxi ZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4g VGhhdCdzIGEgZ29vZCBzdGFydCwgYnV0IGRvbid0IGJlIHN1cnByaXNlZCBpZiB3ZSBnZXQgcXVl c3Rpb25zIA0KPj4+IHNwZWNpZmljYWxseSBhYm91dCBhZGRpbmcgTlBMSSB0byBBQ0sgcmVxdWVz dHMuIHNvbWUgbGFuZ3VhZ2UgdG8gdGhlIA0KPj4+IGVmZmVjdCBvZiB0aGUgZm9sbG93aW5nIG1p Z2h0IGhlbHA6DQo+Pj4NCj4+PiAiVGhpcyBkb2N1bWVudCBhZGRzIHRoZSBhYmlsaXR5IHRvIGlu Y2x1ZGUgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGluIA0KPj4+IEFDSyByZXF1ZXN0cy4gQXMgZG9j dW1lbnRlZCBpbiBSRkM3MzE1LCBQLUFjY2Vzcy1OZXR3b3JrLUluZm8gbWF5IA0KPj4+IGluY2x1 ZGUgcHJpdmFjeSBzZW5zaXRpdmUgaW5mb3JtYXRpb24sIGluY2x1ZGluZyB0aGUgdXNlcidzIA0K Pj4+IGxvY2F0aW9uLg0KPj4+IFRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9u cyBmb3IgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGluIA0KPj4+IEFDSyByZXF1ZXN0cyBhcmUgc2lt aWxhciB0byB0aG9zZSBmb3IgdGhlIG90aGVyIFNJUCByZXF1ZXN0cyANCj4+PiBkaXNjdXNzZWQg aW4gUkZDNzMxNS7igJ0NCj4+DQo+PiBJ4oCZbSBmaW5lIHdpdGggYWRkaW5nIHN1Y2ggdGV4dC4N Cj4+DQo+PiBDaHJpc3RlciAtIENhbiB3ZSBhcHBlbmQgdGhpcyB0byB5b3VyIHByb3Bvc2VkIHRl eHQ/DQo+Pg0KPj4gR29uemFsbw0KPj4NCj4+DQo+Pj4NCj4+PiBUaGFua3MhDQo+Pj4NCj4+PiBC ZW4uDQo+Pj4NCj4+PiBPbiAyMSBKdW4gMjAxNiwgYXQgMzoyNiwgQ2hyaXN0ZXIgSG9sbWJlcmcg d3JvdGU6DQo+Pj4NCj4+Pj4gSGkgQmVuLA0KPj4+Pg0KPj4+PiBTZWUgaW5saW5lLg0KPj4+Pg0K Pj4+Pj4gLS0tLS0tLS0tLS0tLS0NCj4+Pj4+DQo+Pj4+PiBTdWJzdGFudGl2ZToNCj4+Pj4+DQo+ Pj4+PiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3RhdGUgdGhhdCB0aGUgZHJhZnQgcmVt b3ZlcyBzb21lIA0KPj4+Pj4gcGxhY2VzIHRoYXQgc29tZSBvZiB0aGUgUC1IZWFkZXJzIGNhbiBi ZSBzZW50LCBidXQgZXhwYW5kcyB0aGF0IHRvIA0KPj4+Pj4gc29tZSBvdGhlciBwbGFjZXMuIEZ1 cnRoZXIsIGl0IHNheXMgdGhhdCBuZWl0aGVyIGludHJvZHVjZSBuZXcgDQo+Pj4+PiBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBiZXlvbmQgdGhvc2UgaW4gNzMxNS4NCj4+Pj4+DQo+Pj4+PiBJIGFj Y2VwdCB0aGF0IGZvciB0aGUgcmVkdWN0aW9uIHBhcnQuIEJ1dCBJJ20gbm90IHN1cmUgd2UgY2Fu IA0KPj4+Pj4gc3RhdGUgdGhhdCBzb3J0IG9mIHRoaW5nIGZvciB0aGUgZXhwYW5zaW9uIHBhcnQs IGF0IGxlYXN0IHdpdGhvdXQgDQo+Pj4+PiBzb21lIG1vcmUgZGlzY3Vzc2lvbi4gU2luY2UgNzMx NSBhbHJlYWR5IGFja25vd2xlZGdlcyBwb3RlbnRpYWwgDQo+Pj4+PiBwcml2YWN5IGlzc3VlcyBh cm91bmQgUC1BY2Nlc3MtTmV0d29yay1JbmZvLCBJJ2QgbGlrZSB0byBhdCBsZWFzdCANCj4+Pj4+ IHNlZSBhIHNlbnRlbmNlIG9yIHR3byBhYm91dCB0aGUgYWxsb3dhbmNlIG9mIHRoYXQgaW4gQUNL IHJlcXVlc3RzLCANCj4+Pj4+IGV2ZW4gaWYgdGhleSBqdXN0IHNheSB0aGF0IHRoaXMgYWRkaXRp b24gbWFrZXMgdGhpbmdzIG5vIHdvcnNlIA0KPj4+Pj4gdGhhbiB0aGV5IGFscmVhZHkgYXJlLg0K Pj4+Pg0KPj4+Pg0KPj4+PiBPTEQ6DQo+Pj4+DQo+Pj4+IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBmb3IgUC0gaGVhZGVyIGZpZWxkcyBhcmUgZGVmaW5lZCBpbg0KPj4+PiAgIFtSRkM3MzE1 XS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlDQo+ Pj4+ICAgcHJlc2VudCBpbiBtZXNzYWdlcyB3aGVyZSB0aGV5IHdlcmUgcHJldmlvdXNseSBub3Qg YWxsb3dlZCwgYW5kDQo+Pj4+ICAgZGlzYWxsb3cgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlIHBy ZXNlbnQgaW4gbWVzc2FnZXMgd2hlcmUgdGhleSANCj4+Pj4gd2VyZQ0KPj4+PiAgIHByZXZpb3Vz bHkgYWxsb3dlZC4gVGhhdCBkb2VzIG5vdCBjYXVzZSBhbnkgc2VjdXJpdHkgaXNzdWVzLCBidXQN Cj4+Pj4gICBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBiZSBhd2FyZSB0aGF0IGltcGxlbWVudGF0 aW9ucyBtYXkgbm90IA0KPj4+PiBoYXZlDQo+Pj4+ICAgYmVlbiB1cGRhdGVkIGFjY29yZGluZyB0 byB0aGlzIGRvY3VtZW50LCBhbmQgdGFrZSBwcm9wZXIgYWN0aW9ucyANCj4+Pj4gaWYgYQ0KPj4+ PiAgIGhlYWRlciBmaWVsZCBvY2N1ciwgb3IgZG9lcyBub3Qgb2NjdXIsIGluIGEgbWVzc2FnZSB3 aGVyZSBpdCANCj4+Pj4gc2hvdWxkDQo+Pj4+ICAgb2NjdXIgKG9yIG9jY3VycyBpbiBhIG1lc3Nh Z2Ugd2hlcmUgaXQgc2hvdWxkIG5vdCBvY2N1cikuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE5F VzoNCj4+Pj4NCj4+Pj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZSBQLSBo ZWFkZXIgZmllbGRzIGFyZSBkZWZpbmVkIA0KPj4+PiBpbg0KPj4+PiAgIFtSRkM3MzE1XS4gIFRo aXMgc3BlY2lmaWNhdGlvbiBhbGxvd3Mgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJlDQo+Pj4+ICAg cHJlc2VudCBpbiBtZXNzYWdlcyB3aGVyZSB0aGV5IHdlcmUgcHJldmlvdXNseSBub3QgYWxsb3dl ZCwgYW5kIA0KPj4+PiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYW5kIGFzc3VtcHRpb25z IChlLmcuIHJlZ2FyZGluZyBvbmx5IA0KPj4+PiBzZW5kaW5nIEluZm9ybWF0aW9uIHRvIHRydXN0 ZWQgZW50aXRpZXMpIGFsc28gdG8gdGhvc2UgbWVzc2FnZXMuIEluIA0KPj4+PiBhZGRpdGlvbiwg dGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gZGlzYWxsb3cgc29tZSBoZWFkZXIgZmllbGRzIHRvIGJl IA0KPj4+PiBwcmVzZW50IGluIG1lc3NhZ2Ugd2hlcmUgdGhleSB3ZXJlIHByZXZpb3VzbHkgYWxs b3dlZC4gVGhhdCBkb2VzIA0KPj4+PiBub3QgY2F1c2UgYW55IHNlY3VyaXR5IGlzc3VlcywgYnV0 IGltcGxlbWVudGF0aW9ucyBuZWVkIHRvIGJlIGF3YXJlIA0KPj4+PiB0aGF0IGltcGxlbWVudGF0 aW9ucyBtYXkgbm90IGhhdmUgYmVlbiB1cGRhdGVkIGFjY29yZGluZyB0byB0aGlzIA0KPj4+PiBk b2N1bWVudCwgYW5kIHRha2UgcHJvcGVyIGFjdGlvbnMgaWYgYSBoZWFkZXIgZmllbGQgb2NjdXIs IG9yIGRvZXMgDQo+Pj4+IG5vdCBvY2N1ciwgaW4gYSBtZXNzYWdlIHdoZXJlIGl0IHNob3VsZCBv Y2N1ciAob3Igb2NjdXJzIGluIGEgDQo+Pj4+IG1lc3NhZ2Ugd2hlcmUgaXQgc2hvdWxkIG5vdCBv Y2N1cikuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+PiBFZGl0b3JpYWw6DQo+Pj4+Pg0KPj4+Pj4g LTUsIGZpcnN0IHNlbnRlbmNlOiAiVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBQLSBo ZWFkZXIgDQo+Pj4+PiBmaWVsZHMgYXJlIGRlZmluZWQgaW4NCj4+Pj4+ICAgW1JGQzczMTVdIg0K Pj4+Pj4gSSBhc3N1bWUgdGhpcyBtZWFucyA3MzE1IGRpc2N1c3NlcyB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgZm9yIA0KPj4+Pj4gdGhlc2UgUC1IZWFkZXJzIHNwZWNpZmljYWxseSwgbm90 IFAtSGVhZGVycyBpbiBnZW5lcmFsLiBJcyB0aGlzIA0KPj4+Pj4gdGhlIGludGVudD8gSWYgc28s IEkgc3VnZ2VzdDoNCj4+Pj4+DQo+Pj4+PiBzLy4uLiBmb3IgUC1oZWFkZXIgZmllbGRzLi4uLyAu Li4gZm9yIHRoZXNlIFAtaGVhZGVyIGZpZWxkcy4uLg0KPj4+Pg0KPj4+PiBJwrlsbCBmaXggYXMg c3VnZ2VzdGVkIChhc3MgbmV3IHRleHQgYWJvdmUpLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+ Pg0KPj4+PiBDaHJpc3Rlcg0K From nobody Wed Jun 22 14:03:02 2016 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 C138112DC2A for ; Wed, 22 Jun 2016 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 KJKSlTnXizft for ; Wed, 22 Jun 2016 14:02:56 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 0B79212DC40 for ; Wed, 22 Jun 2016 14:02:45 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f6so48559942ith.0 for ; Wed, 22 Jun 2016 14:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fikl5mwLFeRSAudwKuftCO93gPP2dwtDjfvwqH7UqB4=; b=RrAHjaqOQbWFy1ByYyvgGY1uiPsTsdchwUY0NerdUZJPmjFwb0aNg+0vkKjAkiQKZN DNN4E3lC67z85jPTwlYiXwURviWgrWX4pNZSuHpva9Rg3S7ACreD72pE04RsFHkJmuNO Ei9/Uzb+FO0sEE4q+2ZDln+buZI/Zk9dbUMkeOnAJtpTiIeTckyLhOkQq0deVxclu0v9 F2aHKAvSfXQiZ/+1UQn+DaX1I43D+36Hzgr5ueFcn6GOYjdBNInZecdohxVvRTJmC00r 5PGjE64zsPu6pS3kaUYU/GWb9Whxlvut9J7KW/S9F0QT9qsRL3h5DyMACPIjuS689ErA xVXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fikl5mwLFeRSAudwKuftCO93gPP2dwtDjfvwqH7UqB4=; b=B1dol0tquLxni7c7uzXcj1UU2qXJMXVgTTqzyqU5uCKESIfeDqHh+lETnwIf9YWaSC X1Ilbfj0mzYsyh5/xhfOJ2ZGc3QZWMiYJRLzzaLmn+7fTnjmkOx2Khk6e5s5nww3P0pt EYjJ6DMARcZ/5+p2o6c2o/uGYhGIZo3hPd76Ub7jI9szoAiXLaQG0jGzd/iD09pg5SkF sr3r/CvUxIBhi6RoR0YHl3J9rYDpk9QYkyHZID8VzLUDVr+4VvJKmfUrd8CDMVu8Dlwn 6jqZzy4Nrc+novCOJNNPYl11yODKXZw1Gw1dAx3lG1JucwUSX/4mL6geofJN2TEW98iP 6Cww== X-Gm-Message-State: ALyK8tJefLi2497wSeYeK62DleUOGStltzgF8qNCJW+y3DNSWT3hckwuGRKs9knhBST9mA== X-Received: by 10.36.154.135 with SMTP id l129mr16573363ite.79.1466629364244; Wed, 22 Jun 2016 14:02:44 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id k140sm323716itb.13.2016.06.22.14.02.42 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 14:02:43 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id g13so48254768ioj.1 for ; Wed, 22 Jun 2016 14:02:42 -0700 (PDT) X-Received: by 10.107.130.31 with SMTP id e31mr30494095iod.66.1466629362778; Wed, 22 Jun 2016 14:02:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Wed, 22 Jun 2016 14:02:41 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 22 Jun 2016 17:02:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=001a113ed0d02f8e160535e44219 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:03:00 -0000 --001a113ed0d02f8e160535e44219 Content-Type: text/plain; charset=UTF-8 Rifaat, In your example, I would expect to issue an HTTP request to create the conference, get the SIP URI back (with authentication token embedded in the URI) and place the SIP call to this URI. I do not see a reason why any standardization effort is required to implement this. Regards, _____________ Roman Shpount On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shekh-Yusef wrote: > Roman, > > I think that the question of how to exactly carry the token in SIP request > is a minor issue *at this stage*. > We are discussing the idea and concept of delegating both the AuthN and > AuthZ to separate server(s) and how to achieve that. > > Regards, > Rifaat > > > On Tue, Jun 21, 2016 at 7:50 PM, Roman Shpount wrote: > >> Furthermore, reading all of this, I cannot understand why Authorization >> token cannot be a part of SIP URL, either as user part or URL parameter. >> This does not need to be anything more then service specific URL and does >> not require a new SIP header or authentication mechanism. >> >> _____________ >> Roman Shpount >> >> On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon >> wrote: >> >>> >>> It's not really what I'm looking for, no, and after mulling this over a >>> bit, I fear going farther along this path would only drill down into levels >>> of complexity that will likely make this harder to understand rather than >>> easier. >>> >>> I do acknowledge that you describe the INVITE as being rejected if it >>> doesn't contain a token - but that's not the same thing as saying the >>> INVITE will be rejected because the relying party makes an authorization >>> decision based on the attributes in the token. It's more like an INVITE >>> being rejected because a user agent can't supply an Authorization header. I >>> will reiterate that I don't think the kinds of attributes you are proposing >>> should be in the scope of an effort that will try to address a framework >>> for authorizing SIP requests. I don't think the values of the attributes >>> (as opposed to the mere presence of some attributes) have anything to do >>> with authorizing the SIP request that you propose would carry the >>> attributes. >>> >>> With regards to this whole conferencing example, it does seem a bit >>> contrived to me, like you're sketching a SIP-based way of setting >>> conference policy on the fly that happens to require the kind of attributes >>> you want, and then saying that demonstrates the need for the attributes. >>> The fact that all of the ways to do conference policy we can point to in >>> fact do it via the web makes it hard for me to understand why we should >>> create a SIP-based way of doing this. To me, it looks like you're opening a >>> problem space that has much more to do with reshaping the way that SIP does >>> conferences (and again, as Radhika's mail pointing out, there's been a lot >>> of thinking about this since the days of RFC4579) than it does with >>> defining a framework for authorizing SIP requests. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> From: Rifaat Shekh-Yusef >>> Date: Thursday, June 16, 2016 at 6:19 AM >>> To: Jon Peterson >>> Cc: "sipcore@ietf.org" >>> Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 >>> >>> The attributes I provided are examples of attributes that might be >>> provided in an access token; it was not meant to include all the attributes >>> for this use case, because my intention was not to focus on conference >>> server, but to discuss the idea in general. >>> >>> The following could be used with the conference factory to request a >>> conference focus: >>> The INVITE sent to the conference factory could include a token that has >>> a * conference-type* attribute which could take one of the following >>> values: *audio, video, webconference, audio-webconference, or >>> video-webconference*. >>> The conference factory will then issue a *conference uri* for the >>> requested conference type, assuming the token is valid. If the >>> *conference-type* attribute is missing, then the request would be >>> rejected. >>> >>> Is that what you are looking for? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> >>> On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon >> > wrote: >>> >>>> >>>>> >>>>> In that case, if you could furnish a use case with attributes that >>>>> would be carried in a SIP iNVITE that are actually salient to the >>>>> authorization of that particular SIP request, we'd be getting a lot closer >>>>> to common ground. >>>>> >>>>> >>>> An obvious example would be an INVITE with a token sent to a conference >>>> factory to authorize the creation of a focus. >>>> >>>> >>>> We're still talking past each other. My point above was that the two >>>> attributes you specified - constraints on conference size and media types - >>>> have nothing to do with the authorization of the INVITE carrying those >>>> attributes. Like, unless the conference size permitted is 0, then the >>>> INVITE that creates an ad hoc conference and connects you to its bridge is >>>> not going to be rejected by the focus on the basis of that conference size >>>> attribute. If the maximum conference size were 0, the AuthZ service just >>>> wouldn't attach a token to an INVITE as it would never be allowed to start >>>> a conference. Same goes for media types. >>>> >>>> Instead, what your two attributes constrain is what happens after the >>>> conference is created: when ten users try to dial in to a conference with a >>>> permitted size of nine, say. That tenth INVITE would get rejected - not the >>>> conference-forming INVITE that you propose would carry the token. That's >>>> why what you're proposing is overloading the INVITE to tunnel conference >>>> policy constraints to the focus. I mean, maybe that's a problem space worth >>>> investigating, though I suspect there are good reasons why RFC4353 >>>> specified that conference policy is not manipulated with SIP - mostly >>>> because the semantics of manipulating conference policy probably don't map >>>> well onto dialog-forming SIP requests. But I think that conference policy >>>> provisioning problem space would be pretty far from where we started in >>>> this discussion. >>>> >>>> Let me reiterate what I wrote in my previous mail, which I quote here >>>> at the top: "furnish a use case with attributes that would be carried in a >>>> SIP iNVITE that are actually salient to the authorization of that >>>> particular SIP request." Again: "that particular SIP request." Not later >>>> transactions in some broader context in which the original user agent >>>> probably isn't even an endpoint. >>>> >>>> The Authorization header in SIP, for example, is actually used by the >>>> UAS to make a decision about whether or not to authorize the request in >>>> which the header appears. The token that you propose a SIP INVITE would >>>> carry in this case is not used by the relying party to make a decision >>>> about whether or not that INVITE is authorized. That's why I believe this >>>> conference policy issue is a different problem space entirely from figuring >>>> out how to implement attribute-based authorization for SIP requests. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> > --001a113ed0d02f8e160535e44219 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rifaat,<= /span>

In you= r example, I would expect to issue an HTTP request to create the conference= , get the SIP URI back (with authentication token embedded in the URI) and = place the SIP call to this URI. I do not see a reason why any=C2=A0standard= ization=C2=A0effort is required to implement this.
=
=
Regards= ,

_______= ______
Roman Shpount

On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shek= h-Yusef <rifaat.ietf@gmail.com> wrote:
Roman,

I think that th= e question of how to exactly carry the token in SIP request is a minor issu= e at this stage.
We are discussing the idea and concep= t of delegating both the AuthN and AuthZ to separate server(s) and how to a= chieve that.

Regards,
=C2=A0Rifaat


On Tue, Jun 21, 2016 at 7:5= 0 PM, Roman Shpount <roman@telurix.com> wrote:
Furthermore, reading all of this, I c= annot understand why Authorization token cannot be a part of SIP URL, eithe= r as user part or URL parameter. This does not need to be anything more the= n service specific URL and does not require a new SIP header or authenticat= ion mechanism.

_____________
Roman Shpount

On Tue, Jun 21, 2016 at 7:46 PM, P= eterson, Jon <jon.peterson@neustar.biz> wrote:

It's not really what I'm looking for, no, and after mulling th= is over a bit, I fear going farther along this path would only drill down i= nto levels of complexity that will likely make this harder to understand ra= ther than easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying t= he INVITE will be rejected because the relying party makes an authorization= decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent ca= n't supply an Authorization header. I will reiterate that I don't t= hink the kinds of attributes you are proposing should be in the scope of an= effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attribut= es (as opposed to the mere presence of some attributes) have anything to do= with authorizing the SIP request that you propose would carry the attribut= es.

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting confere= nce policy on the fly that happens to require the kind of attributes you wa= nt, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lo= t of thinking about this since the days of RFC4579) than it does with defin= ing a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.


The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the t= wo attributes you specified - constraints on conference size and media type= s - have nothing to do with the authorization of the INVITE carrying those = attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore




--001a113ed0d02f8e160535e44219-- From nobody Wed Jun 22 15:29:28 2016 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 A51D612DD5C for ; Wed, 22 Jun 2016 15:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 AYuVqPmS-ulR for ; Wed, 22 Jun 2016 15:29:23 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 C6F0E12DD50 for ; Wed, 22 Jun 2016 15:29:22 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5MMMtI8001757; Wed, 22 Jun 2016 18:29:20 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23n298rjd4-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2016 18:29:20 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 22 Jun 2016 18:29:19 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAA== Date: Wed, 22 Jun 2016 22:29:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.14] Content-Type: multipart/alternative; boundary="_000_D390592919FF98jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-22_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606220229 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:29:26 -0000 --_000_D390592919FF98jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The token added to the INVITE is not a policy; it is an authorization by th= e AuthZ Server to allow this request to create a conference focus. Well, this is the complexity level I was trying to avoid, but, I do agree t= hat what your proposed token carries isn't strictly a conference policy - i= t is instead a policy that constrains conference policies that users are al= lowed to set. The thing that RFC4353 calls "conference policy" is essentially a policy fo= r a particular instance of a conference. The two attributes you initially p= roposed actually constrain conference policies rather than conferences - th= at is, they apply to all conferences that I might try to set policy for, ra= ther than any given conference instance. When I set up a particular confere= nce, for example, I might want it to be voice only, and to have four seats.= That's the policy I want for that conference. I gather the attributes you = proposed are the constraints that my local administrative domain imposes on= conferences I create, so the conference policy I set for any given policy = needs to be a subset of those constraints. If my administrative domain limi= ts me to only three-seat conferences, then when I try to set a conference p= olicy for four seats, that manipulation of conference policy would presumab= ly be rejected when it is compared to my administrative domain's constraint= s. But of course, in the ad hoc corner case you are considering, the conferenc= e bridge has no way of anticipating how many users Alice will try to add to= the conference - so, her initial INVITE containing the parameter would nev= er be rejected for violating the constraint on conference size, only later = INVITEs would be. That attribute has nothing to do with authorizing the INV= ITE carrying the token. Moreover, how does one actually manipulate my conference policy? According = to RFC4353, it isn't with SIP. Probably with the web, with an HTTP request.= RFC4579 et al do not provide provisions for setting conference policy. Add= ing the attributes you proposed to SIP isn't really about setting conferenc= e policy, it's about alerting the conference service to the constraints on = conference policy that are imposed by my administrative domain. This is an = important distinction, because it shows how far removed that SIP transactio= n actually is from the way conference policy is set. Why would I send a SIP= request with the constraints on conference policy if I'm only going to hav= e to use HTTP to actually set conference policy later? Why wouldn't my admi= nistrative domain have me attach its imposed constraints on conference poli= cy to the actual HTTP message that is manipulating conference policy? Now, Alice decides to start an audio conference; to do that, the phone obta= ins an access token from the AuthNZ server that allows Alice to start a con= ference of the type =93audio=94. I did figure you had something like this is mind - perhaps that Alice would= send her INVITE to the IdP first, and that the IdP would then inspect and= authorize a conference policy that Alice somehow conveyed via the INVITE. = Through what field or parameter do you suppose to INVITE will convey that A= lice intends for the conference to be restricted to audio media? Or do you = perhaps mean that Alice would use HTTP to inform her IdP of the media choic= es for the conference - in the which case policy for the conference starts = in the HTTP realm, and should certainly stay there. I imagine that in the corner case of an ad hoc conference, the INVITE that = Alice is sending would contain some session negotiation parameters that cou= ld be taken to imply what sorts of media types Alice wants to allow or forb= id in the conference. But I will reiterate that RFC4579 and the related spe= cifications I can think of off the top of my head do not contain a provisio= n for the INVITE to communicate session policy information - and I don't th= ink it is safe to infer from the SDP in an INVITE that Alice intends to lim= it the conference to the media type(s) it offers. Moreover, in the ad hoc conference corner case, I see no plausible justific= ation for why the conference bridge would ever reject Alice's initial INVIT= E based on the media type it contains. If she's sending her INVITE through = the IdP via SIP, it would never even forward the request, let alone issue a= token for it, if it didn't like the media type that Alice was proposing - = if Alice proposes "video", and the IdP only allows "audio", when the IdP re= ceives Alice's INVITE containing "video" it would do the rejecting itself (= in SIP or HTTP). So once again, I don't see how this token would ever lead = to the actual INVITE that carried the token ever being rejected by the conf= erence bridge based on the media types authorized by the token. Jon Peterson Neustar, Inc. --_000_D390592919FF98jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <295266A10B3440469A15E65D5C7BAEFF@neustar.biz> Content-Transfer-Encoding: quoted-printable

The token a= dded to the INVITE is not a policy; it is an authorization by the AuthZ Server to allow th= is request to create a conference focus.

Well, this is the complexity level I was trying to avoid, but, I do ag= ree that what your proposed token carries isn't strictly a conference polic= y - it is instead a policy that constrains conference policies that users a= re allowed to set.

The thing that RFC4353 calls "conference policy" is essentia= lly a policy for a particular instance of a conference. The two attributes = you initially proposed actually constrain conference policies rather than c= onferences - that is, they apply to all conferences that I might try to set policy for, rather than any given conference insta= nce. When I set up a particular conference, for example, I might want it to= be voice only, and to have four seats. That's the policy I want for that c= onference. I gather the attributes you proposed are the constraints that my local administrative domain impos= es on conferences I create, so the conference policy I set for any given po= licy needs to be a subset of those constraints. If my administrative domain= limits me to only three-seat conferences, then when I try to set a conference policy for four seats, that manipulati= on of conference policy would presumably be rejected when it is compared to= my administrative domain's constraints. 

But of course, in the ad hoc corner case you are considering, the conf= erence bridge has no way of anticipating how many users Alice will try to a= dd to the conference - so, her initial INVITE containing the parameter woul= d never be rejected for violating the constraint on conference size, only later INVITEs would be. That attri= bute has nothing to do with authorizing the INVITE carrying the token.

Moreover, how does one actually manipulate my conference policy? Accor= ding to RFC4353, it isn't with SIP. Probably with the web, with an HTTP req= uest. RFC4579 et al do not provide provisions for setting conference policy= . Adding the attributes you proposed to SIP isn't really about setting conference policy, it's about alerting t= he conference service to the constraints on conference policy that are impo= sed by my administrative domain. This is an important distinction, because = it shows how far removed that SIP transaction actually is from the way conference policy is set. Why would I= send a SIP request with the constraints on conference policy if I'm only g= oing to have to use HTTP to actually set conference policy later? Why would= n't my administrative domain have me attach its imposed constraints on conference policy to the actual HTTP = message that is manipulating conference policy?

<snip>


Now, Alice decides to start an audio conference; to do that, the phone obta= ins an access token from the AuthNZ server that allows Alice to start a con= ference of the type =93audio=94.

I did figure you had something like this is mind - perhaps that Alice = would send her INVITE to the IdP first, and that the IdP would then  i= nspect and authorize a conference policy that Alice somehow conveyed via th= e INVITE. Through what field or parameter do you suppose to INVITE will convey that Alice intends for the conference= to be restricted to audio media? Or do you perhaps mean that Alice would u= se HTTP to inform her IdP of the media choices for the conference - in the = which case policy for the conference starts in the HTTP realm, and should certainly stay there.

I imagine that in the corner case of an ad hoc conference, the INVITE = that Alice is sending would contain some session negotiation parameters tha= t could be taken to imply what sorts of media types Alice wants to allow or= forbid in the conference. But I will reiterate that RFC4579 and the related specifications I can think of = off the top of my head do not contain a provision for the INVITE to communi= cate session policy information - and I don't think it is safe to infer fro= m the SDP in an INVITE that Alice intends to limit the conference to the media type(s) it offers.

Moreover, in the ad hoc conference corner case, I see no plausible jus= tification for why the conference bridge would ever reject Alice's initial = INVITE based on the media type it contains. If she's sending her INVITE thr= ough the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't lik= e the media type that Alice was proposing - if Alice proposes "video&q= uot;, and the IdP only allows "audio", when the IdP receives Alic= e's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP). So once again, I don't see how this token would e= ver lead to the actual INVITE that carried the token ever being rejected by= the conference bridge based on the media types authorized by the token.

Jon Peterson
Neustar, Inc.
--_000_D390592919FF98jonpetersonneustarbiz_-- From nobody Thu Jun 23 05:02:49 2016 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 15EF312B011 for ; Thu, 23 Jun 2016 05:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 VkG4WOym6meS for ; Thu, 23 Jun 2016 05:02:45 -0700 (PDT) Received: from UCOL19PA11.eemsg.mail.mil (ucol19pa11.eemsg.mail.mil [214.24.24.84]) by ietfa.amsl.com (Postfix) with ESMTP id DD8DD12D0AD for ; Thu, 23 Jun 2016 04:55:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,509,1459814400"; d="scan'208";a="143483436" Received: from edge-cols03.mail.mil ([131.64.107.100]) by UCOL19PA11.eemsg.mail.mil with ESMTP; 23 Jun 2016 11:55:37 +0000 Received: from UCOLHPQL.easf.csd.disa.mil (131.64.107.38) by edge-cols03.mail.mil (131.64.107.100) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 23 Jun 2016 11:55:37 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.48]) by UCOLHPQL.easf.csd.disa.mil ([131.64.107.38]) with mapi id 14.03.0266.001; Thu, 23 Jun 2016 11:55:37 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAIABEPqg Date: Thu, 23 Jun 2016 11:55:36 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA285F58F@UCOLHU2J.easf.csd.disa.mil> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 12:02:48 -0000 Hi, Jon: "So once again, I don't see how this token would ever lead to the actual IN= VITE that carried the token ever being rejected by the conference bridge ba= sed on the media types authorized by the token." Based on your above conclusion, it appears that there is something missing = the way the SIP conferencing is set up. My guess is that both the conferenc= e initiator (who sent the original INVITE) and conference "focus" should be= autonomous in accepting or rejecting the call if the conferencing paramete= rs are not within the expectation of their respective domains. I would be glad to know what are the criteria that the SIP-based conferenci= ng based on focus standardized so far for accepting or rejecting the call i= f it is not token or it is other parameter including SDP. Your analysis will really be helpful to us. BR/Radhika -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, June 22, 2016 6:29 PM To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 The token added to the INVITE is not a policy; it is an authorization by t= he AuthZ Server to allow this request to create a conference focus. Well, this is the complexity level I was trying to avoid, but, I do agree t= hat what your proposed token carries isn't strictly a conference policy - i= t is instead a policy that constrains conference policies that users are al= lowed to set. The thing that RFC4353 calls "conference policy" is essentially a policy fo= r a particular instance of a conference. The two attributes you initially p= roposed actually constrain conference policies rather than conferences - th= at is, they apply to all conferences that I might try to set policy for, ra= ther than any given conference instance. When I set up a particular confere= nce, for example, I might want it to be voice only, and to have four seats.= That's the policy I want for that conference. I gather the attributes you = proposed are the constraints that my local administrative domain imposes on= conferences I create, so the conference policy I set for any given policy = needs to be a subset of those constraints. If my administrative domain limi= ts me to only three-seat conferences, then when I try to set a conference p= olicy for four seats, that manipulation of conference policy would presumab= ly be rejected when it is compared to my administrative domain's constraint= s.=20 But of course, in the ad hoc corner case you are considering, the conferenc= e bridge has no way of anticipating how many users Alice will try to add to= the conference - so, her initial INVITE containing the parameter would nev= er be rejected for violating the constraint on conference size, only later = INVITEs would be. That attribute has nothing to do with authorizing the INV= ITE carrying the token. Moreover, how does one actually manipulate my conference policy? According = to RFC4353, it isn't with SIP. Probably with the web, with an HTTP request.= RFC4579 et al do not provide provisions for setting conference policy. Add= ing the attributes you proposed to SIP isn't really about setting conferenc= e policy, it's about alerting the conference service to the constraints on = conference policy that are imposed by my administrative domain. This is an = important distinction, because it shows how far removed that SIP transactio= n actually is from the way conference policy is set. Why would I send a SIP= request with the constraints on conference policy if I'm only going to hav= e to use HTTP to actually set conference policy later? Why wouldn't my admi= nistrative domain have me attach its imposed constraints on conference poli= cy to the actual HTTP message that is manipulating conference policy? =09 Now, Alice decides to start an audio conference; to do that, the phone obt= ains an access token from the AuthNZ server that allows Alice to start a co= nference of the type "audio". I did figure you had something like this is mind - perhaps that Alice would= send her INVITE to the IdP first, and that the IdP would then inspect and= authorize a conference policy that Alice somehow conveyed via the INVITE. = Through what field or parameter do you suppose to INVITE will convey that A= lice intends for the conference to be restricted to audio media? Or do you = perhaps mean that Alice would use HTTP to inform her IdP of the media choic= es for the conference - in the which case policy for the conference starts = in the HTTP realm, and should certainly stay there. I imagine that in the corner case of an ad hoc conference, the INVITE that = Alice is sending would contain some session negotiation parameters that cou= ld be taken to imply what sorts of media types Alice wants to allow or forb= id in the conference. But I will reiterate that RFC4579 and the related spe= cifications I can think of off the top of my head do not contain a provisio= n for the INVITE to communicate session policy information - and I don't th= ink it is safe to infer from the SDP in an INVITE that Alice intends to lim= it the conference to the media type(s) it offers. Moreover, in the ad hoc conference corner case, I see no plausible justific= ation for why the conference bridge would ever reject Alice's initial INVIT= E based on the media type it contains. If she's sending her INVITE through = the IdP via SIP, it would never even forward the request, let alone issue a= token for it, if it didn't like the media type that Alice was proposing - = if Alice proposes "video", and the IdP only allows "audio", when the IdP re= ceives Alice's INVITE containing "video" it would do the rejecting itself (= in SIP or HTTP). So once again, I don't see how this token would ever lead = to the actual INVITE that carried the token ever being rejected by the conf= erence bridge based on the media types authorized by the token. Jon Peterson Neustar, Inc. From nobody Thu Jun 23 07:21:10 2016 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 74C9012D122 for ; Thu, 23 Jun 2016 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 70C3c6aWtvNJ for ; Thu, 23 Jun 2016 07:21:06 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 519CE12D0E1 for ; Thu, 23 Jun 2016 07:21:06 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id j2so108180178vkg.2 for ; Thu, 23 Jun 2016 07:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H7hb47hC93rzPOE7OkBjHBAs6QXzGhwkPHH2ivLggXo=; b=FIUEcTmp9Cb2Tf3yyWG0hX0wEd6xfzu6+QL0JzrXKjrtstCCQ8MhdvoZfssMsMGdiu O5X3pjHC9gvHpdd4SSl8mBnRmLIYlsVIIDu3QD9zPhp6WsrhraZtYwrs6pNJeX+vZdVF XLzJtwY8WAGmZWC5mevqpezHagOnYRxYn+BMomW19Yye7ja0DEEhk8VqMU6A3si+Go2w b9zWznxNAHCjf7kC9nNybdNkB4rdfItIpen5hFhxIzSQf33yovAN93ZI+SIyKKmePbIZ 67J8+ZsWJlOH+0O6fe7SHQ+8sVdtn2KC4Vy6C5hrphXMd8C692FhwSIywR9sjLN/W8XM EsFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H7hb47hC93rzPOE7OkBjHBAs6QXzGhwkPHH2ivLggXo=; b=Yr2FZuRu7L20TiDR7ZcSyPkwIRS+NtudZjWiHqx6J4IWDrvZLEr3eq8VOu0N27Qu4j lHHQ6ZX22kpO9zPzyXcjwgpzVlncRwvUez30dlCQXGrdG0SRppWeDtoj90TO2dNZudYR 7rSANevEHyeSulAcSIpj4OXjCJypkbva5mudVtOl6bHA+OQwtrW8WzusOnTggr/j6Fh9 gcGCwoyfrpwpit9Ea8NRH3mBEzvKUdQT9MsGcnn61bGTi8X3hljBYjy9l3jpn3tuLDmz 3eg3CK5GgtwVwgDQPT4M+TMCB/Opp5Jhczf8GrIwJUpVXseC88SQhTDIC0jSsr0agwbm h1dA== X-Gm-Message-State: ALyK8tJLDLSXR+6QLkSDVATKJWN879+2SdfgT5ysIcYBT4fFa8hRWB2REP9wJvcutqdneSNiegnLIkGQrfBIqg== X-Received: by 10.176.1.213 with SMTP id 79mr15619300ual.46.1466691665250; Thu, 23 Jun 2016 07:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 23 Jun 2016 07:21:04 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Thu, 23 Jun 2016 10:21:04 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a113d0a84b3ce390535f2c38f Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:21:09 -0000 --001a113d0a84b3ce390535f2c38f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2016 at 6:29 PM, Peterson, Jon wrote: > > The token added to the INVITE is *not a policy*; it is an authorization > by the AuthZ Server to allow this request to create a conference focus. > > > Well, this is the complexity level I was trying to avoid, but, I do agree > that what your proposed token carries isn't strictly a conference policy = - > it is instead a policy that constrains conference policies that users are > allowed to set. > > The thing that RFC4353 calls "conference policy" is essentially a policy > for a particular instance of a conference. The two attributes you initial= ly > proposed actually constrain conference policies rather than conferences - > that is, they apply to all conferences that I might try to set policy for= , > rather than any given conference instance. When I set up a particular > conference, for example, I might want it to be voice only, and to have fo= ur > seats. That's the policy I want for that conference. I gather the > attributes you proposed are the constraints that my local administrative > domain imposes on conferences I create, so the conference policy I set fo= r > any given policy needs to be a subset of those constraints. If my > administrative domain limits me to only three-seat conferences, then when= I > try to set a conference policy for four seats, that manipulation of > conference policy would presumably be rejected when it is compared to my > administrative domain's constraints. > > But of course, in the ad hoc corner case you are considering, the > conference bridge has no way of anticipating how many users Alice will tr= y > to add to the conference - so, her initial INVITE containing the paramete= r > would never be rejected for violating the constraint on conference size, > only later INVITEs would be. That attribute has nothing to do with > authorizing the INVITE carrying the token. > Let me give you an example from the Web that I use all the time. I use Google Drive to share files with others; to do that I go to specific file/directory that I would like to share and add the email of the person that I would like to share the file with, and get a link to that file/directory. I send that link to the person that owns the email address, which will be able to use his email address and his credentials to get access to the file/directory; the system will prevent anybody else from accessing that file. So, Google Drive has no way of knowing that someone else other than the one that I authorized would try to access the file, but it has a clear understanding of the authorization around this specific file/directory that it enforces for any access attempts that comes after I set the authorization. In that sense, it is similar to this conference use case. Why is this a problem? what is it about the conference server enforcing a specific authorization on later requests that is problematic? > > Moreover, how does one actually manipulate my conference policy? Accordin= g > to RFC4353, it isn't with SIP. Probably with the web, with an HTTP reques= t. > RFC4579 et al do not provide provisions for setting conference policy. > Adding the attributes you proposed to SIP isn't really about setting > conference policy, it's about alerting the conference service to the > constraints on conference policy that are imposed by my administrative > domain. This is an important distinction, because it shows how far remove= d > that SIP transaction actually is from the way conference policy is set. W= hy > would I send a SIP request with the constraints on conference policy if I= 'm > only going to have to use HTTP to actually set conference policy later? > Sorry, but this last sentence is not clear to me. What do you mean by "f I'm only going to have to use HTTP to actually set conference policy later?= " Remember that the conference policy is now managed on the AuthNZ server, not the conference server. > Why wouldn't my administrative domain have me attach its imposed > constraints on conference policy to the actual HTTP message that is > manipulating conference policy? > > > > > Now, Alice decides to start an audio conference; to do that, the phone > obtains an access token from the AuthNZ server that allows Alice to start= a > conference of the type =E2=80=9C*audio=E2=80=9D*. > > > I did figure you had something like this is mind - perhaps that Alice > would send her INVITE to the IdP first, and that the IdP would then > inspect and authorize a conference policy that Alice somehow conveyed vi= a > the INVITE. Through what field or parameter do you suppose to INVITE will > convey that Alice intends for the conference to be restricted to audio > media? Or do you perhaps mean that Alice would use HTTP to inform her IdP > of the media choices for the conference - in the which case policy for th= e > conference starts in the HTTP realm, and should certainly stay there. > No, I am not suggesting to use SIP to communicate with the IdP at all. The idea is to utilize existing mechanisms that know how to do that already. In our OAuth draft, we proposed to use HTTP to communicate with the IdP and SIP to carry the token(s) or code. https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-oauth/ > > I imagine that in the corner case of an ad hoc conference, the INVITE tha= t > Alice is sending would contain some session negotiation parameters that > could be taken to imply what sorts of media types Alice wants to allow or > forbid in the conference. But I will reiterate that RFC4579 and the relat= ed > specifications I can think of off the top of my head do not contain a > provision for the INVITE to communicate session policy information - and = I > don't think it is safe to infer from the SDP in an INVITE that Alice > intends to limit the conference to the media type(s) it offers. > > Moreover, in the ad hoc conference corner case, I see no plausible > justification for why the conference bridge would ever reject Alice's > initial INVITE based on the media type it contains. If she's sending her > INVITE through the IdP via SIP, it would never even forward the request, > let alone issue a token for it, if it didn't like the media type that Ali= ce > was proposing - if Alice proposes "video", and the IdP only allows "audio= ", > when the IdP receives Alice's INVITE containing "video" it would do the > rejecting itself (in SIP or HTTP). > Yes, that is the whole idea; to delegate the authorization part from the conference server; the only thing that the conference will be doing now is enforcing the authorization provided in the token, assuming the token is valid and provided by a trusted entity. > So once again, I don't see how this token would ever lead to the actual > INVITE that carried the token ever being rejected by the conference bridg= e > based on the media types authorized by the token. > So what? why is this a problem? Regards, Rifaat > > Jon Peterson > Neustar, Inc. > --001a113d0a84b3ce390535f2c38f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 6:29 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:

The token a= dded to the INVITE is not a policy; it is an authorization by the AuthZ Server to allow th= is request to create a conference focus.

Well, this is the complexity level I was trying to avoid, but, = I do agree that what your proposed token carries isn't strictly a confe= rence policy - it is instead a policy that constrains conference policies t= hat users are allowed to set.

The thing that RFC4353 calls "conference policy" is essentia= lly a policy for a particular instance of a conference. The two attributes = you initially proposed actually constrain conference policies rather than c= onferences - that is, they apply to all conferences that I might try to set policy for, rather than any given conference insta= nce. When I set up a particular conference, for example, I might want it to= be voice only, and to have four seats. That's the policy I want for th= at conference. I gather the attributes you proposed are the constraints that my local administrative domain impos= es on conferences I create, so the conference policy I set for any given po= licy needs to be a subset of those constraints. If my administrative domain= limits me to only three-seat conferences, then when I try to set a conference policy for four seats, that manipulati= on of conference policy would presumably be rejected when it is compared to= my administrative domain's constraints.=C2=A0

But of course, in the ad hoc corner case you are considering, the conf= erence bridge has no way of anticipating how many users Alice will try to a= dd to the conference - so, her initial INVITE containing the parameter woul= d never be rejected for violating the constraint on conference size, only later INVITEs would be. That attri= bute has nothing to do with authorizing the INVITE carrying the token.

Let me give you an example from the= Web that I use all the time.
I use Google Drive to share fil= es with others; to do that I go to specific file/directory that I would lik= e to share and add the email of the person that I would like to share the f= ile with, and get a link to that file/directory.
I send that link= to the person that owns the email address, which will be able to use his e= mail address and his credentials to get access to the file/directory; the s= ystem will prevent anybody else from accessing that file.

So, Google Drive has no way of knowing that someone else other than= the one that I authorized would try to access the file, but it has a clear= understanding of the authorization around this specific file/directory tha= t it enforces for any access attempts that comes after I set the authorizat= ion.

In that sense, it is similar to this conferen= ce use case.=C2=A0

Why is this a problem? what is = it about the conference server enforcing a specific authorization on later = requests that is problematic?

=C2=A0

Moreover, how does one actually manipulate my conference policy? Accor= ding to RFC4353, it isn't with SIP. Probably with the web, with an HTTP= request. RFC4579 et al do not provide provisions for setting conference po= licy. Adding the attributes you proposed to SIP isn't really about setting conference policy, it's about al= erting the conference service to the constraints on conference policy that = are imposed by my administrative domain. This is an important distinction, = because it shows how far removed that SIP transaction actually is from the way conference policy is set. Why would I= send a SIP request with the constraints on conference policy if I'm on= ly going to have to use HTTP to actually set conference policy later?

Sorry, but this last sentence is no= t clear to me. What do you mean by "f I'm only going to have t= o use HTTP to actually set conference policy later?"
= Remember that the conference policy is now managed on the AuthNZ server, no= t the conference server.

=C2=A0
Why wouldn't my administrative domain = have me attach its imposed constraints on conference policy to the actual HTTP = message that is manipulating conference policy?

<snip>


Now, Alice decides to start an audio conference; to do that, the phone obta= ins an access token from the AuthNZ server that allows Alice to start a con= ference of the type =E2=80=9Caudio=E2=80=9D.

I did figure you had something like this is mind - perhaps that= Alice would send her INVITE to the IdP first, and that the IdP would then = =C2=A0inspect and authorize a conference policy that Alice somehow conveyed= via the INVITE. Through what field or parameter do you suppose to INVITE will convey that Alice intends for the conference= to be restricted to audio media? Or do you perhaps mean that Alice would u= se HTTP to inform her IdP of the media choices for the conference - in the = which case policy for the conference starts in the HTTP realm, and should certainly stay there.

No, I am not suggesting to use SIP to communic= ate with the IdP at all. The idea is to utilize existing mechanisms that kn= ow how to do that already.
In our OAuth draft, we proposed to use= HTTP to communicate with the IdP and SIP to carry the token(s) or code.


I imagine that in the corner case of an ad hoc conference, the INVITE = that Alice is sending would contain some session negotiation parameters tha= t could be taken to imply what sorts of media types Alice wants to allow or= forbid in the conference. But I will reiterate that RFC4579 and the related specifications I can think of = off the top of my head do not contain a provision for the INVITE to communi= cate session policy information - and I don't think it is safe to infer= from the SDP in an INVITE that Alice intends to limit the conference to the media type(s) it offers.

Moreover, in the ad hoc conference corner case, I see no plausible jus= tification for why the conference bridge would ever reject Alice's init= ial INVITE based on the media type it contains. If she's sending her IN= VITE through the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't= like the media type that Alice was proposing - if Alice proposes "vid= eo", and the IdP only allows "audio", when the IdP receives = Alice's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP).



--001a113d0a84b3ce390535f2c38f-- From nobody Thu Jun 23 07:32:32 2016 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 731D712D0A8 for ; Thu, 23 Jun 2016 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 vCzDrsJ3fgn8 for ; Thu, 23 Jun 2016 07:32:27 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 A0AE712B071 for ; Thu, 23 Jun 2016 07:32:27 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j2so108706433vkg.2 for ; Thu, 23 Jun 2016 07:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GzPYrccOgrHyPkadUI+K4Ma7GcCoQhksOiOmPgtLWKE=; b=qO3Mjkybp0OTXmEPccU5TAlC/by7JPHLWaqKO4haEkbT96Uhd2rx6husg2ZXJXsTDZ jFpJWQeSGNK4DnmcOtLYSoIAm8TMlKkSSpT2N2+ik5yynplGDYGq6lJp8uI0MLq/m9Bz LDarXejrKLWAOzqFPwXbDkmErys1Dzn0rtsLCExx70aWHvg+8RV3L5aHt5sinq0RDu2e EzL6DJ2x+c9xDA9cyNlerPAL2MHkGvD3oebSqnJ5H5CrVGxL0+Cy0xm2ImCUxqu4T9/G vMKlyvUMXLsxi4nqtCMPPqzFLB9UDH3A6Z5m2tYGThl4kSEV9b0d44DMz30tSn/ulKRg UDEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GzPYrccOgrHyPkadUI+K4Ma7GcCoQhksOiOmPgtLWKE=; b=ceFOxhdvSIDam2BYseIEsdbkra2FvKgokAaPzu2BWtka1rZD0QZ2BCtfbpTDHXDJLv SC8OeENpxHxfgPoJj3lAfUrC+tZPB8RH0jD+ewWBfbvAUOmJfuddHbga43TiBb2D3TpO mIzGS4f/EdgB0qh/UlnikGjMt7Xih+ZrUeqn+hKe1Cf524qr23utN3QFJ6viaBuRjOeT 5RsL6U0QGycS3aIZWlnHVWuNoe06KctpMbouviXxkvjXdLXENFWlrpvSSptJbhq27N15 zBmbo7fvYHKfnaHQUJKgTvGX291fVpf7LXmLUyTjA3yAGYV1nFhl8RlW+xhRlTmriOqF U4Dw== X-Gm-Message-State: ALyK8tKSAoaSOiXQqnUSFGxAGrXOicpsKnrL/oN/uoOOwBSBfomIIuf9ctgA8J0tUUH4Vmw7BI+aGgxA8y0lzA== X-Received: by 10.159.37.207 with SMTP id 73mr15486779uaf.68.1466692346717; Thu, 23 Jun 2016 07:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 23 Jun 2016 07:32:25 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Thu, 23 Jun 2016 10:32:25 -0400 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113d0632522c920535f2ec3a Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:32:31 -0000 --001a113d0632522c920535f2ec3a Content-Type: text/plain; charset=UTF-8 Roman, We are specifically talking about an RFC4579 based conference use case, just to drive the point and discuss the concept and idea of delegating AuthNZ to other entities. Regards, Rifaat On Wed, Jun 22, 2016 at 5:02 PM, Roman Shpount wrote: > Rifaat, > > In your example, I would expect to issue an HTTP request to create the > conference, get the SIP URI back (with authentication token embedded in the > URI) and place the SIP call to this URI. I do not see a reason why > any standardization effort is required to implement this. > > Regards, > > _____________ > Roman Shpount > > On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shekh-Yusef > wrote: > >> Roman, >> >> I think that the question of how to exactly carry the token in SIP >> request is a minor issue *at this stage*. >> We are discussing the idea and concept of delegating both the AuthN and >> AuthZ to separate server(s) and how to achieve that. >> >> Regards, >> Rifaat >> >> >> On Tue, Jun 21, 2016 at 7:50 PM, Roman Shpount wrote: >> >>> Furthermore, reading all of this, I cannot understand why Authorization >>> token cannot be a part of SIP URL, either as user part or URL parameter. >>> This does not need to be anything more then service specific URL and does >>> not require a new SIP header or authentication mechanism. >>> >>> _____________ >>> Roman Shpount >>> >>> On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon >> > wrote: >>> >>>> >>>> It's not really what I'm looking for, no, and after mulling this over a >>>> bit, I fear going farther along this path would only drill down into levels >>>> of complexity that will likely make this harder to understand rather than >>>> easier. >>>> >>>> I do acknowledge that you describe the INVITE as being rejected if it >>>> doesn't contain a token - but that's not the same thing as saying the >>>> INVITE will be rejected because the relying party makes an authorization >>>> decision based on the attributes in the token. It's more like an INVITE >>>> being rejected because a user agent can't supply an Authorization header. I >>>> will reiterate that I don't think the kinds of attributes you are proposing >>>> should be in the scope of an effort that will try to address a framework >>>> for authorizing SIP requests. I don't think the values of the attributes >>>> (as opposed to the mere presence of some attributes) have anything to do >>>> with authorizing the SIP request that you propose would carry the >>>> attributes. >>>> >>>> With regards to this whole conferencing example, it does seem a bit >>>> contrived to me, like you're sketching a SIP-based way of setting >>>> conference policy on the fly that happens to require the kind of attributes >>>> you want, and then saying that demonstrates the need for the attributes. >>>> The fact that all of the ways to do conference policy we can point to in >>>> fact do it via the web makes it hard for me to understand why we should >>>> create a SIP-based way of doing this. To me, it looks like you're opening a >>>> problem space that has much more to do with reshaping the way that SIP does >>>> conferences (and again, as Radhika's mail pointing out, there's been a lot >>>> of thinking about this since the days of RFC4579) than it does with >>>> defining a framework for authorizing SIP requests. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> From: Rifaat Shekh-Yusef >>>> Date: Thursday, June 16, 2016 at 6:19 AM >>>> To: Jon Peterson >>>> Cc: "sipcore@ietf.org" >>>> Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 >>>> >>>> The attributes I provided are examples of attributes that might be >>>> provided in an access token; it was not meant to include all the attributes >>>> for this use case, because my intention was not to focus on conference >>>> server, but to discuss the idea in general. >>>> >>>> The following could be used with the conference factory to request a >>>> conference focus: >>>> The INVITE sent to the conference factory could include a token that >>>> has a * conference-type* attribute which could take one of the >>>> following values: *audio, video, webconference, audio-webconference, >>>> or video-webconference*. >>>> The conference factory will then issue a *conference uri* for the >>>> requested conference type, assuming the token is valid. If the >>>> *conference-type* attribute is missing, then the request would be >>>> rejected. >>>> >>>> Is that what you are looking for? >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon < >>>> jon.peterson@neustar.biz> wrote: >>>> >>>>> >>>>>> >>>>>> In that case, if you could furnish a use case with attributes that >>>>>> would be carried in a SIP iNVITE that are actually salient to the >>>>>> authorization of that particular SIP request, we'd be getting a lot closer >>>>>> to common ground. >>>>>> >>>>>> >>>>> An obvious example would be an INVITE with a token sent to a >>>>> conference factory to authorize the creation of a focus. >>>>> >>>>> >>>>> We're still talking past each other. My point above was that the two >>>>> attributes you specified - constraints on conference size and media types - >>>>> have nothing to do with the authorization of the INVITE carrying those >>>>> attributes. Like, unless the conference size permitted is 0, then the >>>>> INVITE that creates an ad hoc conference and connects you to its bridge is >>>>> not going to be rejected by the focus on the basis of that conference size >>>>> attribute. If the maximum conference size were 0, the AuthZ service just >>>>> wouldn't attach a token to an INVITE as it would never be allowed to start >>>>> a conference. Same goes for media types. >>>>> >>>>> Instead, what your two attributes constrain is what happens after the >>>>> conference is created: when ten users try to dial in to a conference with a >>>>> permitted size of nine, say. That tenth INVITE would get rejected - not the >>>>> conference-forming INVITE that you propose would carry the token. That's >>>>> why what you're proposing is overloading the INVITE to tunnel conference >>>>> policy constraints to the focus. I mean, maybe that's a problem space worth >>>>> investigating, though I suspect there are good reasons why RFC4353 >>>>> specified that conference policy is not manipulated with SIP - mostly >>>>> because the semantics of manipulating conference policy probably don't map >>>>> well onto dialog-forming SIP requests. But I think that conference policy >>>>> provisioning problem space would be pretty far from where we started in >>>>> this discussion. >>>>> >>>>> Let me reiterate what I wrote in my previous mail, which I quote here >>>>> at the top: "furnish a use case with attributes that would be carried in a >>>>> SIP iNVITE that are actually salient to the authorization of that >>>>> particular SIP request." Again: "that particular SIP request." Not later >>>>> transactions in some broader context in which the original user agent >>>>> probably isn't even an endpoint. >>>>> >>>>> The Authorization header in SIP, for example, is actually used by the >>>>> UAS to make a decision about whether or not to authorize the request in >>>>> which the header appears. The token that you propose a SIP INVITE would >>>>> carry in this case is not used by the relying party to make a decision >>>>> about whether or not that INVITE is authorized. That's why I believe this >>>>> conference policy issue is a different problem space entirely from figuring >>>>> out how to implement attribute-based authorization for SIP requests. >>>>> >>>>> Jon Peterson >>>>> Neustar, Inc. >>>>> >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> >> > --001a113d0632522c920535f2ec3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roman,

We are specifically talking abou= t an RFC4579 based conference use case, just to drive the point and discuss= the concept and idea of delegating AuthNZ to other entities.
Regards,
=C2=A0Rifaat


On Wed, Jun 22, 2016 a= t 5:02 PM, Roman Shpount <roman@telurix.com> wrote:
Rifaat,

In your example, I would expect to issue an HTTP requ= est to create the conference, get the SIP URI back (with authentication tok= en embedded in the URI) and place the SIP call to this URI. I do not see a = reason why any=C2=A0standardization=C2=A0effort is required to implement th= is.

Regards,

____= _________
Roman Shpount

On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shek= h-Yusef <rifaat.ietf@gmail.com> wrote:
Roman,

I think that th= e question of how to exactly carry the token in SIP request is a minor issu= e at this stage.
We are discussing the idea and concep= t of delegating both the AuthN and AuthZ to separate server(s) and how to a= chieve that.

Regards,
=C2=A0Rifaat


On Tue, Jun 21, 2016 at 7:50 PM, Roman Shpount <roman@t= elurix.com> wrote:
Furthermore, reading all of this, I cannot understand why Authoriz= ation token cannot be a part of SIP URL, either as user part or URL paramet= er. This does not need to be anything more then service specific URL and do= es not require a new SIP header or authentication mechanism.

_____________
Roman Shpount

On Tue, Jun 21, 2016 at 7:46 PM, P= eterson, Jon <jon.peterson@neustar.biz> wrote:

It's not really what I'm looking for, no, and after mulling th= is over a bit, I fear going farther along this path would only drill down i= nto levels of complexity that will likely make this harder to understand ra= ther than easier.

I do acknowledge that you describe the INVITE as being rejected if it = doesn't contain a token - but that's not the same thing as saying t= he INVITE will be rejected because the relying party makes an authorization= decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent ca= n't supply an Authorization header. I will reiterate that I don't t= hink the kinds of attributes you are proposing should be in the scope of an= effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attribut= es (as opposed to the mere presence of some attributes) have anything to do= with authorizing the SIP request that you propose would carry the attribut= es.

With regards to this whole conferencing example, it does seem a bit co= ntrived to me, like you're sketching a SIP-based way of setting confere= nce policy on the fly that happens to require the kind of attributes you wa= nt, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conferenc= e policy we can point to in fact do it via the web makes it hard for me to = understand why we should create a SIP-based way of doing this. To me, it lo= oks like you're opening a problem space that has much more to do with reshaping the way that SIP does confer= ences (and again, as Radhika's mail pointing out, there's been a lo= t of thinking about this since the days of RFC4579) than it does with defin= ing a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.


The attributes I provided are examples of attributes that might be pro= vided in an access token; it was not meant to include all the attributes fo= r this use case, because my intention was not to focus on conference server= , but to discuss the idea in general.

The following could be used with the conference factory to request a c= onference focus:
The INVITE sent to the conference factory could include a token that h= as a conference-type attribute which could take one of the following values:= audio, video, webconference, audio-webconference, or video-webconferenc= e.
The conference factory will then issue a conference uri for the= requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be reje= cted.

Is that what you are looking for?

Regards,
=C2=A0Rifaat





On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:
In that case, if you could furnish a use case with attributes that wou= ld be carried in a SIP iNVITE that are actually salient to the authorizatio= n of that particular SIP request, we'd be getting a lot closer to commo= n ground.


An obvious example would be an INVITE with a token sent to a conferenc= e factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the t= wo attributes you specified - constraints on conference size and media type= s - have nothing to do with the authorization of the INVITE carrying those = attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and= connects you to its bridge is not going to be rejected by the focus on the= basis of that conference size attribute. If the maximum conference size we= re 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a confer= ence. Same goes for media types.

Instead, what your two attributes constrain is what happens after the = conference is created: when ten users try to dial in to a conference with a= permitted size of nine, say. That tenth INVITE would get rejected - not th= e conference-forming INVITE that you propose would carry the token. That's why what you're proposin= g is overloading the INVITE to tunnel conference policy constraints to the = focus. I mean, maybe that's a problem space worth investigating, though= I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly beca= use the semantics of manipulating conference policy probably don't map = well onto dialog-forming SIP requests. But I think that conference policy p= rovisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here = at the top: "furnish a use case with attributes that would be carried = in a SIP iNVITE that are actually salient to the authorization of that part= icular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which= the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the = UAS to make a decision about whether or not to authorize the request in whi= ch the header appears.=C2=A0 The token that you propose a SIP INVITE would = carry in this case is not used by the relying party to make a decision about whether or not that INVITE is autho= rized. That's why I believe this conference policy issue is a different= problem space entirely from figuring out how to implement attribute-based = authorization for SIP requests.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore





--001a113d0632522c920535f2ec3a-- From nobody Thu Jun 23 07:40:34 2016 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 320FB12D0DA for ; Thu, 23 Jun 2016 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 GRI_wUrWpYWi for ; Thu, 23 Jun 2016 07:40:31 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 A24F4126B6D for ; Thu, 23 Jun 2016 07:40:31 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g13so66465758ioj.1 for ; Thu, 23 Jun 2016 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NnxU4DkmwI62YTa7JhJw90zT39lJD5r5ISnkJuZwAa8=; b=wLVtXjg59mJkoE9ZIXrPt8scWiJ8AnC4Ap6PyqtnO4uHJ3bU4pRPE85B2GxpfN4GgW TAmK+4Z7wf7CptGCoEBOdl1rdbMlr+5zyzF+jGJyUZhHvH1AWBOt4U7aZ3D0PCdx2SgJ AjE3wzqkE29IbMe51FTvlHTgir0pmttNdwwNsNHadB/XrLHanE5+jXnJIvxqSqxEmAb+ fSUznFKEz1oFQTc+EIeSuVENn3wU6IGAHQD1hi7MhF9lrOQtP5GiX11v4IEaONg48x43 +WOFuxkIRNMjD6sDsjn1/IXr3RNbBuBVeeL+qugWxL+fWeQiLaZ5vheafGW1iX+Jz+OO x5LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NnxU4DkmwI62YTa7JhJw90zT39lJD5r5ISnkJuZwAa8=; b=W5vGIGCp5C6OvZ6DpsVwH0i23u1CS/l0E1K88/1mySlyTYhS7u0u+9q3wZBGhKUE9I 8FJxbjQd+ogyo9n7pJDULYmR9jvPBtAYiI0KF1qjYxTyhT2DOrXpWWUKRMhsCnZojrU4 2+0f0afa9inwoLdgB8DEx3kFUy/vNaA/0eXFX292Ox3C8bwOd4AwLIiExUUHwS+LdWjj No+d7LD4WAFtx2qGyooOvgQoC/m0Qr+jGiWGIajlI1vhh2Mlc8wdiU4dqQrrqmLOLTz8 pkVlDqBZrNP4rkIisF2B8862k+GnRnYshT+J/1YztC+DxjdhlN3PFpf2/9y5QpLxZGY8 RYJQ== X-Gm-Message-State: ALyK8tJeEMavwsEBwqV8bfKqonZkhMrj9v222adNVJLlrKNrBL+czQc3V/jiO/SZrK73zQ== X-Received: by 10.107.140.148 with SMTP id o142mr1366388iod.42.1466692830855; Thu, 23 Jun 2016 07:40:30 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id u67sm456025itd.1.2016.06.23.07.40.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 07:40:30 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id t74so73393434ioi.0 for ; Thu, 23 Jun 2016 07:40:29 -0700 (PDT) X-Received: by 10.107.130.31 with SMTP id e31mr1189665iod.66.1466692829766; Thu, 23 Jun 2016 07:40:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Thu, 23 Jun 2016 07:40:28 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 23 Jun 2016 10:40:28 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=001a113ed0d01ceade0535f309eb Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:40:33 -0000 --001a113ed0d01ceade0535f309eb Content-Type: text/plain; charset=UTF-8 On Thu, Jun 23, 2016 at 10:32 AM, Rifaat Shekh-Yusef wrote: > Roman, > > We are specifically talking about an RFC4579 based conference use case, > just to drive the point and discuss the concept and idea of delegating > AuthNZ to other entities. > > I think it is more like we are discussing spherical elephants in vacuum. I am not aware of anybody using RFC4579 based conference in such a manner or ever needing to so. Is there a practical application for this framework? _____________ Roman Shpount --001a113ed0d01ceade0535f309eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2016 at 10:32 AM, R= ifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Roman,

We are specifically t= alking about an RFC4579 based conference use case, just to drive the point = and discuss the concept and idea of delegating AuthNZ to other entities.


I think it is more= like we are discussing spherical elephants in vacuum. I am not aware of an= ybody using=C2=A0=C2=A0RFC4579 based conference in such a manner or ever ne= eding to so.

Is there a practical application for = this framework?
_____________
Roman Shpount
=C2=A0
--001a113ed0d01ceade0535f309eb-- From nobody Thu Jun 23 10:35:46 2016 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 02C8A12D0EC for ; Thu, 23 Jun 2016 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 HMmWiD3FLJWe for ; Thu, 23 Jun 2016 10:35:44 -0700 (PDT) Received: from ukel19pa20.eemsg.mail.mil (ukel19pa20.eemsg.mail.mil [214.24.22.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7970612D08E for ; Thu, 23 Jun 2016 10:35:42 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.100]) by ukel19pa20.eemsg.mail.mil with ESMTP; 23 Jun 2016 17:35:42 +0000 Received: from UCOLHPQM.easf.csd.disa.mil (131.64.107.39) by edge-cols03.mail.mil (131.64.107.100) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 23 Jun 2016 17:35:41 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.48]) by UCOLHPQM.easf.csd.disa.mil ([131.64.107.39]) with mapi id 14.03.0266.001; Thu, 23 Jun 2016 17:35:41 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: Roman Shpount , Rifaat Shekh-Yusef Thread-Topic: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAFfM4CAAEFuAIABZsMAgABovQCADCSir4AAAi4AgAAvFFA= Date: Thu, 23 Jun 2016 17:35:41 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA285F68D@UCOLHU2J.easf.csd.disa.mil> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 17:35:46 -0000 SW5saW5lIFtSUlJdDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3Jl IFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hw b3VudA0KU2VudDogVGh1cnNkYXksIEp1bmUgMjMsIDIwMTYgMTA6NDAgQU0NClRvOiBSaWZhYXQg U2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBzaXBjb3JlQGlldGYub3Jn DQpTdWJqZWN0OiBbTm9uLURvRCBTb3VyY2VdIFJlOiBbc2lwY29yZV0gU0lQIEF1dGhOWiBQcm9i bGVtIFN0YXRlbWVudCAtIHYzDQoNCkFsbCBhY3RpdmUgbGlua3MgY29udGFpbmVkIGluIHRoaXMg ZW1haWwgd2VyZSBkaXNhYmxlZC4gUGxlYXNlIHZlcmlmeSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNl bmRlciwgYW5kIGNvbmZpcm0gdGhlIGF1dGhlbnRpY2l0eSBvZiBhbGwgbGlua3MgY29udGFpbmVk IHdpdGhpbiB0aGUgbWVzc2FnZSBwcmlvciB0byBjb3B5aW5nIGFuZCBwYXN0aW5nIHRoZSBhZGRy ZXNzIHRvIGEgV2ViIGJyb3dzZXIuIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCg0KDQpPbiBUaHUsIEp1biAyMywgMjAxNiBhdCAxMDozMiBBTSwgUmlmYWF0IFNoZWto LVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20gPCBDYXV0aW9uLW1haWx0bzpyaWZhYXQuaWV0 ZkBnbWFpbC5jb20gPiA+IHdyb3RlOg0KDQoNCglSb21hbiwNCg0KCVdlIGFyZSBzcGVjaWZpY2Fs bHkgdGFsa2luZyBhYm91dCBhbiBSRkM0NTc5IGJhc2VkIGNvbmZlcmVuY2UgdXNlIGNhc2UsIGp1 c3QgdG8gZHJpdmUgdGhlIHBvaW50IGFuZCBkaXNjdXNzIHRoZSBjb25jZXB0IGFuZCBpZGVhIG9m IGRlbGVnYXRpbmcgQXV0aE5aIHRvIG90aGVyIGVudGl0aWVzLg0KDQoNCg0KSSB0aGluayBpdCBp cyBtb3JlIGxpa2Ugd2UgYXJlIGRpc2N1c3Npbmcgc3BoZXJpY2FsIGVsZXBoYW50cyBpbiB2YWN1 dW0uIEkgYW0gbm90IGF3YXJlIG9mIGFueWJvZHkgdXNpbmcgIFJGQzQ1NzkgYmFzZWQgY29uZmVy ZW5jZSBpbiBzdWNoIGEgbWFubmVyIG9yIGV2ZXIgbmVlZGluZyB0byBzby4NCg0KSXMgdGhlcmUg YSBwcmFjdGljYWwgYXBwbGljYXRpb24gZm9yIHRoaXMgZnJhbWV3b3JrPw0KDQpbUlJSXSBTSVAt YmFzZWQgY2VudHJhbGl6ZWQgY29uZmVyZW5jaW5nIGlzIGJlaW5nIHVzZWQgaW4gcHJvcHJpZXRh cnkgd2F5cyBmb2xsb3dpbmcgdGhlc2Uga2luZHMgb2YgZnJhbWV3b3JrIChSRkM0NTc5IClhbmQg M3JkIHBhcnR5IGNhbGwgY29udHJvbCBSRkNzIGZpbGxpbmcgbWFueSBibGFjayBob2xlcyB0aGF0 IHRoZXNlIFJGQ3MgZG8gbm90IGFuc3dlciBpbmNsdWRpbmcgc2VjdXJpdHkuDQoNCltSUlJdIElu ZHVzdHJ5IGRpZCBub3QgZ2V0IGVub3VnaCBndWlkYW5jZSBmcm9tIElFVEYgUkZDcyBmb3IgbXVs dGlwYXJ0eSBtdWx0aW1lZGlhIGNvbmZlcmVuY2luZy4NCg0KW1JSUl0gVGhpcyBzZWN1cml0eSBk aXNjdXNzaW9uIGlzIG9uZSBvZiB0aGUgbWluaS12aXZpZCBleGFtcGxlcy4gDQpfX19fX19fX19f X19fDQpSb21hbiBTaHBvdW50DQogDQo= From nobody Thu Jun 23 12:04:35 2016 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 2616A12D69E for ; Thu, 23 Jun 2016 12:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 f4GjTtQx7gyc for ; Thu, 23 Jun 2016 12:04:32 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 C7ADE12D623 for ; Thu, 23 Jun 2016 12:04:32 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with SMTP id G9vUbHcFxBAXOG9vUbJjwY; Thu, 23 Jun 2016 19:04:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466708672; bh=75+6498MOhJUNqC/uDQPpaWAxV9m4/KYvISyonlA/uU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=PdfbhW9dCwYEzTh82pQCXqMsxZ6LLmldNnZGGFwb9c+zwL8w6gwg0307vDNpuxYny SxtYOpWKaUGAU2eu6Pg4vQIoFbRwRW+59Cx9qMxuyyvk6gkw6mheoaESwoabP8u60K ckQ8F3bdSt4qakXcNXG3ifoExmrXhdw8iMM5i1+Tj7b1uqJ1m1grDA2ykJtUfi44K9 i4L1w+MHD6pB0WLNNYSn53J08i2vDSgfar17DY8CsJVmmCx98JBKRHo28Fk45VTYHG 48TGTB6PaU4SkCdNMvQkmq/saLjl8RjUsC/+V2N1oDGtOewSsIkltIgtBMOdmPZmER sxX0Z+blM6zmQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-14v.sys.comcast.net with comcast id AK4X1t00A1nMCLR01K4Xuy; Thu, 23 Jun 2016 19:04:32 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5NJ4UmQ014632; Thu, 23 Jun 2016 15:04:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5NJ4URg014628; Thu, 23 Jun 2016 15:04:30 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Ben Campbell" In-Reply-To: (ben@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Jun 2016 15:04:30 -0400 Message-ID: <87fus3loap.fsf@hobgoblin.ariadne.com> Archived-At: Cc: draft-ietf-sipcore-dns-dual-stack.all@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-dns-dual-stack-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 19:04:34 -0000 "Ben Campbell" writes: > -1, 2nd paragraph, first sentence: > > That sentence is a bit hard to parse, please consider breaking into two > or more simpler sentences. Broken into two sentences. Yes, the joining of the two major clauses of that sentence wasn't done quite correctly. > -2, definition of IPv4/IPv6 UA/UAC/UAS: > > This defines one term, then declares the draft will use another. Why not > just define _that_ term in the first place? Done. > -4: > > This section kind of buries the lede, and leaves me wondering what the > actual clarification was. Is the point to say not to interleave the > results of the address record queries among srv records? Is there a > concern that people thought they were to do something different? It > would be helpful to say what misconception you intend to clarify. I've revised the first paragraph; it now states a MUST for the important point and a MUST NOT for what we have been fearing people might do. > -5, first paragraph, last sentence: > > Oddly constructed sentence. The structure seems to imply a tension > between the idea of optimizing performance and not introducing security > considerations. Please consider something to the effect of the > following: > > "Both of these procedures are optimization designed to improve the > performance of dual-stack clients. Neither introduce new security > considerations." I've reorganized the paragraph. And now it states the presupposition that underlies the conclusion that no new security considerations are introduced: It's assumed that any address that can be derived from a URI might be contacted to send a message to that URI. E.g., security does not depend on SRV priority always being followed. Dale From nobody Thu Jun 23 12:47:29 2016 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 0073B12D786; Thu, 23 Jun 2016 12:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 C1uxPlXQYy03; Thu, 23 Jun 2016 12:47:25 -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 CF75B12D667; Thu, 23 Jun 2016 12:47:25 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5NJlIl5010521 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2016 14:47:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Dale R. Worley" Date: Thu, 23 Jun 2016 14:47:18 -0500 Message-ID: In-Reply-To: <87fus3loap.fsf@hobgoblin.ariadne.com> References: <87fus3loap.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-sipcore-dns-dual-stack.all@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-dns-dual-stack-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 19:47:28 -0000 It all sounds good (pending actual text). Thanks! Ben. On 23 Jun 2016, at 14:04, Dale R. Worley wrote: > "Ben Campbell" writes: >> -1, 2nd paragraph, first sentence: >> >> That sentence is a bit hard to parse, please consider breaking into two >> or more simpler sentences. > > Broken into two sentences. Yes, the joining of the two major clauses of > that sentence wasn't done quite correctly. > >> -2, definition of IPv4/IPv6 UA/UAC/UAS: >> >> This defines one term, then declares the draft will use another. Why not >> just define _that_ term in the first place? > > Done. > >> -4: >> >> This section kind of buries the lede, and leaves me wondering what the >> actual clarification was. Is the point to say not to interleave the >> results of the address record queries among srv records? Is there a >> concern that people thought they were to do something different? It >> would be helpful to say what misconception you intend to clarify. > > I've revised the first paragraph; it now states a MUST for the important > point and a MUST NOT for what we have been fearing people might do. > >> -5, first paragraph, last sentence: >> >> Oddly constructed sentence. The structure seems to imply a tension >> between the idea of optimizing performance and not introducing security >> considerations. Please consider something to the effect of the >> following: >> >> "Both of these procedures are optimization designed to improve the >> performance of dual-stack clients. Neither introduce new security >> considerations." > > I've reorganized the paragraph. And now it states the presupposition > that underlies the conclusion that no new security considerations are > introduced: It's assumed that any address that can be derived from a > URI might be contacted to send a message to that URI. E.g., security > does not depend on SRV priority always being followed. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jun 23 19:20:42 2016 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 DBB7512D935 for ; Thu, 23 Jun 2016 19:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 llo3iILoLKky for ; Thu, 23 Jun 2016 19:20:39 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 338D812D933 for ; Thu, 23 Jun 2016 19:20:38 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with SMTP id GGiwbtmxx8JCNGGjVbpT6H; Fri, 24 Jun 2016 02:20:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466734837; bh=Y7VymcToYV6yIwQTcDqRui0eEmSo0UU0EibYHosmhCY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=UfLBIR5NeUthgYpUm75wUp5OBKAiwEV9TYrGgrsOhVW7YxCCgPw9SnOOKns60fRo3 fgR01gohzZK7Fy8Y8KaLmE/wSbmo1YQPD6NdQvSb045yuL44pYDXJsu6bsAdL1vlgF myz0LtlIdCZPT4iFek4pAN4Db2Ipfr2tY7dOmk4X0XPfI+BisOhJF6Jp8fo2monzk8 uANuQaEN6VjRuvfQvcg5zjVG8kGGG47zY9E/Ade8lNojZ96khv+j7eE3I0iZK8yDem 6o//PIy75L+luz3RHevkFtMfjsCaZkfwDzx0mGPqi+9j70kb/bA55852z2htikLf+i c8rECCZciicuw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id ASLc1t00d1nMCLR01SLd9e; Fri, 24 Jun 2016 02:20:37 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5O2KalE020833 for ; Thu, 23 Jun 2016 22:20:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5O2KaSE020830; Thu, 23 Jun 2016 22:20:36 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Jun 2016 22:20:36 -0400 Message-ID: <87wplfjpjf.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 02:20:41 -0000 This thread is about solutions for this part of the requirements: - Solve the "happy eyeballs" problem for INVITE, i.e., if a destination URI is advertised with both multiple targets (IPv4 and IPv6 or otherwise), but connectivity to only one target exists, usually message transmission will not be delayed unacceptably, and in particular, not by a full timeout as prescribed in 3261. Note that the solution may be decidedly different based on the transport protocol(s) for the targets. There is uncertainty about whether adding an RTT to signaling times is acceptable. For example, in practice RTT on the overall Internet is less than 1/2 second, and that is an acceptable delay in call setup times under ordinary circumstances. - The solution must approximate 3263, in that if several targets are specified by *different* SRV records and are reachable over a long period of time, the relative traffic shares sent to them must be compatible with the priorities and weights of the SRV records. (If they are alternatives that are *not* derived from different SRV records, the solution is unconstrained regarding relative traffic shares.) Comments are invited! Useful definitions: a "client" is the entity that wishes to send a SIP message a "target" or "transport target" is an address/port/protocol triple that is an address for the transport layer of the stack. A target is derived from a SIP URI (for a request) or a host-port (for a response). a "flow" is a sequence of related messages between the client and a target. If the protocol is connection-oriented, the flow encompasses the connection. If the protocol requires cryptographic setup, the flow encompasses the cryptographic session. a "probe" is an operation executed on a flow by a client to determine whether it can successfully communicate with the target, without changing the SIP dialog state with the target. Probes can take many forms: Setting up a connection of a connection-oriented protocol. Performing a cryptographic handshake. Performing a keep-alive as defined by the protocol. Sending an OPTIONS request with Max-Forwards 0. Note that the last choice can be used with any(!) protocol. If the OPTIONS reaches the target, the target is required to respond with either a 200 or 483 response (without forwarding it to another entity). Conveniently, a server can respond to such a request statelessly, so such requests are low-overhead. The current state of the solution (as I know of it) is: Note that some SIP messages are time-sensitive for the usesr experience (e.g., initial INVITEs), while others are not (e.g., a refreshing REGISTER). A client MAY choose not to apply the following rules for non-time-sensitive messages. Devices MAY change the target order prescribed by RFC 3263/2782. The device SHOULD follow the Happy Eyeballs rules, viz.: - Prefer targets with existing flows - Prefer targets with a different address family than that of a non-responsive address - Deprecate targets known to be non-responsive - May simultaneously initiate flows with multiple targets as long as UA does not have more than one simultaneous outstanding copy of a request - Prefer simultaneously initiating flows with targets in different address families Devices MAY contact targets in any order, including those obtained via different SRV records, notwithstanding the priority/weight specified in the SRV records. But in doing this, they MUST approximate the behavior specified by RFC 3263, in this sense: If a set of targets is all of the targets derived from two or more SRV records, and at least one target for each SRV record is reachable by the client over a long period of time, the relative shares of traffic sent to each subset of targets derived from one SRV record must converge to the traffic shares that would result if the client contacted these targets in the order specified by RFC 3263 (i.e., according to the priorities and weights of the SRV records). (Note that the relative traffic shares between targets that are *not* derived from different SRV records (e.g., alternative A records for a DNS name) are not constrained by this requirement.) In general, this means that cached reachability information about targets should time out, causing the behavior of the client to revert to RFC 3263 over time. (Beware that we have to define "reachable" above to include responsiveness -- a high-priority target that has a 5 sec RTT shouldn't be able to commandeer all of the traffic.) If a client does not have recent reachability information for the flow to a given target, the client SHOULD probe the flow before sending a request to the target. This is because in the worst case, sending a request commits the client to waiting for a timeout before it can send a duplicate request to another target. Note that probes do not change the SIP dialog state of any entity, so probes can be sent in parallel to multiple targets. Reduce client transaction timeouts: Timer B and Timer F are currently 64*T1, which defaults to 32 seconds It seems that reducing the default T1 from 500 msec to 100 msec suffices for this. It seems that RTT to arbitrary places on the Internet can take as long as 500 msec, but RTT to web servers generally takes 100 msec or less. That argues for reducing T1 to 100 msec, which makes timers B/F 6.4 sec. In practice, SIP servers are likely to have connectivity like web servers. But we want global public SIP to work (e.g., in peer-to-peer SIP), so SIP to arbitrary addresses should only rarely time out. The retransmission schedule specified by RFC 3261 is: 1st send is at time 0 2nd send is at time T1 3rd send is at time 3*T1 4th send is at time 7*T1 5th send is at time 15*T1 6th send is at time 31*T1 7th send is at time 63*T1 timer B fires at time 64*T1, terminating the transmission This is just long enough to allow 7 transmissions of the message. If we reduce T1 to 100 msec (from 500 msec), the total length of the schedule is reduced to 6.4 sec, which seems tolerable as a fail-over delay. It still alllows 7 retransmissions. Dale From nobody Thu Jun 23 21:11:11 2016 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 71B4F12D95C for ; Thu, 23 Jun 2016 21:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 THrpLxNbeR0h for ; Thu, 23 Jun 2016 21:11:08 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 7070C12D896 for ; Thu, 23 Jun 2016 21:11:08 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id t74so90060150ioi.0 for ; Thu, 23 Jun 2016 21:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NHhGVQBAfrvBqNJR7SNBf/PejM/4X9Driw0aG3J0CT8=; b=V75OQv4hrCl/xgDPb8mc73vP9fkAUGZ3+YOBxwiln2tEqgi3vQowfV7x/kjL4JBBAt SYbTk6WP/PCoxTHlr2xJ9EcLqf0uVpxaom/D7N/nMenbExRlCkZJz+hDlo6pMGVfF+Jb S2c50UowTAm80bnM2FxY+rV7Np+YH3CdgBTvSA7fEyE8kzc8Y/7Y1QrkFn87uePW0hEB jcjnutihzK3eoVtO1sGiBiUNJUw+CkrgWfpnC6yzMOPs9KTIR0+XXMz1TaFSodzkplk7 qA9laY94effVqOQEAhj0aYErT9qqJu71mloxYNLnSwB1s2IeaihYcB2JDQL2ZhciQC0E +pUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NHhGVQBAfrvBqNJR7SNBf/PejM/4X9Driw0aG3J0CT8=; b=SxzzcZk+jIfBUF8XJczOlw7WuDGuQ1Uy2v4MzYrhxgyWabVTg05p+PzYJJZhe1rc7Z F3U1Fb05Sx6ScdqaD52RK9DOEZ4qdS6c79XhYdSmjTnQGGsYW6zKrEVtMiykODtZa8FQ RWaD5m9ICnAIeWh1hK44aoY/MSCUQ6Z3Ut6nbhxbNylW8g8IZj6hsFArOfpT8G4i9PYi lQ37D1Nv3/BzQrKeDzH9n2D8FLv9uMeOun6yUL3otymvrVhUxrqfpjxNbyJFYph4vjQA a19gkzdiyNHJ8H0gUtIjTn6Cz90k4YJPblTLy3a9b2FJkrs4kMOrQx2n87LXHpYieBei IUVA== X-Gm-Message-State: ALyK8tLz4j2TsYBZUBmGZYzVA1CZ36xxQG6F8Cb82TumiR7GZLSqTAknwlMITsmKemMl6Q== X-Received: by 10.107.15.31 with SMTP id x31mr4004543ioi.57.1466741467725; Thu, 23 Jun 2016 21:11:07 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id g98sm1990616ioj.11.2016.06.23.21.11.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 21:11:06 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id g13so82961812ioj.1 for ; Thu, 23 Jun 2016 21:11:06 -0700 (PDT) X-Received: by 10.107.130.31 with SMTP id e31mr3906963iod.66.1466741466500; Thu, 23 Jun 2016 21:11:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Thu, 23 Jun 2016 21:11:06 -0700 (PDT) In-Reply-To: <87wplfjpjf.fsf@hobgoblin.ariadne.com> References: <87wplfjpjf.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Fri, 24 Jun 2016 00:11:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113ed0d01698480535fe5c41 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 04:11:10 -0000 --001a113ed0d01698480535fe5c41 Content-Type: text/plain; charset=UTF-8 Dale, One more mechanism for checking a UDP flows is STUN keep-alive message described in https://tools.ietf.org/html/rfc5626#section-3.5.2. These messages are even lower overhead then OPTIONS messages. Regards, _____________ Roman Shpount --001a113ed0d01698480535fe5c41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dale,

One more mechanism for checking= a UDP flows is STUN keep-alive message described in=C2=A0https://tools.ietf.org/html/rf= c5626#section-3.5.2. These messages are even lower overhead then OPTION= S messages.

Regards,
_____________
Roman Shpount

--001a113ed0d01698480535fe5c41-- From nobody Fri Jun 24 09:04:56 2016 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 A722B12DCBF; Fri, 24 Jun 2016 09:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160050.10933.44043.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:50 -0700 Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org Subject: [sipcore] sipcore - Requested session has been scheduled for IETF 96 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:51 -0000 Dear Adam Roach, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sipcore Session 1 (1:00:00) Wednesday, Afternoon Session II 1550-1720 Room Name: Charlottenburg I size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: netvc xrblock webpush stir mmusic rtcweb avtext perc avtcore dispatch Special Requests: Cannot conflict with interledger bof. --------------------------------------------------------- From nobody Fri Jun 24 09:53:13 2016 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 1327D12D0FD for ; Fri, 24 Jun 2016 09:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=broadsoft-com.20150623.gappssmtp.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 6YGU2t3lsePg for ; Fri, 24 Jun 2016 09:53:09 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 F412C12D0F1 for ; Fri, 24 Jun 2016 09:52:57 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id c73so153058050qkg.2 for ; Fri, 24 Jun 2016 09:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=sF7BvjTUQL0+IcYt2MvaTC7z317+dULYwjPcQLXHdBM=; b=F6Pm+4yELyo3kgNhAbEC5R5Q9Jz81H03grTHHiCRJ06zNSitH0rPOtd7n1lM/Jozih op1IbRkeVwCI6C/AC3egSsDd77qBVC+x/dxSMehuTnjgRMX3h5WEquReUMip5bnZxIEz DJP8Zla5Dwm5y3qzypR5seCxfda5wR6XYKmN36kgorFQv2u3DZ8Ib9Y4MO49tREUkEPH fdIaXe0lPVbon2LV6nSkgGQ7wrn+QztfEhjceMMbuR12GBgJFao+x2Lnlzp9WxwQDC0r MADb+9KzuHAzd2mDCImkBtfR0JpWGn7FAMOXPEzgENp7I7s8oTMMfsZ/jSTbxyPvqLhX VX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=sF7BvjTUQL0+IcYt2MvaTC7z317+dULYwjPcQLXHdBM=; b=bOznHxbPSsIzVGpfee7AHWfWuGrCPMQng89S8SupAMd4Fx/XKwHFeXErD5RvK8h2Bd +drxI4aJjc5Qeq2ED2JfeRaMAkRhmsZ4W4BoNncLE2DPaIy4T9lmGQRi5SklivujelUK vkbgD5+sJ6TGTvHF/WmohUdo5vjkBEOfgx/lrdPbem7dTQviuLlrgcPQbxLL23tPrUiS Vy54krdV41f2by6to8begX0bjdjah4jSNvah9iAQTATlIWq6OfkEQltetbXZvqqUjQY4 92OQRsyJoYp4noNmjUtUQMOXibBD9Bj8dBBxeq1eycG9GQywVY0CAJliFe4hd+vQdpPN XTmA== X-Gm-Message-State: ALyK8tIq9p82XMguHUb12vF85F8pSBVYvUE3mQMITS8ouBBGIaWmRalKoWsU3jEGlWqVU7HF3rlHBhTvjKPpzKEv X-Received: by 10.237.47.228 with SMTP id m91mr5705117qtd.35.1466787177116; Fri, 24 Jun 2016 09:52:57 -0700 (PDT) From: Brett Tate References: <87wplfjpjf.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wplfjpjf.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKxedEm1IoLtYGBnC9QH72FoCQDu545Za8Q Date: Fri, 24 Jun 2016 12:52:56 -0400 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:53:11 -0000 Hi, > Reduce client transaction timeouts: > Timer B and Timer F are currently 64*T1, which defaults to 32 seconds > > It seems that reducing the default T1 from 500 msec to 100 msec > suffices for this. The issue with using a smaller T1 value is that it doesn't just impact the desired timer. For instance, it can cause more retries. Because of this, the draft might want to specify allowing the specific smaller timers in a way which doesn't rely upon a smaller T1. If it matters, RFC 3261 section 17.1.1.2 has normative statements concerning the topic of lowing T1. Thanks, Brett From nobody Fri Jun 24 11:32:51 2016 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 E704912D1C1 for ; Fri, 24 Jun 2016 11:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable 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 p1fvwA5tQWkG for ; Fri, 24 Jun 2016 11:32:49 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 C42AE12D50C for ; Fri, 24 Jun 2016 11:27:12 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5OINpmv021505; Fri, 24 Jun 2016 14:27:12 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23r5ga94df-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Jun 2016 14:27:11 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Fri, 24 Jun 2016 14:27:10 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAIABf0UAgAFhuIA= Date: Fri, 24 Jun 2016 18:27:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.218] Content-Type: multipart/alternative; boundary="_000_D392BAC11A0530jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-24_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606240197 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:32:51 -0000 --_000_D392BAC11A0530jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moreover, in the ad hoc conference corner case, I see no plausible justific= ation for why the conference bridge would ever reject Alice's initial INVIT= E based on the media type it contains. If she's sending her INVITE through = the IdP via SIP, it would never even forward the request, let alone issue a= token for it, if it didn't like the media type that Alice was proposing - = if Alice proposes "video", and the IdP only allows "audio", when the IdP re= ceives Alice's INVITE containing "video" it would do the rejecting itself (= in SIP or HTTP). Yes, that is the whole idea; to delegate the authorization part from the co= nference server; the only thing that the conference will be doing now is en= forcing the authorization provided in the token, assuming the token is vali= d and provided by a trusted entity. ... um, I would have thought this totally undermined your argument. If the = IdP simply prevents the INVITE from ever being sent to the conference bridg= e when the proposed media type is unacceptable to the IdP, then there's no = need to carry attribute to the conference bridge at all. If the IdP doesn't= like the media type, the conference bridge will never see the INVITE; and = if the conference bridge sees the INVITE, then the IdP must have liked the = media type. Attribute adds nothing. This is a consequence of architecting an administrative domain in a draconi= an way that lets intermediaries prevent user agents from sending SIP messag= es where they like, of course. But even if we assume a more open environmen= t where the user agent can send INVITEs directly to the conference bridge, = all the conference bridge needs is a signature or similar token that indica= tes the IdP's approval, -not- any specific attribute. So once again, I don't see how this token would ever lead to the actual INV= ITE that carried the token ever being rejected by the conference bridge bas= ed on the media types authorized by the token. So what? why is this a problem? It's a problem because you're proposing to take a feature (OAuth) that exis= ts in HTTP and to add it to SIP. To make an argument for that, you at leas= t must establish that SIP needs this feature - and preferably you need to e= stablish that making this protocol change and performing these operations i= n SIP is less work (in the grand scheme of implementation and deployment ov= erall) than saying that if you want to perform operations like this you sho= uld instead just use HTTP. (Which you can, and for these conference cases, = you surely should.) What I postulated way back at the beginning of this thread is that the kind= of applications that benefit from attribute-based authorization tend to be= controlled by the web rather than by SIP, and that this is why, although w= e've been studying this problem space for more than a decade, we never stan= dardized an attribute-based authorization protocol for SIP. This entire con= ferencing example has been about manipulating conference policy and managin= g constraints on conference policy, which may be a problem space with unsol= ved issues (honestly, I'm not much of an expert on the current thinking abo= ut conferencing) but I don't think it's the SIP authorization problem space= . The semantics of the INVITE method are "hey, remote resource, I'd like to s= et up a session with you involving the following media types." The question= of whether or not you accept INVITEs, which is to my mind the SIP authoriz= ation problem, is mainly about figuring out why you would say yes or no to = that question. What you are proposing here is a conference policy constrain= t token that lets the IdP piggyback information on the INVITE to be sent to= the conference bring. We've struggled here to even identify how that infor= mation would alter to the decision about whether or not to accept the INVIT= E. If we need to standardize a protocol mechanism for that function, I have= a hard time seeing why SIP would be our first choice, and then why an INVI= TE setting up a session would be the right choice, versus just doing this w= ith a protocol interaction that has a semantics other than "I'd like to set= up a session with you." I'd note that your Google drive example is also a pretty poor fit for these= semantics. But these are the primary semantics of SIP. If the thing you wa= nt to do has different semantics, there's probably a way to do with a diffe= rent protocol. Albeit, that doesn't mean there isn't an authorization probl= em for SIP worth identifying and considering. Jon Peterson Neustar, Inc. Regards, Rifaat --_000_D392BAC11A0530jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <14E34135CD317746A75ED5FE2127B889@neustar.biz> Content-Transfer-Encoding: quoted-printable


Moreover, in the ad hoc conference corner case, I see no plausible jus= tification for why the conference bridge would ever reject Alice's initial = INVITE based on the media type it contains. If she's sending her INVITE thr= ough the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't lik= e the media type that Alice was proposing - if Alice proposes "video&q= uot;, and the IdP only allows "audio", when the IdP receives Alic= e's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP).

Yes, that is the whole idea; to delegate the authorization part from t= he conference server; the only thing that the conference will be doing now = is enforcing the authorization provided in the token, assuming the token is= valid and provided by a trusted entity.

... um, I would have thought this totally undermined your argument. If= the IdP simply prevents the INVITE from ever being sent to the conference = bridge when the proposed media type is unacceptable to the IdP, then there'= s no need to carry attribute to the conference bridge at all. If the IdP doesn't like the media type, the = conference bridge will never see the INVITE; and if the conference bridge s= ees the INVITE, then the IdP must have liked the media type. Attribute adds= nothing.

This is a consequence of architecting an administrative domain in a dr= aconian way that lets intermediaries prevent user agents from sending SIP m= essages where they like, of course. But even if we assume a more open envir= onment where the user agent can send INVITEs directly to the conference bridge, all the conference bridge = needs is a signature or similar token that indicates the IdP's approval, -n= ot- any specific attribute.

 
So once again, I don't see how this token would ever lead to the actua= l INVITE that carried the token ever being rejected by the conference bridg= e based on the media types authorized by the token.

So what? why is this a problem?

It's a problem because you're proposing to take a feature (OAuth) that= exists in HTTP and to add it to SIP.  To make an argument for that, y= ou at least must establish that SIP needs this feature - and preferably you= need to establish that making this protocol change and performing these operations in SIP is less work (in the grand s= cheme of implementation and deployment overall) than saying that if you wan= t to perform operations like this you should instead just use HTTP. (Which = you can, and for these conference cases, you surely should.)

What I postulated way back at the beginning of this thread is that the= kind of applications that benefit from attribute-based authorization tend = to be controlled by the web rather than by SIP, and that this is why, altho= ugh we've been studying this problem space for more than a decade, we never standardized an attribute-based aut= horization protocol for SIP. This entire conferencing example has been abou= t manipulating conference policy and managing constraints on conference pol= icy, which may be a problem space with unsolved issues (honestly, I'm not much of an expert on the current t= hinking about conferencing) but I don't think it's the SIP authorization pr= oblem space.

The semantics of the INVITE method are "hey, remote resource, I'd= like to set up a session with you involving the following media types.&quo= t; The question of whether or not you accept INVITEs, which is to my mind t= he SIP authorization problem, is mainly about figuring out why you would say yes or no to that question. What you are pr= oposing here is a conference policy constraint token that lets the IdP pigg= yback information on the INVITE to be sent to the conference bring. We've s= truggled here to even identify how that information would alter to the decision about whether or not to accep= t the INVITE. If we need to standardize a protocol mechanism for that funct= ion, I have a hard time seeing why SIP would be our first choice, and then = why an INVITE setting up a session would be the right choice, versus just doing this with a protocol interact= ion that has a semantics other than "I'd like to set up a session with= you."

I'd note that your Google drive example is also a pretty poor fit for = these semantics. But these are the primary semantics of SIP. If the thing y= ou want to do has different semantics, there's probably a way to do with a = different protocol. Albeit, that doesn't mean there isn't an authorization problem for SIP worth identifyin= g and considering.

Jon Peterson
Neustar, Inc.


Regards,
 Rifaat


 --_000_D392BAC11A0530jonpetersonneustarbiz_-- From nobody Fri Jun 24 12:13:14 2016 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 6E32E12D594 for ; Fri, 24 Jun 2016 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 fefun3mXA2bd for ; Fri, 24 Jun 2016 12:13:11 -0700 (PDT) Received: from uhil19pa14.eemsg.mail.mil (uhil19pa14.eemsg.mail.mil [214.24.21.87]) by ietfa.amsl.com (Postfix) with ESMTP id C3E2512D54F for ; Fri, 24 Jun 2016 12:13:10 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.103]) by uhil19pa14.eemsg.mail.mil with ESMTP; 24 Jun 2016 19:13:07 +0000 Received: from UCOLHPQL.easf.csd.disa.mil (131.64.107.38) by edge-cols03.mail.mil (131.64.107.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 24 Jun 2016 19:13:02 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.48]) by UCOLHPQL.easf.csd.disa.mil ([131.64.107.38]) with mapi id 14.03.0266.001; Fri, 24 Jun 2016 19:13:02 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAFfM4CAAEFuAIABZsMAgABovQCADCF4eIAB1wKAgAAE4kA= Date: Fri, 24 Jun 2016 19:13:01 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA285F92B@UCOLHU2J.easf.csd.disa.mil> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:13:13 -0000 Hi, Rifaat: If we look into SIP XCON RFCs for centralized conferencing in SIP (and even= in 3pcc), the fundamental assumption is this: All conferencing services t= o all users are centrally controlled by the "focus." It has been done for a= very solid technical reason: Distributed real-time conferencing services w= ith multimedia for multiparty are very difficult to deal with, not only in = SIP but in all other call control protocols, and security feature is only o= ne them. If the above criterion is not met and AuthNZ is put outside the control of = the focus for real-time multimedia multipoint call, Jon has shown diligentl= y where it leads to us. So, I suggest let us analyze all RFCs related of XCON WG and suggest what w= e can do best here under the umbrella of focus. BR/Radhika=20 PS: Jon - I got the answer of my earlier email sent to you why focus will n= ot be able to either accept or reject the call. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 24, 2016 2:27 PM To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Moreover, in the ad hoc conference corner case, I see no plausible justif= ication for why the conference bridge would ever reject Alice's initial INV= ITE based on the media type it contains. If she's sending her INVITE throug= h the IdP via SIP, it would never even forward the request, let alone issue= a token for it, if it didn't like the media type that Alice was proposing = - if Alice proposes "video", and the IdP only allows "audio", when the IdP = receives Alice's INVITE containing "video" it would do the rejecting itself= (in SIP or HTTP).=20 Yes, that is the whole idea; to delegate the authorization part from the c= onference server; the only thing that the conference will be doing now is e= nforcing the authorization provided in the token, assuming the token is val= id and provided by a trusted entity. ... um, I would have thought this totally undermined your argument. If the = IdP simply prevents the INVITE from ever being sent to the conference bridg= e when the proposed media type is unacceptable to the IdP, then there's no = need to carry attribute to the conference bridge at all. If the IdP doesn't= like the media type, the conference bridge will never see the INVITE; and = if the conference bridge sees the INVITE, then the IdP must have liked the = media type. Attribute adds nothing. This is a consequence of architecting an administrative domain in a draconi= an way that lets intermediaries prevent user agents from sending SIP messag= es where they like, of course. But even if we assume a more open environmen= t where the user agent can send INVITEs directly to the conference bridge, = all the conference bridge needs is a signature or similar token that indica= tes the IdP's approval, -not- any specific attribute. =20 So once again, I don't see how this token would ever lead to the actual I= NVITE that carried the token ever being rejected by the conference bridge b= ased on the media types authorized by the token. So what? why is this a problem? It's a problem because you're proposing to take a feature (OAuth) that exis= ts in HTTP and to add it to SIP. To make an argument for that, you at leas= t must establish that SIP needs this feature - and preferably you need to e= stablish that making this protocol change and performing these operations i= n SIP is less work (in the grand scheme of implementation and deployment ov= erall) than saying that if you want to perform operations like this you sho= uld instead just use HTTP. (Which you can, and for these conference cases, = you surely should.) What I postulated way back at the beginning of this thread is that the kind= of applications that benefit from attribute-based authorization tend to be= controlled by the web rather than by SIP, and that this is why, although w= e've been studying this problem space for more than a decade, we never stan= dardized an attribute-based authorization protocol for SIP. This entire con= ferencing example has been about manipulating conference policy and managin= g constraints on conference policy, which may be a problem space with unsol= ved issues (honestly, I'm not much of an expert on the current thinking abo= ut conferencing) but I don't think it's the SIP authorization problem space= . The semantics of the INVITE method are "hey, remote resource, I'd like to s= et up a session with you involving the following media types." The question= of whether or not you accept INVITEs, which is to my mind the SIP authoriz= ation problem, is mainly about figuring out why you would say yes or no to = that question. What you are proposing here is a conference policy constrain= t token that lets the IdP piggyback information on the INVITE to be sent to= the conference bring. We've struggled here to even identify how that infor= mation would alter to the decision about whether or not to accept the INVIT= E. If we need to standardize a protocol mechanism for that function, I have= a hard time seeing why SIP would be our first choice, and then why an INVI= TE setting up a session would be the right choice, versus just doing this w= ith a protocol interaction that has a semantics other than "I'd like to set= up a session with you." I'd note that your Google drive example is also a pretty poor fit for these= semantics. But these are the primary semantics of SIP. If the thing you wa= nt to do has different semantics, there's probably a way to do with a diffe= rent protocol. Albeit, that doesn't mean there isn't an authorization probl= em for SIP worth identifying and considering. Jon Peterson Neustar, Inc. Regards, Rifaat From nobody Fri Jun 24 12:51:00 2016 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 0C01412D608 for ; Fri, 24 Jun 2016 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=broadsoft-com.20150623.gappssmtp.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 Hw3mB8vYSYX7 for ; Fri, 24 Jun 2016 12:50:57 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 367DA12D1DE for ; Fri, 24 Jun 2016 12:50:57 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id c73so158716412qkg.2 for ; Fri, 24 Jun 2016 12:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=+mrsGIEbZSIli8YYbXROFr8cAkG0QTdolcDcQrobzws=; b=bh7f1ZzMZx57Qa9PGblO8WU4wlxOqUfiz+lVDuJ8CEJu8L0xkdvEIOTijEeNViKmDG Y9lbnfxeynphjjeenwMDghXxgJZEBAZH4X1tkQOjZ+wV6n9vGodPviNRFFjzjM87oqfZ bzeDovUsXROElY2NDPV1eT/0XKCOQ3PxAc6FntFWmwr747nE94aCC4P5qt/aKNp206aj HkyziK7uTBp4y9JuMx9KPodeZYNhilhc6sip7B+V0DG4YnKwsDU7YCAx81FTR3M3Vmpf cZqvJPMD4AwDkSDf6xBrq2WP4h1MAaPisyO9HQN9wKRjvLrVDKJGGZm5wq+v3hQ1qH+P 2Uig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=+mrsGIEbZSIli8YYbXROFr8cAkG0QTdolcDcQrobzws=; b=LZgT+qDrE6NjA30aYn834EkQbtldmpt5IWfhhCgkb0KT/yjahAUHBfzuv6i4hb5Jgm 0+u8ARMKNqme1OSVj9gGgI15ayb5K9RfVARJXbMOEZWHraNVAC0dp0PJ2Oupljndnize Fv+DAfeQB4vpFvuBOQTyp57SnV46Sagc6JV4YpeRla9FfVqKrnG7xEulBF0qc1gHVCDp VAPbthfLiEGv2yP2HThSIrdwLzIEiOICtg8TQaVeNBESWUyeYpJJp/RDez9IZl4VZ12H rwMUIiCnPwLHY4TwHIqcsXv4A+i/K2BzNiNjIL3xPC69UkZPhd+PTjJ7TMnhq+EzxxVW u2ag== X-Gm-Message-State: ALyK8tIbxZXKF4Bh4Janj3ohUhN7UiR0OBeJG8hN1g16nc29sVE6o587Cm1t/LKHGFdKZBAE1eXFpcPEV6lk2/fJ X-Received: by 10.55.6.138 with SMTP id 132mr6731048qkg.206.1466797856342; Fri, 24 Jun 2016 12:50:56 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHOUafbm70bLXNgTEW1wPMFiSXezA== Date: Fri, 24 Jun 2016 15:50:55 -0400 Message-ID: <006207b2b6efec957b88552bddedf60b@mail.gmail.com> To: sipcore@ietf.org, draft-sparks-sipcore-name-addr-guidance@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sipcore] draft-sparks-sipcore-name-addr-guidance-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:50:59 -0000 Hi, The following are some comments concerning draft-sparks-sipcore-name-addr-guidance-00. Thanks, Brett ------- 1) Abstract: "and at least one header field was missed" can potentially be removed. The RFC 3261 section 20.31 mandate for Reply-To is the same as the section 20.20 mandate for From. However, it was missing from the RFC 3261 section 20 paragraph that this draft is updating. 2) Section 7: Errata 3744 and 3894 are mentioned; however the draft doesn't explicitly mention RFC 3325. RFC 3325 potentially should be mentioned within section 3 (or elsewhere) even if this draft does not need to update the RFC. From nobody Sat Jun 25 20:24:40 2016 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 56F6912B012 for ; Sat, 25 Jun 2016 20:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 r_O21IaI0wvr for ; Sat, 25 Jun 2016 20:24:38 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 E058E127078 for ; Sat, 25 Jun 2016 20:24:37 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with SMTP id H0gWbXaoJAlI7H0gWbgmve; Sun, 26 Jun 2016 03:24:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466911476; bh=pF0Zlzl1vjsgQwah0nMJR/ChWNeXFggIgczksQiR24E=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=SVqnZM9M9jOHkY28kqVHT1K08qqj+PYdyRaUNlvPd/O7a40qdXCIgkKeF1lk+r2kH xlwz8glSBwbclhUt0VkfEb49wGykcxyKW7Js9jK+TI82dGQihcTnrP8Sc8F1hHXo/3 9uZTTH1+w168RzLkSifYD2IShi4E1KTQH/FbyXwJrRRZtgNV+CvK1ToOCvIOtD8esR CvrnEkWhbXy5HApZeainuAKvN1QgTthslQaW0nZPNQ4f5jbqNzvhGM0XFcGjbkI86i hrSsed3AqbTAbz/km/Q2yDvuc7NV5oVzjbzygcr/RSkt61UivPnkv8E7Lfo85LwnFV 3E0dXpGzcD6/Q== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-10v.sys.comcast.net with comcast id BFQb1t00B1nMCLR01FQcUA; Sun, 26 Jun 2016 03:24:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5Q3OYCU021051 for ; Sat, 25 Jun 2016 23:24:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5Q3OX57021048; Sat, 25 Jun 2016 23:24:33 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 25 Jun 2016 23:24:33 -0400 Message-ID: <877fdck4y6.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] The state of draft-ietf-sipcore-dns-dual-stack-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 03:24:39 -0000 You can see the diff between the -06 version of draft-ietf-sipcore-dns-dual-stack and the current draft of the -07 version using rfcdiff with this URL: https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-06&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-07.txt If you have the subversion client, you can see the text diff with svn diff http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-06.txt http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-07.txt Dale From nobody Sun Jun 26 19:55:49 2016 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 A5DCC12D5A1 for ; Sun, 26 Jun 2016 19:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 vUH2tZHQ91yZ for ; Sun, 26 Jun 2016 19:55:45 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 AC4D712D59B for ; Sun, 26 Jun 2016 19:55:44 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-07v.sys.comcast.net with SMTP id HMhwbJi63rtfLHMi8bCxfX; Mon, 27 Jun 2016 02:55:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466996144; bh=ITVs/9LhZI5+BM+416gfsrEw5zeVQIcFGIPy4MAeDkE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gtPa+7uZy0ExJGmQXd6mmD3joQ88FZ6IHM0UIHkk8touqYTTs8KZvtfQF86HcXnzT hUSjHr9DAszNS4oVy0O94CiTmaNKg2nqgktL4Mfz2mNOe42n67EWeS+m5CBQG0DCRM 4Ww1zJk2qd0M/mkwmcK44Aw2snSpzSEJ30cLLh7qWv1KqN1HhlMwmeHE13wxvJ/oDt R/W+QDZMVIdKwp8kKBVlfBhDu89LfnY4BiOy2q1B5wjemZhmk4dPsmXaWTrW+3a/KR UuR87C1sAtZNyS4A72DdRPOVNiHulxpjmblbk7HzVbTJ5mtREhYhpTZ+rV5qbA7Cuf L2v7EAzKhieYA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id Bevj1t00R1nMCLR01evkj3; Mon, 27 Jun 2016 02:55:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5R2tg6c001457; Sun, 26 Jun 2016 22:55:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5R2tgAm001449; Sun, 26 Jun 2016 22:55:42 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 26 Jun 2016 22:55:41 -0400 Message-ID: <87y45ribma.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Happy Eyeballs: Handoff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 02:55:47 -0000 This thread addresses the following requirements. I consider these to be part of the Happy Eyeballs problem because they are consequent to inconsistent access to transit networks. SIP has these problems, while HTTP does not, because HTTP does not depend on continuity of long-lasting connections. (Thus, these issues are not addressed in RFC 6555.) - Deal with the handoff problem, i.e., when the call (signaling and media) are being sent over one interface, and that interface becomes unavailable, but another interface has become available, the signaling and media should be rerouted via the other interface. - Similarly, if the external address of a NAT binding changes, the UA has, in effect, transitioned from using one interface to another. - The primary requirement is that the signaling path is reestablished, i.e., the call is not dropped. It may take several seconds for signaling flow to be reestablished. - The media flow should be interrupted for only a "short" period of time so the user does not assume that the call has been dropped. 2 seconds seems a reasonable target. Generally, loss of connectivity can be detected by loss of incoming RTCP packets. It looks like the expected RTCP interval is 5 seconds or longer. Intermittent loss of RTP due to network congestion is likely, but we may have to consider detecting loss of RTP as an indicator of loss of connectivity. We have to consider both symmetric loss of connectivity, in which traffic in both directions is lost simultaneously, and asymmetric loss of connectivity, in which traffic in one direction is lost while traffic in the other continues. Restoring RTP (media) connectivity is straightforward once SIP (signaling) connectivity is restored, by executing a re-INVITE to renegotiate RTP listening ports, etc. Restoring signaling connectivity I can see two ways to restore SIP connectivity: (1) sending re-INVITE to perform a target refresh, changing the UA's target URI, and (2) initiating a new dialog by sending an INVITE-with-Replaces to the remote target URI in order to replace the dialog with a new dialog. In either case, the UA should not attempt to modify/replace the dialog before sending an OPTIONS request and receiving a response from the new interface to the URI that will be targeted by the new INVITE. (The round-trip OPTIONS ensures that there is two-way signaling connectivity to the targeted URI.) If the UA has more than one interface that is still working, it probably needs to probe the target URI using each interface (in parallel), because some URIs may not be reachable from some interfaces. Sending a re-INVITE is a good method if the UA knows that the first URI in the route set can be reached from the UA's new address (interface). It seems to me that this will often not be the case, particularly when handing off between a carrier mobile network and a private WiFi network. If the route set of the current dialog cannot be maintained, it is possible to create an entirely new dialog by directing an INVITE-with-Replaces to the remote target URI of the dialog. In a perfect world, the remote target URI is a GRUU, and the connectivity of a new INVITE to the GRUU is assured. Unfortunately there is no guarantee that will work, either. The difficulty is that all the UA knows about the dialog is the route set, and there are no fixed conventions that allow the UA to extract from the route set a URI that can be targeted by an INVITE/Replaces. E.g., if the route set is: A: UA's target B: record route URI 1 C: record route URI 2 D: record route URI 3 E: remote target It's possible that URI C is the only publicly routable URI, and the URI for the INVITE/Replaces should be E?Route=C&Route=D. One possibility is probing each route URI with an OPTIONS request. That may not be a reliable test if the URI contains an IP address, especially if the address is in private-use space, as the UA may send the OPTIONS request to a different server that has the same address. Though probably if the URI contains a DNS name, then if the OPTIONS succeeded, it probably reached the same server as the route URI indicates. Absent any system for indicating which URIs are publicly routable (other than the "gr" parameter for GRUUs), we probably have to rely on the fact that most SIP telephones execute transfers using INVITE/Replaces requests that assume that the remote target URI that they see is publicly routable. As a consequence of this, SIP switches perform machinations to ensure that the remote target URIs seen by phones are publicly routable. Assuming we can assume that remote target URIs are publicly routable, then we can safely recommend that UAs always use INVITE/Replaces to restore signaling. Maintaining one's GRUU Since we expect a UA to use a GRUU as its target URI so that remote UAs can target the GRUU to reestablish signaling, a UA must ensure that its GRUU routes to all the addresses by which it is reachable. Generally, this means that the UA must update its registration promptly whenever an interface becomes usable. However, it looks like there may be some ugly consequences of maintaining multiple mappings for a UA's GRUU -- how does a request get routed to the GRUU, serially or parallely? Can one use "Request-Disposition: parallel" to force an OPTIONS request to fork parallely to all of the contacts of a GRUU? The executing UA does not need to know which of the contacts of the remote UA were accessible via the GRUU, but it does need to know quite promptly that some contact of the remote UA is accessible via the GRUU. OTOH, when the INVITE/Replaces is processed, we don't want it to be delayed due to serial forking to contacts that are no longer accessible, because the timeouts prescribed in SIP are long relative to the time we want handouts to occur in. But perhaps "Request-Disposition: parallel" can be used here, as the first fork of an INVITE/Replaces to reach a UA will be acted upon and generate a 200 response, and any later arrivals from other forks will receive 481 responses. Glare One risk of reestablishing the dialog is that both UAs might attempt to reestablish the dialog at the same time. If both UAs attempt to re-INVITE at the same time, and the invites cross in transit, the "glare" rules will require each UA to reject the other UA's re-INVITE, back off, and resend, as described in RFC 3261 section 14. If one or both UA uses INVITE/Replaces, various conflicts can occur. It seems to me that the correct way to fix this is to treat the state of "an INVITE/Replaces to revive the dialog is outstanding" as a glare-creating condition that is handled the same way as "a re-INVITE is outstanding". Charging information Ideally, if a handoff does not take the call outside the domain of a single carrier, the carrier should be given enough information to determine that the new dialog is a logical continuation of the old dialog, so that it can combine the charging records of the two dialogs. In may cases, the carrier can probably determine from the INVITE/Replaces that the new dialog is related to the old dialog. But should there be a rule that requires that the new dialog copy some charging-related information from the old dialog? Dale From nobody Mon Jun 27 04:31:48 2016 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 2142012D126 for ; Mon, 27 Jun 2016 04:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 D70QVKWekEK0 for ; Mon, 27 Jun 2016 04:31:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 1CA0912D110 for ; Mon, 27 Jun 2016 04:31:42 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1BF33426A; Mon, 27 Jun 2016 13:31:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87y45ribma.fsf@hobgoblin.ariadne.com> Date: Mon, 27 Jun 2016 13:31:39 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <87y45ribma.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs: Handoff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 11:31:46 -0000 > On 27 Jun 2016, at 04:55, Dale R. Worley wrote: > > This thread addresses the following requirements. I consider these to > be part of the Happy Eyeballs problem because they are consequent to > inconsistent access to transit networks. SIP has these problems, > while HTTP does not, because HTTP does not depend on continuity of > long-lasting connections. (Thus, these issues are not addressed in > RFC 6555.) Responding about process issues: I think we should separate our work with Happy Eyeballs from this work. THis is something missing in Outbound that exist regardless of IPv6. I think it including it in Happy Eyeballs will make it much harder to solve that particular problem - connection setup. This is connection/flow resume - something that I agree we need to look at. Switching flows in the middle of a dialog set up with outbound is needed - as stated above, on multiple flows regardless of address family. It could be going from mobile data to wifi, from one outbound flow to a replacement flow (existing or new) or from IPv4 to IPv6, since IPv4 was deemed to be slower in an ICE background check. /O > > - Deal with the handoff problem, i.e., when the call (signaling > and media) are being sent over one interface, and that interface > becomes unavailable, but another interface has become available, > the signaling and media should be rerouted via the other > interface. > > - Similarly, if the external address of a NAT binding changes, the UA > has, in effect, transitioned from using one interface to another. > > - The primary requirement is that the signaling path is > reestablished, i.e., the call is not dropped. It may take several > seconds for signaling flow to be reestablished. > > - The media flow should be interrupted for only a "short" period of > time so the user does not assume that the call has been dropped. > 2 seconds seems a reasonable target. > > Generally, loss of connectivity can be detected by loss of incoming > RTCP packets. It looks like the expected RTCP interval is 5 seconds > or longer. Intermittent loss of RTP due to network congestion is > likely, but we may have to consider detecting loss of RTP as an > indicator of loss of connectivity. We have to consider both symmetric > loss of connectivity, in which traffic in both directions is lost > simultaneously, and asymmetric loss of connectivity, in which traffic > in one direction is lost while traffic in the other continues. > > Restoring RTP (media) connectivity is straightforward once SIP > (signaling) connectivity is restored, by executing a re-INVITE to > renegotiate RTP listening ports, etc. > > Restoring signaling connectivity > > I can see two ways to restore SIP connectivity: (1) sending re-INVITE > to perform a target refresh, changing the UA's target URI, and (2) > initiating a new dialog by sending an INVITE-with-Replaces to the > remote target URI in order to replace the dialog with a new dialog. > > In either case, the UA should not attempt to modify/replace the dialog > before sending an OPTIONS request and receiving a response from the > new interface to the URI that will be targeted by the new INVITE. > (The round-trip OPTIONS ensures that there is two-way signaling > connectivity to the targeted URI.) If the UA has more than one > interface that is still working, it probably needs to probe the target > URI using each interface (in parallel), because some URIs may not be > reachable from some interfaces. > > Sending a re-INVITE is a good method if the UA knows that the first > URI in the route set can be reached from the UA's new address > (interface). It seems to me that this will often not be the case, > particularly when handing off between a carrier mobile network and a > private WiFi network. > > If the route set of the current dialog cannot be maintained, it is > possible to create an entirely new dialog by directing an > INVITE-with-Replaces to the remote target URI of the dialog. In a > perfect world, the remote target URI is a GRUU, and the connectivity > of a new INVITE to the GRUU is assured. Unfortunately there is no > guarantee that will work, either. > > The difficulty is that all the UA knows about the dialog is the route > set, and there are no fixed conventions that allow the UA to extract > from the route set a URI that can be targeted by an INVITE/Replaces. > E.g., if the route set is: > > A: UA's target > B: record route URI 1 > C: record route URI 2 > D: record route URI 3 > E: remote target > > It's possible that URI C is the only publicly routable URI, and the > URI for the INVITE/Replaces should be E?Route=C&Route=D. > > One possibility is probing each route URI with an OPTIONS request. > That may not be a reliable test if the URI contains an IP address, > especially if the address is in private-use space, as the UA may send > the OPTIONS request to a different server that has the same address. > Though probably if the URI contains a DNS name, then if the OPTIONS > succeeded, it probably reached the same server as the route URI > indicates. > > Absent any system for indicating which URIs are publicly routable > (other than the "gr" parameter for GRUUs), we probably have to rely on > the fact that most SIP telephones execute transfers using > INVITE/Replaces requests that assume that the remote target URI that > they see is publicly routable. As a consequence of this, SIP switches > perform machinations to ensure that the remote target URIs seen by > phones are publicly routable. > > Assuming we can assume that remote target URIs are publicly routable, > then we can safely recommend that UAs always use INVITE/Replaces to > restore signaling. > > Maintaining one's GRUU > > Since we expect a UA to use a GRUU as its target URI so that remote > UAs can target the GRUU to reestablish signaling, a UA must ensure > that its GRUU routes to all the addresses by which it is reachable. > Generally, this means that the UA must update its registration > promptly whenever an interface becomes usable. > > However, it looks like there may be some ugly consequences of > maintaining multiple mappings for a UA's GRUU -- how does a request > get routed to the GRUU, serially or parallely? Can one use > "Request-Disposition: parallel" to force an OPTIONS request to fork > parallely to all of the contacts of a GRUU? The executing UA does not > need to know which of the contacts of the remote UA were accessible > via the GRUU, but it does need to know quite promptly that some > contact of the remote UA is accessible via the GRUU. > > OTOH, when the INVITE/Replaces is processed, we don't want it to be > delayed due to serial forking to contacts that are no longer > accessible, because the timeouts prescribed in SIP are long relative > to the time we want handouts to occur in. But perhaps > "Request-Disposition: parallel" can be used here, as the first fork of > an INVITE/Replaces to reach a UA will be acted upon and generate a 200 > response, and any later arrivals from other forks will receive 481 > responses. > > Glare > > One risk of reestablishing the dialog is that both UAs might attempt > to reestablish the dialog at the same time. If both UAs attempt to > re-INVITE at the same time, and the invites cross in transit, the > "glare" rules will require each UA to reject the other UA's re-INVITE, > back off, and resend, as described in RFC 3261 section 14. > > If one or both UA uses INVITE/Replaces, various conflicts can occur. > It seems to me that the correct way to fix this is to treat the state > of "an INVITE/Replaces to revive the dialog is outstanding" as a > glare-creating condition that is handled the same way as "a re-INVITE > is outstanding". > > Charging information > > Ideally, if a handoff does not take the call outside the domain of a > single carrier, the carrier should be given enough information to > determine that the new dialog is a logical continuation of the old > dialog, so that it can combine the charging records of the two > dialogs. In may cases, the carrier can probably determine from the > INVITE/Replaces that the new dialog is related to the old dialog. But > should there be a rule that requires that the new dialog copy some > charging-related information from the old dialog? > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jun 27 09:07:26 2016 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 65CD212D6AA for ; Mon, 27 Jun 2016 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 GUZGYY1zeAnc for ; Mon, 27 Jun 2016 09:07:24 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 32C4D12D689 for ; Mon, 27 Jun 2016 09:07:20 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with SMTP id HZ2ZbKRg9rtfLHZ4BbENMW; Mon, 27 Jun 2016 16:07:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467043639; bh=owvREPjP3aLurAIE+9kRxevgCUqjGHIUOK2ZAWHJ9q8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=MzdMEmt5FahgNT6vNOcPm9beHHCMyKS0Y9ElolVcbFsNM9gJ8U7JSDiE1VeB2auMo 7DYpYIUHx3OzEA1Cu1+2yEZfBMh/wFb1mBVyUw7O6HNZFuQhcsdb0aKlforAWL1wdx FVSIAanhp6wyrqxHOw4BlwBkHLMRJDT8Z+hslxki98phvQh+LoQJnXubcTr7uNXq13 VkJsH6Bjp3K3hd71UvPBJSHP9CfzP6H35Y+USRU4bUyxhhzKa1PdTzwR1kJL3oQ8Wv AzrIyJbNgMVvwyvuy5MJMoAQgxWen8SxtYvT4JAqliEZKX4F4t3VTvGJbYCQ4loAYa RT3unLZG3C10w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id Bs7J1t0081nMCLR01s7J6s; Mon, 27 Jun 2016 16:07:19 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5RG7HVm017456; Mon, 27 Jun 2016 12:07:17 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5RG7Gnr017445; Mon, 27 Jun 2016 12:07:16 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 27 Jun 2016 12:07:15 -0400 Message-ID: <87bn2mipjg.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Handoff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 16:07:25 -0000 "Olle E. Johansson" writes: > I think we should separate our work with Happy Eyeballs from this work. > THis is something missing in Outbound that exist regardless of IPv6. > I think it including it in Happy Eyeballs will make it much harder to > solve that particular problem - connection setup. It's not even limited to Outbound, either. But yes, it probably can be profitably separated from Happy Eyeballs itself. Dale From nobody Mon Jun 27 12:14:22 2016 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 B5E4D12D7A7 for ; Mon, 27 Jun 2016 12:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 3JFBUz4iuqhN for ; Mon, 27 Jun 2016 12:14:19 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 74FB512D75D for ; Mon, 27 Jun 2016 12:14:19 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with SMTP id HbxcbihyVTD5UHbz8bOCws; Mon, 27 Jun 2016 19:14:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467054858; bh=rLJMKSlyR7OfiO1dUeMGJz4hKPmr1NCMNtQZR0ns5GY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=r1NdqxLGx0HGy3yvvCuEh4HErnOxGUzJC9UXtwebpqsFJJq3iKM7ZXc+pgVpMREqR QpSWfiENgqgi3l123tLAp7M1DVeWrdWZM0lGvstzQqb8CL1Th+ap3Xy6bekZnJrx2R 5RNY8uWFskTIHvKOXpUt8iFvAdk5Ax82sIvmpDzFOunIP3ARpLaSDSA0PoM6kQ6OHo Xf2+IdIN1jc6bXh7qr3aD7qj1jOr8F6c2OB7QnVdkYdTgyKQyJmEZyHP86nq+HqHo9 RXfWrKHYvCpakPulT3sp8N1ewxe5W00owQuMJiJ6toalWzP6FdpWj9vcH759uzi2AT TkqW2HKi4O8vQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id BvEJ1t0021nMCLR01vEJVS; Mon, 27 Jun 2016 19:14:18 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5RJEGT7004133; Mon, 27 Jun 2016 15:14:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5RJEGGW004126; Mon, 27 Jun 2016 15:14:16 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 27 Jun 2016 15:14:16 -0400 Message-ID: <87twgeh2bb.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:14:21 -0000 Brett Tate writes: > The issue with using a smaller T1 value is that it doesn't just impact the > desired timer. For instance, it can cause more retries. Because of this, > the draft might want to specify allowing the specific smaller timers in a > way which doesn't rely upon a smaller T1. > > If it matters, RFC 3261 section 17.1.1.2 has normative statements > concerning the topic of lowing T1. It seems to me that the core concept of that section is "T1 is an estimate of the round-trip time (RTT)". And while the average RTT over the global Internet is nearly 500ms, the RTT to places that expect a lot of traffic seems to be 100ms or less. (I expect RTT on carrier-managed networks to be even less.) So I don't see cutting the default T1 as contravening that section. True, that does increase the number of retries, but that seems to be the correct change if it's true that if you don't see a response in 100ms, it is more likely that the request was lost than that it is delayed in transit. Do we have any data on what RTT and packet loss is like in real systems? Dale From nobody Mon Jun 27 12:47:04 2016 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 EF00C12D13F for ; Mon, 27 Jun 2016 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 JkSZTijxlkcS for ; Mon, 27 Jun 2016 12:47:00 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 F272C12B044 for ; Mon, 27 Jun 2016 12:46:59 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id f6so70075521ith.0 for ; Mon, 27 Jun 2016 12:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SbN6rq6tXGxZoTQiMkBxVIFxu5AHOMLy9atfJqsHKAk=; b=POHEObQKJvQI3kq7PViiFIsHvcDNdbtGFhxDZ4XltJG1zFAUQr0wAPu7TudppgkYV6 rZdDnYuUE8Zn9Sm/4ZgYBq1lT1Y8AwkS1Cnvs13U/84yu6HFLIIyWj/w2aa+ydXvogM1 X9R4Lo0KkY9QE9Vwlc+U7vnakOtLFJXDN6ePj/Mzow7wV3o5sXBLf0codSXKUpSv12Wd YCiGXtenXfVJSPB9zgKepQYeuksgOcd1rOJKmw2OBZaywq99B4phreBocZ42XLEnQnF7 qJyiiq4R+qJAfM7gGaOlW0/aDNBepkoNmq08Cdv+O4Jgvqqq9AIoSf5ztJqhpDMAQXry VROQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SbN6rq6tXGxZoTQiMkBxVIFxu5AHOMLy9atfJqsHKAk=; b=ZyL0r9AYn4zVGt7CPPWCM63JIwy92HCTBbEXZ4kQ0qUrwzzbOOpyVNhlldfwCMH1MQ 5L3mhkw5yY05qwJU1p30JqoJ8yr7N+dbpoQrCDRxK8+GTyjrynYhwas8DZn6cPtmqV1b V27xSTOHi93WWtEsOJkZcHzVGBI5IHRgmAwBRrVdwrhB4JKE2efeOs/FuUEJG0LJJCTq bTpLqkZbS4TTzvcP80D4m2jPHUGNrFTMm38le/mgixXr0bYbwJRs7U69IFMYnL1hcIji 3Jl6ucDkJVVgEaiIC8buG+0TTYis/QnPwugv8yyZ+4/Nzw63O/9fYlWSLLPTrWQPyiGe 0bxA== X-Gm-Message-State: ALyK8tL//MRzQwvZ0vfmi8U/kmfrGvHA3hTqrcL2RM2sEuY7wDzwqYrml/1PHfRPu/s9xg== X-Received: by 10.36.216.5 with SMTP id b5mr10782528itg.19.1467056819160; Mon, 27 Jun 2016 12:46:59 -0700 (PDT) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com. [209.85.214.44]) by smtp.gmail.com with ESMTPSA id h193sm10003803ioe.40.2016.06.27.12.46.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2016 12:46:58 -0700 (PDT) Received: by mail-it0-f44.google.com with SMTP id h190so71184251ith.1 for ; Mon, 27 Jun 2016 12:46:58 -0700 (PDT) X-Received: by 10.36.184.130 with SMTP id m124mr10665580ite.95.1467056818088; Mon, 27 Jun 2016 12:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Mon, 27 Jun 2016 12:46:57 -0700 (PDT) In-Reply-To: <87twgeh2bb.fsf@hobgoblin.ariadne.com> References: <87twgeh2bb.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Mon, 27 Jun 2016 15:46:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=94eb2c11424681f7ab053647c81b Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:47:02 -0000 --94eb2c11424681f7ab053647c81b Content-Type: text/plain; charset=UTF-8 On Mon, Jun 27, 2016 at 3:14 PM, Dale R. Worley wrote: > Do we have any data on what RTT and packet loss is like in real systems? > This all depends what you mean by the "real systems". For USA hosted PBX systems working with office based networks, RTT is 70ms (typical delay from east coast USA to LA datacenter) or less. If service is geo optimized between two or more data centers, RTT is 40ms or less. Packet loss is nearly zero. These conditions account for majority of hosted PBX traffic. If you are dealing with international, RTT is around 500ms or less for most locations. Brazil to Singapore is around 420ms RTT, for instance. Western Europe to LA is around 150ms RTT. There are, of cause, locations where RTT is much higher, especially when satellite links are involved. Packet loss heavily depends on the last mile link utilization. There are still links which are 128K which are used for VoIP. If someone starts uploading things on this link, you start seeing packet loss or 2-3 sec packet delays. Most of the time, form locations with broadband connections, packet loss is close to zero. If you start dealing with mobile, things are a lot less predictable. Packet loss can be in 10-20% range. RTT delays can be up to a second. Some other locations, such as hotels, especially internationally, are often even worse then mobile due to random traffic blocking or deliberate attempts to block VoIP. Please let me know if you need any more data. _____________ Roman Shpount --94eb2c11424681f7ab053647c81b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 27, 2016 at 3:14 PM, Da= le R. Worley <worley@ariadne.com> wrote:
D= o we have any data on what RTT and packet loss is like in real systems?
=

This all depends what you mean by the &quo= t;real systems". For USA hosted PBX systems working with office based = networks, RTT is 70ms (typical delay from east coast USA to LA datacenter) = or less. If service is geo optimized between two or more data centers, RTT = is 40ms or less. Packet loss is nearly zero. These conditions account for m= ajority of hosted PBX traffic.

If you are dealing = with international, RTT is around 500ms or less for most locations. Brazil = to Singapore is around 420ms RTT, for instance. Western Europe to LA is aro= und 150ms RTT. There are, of cause, locations where RTT is much higher, esp= ecially when satellite links are involved.

Packet = loss heavily depends on the last mile link utilization. There are still lin= ks which are 128K which are used for VoIP. If someone starts uploading thin= gs on this link, you start seeing packet loss or 2-3 sec packet delays. Mos= t of the time, form locations with broadband connections, packet loss is cl= ose to zero.

If you start dealing with mobile, thi= ngs are a lot less predictable. Packet loss can be in 10-20% range. RTT del= ays can be up to a second. Some other locations, such as hotels, especially= internationally, are often even worse then mobile due to random traffic bl= ocking or deliberate attempts to block VoIP.

Pleas= e let me know if you need any more data.
_____________
Roman Shpount
=C2=A0
--94eb2c11424681f7ab053647c81b-- From nobody Tue Jun 28 02:32:56 2016 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 EA12A12DBFD for ; Tue, 28 Jun 2016 02:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 6iIje438FKXV for ; Tue, 28 Jun 2016 02:32:51 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 0B0F612DBE1 for ; Tue, 28 Jun 2016 02:32:23 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id c2so14176739vkg.1 for ; Tue, 28 Jun 2016 02:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zBS8psJTJ1XI8nzT2dSEatGMXiG8BkWvfCi73jQYpk8=; b=YPlWAJGzvkGKZ/qL6c0TyPGUZ1ZlpyL7bWKbOErB9tEhK0InIuvUcuzC+IRsys5RSa C/VO2hM7q0Tslam6hCHxUTZqvkxtPFXP5o2H8vARcJ1QC5yoy+Wh0eSvzy2Pv61L41EO 1B9+hFD3yIx9cpiB9zUJtLhxgpnurYVOk5JO8y7qHPq3SL+/xDE+O6tMuSDGFmz2+6/e XXfIw+XFrY7V2dU87bE7QRQoqcOdSfkYmPoNQdr9yuxCCi7dL1kXcl/Cv5/S+jqBbCJJ OLuV52uV/4OukNFIr/P8q8QJ00YTKTzWIHzQrkVTe7uQ21MyqclNVXCn9goniaoIs4+i IO3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zBS8psJTJ1XI8nzT2dSEatGMXiG8BkWvfCi73jQYpk8=; b=in5U7XiYAy1rmgtJNNKDIMkC8+GL6psu4heIXeLFlOvtpsdZjz9+xURqvvtq4PeTeh YsA7iME9kIdsJO+2paQcgHCjm+MJ3Ehw304mcU/gIFndS+GXuJI7t+ENeQ1zP27PTXb6 0o8GzOwY8bE4Rv0/MACvOT5JYJI0LpAJ6rEGli5pf6eaRgXy3hmX79EVuzPxhzXY8maZ vzT71UQBoyr1VGlo9pD0ZjeAoWe7/aQsSFrqH+3l7dWvGp6YDWa+PXQnYah29aIdxcPN ajj6qyIqs1+LA7vqHu1RIIMcGtl4EJpppMohED6HHJ9rWuKVfRlOI5eQxfWLtN+Vqxhp tRxA== X-Gm-Message-State: ALyK8tLFkqYtcfb6NMKlHHrjUcPI2/e9eNl8DPF7fDMfhau3tSGGNGII1TKkIPu3nzrXA3Qst4NTt3tvkiEVpA== X-Received: by 10.31.165.198 with SMTP id o189mr34934vke.9.1467106342148; Tue, 28 Jun 2016 02:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Tue, 28 Jun 2016 02:32:21 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Rifaat Shekh-Yusef Date: Tue, 28 Jun 2016 05:32:21 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a114161185f21c605365350a8 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 09:32:55 -0000 --001a114161185f21c605365350a8 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 24, 2016 at 2:27 PM, Peterson, Jon wrote: > >> >> Moreover, in the ad hoc conference corner case, I see no plausible >> justification for why the conference bridge would ever reject Alice's >> initial INVITE based on the media type it contains. If she's sending her >> INVITE through the IdP via SIP, it would never even forward the request, >> let alone issue a token for it, if it didn't like the media type that Alice >> was proposing - if Alice proposes "video", and the IdP only allows "audio", >> when the IdP receives Alice's INVITE containing "video" it would do the >> rejecting itself (in SIP or HTTP). >> > > Yes, that is the whole idea; to delegate the authorization part from the > conference server; the only thing that the conference will be doing now is > enforcing the authorization provided in the token, assuming the token is > valid and provided by a trusted entity. > > > ... um, I would have thought this totally undermined your argument. If the > IdP simply prevents the INVITE from ever being sent to the conference > bridge when the proposed media type is unacceptable to the IdP, then > there's no need to carry attribute to the conference bridge at all. If the > IdP doesn't like the media type, the conference bridge will never see the > INVITE; and if the conference bridge sees the INVITE, then the IdP must > have liked the media type. Attribute adds nothing. > > This is a consequence of architecting an administrative domain in a > draconian way that lets intermediaries prevent user agents from sending SIP > messages where they like, of course. > I am not sure what you mean by this. The IdP cannot prevent anybody from sending any request to any server. > But even if we assume a more open environment where the user agent can > send INVITEs directly to the conference bridge, all the conference bridge > needs is a signature or similar token that indicates the IdP's approval, > -not- any specific attribute. > Of course attributes are needed. How would otherwise the conference server know which type of conference to start (audio, video, etc)? what is the limitation on the number of participant? etc... > > > >> So once again, I don't see how this token would ever lead to the actual >> INVITE that carried the token ever being rejected by the conference bridge >> based on the media types authorized by the token. >> > > So what? why is this a problem? > > > It's a problem because you're proposing to take a feature (OAuth) that > exists in HTTP and to add it to SIP. > I would not call OAuth a "feature". It is an authorization framework. > To make an argument for that, you at least must establish that SIP needs > this feature - and preferably you need to establish that making this > protocol change and performing these operations in SIP is less work (in the > grand scheme of implementation and deployment overall) than saying that if > you want to perform operations like this you should instead just use HTTP. > (Which you can, and for these conference cases, you surely should.) > > What I postulated way back at the beginning of this thread is that the > kind of applications that benefit from attribute-based authorization tend > to be controlled by the web rather than by SIP, and that this is why, > although we've been studying this problem space for more than a decade, we > never standardized an attribute-based authorization protocol for SIP. This > entire conferencing example has been about manipulating conference policy > and managing constraints on conference policy, which may be a problem space > with unsolved issues (honestly, I'm not much of an expert on the current > thinking about conferencing) but I don't think it's the SIP authorization > problem space. > > The semantics of the INVITE method are "hey, remote resource, I'd like to > set up a session with you involving the following media types." The > question of whether or not you accept INVITEs, which is to my mind the SIP > authorization problem, > This is the main difference between how you and I see this. I think that the authorization problem is much bigger than just authorizing a specific SIP method. The authorization should be dealing with *access to services* provided by SIP servers regardless of the SIP method being used. Much the same way that HTTP authorizes *access to resources*, regardless of the HTTP method being used. You do not need a specific token for HTTP GET vs HTTP POST, because the method does not matter; what matters is the resource that the method is trying to access. Regards, Rifaat > is mainly about figuring out why you would say yes or no to that question. > What you are proposing here is a conference policy constraint token that > lets the IdP piggyback information on the INVITE to be sent to the > conference bring. We've struggled here to even identify how that > information would alter to the decision about whether or not to accept the > INVITE. If we need to standardize a protocol mechanism for that function, I > have a hard time seeing why SIP would be our first choice, and then why an > INVITE setting up a session would be the right choice, versus just doing > this with a protocol interaction that has a semantics other than "I'd like > to set up a session with you." > > I'd note that your Google drive example is also a pretty poor fit for > these semantics. But these are the primary semantics of SIP. If the thing > you want to do has different semantics, there's probably a way to do with a > different protocol. Albeit, that doesn't mean there isn't an authorization > problem for SIP worth identifying and considering. > > Jon Peterson > Neustar, Inc. > > > Regards, > Rifaat > > > --001a114161185f21c605365350a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 24, 2016 at 2:27 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:


Moreover, in the ad hoc conference corner case, I see no plausible jus= tification for why the conference bridge would ever reject Alice's init= ial INVITE based on the media type it contains. If she's sending her IN= VITE through the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't= like the media type that Alice was proposing - if Alice proposes "vid= eo", and the IdP only allows "audio", when the IdP receives = Alice's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP).

Yes, that is the whole idea; to delegate the authorization part from t= he conference server; the only thing that the conference will be doing now = is enforcing the authorization provided in the token, assuming the token is= valid and provided by a trusted entity.

... um, I would have thought this totally undermined your argum= ent. If the IdP simply prevents the INVITE from ever being sent to the conf= erence bridge when the proposed media type is unacceptable to the IdP, then= there's no need to carry attribute to the conference bridge at all. If the IdP doesn't like the media type, = the conference bridge will never see the INVITE; and if the conference brid= ge sees the INVITE, then the IdP must have liked the media type. Attribute = adds nothing.

This is a consequence of architecting an administrative domain in a dr= aconian way that lets intermediaries prevent user agents from sending SIP m= essages where they like, of course.

I am not sure what you mean by this. The IdP cannot prevent anybody f= rom sending any request to any server.

=C2=A0
But even if we assume a more= open environment where the user agent can send INVITEs directly to the conference bridge, all the conference bridge = needs is a signature or similar token that indicates the IdP's approval= , -not- any specific attribute.

Of course attributes are needed.=C2=A0
How would otherwise the c= onference server know which type of conference to start (audio, video, etc)= ? what is the limitation on the number of participant? etc...
=C2=A0

=C2=A0
So once again, I don't see how this token would ever lead to the a= ctual INVITE that carried the token ever being rejected by the conference b= ridge based on the media types authorized by the token.

So what? why is this a problem?

It's a problem because you're proposing to take a featu= re (OAuth) that exists in HTTP and to add it to SIP. =C2=A0

I would not call OAuth a "feature". = It is an authorization framework.

=C2=A0
To make an argument for that, you= at least must establish that SIP needs this feature - and preferably you n= eed to establish that making this protocol change and performing these operations in SIP is less work (in the grand s= cheme of implementation and deployment overall) than saying that if you wan= t to perform operations like this you should instead just use HTTP. (Which = you can, and for these conference cases, you surely should.)

What I postulated way back at the beginning of this thread is that the= kind of applications that benefit from attribute-based authorization tend = to be controlled by the web rather than by SIP, and that this is why, altho= ugh we've been studying this problem space for more than a decade, we never standardized an attribute-based aut= horization protocol for SIP. This entire conferencing example has been abou= t manipulating conference policy and managing constraints on conference pol= icy, which may be a problem space with unsolved issues (honestly, I'm not much of an expert on the curre= nt thinking about conferencing) but I don't think it's the SIP auth= orization problem space.

The semantics of the INVITE method are "hey, remote resource, I&#= 39;d like to set up a session with you involving the following media types.= " The question of whether or not you accept INVITEs, which is to my mi= nd the SIP authorization problem,

This is the main difference between how you and I see this.
I = think that the authorization problem is much bigger than just authorizing a= specific SIP method. The authorization should be dealing with access to= services provided by SIP servers regardless of the SIP method being us= ed.
Much the same way that HTTP authorizes access to resources= , regardless of the HTTP method being used. You do not need a specific = token for HTTP GET vs HTTP POST, because the method does not matter; what m= atters is the resource that the method is trying to access.

<= /div>
Regards,
=C2=A0Rifaat


=C2=A0
is mainly= about figuring out why you would say yes or no to that question. What you are pr= oposing here is a conference policy constraint token that lets the IdP pigg= yback information on the INVITE to be sent to the conference bring. We'= ve struggled here to even identify how that information would alter to the decision about whether or not to accep= t the INVITE. If we need to standardize a protocol mechanism for that funct= ion, I have a hard time seeing why SIP would be our first choice, and then = why an INVITE setting up a session would be the right choice, versus just doing this with a protocol interact= ion that has a semantics other than "I'd like to set up a session = with you."

I'd note that your Google drive example is also a pretty poor fit = for these semantics. But these are the primary semantics of SIP. If the thi= ng you want to do has different semantics, there's probably a way to do= with a different protocol. Albeit, that doesn't mean there isn't an authorization problem for SIP worth id= entifying and considering.

Jon Peterson
Neustar, Inc.


Regards,
=C2=A0Rifaat

--001a114161185f21c605365350a8-- From nobody Tue Jun 28 09:29:32 2016 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 E1D1112D589 for ; Tue, 28 Jun 2016 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=broadsoft-com.20150623.gappssmtp.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 ybR_r1lM9C5h for ; Tue, 28 Jun 2016 09:29:28 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BC7BB12D51F for ; Tue, 28 Jun 2016 09:29:28 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id t127so39185828qkf.1 for ; Tue, 28 Jun 2016 09:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=gxPTo8eKFhDT0iLyaWnPdqEUgwXN9tJ84L7F5XlE2O0=; b=0axPlIWZV/62qvBeZoHv4Rcc9kFbIkvW+cVxX1YLHYLdEoyTh8aL7ZYPAs0wsZJ3Wx K5efpIcbcAolaT4xfTahBGj/u4apT5aAnBFUUTOh0qU3aCeUo89R9oFRV/Pkf7Ts9imp 7SQalWLm6g60rN6alfy6Hgx+HImBd/f17T6ZcEq0Mtuuurl+tmxkZTREpO/+8m5g0+qE 8GYaJlLYSMqiJ0pw+zCunR7t52/F9T+wG72tKwu7iPu+2kIxsrJhnVp5hVT20HT6y0x4 pyIkXMNJ/+aZt59b9ED/5V+Co33wLuVwOo7T0OK0cqwAFNAJLZRWx4MRlF+ncJC/KA6B +gbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=gxPTo8eKFhDT0iLyaWnPdqEUgwXN9tJ84L7F5XlE2O0=; b=JO6q8SGbG3i4PFkiaWxM7GWak4TGNG1Leo9tNcyv6ZBPy3O1fIodfYhDX+LtF12KyX nxdg97b+kqn2aMRNlw6pZe6Olg2mzZEO7uudtxBoFKthSFvgXdBdKqnZkzXFnDacdVf0 DOFcA9ki21eisdUg8KHpKV1H7BXo65orNpa+TBeJy53BRrFzgbaKaJYnVl43mI4jatze rx8Y7QfW+v9oEfDNaLJf8TgS5rft7/WWeBUV19/JLxH/qX+bspwoYC/P/w/PNIE1IeL+ yG5jk/NQK4LVe13lub1H65F4W/HWYTCu22PuPsZDG6BYHgwoeTxZF0T0a9dbF84MCQB3 po8g== X-Gm-Message-State: ALyK8tLkZf+cNiLk9C/vJRyJHmUruv/IyoByWZo50qobPl/kgSJtJUPxrqivEh/upKHg0tqmdVzehoaUdrlay8Dv X-Received: by 10.55.110.65 with SMTP id j62mr3529327qkc.112.1467131367882; Tue, 28 Jun 2016 09:29:27 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHRWgyM1C64+0SdTX2PDuyfHpd68Q== Date: Tue, 28 Jun 2016 12:29:26 -0400 Message-ID: <89c6b358b260d20a188e046840511c2c@mail.gmail.com> To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs: Targets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:29:31 -0000 Hi, Thanks for the response; reply is inline. > > The issue with using a smaller T1 value is that it doesn't > > just impact the desired timer. For instance, it can cause > > more retries. Because of this, the draft might want to > > specify allowing the specific smaller timers in a way which > > doesn't rely upon a smaller T1. > > > > If it matters, RFC 3261 section 17.1.1.2 has normative > > statements concerning the topic of lowing T1. > > It seems to me that the core concept of that section is > "T1 is an estimate of the round-trip time (RTT)". > And while the average RTT over the global Internet is nearly > 500ms, the RTT to places that expect a lot of traffic > seems to be 100ms or less. (I expect RTT on carrier-managed > networks to be even less.) So I don't see cutting the > default T1 as contravening that section. Although this draft can update it if needed, RFC 3261 section 17.1.1.2 paragraph four was the text of potential concern since it looks like an attempt to limit where T1 can be lowered. "Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger." > True, that does increase the number of retries, but that seems > to be the correct change if it's true that if you don't see a > response in 100ms, it is more likely that the request was lost > than that it is delayed in transit. It seems like the extra retries would be an unnecessary burden upon the next hop. However, I guess that it depends upon if more concerned with 1) dropped packets or 2) the retries increasing the frequency of devices becoming overloaded. Unless this draft updates the RFC 4320 behavior, there can be many retries before the next hop can return 100 for non-INVITE requests. As mentioned, the smaller T1 value would not just impact the desired timers. It would impact other letter timers within RFC 3261 and RFC 6026 such as Timer L, Timer M, Timer H, Timer J, and as mentioned Timer A, Timer E, and Timer G. Should these timers really be reduced? For instance, is it acceptable for UAS to use T1 of 100ms when the UAC and intermediaries are using T1 of 500ms? From nobody Tue Jun 28 12:04:16 2016 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 53AD912D642 for ; Tue, 28 Jun 2016 12:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 QwLbpJA-kVHk for ; Tue, 28 Jun 2016 12:04:12 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 2279612D65E for ; Tue, 28 Jun 2016 12:04:05 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with SMTP id HyHpb945fE8zeHyImbbVTG; Tue, 28 Jun 2016 19:04:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467140644; bh=V3UNlIgTEH8bUB0RikTLXy1qg2KmuaJOGeyApnjmRfc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=YUnlkTcGlrRcOYN/cz7QIS8p1dXD5bGEhhiRumvmh7FZHB1vmIpZwvslWUD5xOXhb YR8R5D0uuhg8h3UudKEuWWyNkuMaunV84TN8a7PJHg0PatfL3DOuQiUutXbPjUo3ul hPzMXF6HYfv2NY0m9XOkYIe1qnEbH6ww+a6D0KBYkI+pXHOsJ9OZGf4ruHDBWQXxQl Amn9yTJ52iYIuY9wBIY8mDcmiQVHqOSRwiXNLajd0vT6Tsx0lf1oaNBBDLMjIM7pjT z3VJ3IP2z2U9/3lyuUp6WygpbmaagFvQ+1q+p1xo6yV+ccwLIAePi+3eEk7N/p1Gk7 qbXlUTfLDcZDw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id CK431t00i1nMCLR01K44Lc; Tue, 28 Jun 2016 19:04:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5SJ43cb020911 for ; Tue, 28 Jun 2016 15:04:03 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5SJ43Np020908; Tue, 28 Jun 2016 15:04:03 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 28 Jun 2016 15:04:03 -0400 Message-ID: <87por1dtjw.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] How to construct a finite state machine to select an alerting signal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 19:04:14 -0000 I've worked out how to construct a finite state machine to process the 'alert' URNs in an Alert-Info header to select one of the alerting signals of a UA. Once you fix the set of signals and their meanings (the URNs that the signal indicates), there's an algorithm that constructs the FSM, and it ensures that FSM satisfies the rules in RFC 7462. I've written a draft to describe the process in detail. The draft also points to an implementation of the algorithm in Python, so people can try out this method and see how it works for them. I'd like to hear any feedback you have. Dale A new version of I-D, draft-worley-alert-info-fsm-02.txt has been successfully submitted by Dale R. Worley and posted to the IETF repository. Name: draft-worley-alert-info-fsm Revision: 02 Title: A Simpler Method for Processing Alert-Info URNs Document date: 2016-06-05 Group: Individual Submission Pages: 36 URL: https://www.ietf.org/internet-drafts/draft-worley-alert-info-fsm-02.txt Status: https://datatracker.ietf.org/doc/draft-worley-alert-info-fsm/ Htmlized: https://tools.ietf.org/html/draft-worley-alert-info-fsm-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-worley-alert-info-fsm-02 Abstract: The "alert" namespace of uniform resource names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a VoIP telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. Based on the URNs in the Alert-Info header field, the user agent must select an the best available signal to present to its user to indicate the characteristics of the call. This document describes a method by which a user agent's designer can, based on the user agent's signals and their meanings, constructing a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace. In many situations, the resulting FSM is simpler and faster than the previously described selection algorithm. From nobody Tue Jun 28 13:55:50 2016 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 AFBE212D099 for ; Tue, 28 Jun 2016 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 EHaWWUot42zl for ; Tue, 28 Jun 2016 13:55:46 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 1F65512DAEF for ; Tue, 28 Jun 2016 13:55:10 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-01v.sys.comcast.net with SMTP id I01tbH5gqkzylI02Gb7xs2; Tue, 28 Jun 2016 20:55:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467147308; bh=+u5EbnUu3g4KHF97IInzJxeRIiHKDLwovEGmWNztBMw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mOeTy/8VAanY8pe+FTkxAhlr7E8G4Tqj4shgcnoG/epj6Cd1Nz/nSsBHAWQ85AzBE hRM7w2HSI5oobku+SY3nAeKYNf2uHRUGvYG1PoxxBXqZGEnNYu6QDDJXcf9xPSFi7d u8SMLyp6IHwfO/sWb9Wyn8ESlJcESt73SAYzKJlQqQThSh1wmqDDMHQem9ClKVchgo lkC/KPqHkA/ldwhZjAA9/v1WixzHIieWErFWvEqpnSo2mxMXxJrKrkrj2PSOv08b2E QDKlj0D5C1PCzOt9VlFlKXOy+MZmg6dIpsmtd+r0dhYuw1Iv5Oo3r+2Gs2epzBv+Y9 A9GTIGrte5QCQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-20v.sys.comcast.net with comcast id CLv71t00p3KdFy101Lv8F4; Tue, 28 Jun 2016 20:55:08 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Tue, 28 Jun 2016 16:55:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 20:55:48 -0000 On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote: > The semantics of the INVITE method are "hey, remote resource, I'd > like to set up a session with you involving the following media > types." The question of whether or not you accept INVITEs, which is > to my mind the SIP authorization problem, > > This is the main difference between how you and I see this. > I think that the authorization problem is much bigger than just > authorizing a specific SIP method. The authorization should be dealing > with *access to services* provided by SIP servers regardless of the SIP > method being used. > Much the same way that HTTP authorizes *access to resources*, regardless > of the HTTP method being used. You do not need a specific token for HTTP > GET vs HTTP POST, because the method does not matter; what matters is > the resource that the method is trying to access. If you want to tell a server something about what you want it to do, you can use caller preferences. At least then you are being explicit about it. That seems more straightforward than embedding similar information into an authorization token. Thanks, Paul From nobody Wed Jun 29 18:35:30 2016 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 1B7E012DF2A for ; Wed, 29 Jun 2016 18:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 ST8aBtfY4W46 for ; Wed, 29 Jun 2016 18:35:27 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 286A812D8AA for ; Wed, 29 Jun 2016 18:35:27 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-10v.sys.comcast.net with SMTP id IQs8bsAHuEFCNIQt4bGoUs; Thu, 30 Jun 2016 01:35:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467250526; bh=573jVMgazF6Kwc1qaYg0woQxhOkUnCAWwE4JaFn2ZY0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=YfMgZ40Y/BBBThbpLHLS+nB/sbNl89ou5cVXAVlJYTa5kAO6T23MVfFlFAkos6hoN 5nTMzr4m1NonTVYYSjBZTruI3PFH9CV5NUJB9oEq0Rv8pmm1wH3aNhjqMECa7ffI2r 0ZLX7yWRXLhZCBNg6D64cC4NJIy5YZ3+Jv5j/jFidDHSB9a3XuoWLo/Ws1R10oAhdo WGyHbaGQ46xIpxKb24//qqLq/iEREKK8YZY9ngVvJq8xPtH0gStHEgLtOJ6u/qR1iT C6yTxeL7yVZPMhojb0kKFa6ZGwAWzzGHJAqr72tDqayZJ4wjz50oV/YYzEj4y2/Ktg PlfchJO+9QAmQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id CpbR1t00P1nMCLR01pbSzg; Thu, 30 Jun 2016 01:35:26 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5U1ZPY0003080 for ; Wed, 29 Jun 2016 21:35:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5U1ZOJA003076; Wed, 29 Jun 2016 21:35:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 29 Jun 2016 21:35:24 -0400 Message-ID: <87h9cbcvc3.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 01:35:29 -0000 This thread is to explore "outbound" issues. As I have them, the requirements are: - Clients behind client-side NATs must be fully supported. - The solution should be as compatible with SIP Outbound as practicable. The difficult part of this is "the solution for simple UDP (i.e., not using SIP Outbound)". There is a strong perception that in systems where an edge proxy services 10^5 or 10^6 UAs that only UDP-without-Outbound has a low enough per-flow overhead to be workable. The important requirements for simple UDP seem to be: - The per-UA state in the edge proxy must be no larger than about what is kept for a registration. - The update rate of the per-UA state in the edge proxy must be no larger than about the update rate for a registration. It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet these requirements. A substantial fraction of the UAs tested in the latest SIPit do not support TCP, TLS, or Outbound, showing that there is substantial market presence of simple-UDP-only UAs. It is possible that a "Simple Outbound" can be defined that provides the needed part of the functionality of Outbound at a sufficiently low overhead and complexity that it meets these requirements. If so, it is desirable that it be conceptually and operationally upward-compatible with Outbound. It's clear to me that the problem is *solvable*, because existing SIP systems do handle the client-side NAT problem. E.g., the open-source sipX system has full client-side NAT support. That scheme doesn't require SIP Outbound support in the client at all. NAT support is triggered by the client's requests arriving from an address that is different than what is specified in the request. Support is implemented by manipulating the client's behavior, rewriting requests/responses to substitute IP addresses, and providing (essentially) a TURN server to relay media. As far as I can remember, sipX's NAT support is recorded and implemented in the standard registration/redirect database. However, NAT support does depend on forcing the client to re-register frequently enough to be assured that the NAT mapping is not released. Since processing re-registrations is by far the bulk of the signaling traffic even without NAT support, this is not a trivial change. My expectation is that almost all commercial SIP systems have NAT support of this sort. One difference between this sort of NAT support and Outbound is that NAT support is done only at the registrar/proxy; if there is a separate edge proxy, it only passes UDP messages and can easily be stateless. This might be a significant factor in very large deployments. Perhaps a significant problem with Outbound is that it has to be implemented in both the phone and the switch, leading to a network effect problem. At this point, it seems to me that we need to get a better understanding of what people are doing in the market to deal with NATs and find out why they don't use Outbound. (Since Outbound is the standard method, I would think it has a strategic advantage in the technological competition.) Dale From nobody Thu Jun 30 07:29:19 2016 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 B2A3012D09A for ; Thu, 30 Jun 2016 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 nZ0PiY2aCr2b for ; Thu, 30 Jun 2016 07:29:15 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 A275412B01D for ; Thu, 30 Jun 2016 07:29:15 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id c2so112048724vkg.1 for ; Thu, 30 Jun 2016 07:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vVHdJrT63l67gBgWXyeLP/9lJnBFIolhwqTXURuXRAk=; b=PRg4kvbJEx44TIhBvQeyle1X3qSzAX3IkI1gm0CipYzyBaG8D6ttErJVHUjyd2y5CU QC4H0m3Los+dYGuNgMSHZSTYCaIULGJRCF5eD5/1tZO7438/UvMfx2/BxZX41Bd+OoF9 7FvX6XfBnt5XHXEzkYGdN/PXJbv7mQPwClHJKUVSOoE1zoJHy9eqm3245L1lF+pwOZb/ cTHgnA0kWHAKOOBEHMsqFwfVxgRMENw1DyugPjklnxcbNLmIGkjn5aCumXG+/HhUHhUm DHwMHC5/RXTdnjwnRHZV7za47w44F9IClkw6mKF1LrFvZ1DI3anfUDObLORXFiNynN9I oVlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vVHdJrT63l67gBgWXyeLP/9lJnBFIolhwqTXURuXRAk=; b=ZHtrofw/LHRVmRAnmMYtjLHSrdOTzEbsfMRLS7ITBCg31latDN4XWmYXvYs+XRc3Np 2a/e916Mq9Uc8ti5CkKYspRCGAdjqCBqbTRyIj6NYEiWiybegleqKtT3gCUhh/bFHVXL wB8aDGXGbjBP4aRe79ujIfbAZ/G6nvAsovMdkgoqD9g24Sl/rf5IuvlGSdYXXXkCEqnA 8cO9CaiHrChog6zUKBWzzKkTBLn99ST/ih61cUJqHHENHysuGsFPhigSf9nvG+FIhVoT 1nsTJV531RmN0GmYF/fDdk96Eys3DIqWNX6ZvGwA1K/7pfqAFcrfnbQrdSk/jwCTkzU+ Tcqw== X-Gm-Message-State: ALyK8tL4EjHpV2C3X/UL6i0mzAvxNPtrFMFnXmpWSr+jpf/eavYJ8XFGfhVdBurmP1S60iW2nrVIKAQlCOyOBA== X-Received: by 10.31.56.69 with SMTP id f66mr6651487vka.135.1467296954775; Thu, 30 Jun 2016 07:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 30 Jun 2016 07:29:13 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Thu, 30 Jun 2016 10:29:13 -0400 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1143f0ecc506b805367fb1e7 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:29:18 -0000 --001a1143f0ecc506b805367fb1e7 Content-Type: text/plain; charset=UTF-8 An access token is explicit too; it carries authorization to access some resource/service. I am not sure what you have in mind. Are you suggesting that after the UA/Proxy gets the token from the IdP, that the UA/Proxy would then transform the authorizations given in the token to a SIP caller preference format? Regards, Rifaat On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat wrote: > On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote: > > The semantics of the INVITE method are "hey, remote resource, I'd >> like to set up a session with you involving the following media >> types." The question of whether or not you accept INVITEs, which is >> to my mind the SIP authorization problem, >> >> This is the main difference between how you and I see this. >> I think that the authorization problem is much bigger than just >> authorizing a specific SIP method. The authorization should be dealing >> with *access to services* provided by SIP servers regardless of the SIP >> method being used. >> Much the same way that HTTP authorizes *access to resources*, regardless >> of the HTTP method being used. You do not need a specific token for HTTP >> GET vs HTTP POST, because the method does not matter; what matters is >> the resource that the method is trying to access. >> > > If you want to tell a server something about what you want it to do, you > can use caller preferences. At least then you are being explicit about it. > > That seems more straightforward than embedding similar information into an > authorization token. > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1143f0ecc506b805367fb1e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An access token is explicit too; it carries authorization = to access some resource/service.

I am not sure what you = have in mind.=C2=A0
Are you suggesting that after the UA/Proxy ge= ts the token from the IdP, that the UA/Proxy would then transform the autho= rizations given in the token to a SIP caller preference format?
<= br>
Regards,
=C2=A0Rifaat


=


On Tue, = Jun 28, 2016 at 4:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 6/28/16 5:32 AM, Ri= faat Shekh-Yusef wrote:

=C2=A0 =C2=A0 The semantics of the INVITE method are "hey, remote reso= urce, I'd
=C2=A0 =C2=A0 like to set up a session with you involving the following med= ia
=C2=A0 =C2=A0 types." The question of whether or not you accept INVITE= s, which is
=C2=A0 =C2=A0 to my mind the SIP authorization problem,

This is the main difference between how you and I see this.
I think that the authorization problem is much bigger than just
authorizing a specific SIP method. The authorization should be dealing
<= /span> with *access to services* provided by SIP servers regardless of the SIP
method being used.
Much the same way that HTTP authorizes *access to resources*, regardless
of the HTTP method being used. You do not need a specific token for HTTP GET vs HTTP POST, because the method does not matter; what matters is
the resource that the method is trying to access.

If you want to tell a server something about what you want it to do, you ca= n use caller preferences. At least then you are being explicit about it.
That seems more straightforward than embedding similar information into an = authorization token.

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


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a1143f0ecc506b805367fb1e7-- From nobody Thu Jun 30 07:43:26 2016 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 BD7E412D0EE for ; Thu, 30 Jun 2016 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 pnx-wmBYnnWL for ; Thu, 30 Jun 2016 07:43:23 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 1312212B028 for ; Thu, 30 Jun 2016 07:43:22 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-10v.sys.comcast.net with SMTP id IdBQbsrsvEFCNIdBabI3FH; Thu, 30 Jun 2016 14:43:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467297802; bh=6xCVgZm8eWSlmw1eCO5D14qAO2oors88td8uVQza2vY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LKojoqf5PYcHJLwoBMBgdmc1woH2k7Yp9aH30f60f59Ij9a7FZuyFnJDScaiy+E8T vUyyVSwaOCdwXIls+hcx8xaDHwlRs6xMK8kjvTSy1hcHUgsEFyJ63vc6HZAOKCSMOp Zp3O2KsNrDFhwSIG1r2pPrizSj2nw5+gweOR2o8P6PCzt+Avn1EDawhlAdoW+fo28+ OmpmoBj2HcdlFPk4ViOJmOg0CEGgJTYEZrsheZFeHmItGlWtKjrkM1q+1B5kY8IvtJ F114K/CqT/hTUSsgZf3tVW5SLtXOjrwsZ8wYviopLX2FmgLw5EvZGF8r9KEnJFXY64 zFR21NdPEb0WA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id D2jM1t00W3KdFy1012jN1Z; Thu, 30 Jun 2016 14:43:22 +0000 To: Rifaat Shekh-Yusef References: From: Paul Kyzivat Message-ID: <1a0ef7d8-4fb7-166d-4e9f-25e200eee1e2@alum.mit.edu> Date: Thu, 30 Jun 2016 10:43:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:43:25 -0000 On 6/30/16 10:29 AM, Rifaat Shekh-Yusef wrote: > An access token is explicit too; it carries authorization to access some > resource/service. > > I am not sure what you have in mind. > Are you suggesting that after the UA/Proxy gets the token from the IdP, > that the UA/Proxy would then transform the authorizations given in the > token to a SIP caller preference format? It sounds like you are imagining a situation where the user gets a token that authorizes some specific service(s) without the user knowing what services those are. And then the user makes a request with the token and expects the server to figure out what services to supply. That seems backwards to me. I would expect that the user would figure out what services he wants, then get some credentials that are sufficient to authorize the service, and then request the service and supply the credentials to cover it. It may be that the credentials he has are broad enough to cover lots of services. He doesn't want them all, he wants what he wants at the time of invocation. So callerprefs provides a mechanism to express what features you want from a callee. To that you then need to supply credentials, in this case in the form of an authorization token. Thanks, Paul > Regards, > Rifaat > > > > > On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat > wrote: > > On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote: > > The semantics of the INVITE method are "hey, remote > resource, I'd > like to set up a session with you involving the following media > types." The question of whether or not you accept INVITEs, > which is > to my mind the SIP authorization problem, > > This is the main difference between how you and I see this. > I think that the authorization problem is much bigger than just > authorizing a specific SIP method. The authorization should be > dealing > with *access to services* provided by SIP servers regardless of > the SIP > method being used. > Much the same way that HTTP authorizes *access to resources*, > regardless > of the HTTP method being used. You do not need a specific token > for HTTP > GET vs HTTP POST, because the method does not matter; what > matters is > the resource that the method is trying to access. > > > If you want to tell a server something about what you want it to do, > you can use caller preferences. At least then you are being explicit > about it. > > That seems more straightforward than embedding similar information > into an authorization token. > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From nobody Thu Jun 30 10:02:37 2016 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 3BD6712DB14 for ; Thu, 30 Jun 2016 10:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 w7EyohDwON14 for ; Thu, 30 Jun 2016 10:02:33 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 B23B312D885 for ; Thu, 30 Jun 2016 10:02:32 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id m127so58929911vkb.3 for ; Thu, 30 Jun 2016 10:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4LBlNHyya4gRsaDSHl4Dj2tiqM5bVCZlmZCKMIZl9OI=; b=UTTZVmMG1ZI6cwvn6SMMOinQsRNXLVqQFGu4V9kzCGEDqQZVCa9HrzBbe0On2bvgn+ Wt+hLbIsRhLZlQMZaTyeZzZRUEumTdmUjaTSo89elo/W8V3tITjTK6c8HQ9RDZhpB/+c Z2oUjSx9gK2/kGTFljGDarPR2Jim7cv5LGXgHWy6dW6mVm5RW6dQvrwAoZlNkeNB/dRX 1ZxRGaWsozbY/0JigbyxtqbQKuKzYl7TueisW1Fh26NDnCXuPT0Fw/buxdrfluUi0StB +E8TLoUnRtWlQ498g67tSjXjNtF4rAlA3K9C7k/RpOhc1KRNl0R99AtiM5FYYaTIS8VF lFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4LBlNHyya4gRsaDSHl4Dj2tiqM5bVCZlmZCKMIZl9OI=; b=R954zKlcB6tPONMREegdQq5P50PvXLmI5w+BD/yPvEszXqL9hHtC2/2kE8b37hkooP lmX9Ht+Z5ZN+fkgwxqCjmYjzL6XNZjEal6aMAKFKQagYjn+xeoKe4RyWvG8E9mBdmcRb jdk0qI0mNvjC1PzF8NnE16VqSLAMQyGITChq21+98yOPfPeL8WcwIqoUGDD3D4crQM5/ tFySCara/jXMl41sk4ODwhn84ERxcGN5QCYH3/X5JThlqmG5AqRv6tVqAo1jjXB6fPB3 p4RTTpIaci5i4s6vdwIYeVKKrQfY0yFfH9r5dQa5wOzmguvJKwgYg4eikW13fX/6h1e5 SZbA== X-Gm-Message-State: ALyK8tIkkiwjaBPi3d6jJ1EVUjgYkTuDFZeSEJu0MzXhNGVJtvGHEaPo9jmuZfdiFM53f4c2b9lJ9TBrL+Z3Mg== X-Received: by 10.159.37.245 with SMTP id 108mr1874556uaf.66.1467306151835; Thu, 30 Jun 2016 10:02:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.174 with HTTP; Thu, 30 Jun 2016 10:02:29 -0700 (PDT) In-Reply-To: <1a0ef7d8-4fb7-166d-4e9f-25e200eee1e2@alum.mit.edu> References: <1a0ef7d8-4fb7-166d-4e9f-25e200eee1e2@alum.mit.edu> From: Rifaat Shekh-Yusef Date: Thu, 30 Jun 2016 13:02:29 -0400 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113ad63cf4fde2053681d5c2 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:02:35 -0000 --001a113ad63cf4fde2053681d5c2 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 30, 2016 at 10:43 AM, Paul Kyzivat wrote: > On 6/30/16 10:29 AM, Rifaat Shekh-Yusef wrote: > >> An access token is explicit too; it carries authorization to access some >> resource/service. >> >> I am not sure what you have in mind. >> Are you suggesting that after the UA/Proxy gets the token from the IdP, >> that the UA/Proxy would then transform the authorizations given in the >> token to a SIP caller preference format? >> > > It sounds like you are imagining a situation where the user gets a token > that authorizes some specific service(s) without the user knowing what > services those are. No, that is not what I am proposing. The user in the conference example will have to explicitly ask for a specific conference type, e.g. video conference. There are different ways of obtaining a token with the right authorization needed for a specific service. > And then the user makes a request with the token and expects the server to > figure out what services to supply. > Yes, the server providing the service will be able to validate the token, which explicitly states requested service (e.g. video conference with a maximum of 5 participants) , and then provide the service accordingly. > > That seems backwards to me. I would expect that the user would figure out > what services he wants, then get some credentials that are sufficient to > authorize the service, and then request the service and supply the > credentials to cover it. > > It may be that the credentials he has are broad enough to cover lots of > services. He doesn't want them all, he wants what he wants at the time of > invocation. > > So callerprefs provides a mechanism to express what features you want from > a callee. To that you then need to supply credentials, in this case in the > form of an authorization token. > Well, if we are sending an authorization token anyway, why would we separate the token from the authorizations? Regards, Rifaat > > Thanks, > Paul > > Regards, >> Rifaat >> >> >> >> >> On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat > > wrote: >> >> On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote: >> >> The semantics of the INVITE method are "hey, remote >> resource, I'd >> like to set up a session with you involving the following >> media >> types." The question of whether or not you accept INVITEs, >> which is >> to my mind the SIP authorization problem, >> >> This is the main difference between how you and I see this. >> I think that the authorization problem is much bigger than just >> authorizing a specific SIP method. The authorization should be >> dealing >> with *access to services* provided by SIP servers regardless of >> the SIP >> method being used. >> Much the same way that HTTP authorizes *access to resources*, >> regardless >> of the HTTP method being used. You do not need a specific token >> for HTTP >> GET vs HTTP POST, because the method does not matter; what >> matters is >> the resource that the method is trying to access. >> >> >> If you want to tell a server something about what you want it to do, >> you can use caller preferences. At least then you are being explicit >> about it. >> >> That seems more straightforward than embedding similar information >> into an authorization token. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > --001a113ad63cf4fde2053681d5c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 30, 2016 at 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 6/30/16 10:29 AM, Ri= faat Shekh-Yusef wrote:
An access token is explicit too; it carries authorization to access some resource/service.

I am not sure what you have in mind.
Are you suggesting that after the UA/Proxy gets the token from the IdP,
that the UA/Proxy would then transform the authorizations given in the
token to a SIP caller preference format?

 It sounds like you are imagining a situation where the user gets a token th= at authorizes some specific service(s) without the user knowing what servic= es those are.

No, that is not what I am pr= oposing.=C2=A0
The user in the conference example will have to ex= plicitly ask for a specific conference type, e.g. video conference.
There are different ways of obtaining a token with the right authorizati= on needed for a specific service.

=C2=A0
=
And then the user makes a request with the token and expec= ts the server to figure out what services to supply.
<= br>
Yes, the server providing the service will be able to validat= e the token, which explicitly states requested service (e.g. video conferen= ce with a maximum of 5 participants) , and then provide the service accordi= ngly.

=C2=A0

That seems backwards to me. I would expect that the user would figure out w= hat services he wants, then get some credentials that are sufficient to aut= horize the service, and then request the service and supply the credentials= to cover it.

It may be that the credentials he has are broad enough to cover lots of ser= vices. He doesn't want them all, he wants what he wants at the time of = invocation.

So callerprefs provides a mechanism to express what features you want from = a callee. To that you then need to supply credentials, in this case in the = form of an authorization token.

Well, i= f we are sending an authorization token anyway, why would we separate the t= oken from the authorizations?

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=A0Rifaat




On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
=
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The semantics of the INVITE metho= d are "hey, remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 resource, I'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 like to set up a session with you= involving the following media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 types." The question of whet= her or not you accept INVITEs,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to my mind the SIP authorization = problem,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the main difference between how you and= I see this.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think that the authorization problem is much = bigger than just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorizing a specific SIP method. The authoriz= ation should be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dealing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with *access to services* provided by SIP serve= rs regardless of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the SIP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 method being used.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Much the same way that HTTP authorizes *access = to resources*,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regardless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the HTTP method being used. You do not need = a specific token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for HTTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 GET vs HTTP POST, because the method does not m= atter; what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 matters is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the resource that the method is trying to acces= s.


=C2=A0 =C2=A0 If you want to tell a server something about what you want it= to do,
=C2=A0 =C2=A0 you can use caller preferences. At least then you are being e= xplicit
=C2=A0 =C2=A0 about it.

=C2=A0 =C2=A0 That seems more straightforward than embedding similar inform= ation
=C2=A0 =C2=A0 into an authorization token.

=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 Paul


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 sipcore mailing list
=C2=A0 =C2=A0 sipcore= @ietf.org <mailto:sipcore@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/sip= core




--001a113ad63cf4fde2053681d5c2-- From nobody Thu Jun 30 10:24:23 2016 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 9BD7B12B01F for ; Thu, 30 Jun 2016 10:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 p97fd6A8tqEA for ; Thu, 30 Jun 2016 10:24:19 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 87A9912B015 for ; Thu, 30 Jun 2016 10:24:19 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with SMTP id Ifexb0uDj8RcDIfhKbeIMr; Thu, 30 Jun 2016 17:24:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467307458; bh=MiV5CzrD5Tthd9k87zJO9B6p0sNQFyqiqHmnxsVOZ+E=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kmZ/njKqjtC4TOC0j49Ng6D6+w8cNGizZcNEcyo6WUCwHkGn7Y5DpSxDNp3UToyM0 89R6y4McZ6MtrqYLk0ANCDf583fj3LdfcCOcbynIjyhpAWnHxBuUlSA0dOv2WCmGk+ MSW65ymlc/SgGwhLDkIVhvKu+fitBnpQzb6zjMcBrj43P6qy3ijjr7StP//sY5vw5m rzlTp0FYUNRsdf3JE+pcFH+f80BufZmQ26PaXdbb6nC2/c81PMYV3Uojbw8R9QDrCS 6dS9DZq3DxvdZk71xXt62LJp48ElpYO7f6F9wrT9t1LAyV9i+Pxq6ikIJ43ZvvnzKF kE/z0Sn6iG4mw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id D5QH1t00i3KdFy1015QHEU; Thu, 30 Jun 2016 17:24:18 +0000 To: Rifaat Shekh-Yusef References: <1a0ef7d8-4fb7-166d-4e9f-25e200eee1e2@alum.mit.edu> From: Paul Kyzivat Message-ID: <9e48ec18-3daa-df94-0ed0-f119f874a605@alum.mit.edu> Date: Thu, 30 Jun 2016 13:24:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:24:21 -0000 Comment at end On 6/30/16 1:02 PM, Rifaat Shekh-Yusef wrote: > > On Thu, Jun 30, 2016 at 10:43 AM, Paul Kyzivat > wrote: > > On 6/30/16 10:29 AM, Rifaat Shekh-Yusef wrote: > > An access token is explicit too; it carries authorization to > access some > resource/service. > > I am not sure what you have in mind. > Are you suggesting that after the UA/Proxy gets the token from > the IdP, > that the UA/Proxy would then transform the authorizations given > in the > token to a SIP caller preference format? > > It sounds like you are imagining a situation where the user gets a > token that authorizes some specific service(s) without the user > knowing what services those are. > > No, that is not what I am proposing. > The user in the conference example will have to explicitly ask for a > specific conference type, e.g. video conference. > There are different ways of obtaining a token with the right > authorization needed for a specific service. > > And then the user makes a request with the token and expects the > server to figure out what services to supply. > > Yes, the server providing the service will be able to validate the > token, which explicitly states requested service (e.g. video conference > with a maximum of 5 participants) , and then provide the service > accordingly. > > That seems backwards to me. I would expect that the user would > figure out what services he wants, then get some credentials that > are sufficient to authorize the service, and then request the > service and supply the credentials to cover it. > > It may be that the credentials he has are broad enough to cover lots > of services. He doesn't want them all, he wants what he wants at the > time of invocation. > > So callerprefs provides a mechanism to express what features you > want from a callee. To that you then need to supply credentials, in > this case in the form of an authorization token. > > Well, if we are sending an authorization token anyway, why would we > separate the token from the authorizations? 1) Separation of responsibility. 2) What you are suggesting would require authorization servers to have the means to dice up authorizations into whatever granularity a user wants to request services. Suppose some systems don't do that. They simply grant you access to a conference server that can do all sorts of conferences. But you still want to decide whether to have an audio-only conference or an audio/video conference. Now you need a different way to request that. Thanks, Paul From nobody Thu Jun 30 13:03:16 2016 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 66DA912D122 for ; Thu, 30 Jun 2016 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.925 X-Spam-Level: X-Spam-Status: No, score=-100.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=1.675, USER_IN_WHITELIST=-100] autolearn=no 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 9VB0lgDqSpDb for ; Thu, 30 Jun 2016 13:03:12 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 B0D7312D0BB for ; Thu, 30 Jun 2016 13:03:12 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5UK2P7J009423; Thu, 30 Jun 2016 16:03:11 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23w9yvr0kr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jun 2016 16:03:11 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 30 Jun 2016 16:03:10 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAF/VngIAF7xoAgAGiQYD//8wQAIAB3CEA///zYgCAAYUpAIAIFXSAgAFN74CAAC7vAIABf0UAgAFhuICABilFgIADX4uA Date: Thu, 30 Jun 2016 20:03:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.123] Content-Type: multipart/alternative; boundary="_000_D39AC0E11A3271jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606300188 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 20:03:14 -0000 --_000_D39AC0E11A3271jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But even if we assume a more open environment where the user agent can send= INVITEs directly to the conference bridge, all the conference bridge needs= is a signature or similar token that indicates the IdP's approval, -not- a= ny specific attribute. Of course attributes are needed. How would otherwise the conference server know which type of conference to = start (audio, video, etc)? what is the limitation on the number of particip= ant? etc... This is exactly what my "deeper level of complexity" in a previous mail pul= led apart. You need to differentiate a) what kind of conference the user wa= nts from b) what kind of conference the IdP is willing to authorize. Your = token is just an indication of what the IdP is willing to authorize, and if= that is a superset of what the user wants, then the IdP will issue a token= . If it is a subset, then it won't. So how does the conference server know which type of conference to start? W= ell, again, you've focused this discussion on the corner case of an ad hoc = RFC4579 conference, in the ad hoc case the conference bridge has to infer t= hat from the type of session that the user agent creates with the conferenc= e bridge with its initial INVITE. It's not really a very good assumption, t= hough, which is why we quickly run into trouble when we start trying to und= erstand this corner case. However, I think it would be safe to say that for= this ad hoc case, if the IdP was willing to issue an authorization token, = then it authorizes the media type(s) that the user specified in their INVIT= E - and thus that attributes in the token to express what media types the = IdP allowed would be at best redundant. But to be clear, a token that conveys what the IdP is willing to authorize = does not serve the same purpose as a SIP means for a user agent to convey t= o a conference bridge what kind of conference it would like to have - nor a= s a means for a user agent to communicate to an IdP what kind of conference= it intends to propose. Paul is mentioning mechanisms like caller prefs her= e because it would be new work, through some SIP mechanism along those line= s, to convey that information with SIP. Outside of this corner case, though, the conference URI is acquired in an o= ut-of-band fashion at the same time as conference policy is set - surely th= rough HTTP, surely through a web interface, and that's where all the OAuth = goodness can (and should) play into conference policy management. Trying to= inflate this one ad hoc corner case into a murky argument that SIP needs O= Auth is and has this whole time been a stretch. RFC4353 already says confer= ence policy management is not a SIP function. I'm not particularly interest= ed in working on overriding that, since it Is obviously solved by just usin= g HTTP, without any new work on our part. The semantics of the INVITE method are "hey, remote resource, I'd like to s= et up a session with you involving the following media types." The question= of whether or not you accept INVITEs, which is to my mind the SIP authoriz= ation problem, This is the main difference between how you and I see this. I think that the authorization problem is much bigger than just authorizing= a specific SIP method. The authorization should be dealing with access to = services provided by SIP servers regardless of the SIP method being used. Our real disconnect I think is the degree to which you think SIP offers "se= rvices" or that application control is inside the scope of SIP. It's not. S= IP is a protocol that allows Internet endpoints to discover one another and= to agree on the character of a session they'd like to share, according to = RFC3261. If I may quote from Section 2 of that document "SIP does not offe= r conference control services" and indeed "SIP does not provide services." = The only thing SIP has to do with conference services is that "SIP can be = used to initiate a session that uses some other conference control protocol= ", look ahead to BFCP, and of course that SIP user agents can initiate sess= ions with conference bridges. Much the same way that HTTP authorizes access to resources, regardless of t= he HTTP method being used. You do not need a specific token for HTTP GET vs= HTTP POST, because the method does not matter; what matters is the resourc= e that the method is trying to access. Accessing and changing resources on the Internet is in the scope of HTTP, w= hich is why HTTP should be used for the purposes you have in mind here. Yes= , in addition to initiating sessions, SIP has a number of methods that let = it convey data, such as INFO, MESSAGE, NOTIFY and so on, and in some use ca= ses, they can similarly provide access to resources. Maybe there's a SIP au= thorization problem for those methods that we could find. But for the most = part, the SIP authorization problem should be aligned with the purpose of S= IP - it should be about deciding whether or not to accept session initiatio= n attempts. That's a problem I'd be willing to work on. Jon Peterson Neustar, Inc. Regards, Rifaat --_000_D39AC0E11A3271jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <899E88441CB5D84F9D870AD3A0BDDF63@neustar.biz> Content-Transfer-Encoding: quoted-printable


 
But even if we assume a more open environment where the user agent can= send INVITEs directly to the conference bridge, all the conference bridge = needs is a signature or similar token that indicates the IdP's approval, -n= ot- any specific attribute.

Of course attributes are needed. 
How would otherwise the conference server know which type of conferenc= e to start (audio, video, etc)? what is the limitation on the number of par= ticipant? etc...

This is exactly what my "deeper level of complexity" in a pr= evious mail pulled apart. You need to differentiate a) what kind of confere= nce the user wants from b) what kind of conference the IdP is willing to au= thorize.  Your token is just an indication of what the IdP is willing to authorize, and if that is a superset of what= the user wants, then the IdP will issue a token. If it is a subset, then i= t won't.

So how does the conference server know which type of conference to sta= rt? Well, again, you've focused this discussion on the corner case of an ad= hoc RFC4579 conference, in the ad hoc case the conference bridge has to in= fer that from the type of session that the user agent creates with the conference bridge with its initial IN= VITE. It's not really a very good assumption, though, which is why we quick= ly run into trouble when we start trying to understand this corner case. Ho= wever, I think it would be safe to say that for this ad hoc case, if the IdP was willing to issue an autho= rization token, then it authorizes the media type(s) that the user specifie= d in their INVITE -  and thus that attributes in the token to express = what media types the IdP allowed would be at best redundant.

But to be clear, a token that conveys what the IdP is willing to autho= rize does not serve the same purpose as a SIP means for a user agent to con= vey to a conference bridge what kind of conference it would like to have - = nor as a means for a user agent to communicate to an IdP what kind of conference it intends to propose. Pa= ul is mentioning mechanisms like caller prefs here because it would be new = work, through some SIP mechanism along those lines, to convey that informat= ion with SIP.

Outside of this corner case, though, the conference URI is acquired in= an out-of-band fashion at the same time as conference policy is set - sure= ly through HTTP, surely through a web interface, and that's where all the O= Auth goodness can (and should) play into conference policy management. Trying to inflate this one ad hoc corne= r case into a murky argument that SIP needs OAuth is and has this whole tim= e been a stretch. RFC4353 already says conference policy management is not = a SIP function. I'm not particularly interested in working on overriding that, since it Is obviously solved by = just using HTTP, without any new work on our part.


The semantics of the INVITE method are "hey, remote resource, I'd= like to set up a session with you involving the following media types.&quo= t; The question of whether or not you accept INVITEs, which is to my mind t= he SIP authorization problem,

This is the main difference between how you and I see this.
I think that the authorization problem is much bigger than just author= izing a specific SIP method. The authorization should be dealing with access to services provided by SIP servers regardless of the SIP met= hod being used.

Our real disconnect I think is the degree to which you think SIP offer= s "services" or that application control is inside the scope of S= IP. It's not. SIP is a protocol that allows Internet endpoints to discover = one another and to agree on the character of a session they'd like to share, according to RFC3261. If I may quote fr= om Section 2  of that document "SIP does not offer conference con= trol services" and indeed "SIP does not provide services." &= nbsp;The only thing SIP has to do with conference services is that "SIP can be used to initiate a session that uses some other conf= erence control protocol", look ahead to BFCP, and of course that SIP u= ser agents can initiate sessions with conference bridges.

Much the same way that HTTP authorizes access to resources, reg= ardless of the HTTP method being used. You do not need a specific token for= HTTP GET vs HTTP POST, because the method does not matter; what matters is= the resource that the method is trying to access.

Accessing and changing resources on the Internet is in the scope of HT= TP, which is why HTTP should be used for the purposes you have in mind here= . Yes, in addition to initiating sessions, SIP has a number of methods that= let it convey data, such as INFO, MESSAGE, NOTIFY and so on, and in some use cases, they can similarly provi= de access to resources. Maybe there's a SIP authorization problem for those= methods that we could find. But for the most part, the SIP authorization p= roblem should be aligned with the purpose of SIP - it should be about deciding whether or not to accept sess= ion initiation attempts. That's a problem I'd be willing to work on.

Jon Peterson
Neustar, Inc.


Regards,
 Rifaat

 --_000_D39AC0E11A3271jonpetersonneustarbiz_-- From nobody Thu Jun 30 15:42:38 2016 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 C592B12B019 for ; Thu, 30 Jun 2016 15:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 DugOAgamVOAh for ; Thu, 30 Jun 2016 15:42:35 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 E237D12B02B for ; Thu, 30 Jun 2016 15:42:34 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id g127so3982722ith.0 for ; Thu, 30 Jun 2016 15:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TBrvVX7Tm+75BlIUkxnihtvH6Ep5QpdcbiBNUjxRCE0=; b=zmxrjJtIrba3OLrXjlDehDrV6oICr/MGJXxR6Zp67dUwVRp8hXQxyWr1tII2CohuHJ 8H8dC8/h/UElEyks1rvWqszEtoAdujVQhYETy1RJjhjHKUtHbUeji0khl7JnOF4nZRQe IAD7+03kUi7yNJEtnOV4Id3nb6VSjp90LaBqCkH9f33rShlwcFru/BQC4KY/ye7BZtKo ujxA4D1Br60GWXwiD/rKBWg+9A8pJeUmxSfiXjlS4BKuDDar+tcAlxHqaRDsAafiQ4iH RvY/dw910jfca3UEuwgYcxGQHYJQfpWwO9o4Ck5ghS2hZ1b6cyVECjDFebbZTcL69Mjb Zx1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TBrvVX7Tm+75BlIUkxnihtvH6Ep5QpdcbiBNUjxRCE0=; b=G8jlJQL68niGQYWwbmRDd50v5LbmK7IlttgxjajLzabSmaT3pIxJYNSwwT0uOUO2CW I6gbsT94nex23985DzyiFW3QcIlG0/0GLYUF/wU6PGZkH47EcoGwPMEO8w6ppFuSZ2Ny /Bxc6qworLCruWamPPETSq+XiBdWozwKHicDwZAgwW4qryMKcPE5T51JO5VWCem5n3yS mLNxi9dCaqfbltvkede6H0AlqfjyhhzHTqPObLtkc0wOlFvRcIEikzerXJubjuGtdYhh IYXchggabk2zzXIBQRHqtcxPH7REIlSxF2yNEMb73/okuABXSfsNOPwx5R4Ds4Mp/uS4 yIwQ== X-Gm-Message-State: ALyK8tLCmV59g/JoBMUkmU5pJX0RAWsJLZnxa5M9ito81PO1dhpFRaVCVcnxVlwkTyFPmQ== X-Received: by 10.36.57.70 with SMTP id l67mr17705647ita.22.1467326554042; Thu, 30 Jun 2016 15:42:34 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id j37sm4878939iod.4.2016.06.30.15.42.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 15:42:33 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id s63so85534049ioi.3 for ; Thu, 30 Jun 2016 15:42:33 -0700 (PDT) X-Received: by 10.107.147.86 with SMTP id v83mr16905504iod.3.1467326553164; Thu, 30 Jun 2016 15:42:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Thu, 30 Jun 2016 15:42:32 -0700 (PDT) In-Reply-To: <87h9cbcvc3.fsf@hobgoblin.ariadne.com> References: <87h9cbcvc3.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Thu, 30 Jun 2016 18:42:32 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=94eb2c05665cf893ee0536869548 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs: Outbounde X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 22:42:38 -0000 --94eb2c05665cf893ee0536869548 Content-Type: text/plain; charset=UTF-8 Few observations: 1. There is a significant number of end points, such as Polycom phones, that do support SIP outbound. 2. The most efficient way for the client to keep the NAT hole open is to send STUN based keep alive messages. They are widely supported. For instance OpenSIPS supports via Stun Module. 3. For server, the most efficient way to keep the NAT hole open is to send OPTIONS or NOTIFY requests to the client. This is much more efficient then registrations with small timeouts. 4. Registration server which has an in-memory database for current registrations can be fairly efficient in reducing number of back-end DB updates due to registrations and subscriptions with small timeouts. It is not going to be stateless, but its state does not need to be replicated and would automatically recover on the stand-by server on the next registration or subscription request from the client. 5. One of the big problems with encrypted SIP traffic is that it gets modified by ALG. For a lot of hosted PBX providers avoiding the need to troubleshoot customer routers is a bigger incentive to deploy TLS then user privacy. Regards, _____________ Roman Shpount On Wed, Jun 29, 2016 at 9:35 PM, Dale R. Worley wrote: > This thread is to explore "outbound" issues. As I have them, the > requirements are: > > - Clients behind client-side NATs must be fully supported. > > - The solution should be as compatible with SIP Outbound as > practicable. > > The difficult part of this is "the solution for simple UDP (i.e., not > using SIP Outbound)". There is a strong perception that in systems > where an edge proxy services 10^5 or 10^6 UAs that only > UDP-without-Outbound has a low enough per-flow overhead to be > workable. The important requirements for simple UDP seem to be: > > - The per-UA state in the edge proxy must be no larger than about what > is kept for a registration. > > - The update rate of the per-UA state in the edge proxy must be no > larger than about the update rate for a registration. > > It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet > these requirements. A substantial fraction of the UAs tested in the > latest SIPit do not support TCP, TLS, or Outbound, showing that there > is substantial market presence of simple-UDP-only UAs. > > It is possible that a "Simple Outbound" can be defined that provides > the needed part of the functionality of Outbound at a sufficiently low > overhead and complexity that it meets these requirements. If so, it > is desirable that it be conceptually and operationally > upward-compatible with Outbound. > > It's clear to me that the problem is *solvable*, because existing SIP > systems do handle the client-side NAT problem. E.g., the open-source > sipX system has full client-side NAT support. That scheme doesn't > require SIP Outbound support in the client at all. NAT support is > triggered by the client's requests arriving from an address that is > different than what is specified in the request. Support is > implemented by manipulating the client's behavior, rewriting > requests/responses to substitute IP addresses, and providing > (essentially) a TURN server to relay media. > > As far as I can remember, sipX's NAT support is recorded and > implemented in the standard registration/redirect database. However, > NAT support does depend on forcing the client to re-register > frequently enough to be assured that the NAT mapping is not released. > Since processing re-registrations is by far the bulk of the signaling > traffic even without NAT support, this is not a trivial change. > > My expectation is that almost all commercial SIP systems have NAT > support of this sort. > > One difference between this sort of NAT support and Outbound is that > NAT support is done only at the registrar/proxy; if there is a > separate edge proxy, it only passes UDP messages and can easily be > stateless. This might be a significant factor in very large > deployments. > > Perhaps a significant problem with Outbound is that it has to be > implemented in both the phone and the switch, leading to a network > effect problem. > > At this point, it seems to me that we need to get a better > understanding of what people are doing in the market to deal with NATs > and find out why they don't use Outbound. (Since Outbound is the > standard method, I would think it has a strategic advantage in the > technological competition.) > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --94eb2c05665cf893ee0536869548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Few observations:

1. There is a s= ignificant number of end points, such as Polycom phones, that do support SI= P outbound.

2. The most efficient way for the client to keep t= he NAT hole open is to send STUN based keep alive messages. They are widely= supported. For instance OpenSIPS supports via Stun Module.

3. For server, the most efficient way to keep the NAT hole = open is to send OPTIONS or NOTIFY requests to the client. This is much more= efficient then registrations with small timeouts.

4. Registration server which has an in-memory database for current registr= ations can be fairly efficient in reducing number of back-end DB updates du= e to registrations and subscriptions with small timeouts. It is not going t= o be stateless, but its state does not need to be replicated and would auto= matically recover on the stand-by server on the next registration or subscr= iption request from the client.

5. One of the big = problems with encrypted SIP traffic is that it gets modified by ALG. For a = lot of hosted PBX providers avoiding the need to troubleshoot customer rout= ers is a bigger incentive to deploy TLS then user privacy.

Regards,=C2=A0

_____________
Roman Shpount

On Wed, Jun 29, 2016 at 9:35 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
This thread is to explore "outbound" issues.=C2=A0 As I ha= ve them, the
requirements are:

=C2=A0 =C2=A0 - Clients behind client-side NATs must be fully supported.
=C2=A0 =C2=A0 - The solution should be as compatible with SIP Outbound as p= racticable.

=C2=A0 =C2=A0 The difficult part of this is "the solution for simple U= DP (i.e., not
=C2=A0 =C2=A0 using SIP Outbound)".=C2=A0 There is a strong perception= that in systems
=C2=A0 =C2=A0 where an edge proxy services 10^5 or 10^6 UAs that only
=C2=A0 =C2=A0 UDP-without-Outbound has a low enough per-flow overhead to be=
=C2=A0 =C2=A0 workable.=C2=A0 The important requirements for simple UDP see= m to be:

=C2=A0 =C2=A0 - The per-UA state in the edge proxy must be no larger than a= bout what
=C2=A0 =C2=A0 =C2=A0 is kept for a registration.

=C2=A0 =C2=A0 - The update rate of the per-UA state in the edge proxy must = be no
=C2=A0 =C2=A0 =C2=A0 larger than about the update rate for a registration.<= br>
=C2=A0 =C2=A0 It is perceived that TCP, TLS, and even UDP-with-Outbound do = not meet
=C2=A0 =C2=A0 these requirements.=C2=A0 A substantial fraction of the UAs t= ested in the
=C2=A0 =C2=A0 latest SIPit do not support TCP, TLS, or Outbound, showing th= at there
=C2=A0 =C2=A0 is substantial market presence of simple-UDP-only UAs.

=C2=A0 =C2=A0 It is possible that a "Simple Outbound" can be defi= ned that provides
=C2=A0 =C2=A0 the needed part of the functionality of Outbound at a suffici= ently low
=C2=A0 =C2=A0 overhead and complexity that it meets these requirements.=C2= =A0 If so, it
=C2=A0 =C2=A0 is desirable that it be conceptually and operationally
=C2=A0 =C2=A0 upward-compatible with Outbound.

It's clear to me that the problem is *solvable*, because existing SIP systems do handle the client-side NAT problem.=C2=A0 E.g., the open-source<= br> sipX system has full client-side NAT support.=C2=A0 That scheme doesn't=
require SIP Outbound support in the client at all.=C2=A0 NAT support is
triggered by the client's requests arriving from an address that is
different than what is specified in the request.=C2=A0 Support is
implemented by manipulating the client's behavior, rewriting
requests/responses to substitute IP addresses, and providing
(essentially) a TURN server to relay media.

As far as I can remember, sipX's NAT support is recorded and
implemented in the standard registration/redirect database.=C2=A0 However,<= br> NAT support does depend on forcing the client to re-register
frequently enough to be assured that the NAT mapping is not released.
Since processing re-registrations is by far the bulk of the signaling
traffic even without NAT support, this is not a trivial change.

My expectation is that almost all commercial SIP systems have NAT
support of this sort.

One difference between this sort of NAT support and Outbound is that
NAT support is done only at the registrar/proxy; if there is a
separate edge proxy, it only passes UDP messages and can easily be
stateless.=C2=A0 This might be a significant factor in very large
deployments.

Perhaps a significant problem with Outbound is that it has to be
implemented in both the phone and the switch, leading to a network
effect problem.

At this point, it seems to me that we need to get a better
understanding of what people are doing in the market to deal with NATs
and find out why they don't use Outbound.=C2=A0 (Since Outbound is the<= br> standard method, I would think it has a strategic advantage in the
technological competition.)

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--94eb2c05665cf893ee0536869548--