From nobody Fri Apr 1 06:56: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 EC1C112D5EA for ; Fri, 1 Apr 2016 06:56:54 -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 znD1B0oPCc4d for ; Fri, 1 Apr 2016 06:56:53 -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 623EA12D5C3 for ; Fri, 1 Apr 2016 06:56:46 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by comcast with SMTP id lzX8ahsWs2R4wlzZ7aMUtn; Fri, 01 Apr 2016 13:56:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459519005; bh=G8SRmlo68bXzwwvtP9YIfN3yWdECefnUCvjgS3P4rSQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ws//tSArko9u2eL2b2of3jAm9z8IBS1L1V7n/iNm3F4tJ9CK5sxFH6qHrdZ7V/wb2 OP7QaXQRVF2UIiL6WebWPbRv8jDpI394ZhdSqx23wWgHLgyfWh1PruxxEWG/8aqnlW WdhHJ843OHHqsUbRqK6gBqJyncYZdlVfK0g2+x/5ruBn5jIAD6TzStQ2myi3SLMe5s +Sbbf0BPXjfXPhnY3HGlDyzQddL91/ZqMzQ5Cpvt1PEY3dxKE+0sQR1HkVrbh3tmxz nziAx/JSa2enUQmJiHt0SQ4/+bh6gzi23eIn1X/BzMkIBNEtdEpRXU6Kjs4sow2Mrb CjcjKzP7HKRmQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id d1wl1s0083KdFy1011wlWr; Fri, 01 Apr 2016 13:56:45 +0000 To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> From: Paul Kyzivat Message-ID: <56FE7E1C.50304@alum.mit.edu> Date: Fri, 1 Apr 2016 09:56:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FD9FF7.7020207@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... 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, 01 Apr 2016 13:56:55 -0000 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. 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 > From nobody Sat Apr 2 06:02:43 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 8D09912D77F for ; Sat, 2 Apr 2016 06:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 4amxp1P_JLrq for ; Sat, 2 Apr 2016 06:02:40 -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 B47B812D126 for ; Sat, 2 Apr 2016 06:02:40 -0700 (PDT) Received: from dhcp-b103.meeting.ietf.org (dhcp-b103.meeting.ietf.org [31.133.177.3]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u32D2cdu005786 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Sat, 2 Apr 2016 08:02:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> <56FD9FF7.7020207@nostrum.com> <56FE7E1C.50304@alum.mit.edu> From: Robert Sparks Message-ID: <56FFC2ED.5030509@nostrum.com> Date: Sat, 2 Apr 2016 10:02:37 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FE7E1C.50304@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... 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, 02 Apr 2016 13:02:42 -0000 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 From nobody Wed Apr 6 12:52: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 2582912D7D5 for ; Wed, 6 Apr 2016 12:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 TbIDrCVaL4kr for ; Wed, 6 Apr 2016 12:52:47 -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 9187212D7CD for ; Wed, 6 Apr 2016 12:52:47 -0700 (PDT) Received: from dhcp-8915.meeting.ietf.org ([IPv6:2001:67c:370:136:3d2d:f8bb:3908:413c]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u36JqhqM078021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 6 Apr 2016 14:52:47 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:3d2d:f8bb:3908:413c] claimed to be dhcp-8915.meeting.ietf.org From: "A. Jean Mahoney" To: sipcore@ietf.org References: <56F01C7F.5000507@nostrum.com> Message-ID: <57056907.50804@nostrum.com> Date: Wed, 6 Apr 2016 16:52:39 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56F01C7F.5000507@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack 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, 06 Apr 2016 19:52:49 -0000 [as individual] As pointed out by others, section 5 needs to be clarified, and an example would be helpful. Feedback from ID Nits: - Since this draft directly quotes 3263, the authors of 3263 should be contacted about granting BCP78 rights, if you have not already done so. - Remove the 'RFC' label in the 'Updates: ' line. - Remove the mention of RFC 3484, which is is obsolete. Just point to 6724. Other nits: - Section 1 and 4.1 Add a space between "RFC 3263[RFC3263]" - Since there's only a few uses of "RR", just use "record" instead. Thanks! Jean On 3/21/16 1:08 PM, Adam Roach wrote: > [as chair] > > Today marks the start of a three-week Working Group Last Call for the > following document: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ > > The end of this last call is specifically intended to end on the Friday > of the upcoming face-to-face meeting in Buenos Aires. Our plan is to ask > the authors to incorporate any feedback received during these final > weeks as well as comments from the face-to-face meeting into a version > of the document that will be ready to send to the IESG. > > All Working Group participants are requested to review the document and > send comments to the SIPCORE mailing list. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Apr 6 13:42: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 F3AC112D0BC for ; Wed, 6 Apr 2016 13:42:41 -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 5TDhyDXW3GM9 for ; Wed, 6 Apr 2016 13:42:40 -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 703F512D149 for ; Wed, 6 Apr 2016 13:42:39 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by comcast with SMTP id nuEPavXFKgEHvnuHeazvVL; Wed, 06 Apr 2016 20:42:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459975358; bh=CARYWqFtObq9QckgFayUJcG1MUp8fKUJJfPDnShhGO8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Vp88zQT3FRUsf3pVdxl6JbVos7+/47vv02FL+ePA0O3Vc+bMp6V/Wjzg47HN6h2YU tT2L138QIGgYN5AmICnVygvvVLTBtdN9FqRhpWvj5Xch3vbdYYwqjDknu2OZDp8AvL 0np4tfBdBjrbr49szx8b3yAPU6E8kLW+kLQf9J6BT1gaxyy9Tdfz5paxjVzJIZWafJ ho2RrnZF5APTi5jJ3p7vj0iRgc4e5xn7Cb1cUFKGaH9nt5ac6g8lZ18Q9MTDgI7FXC K+Dcq3BcTFf9lSw6bOvwrhAJ1JLZp15FhpEUpIoJEPAerf9aQLXW8ULPilt0kk9OM9 4CqNC8X0+1QUg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id f8id1s00b1nMCLR018ieWd; Wed, 06 Apr 2016 20:42:38 +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 u36Kgab7014118 for ; Wed, 6 Apr 2016 16:42:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u36Kgakk014115; Wed, 6 Apr 2016 16:42: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 In-Reply-To: (gsalguei@cisco.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Apr 2016 16:42:36 -0400 Message-ID: <874mbev58j.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack 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, 06 Apr 2016 20:42:42 -0000 I suspect the problem is that everyone agrees on both (1) what is the desired behavior and (2) that the existing RFCs specify that behavior. The goal of section 5 is to point out the complexities involved and make sure that readers are aware of what the correct behavior is, but the fact that the text makes no normative changes makes it more difficult to describe what behaviors are excluded. I've rewritten the section based on y'all's e-mails, and particularly the example Adam provided: 5. Clarification of RFC 6157 Section 5 of [RFC6157] specifies that the addresses from the address records for a single target DNS name for a server's DNS name must be contacted in the order specified by the Source and Destination Address Selection algorithms defined in [RFC6724] (the successor of [RFC3484]). Typically, this is done by using the getaddrinfo() function to translate the target DNS name into a list of IPv4 and/or IPv6 addresses in the order in which they are to be contacted, as that function implements [RFC6724]. Thus, if SRV lookup on the server's DNS name is successful, the major ordering of the complete list of destination addresses is determined by the priority and weight fields of the SRV records (as specified in [RFC2782]) and the (minor) ordering among the destinations derived from the "target" field of a single SRV record is determined by [RFC6724]. For example, consider a server with DNS name example.com, with TCP transport specified. The relevant SRV records are: _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. The address records for sip-1.example.com, as ordered by [RFC6724], are sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce sip-1.example.com. 300 IN A 192.0.2.45 sip-1.example.com. 300 IN A 203.0.113.109 sip-1.example.com. 300 IN A 198.51.100.24 and the address records for sip-2.example.com, as ordered by [RFC6724], are: sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de sip-2.example.com. 300 IN A 192.0.2.75 sip-2.example.com. 300 IN A 203.0.113.38 sip-2.example.com. 300 IN A 198.51.100.140 Thus, the complete list of destination addresses has this ordering: 2001:0db8:58:c02::face 2001:0db8:c:a06::2:cafe 2001:0db8:44:204::d1ce 192.0.2.45 203.0.113.109 198.51.100.24 2001:0db8:58:c02::dead 2001:0db8:c:a06::2:beef 2001:0db8:44:204::c0de 192.0.2.75 203.0.113.38 198.51.100.140 In particular, the destination addresses derived from sip- 1.example.com and those derived from sip-2.example.com are not interleaved; [RFC6724] does not operate on the complete list. This would be true even if the two SRV records had the same priority and were (randomly) ordered based on their weights, as the address records of two target DNS names are never interleaved. What do people think of that? Dale From nobody Fri Apr 8 13:33: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 98B6612D6B8 for ; Fri, 8 Apr 2016 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 g8FWLVYyUr6I for ; Fri, 8 Apr 2016 13:33:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF6A12D57A for ; Fri, 8 Apr 2016 13:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4057; q=dns/txt; s=iport; t=1460147616; x=1461357216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7sI6coNLe3YZlE37c/ccpTh3hx/aqI9n2IRncWKkAx0=; b=Xg5LL6RtSPS8wSBAIZIAEsXLMuvj2KY8PaE9SrUq6CfZfiRhQNdlf4LF C0W/nqKsVBFK9Qj2O0BIwvINNDZp7wp2hu4IDASb2PWr1jwWcnQICbsW3 RpgIW23XqyeRbhrtPRNFmFI1KpYYjJfx2evcuzYCKqIIljU5/LPrxJDzo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgClFAhX/40NJK1cgzdTfQa6PwENg?= =?us-ascii?q?XMXCoUiSgKBMzgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwULAgEIEwUeECcLJQI?= =?us-ascii?q?EDgWIHwgOwFEBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdQiCToQnFg2DIIIrB?= =?us-ascii?q?Y1OijYBhXaCcoUjgjWMWI8kAR4BAUKDZ2yIO34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="91738200" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 20:33:35 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u38KXZm1022410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 20:33:35 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 15:33:34 -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; Fri, 8 Apr 2016 15:33:34 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Dale R. Worley" Thread-Topic: [sipcore] WGLC: draft-ietf-sip-dual-stack Thread-Index: AQHRkETZr98vZv8TNUOQkBkvtxJAUJ+A3ykA Date: Fri, 8 Apr 2016 20:33:34 +0000 Message-ID: <3AE1D2E0-40D0-4179-A988-96DA0315AA91@cisco.com> References: <874mbev58j.fsf@hobgoblin.ariadne.com> In-Reply-To: <874mbev58j.fsf@hobgoblin.ariadne.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.239.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack 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, 08 Apr 2016 20:33:38 -0000 This updated text works for me and the example really helps provide additio= nal clarity and sheds light on practical usage/implementation of draft. =20 At this point my concerns are addressed and am satisfied with the state of = the draft. Thanks, Dale. Cheers, Gonzalo > On Apr 6, 2016, at 4:42 PM, Dale R. Worley wrote: >=20 > I suspect the problem is that everyone agrees on both (1) what is the > desired behavior and (2) that the existing RFCs specify that behavior. > The goal of section 5 is to point out the complexities involved and make > sure that readers are aware of what the correct behavior is, but the > fact that the text makes no normative changes makes it more difficult to > describe what behaviors are excluded. >=20 > I've rewritten the section based on y'all's e-mails, and particularly > the example Adam provided: >=20 > 5. Clarification of RFC 6157 >=20 > Section 5 of [RFC6157] specifies that the addresses from the address > records for a single target DNS name for a server's DNS name must be > contacted in the order specified by the Source and Destination > Address Selection algorithms defined in [RFC6724] (the successor of > [RFC3484]). Typically, this is done by using the getaddrinfo() > function to translate the target DNS name into a list of IPv4 and/or > IPv6 addresses in the order in which they are to be contacted, as > that function implements [RFC6724]. >=20 > Thus, if SRV lookup on the server's DNS name is successful, the major > ordering of the complete list of destination addresses is determined > by the priority and weight fields of the SRV records (as specified in > [RFC2782]) and the (minor) ordering among the destinations derived > from the "target" field of a single SRV record is determined by > [RFC6724]. >=20 > For example, consider a server with DNS name example.com, with TCP > transport specified. The relevant SRV records are: >=20 > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. >=20 > The address records for sip-1.example.com, as ordered by [RFC6724], > are >=20 > sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face > sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe > sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce > sip-1.example.com. 300 IN A 192.0.2.45 > sip-1.example.com. 300 IN A 203.0.113.109 > sip-1.example.com. 300 IN A 198.51.100.24 >=20 >=20 > and the address records for sip-2.example.com, as ordered by > [RFC6724], are: >=20 > sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead > sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef > sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de > sip-2.example.com. 300 IN A 192.0.2.75 > sip-2.example.com. 300 IN A 203.0.113.38 > sip-2.example.com. 300 IN A 198.51.100.140 >=20 >=20 > Thus, the complete list of destination addresses has this ordering: >=20 > 2001:0db8:58:c02::face > 2001:0db8:c:a06::2:cafe > 2001:0db8:44:204::d1ce > 192.0.2.45 > 203.0.113.109 > 198.51.100.24 > 2001:0db8:58:c02::dead > 2001:0db8:c:a06::2:beef > 2001:0db8:44:204::c0de > 192.0.2.75 > 203.0.113.38 > 198.51.100.140 >=20 >=20 > In particular, the destination addresses derived from sip- > 1.example.com and those derived from sip-2.example.com are not > interleaved; [RFC6724] does not operate on the complete list. This > would be true even if the two SRV records had the same priority and > were (randomly) ordered based on their weights, as the address > records of two target DNS names are never interleaved. >=20 > What do people think of that? >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Apr 8 18:02: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 A5AD112D0D3 for ; Fri, 8 Apr 2016 18:02:37 -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 1Nhn7kjQ2Pd6 for ; Fri, 8 Apr 2016 18:02:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 72A2B12D0A8 for ; Fri, 8 Apr 2016 18:02:36 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by comcast with SMTP id ohH0ahgXIbFYYohIJa4X7a; Sat, 09 Apr 2016 01:02:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460163755; bh=fEfaJHPOaCC6tPY873OuqN6McEXpSbqZ7PKZq/7ziMw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=T0MR/ETaCProoc94kifddYHGP9dtRa3it+qi7SVJLrkViukrBHLq79AsO7OAhkapQ QqItjO/YDNbra1NVmI7ofyRcTnWH7gJwae8LYmfFIEaW5eWdSap1Eg3Evdu6YRzjpA FbHyyvD0vVPFfnUG5L3WC+zvmIqockvidhVw02UaNVb7APZOFA3nrpx5QgKjf1Ja/G r7Dcl2FZ1cfXofg6QWanf3J218pIa97b9YwISq3hIQ3WuS3/+G8fnhwDlh9bHN7vfp uWu0Mr20iwbR68HrSF9e+HvoqIvs4xFWkD3FCR1gT1XiQ5lonWT/PwHDtQF939qBTh vv093XNwTGCtg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-04v.sys.comcast.net with comcast id g12b1s0021nMCLR0112bte; Sat, 09 Apr 2016 01:02:35 +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 u3912YP6018408 for ; Fri, 8 Apr 2016 21:02:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3912YQW018405; Fri, 8 Apr 2016 21:02:34 -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: Fri, 08 Apr 2016 21:02:34 -0400 Message-ID: <87r3effvbp.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] draft-ietf-sip-dual-stack presentation at the IETF meeting 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, 09 Apr 2016 01:02:37 -0000 My apologies for not giving the promised presentation for draft-ietf-sip-dual-stack at the meeting. The Meetecho client wouldn't connect for me. At this point I think the problem was serious network congestion between the venue and the international links, but the Meetecho people haven't had a chance to look deep into the problem. Many thanks to Olle for stepping in! Dale From nobody Fri Apr 8 18:19: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 C48E812D11F for ; Fri, 8 Apr 2016 18:19:17 -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 yweJ5oQkcxtL for ; Fri, 8 Apr 2016 18:19:16 -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 675D212D5BF for ; Fri, 8 Apr 2016 18:19:15 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by comcast with SMTP id ohYHaGsXE8DPnohYQa7P6C; Sat, 09 Apr 2016 01:19:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460164754; bh=OUOMdQqQK/dPNi1y7uuIWIZrbAKr11W5gnVXcdunXsc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=B56Pi1VdYEYezwYJ0oy1Vdm4pqxoya7mm7ezZrolaRZD7QrWGay+bd6sJaC+HBgN7 yVZ/lUgVTT4tFW8uoAaftkQn1cKbXGb5plhVR7edPumfhJ3bDN7sqGlHWcjr5bU7OT 0AfUZLfMO2twe/EsbHWK8W1FOZ1048ogSeo6SCRJV/Fi0OJYWWpoSGFeknflPhhDL6 krPvHVOOS0ceUI9kkYikkPgwpKpTF36ttAjp0TBsOTjlyUXBeMnW6orE2Pc5UIfg00 WxUBF4ofjlCZHln3474/osXazKG6FijoMKQscpZJf4gj39n1kxX7CDA1X2gOFhGazx gdoQ18H9nLKFg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id g1KE1s0031nMCLR011KEom; Sat, 09 Apr 2016 01:19:14 +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 u391JD4u019482 for ; Fri, 8 Apr 2016 21:19:13 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u391JDKH019477; Fri, 8 Apr 2016 21:19:13 -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: Fri, 08 Apr 2016 21:19:13 -0400 Message-ID: <87oa9jfujy.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Changes to draft-ietf-sipcore-dns-dual-stack 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, 09 Apr 2016 01:19:18 -0000 I saw that in the meeting questions arose about what changes this draft makes to 3263. The major point of the draft is to fix/clarify the two points in 3263 where "the client performs an A or AAAA record lookup" of a target domain name. In order to get good behavior in dual-stack environments, it is necessary that both A and AAAA lookups be done on target names (if the client supports both address families). (See section 3.1 of the draft for the details.) Personally, I'd argue that the corrected meaning is the only *rational* interpretation of what 3263 must have meant ... but other people have read the text with the other meaning, and "Once you're arguing whether or not the text is unclear, you've proven that the text is unclear." The second point is to make sure that the interaction of 3262 and the IPv6 source/destination selection algorithm (RFC 6724) is made clear. In this case, I think everyone has always agreed what the correct answer is, but the situation is just treacherous enough that we want to explain the tricky part in detail. This is described in section 5 of -04. (Note that for the -05 I've proposed a substantial change in the wording of this section and incorporated a detailed example provided by Adam.) Also, there is the question of the difference between -04 version and the -02 version (the one that was current when I took over, and in reality, the last widely circulated version). My opinion is that there are no *technical* changes but there are a lot of changes of wording in order to make it clearer. The differences are described in prose in section 9, and you can see the diffs between the two versions at https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-02&url2=draft-ietf-sipcore-dns-dual-stack-04 There are a number of outstanding comments and changes that will be incorporated into the -05 version (assuming the WG agrees). One of them is the update of section 5 I mentioned above. Another are the commends that Jean Mahoney made on the 6th. Dale From nobody Fri Apr 8 18:39: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 0CBA512D5C3 for ; Fri, 8 Apr 2016 18:39:46 -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 3-7yKwSvrPns for ; Fri, 8 Apr 2016 18:39:44 -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 473CA12D15B for ; Fri, 8 Apr 2016 18:39:44 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id ohs7aK0zXp1BeohsFap4Ip; Sat, 09 Apr 2016 01:39:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460165983; bh=iz8JkWn4JImbpJiLZlyo0dGqSYh35ra2n22NVVcTqZ0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Xyfh57HdiQiCmT+Y1JR7HCXjJkHpWuuCxGx7fvBM+6zTqL6DdJEnpBVxdZs1jGUvA aUD7tji4kuJsuoNxlqgelSZ8+V/4yGXAffiF1fthwyNYM5PpAgB0GvaEofUCKiaRk2 Z3siF161UvUZcobyKLPpbtgYcwyntmqO1vGluLden8/rkeHaawKjdDN+nhOf5UhZrH aot4PwtbdEBrSrPBjwUA/usVBO5KAJN9Uh7GmfTkuUjQpPgYBm8LWRIrLbA8ccOmGe 1rH+lcGwpCT7Oku1tKWMxK+2WBMSK5E293/WF8eUca2g+ZSLyyKbwdz1y8dny8IVbq GD4/TddTprbLw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-19v.sys.comcast.net with comcast id g1fi1s00M1nMCLR011fjxG; Sat, 09 Apr 2016 01:39:43 +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 u391dgET020809 for ; Fri, 8 Apr 2016 21:39:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u391dfV0020806; Fri, 8 Apr 2016 21:39:41 -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: Fri, 08 Apr 2016 21:39:41 -0400 Message-ID: <87lh4nftlu.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Remaining Happy Eyeballs work 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, 09 Apr 2016 01:39:46 -0000 I believe that we can make a clean list of the work that remains for Happy Eyeballs in SIP. (This is taken from from slide 4 of my presentation at the meeting, https://www.ietf.org/proceedings/95/slides/slides-95-sipcore-1.pdf) - Recommend SIP Outbound (RFC 5626) between UAs and edge proxies [everybody thinks that using SIP Outbound is the in-principle best solution] - Allow devices to change the target order prescribed by RFC 3263/2782 using the Happy Eyeballs rules: - Prefer targets with existing flows - Deprecate targets known to be non-responsive - Prefer targets with different address family than a non-responsive address family - May simultaneously initiate flows with multiple targets - Reduce client transaction timeouts: Timer B and Timer F are currently 64*T1, which defaults to 32 seconds - A solution is needed for simple UDP, either - a simple mechanism to maintain UDP flow state, or - a way to send simultaneous redundant requests to multiple addresses The messy 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 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. Certainly, a substantial fraction of the UAs tested in the latest SIPit do not support TCP, TLS, or Outbound, showing that there is substantial market acceptance of simple-UDP-only UAs. There are a number of decidedly different ways that this need might be satisfied. The ones that I can think of are: - documenting a suitable subset of SIP Outbound (if one exists) - a lightweight SIP/DTLS (the cryptographic setup creates a flow) - a mechanism to send simultaneous redundant requests to multiple addresses without causing problems with merged requests It would also be helpful if the NAT binding of a UA behind a NAT could change without causing existing dialogs or transactions to fail. Dale From nobody Fri Apr 8 18:58: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 56D6E12D1B5 for ; Fri, 8 Apr 2016 18:58:44 -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 IS9VwciKM1By for ; Fri, 8 Apr 2016 18:58:43 -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 0090012D0E9 for ; Fri, 8 Apr 2016 18:58:42 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id oiAUaRhEPnIc7oiAcaTD62; Sat, 09 Apr 2016 01:58:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460167122; bh=d3BeOOblm9iceaRich33RQKk2fLxMGKXkQ56oaCp2ek=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=lE6nMPGTHRP4EfvaoJPCJT08qfuyPGPlljx9Ypzx7qL4I0RrpPg2ExVy92953A4om JwhFmBSjwtqoZr6W7Ycx/8TOT65lobyt4XlU/+k7UZlAFXNWLdT06/AQwMpgAoMEhG QD8Aa3EMYsxVdbEMOBWOnxWFujl0XcYZDmj9vWtsws9hcCT8gXMnWYsM2YFfzvL2pw 8G5zATs6h49eP67cakoHt+/w1OMhItTmO7Gc0O2u+qVS/0z1XHzDfLKuqV0lrBHQzE giTA1umvpOrz02q5Kxzu/3CVK+OTgYjO93XRffW/xw3aNzXIU3XmObXpllQ6ZAlIaM m3yayylIvEQ6w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id g1yg1s0051nMCLR011ygHH; Sat, 09 Apr 2016 01:58:42 +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 u391wdZC021984; Fri, 8 Apr 2016 21:58:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u391wcnB021980; Fri, 8 Apr 2016 21:58:38 -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: "A. Jean Mahoney" In-Reply-To: <57056907.50804@nostrum.com> (mahoney@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 08 Apr 2016 21:58:38 -0400 Message-ID: <87inzrfsq9.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack 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, 09 Apr 2016 01:58:44 -0000 "A. Jean Mahoney" writes: > As pointed out by others, section 5 needs to be clarified, and an > example would be helpful. See my message of 6 Apr for a proposed update of section 5. > Feedback from ID Nits: > - Since this draft directly quotes 3263, the authors of 3263 should > be contacted about granting BCP78 rights, if you have not already > done so. Ugh, I'll look into that. > - Remove the 'RFC' label in the 'Updates: ' line. Will appear in -05. > - Remove the mention of RFC 3484, which is is obsolete. Just point > to 6724. The only reference to 3484 is in the passage "... contacted in the order specified by the Source and Destination Address Selection algorithms defined in [RFC6724] (the successor of [RFC3484])." I want to state in this draft that 6724 is the successor of 3484, because 6157 mentions 3484 repeatedly. > Other nits: > - Section 1 and 4.1 Add a space between "RFC 3263[RFC3263]" Will appear in -05. > - Since there's only a few uses of "RR", just use "record" instead. The only use of "RR" that I can find is in the title of RFC 2782 in the references. I suspect "RR" is a typo here. Thanks! Dale From nobody Sat Apr 9 04:08: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 9010412D5FF for ; Sat, 9 Apr 2016 04:08:22 -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 E43bCZls4Ooe for ; Sat, 9 Apr 2016 04:08:21 -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 1684B12D5F5 for ; Sat, 9 Apr 2016 04:08:20 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by comcast with SMTP id oqkWa9zuJpyiooqkWaCxlS; Sat, 09 Apr 2016 11:08:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460200100; bh=DXO4yQ3VEykt387aPN6DFU3Aar526s35+9fRv8O2m5M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=NqvqCBQdDEfCYMH9gQMHKiQ9VAL01RsGWgjwpt05TPBkRN9nqPrqTLZtHoYO6ey+x YE+lbvgerhuOhCOWiP2U6bKPTXgULeeguN3YRelZ6GEAHWIlsU2o4DAQKXWjFGGYSJ 1nh/iNFiZU0XmOKvcH42Hl5ZYX3MkJmvwiVYFDk7/HLwOOacDVai2nStaKuIRMhZRu N/8uvlbj0K8rfm9ISOiMcPQlggQocIrB9T1uMbKxO/1SS+IDHSrPKrd5X0RNvbfyYR K3qkeq1WdjAwR0KV6fFp2PKkeWukp++QEvvu4caikope1PfdIf7kO33nZAIeYvdrja 3EtAdgndk9bug== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-05v.sys.comcast.net with comcast id gB8J1s0051nMCLR01B8K2A; Sat, 09 Apr 2016 11:08:20 +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 u39B8HZs027361; Sat, 9 Apr 2016 07:08:17 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u39B8HAj027358; Sat, 9 Apr 2016 07:08:17 -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: worley@ariadne.com (Dale R. Worley) In-Reply-To: <87inzrfsq9.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 09 Apr 2016 07:08:16 -0400 Message-ID: <877fg7f3a7.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack 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, 09 Apr 2016 11:08:22 -0000 worley@ariadne.com (Dale R. Worley) writes: > "A. Jean Mahoney" writes: >> - Since there's only a few uses of "RR", just use "record" instead. > > The only use of "RR" that I can find is in the title of RFC 2782 in the > references. I suspect "RR" is a typo here. Oops, my mistake there. My clever regexp search for "RR" overlooked both "RR's" and "RRs". I'll fix the wording in the -05. Dale From nobody Sat Apr 9 04:38: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 4920412D5CA for ; Sat, 9 Apr 2016 04:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 9LL9tP09jAiQ for ; Sat, 9 Apr 2016 04:38:41 -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 7DC8812D0A5 for ; Sat, 9 Apr 2016 04:38:41 -0700 (PDT) Received: from dhcp-8ca1.meeting.ietf.org ([IPv6:2001:67c:370:136:bcb7:d75f:66b7:94f0]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u39BcZO5076092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 9 Apr 2016 06:38:38 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:bcb7:d75f:66b7:94f0] claimed to be dhcp-8ca1.meeting.ietf.org To: sipcore@ietf.org References: <87r3effvbp.fsf@hobgoblin.ariadne.com> From: "A. Jean Mahoney" Message-ID: <5708E9B7.6080708@nostrum.com> Date: Sat, 9 Apr 2016 08:38:31 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <87r3effvbp.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-ietf-sip-dual-stack presentation at the IETF meeting 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, 09 Apr 2016 11:38:43 -0000 Hi Dale, No need to apologize. Thank you for being willing to give remote presentation a try. I hope Meetecho can find some useful troubleshooting information from yesterday's session. Jean On 4/8/16 10:02 PM, Dale R. Worley wrote: > My apologies for not giving the promised presentation for > draft-ietf-sip-dual-stack at the meeting. The Meetecho client wouldn't > connect for me. At this point I think the problem was serious network > congestion between the venue and the international links, but the > Meetecho people haven't had a chance to look deep into the problem. > > Many thanks to Olle for stepping in! > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Apr 11 00:25: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 0B1A812DD56 for ; Mon, 11 Apr 2016 00:25: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 1nisJ1fOEbQK for ; Mon, 11 Apr 2016 00:25:48 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6F12D6BD for ; Mon, 11 Apr 2016 00:25:47 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4B6A493DE44; Mon, 11 Apr 2016 07:24:44 +0000 (UTC) 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: <87oa9jfujy.fsf@hobgoblin.ariadne.com> Date: Mon, 11 Apr 2016 09:25:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDB8B40-2B0E-4080-BDBB-1C26BB267B31@edvina.net> References: <87oa9jfujy.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] Changes to draft-ietf-sipcore-dns-dual-stack 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, 11 Apr 2016 07:25:50 -0000 > On 09 Apr 2016, at 03:19, Dale R. Worley wrote: >=20 > I saw that in the meeting questions arose about what changes this = draft > makes to 3263. >=20 > The major point of the draft is to fix/clarify the two points in 3263 > where "the client performs an A or AAAA record lookup" of a target > domain name. In order to get good behavior in dual-stack = environments, > it is necessary that both A and AAAA lookups be done on target names = (if > the client supports both address families). (See section 3.1 of the > draft for the details.) Personally, I'd argue that the corrected > meaning is the only *rational* interpretation of what 3263 must have > meant ... but other people have read the text with the other meaning, > and "Once you're arguing whether or not the text is unclear, you've > proven that the text is unclear.=E2=80=9D As this text is copied to other documents we need to make sure that we are clear on this, because it will lead to other updates. Section 6.2 = of RFC 4975 - MSRP - has a similar mistake which will make Happy=20 Eyeballs hard for MSRP - RFC 4976 section 8 has the very same issue. I am pretty sure we can find the same problem in other places too. /O >=20 > The second point is to make sure that the interaction of 3262 and the > IPv6 source/destination selection algorithm (RFC 6724) is made clear. > In this case, I think everyone has always agreed what the correct = answer > is, but the situation is just treacherous enough that we want to = explain > the tricky part in detail. This is described in section 5 of -04. > (Note that for the -05 I've proposed a substantial change in the = wording > of this section and incorporated a detailed example provided by Adam.) >=20 > Also, there is the question of the difference between -04 version and > the -02 version (the one that was current when I took over, and in > reality, the last widely circulated version). >=20 > My opinion is that there are no *technical* changes but there are a = lot > of changes of wording in order to make it clearer. The differences = are > described in prose in section 9, and you can see the diffs between the > two versions at > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-02&u= rl2=3Ddraft-ietf-sipcore-dns-dual-stack-04 >=20 > There are a number of outstanding comments and changes that will be > incorporated into the -05 version (assuming the WG agrees). One of = them > is the update of section 5 I mentioned above. Another are the = commends > that Jean Mahoney made on the 6th. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Apr 11 00:37: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 4797612E843 for ; Mon, 11 Apr 2016 00:37:47 -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 bxpZ_9GgCmyt for ; Mon, 11 Apr 2016 00:37:44 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8412E84F for ; Mon, 11 Apr 2016 00:37:43 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 46F3093C2A2; Mon, 11 Apr 2016 07:36:46 +0000 (UTC) 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: <87lh4nftlu.fsf@hobgoblin.ariadne.com> Date: Mon, 11 Apr 2016 09:37:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87lh4nftlu.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] Remaining Happy Eyeballs work 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, 11 Apr 2016 07:37:47 -0000 > On 09 Apr 2016, at 03:39, Dale R. Worley wrote: >=20 > I believe that we can make a clean list of the work that remains for > Happy Eyeballs in SIP. (This is taken from from slide 4 of my > presentation at the meeting, > https://www.ietf.org/proceedings/95/slides/slides-95-sipcore-1.pdf) >=20 > - Recommend SIP Outbound (RFC 5626) between UAs and edge proxies > [everybody thinks that using SIP Outbound is the in-principle best = solution] Based on previous discussions about why very few are implementing a = full, two flow Outbound solution we may need to draft an =E2=80=9COutbound = Simple=E2=80=9D with only one flow. This is in my opinion what=E2=80=99s outlined in the = latest SIP Connect draft, without any IETF document to support it. Proper TLS usage will = require this too, so it may be time to do that anyway. >=20 > - Allow devices to change the target order prescribed by RFC 3263/2782 > using the Happy Eyeballs rules: > - Prefer targets with existing flows > - Deprecate targets known to be non-responsive > - Prefer targets with different address family than > a non-responsive address family > - May simultaneously initiate flows with multiple targets - Maybe a preference for flows with different address families = (brainstorming) >=20 > - Reduce client transaction timeouts: > Timer B and Timer F are currently 64*T1, which defaults to 32 = seconds >=20 > - A solution is needed for simple UDP, either > - a simple mechanism to maintain UDP flow state, or > - a way to send simultaneous redundant requests to multiple = addresses >=20 > The messy 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 seem to be: >=20 > - The per-UA state in the edge proxy must be no larger than about what > is kept for a registration. >=20 > - The update rate of the per-UA state in the edge proxy must be no > larger than about the update rate for a registration. >=20 > It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet > these requirements. Certainly, a substantial fraction of the UAs = tested > in the latest SIPit do not support TCP, TLS, or Outbound, showing that > there is substantial market acceptance of simple-UDP-only UAs. >=20 > There are a number of decidedly different ways that this need might be > satisfied. The ones that I can think of are: >=20 > - documenting a suitable subset of SIP Outbound (if one exists) According to several emails people talk about =E2=80=9Cthe relevant = parts of Outbound that is implemented=E2=80=9D - but no one has documented the relevant = parts=E2=80=A6 (see above) >=20 > - a lightweight SIP/DTLS (the cryptographic setup creates a flow) I think this is a good idea. >=20 > - a mechanism to send simultaneous redundant requests to multiple > addresses without causing problems with merged requests While this is interesting, I think it will take a very long time to get = implementations. There are many SIP extensions that solve good problems, but have not gotten implemented in a majority of the SIP stacks because they don=E2=80=99= t solve current business problems.=20 >=20 > It would also be helpful if the NAT binding of a UA behind a NAT could > change without causing existing dialogs or transactions to fail. THat=E2=80=99s a missing part of SIP. Outbound only handles dialog = set-up, but not failures in-dialog or failover in-dialog. The work on mobility with TURN helps media and maybe SIP should document a similar solution.=20 Based on this discussion I see ideas for several different pieces of = work - 1.Happy Eyeballs for SIP - 2.SImple Outbound=20 - 3.Merge Request avoidance - 4.SIP dialog retargeting with Outbound involvement In order to focus, can we do Happy eyeballs without having to do all = four? I personally think that we can separate out 3 and 4, but am afraid that = 2 can=E2=80=99t be avoided. /O= From nobody Mon Apr 11 07:45: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 56BF212EFF5 for ; Mon, 11 Apr 2016 07:44:52 -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 hs3xg6LzybYn for ; Mon, 11 Apr 2016 07:44:51 -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 0F03E12EFF8 for ; Mon, 11 Apr 2016 07:44:50 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by comcast with SMTP id pd4laKH9ALCmUpd57aOwpM; Mon, 11 Apr 2016 14:44:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460385889; bh=7XUMZ9HUfxRgfZU6wOUkuUYwphKBFVkPey8X5tVOeng=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=M8i7hSKpXs3/o2BONugiVDEVkgV45Nz5NiQVMClbzMU/mz9vbjw1a3YLnWEhL5Yqo TTnrywtY0LpauSM83lDfVr/9ttk5H5ZdO3RhBeTybkIZ/fIdnmqqdZ1A8+XbUpvV0q qbXqiZ7kKcrvHxprjtw/D/REA/ShrMeCjhkeOLOR1eqWNMD+le6+dPo+HrtFaRFBuB rD+B4Lo3EDoka0Vb8EGdsSOiOGeSOnJLZcc8NcufApEaETEum3ZxS4OCtPVD/ti2EV MnA0cijn9a3yKZkrAUlydvrXmnYZ+603DDRP3anolMhcIbEWh1V66WRWwF9+PMoN28 LxbcTjtIga0pA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id h2ko1s00J1nMCLR012koGX; Mon, 11 Apr 2016 14:44:49 +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 u3BEimcL015862; Mon, 11 Apr 2016 10:44:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3BEilMD015859; Mon, 11 Apr 2016 10:44:47 -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: worley@ariadne.com (Dale R. Worley) In-Reply-To: <87lh4nftlu.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 11 Apr 2016 10:44:47 -0400 Message-ID: <87lh4kyzkw.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Remaining Happy Eyeballs work 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, 11 Apr 2016 14:44:52 -0000 worley@ariadne.com (Dale R. Worley) writes: > It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet > these requirements. Certainly, a substantial fraction of the UAs tested > in the latest SIPit do not support TCP, TLS, or Outbound, showing that > there is substantial market acceptance of simple-UDP-only UAs. > > There are a number of decidedly different ways that this need might be > satisfied. The ones that I can think of are: > > - documenting a suitable subset of SIP Outbound (if one exists) > > - a lightweight SIP/DTLS (the cryptographic setup creates a flow) > > - a mechanism to send simultaneous redundant requests to multiple > addresses without causing problems with merged requests Another possibility is: - the registration message flow from the UA is sufficient to keep the cached reachability information up to date Dale From nobody Mon Apr 11 07:50: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 8A2B512EFDE for ; Mon, 11 Apr 2016 07:49:59 -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 B0H8CAegjJ0j for ; Mon, 11 Apr 2016 07:49:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3A12EFB3 for ; Mon, 11 Apr 2016 07:49:56 -0700 (PDT) Received: from [192.168.40.32] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4C70193C2A2; Mon, 11 Apr 2016 14:48:58 +0000 (UTC) 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: <87lh4kyzkw.fsf@hobgoblin.ariadne.com> Date: Mon, 11 Apr 2016 16:49:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87lh4kyzkw.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] Remaining Happy Eyeballs work 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, 11 Apr 2016 14:49:59 -0000 > On 11 Apr 2016, at 16:44, Dale R. Worley wrote: >=20 > worley@ariadne.com (Dale R. Worley) writes: >> It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet >> these requirements. Certainly, a substantial fraction of the UAs = tested >> in the latest SIPit do not support TCP, TLS, or Outbound, showing = that >> there is substantial market acceptance of simple-UDP-only UAs. >>=20 >> There are a number of decidedly different ways that this need might = be >> satisfied. The ones that I can think of are: >>=20 >> - documenting a suitable subset of SIP Outbound (if one exists) >>=20 >> - a lightweight SIP/DTLS (the cryptographic setup creates a flow) >>=20 >> - a mechanism to send simultaneous redundant requests to multiple >> addresses without causing problems with merged requests >=20 > Another possibility is: >=20 > - the registration message flow from the UA is sufficient to keep the > cached reachability information up to date =E2=80=A6and how is that different from SIP outbound simple (SOS) ? /O= From nobody Mon Apr 11 10:50: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 8D78512D0A4 for ; Mon, 11 Apr 2016 10:50:55 -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 XWTjz-K1Qe0s for ; Mon, 11 Apr 2016 10:50:54 -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 1562812DCFA for ; Mon, 11 Apr 2016 10:50:54 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id pfyTa8heIpUrhpfzBaY8Q6; Mon, 11 Apr 2016 17:50:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460397053; bh=4M4fPUST33xvu8CrAEfVPVo7pi79WV5TvsuhgBOBLtQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=sLYc3JEDx3F0uOd2krEnli7OUMdqxDLIylE9kjty1mwPhtbGCjSpk6r1YaxWmavpB 7IT73eWCaWVd/U+KNeh0cJifHhT4sIbwEva7+8XjRiv05hlBXH0v1dpGY4+fmNf4Zw TgXms6+sJrxzK2INaQ2SU7NCsUehVK9mgXRXTQKQy8bpssGsfWmPBgPwAbJOZfw0V6 AxuQ6CfVsqJy2vYfv1kc3cOH6Ka/lU24lP+P3jYH1CSxwG9rdWrWn3DpahAcLJH29G NKSd+/TJ8JMk/O0mm5ABbwyRLyZ77vZuRvq/13a9pwwK0WBj5N8weUj6wvkruht7Ko J680v9Zs9qf9Q== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-16v.sys.comcast.net with comcast id h5qr1s00Y1nMCLR015qsEi; Mon, 11 Apr 2016 17:50:53 +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 u3BHop17026167; Mon, 11 Apr 2016 13:50:51 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3BHoo7I026164; Mon, 11 Apr 2016 13:50:50 -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, 11 Apr 2016 13:50:50 -0400 Message-ID: <87a8l0yqyt.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Remaining Happy Eyeballs work 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, 11 Apr 2016 17:50:55 -0000 "Olle E. Johansson" writes: > Based on previous discussions about why very few are implementing a full, > two flow Outbound solution we may need to draft an "Outbound Simple" with > only one flow. This is in my opinion what's outlined in the latest SIP Connect > draft, without any IETF document to support it. Proper TLS usage will require > this too, so it may be time to do that anyway. I re-read parts of RFC 5626. I'm not sure that there's much benefit to be obtained from one-flow Outbound beyond what can be obtained from an ordinary registration. Indeed, an ordinary registration is a verification that a particular address for the domain is reachable. I wonder if that is sufficient for Happy Eyeballs purposes? >> - Allow devices to change the target order prescribed by RFC 3263/2782 >> using the Happy Eyeballs rules: >> - Prefer targets with existing flows >> - Deprecate targets known to be non-responsive >> - Prefer targets with different address family than >> a non-responsive address family >> - May simultaneously initiate flows with multiple targets > > - Maybe a preference for flows with different address families (brainstorming) Yes... There are a number of variations on the idea that an address's address family can be taken into account. Perhaps we need broad wording to cover this topic broadly. >> - a lightweight SIP/DTLS (the cryptographic setup creates a flow) > > I think this is a good idea. I think so, too, but mostly as a matter of privacy, rather than for Happy Eyeballs. >> It would also be helpful if the NAT binding of a UA behind a NAT could >> change without causing existing dialogs or transactions to fail. > > THat's a missing part of SIP. Outbound only handles dialog set-up, > but not failures in-dialog or failover in-dialog. The work on mobility > with TURN helps media and maybe SIP should document a similar > solution. That could become a complicated piece of work. Is there a perceived need for it? > Based on this discussion I see ideas for several different pieces of work > - 1.Happy Eyeballs for SIP > - 2.SImple Outbound > - 3.Merge Request avoidance > - 4.SIP dialog retargeting with Outbound involvement > > In order to focus, can we do Happy eyeballs without having to do all > four? I personally think that we can separate out 3 and 4, but am > afraid that 2 can't be avoided. We could add 5.SIP/DTLS As for 2, we need to assess the benefits of Simple Outbound over ordinary registration. Dale From nobody Mon Apr 11 14:24: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 4FF0F12E585 for ; Mon, 11 Apr 2016 14:24:06 -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 ArfX0lXEPe_d for ; Mon, 11 Apr 2016 14:24:05 -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 50B7812E588 for ; Mon, 11 Apr 2016 14:24:05 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by comcast with SMTP id pjIJa3cSCgEHvpjJUaG7aN; Mon, 11 Apr 2016 21:24:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460409844; bh=D3ZJ2VCB8iFDNHo1qDdbkFAkcbuAkxGxvN55a8HAdDU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aO+2w8Lg4l+Z5pBgxYK6grI+F79F3ELdV7upmpOQaujqO9gawQMcIWpzyIhzpyfKQ VEIlfoqoTxFqUEinGD2q3t0ti3m21ZXOx4ePYhsEbEBN5VpBcjGSj7U2F8O8NceYAr 94p/keQW87rWgRRFwbiiSXDcY+XGnodws0odQJLgRMNBhwLHdMP581v5QQPukglEjv cBrt5liPz+cnydORr15LbFe4Zf3W9tSVz2UUgUh/27urQe5GqFLHttEh8NFqhASIeC SSnd7EOCLEYEodiPvl+qLCesNE05H2odtDlKZrZiZPYPJn/A5H3SHeZbKOMIVjmWt4 B52mKs802fiEw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id h9Q31s00E3KdFy1019Q3Eh; Mon, 11 Apr 2016 21:24:04 +0000 To: sipcore@ietf.org References: <87a8l0yqyt.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <570C15F3.3020300@alum.mit.edu> Date: Mon, 11 Apr 2016 17:24:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <87a8l0yqyt.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Remaining Happy Eyeballs work 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, 11 Apr 2016 21:24:06 -0000 On 4/11/16 1:50 PM, Dale R. Worley wrote: > "Olle E. Johansson" writes: >> Based on previous discussions about why very few are implementing a full, >> two flow Outbound solution we may need to draft an "Outbound Simple" with >> only one flow. This is in my opinion what's outlined in the latest SIP Connect >> draft, without any IETF document to support it. Proper TLS usage will require >> this too, so it may be time to do that anyway. > > I re-read parts of RFC 5626. I'm not sure that there's much benefit to > be obtained from one-flow Outbound beyond what can be obtained from an > ordinary registration. Indeed, an ordinary registration is a > verification that a particular address for the domain is reachable. I > wonder if that is sufficient for Happy Eyeballs purposes? My impression is that people are using registration as sufficient evidence to use the resulting "flow" for outbound calls. That of course doesn't mean much for UDP, but it does for TCP with or without TLS. But such is not formally allowed. One of the key points of outbound is for "safe" connection reuse. For that, "simple" (one flow) outbound would be useful. And it would also be useful with SIP over DTLS. Thanks, Paul From nobody Tue Apr 12 00:53: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 5B8E912E7DA for ; Tue, 12 Apr 2016 00:53:36 -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 kC0JmRUkMHmZ for ; Tue, 12 Apr 2016 00:53:34 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A7E5B12E7D7 for ; Tue, 12 Apr 2016 00:53:32 -0700 (PDT) Received: from [10.228.165.132] (unknown [134.25.0.35]) by smtp7.webway.se (Postfix) with ESMTPA id 1930F93DE44; Tue, 12 Apr 2016 07:52:33 +0000 (UTC) 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: <87a8l0yqyt.fsf@hobgoblin.ariadne.com> Date: Tue, 12 Apr 2016 09:53:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D166172-5CB6-4DF1-8968-6383CA8430D2@edvina.net> References: <87a8l0yqyt.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] Remaining Happy Eyeballs work 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, 12 Apr 2016 07:53:36 -0000 > On 11 Apr 2016, at 19:50, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >> Based on previous discussions about why very few are implementing a = full, >> two flow Outbound solution we may need to draft an "Outbound Simple" = with >> only one flow. This is in my opinion what's outlined in the latest = SIP Connect >> draft, without any IETF document to support it. Proper TLS usage will = require >> this too, so it may be time to do that anyway. >=20 > I re-read parts of RFC 5626. I'm not sure that there's much benefit = to > be obtained from one-flow Outbound beyond what can be obtained from an > ordinary registration. =20 The main part is that the server may reuse the connection instead of the = contact url. If a client connects to a server using TLS the server needs a way = to set up a flow in the other direction. Without Outbound the server needs to = set up a new connection to the client and the client will need a TLS cert. Many = servers actually use this form of connection reuse today (like Kamailio) but it = is not documented anywhere. > Indeed, an ordinary registration is a > verification that a particular address for the domain is reachable. I > wonder if that is sufficient for Happy Eyeballs purposes? We need a working flow in the direction from the server to the client. The client sets it up at registration and the server reuse it. THat=E2=80=99s outbound. >=20 >>> - Allow devices to change the target order prescribed by RFC = 3263/2782 >>> using the Happy Eyeballs rules: >>> - Prefer targets with existing flows >>> - Deprecate targets known to be non-responsive >>> - Prefer targets with different address family than >>> a non-responsive address family >>> - May simultaneously initiate flows with multiple targets >>=20 >> - Maybe a preference for flows with different address families = (brainstorming) >=20 > Yes... There are a number of variations on the idea that an address's > address family can be taken into account. Perhaps we need broad = wording > to cover this topic broadly. We need to check the latest BCP from the IPv6ops guys. It=E2=80=99s been = a moving target. =46rom start it was =E2=80=9CALWAYS prefer IPv6=E2=80=9D but = then it=E2=80=99s become admin settable if I remember right. Happy Eyeballs give IPv6 a head start, but = connection setup no longer a serial process, it=E2=80=99s a parallell process. >=20 >>> - a lightweight SIP/DTLS (the cryptographic setup creates a flow) >>=20 >> I think this is a good idea. >=20 > I think so, too, but mostly as a matter of privacy, rather than for > Happy Eyeballs. >=20 >>> It would also be helpful if the NAT binding of a UA behind a NAT = could >>> change without causing existing dialogs or transactions to fail. >>=20 >> THat's a missing part of SIP. Outbound only handles dialog set-up, >> but not failures in-dialog or failover in-dialog. The work on = mobility >> with TURN helps media and maybe SIP should document a similar >> solution.=20 >=20 > That could become a complicated piece of work. Is there a perceived > need for it? More and more with mobile to wifi handover. It=E2=80=99s been discussed = many times at SIPit and other meetings of SIP developers. >=20 >> Based on this discussion I see ideas for several different pieces of = work >> - 1.Happy Eyeballs for SIP >> - 2.SImple Outbound=20 >> - 3.Merge Request avoidance >> - 4.SIP dialog retargeting with Outbound involvement >>=20 >> In order to focus, can we do Happy eyeballs without having to do all >> four? I personally think that we can separate out 3 and 4, but am >> afraid that 2 can't be avoided. >=20 > We could add >=20 > 5.SIP/DTLS >=20 > As for 2, we need to assess the benefits of Simple Outbound over > ordinary registration. It=E2=80=99s a matter of being able to reuse an existing flow in two = directions. You can see a long discussion about this on the SIP Forum techwg mailing list. In my view, their current document describes what we=20 want to do, but I can=E2=80=99t find it documented in any RFC but = outbound. There=E2=80=99s a large resistance against referring to outbound, so = yes, we need a SImple Outbound that at least documents the current practise. /O= From nobody Tue Apr 12 08:37: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 8774412E834 for ; Tue, 12 Apr 2016 08:37:11 -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 GwyW474IPn0s for ; Tue, 12 Apr 2016 08:37:09 -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 CEC6B12E7A5 for ; Tue, 12 Apr 2016 08:37:09 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by comcast with SMTP id q0MoalnMgVEtuq0NJa2tJG; Tue, 12 Apr 2016 15:37:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460475429; bh=dIInGKuthJgM0MF9sewgAYpyNgboo1mgOhOymO9oAA4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=wqzoB6GC5a7paIbggQZmGi8SGp34GABhOc8f5cUMnvm7VEx7k75f9uzt8RpbwIsDo PFRwfwxQzs4uKXRDWQRznJg7BDDYVAiPkqYoOwZOWkZ+zBJkuEyXOEE1moop53rdoO mYa2JYitArM3bbQkHYJxxeKnYTX7BsQUMrWQm+lJ5MSjr6ZQV+MYK+WdBYkit0s4jZ b1KbayfM85AkY4nubfTENsPDJviWBlCwgibZ+5SMWcEnAKJpUdWHNsUUaIScBWlzRU eTJM5zxq32Yo5KLOUz1yPWmSsYpGTkSSCmOZZVp+Nt1RLEHyT+e2nRy8Yqqh01DX/K 6aiAroqdnTxMQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id hTd41s0071nMCLR01Td6me; Tue, 12 Apr 2016 15:37:09 +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 u3CFau9A002696; Tue, 12 Apr 2016 11:36:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3CFatd1002693; Tue, 12 Apr 2016 11:36:55 -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: Tue, 12 Apr 2016 11:36:55 -0400 Message-ID: <87fuuqg7oo.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Remaining Happy Eyeballs work 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, 12 Apr 2016 15:37:11 -0000 "Olle E. Johansson" writes: >> Another possibility is: >> >> - the registration message flow from the UA is sufficient to keep the >> cached reachability information up to date > ...and how is that different from SIP outbound simple (SOS) ? Well, it's already implmented, basically. Dale From nobody Tue Apr 12 10:54: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 C9D1F12D0E0 for ; Tue, 12 Apr 2016 10:54:23 -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 d5ubyg_V8p8r for ; Tue, 12 Apr 2016 10:54:22 -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 20ECA12B044 for ; Tue, 12 Apr 2016 10:54:22 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id q2VKaoWpWBE6Oq2W5arwDz; Tue, 12 Apr 2016 17:54:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460483661; bh=SOT84F54xqFj1OhTp9MsaY4ajHi8/PqOm3G/lM25lSk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=EyWNbHA9l0L8f2XcQoicXFqElQz+wmlN0v/b93w/0VqOABG76lBL13KCE9ADqIhPA F/1pkcVJfc0KxuUhP4IqeR+v+ngXcDp5EEcoCG+ZXnBBoImVDBrHyNPrrJJgNvp2Oc rroFATG2Re6AUrKaTmjQQMJXySxBkMoIC7kO06OAQRjPkzOwSaij1OIqGdkbOc2vSi dI96sLxgnAUv8+AuHNt41MjxyJvLZu+A0Q9720QDUwuAfhr3N7V+49pLsIwRXVJF00 3VYDePjD2JKWXjTVP7J/7ROyupQ87hlovHmXu8w9hIe7SJoboGbsqU1FVcYOQZd5EU m+nv3TYBURTnA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-09v.sys.comcast.net with comcast id hVuL1s00H1nMCLR01VuLhi; Tue, 12 Apr 2016 17:54:21 +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 u3CHsKUv010138; Tue, 12 Apr 2016 13:54:20 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3CHsIeq010134; Tue, 12 Apr 2016 13:54:18 -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, oej@edvina.net In-Reply-To: <4D166172-5CB6-4DF1-8968-6383CA8430D2@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 12 Apr 2016 13:54:18 -0400 Message-ID: <8760vmg1bp.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Changing UA address 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, 12 Apr 2016 17:54:24 -0000 "Olle E. Johansson" writes: >>> THat's a missing part of SIP. Outbound only handles dialog set-up, >>> but not failures in-dialog or failover in-dialog. The work on mobility >>> with TURN helps media and maybe SIP should document a similar >>> solution. >> >> That could become a complicated piece of work. Is there a perceived >> need for it? > > More and more with mobile to wifi handover. It's been discussed many times > at SIPit and other meetings of SIP developers. Ah, yes, that's the use case. I've been outlining a solution for re-addressing. So far what I have is: - The UA detects that the previous address may be no longer functioning by the loss of RTP. (Loss of RTCP actually, since the dialog may be on-hold.) This can happen within maybe 10 seconds, if the default RTCP interval of 5 seconds is used. - The UA sends a STUN request to a STUN server near its edge proxy to determine if its address has changed. The STUN respond contains the UA's current public address. Assuming that the public address has changed: - The UA reregisters, using Outbound with the current address (at the UA's interface), which will be recorded by the registrar with the UA's current public address. Since Outbound is being used, this registration replaces the UA's previous registration. This rebinds the UA's GRUU to the current address, so that the dialog's route set remains valid. - The UA then does a re-INVITE cycle to correct the session's RTP addresses. That seems like it would work. The slowest part of the process is detecting the changeover, but if the process was triggered by the lower-level networking code deciding to change which interface is preferred, the adjustments could be made before the old address stops working. Dale From nobody Tue Apr 12 11:09: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 C39C512E27A for ; Tue, 12 Apr 2016 11:09: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 L2waVUg3wuER for ; Tue, 12 Apr 2016 11:09:11 -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 D37CF12D71B for ; Tue, 12 Apr 2016 11:09:11 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by comcast with SMTP id q2epaoXoYBE6Oq2kRas0Ws; Tue, 12 Apr 2016 18:09:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460484551; bh=883punbuaJfAubHWPGBnFQl1PI05KmVFpfzUMULOHWg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Kb3k2Iymu85/PckeaAiNdm2u/Zn4RqepBLpWHC6F4rAu81YajnseizwM5LYrhYiL8 WANQRyi8rmOQmswDDuJ7OpFK4pk1hP+JUwdx3XySa/rBlmrFAqN/ctr6JjdLQZKRO6 o7HeWFiTVCpi43X7kuDYqBDJ0UkA15VREoQttK0dOeOEH1vbOInE3fmm2CxJP/pNVG he0g5QFNuCIgOvikZTINubWHkD+67GNDeoL4+GcpSQlQCRzJguUkfSYp2O2UC5xdeb DjrHsShvdLLvgZuBCZ+kSKR5exxPNhFcdp8/QwX4p3o0LbMm4JeDMN7SsvMHTwEeVV eSdoYFdCgnrFg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id hW9A1s00V1nMCLR01W9BH6; Tue, 12 Apr 2016 18:09:11 +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 u3CI9A8l010939; Tue, 12 Apr 2016 14:09:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3CI99jL010935; Tue, 12 Apr 2016 14:09: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: Paul Kyzivat In-Reply-To: <570C15F3.3020300@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 12 Apr 2016 14:09:09 -0400 Message-ID: <871t6ag0my.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Remaining Happy Eyeballs work 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, 12 Apr 2016 18:09:13 -0000 Paul Kyzivat writes: > My impression is that people are using registration as sufficient > evidence to use the resulting "flow" for outbound calls. That of course > doesn't mean much for UDP, but it does for TCP with or without TLS. But > such is not formally allowed. > > One of the key points of outbound is for "safe" connection reuse. For > that, "simple" (one flow) outbound would be useful. And it would also be > useful with SIP over DTLS. For UDP, the registration *is* sufficient evidence that a particular address can be used to contact the edge proxy, and since there is no connection, the flow can be reused legitimately. The limitation is that the registration proved connectivity only at the moment of registration, not at the moment of call initiation. What is the risk that an address that the UA could register to is not unreachable? If that risk is high enough, the UA needs a way to rapidly fail over to another destination address. The difficulty with single-flow Outbound is that the proxy/registrar still have to implement the full array of Outbound behaviors. Those behaviors aren't that complicated, but the description in the RFC is daunting. (Only 2/3 of proxy/registrars at the last SIPit supported Outbound.) (Oddly, it seems to me that the registrar is not allowed to limit the number of registered flows for a single UA -- If the registrar wants to limit the number of flows, it has to reject a REGISTER with a specific error code so that the UA doesn't keep trying to reestablish the failed flow, and there is no such error code.) In regard to SIP/DTLS, as long as the DTLS state is not updated by the passage of ordinary packets, it isn't a connection, it's just a transport (or we can define it as such!), and can be reused without special arrangements in the same way UDP can be. Dale From nobody Tue Apr 12 11:23:59 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 1400A12DA70 for ; Tue, 12 Apr 2016 11:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-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 1yhyKZKv9sZc for ; Tue, 12 Apr 2016 11:23:46 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 318C612D615 for ; Tue, 12 Apr 2016 11:23:46 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 2so39579256ioy.1 for ; Tue, 12 Apr 2016 11:23:46 -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:date:message-id:subject:from:to :cc; bh=l/Guhx1gT5cIt3Y5/3EKLFNXn3wfRWuDT8iDHdkItFU=; b=EBQ05HuVbowE/WrQmSqj1SAGKFjnHJTqzeQ0ZKzM+f9ZC8N7aDIyptQ+K/D+my4rq7 gCYtn9i1uFQ881RJ7orjGcbHUBVglLiVMoWsdYMHPAs619gnecKU2eo1XtqN06k3WoJW EvYScTNcE55eojv8XjFpWM+rCZ3WPDJ5KEKLDrZZcaHxEbjSpMjV0AzrZO5rfjN+n1cz vJ1StH7Ox093mI25tnD5UntyR27DE81JbLMuG3d19yc0jfoKO5LOrkOZGPvSR2fF5/8w /cFF7ztPeRBGtL7qMW46dSvFUoJ0S+8iAFj+j9qNz5gp7imTKPi2LU3v3N+pauifxpsO /lMw== 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:date :message-id:subject:from:to:cc; bh=l/Guhx1gT5cIt3Y5/3EKLFNXn3wfRWuDT8iDHdkItFU=; b=NaReQXIdo4b6PtgkWQkQ5mPqrrxaNVwdueuGh0UIH4gI29r+UrntG/gNJWcaZsRhbF am/tIkfJKn16AmzvzBSuiHlePQdqQJ/SC/ItStwRFutmUJknwZXgWqHuK32I7FsChBjT pvIDo9odARF/0R2/MeOGy0oQBK0izZiMpNusQGZSZGOMdAJvACNG8Bam8BOBdOIkbrb1 AkedWegHKT91jgJM+/G5sl0qcug0LusdksFvT6Afqq+TinV7gdcQ/jL9DdXCtVuAN9I8 i8Jud7EzemwvGE1goguXVZvGNcH1vq1fcQRTKr/NYcI1CdL4ZzOv3k7q0B2lNse28+we Am4w== X-Gm-Message-State: AOPr4FWMmPoYij7JU0QlLUbnOZfob9POwqyIekonJbYshr598AFQoSLtKFJ2IQ5FMM8tpA== X-Received: by 10.107.16.104 with SMTP id y101mr5201456ioi.148.1460485425460; Tue, 12 Apr 2016 11:23:45 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id l67sm21105230ioa.13.2016.04.12.11.23.44 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 11:23:44 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id gy3so94948211igb.0 for ; Tue, 12 Apr 2016 11:23:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.129.103 with SMTP id nv7mr26399189igb.24.1460485424278; Tue, 12 Apr 2016 11:23:44 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Tue, 12 Apr 2016 11:23:44 -0700 (PDT) In-Reply-To: <8760vmg1bp.fsf@hobgoblin.ariadne.com> References: <4D166172-5CB6-4DF1-8968-6383CA8430D2@edvina.net> <8760vmg1bp.fsf@hobgoblin.ariadne.com> Date: Tue, 12 Apr 2016 14:23:44 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b414128ea2b4e05304dc211 Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Changing UA address 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, 12 Apr 2016 18:23:57 -0000 --047d7b414128ea2b4e05304dc211 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 12, 2016 at 1:54 PM, Dale R. Worley wrote: > I've been outlining a solution for re-addressing. So far what I have > is: > > - The UA detects that the previous address may be no longer functioning > by the loss of RTP. (Loss of RTCP actually, since the dialog may be > on-hold.) This can happen within maybe 10 seconds, if the default > RTCP interval of 5 seconds is used. > > - The UA sends a STUN request to a STUN server near its edge proxy to > determine if its address has changed. The STUN respond contains the > UA's current public address. Assuming that the public address has > changed: > > - The UA reregisters, using Outbound with the current address (at the > UA's interface), which will be recorded by the registrar with the UA's > current public address. Since Outbound is being used, this > registration replaces the UA's previous registration. This rebinds > the UA's GRUU to the current address, so that the dialog's route set > remains valid. > > - The UA then does a re-INVITE cycle to correct the session's RTP > addresses. > > That seems like it would work. The slowest part of the process is > detecting the changeover, but if the process was triggered by the > lower-level networking code deciding to change which interface is > preferred, the adjustments could be made before the old address stops > working. > Few corrections/clarifications: - If you are using SIP outbound, you more often detect IP address change via SIP Keep-Alive timeout. Also, your signaling path might not be the same as media. For instance if you are using ICE with hosted PBX, a lot of RTP traffic is local to the office, but the signaling is going to central server. - You can detect new local IP address by running the registration and looking at received and rport parameters in VIA. - UDP Edge Proxy is typically configured to either use symmetric SIP signaling (i.e. overwrite remote IP:Port from contact resolution with IP:Port from which registration was received). TCP/TLS Edge proxy will typically reuse the existing flow. This works much better then using STUN to determine the client public IP, since it saves the round trip and gives the proxy an indication that the client is behind NAT vs public IP. If you see STUN used for anything except SIP UDP Keep-Alive or ICE, it typically means it is used for a wrong purpose and something will break. - What happens to transactions in progress when IP changes? Specifically what happens to an outstanding INVITE transaction which can take a long time to complete? In solutions that we developed, if there is transaction in progress, client will resend the the last request when connection is re-established in attempt to recover the transaction. - We also normally run transactions running over TCP or TLS with UDP re-transmit timers to deal with situations where TCP connection gets torn down and does not provide a clear indication that message was not delivered. This also simplifies proxy process for request received over TCP or TLS and forwarded to UDP. - Request re-transmits update remote and rport values for transaction. This allows transaction recovery when connection is reestablished. Regards, _____________ Roman Shpount --047d7b414128ea2b4e05304dc211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 12, 2016 at 1:54 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:
I've been outlining a solution for re-addressing.=C2=A0 So far wh= at I have
is:

- The UA detects that the previous address may be no longer functioning
=C2=A0 by the loss of RTP.=C2=A0 (Loss of RTCP actually, since the dialog m= ay be
=C2=A0 on-hold.)=C2=A0 This can happen within maybe 10 seconds, if the defa= ult
=C2=A0 RTCP interval of 5 seconds is used.

- The UA sends a STUN request to a STUN server near its edge proxy to
=C2=A0 determine if its address has changed.=C2=A0 The STUN respond contain= s the
=C2=A0 UA's current public address.=C2=A0 Assuming that the public addr= ess has
=C2=A0 changed:

- The UA reregisters, using Outbound with the current address (at the
=C2=A0 UA's interface), which will be recorded by the registrar with th= e UA's
=C2=A0 current public address.=C2=A0 Since Outbound is being used, this
=C2=A0 registration replaces the UA's previous registration.=C2=A0 This= rebinds
=C2=A0 the UA's GRUU to the current address, so that the dialog's r= oute set
=C2=A0 remains valid.

- The UA then does a re-INVITE cycle to correct the session's RTP
=C2=A0 addresses.

That seems like it would work.=C2=A0 The slowest part of the process is
detecting the changeover, but if the process was triggered by the
lower-level networking code deciding to change which interface is
preferred, the adjustments could be made before the old address stops
working.

Few corrections/clarifications= :

- If you are using SIP outbound, you more often = detect IP address change via SIP Keep-Alive timeout. Also, your signaling p= ath might not be the same as media. For instance if you are using ICE with = hosted PBX, a lot of RTP traffic is local to the office, but the signaling = is going to central server.

- You can detect new l= ocal IP address by running the registration and looking at received and rpo= rt parameters in VIA.

- UDP Edge Proxy is typicall= y configured to either use symmetric SIP signaling (i.e. overwrite remote I= P:Port from contact resolution with IP:Port from which registration was rec= eived). TCP/TLS Edge proxy will typically reuse the existing flow.=C2=A0 Th= is works much better then using STUN to determine the client public IP, sin= ce it saves the round trip and gives the proxy an indication that the clien= t is behind NAT vs public IP. If you see STUN used for anything except SIP = UDP Keep-Alive or ICE, it typically means it is used for a wrong purpose an= d something will break.

- What happens to transact= ions in progress when IP changes? Specifically what happens to an outstandi= ng INVITE transaction which can take a long time to complete? In solutions = that we developed, if there is transaction in progress, client will resend = the the last request when connection is re-established in attempt to recove= r the transaction.=C2=A0

- We also normally ru= n transactions running over TCP or TLS with UDP re-transmit timers to deal = with situations where TCP connection gets torn down and does not provide a = clear indication that message was not delivered. This also simplifies proxy= process for request received over TCP or TLS and forwarded to UDP.


--047d7b414128ea2b4e05304dc211-- From nobody Tue Apr 12 11:47: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 8FC4E12DA6A for ; Tue, 12 Apr 2016 11:47:33 -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 Qmd7KGGnxwJ3 for ; Tue, 12 Apr 2016 11:47:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8F12DA15 for ; Tue, 12 Apr 2016 11:47:31 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0E42993C2A2; Tue, 12 Apr 2016 18:46:30 +0000 (UTC) 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: <87fuuqg7oo.fsf@hobgoblin.ariadne.com> Date: Tue, 12 Apr 2016 20:47:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56579B3F-F22C-412F-93FF-9C30910889D6@edvina.net> References: <87fuuqg7oo.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] Remaining Happy Eyeballs work 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, 12 Apr 2016 18:47:33 -0000 > On 12 Apr 2016, at 17:36, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >>> Another possibility is: >>>=20 >>> - the registration message flow from the UA is sufficient to keep = the >>> cached reachability information up to date >> ...and how is that different from SIP outbound simple (SOS) ? >=20 > Well, it's already implmented, basically. Yes, but not documented - the problem is how the server reach the client using the contact URI. The contact doesn=E2=80=99t always follow the actual flow, so we=E2=80=99re ending up with two=20 TCP or TLS flows. SIP outbound flow reuse is what most people use here - but as far as I know, it=E2=80=99s not documented. For dual stack/Happy Eyeballs from UDP we can use outbound to make the decision about address family when we have time - at = registration time. When that decision is made and proven, we can continue to=20 use that flow and NOT have to make a new happy eyeballs-like discovery for each SIP request sent over that flow. This means that we simplify quite a lot and do not affect call setup time.=20 How the SIP UA makes a decision and connection test can be discussed - send two different REGISTER with different contacts, two with two contacts (one per address family) or one at a time, that=E2=80=99s just a few suggestions. We won=E2=80=99t have a merge = problem and can suggest something that is not too had to implement. In this case outbound is used to maintain a relationship between registration state and flow use. If an INVITE (or another transaction)=20= fails, the UA will have to re-start flow setup. For any SIP transaction, there needs to be at least one proven flow. /O= From nobody Tue Apr 12 12: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 9BDF512E693 for ; Tue, 12 Apr 2016 12: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 cKGlL5-x6gZs for ; Tue, 12 Apr 2016 12:08:58 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15712D0BA for ; Tue, 12 Apr 2016 12:08:53 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6DA3293DE44; Tue, 12 Apr 2016 19:07:54 +0000 (UTC) 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: <871t6ag0my.fsf@hobgoblin.ariadne.com> Date: Tue, 12 Apr 2016 21:08:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38787D21-09D3-4E4D-B387-E79F17B423EB@edvina.net> References: <871t6ag0my.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] Remaining Happy Eyeballs work 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, 12 Apr 2016 19:09:00 -0000 > On 12 Apr 2016, at 20:09, Dale R. Worley wrote: >=20 > Paul Kyzivat writes: >> My impression is that people are using registration as sufficient=20 >> evidence to use the resulting "flow" for outbound calls. That of = course=20 >> doesn't mean much for UDP, but it does for TCP with or without TLS. = But=20 >> such is not formally allowed. >>=20 >> One of the key points of outbound is for "safe" connection reuse. For=20= >> that, "simple" (one flow) outbound would be useful. And it would also = be=20 >> useful with SIP over DTLS. >=20 > For UDP, the registration *is* sufficient evidence that a particular > address can be used to contact the edge proxy, and since there is no > connection, the flow can be reused legitimately. >=20 > The limitation is that the registration proved connectivity only at = the > moment of registration, not at the moment of call initiation. What is > the risk that an address that the UA could register to is not > unreachable? If that risk is high enough, the UA needs a way to = rapidly > fail over to another destination address. >=20 > The difficulty with single-flow Outbound is that the proxy/registrar > still have to implement the full array of Outbound behaviors. Those > behaviors aren't that complicated, but the description in the RFC is > daunting. (Only 2/3 of proxy/registrars at the last SIPit supported > Outbound.) SO the big question is what the diff between SOutbound and Outbound is. Can we remove some of these behaviours with a one-legged SOutbound? Make it easier? We=E2=80=99re looking for something like XMPP behaviour. You have a working flow that starts with a registration. If there=E2=80=99s no flow established, no party sends any requests in = any direction. I know that XMPP doesn=E2=80=99t have UDP and see my previous email for some ideas on UDP behaviour. >=20 > (Oddly, it seems to me that the registrar is not allowed to limit the > number of registered flows for a single UA -- If the registrar wants = to > limit the number of flows, it has to reject a REGISTER with a specific > error code so that the UA doesn't keep trying to reestablish the = failed > flow, and there is no such error code.) Hmm. Interesting. We haven=E2=80=99t been able to test outbound with any = flows at SIPit, so that problem is beyond the current testing scope :-) >=20 > In regard to SIP/DTLS, as long as the DTLS state is not updated by the > passage of ordinary packets, it isn't a connection, it's just a > transport (or we can define it as such!), and can be reused without > special arrangements in the same way UDP can be. I think we need a special thread for DTLS/udp. There=E2=80=99s some very interesting stuff one can do there.=20 /O= From nobody Fri Apr 15 13:14:36 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 1BA5712D119; Fri, 15 Apr 2016 13:14:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415201435.17440.22424.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 13:14:35 -0700 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-05.txt 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, 15 Apr 2016 20:14:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-05.txt Pages : 10 Date : 2016-04-15 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 13:21: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 0B2FA12DC5C for ; Fri, 15 Apr 2016 13:21:16 -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 6PColxV547aD for ; Fri, 15 Apr 2016 13:21:15 -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 0E30C12DBD0 for ; Fri, 15 Apr 2016 13:21:14 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id rACWarX2GVEturAEsaEp0t; Fri, 15 Apr 2016 20:21:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460751674; bh=75AOvQ5W76BvxTK/i8D94udUDoqcy0Peamw5234cruA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=IxXFPzFqblwk8qzvO6thYti3Z2+FHCEDEI6JitX0m6ChKd48GsuFRlf4S/amwfVN4 xmL3a8fveijgTm4YfTpSu4WDIBmzD98S8nlwo2XFWt2h3LPhw79Nu3JkfjqkweFhT3 CTYCJcVywkAJynId72rBXjTpp14ei1wqEKkucCjeav20BHteetLLm9ASjkjK7K5Os3 jvI+F5ZLNwjTogSuJg8nW34euLRe989+jnAIao3FXxsT67z4U7dY5yxIZR8WBoiSYM Mj55qVP+5GIYDX/tGK+qD1WAA00F+DpS4mFOdPklu9PMFfYMJoZlHkHrI5y5oxMD/i kFYgDLRSB/kTA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id ikMD1s00Q1nMCLR01kMDMb; Fri, 15 Apr 2016 20:21:14 +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 u3FKLC84012944 for ; Fri, 15 Apr 2016 16:21:12 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3FKLBNV012941; Fri, 15 Apr 2016 16:21:11 -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: Fri, 15 Apr 2016 16:21:11 -0400 Message-ID: <87k2jyaaiw.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack-05 submitted, based on WGLC 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, 15 Apr 2016 20:21:16 -0000 I've just submitted draft-ietf-sipcore-dns-dual-stack-05. The changes since -04 (which was put up for WGLC) are: Simplified the acknowledgments. Improve wording and punctuation. Rewrote Section 4 [previously section 5, concerning RFC 6724] based on critiques on the Sipcore list. Included an example by Adam Roach. Replaced "RR's" with "records" per suggestion by Jean Mahoney. I did not remove the statement that RFC 3484 is the predecessor of RFC 6724, because that's not mentioned in the bodies of any of the referenced RFCs, and I don't want the reader to overlook it. There is also an open issue regarding the correct copyright permissions for quoting parts of RFC 3263 that Jean Mahoney is tracking down, but resolving might change only the copyright boilerplate, not the technical content. I believe that takes care of all of the WGLC comments. If you have an interest in this draft, please check that your concerns have been answered. Dale From nobody Fri Apr 15 15:23: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 C4EFD12E111 for ; Fri, 15 Apr 2016 15:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 TCcxsD5U3oZ6 for ; Fri, 15 Apr 2016 15:23:16 -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 83CCC12E110 for ; Fri, 15 Apr 2016 15:23:16 -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.14.9) with ESMTPSA id u3FMNF9r000333 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 15 Apr 2016 17:23:16 -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: <571169D3.4000509@nostrum.com> Date: Fri, 15 Apr 2016 17:23:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Draft minutes posted 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, 15 Apr 2016 22:23:18 -0000 [as chair] I've posted a draft version of the minutes from last week's SIPCORE meeting online: Presentation https://www.ietf.org/proceedings/95/minutes/minutes-95-sipcore Please send any corrections or additions to me and Jean before the end of April. Thanks! /a From nobody Mon Apr 18 08:41:59 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 AB20E12E133 for ; Mon, 18 Apr 2016 08:41:57 -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 8ZEpfNDErtpd for ; Mon, 18 Apr 2016 08:41:56 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 B6DB612E131 for ; Mon, 18 Apr 2016 08:41:54 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by comcast with SMTP id sBJ3aMIOM9sFTsBJBaf4GV; Mon, 18 Apr 2016 15:41:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460994113; bh=EuP33P4lQKTG+xzOMsfj4pfzbpWLaRi0LxQnTiW4WUo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=V3aQBZXr76y6iIEAGHWqZ2nf66sRXb5fc2X5nm3JExn3oTm2raFJSzEhuQ/JXXzm1 7VViBwuIafNrC+4Hb1UDwZvDGcLGPPSaNGt40Td/EdItKFWFxy9bBB9y9xqdSBHf+a AmznFRYqYR6uMBRpwsM3s/BmEX7g0PB4WbWXdT7ksjSwDhwa7/chduEwSDCG8hudU0 eYN7EdTP+KmsFQmfFxfDXlNKkZjN17qYrfJlltzWHJ5SPXT4UNBM8qALn6Jcub0OgE 0zxWYGrRmxcSNs9IeIhY+bDXowKfitZ4+80bFDI8flG8flEg8S1NLonBdLTCpKws2t S33TgXHTg5Q/g== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-18v.sys.comcast.net with comcast id jrhs1s00W1nMCLR01rht8n; Mon, 18 Apr 2016 15:41:53 +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 u3IFfqwF012369; Mon, 18 Apr 2016 11:41:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3IFfpYn012366; Mon, 18 Apr 2016 11:41:51 -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: worley@ariadne.com (Dale R. Worley) In-Reply-To: <87k2jyaaiw.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 18 Apr 2016 11:41:51 -0400 Message-ID: <87lh4adiv4.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack-05 submitted, based on WGLC 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, 18 Apr 2016 15:41:57 -0000 I've already made a fix to the 06 version, noting that Adam supplied the example of combined 3263/6724 processing. And a second fix to correct the references to 6157 vs. the references to 6724. Dale From nobody Mon Apr 18 11:46: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 C2F6512E574 for ; Mon, 18 Apr 2016 11:46:05 -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 gbM8KPQk_qtF for ; Mon, 18 Apr 2016 11:46:04 -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 6584F12E573 for ; Mon, 18 Apr 2016 11:46:02 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by comcast with SMTP id sEAHaBbPT2R4wsEBNaHpk7; Mon, 18 Apr 2016 18:46:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461005161; bh=T/Q7ZjaW2GQQmwiDUfXug9ji/q7/EnOkfZdyKQ1Uh3w=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rq8imzYw+hPDLs6cRUUVrLAF6zh0DVNGw99hPeh44TnClOISsrNuc5PjmRnfph++2 GOdy6FNXiRO8pumHAYOZSRDoKOgyL+UTUtv/m0E38IcnOou/kCURft5mz1KDHZsslg RTFRnOkr9u/+dhyhv1CbwRwjfobngvnElssxPgoYFVj3RYPPVm8isYQM8/4S1h/qS6 f+mjwpSu05+kunLqDDuDDTC+6/0WtBqKHJEI+u6loNpGLJK1y7oLnUUhAKi8zJGMXm HhDUtrWtAzOpth99MwkbFs6uyAmZlmuCkhNB/BNDfov95NUgj+lSFmdp085zxYeRCo B4tBJupBFTvSA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id jum11s00C1nMCLR01um1HT; Mon, 18 Apr 2016 18:46:01 +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 u3IIk09X022224 for ; Mon, 18 Apr 2016 14:46:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3IIk0JV022221; Mon, 18 Apr 2016 14:46:00 -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, 18 Apr 2016 14:46:00 -0400 Message-ID: <87inzedac7.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] A couple of points on Happy Eyeballs 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, 18 Apr 2016 18:46:05 -0000 I think that Happy Eyeballs for SIP differs from Happy Eyeballs for HTTP in three significant ways. These facts have implications for the work that needs to be done for SIP H.E. It seems to me that these do not require defining new mechanisms, but do add further considerations to how H.E. is carried out. A. There are few "opportunistic" connections in SIP, that is, where a device must talk to an address with no prior warning that it would need to do so. The consequence is that it's not likely to be valuable to define complex new features (e.g., how to send simultaneous redundant requests to multiple servers) to handle the case where the device has no existing flow to the destination. B. In SIP, there will often be "idle flows", that is, flows that were established in the past but which have had no traffic for a considerable amount of time. If there are multiple flows to the destination that are idle, it will be desirable to test the flows to see which of them is still functioning before sending the request on one flow. Testing can be done with an Outbound keep-alive (CR-LF or STUN), a transport keep-alive, a REGISTER request, or an OPTIONS request with Max-Forwards of 0. C. In SIP, flows can be very long-lived, lasting for many days. If a device has cached a record that a target for a destination is unreachable and that target is preferred to the target that the device is now using, the target should be periodically re-tested to see if it has become reachable. I believe that it is already known that a device should not cache information obtained from DNS beyond the time-to-live recorded with the information it received. This ensures that a device will properly refresh cached DNS information. There is a question of whether there is any need for a device to rotate its usage of several equal-weighted host names in SRV records. E.g., if only one host is responding when a large number of UAs start, then all of their flows may be established with one host, leaving the others idle. If the UAs stay active for many days, traffic may remain unbalanced for many days. Should there be a requirement that devices periodically reestablish their flows (and thus re-execute the SRV procedures)? Discussion: A. In regard to flows, it seems that almost all of them will fall into two classes: 1. between a UA and its edge or home proxy 2. between two devices whose communication is administratively configured Case 1 has all the problems of Happy Eyeballs, but the UA has the advantage that it will register well in advance of participating in calls, and during registration it can determine how to talk to the proxy. Almost all of the time, that communication choice will work for subsequent INVITEs. The solution to case 2 will likely be manually configured by an administrator and so the device won't have to determine which apparent targets are in fact reachable. It is true that some SIP connections will be opportunistic. For instance, the sipX system implemented ISN dialing (http://www.freenum.org/cookbook/), so dialing "890*1234" would route to a phone at Nortel in Ottawa. The proxy that forwarded that INVITE would be contacting a server for nortel.ca that it had no established flow with. But that is a small minority of the traffic. B. There will often be idle flows, flows that have been established and are still thought to be active, but on which no message has passed for a substantial time, and thus may no longer be active. (My understanding is that in HTTP idle connections are torn down relatively quickly.) The commonness of idle flows means that we need a rapid way to test an existing flow to determine if it's still active. E.g., in the HTTP case, H.E. races the establishment of an IPv4 TCP connection with the establishment of an IPv6 TCP connection. In a SIP case, both of these connections may already exist, but the device can't be certain if either of them is still working. So it's useful to first send some sort of test on each connection, and whichever one is proved active first is used to send the request. For a UA which wants to send a message to a proxy, if its registration uses Outbound, then it can use a CR-LF or STUN keepalive as a probe of the connection. OTOH, if Outbound is being used, the UA may have been sending keepalives frequently enough that the risk of failed flows is low enough to ignore. For a UA not using Outbound, it can either send an updated REGISTER request or send an OPTIONS request with a Max-Forwards value of 0. In other cases, the device is limited to sending an OPTIONS request or using a transport-level keepalive request (if the transport has one). C. H.E. specifies that a device should cache reachability information about the alternative targets for a destination. But a SIP registration flow may well last long enough that the cached indication of the non-reachability of an address no longer be correct. So H.E. for SIP should specify that if a device caches information that a preferred address is not reachable, the device should periodically re-test the address to see if it should be used in preference to the address the device is currently using. Dale From nobody Wed Apr 20 10:40:59 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 6884712EFCA for ; Wed, 20 Apr 2016 10:40:58 -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 pqFn_yFeMdFv for ; Wed, 20 Apr 2016 10:40:56 -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 23F0312EFC7 for ; Wed, 20 Apr 2016 10:40:56 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id n67so59615488vkf.3 for ; Wed, 20 Apr 2016 10:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=xM7Qw9UcMnwM8LSt2vsUH+OmetLLexikHm74N9aJBCk=; b=Ga8xAjVhVxk52F4FEz3hQMx3XSGyt6QM7lU9wd2/HwkYvvyY6k5hZWLw36E9VrCUK6 2X3xGtJHxPzyqhsUFVClGcKEp5kY2isNs+82z7OLuxixjybVfaV4sA/1aWBErAYNhupZ nKb7ojRTWZ3d/AhEroVYs+j+pJELE2sM16xFRSTUfFYk/0mcBvOyXJ0Xx0NG0xC6gpxs zR8BcyxWBjewKrCcm+f80ydkq59Swzx3zMnWSV4H46nTWr5/NKUZgoang2fTAS5QVHHJ jrA6nz8CDc5v5Ew6pFy+nm5gjVy0I6cHA7r9kDtjIdffOPcv7AfcoYTg8OQ46geUUNL9 CTFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=xM7Qw9UcMnwM8LSt2vsUH+OmetLLexikHm74N9aJBCk=; b=BfBzUuSgoQhtuMBYzf9xhuCebgb1c1IA/QNSUWQuu7OteFtHpc5VQXdC11ASqI7Mie oJzf3FiJ4GcV7aeKWK5J8Kr/nrSLC/hZ8xSp05o8tjNHVitFv7DBtc1b81fsxeevdgws PIErcvXbHeg35uY98uynHQfIa7kRzM6berYwvAcnzTk0Q+fuvrHdZiVH+wwXZ38gE6vy EnxK9jNj+w8bZvpiuHnbsZgchmAtOoOR7vFP+zwPuC3V63f4OroN8OAUqMCOZGAUrkp+ RcdXTPUOo9bgozNeLebAmvwS4m1oF5xnvvRp6K3Wt2QsjWt7b0LQNwGAS0Apou0/xk+q zKHQ== X-Gm-Message-State: AOPr4FUxubQac5vqKwtJVfgM0CxL/SZD82W2azHPUXL0kllEf/gFN9fOdSGjpP7W+UyB7CaIIkhI6NjZtIajQQ== MIME-Version: 1.0 X-Received: by 10.176.0.239 with SMTP id 102mr5338555uaj.33.1461174055188; Wed, 20 Apr 2016 10:40:55 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 20 Apr 2016 10:40:55 -0700 (PDT) Date: Wed, 20 Apr 2016 13:40:55 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a113cceec83c0920530ee18b7 Archived-At: Subject: [sipcore] SIP Authentication/Authorization Problem Statement 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, 20 Apr 2016 17:40:58 -0000 --001a113cceec83c0920530ee18b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, A group of us decided to take a step back from discussing the SIP OAuth document, and instead decided to discuss the SIP Authentication/Authorization problem to allow the different parties to articulate where they are coming from and what problem they are trying to solve. I started this discussion with the following text as a starting point: The following is a simplified classic SIP deployment model: +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned an outbound SIP proxy and all SIP communications must go through that SIP proxy. The SIP Proxy plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy. We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the user= authentication and services authorization to separate network element(s): The first goal is to =E2=80=9Coutsource=E2=80=9D the user authentication pa= rt to a separate IdP entity, to allow the SIP user to use his credentials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application Servers. The second goal is to =E2=80=9Coutsource=E2=80=9D the authorization part to= a separate network element to allow the *administrator* to grant access to the basic services provided by the SIP Proxy and the various advanced services provided by the SIP Application Servers. I also explained that my motivation for this work is to address few *Enterprise* use cases, which mainly include the Single-Sign On use case where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP services, and a centralized authorization use case where the administrator is able to authorize access to these services from one network element. Jon suggested that there are several use cases that we should be looking at, and he articulated these use cases as follows: But more to my point (and I suspect Adam's) there are several distinct use cases for SIP that involve adding a secure attestation about the user to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to whether the meat of that assertion is fetched from a network service or generated locally at a SIP entity - for SIP Identity-like architectures, one might say the IdP-ish component of the architecture (the "authentication service") is typically colocated with a proxy server, for example. In some cases, the relying parties downstream are in the same trust domain as the attester/user, and in some cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality of the user's identity. This encompasses interworking with external protocols like Jingle and WebRTC, this encompasses preventing impersonation, this potentially involves enterprise use cases like Cullen was talking about. Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdiffer= ent trust domains=E2=80=9D as follows: I believe he's referring to the kind of use cases addressed by RFC 4474 and by the work currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use by an entity in a completely unrelated trust domain. There's also the matter of interdomain trait-based authorization (independent of identity). The introduction section of RFC 4484 is a really good place to start if you're not familiar with the concept. At this point Adam, as SIPCORE chair, suggested that we continue this discussion on the SIPCORE mailing list. So here we are=E2=80=A6 Regards, Rifaat --001a113cceec83c0920530ee18b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

All,

=C2=A0

A group of us decided to take a step back from discussing the SIP OAuth = document, and instead decided to discuss the SIP Authentication/Authorizati= on problem to allow the different parties to articulate where they are comi= ng from and what problem they are trying to solve.

=C2=A0

I started this discussion with the following text as a starting point:

=C2=A0

The following is= a simplified classic SIP deployment model:

=C2=A0

<= font face=3D"monospace, monospace">+--------= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=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 UA=C2=A0=C2=A0 |------------= ----------| Proxy=C2=A0 |----------------------| Server |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

+--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--------+=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--------= +

=C2=A0

With this model, the endpoint is assigned an outbou= nd SIP proxy and all SIP communications must go through that SIP proxy.

=C2=A0

The SIP Proxy plays 3 different roles:

1. Authentication Server (SIP Registrar)

2. Authorization Server

3. Service provider, e.g. basic calls, ca= ll forwarding, call transfer, etc.

=C2=A0

SIP Application Se= rvers provide advanced SIP services, e.g. conference, presence, etc. Applic= ation Servers usually have their own authentication and authorization mecha= nism that is separate from the one provided by the SIP proxy.

=C2=A0

We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D= the user authentication and services authorization to separate network ele= ment(s):

=C2=A0

= The first goal is to =E2=80=9Coutsource=E2= =80=9D the user authentication part to a separate=C2=A0IdP entity, to allow= the SIP user to use his credentials with the IdP to register with the SIP = Proxy and get basic SIP services, and to get access to the advanced service= s provided by the SIP Application Servers.

=C2=A0

=

The second= goal is to =E2=80=9Coutsource=E2=80=9D the authorization part to a separat= e network element to allow the *administrator* to grant access to the basic= services provided by the SIP Proxy and the various advanced services provi= ded by the SIP Application Servers.

=C2=A0

I also explained that my motivation for this work is= to address few *Enterprise* use cases, which mainly include the Single-Sig= n On use case where the user is authenticated once and as a result the user= gets access to a variety of SIP and non-SIP services, and a centralized au= thorization use case where the administrator is able to authorize access to= these services from one network element.

<= span style=3D"font-size:10pt;line-height:15.3333px">

=C2=A0

Jon suggested that there are seve= ral use cases that we should be looking at, and he articulated these use ca= ses as follows:

=C2=A0=

But more to my point (and I suspect Adam's) there are seve= ral distinct use cases for SIP that involve adding a secure attestation abo= ut the user to SIP requests that will be consumed and trusted by some entit= y downstream. This problem is probably generic to whether the meat of that = assertion is fetched from a network service or generated locally at a SIP e= ntity - for SIP Identity-like architectures, one might say the IdP-ish comp= onent of the architecture (the "authentication service") is typic= ally colocated with a proxy server, for example. In some cases, the relying= parties downstream are in the same trust domain as the attester/user, and = in some cases they could be in a different trust domain. It may vary in the= confidentiality of the assertion, or indeed in the confidentiality of the = user's identity. This encompasses interworking with external protocols = like Jingle and WebRTC, this encompasses preventing impersonation, this pot= entially involves enterprise use cases like Cullen was talking about.=C2=A0=

=C2=A0

=C2=A0

Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdi= fferent trust domains=E2=80=9D as follows:

= =C2=A0

I believe he's referr= ing to the kind of use cases addressed by RFC 4474 and by the work currentl= y going on in STIR -- ones in which some entity asserts the identity of a p= arty in the call for use by an entity in a completely unrelated trust domai= n.

There's a= lso the matter of interdomain trait-based authorization (independent of ide= ntity). The introduction section of RFC 4484 is a really good place to star= t if you're not familiar with the concept.

=C2=A0

=C2=A0


At this point Adam, as SIPCORE chair, suggested that we co= ntinue this discussion on the SIPCORE mailing list. So here we are=E2=80=A6=

=C2=A0

Regards,

=C2=A0Rifaat

--001a113cceec83c0920530ee18b7-- From nobody Wed Apr 20 11:18: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 44C1112E2FB for ; Wed, 20 Apr 2016 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 WMTsbiDNw95d for ; Wed, 20 Apr 2016 11:17:54 -0700 (PDT) Received: from ucol19pa16.eemsg.mail.mil (ucol19pa16.eemsg.mail.mil [214.24.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0A512E0D5 for ; Wed, 20 Apr 2016 11:17:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,510,1454976000"; d="scan'208";a="199807893" Received: from edge-cols03.mail.mil ([131.64.107.103]) by ucol19pa16.eemsg.mail.mil with ESMTP; 20 Apr 2016 18:17:51 +0000 Received: from UCOLHPQQ.easf.csd.disa.mil (131.64.107.43) by edge-cols03.mail.mil (131.64.107.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 20 Apr 2016 18:17:51 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.99]) by UCOLHPQQ.easf.csd.disa.mil ([131.64.107.43]) with mapi id 14.03.0266.001; Wed, 20 Apr 2016 18:17:50 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [Non-DoD Source] [sipcore] SIP Authentication/Authorization Problem Statement Thread-Index: AQHRmyvWvfEZS4Lq0U6+1b3xOmflSJ+TKujA Date: Wed, 20 Apr 2016 18:17:49 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF9FEFE302@UCOLHU2J.easf.csd.disa.mil> References: 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: Subject: Re: [sipcore] [Non-DoD Source] SIP Authentication/Authorization Problem Statement 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, 20 Apr 2016 18:18:01 -0000 SGksIFJpZmFhdCBhbmQgYWxsOg0KDQpJbiBhZGRpdGlvbiwgeW91IGNhbiBhbHNvIGxvb2sgaW50 byBTSVAtcmVsYXRlZCBhdXRoZW50aWNhdGlvbi9BdXRob3JpemF0aW9uIGluIERJQU1FVEVSL1JB RElVUyBSRkNzIC0gaG93IHRoZXkgdXNlIEFBQSBwcm90b2NvbCB0byBhZGRyZXNzIHRoZSBzaW1p bGFyIHByb2JsZW0uDQoNCkJSL1JhZGhpa2EgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUmlmYWF0IFNoZWtoLVl1c2VmDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIwLCAyMDE2 IDE6NDEgUE0NClRvOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBbTm9uLURvRCBTb3VyY2Vd IFtzaXBjb3JlXSBTSVAgQXV0aGVudGljYXRpb24vQXV0aG9yaXphdGlvbiBQcm9ibGVtIFN0YXRl bWVudA0KDQpBbGwsDQoNCiANCg0KQSBncm91cCBvZiB1cyBkZWNpZGVkIHRvIHRha2UgYSBzdGVw IGJhY2sgZnJvbSBkaXNjdXNzaW5nIHRoZSBTSVAgT0F1dGggZG9jdW1lbnQsIGFuZCBpbnN0ZWFk IGRlY2lkZWQgdG8gZGlzY3VzcyB0aGUgU0lQIEF1dGhlbnRpY2F0aW9uL0F1dGhvcml6YXRpb24g cHJvYmxlbSB0byBhbGxvdyB0aGUgZGlmZmVyZW50IHBhcnRpZXMgdG8gYXJ0aWN1bGF0ZSB3aGVy ZSB0aGV5IGFyZSBjb21pbmcgZnJvbSBhbmQgd2hhdCBwcm9ibGVtIHRoZXkgYXJlIHRyeWluZyB0 byBzb2x2ZS4NCg0KIA0KDQpJIHN0YXJ0ZWQgdGhpcyBkaXNjdXNzaW9uIHdpdGggdGhlIGZvbGxv d2luZyB0ZXh0IGFzIGEgc3RhcnRpbmcgcG9pbnQ6DQoNCiANCg0KVGhlIGZvbGxvd2luZyBpcyBh IHNpbXBsaWZpZWQgY2xhc3NpYyBTSVAgZGVwbG95bWVudCBtb2RlbDoNCg0KIA0KDQorLS0tLS0t LS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tKw0KDQp8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgU0lQICAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCBTSVAgQXBwfA0KDQp8ICAgVUEgICB8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwgUHJveHkgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCBTZXJ2ZXIgfA0KDQp8 ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgfA0KDQorLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KDQogDQoNCldpdGggdGhpcyBt b2RlbCwgdGhlIGVuZHBvaW50IGlzIGFzc2lnbmVkIGFuIG91dGJvdW5kIFNJUCBwcm94eSBhbmQg YWxsIFNJUCBjb21tdW5pY2F0aW9ucyBtdXN0IGdvIHRocm91Z2ggdGhhdCBTSVAgcHJveHkuDQoN CiANCg0KVGhlIFNJUCBQcm94eSBwbGF5cyAzIGRpZmZlcmVudCByb2xlczoNCg0KMS4gQXV0aGVu dGljYXRpb24gU2VydmVyIChTSVAgUmVnaXN0cmFyKQ0KDQoyLiBBdXRob3JpemF0aW9uIFNlcnZl cg0KDQozLiBTZXJ2aWNlIHByb3ZpZGVyLCBlLmcuIGJhc2ljIGNhbGxzLCBjYWxsIGZvcndhcmRp bmcsIGNhbGwgdHJhbnNmZXIsIGV0Yy4NCg0KIA0KDQpTSVAgQXBwbGljYXRpb24gU2VydmVycyBw cm92aWRlIGFkdmFuY2VkIFNJUCBzZXJ2aWNlcywgZS5nLiBjb25mZXJlbmNlLCBwcmVzZW5jZSwg ZXRjLiBBcHBsaWNhdGlvbiBTZXJ2ZXJzIHVzdWFsbHkgaGF2ZSB0aGVpciBvd24gYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0 aGUgb25lIHByb3ZpZGVkIGJ5IHRoZSBTSVAgcHJveHkuDQoNCiANCg0KV2Ugd291bGQgbGlrZSB0 byBkaXNjdXNzIHRoZSBpZGVhIG9mIOKAnG91dHNvdXJjaW5n4oCdIHRoZSB1c2VyIGF1dGhlbnRp Y2F0aW9uIGFuZCBzZXJ2aWNlcyBhdXRob3JpemF0aW9uIHRvIHNlcGFyYXRlIG5ldHdvcmsgZWxl bWVudChzKToNCg0KIA0KDQpUaGUgZmlyc3QgZ29hbCBpcyB0byDigJxvdXRzb3VyY2XigJ0gdGhl IHVzZXIgYXV0aGVudGljYXRpb24gcGFydCB0byBhIHNlcGFyYXRlIElkUCBlbnRpdHksIHRvIGFs bG93IHRoZSBTSVAgdXNlciB0byB1c2UgaGlzIGNyZWRlbnRpYWxzIHdpdGggdGhlIElkUCB0byBy ZWdpc3RlciB3aXRoIHRoZSBTSVAgUHJveHkgYW5kIGdldCBiYXNpYyBTSVAgc2VydmljZXMsIGFu ZCB0byBnZXQgYWNjZXNzIHRvIHRoZSBhZHZhbmNlZCBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUg U0lQIEFwcGxpY2F0aW9uIFNlcnZlcnMuDQoNCiANCg0KVGhlIHNlY29uZCBnb2FsIGlzIHRvIOKA nG91dHNvdXJjZeKAnSB0aGUgYXV0aG9yaXphdGlvbiBwYXJ0IHRvIGEgc2VwYXJhdGUgbmV0d29y ayBlbGVtZW50IHRvIGFsbG93IHRoZSAqYWRtaW5pc3RyYXRvciogdG8gZ3JhbnQgYWNjZXNzIHRv IHRoZSBiYXNpYyBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgU0lQIFByb3h5IGFuZCB0aGUgdmFy aW91cyBhZHZhbmNlZCBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgU0lQIEFwcGxpY2F0aW9uIFNl cnZlcnMuDQoNCiANCg0KSSBhbHNvIGV4cGxhaW5lZCB0aGF0IG15IG1vdGl2YXRpb24gZm9yIHRo aXMgd29yayBpcyB0byBhZGRyZXNzIGZldyAqRW50ZXJwcmlzZSogdXNlIGNhc2VzLCB3aGljaCBt YWlubHkgaW5jbHVkZSB0aGUgU2luZ2xlLVNpZ24gT24gdXNlIGNhc2Ugd2hlcmUgdGhlIHVzZXIg aXMgYXV0aGVudGljYXRlZCBvbmNlIGFuZCBhcyBhIHJlc3VsdCB0aGUgdXNlciBnZXRzIGFjY2Vz cyB0byBhIHZhcmlldHkgb2YgU0lQIGFuZCBub24tU0lQIHNlcnZpY2VzLCBhbmQgYSBjZW50cmFs aXplZCBhdXRob3JpemF0aW9uIHVzZSBjYXNlIHdoZXJlIHRoZSBhZG1pbmlzdHJhdG9yIGlzIGFi bGUgdG8gYXV0aG9yaXplIGFjY2VzcyB0byB0aGVzZSBzZXJ2aWNlcyBmcm9tIG9uZSBuZXR3b3Jr IGVsZW1lbnQuDQoNCg0KDQoNCiANCg0KSm9uIHN1Z2dlc3RlZCB0aGF0IHRoZXJlIGFyZSBzZXZl cmFsIHVzZSBjYXNlcyB0aGF0IHdlIHNob3VsZCBiZSBsb29raW5nIGF0LCBhbmQgaGUgYXJ0aWN1 bGF0ZWQgdGhlc2UgdXNlIGNhc2VzIGFzIGZvbGxvd3M6DQoNCiANCg0KQnV0IG1vcmUgdG8gbXkg cG9pbnQgKGFuZCBJIHN1c3BlY3QgQWRhbSdzKSB0aGVyZSBhcmUgc2V2ZXJhbCBkaXN0aW5jdCB1 c2UgY2FzZXMgZm9yIFNJUCB0aGF0IGludm9sdmUgYWRkaW5nIGEgc2VjdXJlIGF0dGVzdGF0aW9u IGFib3V0IHRoZSB1c2VyIHRvIFNJUCByZXF1ZXN0cyB0aGF0IHdpbGwgYmUgY29uc3VtZWQgYW5k IHRydXN0ZWQgYnkgc29tZSBlbnRpdHkgZG93bnN0cmVhbS4gVGhpcyBwcm9ibGVtIGlzIHByb2Jh Ymx5IGdlbmVyaWMgdG8gd2hldGhlciB0aGUgbWVhdCBvZiB0aGF0IGFzc2VydGlvbiBpcyBmZXRj aGVkIGZyb20gYSBuZXR3b3JrIHNlcnZpY2Ugb3IgZ2VuZXJhdGVkIGxvY2FsbHkgYXQgYSBTSVAg ZW50aXR5IC0gZm9yIFNJUCBJZGVudGl0eS1saWtlIGFyY2hpdGVjdHVyZXMsIG9uZSBtaWdodCBz YXkgdGhlIElkUC1pc2ggY29tcG9uZW50IG9mIHRoZSBhcmNoaXRlY3R1cmUgKHRoZSAiYXV0aGVu dGljYXRpb24gc2VydmljZSIpIGlzIHR5cGljYWxseSBjb2xvY2F0ZWQgd2l0aCBhIHByb3h5IHNl cnZlciwgZm9yIGV4YW1wbGUuIEluIHNvbWUgY2FzZXMsIHRoZSByZWx5aW5nIHBhcnRpZXMgZG93 bnN0cmVhbSBhcmUgaW4gdGhlIHNhbWUgdHJ1c3QgZG9tYWluIGFzIHRoZSBhdHRlc3Rlci91c2Vy LCBhbmQgaW4gc29tZSBjYXNlcyB0aGV5IGNvdWxkIGJlIGluIGEgZGlmZmVyZW50IHRydXN0IGRv bWFpbi4gSXQgbWF5IHZhcnkgaW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgYXNzZXJ0aW9u LCBvciBpbmRlZWQgaW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgdXNlcidzIGlkZW50aXR5 LiBUaGlzIGVuY29tcGFzc2VzIGludGVyd29ya2luZyB3aXRoIGV4dGVybmFsIHByb3RvY29scyBs aWtlIEppbmdsZSBhbmQgV2ViUlRDLCB0aGlzIGVuY29tcGFzc2VzIHByZXZlbnRpbmcgaW1wZXJz b25hdGlvbiwgdGhpcyBwb3RlbnRpYWxseSBpbnZvbHZlcyBlbnRlcnByaXNlIHVzZSBjYXNlcyBs aWtlIEN1bGxlbiB3YXMgdGFsa2luZyBhYm91dC4gDQoNCiANCg0KIA0KDQpBZGFtIGVsYWJvcmF0 ZWQgb24gSm9u4oCZcyBzdGF0ZW1lbnQgdGhhdCB0YWxrcyBhYm91dCDigJxkaWZmZXJlbnQgdHJ1 c3QgZG9tYWluc+KAnSBhcyBmb2xsb3dzOg0KDQogDQoNCkkgYmVsaWV2ZSBoZSdzIHJlZmVycmlu ZyB0byB0aGUga2luZCBvZiB1c2UgY2FzZXMgYWRkcmVzc2VkIGJ5IFJGQyA0NDc0IGFuZCBieSB0 aGUgd29yayBjdXJyZW50bHkgZ29pbmcgb24gaW4gU1RJUiAtLSBvbmVzIGluIHdoaWNoIHNvbWUg ZW50aXR5IGFzc2VydHMgdGhlIGlkZW50aXR5IG9mIGEgcGFydHkgaW4gdGhlIGNhbGwgZm9yIHVz ZSBieSBhbiBlbnRpdHkgaW4gYSBjb21wbGV0ZWx5IHVucmVsYXRlZCB0cnVzdCBkb21haW4uDQoN ClRoZXJlJ3MgYWxzbyB0aGUgbWF0dGVyIG9mIGludGVyZG9tYWluIHRyYWl0LWJhc2VkIGF1dGhv cml6YXRpb24gKGluZGVwZW5kZW50IG9mIGlkZW50aXR5KS4gVGhlIGludHJvZHVjdGlvbiBzZWN0 aW9uIG9mIFJGQyA0NDg0IGlzIGEgcmVhbGx5IGdvb2QgcGxhY2UgdG8gc3RhcnQgaWYgeW91J3Jl IG5vdCBmYW1pbGlhciB3aXRoIHRoZSBjb25jZXB0Lg0KDQogDQoNCiANCg0KDQoNCg0KQXQgdGhp cyBwb2ludCBBZGFtLCBhcyBTSVBDT1JFIGNoYWlyLCBzdWdnZXN0ZWQgdGhhdCB3ZSBjb250aW51 ZSB0aGlzIGRpc2N1c3Npb24gb24gdGhlIFNJUENPUkUgbWFpbGluZyBsaXN0LiBTbyBoZXJlIHdl IGFyZeKApg0KDQogDQoNClJlZ2FyZHMsDQoNCiBSaWZhYXQNCg0K From nobody Wed Apr 20 11:59: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 C7A7F12D134 for ; Wed, 20 Apr 2016 11:59:22 -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 21wRAnlqfBCZ for ; Wed, 20 Apr 2016 11:59:19 -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 6C8E612E64D for ; Wed, 20 Apr 2016 11:59:16 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3KIqdpE003202; Wed, 20 Apr 2016 14:59:15 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22bg1udtxg-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Apr 2016 14:59:15 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.235]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 14:59:13 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Authentication/Authorization Problem Statement Thread-Index: AQHRmyvRNkZuGRVP1kiSpar7gSS7n5+TBM8A Date: Wed, 20 Apr 2016 18:59:12 +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.3.160329 x-originating-ip: [10.96.12.93] Content-Type: multipart/alternative; boundary="_000_D33D1373186631jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-20_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-1603290000 definitions=main-1604200298 Archived-At: Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 20 Apr 2016 18:59:23 -0000 --_000_D33D1373186631jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am definitely supportive of trying to find a common problem statement her= e to reconcile the numerous ways that we seem to be specifying identity ass= ertions in SIP (and in related real-time communication protocols). Authoriz= ation, because of its implications for policy and trust models, has been a = thornier topic for us to cover, though I'm open to developing a problem sta= tement for it as well (RFC4484 notably never got any farther than requireme= nts). I think to get this into the shape we'd need a problem statement to be, we = need to be more specific about what we mean by "IdP" and "Authorization Ser= ver" in the starting point discussion below. If an IdP is just an entity th= at provides some kind of token that can be added to SIP messages asserting = the identity of the originator, for example, then we have a number of overl= apping mechanisms that do that. Getting a single sign-on experience, such t= hat a SIP entities is authenticated by a service that creates an assertion = added to SIP requests that can be validated and trusted by entities receivi= ng the request is probably achievable without any new protocol work. But If= we mean something more specific by "IdP," we need to narrow in on what tha= t is. For an "Authorization Server," well, I think the function of that entity is= somewhat unclear in the statement below. I agree that today, authorization= decisions are made by the entities that receive SIP requests based on some= sort of local policy predicated on trust relationships dictated by the con= troller of the device. The distinction between the owner or controller of t= he device and the "administrator" of this authorization architecture isn't = clear to me from reading this, nor is it clear what information the "advanc= ed" services residing in app servers might need to make an authorization de= cision. The nature of that information will dictate much of the requirement= s here: to whom can it be revealed, and to whom must it be confidential; ho= w is it structured; etc. My point about "trust domains" below is tied up in questions about the scop= e of the identity and authorization mechanism. Can or should the assertion = be trusted by relying parties who have no previous association with the iss= uer of the token, for example? For the "Authorization Server" function, sin= ce it assumes an "administrator" who can authorize access to a set of resou= rces under its control, I'd imagine that the only relying parties that woul= d accept the token have a very clear prior association with the "administra= tor" (though we'd need to say more about what we imagine it would be). In f= ederated identity models that come up fairly often, you sometimes do have t= rust across domain boundaries that is significantly looser. If that's in sc= ope, that's important to understand. Jon Peterson Neustar, Inc. From: sipcore > o= n behalf of Rifaat Shekh-Yusef > Date: Wednesday, April 20, 2016 at 10:40 AM To: "sipcore@ietf.org" > Subject: [sipcore] SIP Authentication/Authorization Problem Statement All, A group of us decided to take a step back from discussing the SIP OAuth doc= ument, and instead decided to discuss the SIP Authentication/Authorization = problem to allow the different parties to articulate where they are coming = from and what problem they are trying to solve. I started this discussion with the following text as a starting point: The following is a simplified classic SIP deployment model: +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned an outbound SIP proxy and all SIP= communications must go through that SIP proxy. The SIP Proxy plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, pre= sence, etc. Application Servers usually have their own authentication and a= uthorization mechanism that is separate from the one provided by the SIP pr= oxy. We would like to discuss the idea of =93outsourcing=94 the user authenticat= ion and services authorization to separate network element(s): The first goal is to =93outsource=94 the user authentication part to a sepa= rate IdP entity, to allow the SIP user to use his credentials with the IdP = to register with the SIP Proxy and get basic SIP services, and to get acces= s to the advanced services provided by the SIP Application Servers. The second goal is to =93outsource=94 the authorization part to a separate = network element to allow the *administrator* to grant access to the basic s= ervices provided by the SIP Proxy and the various advanced services provide= d by the SIP Application Servers. I also explained that my motivation for this work is to address few *Enterp= rise* use cases, which mainly include the Single-Sign On use case where the= user is authenticated once and as a result the user gets access to a varie= ty of SIP and non-SIP services, and a centralized authorization use case wh= ere the administrator is able to authorize access to these services from on= e network element. Jon suggested that there are several use cases that we should be looking at= , and he articulated these use cases as follows: But more to my point (and I suspect Adam's) there are several distinct use = cases for SIP that involve adding a secure attestation about the user to SI= P requests that will be consumed and trusted by some entity downstream. Thi= s problem is probably generic to whether the meat of that assertion is fetc= hed from a network service or generated locally at a SIP entity - for SIP I= dentity-like architectures, one might say the IdP-ish component of the arch= itecture (the "authentication service") is typically colocated with a proxy= server, for example. In some cases, the relying parties downstream are in = the same trust domain as the attester/user, and in some cases they could be= in a different trust domain. It may vary in the confidentiality of the ass= ertion, or indeed in the confidentiality of the user's identity. This encom= passes interworking with external protocols like Jingle and WebRTC, this en= compasses preventing impersonation, this potentially involves enterprise us= e cases like Cullen was talking about. Adam elaborated on Jon=92s statement that talks about =93different trust do= mains=94 as follows: I believe he's referring to the kind of use cases addressed by RFC 4474 and= by the work currently going on in STIR -- ones in which some entity assert= s the identity of a party in the call for use by an entity in a completely = unrelated trust domain. There's also the matter of interdomain trait-based authorization (independe= nt of identity). The introduction section of RFC 4484 is a really good plac= e to start if you're not familiar with the concept. At this point Adam, as SIPCORE chair, suggested that we continue this discu= ssion on the SIPCORE mailing list. So here we are=85 Regards, Rifaat --_000_D33D1373186631jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I am definitely supportive of trying to find a common problem statemen= t here to reconcile the numerous ways that we seem to be specifying identit= y assertions in SIP (and in related real-time communication protocols). Aut= horization, because of its implications for policy and trust models, has been a thornier topic for us to cover, th= ough I'm open to developing a problem statement for it as well (RFC4484 not= ably never got any farther than requirements).

I think to get this into the shape we'd need a problem statement to be= , we need to be more specific about what we mean by "IdP" and &qu= ot;Authorization Server" in the starting point discussion below. If an= IdP is just an entity that provides some kind of token that can be added to SIP messages asserting the identity of the originator= , for example, then we have a number of overlapping mechanisms that do that= . Getting a single sign-on experience, such that a SIP entities is authenti= cated by a service that creates an assertion added to SIP requests that can be validated and trusted by en= tities receiving the request is probably achievable without any new protoco= l work. But If we mean something more specific by "IdP," we need = to narrow in on what that is. 

For an "Authorization Server," well, I think the function of= that entity is somewhat unclear in the statement below. I agree that today= , authorization decisions are made by the entities that receive SIP request= s based on some sort of local policy predicated on trust relationships dictated by the controller of the device. The disti= nction between the owner or controller of the device and the "administ= rator" of this authorization architecture isn't clear to me from readi= ng this, nor is it clear what information the "advanced" services residing in app servers might need to ma= ke an authorization decision. The nature of that information will dictate m= uch of the requirements here: to whom can it be revealed, and to whom must = it be confidential; how is it structured; etc. 

My point about "trust domains" below is tied up in questions= about the scope of the identity and authorization mechanism. Can or should= the assertion be trusted by relying parties who have no previous associati= on with the issuer of the token, for example? For the "Authorization Server" function, since it assumes an &qu= ot;administrator" who can authorize access to a set of resources under= its control, I'd imagine that the only relying parties that would accept t= he token have a very clear prior association with the "administrator" (though we'd need to say more about what we imag= ine it would be). In federated identity models that come up fairly often, y= ou sometimes do have trust across domain boundaries that is significantly l= ooser. If that's in scope, that's important to understand.

Jon Peterson
Neustar, Inc.

All,

 

A group of us decided to take a step back from discussing the = SIP OAuth document, and instead decided to discuss the SIP Authentication/A= uthorization problem to allow the different parties to articulate where they are coming from and what problem they are= trying to solve.

 

I started this discussion with the following text as a startin= g point:

 

The follo= wing is a simplified classic SIP deployment model:

 

+----= ----+           =            +--------&= #43;            = ;          +--------+<= /span>

| &n= bsp;      |       &n= bsp;            = ;  | SIP    |      &= nbsp;           &nbs= p;   | SIP App|

| &n= bsp; UA   |----------------------| Proxy  |-----------------= -----| Server |

| &n= bsp;      |      &nb= sp;            =    |        |   = ;            &n= bsp;      |      &nb= sp; |

+----= ----+           =            +--------&= #43;            &nbs= p;         +--------+<= /span>

 

With this= model, the endpoint is assigned an outbound SIP proxy and all SIP communic= ations must go through that SIP proxy.

 

The SIP P= roxy plays 3 different roles:<= /font>

1. Authen= tication Server (SIP Registrar)

2. Author= ization Server

3. Servic= e provider, e.g. basic calls, call forwarding, call transfer, etc.

 

SIP Appli= cation Servers provide advanced SIP services, e.g. conference, presence, et= c. Application Servers usually have their own authentication and authorizat= ion mechanism that is separate from the one provided by the SIP proxy.

 

We would = like to discuss the idea of =93outsourcing=94 the user authentication and s= ervices authorization to separate network element(s):

 

The first= goal is to =93outsource=94 the user authentication part to a separate = ;IdP entity, to allow the SIP user to use his credentials with the IdP to r= egister with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP A= pplication Servers.

 

The secon= d goal is to =93outsource=94 the authorization part to a separate network e= lement to allow the *administrator* to grant access to the basic services p= rovided by the SIP Proxy and the various advanced services provided by the SIP Application Servers.

 

I also explained that my motivation for this work is to addres= s few *Enterprise* use cases, which mainly include the Single-Sign On use c= ase where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP = services, and a centralized authorization use case where the administrator = is able to authorize access to these services from one network element.


 

Jon suggested that there are several use cases that we should = be looking at, and he articulated these use cases as follows:=

 

But more to my point (and I suspect Adam's) there are several distinct u= se cases for SIP that involve adding a secure attestation about the user to= SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to= whether the meat of that assertion is fetched from a network service or ge= nerated locally at a SIP entity - for SIP Identity-like architectures, one = might say the IdP-ish component of the architecture (the "authentication service") is typically = colocated with a proxy server, for example. In some cases, the relying part= ies downstream are in the same trust domain as the attester/user, and in so= me cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in = the confidentiality of the user's identity. This encompasses interworking w= ith external protocols like Jingle and WebRTC, this encompasses preventing = impersonation, this potentially involves enterprise use cases like Cullen was talking about. <= /span>

 

 

Adam elaborated on Jon=92s statement that talks about =93diffe= rent trust domains=94 as follows:

 

I believe h= e's referring to the kind of use cases addressed by RFC 4474 and by the wor= k currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use b= y an entity in a completely unrelated trust domain.

There's = also the matter of interdomain trait-based authorization (independent of id= entity). The introduction section of RFC 4484 is a really good place to sta= rt if you're not familiar with the concept.

 

 


At this point Adam, as SIPCORE chair, suggested that we contin= ue this discussion on the SIPCORE mailing list. So here we are=85

 

Regards,

 Rifaat

--_000_D33D1373186631jonpetersonneustarbiz_-- From nobody Wed Apr 20 13:22: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 21E3912E5DD for ; Wed, 20 Apr 2016 13:22:00 -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 zrwdCWzGA9Ay for ; Wed, 20 Apr 2016 13:21:55 -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 E28FA12E4AB for ; Wed, 20 Apr 2016 13:21:54 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-91-5717e4e12e93 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.48.12926.1E4E7175; Wed, 20 Apr 2016 22:21:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 22:21:52 +0200 From: Christer Holmberg To: "Peterson, Jon" , Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Authentication/Authorization Problem Statement Thread-Index: AQHRmzbHQNeoy3/gyEa/1zAbNvutZ5+TS7pg Date: Wed, 20 Apr 2016 20:21:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F6D436@ESESSMB209.ericsson.se> References: 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F6D436ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2J7lO7DJ+LhBpePCFqcabC02Pmilc3i 649NbA7MHjtn3WX3WLLkJ5PHjobnzAHMUVw2Kak5mWWpRfp2CVwZ13acZyt4/omx4u8h7wbG ozcYuxg5OSQETCQuNU9hgrDFJC7cW8/WxcjFISRwhFHiyLc+VghnCaPEocnb2bsYOTjYBCwk uv9pg5giAs2MEjddQHqFBTwlzs9axAxiiwh4SbxtvckOYRtJ3P3RyAZiswioSrzo3Qhm8wr4 SnQ8vs4CYgsJ1Eo8mHcT7AZOAXOJNX8vg81hBLrn+6k1YHFmAXGJW0/mQ90pILFkz3lmCFtU 4uXjf6wQtpLE2sPbWSDq8yVu/fvGDrFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdja EssWvmaGsc8ceMyELL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCkHdzyW3UH4+U3 jocYBTgYlXh4E7rFw4VYE8uKK3MPMUpwMCuJ8PZcBwrxpiRWVqUW5ccXleakFh9ilOZgURLn zY78FyYkkJ5YkpqdmlqQWgSTZeLglGpgFFufX2S0wNCwcvPa35MPzeXw/dV5xE+u94MyZz6z 3k4nAX7p/7YZQRMyDl0QO7i3onZT7YeSbR2XooJTl529+CH73ykz5hd/v/31quiJl25NE9jk 33lGmFNqeflpwcK3N+ZLteUL7wjl3ryk4aRLbX6EMuO5r1ObOG+oGDG/YCtjm3m1fU+bEktx RqKhFnNRcSIAlwo8frACAAA= Archived-At: Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 20 Apr 2016 20:22:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F6D436ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for your input! A comment below. ... >I think to get this into the shape we'd need a problem statement to be, we= need to be more specific about what we mean by "IdP" and "Authorization Se= rver" in the starting point discussion below. If an IdP is just an >entity = that provides some kind of token that can be added to SIP messages assertin= g the identity of the originator, for example, then we have a number of ove= rlapping mechanisms that do that. Getting a single sign->on experience, suc= h that a SIP entities is authenticated by a service that creates an asserti= on added to SIP requests that can be validated and trusted by entities rece= iving the request is probably achievable without any >new protocol work. Bu= t If we mean something more specific by "IdP," we need to narrow in on what= that is. We will probably need different definitions of "IdP", depending on the use-= case. For example, in the 3GPP use-case the IdP is just an entity that prov= ides some kind of token. However, even in that case, carrying that token in SIP does require some pr= otocol work. Regards, Christer From: sipcore > o= n behalf of Rifaat Shekh-Yusef > Date: Wednesday, April 20, 2016 at 10:40 AM To: "sipcore@ietf.org" > Subject: [sipcore] SIP Authentication/Authorization Problem Statement All, A group of us decided to take a step back from discussing the SIP OAuth doc= ument, and instead decided to discuss the SIP Authentication/Authorization = problem to allow the different parties to articulate where they are coming = from and what problem they are trying to solve. I started this discussion with the following text as a starting point: The following is a simplified classic SIP deployment model: +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned an outbound SIP proxy and all SIP= communications must go through that SIP proxy. The SIP Proxy plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, pre= sence, etc. Application Servers usually have their own authentication and a= uthorization mechanism that is separate from the one provided by the SIP pr= oxy. We would like to discuss the idea of "outsourcing" the user authentication = and services authorization to separate network element(s): The first goal is to "outsource" the user authentication part to a separate= IdP entity, to allow the SIP user to use his credentials with the IdP to r= egister with the SIP Proxy and get basic SIP services, and to get access to= the advanced services provided by the SIP Application Servers. The second goal is to "outsource" the authorization part to a separate netw= ork element to allow the *administrator* to grant access to the basic servi= ces provided by the SIP Proxy and the various advanced services provided by= the SIP Application Servers. I also explained that my motivation for this work is to address few *Enterp= rise* use cases, which mainly include the Single-Sign On use case where the= user is authenticated once and as a result the user gets access to a varie= ty of SIP and non-SIP services, and a centralized authorization use case wh= ere the administrator is able to authorize access to these services from on= e network element. Jon suggested that there are several use cases that we should be looking at= , and he articulated these use cases as follows: But more to my point (and I suspect Adam's) there are several distinct use = cases for SIP that involve adding a secure attestation about the user to SI= P requests that will be consumed and trusted by some entity downstream. Thi= s problem is probably generic to whether the meat of that assertion is fetc= hed from a network service or generated locally at a SIP entity - for SIP I= dentity-like architectures, one might say the IdP-ish component of the arch= itecture (the "authentication service") is typically colocated with a proxy= server, for example. In some cases, the relying parties downstream are in = the same trust domain as the attester/user, and in some cases they could be= in a different trust domain. It may vary in the confidentiality of the ass= ertion, or indeed in the confidentiality of the user's identity. This encom= passes interworking with external protocols like Jingle and WebRTC, this en= compasses preventing impersonation, this potentially involves enterprise us= e cases like Cullen was talking about. Adam elaborated on Jon's statement that talks about "different trust domain= s" as follows: I believe he's referring to the kind of use cases addressed by RFC 4474 and= by the work currently going on in STIR -- ones in which some entity assert= s the identity of a party in the call for use by an entity in a completely = unrelated trust domain. There's also the matter of interdomain trait-based authorization (independe= nt of identity). The introduction section of RFC 4484 is a really good plac= e to start if you're not familiar with the concept. At this point Adam, as SIPCORE chair, suggested that we continue this discu= ssion on the SIPCORE mailing list. So here we are... Regards, Rifaat --_000_7594FB04B1934943A5C02806D1A2204B37F6D436ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 = ;

Thanks for= your input! A comment below.

 = ;

…

 

>I think to ge= t this into the shape we'd need a problem statement to be, we need to be more specific about what we mean by "IdP" and "A= uthorization Server" in the starting point discussion below. If an IdP= is just an >entity that provides some kin= d of token that can be added to SIP messages asserting the identity of the originator, for example, then we have a number of overlapp= ing mechanisms that do that. Getting a single sign-&g= t;on experience, such that a SIP entities is authenticated by a service that cr= eates an assertion added to SIP requests that can be validated and trusted = by entities receiving the request is probably achievable without any >new protocol work. But If we = mean something more specific by "IdP," we need to narrow in on what that is. 

 

We will probably need different defin= itions of “IdP”, depending on the use-case. For example, in the= 3GPP use-case the IdP is just an entity that provides some kind of token.

 

However, even in that case, carrying = that token in SIP does require some protocol work.

 

Regards,

 

Christer

 

 

 

From: sipcore <sipcore-bounces@ietf.org> on behalf of Rifaat Shekh-Yusef <<= a href=3D"mailto:rifaat.ietf@gmail.com">rifaat.ietf@gmail.com>
Date: Wednesday, April 20, 2016 at 10:40 AM
To: "sipcore@ietf.org&q= uot; <sipcore@ietf.org>
Subject: [sipcore] SIP Authentication/Authorization Problem Statemen= t

 

All,

 

A group of= us decided to take a step back from discussing the SIP OAuth document, and= instead decided to discuss the SIP Authentication/Authorization problem to allow the different parties to articulate where they are coming= from and what problem they are trying to solve.

 

I started = this discussion with the following text as a starting point:

 

The following is a simplified classic SIP deployment model:<= span style=3D"font-size:10.5pt;color:#500050">

 

+--------+        &= nbsp;           &nbs= p; +--------+         =              &#= 43;--------+=

|        |   &nbs= p;             =      | SIP    |   &n= bsp;            = ;      | SIP App|

|   UA   |----------------------| Proxy  |= ----------------------| Server |

|        |   &nbs= p;            &= nbsp;     |        |=             &nb= sp;         |   &nbs= p;    |

+--------+        &= nbsp;           &nbs= p; +--------+          = ;            &#= 43;--------+=

 

With this model, the endpoint is assigned an outbound SIP proxy and= all SIP communications must go through that SIP proxy.

 

The SIP Proxy plays 3 different roles:

1. Authentication Server (SIP Registrar)

2. Authorization Server

3. Service provider, e.g. basic calls, call forwarding, call transf= er, etc.

 

SIP Application Servers provide advanced SIP services, e.g. confere= nce, presence, etc. Application Servers usually have their own authenticati= on and authorization mechanism that is separate from the one provided by the SIP proxy.

 

We would like to discuss the idea of “outsourcing” the = user authentication and services authorization to separate network element(= s):=

 

The first goal is to “outsource” the user authenticatio= n part to a separate IdP entity, to allow the SIP user to use his cred= entials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the S= IP Application Servers.

 

The second goal is to “outsource” the authorization par= t to a separate network element to allow the *administrator* to grant acces= s to the basic services provided by the SIP Proxy and the various advanced services provided by the SIP Application Servers.<= span style=3D"font-size:10.5pt;color:#500050">

 

I also exp= lained that my motivation for this work is to address few *Enterprise* use = cases, which mainly include the Single-Sign On use case where the user is authenticated once and as a result the user gets ac= cess to a variety of SIP and non-SIP services, and a centralized authorizat= ion use case where the administrator is able to authorize access to these s= ervices from one network element.

 

 

Jon sugges= ted that there are several use cases that we should be looking at, and he a= rticulated these use cases as follows:

 

But more to my point (and I suspect Adam's) there are several distinc= t use cases for SIP that involve adding a secure attestation about the user= to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to whether the= meat of that assertion is fetched from a network service or generated loca= lly at a SIP entity - for SIP Identity-like architectures, one might say th= e IdP-ish component of the architecture (the "authentication service") is typically colocated with a pro= xy server, for example. In some cases, the relying parties downstream are i= n the same trust domain as the attester/user, and in some cases they could = be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality = of the user's identity. This encompasses interworking with external protoco= ls like Jingle and WebRTC, this encompasses preventing impersonation, this = potentially involves enterprise use cases like Cullen was talking about. 

 

 

Adam elabo= rated on Jon’s statement that talks about “different trust doma= ins” as follows:

 

I believe he's = referring to the kind of use cases addressed by RFC 4474 and by the work cu= rrently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use by an entity in a comp= letely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (independe= nt of identity). The introduction section of RFC 4484 is a really good plac= e to start if you're not familiar with the concept.

 

 

 

At this po= int Adam, as SIPCORE chair, suggested that we continue this discussion on t= he SIPCORE mailing list. So here we are…

 

Regards,

 Rifa= at<= /p>

--_000_7594FB04B1934943A5C02806D1A2204B37F6D436ESESSMB209erics_-- From nobody Wed Apr 20 19:07: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 16A8812B05E for ; Wed, 20 Apr 2016 19:07:52 -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 33yUIBg3iEIX for ; Wed, 20 Apr 2016 19:07:51 -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 9271512DC0E for ; Wed, 20 Apr 2016 19:07:51 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by comcast with SMTP id t3zvaL6oSgEHvt422amuxq; Thu, 21 Apr 2016 02:07:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461204470; bh=qvkG1zcchFt8HF3OV9UBIno10nP3ewNmiNKct4YNqsQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FEyXTu5Ko9iVmw4VdgRjy+QnK0A+0btePv1EXl4T05vQwE67OwEtzUy2qvQCLDeCy G+PXyN+Cb1OEFlTkP2EdZqGdgDo4cDbh0qCv33mYsMUSh2XIUJKm02ArAgiyfc4Cav JDfhbo+PJMwvtVA4MFa3CJHCbp9Ik7A1CP0eFQSXKgFfJicYDVPYNbRApUhFKG4Cva cglrk5b7RigFtyBH+aAwRuslpiozFCA9hIonsrmRgvlT5hVI/3SiPTmXs4TJv8sulj 65y+Dsqpj43gM2cV7hIQNt9r3tZN9KFL9agBlzMb2HKQ6moy2Z+nZ1c/GE0ilX2lrX G8r+z4BrFlhJQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id kq7q1s00C1nMCLR01q7qUz; Thu, 21 Apr 2016 02:07:50 +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 u3L27nlZ012394; Wed, 20 Apr 2016 22:07:49 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u3L27nhF012391; Wed, 20 Apr 2016 22:07:49 -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: Rifaat Shekh-Yusef In-Reply-To: (rifaat.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 20 Apr 2016 22:07:49 -0400 Message-ID: <87oa9390ju.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 21 Apr 2016 02:07:53 -0000 Rifaat Shekh-Yusef writes: > The following is a simplified classic SIP deployment model: > > +--------+ +--------+ +--------+ > | | | SIP | | SIP App| > | UA |----------------------| Proxy |----------------------| Server | > | | | | | | > +--------+ +--------+ +--------+ > The first goal is to "outsource" the user authentication part to a > separate IdP entity, to allow the SIP user to use his credentials with the > IdP to register with the SIP Proxy and get basic SIP services, and to get > access to the advanced services provided by the SIP Application Servers. > > The second goal is to "outsource" the authorization part to a separate > network element to allow the *administrator* to grant access to the basic > services provided by the SIP Proxy and the various advanced services > provided by the SIP Application Servers. I have a hard time thinking about this without knowing what the dataflow is. I don't know if this limitation is intrinsic to the subject or just how I think. For example, in the sipX system, calls are only allowed to exit the IP->PSTN gateway if they arrive at the gateway directly from the proxy, and the proxy verifies that the SIP caller is allowed to make a PSTN call to the specific destination. So in that example, the UA contains the user's credentials, which it attaches to the request and sends to the proxy. (Let's neglect how the UA gets a valid nonce.) The proxy authenticates the user and then authorizes the user to make a PSTN call to the particular E.164 number. It then attaches an authorization token to the request (i.e., the IP source address) to the request and sends it to the application server (gateway). It seems like permission to use the app server requires two steps: (1) authentication of the source, and then (2) authorization of the source to use the service. These can be done together in one place (as in the above example) or they can be done in two places. In principle, either step can be done in either the proxy or the app server, or even the UA. The entity that performs a step can outsource it to another server. If either step is done by the proxy, it needs to attach to the request some sort of token indicating that the step has been completed before sending the request to the app server. It seems like there are a dozen or more dataflow patterns that could be used to "outsource" one or both of these steps. Dale From nobody Thu Apr 21 05:46: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 A3FF812EC27 for ; Thu, 21 Apr 2016 05:46:51 -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_H4=-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 tQr0rKsM_ttO for ; Thu, 21 Apr 2016 05:46:49 -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 974C912EC29 for ; Thu, 21 Apr 2016 05:46:48 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-3b-5718cbb62b7a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2D.72.16963.6BBC8175; Thu, 21 Apr 2016 14:46:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 21 Apr 2016 14:46:44 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Authentication/Authorization Problem Statement Thread-Index: AQHRmyvPxYGCWppWbkaplYNn0hLkU5+UYFTA Date: Thu, 21 Apr 2016 12:46:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F71758@ESESSMB209.ericsson.se> References: 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F71758ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7ge620xLhBvc2KljsfNHKZvH1xyY2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStjx9eNbAXnFjNV/Dv0irGB8c9spi5GTg4J AROJjv9TmCFsMYkL99azgdhCAkcYJY4vFOti5AKylzBK/Ds2ibWLkYODTcBCovufNkiNiEC4 xI7dF1lBbGEBL4n+bQuYIeLeEq+nrmSBsI0kpk47yw5iswioSizpOAVWwyvgK/Hh0HtWiF0B Ese29IHFOQUCJZ6cvcQIYjMC3fP91BqwO5kFxCVuPZkPdbOAxJI956FuFpV4+fgfK4StJLH2 8HYWkDOZBfIlrrQoQawSlDg58wnLBEaRWUgmzUKomoWkCiKsKbF+lz5EtaLElO6H7BC2hkTr nLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG1MEtv612MB587niIUYCDUYmH V8FEIlyINbGsuDL3EKMEB7OSCG/aCaAQb0piZVVqUX58UWlOavEhRmkOFiVx3pzIf2FCAumJ JanZqakFqUUwWSYOTqkGRpn9spvml74o3XsrPP7kvgX1/ZwLnmtOdpn2ICmt4IlYUU5D9HWe fcmsDzovWW7Lioz5dNJti3Lfj93zAjvvbf9Ys/N/e/3D4Bg+A9lW996DTNs9lidV3AsWNbxn p1So3M5QmXSAK9u8W65/8swpEw9eDlp2MzbS9Nf/2Yk+j95xpa2LznjapsRSnJFoqMVcVJwI AE5EinSlAgAA Archived-At: Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 21 Apr 2016 12:46:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F71758ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkEgZmV3IGNvbW1lbnRzIG9uIHRoZSB0ZXh0Og0KDQpGaXJzdCwgSSBkb27igJl0IHRo aW5rIHdlIHNob3VsZCBzYXkg4oCcb3V0Ym91bmQgU0lQIHByb3h54oCdLiBUaGF0IG1heSBjb25m dXNlIHBlb3BsZSB3aXRoIFJGQyA1MjU2LCBhbmQgSSBhc3N1bWUgdGhhdCBpcyBub3Qgd2hhdCB5 b3UgYXJlIHRhbGtpbmcgYWJvdXQuIFdoeSBub3Qgc2ltcGx5IGNhbGwgaXQg4oCcU0lQIHJlZ2lz dHJhcuKAnT8NCg0KU2Vjb25kLCB3aGVuIHdlIHRhbGsgYWJvdXQgY3JlZGVudGlhbHMsIHdlIG11 c3QgYmUgY2xlYXIgb24gd2hhdCBraW5kIG9mIGNyZWRlbnRpYWxzIHdlIHRhbGsgYWJvdXQuDQoN ClRoaXJkLCBpdCBpcyBnb29kIHRyeWluZyB0byBjb21lIHVwIHdpdGggYSBzZXQgb2YgZ29hbHMs IGJ1dCBpdCBuZWVkcyB0byBiZSBjbGVhciB0aGF0IGZvciBzb21lIHVzZS1jYXNlcyBvbmx5IHNv bWUgZ29hbHMgbWF5IGFwcGx5Lg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUmlmYWF0IFNoZWtoLVl1c2VmDQpTZW50OiAyMCBBcHJpbCAyMDE2IDIwOjQxDQpU bzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW3NpcGNvcmVdIFNJUCBBdXRoZW50aWNhdGlv bi9BdXRob3JpemF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkFsbCwNCg0KQSBncm91cCBvZiB1 cyBkZWNpZGVkIHRvIHRha2UgYSBzdGVwIGJhY2sgZnJvbSBkaXNjdXNzaW5nIHRoZSBTSVAgT0F1 dGggZG9jdW1lbnQsIGFuZCBpbnN0ZWFkIGRlY2lkZWQgdG8gZGlzY3VzcyB0aGUgU0lQIEF1dGhl bnRpY2F0aW9uL0F1dGhvcml6YXRpb24gcHJvYmxlbSB0byBhbGxvdyB0aGUgZGlmZmVyZW50IHBh cnRpZXMgdG8gYXJ0aWN1bGF0ZSB3aGVyZSB0aGV5IGFyZSBjb21pbmcgZnJvbSBhbmQgd2hhdCBw cm9ibGVtIHRoZXkgYXJlIHRyeWluZyB0byBzb2x2ZS4NCg0KSSBzdGFydGVkIHRoaXMgZGlzY3Vz c2lvbiB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dCBhcyBhIHN0YXJ0aW5nIHBvaW50Og0KDQpUaGUg Zm9sbG93aW5nIGlzIGEgc2ltcGxpZmllZCBjbGFzc2ljIFNJUCBkZXBsb3ltZW50IG1vZGVsOg0K DQorLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tKw0KfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8IFNJ UCAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgU0lQIEFwcHwNCnwgICBVQSAgIHwtLS0tLS0t LS0tLS0tLS0tLS0tLS0tfCBQcm94eSAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IFNlcnZlciB8 DQp8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgfA0KKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsNCg0KV2l0aCB0aGlzIG1vZGVs LCB0aGUgZW5kcG9pbnQgaXMgYXNzaWduZWQgYW4gb3V0Ym91bmQgU0lQIHByb3h5IGFuZCBhbGwg U0lQIGNvbW11bmljYXRpb25zIG11c3QgZ28gdGhyb3VnaCB0aGF0IFNJUCBwcm94eS4NCg0KVGhl IFNJUCBQcm94eSBwbGF5cyAzIGRpZmZlcmVudCByb2xlczoNCjEuIEF1dGhlbnRpY2F0aW9uIFNl cnZlciAoU0lQIFJlZ2lzdHJhcikNCjIuIEF1dGhvcml6YXRpb24gU2VydmVyDQozLiBTZXJ2aWNl IHByb3ZpZGVyLCBlLmcuIGJhc2ljIGNhbGxzLCBjYWxsIGZvcndhcmRpbmcsIGNhbGwgdHJhbnNm ZXIsIGV0Yy4NCg0KU0lQIEFwcGxpY2F0aW9uIFNlcnZlcnMgcHJvdmlkZSBhZHZhbmNlZCBTSVAg c2VydmljZXMsIGUuZy4gY29uZmVyZW5jZSwgcHJlc2VuY2UsIGV0Yy4gQXBwbGljYXRpb24gU2Vy dmVycyB1c3VhbGx5IGhhdmUgdGhlaXIgb3duIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0 aW9uIG1lY2hhbmlzbSB0aGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIG9uZSBwcm92aWRlZCBieSB0 aGUgU0lQIHByb3h5Lg0KDQpXZSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhlIGlkZWEgb2Yg4oCc b3V0c291cmNpbmfigJ0gdGhlIHVzZXIgYXV0aGVudGljYXRpb24gYW5kIHNlcnZpY2VzIGF1dGhv cml6YXRpb24gdG8gc2VwYXJhdGUgbmV0d29yayBlbGVtZW50KHMpOg0KDQpUaGUgZmlyc3QgZ29h bCBpcyB0byDigJxvdXRzb3VyY2XigJ0gdGhlIHVzZXIgYXV0aGVudGljYXRpb24gcGFydCB0byBh IHNlcGFyYXRlIElkUCBlbnRpdHksIHRvIGFsbG93IHRoZSBTSVAgdXNlciB0byB1c2UgaGlzIGNy ZWRlbnRpYWxzIHdpdGggdGhlIElkUCB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUHJveHkgYW5k IGdldCBiYXNpYyBTSVAgc2VydmljZXMsIGFuZCB0byBnZXQgYWNjZXNzIHRvIHRoZSBhZHZhbmNl ZCBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgU0lQIEFwcGxpY2F0aW9uIFNlcnZlcnMuDQoNClRo ZSBzZWNvbmQgZ29hbCBpcyB0byDigJxvdXRzb3VyY2XigJ0gdGhlIGF1dGhvcml6YXRpb24gcGFy dCB0byBhIHNlcGFyYXRlIG5ldHdvcmsgZWxlbWVudCB0byBhbGxvdyB0aGUgKmFkbWluaXN0cmF0 b3IqIHRvIGdyYW50IGFjY2VzcyB0byB0aGUgYmFzaWMgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhl IFNJUCBQcm94eSBhbmQgdGhlIHZhcmlvdXMgYWR2YW5jZWQgc2VydmljZXMgcHJvdmlkZWQgYnkg dGhlIFNJUCBBcHBsaWNhdGlvbiBTZXJ2ZXJzLg0KDQpJIGFsc28gZXhwbGFpbmVkIHRoYXQgbXkg bW90aXZhdGlvbiBmb3IgdGhpcyB3b3JrIGlzIHRvIGFkZHJlc3MgZmV3ICpFbnRlcnByaXNlKiB1 c2UgY2FzZXMsIHdoaWNoIG1haW5seSBpbmNsdWRlIHRoZSBTaW5nbGUtU2lnbiBPbiB1c2UgY2Fz ZSB3aGVyZSB0aGUgdXNlciBpcyBhdXRoZW50aWNhdGVkIG9uY2UgYW5kIGFzIGEgcmVzdWx0IHRo ZSB1c2VyIGdldHMgYWNjZXNzIHRvIGEgdmFyaWV0eSBvZiBTSVAgYW5kIG5vbi1TSVAgc2Vydmlj ZXMsIGFuZCBhIGNlbnRyYWxpemVkIGF1dGhvcml6YXRpb24gdXNlIGNhc2Ugd2hlcmUgdGhlIGFk bWluaXN0cmF0b3IgaXMgYWJsZSB0byBhdXRob3JpemUgYWNjZXNzIHRvIHRoZXNlIHNlcnZpY2Vz IGZyb20gb25lIG5ldHdvcmsgZWxlbWVudC4NCg0KDQpKb24gc3VnZ2VzdGVkIHRoYXQgdGhlcmUg YXJlIHNldmVyYWwgdXNlIGNhc2VzIHRoYXQgd2Ugc2hvdWxkIGJlIGxvb2tpbmcgYXQsIGFuZCBo ZSBhcnRpY3VsYXRlZCB0aGVzZSB1c2UgY2FzZXMgYXMgZm9sbG93czoNCg0KQnV0IG1vcmUgdG8g bXkgcG9pbnQgKGFuZCBJIHN1c3BlY3QgQWRhbSdzKSB0aGVyZSBhcmUgc2V2ZXJhbCBkaXN0aW5j dCB1c2UgY2FzZXMgZm9yIFNJUCB0aGF0IGludm9sdmUgYWRkaW5nIGEgc2VjdXJlIGF0dGVzdGF0 aW9uIGFib3V0IHRoZSB1c2VyIHRvIFNJUCByZXF1ZXN0cyB0aGF0IHdpbGwgYmUgY29uc3VtZWQg YW5kIHRydXN0ZWQgYnkgc29tZSBlbnRpdHkgZG93bnN0cmVhbS4gVGhpcyBwcm9ibGVtIGlzIHBy b2JhYmx5IGdlbmVyaWMgdG8gd2hldGhlciB0aGUgbWVhdCBvZiB0aGF0IGFzc2VydGlvbiBpcyBm ZXRjaGVkIGZyb20gYSBuZXR3b3JrIHNlcnZpY2Ugb3IgZ2VuZXJhdGVkIGxvY2FsbHkgYXQgYSBT SVAgZW50aXR5IC0gZm9yIFNJUCBJZGVudGl0eS1saWtlIGFyY2hpdGVjdHVyZXMsIG9uZSBtaWdo dCBzYXkgdGhlIElkUC1pc2ggY29tcG9uZW50IG9mIHRoZSBhcmNoaXRlY3R1cmUgKHRoZSAiYXV0 aGVudGljYXRpb24gc2VydmljZSIpIGlzIHR5cGljYWxseSBjb2xvY2F0ZWQgd2l0aCBhIHByb3h5 IHNlcnZlciwgZm9yIGV4YW1wbGUuIEluIHNvbWUgY2FzZXMsIHRoZSByZWx5aW5nIHBhcnRpZXMg ZG93bnN0cmVhbSBhcmUgaW4gdGhlIHNhbWUgdHJ1c3QgZG9tYWluIGFzIHRoZSBhdHRlc3Rlci91 c2VyLCBhbmQgaW4gc29tZSBjYXNlcyB0aGV5IGNvdWxkIGJlIGluIGEgZGlmZmVyZW50IHRydXN0 IGRvbWFpbi4gSXQgbWF5IHZhcnkgaW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgYXNzZXJ0 aW9uLCBvciBpbmRlZWQgaW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgdXNlcidzIGlkZW50 aXR5LiBUaGlzIGVuY29tcGFzc2VzIGludGVyd29ya2luZyB3aXRoIGV4dGVybmFsIHByb3RvY29s cyBsaWtlIEppbmdsZSBhbmQgV2ViUlRDLCB0aGlzIGVuY29tcGFzc2VzIHByZXZlbnRpbmcgaW1w ZXJzb25hdGlvbiwgdGhpcyBwb3RlbnRpYWxseSBpbnZvbHZlcyBlbnRlcnByaXNlIHVzZSBjYXNl cyBsaWtlIEN1bGxlbiB3YXMgdGFsa2luZyBhYm91dC4NCg0KDQpBZGFtIGVsYWJvcmF0ZWQgb24g Sm9u4oCZcyBzdGF0ZW1lbnQgdGhhdCB0YWxrcyBhYm91dCDigJxkaWZmZXJlbnQgdHJ1c3QgZG9t YWluc+KAnSBhcyBmb2xsb3dzOg0KDQpJIGJlbGlldmUgaGUncyByZWZlcnJpbmcgdG8gdGhlIGtp bmQgb2YgdXNlIGNhc2VzIGFkZHJlc3NlZCBieSBSRkMgNDQ3NCBhbmQgYnkgdGhlIHdvcmsgY3Vy cmVudGx5IGdvaW5nIG9uIGluIFNUSVIgLS0gb25lcyBpbiB3aGljaCBzb21lIGVudGl0eSBhc3Nl cnRzIHRoZSBpZGVudGl0eSBvZiBhIHBhcnR5IGluIHRoZSBjYWxsIGZvciB1c2UgYnkgYW4gZW50 aXR5IGluIGEgY29tcGxldGVseSB1bnJlbGF0ZWQgdHJ1c3QgZG9tYWluLg0KDQpUaGVyZSdzIGFs c28gdGhlIG1hdHRlciBvZiBpbnRlcmRvbWFpbiB0cmFpdC1iYXNlZCBhdXRob3JpemF0aW9uIChp bmRlcGVuZGVudCBvZiBpZGVudGl0eSkuIFRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiBSRkMg NDQ4NCBpcyBhIHJlYWxseSBnb29kIHBsYWNlIHRvIHN0YXJ0IGlmIHlvdSdyZSBub3QgZmFtaWxp YXIgd2l0aCB0aGUgY29uY2VwdC4NCg0KDQoNCkF0IHRoaXMgcG9pbnQgQWRhbSwgYXMgU0lQQ09S RSBjaGFpciwgc3VnZ2VzdGVkIHRoYXQgd2UgY29udGludWUgdGhpcyBkaXNjdXNzaW9uIG9uIHRo ZSBTSVBDT1JFIG1haWxpbmcgbGlzdC4gU28gaGVyZSB3ZSBhcmXigKYNCg0KUmVnYXJkcywNCiBS aWZhYXQNCg== --_000_7594FB04B1934943A5C02806D1A2204B37F71758ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkEgZmV3IGNvbW1lbnRzIG9uIHRoZSB0ZXh0OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Rmlyc3QsIEkgZG9u4oCZdCB0aGlu ayB3ZSBzaG91bGQgc2F5IOKAnG91dGJvdW5kIFNJUCBwcm94eeKAnS4gVGhhdCBtYXkgY29uZnVz ZSBwZW9wbGUgd2l0aCBSRkMgNTI1NiwgYW5kIEkgYXNzdW1lIHRoYXQgaXMgbm90IHdoYXQgeW91 IGFyZQ0KIHRhbGtpbmcgYWJvdXQuIFdoeSBub3Qgc2ltcGx5IGNhbGwgaXQg4oCcU0lQIHJlZ2lz dHJhcuKAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY29uZCwg d2hlbiB3ZSB0YWxrIGFib3V0IGNyZWRlbnRpYWxzLCB3ZSBtdXN0IGJlIGNsZWFyIG9uIHdoYXQg a2luZCBvZiBjcmVkZW50aWFscyB3ZSB0YWxrIGFib3V0Lg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlyZCwgaXQgaXMgZ29vZCB0cnlpbmcgdG8gY29tZSB1cCB3 aXRoIGEgc2V0IG9mIGdvYWxzLCBidXQgaXQgbmVlZHMgdG8gYmUgY2xlYXIgdGhhdCBmb3Igc29t ZSB1c2UtY2FzZXMgb25seSBzb21lIGdvYWxzIG1heSBhcHBseS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2lwY29yZSBbbWFpbHRvOnNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmlmYWF0IFNoZWto LVl1c2VmPGJyPg0KPGI+U2VudDo8L2I+IDIwIEFwcmlsIDIwMTYgMjA6NDE8YnI+DQo8Yj5Ubzo8 L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NpcGNvcmVdIFNJUCBB dXRoZW50aWNhdGlvbi9BdXRob3JpemF0aW9uIFByb2JsZW0gU3RhdGVtZW50PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj5BbGwsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ QSBncm91cCBvZiB1cyBkZWNpZGVkIHRvIHRha2UgYSBzdGVwIGJhY2sgZnJvbSBkaXNjdXNzaW5n IHRoZSBTSVAgT0F1dGggZG9jdW1lbnQsIGFuZCBpbnN0ZWFkIGRlY2lkZWQgdG8gZGlzY3VzcyB0 aGUgU0lQIEF1dGhlbnRpY2F0aW9uL0F1dGhvcml6YXRpb24NCiBwcm9ibGVtIHRvIGFsbG93IHRo ZSBkaWZmZXJlbnQgcGFydGllcyB0byBhcnRpY3VsYXRlIHdoZXJlIHRoZXkgYXJlIGNvbWluZyBm cm9tIGFuZCB3aGF0IHByb2JsZW0gdGhleSBhcmUgdHJ5aW5nIHRvIHNvbHZlLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM1MDAwNTAiPkkgc3RhcnRlZCB0aGlzIGRpc2N1c3Npb24gd2l0aCB0aGUgZm9sbG93 aW5nIHRleHQgYXMgYSBzdGFydGluZyBwb2ludDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dy b3VuZC1yZXBlYXQ6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj5UaGUgZm9sbG93 aW5nIGlzIGEgc2ltcGxpZmllZCBjbGFzc2ljIFNJUCBkZXBsb3ltZW50IG1vZGVsOjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5p dGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAi PiYjNDM7LS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tJiM0MzsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0aWFs O2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+fCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wg U0lQJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTSVAgQXBwfDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Jh Y2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPnwmbmJzcDsmbmJzcDsgVUEmbmJzcDsmbmJzcDsgfC0tLS0tLS0t LS0tLS0tLS0tLS0tLS18IFByb3h5Jm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCBTZXJ2 ZXIgfDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDpp bml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0aWFs O2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+JiM0 MzstLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmIzQzOy0tLS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFj a2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlh bCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj5XaXRoIHRoaXMgbW9kZWwsIHRoZSBlbmRwb2lu dCBpcyBhc3NpZ25lZCBhbiBvdXRib3VuZCBTSVAgcHJveHkgYW5kIGFsbCBTSVAgY29tbXVuaWNh dGlvbnMgbXVzdCBnbyB0aHJvdWdoIHRoYXQgU0lQIHByb3h5Ljwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQt aW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3Jv dW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPlRoZSBTSVAgUHJv eHkgcGxheXMgMyBkaWZmZXJlbnQgcm9sZXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0 aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ MS4gQXV0aGVudGljYXRpb24gU2VydmVyIChTSVAgUmVnaXN0cmFyKTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91 bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM1MDAwNTAiPjIuIEF1dGhvcml6YXRpb24gU2VydmVyPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1p bWFnZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzUwMDA1MCI+My4gU2VydmljZSBwcm92aWRlciwgZS5nLiBiYXNpYyBjYWxscywgY2FsbCBmb3J3 YXJkaW5nLCBjYWxsIHRyYW5zZmVyLCBldGMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0 aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAwNTAi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0 OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+U0lQIEFwcGxpY2F0aW9uIFNlcnZl cnMgcHJvdmlkZSBhZHZhbmNlZCBTSVAgc2VydmljZXMsIGUuZy4gY29uZmVyZW5jZSwgcHJlc2Vu Y2UsIGV0Yy4gQXBwbGljYXRpb24gU2VydmVycyB1c3VhbGx5IGhhdmUgdGhlaXIgb3duIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbSB0aGF0IGlzIHNlcGFyYXRlDQog ZnJvbSB0aGUgb25lIHByb3ZpZGVkIGJ5IHRoZSBTSVAgcHJveHkuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3Vu ZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tn cm91bmQtcmVwZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+V2Ugd291bGQg bGlrZSB0byBkaXNjdXNzIHRoZSBpZGVhIG9mIOKAnG91dHNvdXJjaW5n4oCdIHRoZSB1c2VyIGF1 dGhlbnRpY2F0aW9uIGFuZCBzZXJ2aWNlcyBhdXRob3JpemF0aW9uIHRvIHNlcGFyYXRlIG5ldHdv cmsgZWxlbWVudChzKTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3Vu ZC1yZXBlYXQ6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNTAwMDUwIj5UaGUgZmlyc3QgZ29hbCBpcyB0byDigJxvdXRzb3VyY2Xi gJ0gdGhlIHVzZXIgYXV0aGVudGljYXRpb24gcGFydCB0byBhIHNlcGFyYXRlJm5ic3A7SWRQIGVu dGl0eSwgdG8gYWxsb3cgdGhlIFNJUCB1c2VyIHRvIHVzZSBoaXMgY3JlZGVudGlhbHMgd2l0aCB0 aGUgSWRQIHRvIHJlZ2lzdGVyIHdpdGggdGhlIFNJUCBQcm94eSBhbmQgZ2V0IGJhc2ljDQogU0lQ IHNlcnZpY2VzLCBhbmQgdG8gZ2V0IGFjY2VzcyB0byB0aGUgYWR2YW5jZWQgc2VydmljZXMgcHJv dmlkZWQgYnkgdGhlIFNJUCBBcHBsaWNhdGlvbiBTZXJ2ZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQt aW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3Jv dW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPlRoZSBzZWNvbmQg Z29hbCBpcyB0byDigJxvdXRzb3VyY2XigJ0gdGhlIGF1dGhvcml6YXRpb24gcGFydCB0byBhIHNl cGFyYXRlIG5ldHdvcmsgZWxlbWVudCB0byBhbGxvdyB0aGUgKmFkbWluaXN0cmF0b3IqIHRvIGdy YW50IGFjY2VzcyB0byB0aGUgYmFzaWMgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhlIFNJUCBQcm94 eSBhbmQgdGhlDQogdmFyaW91cyBhZHZhbmNlZCBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgU0lQ IEFwcGxpY2F0aW9uIFNlcnZlcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAw NTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+SSBhbHNvIGV4 cGxhaW5lZCB0aGF0IG15IG1vdGl2YXRpb24gZm9yIHRoaXMgd29yayBpcyB0byBhZGRyZXNzIGZl dyAqRW50ZXJwcmlzZSogdXNlIGNhc2VzLCB3aGljaCBtYWlubHkgaW5jbHVkZSB0aGUgU2luZ2xl LVNpZ24gT24gdXNlDQogY2FzZSB3aGVyZSB0aGUgdXNlciBpcyBhdXRoZW50aWNhdGVkIG9uY2Ug YW5kIGFzIGEgcmVzdWx0IHRoZSB1c2VyIGdldHMgYWNjZXNzIHRvIGEgdmFyaWV0eSBvZiBTSVAg YW5kIG5vbi1TSVAgc2VydmljZXMsIGFuZCBhIGNlbnRyYWxpemVkIGF1dGhvcml6YXRpb24gdXNl IGNhc2Ugd2hlcmUgdGhlIGFkbWluaXN0cmF0b3IgaXMgYWJsZSB0byBhdXRob3JpemUgYWNjZXNz IHRvIHRoZXNlIHNlcnZpY2VzIGZyb20gb25lIG5ldHdvcmsgZWxlbWVudC48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPkpvbiBzdWdnZXN0ZWQgdGhhdCB0aGVyZSBhcmUg c2V2ZXJhbCB1c2UgY2FzZXMgdGhhdCB3ZSBzaG91bGQgYmUgbG9va2luZyBhdCwgYW5kIGhlIGFy dGljdWxhdGVkIHRoZXNlIHVzZSBjYXNlcyBhcyBmb2xsb3dzOjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlh bDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5CdXQg bW9yZSB0byBteSBwb2ludCAoYW5kIEkgc3VzcGVjdCBBZGFtJ3MpIHRoZXJlIGFyZSBzZXZlcmFs IGRpc3RpbmN0IHVzZSBjYXNlcyBmb3IgU0lQIHRoYXQgaW52b2x2ZSBhZGRpbmcgYSBzZWN1cmUg YXR0ZXN0YXRpb24gYWJvdXQgdGhlIHVzZXIgdG8gU0lQIHJlcXVlc3RzIHRoYXQgd2lsbCBiZSBj b25zdW1lZCBhbmQgdHJ1c3RlZA0KIGJ5IHNvbWUgZW50aXR5IGRvd25zdHJlYW0uIFRoaXMgcHJv YmxlbSBpcyBwcm9iYWJseSBnZW5lcmljIHRvIHdoZXRoZXIgdGhlIG1lYXQgb2YgdGhhdCBhc3Nl cnRpb24gaXMgZmV0Y2hlZCBmcm9tIGEgbmV0d29yayBzZXJ2aWNlIG9yIGdlbmVyYXRlZCBsb2Nh bGx5IGF0IGEgU0lQIGVudGl0eSAtIGZvciBTSVAgSWRlbnRpdHktbGlrZSBhcmNoaXRlY3R1cmVz LCBvbmUgbWlnaHQgc2F5IHRoZSBJZFAtaXNoIGNvbXBvbmVudCBvZiB0aGUgYXJjaGl0ZWN0dXJl DQogKHRoZSAmcXVvdDthdXRoZW50aWNhdGlvbiBzZXJ2aWNlJnF1b3Q7KSBpcyB0eXBpY2FsbHkg Y29sb2NhdGVkIHdpdGggYSBwcm94eSBzZXJ2ZXIsIGZvciBleGFtcGxlLiBJbiBzb21lIGNhc2Vz LCB0aGUgcmVseWluZyBwYXJ0aWVzIGRvd25zdHJlYW0gYXJlIGluIHRoZSBzYW1lIHRydXN0IGRv bWFpbiBhcyB0aGUgYXR0ZXN0ZXIvdXNlciwgYW5kIGluIHNvbWUgY2FzZXMgdGhleSBjb3VsZCBi ZSBpbiBhIGRpZmZlcmVudCB0cnVzdCBkb21haW4uIEl0IG1heSB2YXJ5DQogaW4gdGhlIGNvbmZp ZGVudGlhbGl0eSBvZiB0aGUgYXNzZXJ0aW9uLCBvciBpbmRlZWQgaW4gdGhlIGNvbmZpZGVudGlh bGl0eSBvZiB0aGUgdXNlcidzIGlkZW50aXR5LiBUaGlzIGVuY29tcGFzc2VzIGludGVyd29ya2lu ZyB3aXRoIGV4dGVybmFsIHByb3RvY29scyBsaWtlIEppbmdsZSBhbmQgV2ViUlRDLCB0aGlzIGVu Y29tcGFzc2VzIHByZXZlbnRpbmcgaW1wZXJzb25hdGlvbiwgdGhpcyBwb3RlbnRpYWxseSBpbnZv bHZlcyBlbnRlcnByaXNlDQogdXNlIGNhc2VzIGxpa2UgQ3VsbGVuIHdhcyB0YWxraW5nIGFib3V0 LiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUw Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPkFkYW0gZWxhYm9yYXRlZCBvbiBKb27igJlzIHN0YXRlbWVu dCB0aGF0IHRhbGtzIGFib3V0IOKAnGRpZmZlcmVudCB0cnVzdCBkb21haW5z4oCdIGFzIGZvbGxv d3M6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPkkgYmVsaWV2ZSBoZSdzIHJlZmVycmluZyB0byB0aGUg a2luZCBvZiB1c2UgY2FzZXMgYWRkcmVzc2VkIGJ5IFJGQyA0NDc0IGFuZCBieSB0aGUgd29yayBj dXJyZW50bHkgZ29pbmcgb24gaW4gU1RJUiAtLSBvbmVzIGluIHdoaWNoIHNvbWUgZW50aXR5DQog YXNzZXJ0cyB0aGUgaWRlbnRpdHkgb2YgYSBwYXJ0eSBpbiB0aGUgY2FsbCBmb3IgdXNlIGJ5IGFu IGVudGl0eSBpbiBhIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHRydXN0IGRvbWFpbi48YnI+DQo8YnI+ DQpUaGVyZSdzIGFsc28gdGhlIG1hdHRlciBvZiBpbnRlcmRvbWFpbiB0cmFpdC1iYXNlZCBhdXRo b3JpemF0aW9uIChpbmRlcGVuZGVudCBvZiBpZGVudGl0eSkuIFRoZSBpbnRyb2R1Y3Rpb24gc2Vj dGlvbiBvZiBSRkMgNDQ4NCBpcyBhIHJlYWxseSBnb29kIHBsYWNlIHRvIHN0YXJ0IGlmIHlvdSdy ZSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgY29uY2VwdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUw Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1 MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAw NTAiPkF0IHRoaXMgcG9pbnQgQWRhbSwgYXMgU0lQQ09SRSBjaGFpciwgc3VnZ2VzdGVkIHRoYXQg d2UgY29udGludWUgdGhpcyBkaXNjdXNzaW9uIG9uIHRoZSBTSVBDT1JFIG1haWxpbmcgbGlzdC4g U28gaGVyZSB3ZSBhcmXigKY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzUwMDA1MCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj5SZWdhcmRzLDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwO1JpZmFhdDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37F71758ESESSMB209erics_-- From nobody Thu Apr 21 07:30: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 01B7B12EB79 for ; Thu, 21 Apr 2016 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 JgZzHLFjEIjQ for ; Thu, 21 Apr 2016 07:30:44 -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 8F0E412EB3B for ; Thu, 21 Apr 2016 07:30:44 -0700 (PDT) Received: from unnumerable.local ([173.57.167.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3LEUh5L031277 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 21 Apr 2016 09:30:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.167.89] claimed to be unnumerable.local To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37F71758@ESESSMB209.ericsson.se> From: Robert Sparks Message-ID: <5718E414.9060403@nostrum.com> Date: Thu, 21 Apr 2016 09:30:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F71758@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------090207090700030903090106" Archived-At: Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 21 Apr 2016 14:30:50 -0000 This is a multi-part message in MIME format. --------------090207090700030903090106 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/21/16 7:46 AM, Christer Holmberg wrote: > > Hi, > > A few comments on the text: > > First, I don’t think we should say “outbound SIP proxy”. That may > confuse people with RFC 5256, and I assume that is not what you are > talking about. Why not simply call it “SIP registrar”? > Because it's not acting only as a registrar, at least in that example. Routes (loaded with Service-Route I assume?) are forcing traffic through it. If it has a role to play in this auth/auth story when messages go through it in this role, it needs to have a named player, and registrar would be even more confusing. (Does it have such a role?) It might be even more useful to show any proxies put on the path by Route establishing mechanisms (preloaded or provided by Service-Route) as separate from the registrar, even if the roles are combined in one box a given deployment. > > Second, when we talk about credentials, we must be clear on what kind > of credentials we talk about. > > Third, it is good trying to come up with a set of goals, but it needs > to be clear that for some use-cases only some goals may apply. > > Thanks! > > Regards, > > Christer > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Rifaat > Shekh-Yusef > *Sent:* 20 April 2016 20:41 > *To:* sipcore@ietf.org > *Subject:* [sipcore] SIP Authentication/Authorization Problem Statement > > All, > > A group of us decided to take a step back from discussing the SIP > OAuth document, and instead decided to discuss the SIP > Authentication/Authorization problem to allow the different parties to > articulate where they are coming from and what problem they are trying > to solve. > > I started this discussion with the following text as a starting point: > > The following is a simplified classic SIP deployment model: > > +--------+ +--------+ +--------+ > > | | | SIP | | SIP App| > > | UA |----------------------| Proxy |----------------------| Server | > > | | | | | | > > +--------+ +--------+ +--------+ > > With this model, the endpoint is assigned an outbound SIP proxy and > all SIP communications must go through that SIP proxy. > > The SIP Proxy plays 3 different roles: > > 1. Authentication Server (SIP Registrar) > > 2. Authorization Server > > 3. Service provider, e.g. basic calls, call forwarding, call transfer, > etc. > > SIP Application Servers provide advanced SIP services, e.g. > conference, presence, etc. Application Servers usually have their own > authentication and authorization mechanism that is separate from the > one provided by the SIP proxy. > > We would like to discuss the idea of “outsourcing” the user > authentication and services authorization to separate network element(s): > > The first goal is to “outsource” the user authentication part to a > separate IdP entity, to allow the SIP user to use his credentials with > the IdP to register with the SIP Proxy and get basic SIP services, and > to get access to the advanced services provided by the SIP Application > Servers. > > The second goal is to “outsource” the authorization part to a separate > network element to allow the *administrator* to grant access to the > basic services provided by the SIP Proxy and the various advanced > services provided by the SIP Application Servers. > > I also explained that my motivation for this work is to address few > *Enterprise* use cases, which mainly include the Single-Sign On use > case where the user is authenticated once and as a result the user > gets access to a variety of SIP and non-SIP services, and a > centralized authorization use case where the administrator is able to > authorize access to these services from one network element. > > Jon suggested that there are several use cases that we should be > looking at, and he articulated these use cases as follows: > > But more to my point (and I suspect Adam's) there are several distinct > use cases for SIP that involve adding a secure attestation about the > user to SIP requests that will be consumed and trusted by some entity > downstream. This problem is probably generic to whether the meat of > that assertion is fetched from a network service or generated locally > at a SIP entity - for SIP Identity-like architectures, one might say > the IdP-ish component of the architecture (the "authentication > service") is typically colocated with a proxy server, for example. In > some cases, the relying parties downstream are in the same trust > domain as the attester/user, and in some cases they could be in a > different trust domain. It may vary in the confidentiality of the > assertion, or indeed in the confidentiality of the user's identity. > This encompasses interworking with external protocols like Jingle and > WebRTC, this encompasses preventing impersonation, this potentially > involves enterprise use cases like Cullen was talking about. > > Adam elaborated on Jon’s statement that talks about “different trust > domains” as follows: > > I believe he's referring to the kind of use cases addressed by RFC > 4474 and by the work currently going on in STIR -- ones in which some > entity asserts the identity of a party in the call for use by an > entity in a completely unrelated trust domain. > > There's also the matter of interdomain trait-based authorization > (independent of identity). The introduction section of RFC 4484 is a > really good place to start if you're not familiar with the concept. > > At this point Adam, as SIPCORE chair, suggested that we continue this > discussion on the SIPCORE mailing list. So here we are… > > Regards, > > Rifaat > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------090207090700030903090106 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 4/21/16 7:46 AM, Christer Holmberg wrote:

Hi,

 

A few comments on the text:

 

First, I don’t think we should say “outbound SIP proxy”. That may confuse people with RFC 5256, and I assume that is not what you are talking about. Why not simply call it “SIP registrar”?

Because it's not acting only as a registrar, at least in that example. Routes (loaded with Service-Route I assume?) are forcing traffic through it. If it has a role to play in this auth/auth story when messages go through it in this role, it needs to have a named player, and registrar would be even more confusing. (Does it have such a role?)

It might be even more useful to show any proxies put on the path by Route establishing mechanisms (preloaded or provided by Service-Route) as separate from the registrar, even if the roles are combined in one box a given deployment.

 

Second, when we talk about credentials, we must be clear on what kind of credentials we talk about.

 

Third, it is good trying to come up with a set of goals, but it needs to be clear that for some use-cases only some goals may apply.

 

Thanks!

 

Regards,

 

Christer

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 20 April 2016 20:41
To: sipcore@ietf.org
Subject: [sipcore] SIP Authentication/Authorization Problem Statement

 

All,

 

A group of us decided to take a step back from discussing the SIP OAuth document, and instead decided to discuss the SIP Authentication/Authorization problem to allow the different parties to articulate where they are coming from and what problem they are trying to solve.

 

I started this discussion with the following text as a starting point:

 

The following is a simplified classic SIP deployment model:

 

+--------+                      +--------+                      +--------+

|        |                      | SIP    |                      | SIP App|

|   UA   |----------------------| Proxy  |----------------------| Server |

|        |                      |        |                      |        |

+--------+                      +--------+                      +--------+

 

With this model, the endpoint is assigned an outbound SIP proxy and all SIP communications must go through that SIP proxy.

 

The SIP Proxy plays 3 different roles:

1. Authentication Server (SIP Registrar)

2. Authorization Server

3. Service provider, e.g. basic calls, call forwarding, call transfer, etc.

 

SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy.

 

We would like to discuss the idea of “outsourcing” the user authentication and services authorization to separate network element(s):

 

The first goal is to “outsource” the user authentication part to a separate IdP entity, to allow the SIP user to use his credentials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application Servers.

 

The second goal is to “outsource” the authorization part to a separate network element to allow the *administrator* to grant access to the basic services provided by the SIP Proxy and the various advanced services provided by the SIP Application Servers.

 

I also explained that my motivation for this work is to address few *Enterprise* use cases, which mainly include the Single-Sign On use case where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP services, and a centralized authorization use case where the administrator is able to authorize access to these services from one network element.

 

 

Jon suggested that there are several use cases that we should be looking at, and he articulated these use cases as follows:

 

But more to my point (and I suspect Adam's) there are several distinct use cases for SIP that involve adding a secure attestation about the user to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to whether the meat of that assertion is fetched from a network service or generated locally at a SIP entity - for SIP Identity-like architectures, one might say the IdP-ish component of the architecture (the "authentication service") is typically colocated with a proxy server, for example. In some cases, the relying parties downstream are in the same trust domain as the attester/user, and in some cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality of the user's identity. This encompasses interworking with external protocols like Jingle and WebRTC, this encompasses preventing impersonation, this potentially involves enterprise use cases like Cullen was talking about. 

 

 

Adam elaborated on Jon’s statement that talks about “different trust domains” as follows:

 

I believe he's referring to the kind of use cases addressed by RFC 4474 and by the work currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use by an entity in a completely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (independent of identity). The introduction section of RFC 4484 is a really good place to start if you're not familiar with the concept.

 

 

 

At this point Adam, as SIPCORE chair, suggested that we continue this discussion on the SIPCORE mailing list. So here we are…

 

Regards,

 Rifaat



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

--------------090207090700030903090106-- From nobody Sat Apr 23 04:30: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 EC9B612D0AA for ; Sat, 23 Apr 2016 04:30: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 yIhvTETbYbPp for ; Sat, 23 Apr 2016 04:30:51 -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 90F0312D761 for ; Sat, 23 Apr 2016 04:30:51 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id n62so166298072vkb.0 for ; Sat, 23 Apr 2016 04:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3XWnhbVSABBNMIMVAZ2CfK/B/2jbTFdNs+3863ed/Yw=; b=V+T9nmrJT/awO0nKltdtl8mTVPfbdJdx8NtvkhB2l+txtYEGDe9zh7ptR1dl4pZCdr PdKQ8T0uXp9qLB9WEgLWDqvNyhr6vIcE/vzvT/Wh6QjVelVaI0go7j0i7ecULsgXCsx0 4ZEh9LCidweeoWl3WvfxVUl2k0r+X4aqVJmG+lUribsp3NmFwbaHkU1CnkMInoIGWUyx U1zad9DvLxHXOz0IO2GroIy1ne5X/IqSj8Bt36yvTvVGBAji/h4yuiJYbJTQ2WiiEzHd eb0S/Th5mBgSQPluy9E8bKZWk5nEJVU1jIdhU7SHE2k0x7ET8Tbxvo2l6tWXR5X1CQ18 fQ3g== 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:date :message-id:subject:from:to:cc; bh=3XWnhbVSABBNMIMVAZ2CfK/B/2jbTFdNs+3863ed/Yw=; b=MKehn/G3C0FxfSVzwoZY0FXXW1qp4iWoJuLZKClWoFzL41mIvuFkHqnrARrffGDKx5 9+li/2u5hwvSTuwie4y56XAFMyBrSoh4m6X9/n3rVr+DtFbg/FUMQdKKdhL8MN2eu7At NTaLMldf8j1ntIjl+NZqvz0yHaikWLIuv6DX1DjcCg+jVl1ycJ+hrXtH9NjaGVm1Fq7Z Ysw+xotdyT8mBGr75I3njyrDXOsoONJSn7VZ97oetAywi0uHfmBBTof0DDLLm6+EBdfo X7kzKadm/Np46/jo/CNXbGlSBjZPqUlocDQQ5a/Kc+EZOIK9c1SP/ZbpYDAUm19S2I37 5J3A== X-Gm-Message-State: AOPr4FXJbvYe9Qf18zoOJ1NYZwutWXxqZu8TEnZb5nc07wuM8ulb1oemkQLg5On5bXUnt+QQeCKWDcpcc9ATSQ== MIME-Version: 1.0 X-Received: by 10.176.69.235 with SMTP id u98mr13820508uau.131.1461411050641; Sat, 23 Apr 2016 04:30:50 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sat, 23 Apr 2016 04:30:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Apr 2016 07:30:50 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c11c4c28b5d120531254624 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 23 Apr 2016 11:30:55 -0000 --94eb2c11c4c28b5d120531254624 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Jon! Please, see my reply inline... Regards, Rifaat On Wed, Apr 20, 2016 at 2:59 PM, Peterson, Jon wrote: > > I am definitely supportive of trying to find a common problem statement > here to reconcile the numerous ways that we seem to be specifying identit= y > assertions in SIP (and in related real-time communication protocols). > Authorization, because of its implications for policy and trust models, h= as > been a thornier topic for us to cover, though I'm open to developing a > problem statement for it as well (RFC4484 notably never got any farther > than requirements). > > I think to get this into the shape we'd need a problem statement to be, w= e > need to be more specific about what we mean by "IdP" and "Authorization > Server" in the starting point discussion below. If an IdP is just an enti= ty > that provides some kind of token that can be added to SIP messages > asserting the identity of the originator, for example, then we have a > number of overlapping mechanisms that do that. > Yes, I agree with that. This is one of the challenges that we need to discuss and address. Should we support multiple mechanisms? should we select one to rule them all? other options? > Getting a single sign-on experience, such that a SIP entities is > authenticated by a service that creates an assertion added to SIP request= s > that can be validated and trusted by entities receiving the request is > probably achievable without any new protocol work. > That depends on how you get that assertion. Do you get it directly or indirectly through some interim step? This is dictated by the type of client you are using; the following client limitation would require an interim step: 1. *UI Limitation*: a hardphone with limited UI capability that only allows the user to interact with the phone through the phone's keypad. 2. *Security Limitation*:a client that is incapable of maintaining the security of the user's credentials or the assertion. In these use cases, we would need away to get the assertion to the servers that will provide the service without requiring the client to get access to the assertion. Another part that we need to think about is how to carry the assertion in a SIP message. > But If we mean something more specific by "IdP," we need to narrow in on > what that is. > > For an "Authorization Server," well, I think the function of that entity > is somewhat unclear in the statement below. I agree that today, > authorization decisions are made by the entities that receive SIP request= s > based on some sort of local policy predicated on trust relationships > dictated by the controller of the device. The distinction between the own= er > or controller of the device and the "administrator" of this authorization > architecture isn't clear to me from reading this, nor is it clear what > information the "advanced" services residing in app servers might need to > make an authorization decision. The nature of that information will dicta= te > much of the requirements here: to whom can it be revealed, and to whom mu= st > it be confidential; how is it structured; etc. > > Ok. I will add more details to clarify these aspects. In general, I can think of two possible ways to provide authorization: 1. *Self-contained token*, which includes all the authorizations needed for the server providing the service to be able to make a decision to grant or deny the service request, and might include control over the level of service provided to the user. 2. *Opaque token*, which requires an introspection step, where the server providing the service would reach to the authorization server to get the details of the authorizations provided for that specific token. There are pros and cons to each approach that we need to discuss and make a decision on supporting one of these, or maybe both. Do you see other options here? My point about "trust domains" below is tied up in questions about the > scope of the identity and authorization mechanism. Can or should the > assertion be trusted by relying parties who have no previous association > with the issuer of the token, for example? > As I mentioned before, my motivation for this work was to address few *Enterprise *use cases, so this use case was out of scope for what I was trying to accomplish. > For the "Authorization Server" function, since it assumes an > "administrator" who can authorize access to a set of resources under its > control, I'd imagine that the only relying parties that would accept the > token have a very clear prior association with the "administrator" (thoug= h > we'd need to say more about what we imagine it would be). > Yes. Sure, I will add more details to cover this. > In federated identity models that come up fairly often, you sometimes do > have trust across domain boundaries that is significantly looser. If that= 's > in scope, that's important to understand. > > I am definitely open to discussing this and see if we can find a common solution that would apply to this use case too. Regards, Rifaat > Jon Peterson > Neustar, Inc. > > From: sipcore on behalf of Rifaat Shekh-Yusef = < > rifaat.ietf@gmail.com> > Date: Wednesday, April 20, 2016 at 10:40 AM > To: "sipcore@ietf.org" > Subject: [sipcore] SIP Authentication/Authorization Problem Statement > > All, > > > > A group of us decided to take a step back from discussing the SIP OAuth > document, and instead decided to discuss the SIP > Authentication/Authorization problem to allow the different parties to > articulate where they are coming from and what problem they are trying to > solve. > > > > I started this discussion with the following text as a starting point: > > > > The following is a simplified classic SIP deployment model: > > > > +--------+ +--------+ +--------= + > > | | | SIP | | SIP App= | > > | UA |----------------------| Proxy |----------------------| Server = | > > | | | | | = | > > +--------+ +--------+ +--------= + > > > > With this model, the endpoint is assigned an outbound SIP proxy and all > SIP communications must go through that SIP proxy. > > > > The SIP Proxy plays 3 different roles: > > 1. Authentication Server (SIP Registrar) > > 2. Authorization Server > > 3. Service provider, e.g. basic calls, call forwarding, call transfer, et= c. > > > > SIP Application Servers provide advanced SIP services, e.g. conference, > presence, etc. Application Servers usually have their own authentication > and authorization mechanism that is separate from the one provided by the > SIP proxy. > > > > We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the us= er authentication > and services authorization to separate network element(s): > > > > The first goal is to =E2=80=9Coutsource=E2=80=9D the user authentication = part to a > separate IdP entity, to allow the SIP user to use his credentials with th= e > IdP to register with the SIP Proxy and get basic SIP services, and to get > access to the advanced services provided by the SIP Application Servers. > > > > The second goal is to =E2=80=9Coutsource=E2=80=9D the authorization part = to a separate > network element to allow the *administrator* to grant access to the basic > services provided by the SIP Proxy and the various advanced services > provided by the SIP Application Servers. > > > > I also explained that my motivation for this work is to address few > *Enterprise* use cases, which mainly include the Single-Sign On use case > where the user is authenticated once and as a result the user gets access > to a variety of SIP and non-SIP services, and a centralized authorization > use case where the administrator is able to authorize access to these > services from one network element. > > > > > Jon suggested that there are several use cases that we should be looking > at, and he articulated these use cases as follows: > > > > But more to my point (and I suspect Adam's) there are several distinct us= e > cases for SIP that involve adding a secure attestation about the user to > SIP requests that will be consumed and trusted by some entity downstream. > This problem is probably generic to whether the meat of that assertion is > fetched from a network service or generated locally at a SIP entity - for > SIP Identity-like architectures, one might say the IdP-ish component of t= he > architecture (the "authentication service") is typically colocated with a > proxy server, for example. In some cases, the relying parties downstream > are in the same trust domain as the attester/user, and in some cases they > could be in a different trust domain. It may vary in the confidentiality = of > the assertion, or indeed in the confidentiality of the user's identity. > This encompasses interworking with external protocols like Jingle and > WebRTC, this encompasses preventing impersonation, this potentially > involves enterprise use cases like Cullen was talking about. > > > > > > Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdiff= erent trust > domains=E2=80=9D as follows: > > > > I believe he's referring to the kind of use cases addressed by RFC 4474 > and by the work currently going on in STIR -- ones in which some entity > asserts the identity of a party in the call for use by an entity in a > completely unrelated trust domain. > > There's also the matter of interdomain trait-based authorization > (independent of identity). The introduction section of RFC 4484 is a real= ly > good place to start if you're not familiar with the concept. > > > > > > > At this point Adam, as SIPCORE chair, suggested that we continue this > discussion on the SIPCORE mailing list. So here we are=E2=80=A6 > > > > Regards, > > Rifaat > > --94eb2c11c4c28b5d120531254624 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jon!

Please, see my reply i= nline...

Regards,
=C2=A0Rifaat




On Wed, Apr 20, 2016 at 2:59 PM, Peterso= n, Jon <jon.peterson@neustar.biz> wrote:

I am definitely supportive of trying to find a common problem statemen= t here to reconcile the numerous ways that we seem to be specifying identit= y assertions in SIP (and in related real-time communication protocols). Aut= horization, because of its implications for policy and trust models, has been a thornier topic for us to cover, th= ough I'm open to developing a problem statement for it as well (RFC4484= notably never got any farther than requirements).

I think to get this into the shape we'd need a problem statement t= o be, we need to be more specific about what we mean by "IdP" and= "Authorization Server" in the starting point discussion below. I= f an IdP is just an entity that provides some kind of token that can be added to SIP messages asserting the identity of the originator= , for example, then we have a number of overlapping mechanisms that do that= .

Yes, I agree with that.
This is one of the challenges that we need to discuss and address. Sh= ould we support multiple mechanisms? should we select one to rule them all?= other options?

=C2=A0
Getting a single sign-on experience, such that a SI= P entities is authenticated by a service that creates an assertion added to SIP requests that can be validated and trusted by en= tities receiving the request is probably achievable without any new protoco= l work.

That depends on how yo= u get that assertion. Do you get it directly or indirectly through some int= erim step?
This is dictated by the type of client you are usi= ng; the following client limitation would require an interim step:
1. UI Limitation: a hardphone with limited UI capability that only= allows the user to interact with the phone through the phone's keypad.=
2. Security Limitation:a client that is incapable of main= taining the security of the user's credentials or the assertion.
<= div>
In these use cases, we would need away to get the assert= ion to the servers that will provide the service without requiring the clie= nt to get access to the assertion.

Another part th= at we need to think about is how to carry the assertion in a SIP message.

=C2=A0
But If we mean something more specific by "IdP," we ne= ed to narrow in on what that is.=C2=A0

For an "Authorization Server," well, I think the function of= that entity is somewhat unclear in the statement below. I agree that today= , authorization decisions are made by the entities that receive SIP request= s based on some sort of local policy predicated on trust relationships dictated by the controller of the device. The disti= nction between the owner or controller of the device and the "administ= rator" of this authorization architecture isn't clear to me from r= eading this, nor is it clear what information the "advanced" services residing in app servers might need to ma= ke an authorization decision. The nature of that information will dictate m= uch of the requirements here: to whom can it be revealed, and to whom must = it be confidential; how is it structured; etc.=C2=A0


Ok. I will add more d= etails to clarify these aspects.
In general, I can think of two p= ossible ways to provide authorization:
1. Self-contained token= , which includes all the authorizations needed for the server providing= the service to be able to make a decision to grant or deny the service req= uest, and might include control over the level of service provided to the u= ser.
2. Opaque token, which requires an introspection step= , where the server providing the service would reach to the authorization s= erver to get the details of the authorizations provided for that specific t= oken.

There are pros and cons to each approach tha= t we need to discuss and make a decision on supporting one of these, or may= be both.
Do you see other options here?

=C2=A0

For the "Authorization Server" function, sinc= e it assumes an "administrator" who can authorize access to a set= of resources under its control, I'd imagine that the only relying part= ies that would accept the token have a very clear prior association with th= e "administrator" (though we'd need to say more about what we = imagine it would be).

Yes. Sur= e, I will add more details to cover this.


=C2=A0
In federat= ed identity models that come up fairly often, you sometimes do have trust a= cross domain boundaries that is significantly looser. If that's in scop= e, that's important to understand.


I am definitely = open to discussing this and see if we can find a common solution that would= apply to this use case too.


= Regards,
=C2=A0Rifaat


=C2= =A0
Jon Peterson
Neustar, Inc.

From: sipcore <sipcore-bounces@ietf.org&g= t; on behalf of Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Wednesday, April 20, 2016 at = 10:40 AM
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] SIP Authenticati= on/Authorization Problem Statement

All,

=C2=A0

A group of us decided to take a step back from discussing the = SIP OAuth document, and instead decided to discuss the SIP Authentication/A= uthorization problem to allow the different parties to articulate where they are coming from and what problem they are= trying to solve.

=C2=A0

I started this discussion with the following text as a startin= g point:

=C2=A0

The follo= wing is a simplified classic SIP deployment model:

=C2=A0

+--------= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+

|=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | SIP App|<= /font>

|=C2=A0= =C2=A0 UA=C2=A0=C2=A0 |----------------------| Proxy=C2=A0 |---------------= -------| Server |

|=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

+--------= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--------+

=C2=A0

With this= model, the endpoint is assigned an outbound SIP proxy and all SIP communic= ations must go through that SIP proxy.

=C2=A0

The SIP P= roxy plays 3 different roles:<= /font>

1. Authen= tication Server (SIP Registrar)

2. Author= ization Server

3. Servic= e provider, e.g. basic calls, call forwarding, call transfer, etc.

=C2=A0

SIP Appli= cation Servers provide advanced SIP services, e.g. conference, presence, et= c. Application Servers usually have their own authentication and authorizat= ion mechanism that is separate from the one provided by the SIP proxy.

=C2=A0

We would = like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the user authenti= cation and services authorization to separate network element(s):

=C2=A0

The first= goal is to =E2=80=9Coutsource=E2=80=9D the user authentication part to a s= eparate=C2=A0IdP entity, to allow the SIP user to use his credentials with = the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP A= pplication Servers.

=C2=A0

The secon= d goal is to =E2=80=9Coutsource=E2=80=9D the authorization part to a separa= te network element to allow the *administrator* to grant access to the basi= c services provided by the SIP Proxy and the various advanced services provided by the SIP Application Servers.

=C2=A0

I also explained that my motivation for this work is to addres= s few *Enterprise* use cases, which mainly include the Single-Sign On use c= ase where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP = services, and a centralized authorization use case where the administrator = is able to authorize access to these services from one network element.


=C2=A0

Jon suggested that there are several use cases that we should = be looking at, and he articulated these use cases as follows:=

=C2=A0

But more to my point (and I suspect Adam's) there are several distin= ct use cases for SIP that involve adding a secure attestation about the use= r to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to= whether the meat of that assertion is fetched from a network service or ge= nerated locally at a SIP entity - for SIP Identity-like architectures, one = might say the IdP-ish component of the architecture (the "authentication service") is typically = colocated with a proxy server, for example. In some cases, the relying part= ies downstream are in the same trust domain as the attester/user, and in so= me cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in = the confidentiality of the user's identity. This encompasses interworki= ng with external protocols like Jingle and WebRTC, this encompasses prevent= ing impersonation, this potentially involves enterprise use cases like Cullen was talking about.=C2=A0<= /span>

=C2=A0

=C2=A0

Adam elaborated on Jon=E2=80=99s statement that talks about = =E2=80=9Cdifferent trust domains=E2=80=9D as follows:

=C2=A0

I believe h= e's referring to the kind of use cases addressed by RFC 4474 and by the= work currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use b= y an entity in a completely unrelated trust domain.

There= 9;s also the matter of interdomain trait-based authorization (independent o= f identity). The introduction section of RFC 4484 is a really good place to= start if you're not familiar with the concept.

=C2=A0

=C2=A0


At this point Adam, as SIPCORE chair, suggested that we contin= ue this discussion on the SIPCORE mailing list. So here we are=E2=80=A6

=C2=A0

Regards,

=C2=A0Rifaat

--94eb2c11c4c28b5d120531254624-- From nobody Sat Apr 23 04:39: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 3953312D6D6 for ; Sat, 23 Apr 2016 04:39:44 -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 fDU0IQ5JHIVM for ; Sat, 23 Apr 2016 04:39:42 -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 F19D112D0B0 for ; Sat, 23 Apr 2016 04:39:41 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id t129so166493767vkg.2 for ; Sat, 23 Apr 2016 04:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kPR2NT777WfK7LZJz2vNc7Gj0SnXSbG94RqhWyffmRc=; b=kE07j/F40MkU2wkWRZxy6KONQ/WmQmpffhMphQpElstULH3jddzy8zabMkOqX3PzB6 45oP1Cjv0EIaFYmj4iawWn5E2bQrCPfV3Oxdf4getIdKt/YiLneOz/WlkarWGnIQUwcH QSTMmbS4e6kyzEOAVFb9NbSV6KgyfqUK1zm1HRXAguliWaQan7otDNaC5nDXLj7kDOSu vD3GNH7PKlPjs8qvY0DT/6YCuHxn/5P/5oUkiMrY1H2RSDCl6Jzqd2SXaOq9n+DH1NoT 8MJ8i/XUASh/34lqFTP4JWNpd8CRUby4SNigXwzVkc+u0Xvn35k5T5t10vwkrOc5Q/qn Ktyg== 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:date :message-id:subject:from:to:cc; bh=kPR2NT777WfK7LZJz2vNc7Gj0SnXSbG94RqhWyffmRc=; b=AeDvib/1aLMxVpURPoMXkBivcl/BFFOQdrhVJ/zC5MfUmDh2TbyjI42Zse9pghDTdM fhFv1kKdK3HwEtvA9HJPptoBGUswpfnbjhXERrowoVKFXOoii1rdnkAHirDEaM14LRpL fm1ft0wbS+XJ8XXBDgQkHKYscpe5IX4YjUiLGJlz8FTIWEDWWJj+JZ3RceY4tzRJab24 QbmAS2jROPcu6IH8Pupt0ewMREBHmVyMFAO+mGg0P1QJC/jgS9DGXzx9QuVgED7v5+h2 cazvE/Q3RJJbvpxg51F55QoqoCRME6kwwNQm844Ll0dCnX22eUyqUiXkNRzkbGRvmTNE iZuA== X-Gm-Message-State: AOPr4FV0JSjYHRBVsGUAYYYVLUWXnCexRM5hN9IvWZzDo6FoWXUWgdWMxIOneGPrEY7iaO/FwyG6e/zIwznCcw== MIME-Version: 1.0 X-Received: by 10.159.53.67 with SMTP id o61mr13972998uao.83.1461411581119; Sat, 23 Apr 2016 04:39:41 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sat, 23 Apr 2016 04:39:41 -0700 (PDT) In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF9FEFE302@UCOLHU2J.easf.csd.disa.mil> References: <8486C8728176924BAF5BDB2F7D7EEDDF9FEFE302@UCOLHU2J.easf.csd.disa.mil> Date: Sat, 23 Apr 2016 07:39:41 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" Content-Type: multipart/alternative; boundary=94eb2c03bb2629d4be05312566b6 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] SIP Authentication/Authorization Problem Statement 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, 23 Apr 2016 11:39:44 -0000 --94eb2c03bb2629d4be05312566b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Radhika, I need to educate myself about Diameter/Radius and the SIP-related RFCs. Meanwhile, please feel free to chime in with any thoughts about this discussion based on your experience with Diameter/Radius. Regards, Rifaat On Wed, Apr 20, 2016 at 2:17 PM, Roy, Radhika R CIV USARMY RDECOM CERDEC (US) wrote: > Hi, Rifaat and all: > > In addition, you can also look into SIP-related > authentication/Authorization in DIAMETER/RADIUS RFCs - how they use AAA > protocol to address the similar problem. > > BR/Radhika > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat > Shekh-Yusef > Sent: Wednesday, April 20, 2016 1:41 PM > To: sipcore@ietf.org > Subject: [Non-DoD Source] [sipcore] SIP Authentication/Authorization > Problem Statement > > All, > > > > A group of us decided to take a step back from discussing the SIP OAuth > document, and instead decided to discuss the SIP > Authentication/Authorization problem to allow the different parties to > articulate where they are coming from and what problem they are trying to > solve. > > > > I started this discussion with the following text as a starting point: > > > > The following is a simplified classic SIP deployment model: > > > > +--------+ +--------+ +--------= + > > | | | SIP | | SIP App= | > > | UA |----------------------| Proxy |----------------------| Server = | > > | | | | | = | > > +--------+ +--------+ +--------= + > > > > With this model, the endpoint is assigned an outbound SIP proxy and all > SIP communications must go through that SIP proxy. > > > > The SIP Proxy plays 3 different roles: > > 1. Authentication Server (SIP Registrar) > > 2. Authorization Server > > 3. Service provider, e.g. basic calls, call forwarding, call transfer, et= c. > > > > SIP Application Servers provide advanced SIP services, e.g. conference, > presence, etc. Application Servers usually have their own authentication > and authorization mechanism that is separate from the one provided by the > SIP proxy. > > > > We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the us= er authentication > and services authorization to separate network element(s): > > > > The first goal is to =E2=80=9Coutsource=E2=80=9D the user authentication = part to a > separate IdP entity, to allow the SIP user to use his credentials with th= e > IdP to register with the SIP Proxy and get basic SIP services, and to get > access to the advanced services provided by the SIP Application Servers. > > > > The second goal is to =E2=80=9Coutsource=E2=80=9D the authorization part = to a separate > network element to allow the *administrator* to grant access to the basic > services provided by the SIP Proxy and the various advanced services > provided by the SIP Application Servers. > > > > I also explained that my motivation for this work is to address few > *Enterprise* use cases, which mainly include the Single-Sign On use case > where the user is authenticated once and as a result the user gets access > to a variety of SIP and non-SIP services, and a centralized authorization > use case where the administrator is able to authorize access to these > services from one network element. > > > > > > > Jon suggested that there are several use cases that we should be looking > at, and he articulated these use cases as follows: > > > > But more to my point (and I suspect Adam's) there are several distinct us= e > cases for SIP that involve adding a secure attestation about the user to > SIP requests that will be consumed and trusted by some entity downstream. > This problem is probably generic to whether the meat of that assertion is > fetched from a network service or generated locally at a SIP entity - for > SIP Identity-like architectures, one might say the IdP-ish component of t= he > architecture (the "authentication service") is typically colocated with a > proxy server, for example. In some cases, the relying parties downstream > are in the same trust domain as the attester/user, and in some cases they > could be in a different trust domain. It may vary in the confidentiality = of > the assertion, or indeed in the confidentiality of the user's identity. > This encompasses interworking with external protocols like Jingle and > WebRTC, this encompasses preventing impersonation, this potentially > involves enterprise use cases like Cullen was talking about. > > > > > > Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdiff= erent trust > domains=E2=80=9D as follows: > > > > I believe he's referring to the kind of use cases addressed by RFC 4474 > and by the work currently going on in STIR -- ones in which some entity > asserts the identity of a party in the call for use by an entity in a > completely unrelated trust domain. > > There's also the matter of interdomain trait-based authorization > (independent of identity). The introduction section of RFC 4484 is a real= ly > good place to start if you're not familiar with the concept. > > > > > > > > > At this point Adam, as SIPCORE chair, suggested that we continue this > discussion on the SIPCORE mailing list. So here we are=E2=80=A6 > > > > Regards, > > Rifaat > > --94eb2c03bb2629d4be05312566b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Radhika,

I need to educate mysel= f about Diameter/Radius and the SIP-related RFCs.
Meanwhile, plea= se feel free to chime in with any thoughts about this discussion based on y= our experience with Diameter/Radius.

Regards,
=C2=A0Rifaat



On Wed, Apr 20, 2016 at 2:17 PM,= Roy, Radhika R CIV USARMY RDECOM CERDEC (US) <radhika.r.roy.civ@= mail.mil> wrote:
Hi, Rifa= at and all:

In addition, you can also look into SIP-related authentication/Authorizatio= n in DIAMETER/RADIUS RFCs - how they use AAA protocol to address the simila= r problem.

BR/Radhika

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 20, 2016 1:41 PM
To: sipcore@ietf.org
Subject: [Non-DoD Source] [sipcore] SIP Authentication/Authorization Proble= m Statement

All,



A group of us decided to take a step back from discussing the SIP OAuth doc= ument, and instead decided to discuss the SIP Authentication/Authorization = problem to allow the different parties to articulate where they are coming = from and what problem they are trying to solve.



I started this discussion with the following text as a starting point:



The following is a simplified classic SIP deployment model:



+--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+

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

|=C2=A0 =C2=A0UA=C2=A0 =C2=A0|----------------------| Proxy=C2=A0 |--------= --------------| Server |

|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |

+--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+



With this model, the endpoint is assigned an outbound SIP proxy and all SIP= communications must go through that SIP proxy.



The SIP Proxy plays 3 different roles:

1. Authentication Server (SIP Registrar)

2. Authorization Server

3. Service provider, e.g. basic calls, call forwarding, call transfer, etc.=



SIP Application Servers provide advanced SIP services, e.g. conference, pre= sence, etc. Application Servers usually have their own authentication and a= uthorization mechanism that is separate from the one provided by the SIP pr= oxy.



We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the user= authentication and services authorization to separate network element(s):<= br>


The first goal is to =E2=80=9Coutsource=E2=80=9D the user authentication pa= rt to a separate IdP entity, to allow the SIP user to use his credentials w= ith the IdP to register with the SIP Proxy and get basic SIP services, and = to get access to the advanced services provided by the SIP Application Serv= ers.



The second goal is to =E2=80=9Coutsource=E2=80=9D the authorization part to= a separate network element to allow the *administrator* to grant access to= the basic services provided by the SIP Proxy and the various advanced serv= ices provided by the SIP Application Servers.



I also explained that my motivation for this work is to address few *Enterp= rise* use cases, which mainly include the Single-Sign On use case where the= user is authenticated once and as a result the user gets access to a varie= ty of SIP and non-SIP services, and a centralized authorization use case wh= ere the administrator is able to authorize access to these services from on= e network element.






Jon suggested that there are several use cases that we should be looking at= , and he articulated these use cases as follows:



But more to my point (and I suspect Adam's) there are several distinct = use cases for SIP that involve adding a secure attestation about the user t= o SIP requests that will be consumed and trusted by some entity downstream.= This problem is probably generic to whether the meat of that assertion is = fetched from a network service or generated locally at a SIP entity - for S= IP Identity-like architectures, one might say the IdP-ish component of the = architecture (the "authentication service") is typically colocate= d with a proxy server, for example. In some cases, the relying parties down= stream are in the same trust domain as the attester/user, and in some cases= they could be in a different trust domain. It may vary in the confidential= ity of the assertion, or indeed in the confidentiality of the user's id= entity. This encompasses interworking with external protocols like Jingle a= nd WebRTC, this encompasses preventing impersonation, this potentially invo= lves enterprise use cases like Cullen was talking about.





Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdiffer= ent trust domains=E2=80=9D as follows:



I believe he's referring to the kind of use cases addressed by RFC 4474= and by the work currently going on in STIR -- ones in which some entity as= serts the identity of a party in the call for use by an entity in a complet= ely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (indep= endent of identity). The introduction section of RFC 4484 is a really good = place to start if you're not familiar with the concept.








At this point Adam, as SIPCORE chair, suggested that we continue this discu= ssion on the SIPCORE mailing list. So here we are=E2=80=A6



Regards,

=C2=A0Rifaat


--94eb2c03bb2629d4be05312566b6-- From nobody Sat Apr 23 04:55: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 1042F12D7F3 for ; Sat, 23 Apr 2016 04:55:50 -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 bRsJoaOCiLOs for ; Sat, 23 Apr 2016 04:55:48 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 5C76412D6FF for ; Sat, 23 Apr 2016 04:55:48 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id n67so144957030vkf.3 for ; Sat, 23 Apr 2016 04:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Glpjcz6NfXcV1P1ntbwGWv0rZAKNdqh2yu2OAXjG+50=; b=c07aoKmqean0FNBJy+LX2ia5OxSjrN65k7OHqqz3U2U4ceLpcDLrk1kRO/T0tUJpvF v0uCxXMzWx4H6cHBshxdn8wR2HijuXcqELUvhKVYldZHepURw/dH/AxoB2K1rFrECQDI LXWBm1HUSCGjNm8GrVWujUo7BCney7JR372KN+ouiSHHS6Kt308de04O9ao8l8NNtRJs yoMhJQdjnrHMuxJdXBd4Xd5QyYaohR+yFr9wgmv4hdK3SP5gwaPmm1F1qe/QCvpktsWJ 5o+m/P1uw56vAtHqkZRzxenaJ6VOupe3/4sw8DaDe9Y4o8yH9NHZe/60t645BnLEUqVy 56aQ== 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:date :message-id:subject:from:to:cc; bh=Glpjcz6NfXcV1P1ntbwGWv0rZAKNdqh2yu2OAXjG+50=; b=ANfvrHvtjp3P9+gAVRtLaP7RBMe+cSftVGD/l25MFaHPM9BsQkS0I8ve7h/h0SyRrp vGQnzOcy+plo6sfFiTvWcA3h0wNKGzu/wUggQnu3r/C+llFTk6v8ATG0+ZA2RZbT/HFf 16XOHvieKWZ6p5fLcr+at/+3QBTtiNTeb1on5ESHtF2CxUACNOX6IxXCSDCNTljdSWKq NyXDB5OzGD1nnyyyTda7iByONxqdtQKyUZ10FFfdKLb2lpLAL6edAgHGqrGo60ayF9wP JUlA0kzrixfKTYN3jtf0w5Gbv1Fvl2LszE5Ba8euB+M9GyzhnEJZb92lOkIPW7YVnaD4 rzkw== X-Gm-Message-State: AOPr4FXgeSGowaJ4iBd0hNMhf1IcB3E88H+bmkGgJGVxwnq6rtm4V1+w3GsOyFeo0Z7fyEcCkl9EvV2CzTcezA== MIME-Version: 1.0 X-Received: by 10.159.53.67 with SMTP id o61mr14007508uao.83.1461412547458; Sat, 23 Apr 2016 04:55:47 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sat, 23 Apr 2016 04:55:47 -0700 (PDT) In-Reply-To: <87oa9390ju.fsf@hobgoblin.ariadne.com> References: <87oa9390ju.fsf@hobgoblin.ariadne.com> Date: Sat, 23 Apr 2016 07:55:47 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=94eb2c03bb26c302360531259fe6 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 23 Apr 2016 11:55:50 -0000 --94eb2c03bb26c302360531259fe6 Content-Type: text/plain; charset=UTF-8 Thanks Dale! Yes, you are absolutely right. Two steps are needed: authentication of the user and authorization to access services. These could be done by one new network element, or could be done by two separate network elements. We need to discuss these options and pros and cons of each. Regards, Rifaat On Wed, Apr 20, 2016 at 10:07 PM, Dale R. Worley wrote: > Rifaat Shekh-Yusef writes: > > The following is a simplified classic SIP deployment model: > > > > +--------+ +--------+ > +--------+ > > | | | SIP | | SIP > App| > > | UA |----------------------| Proxy |----------------------| Server > | > > | | | | | > | > > +--------+ +--------+ > +--------+ > > > The first goal is to "outsource" the user authentication part to a > > separate IdP entity, to allow the SIP user to use his credentials with > the > > IdP to register with the SIP Proxy and get basic SIP services, and to get > > access to the advanced services provided by the SIP Application Servers. > > > > The second goal is to "outsource" the authorization part to a separate > > network element to allow the *administrator* to grant access to the basic > > services provided by the SIP Proxy and the various advanced services > > provided by the SIP Application Servers. > > I have a hard time thinking about this without knowing what the dataflow > is. I don't know if this limitation is intrinsic to the subject or just > how I think. > > For example, in the sipX system, calls are only allowed to exit the > IP->PSTN gateway if they arrive at the gateway directly from the proxy, > and the proxy verifies that the SIP caller is allowed to make a PSTN > call to the specific destination. So in that example, the UA contains > the user's credentials, which it attaches to the request and sends to > the proxy. (Let's neglect how the UA gets a valid nonce.) The proxy > authenticates the user and then authorizes the user to make a PSTN call > to the particular E.164 number. It then attaches an authorization token > to the request (i.e., the IP source address) to the request and sends it > to the application server (gateway). > > It seems like permission to use the app server requires two steps: (1) > authentication of the source, and then (2) authorization of the source > to use the service. These can be done together in one place (as in the > above example) or they can be done in two places. In principle, either > step can be done in either the proxy or the app server, or even the UA. > The entity that performs a step can outsource it to another server. If > either step is done by the proxy, it needs to attach to the request some > sort of token indicating that the step has been completed before sending > the request to the app server. > > It seems like there are a dozen or more dataflow patterns that could be > used to "outsource" one or both of these steps. > > Dale > --94eb2c03bb26c302360531259fe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Dale!

Yes, you are absolutely ri= ght.

Two steps are needed: authentication of the u= ser and authorization to access services.
These could be done by = one new network element, or could be done by two separate network elements.=

We need to discuss these options and pros and con= s of each.

Regards,
=C2=A0Rifaat



On Wed, Apr 20, 2016 at 10:07 PM, Dale R. Worley <worley= @ariadne.com> wrote:
= Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> writes:
> The following is a simplified classic SIP deployment model:
>
> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
> |=C2=A0 =C2=A0 =C2=A0 =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 | SIP App| > |=C2=A0 =C2=A0UA=C2=A0 =C2=A0|----------------------| Proxy=C2=A0 |---= -------------------| Server |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+

> The first goal is to "outsource" the user authe= ntication part to a
> separate IdP entity, to allow the SIP user to use his credentials with= the
> IdP to register with the SIP Proxy and get basic SIP services, and to = get
> access to the advanced services provided by the SIP Application Server= s.
>
> The second goal is to "outsource" the authorization part to = a separate
> network element to allow the *administrator* to grant access to the ba= sic
> services provided by the SIP Proxy and the various advanced services > provided by the SIP Application Servers.

I have a hard time thinking about this without knowing what the data= flow
is.=C2=A0 I don't know if this limitation is intrinsic to the subject o= r just
how I think.

For example, in the sipX system, calls are only allowed to exit the
IP->PSTN gateway if they arrive at the gateway directly from the proxy,<= br> and the proxy verifies that the SIP caller is allowed to make a PSTN
call to the specific destination.=C2=A0 So in that example, the UA contains=
the user's credentials, which it attaches to the request and sends to the proxy.=C2=A0 (Let's neglect how the UA gets a valid nonce.)=C2=A0 T= he proxy
authenticates the user and then authorizes the user to make a PSTN call
to the particular E.164 number.=C2=A0 It then attaches an authorization tok= en
to the request (i.e., the IP source address) to the request and sends it to the application server (gateway).

It seems like permission to use the app server requires two steps: (1)
authentication of the source, and then (2) authorization of the source
to use the service.=C2=A0 These can be done together in one place (as in th= e
above example) or they can be done in two places.=C2=A0 In principle, eithe= r
step can be done in either the proxy or the app server, or even the UA.
The entity that performs a step can outsource it to another server.=C2=A0 I= f
either step is done by the proxy, it needs to attach to the request some sort of token indicating that the step has been completed before sending the request to the app server.

It seems like there are a dozen or more dataflow patterns that could be
used to "outsource" one or both of these steps.

Dale

--94eb2c03bb26c302360531259fe6-- From nobody Sat Apr 23 05:07: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 6A8A112DAB4 for ; Sat, 23 Apr 2016 05:07: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 EPPg0adN1qQC for ; Sat, 23 Apr 2016 05:07:27 -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 38B9112D9D7 for ; Sat, 23 Apr 2016 05:07:27 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id t129so166931614vkg.2 for ; Sat, 23 Apr 2016 05:07: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:date:message-id:subject:from:to :cc; bh=otZkBiyOiXHpzJwmvdNAtdaRTMUGCbTPNKR4qbw57+8=; b=hstlYHyKGeRHdLWOTbufveIC1maH4b7D1UNaPDeYHGnJUK9Syol26EP1uulEBeHJiH jX5saQwyxL6ghLELxov75teGZHV5Tfdc279TEQQa8bSVJYQdCtLf1dUQ2j8XuGJfhQPx zXazq1JEWTt1FOvuUgBUC5wBq7mHgpyz0FhCKwTF/K4T2UOGURxJUemZj3l9kBfgMVfJ O34IchQl6V23KLouow5BNJ0A0J4dnw7k0wcx4j2u+QrHduZzTRim1/3fH7LDq7CCJ7PT 3mFpA5hrEaowy1mraitDsakPEa94yjqf/kv3nqMLsXYtlRR3XRC+jKN1eI42CzSNBVw2 QsmA== 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:date :message-id:subject:from:to:cc; bh=otZkBiyOiXHpzJwmvdNAtdaRTMUGCbTPNKR4qbw57+8=; b=AwLZp7N8KczMAeaRMEtkEczjf/yD2QdPimnugyJ1zb6XjyQsBNF8LmkDgllmyiLkpn B4+5S+8YBjoHxCa3lF2ejogNYoeCo6sUD+R86+vQWvMO4j1GqqBb7h7JeCmAVas+tlWd gNzcBE/4d5zp257kpsbWFnJYuQo8j1MQET1wpRBiLBdqSRUXQzrBuomm0iCyB3GMvGPp Jw2fLzpUU6helRc4Td8/t7fFD5rth9wvfxytDN13sAaY0h+ea6Y2dsOsuV5h333Rie9b cLOrX4CFLTt5c1egSJtDKJFRk/J5aq7eNgxSGxiLy4CuWnoRbccYWtePg1cZBe8kYwXL WCCg== X-Gm-Message-State: AOPr4FVz0C4N2ro5b8bYofEi6cX1Fg5sumZJ9BK676LF4DmvNjMm/qNmhyeujPCfbnXBcRPqP3WjvIyQWMlg6g== MIME-Version: 1.0 X-Received: by 10.176.64.231 with SMTP id i94mr14222255uad.66.1461413246279; Sat, 23 Apr 2016 05:07:26 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sat, 23 Apr 2016 05:07:26 -0700 (PDT) In-Reply-To: <5718E414.9060403@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B37F71758@ESESSMB209.ericsson.se> <5718E414.9060403@nostrum.com> Date: Sat, 23 Apr 2016 08:07:26 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Robert Sparks Content-Type: multipart/alternative; boundary=94eb2c1237dc6a2adf053125c99c Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 23 Apr 2016 12:07:40 -0000 --94eb2c1237dc6a2adf053125c99c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer, I agree with your second and third points below. Regarding the first point, I agree with Robert, that calling it SIP Registrar might be even more confusing. Robert, Yes, the proxy would have an important role to play in the authNZ (authentication/authorization) story. I like you suggestion of explicitly separating the registrar function from the proxy function. I will do that in the next version of the text. Regards, Rifaat On Thu, Apr 21, 2016 at 10:30 AM, Robert Sparks wrote: > > > On 4/21/16 7:46 AM, Christer Holmberg wrote: > > Hi, > > > > A few comments on the text: > > > > First, I don=E2=80=99t think we should say =E2=80=9Coutbound SIP proxy=E2= =80=9D. That may confuse > people with RFC 5256, and I assume that is not what you are talking about= . > Why not simply call it =E2=80=9CSIP registrar=E2=80=9D? > > Because it's not acting only as a registrar, at least in that example. > Routes (loaded with Service-Route I assume?) are forcing traffic through > it. If it has a role to play in this auth/auth story when messages go > through it in this role, it needs to have a named player, and registrar > would be even more confusing. (Does it have such a role?) > > It might be even more useful to show any proxies put on the path by Route > establishing mechanisms (preloaded or provided by Service-Route) as > separate from the registrar, even if the roles are combined in one box a > given deployment. > > > > Second, when we talk about credentials, we must be clear on what kind of > credentials we talk about. > > > > Third, it is good trying to come up with a set of goals, but it needs to > be clear that for some use-cases only some goals may apply. > > > > Thanks! > > > > Regards, > > > > Christer > > > > > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org > ] *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* 20 April 2016 20:41 > *To:* sipcore@ietf.org > *Subject:* [sipcore] SIP Authentication/Authorization Problem Statement > > > > All, > > > > A group of us decided to take a step back from discussing the SIP OAuth > document, and instead decided to discuss the SIP > Authentication/Authorization problem to allow the different parties to > articulate where they are coming from and what problem they are trying to > solve. > > > > I started this discussion with the following text as a starting point: > > > > The following is a simplified classic SIP deployment model: > > > > +--------+ +--------+ +--------= + > > | | | SIP | | SIP App= | > > | UA |----------------------| Proxy |----------------------| Server = | > > | | | | | = | > > +--------+ +--------+ +--------= + > > > > With this model, the endpoint is assigned an outbound SIP proxy and all > SIP communications must go through that SIP proxy. > > > > The SIP Proxy plays 3 different roles: > > 1. Authentication Server (SIP Registrar) > > 2. Authorization Server > > 3. Service provider, e.g. basic calls, call forwarding, call transfer, et= c. > > > > SIP Application Servers provide advanced SIP services, e.g. conference, > presence, etc. Application Servers usually have their own authentication > and authorization mechanism that is separate from the one provided by the > SIP proxy. > > > > We would like to discuss the idea of =E2=80=9Coutsourcing=E2=80=9D the us= er authentication > and services authorization to separate network element(s): > > > > The first goal is to =E2=80=9Coutsource=E2=80=9D the user authentication = part to a > separate IdP entity, to allow the SIP user to use his credentials with th= e > IdP to register with the SIP Proxy and get basic SIP services, and to get > access to the advanced services provided by the SIP Application Servers. > > > > The second goal is to =E2=80=9Coutsource=E2=80=9D the authorization part = to a separate > network element to allow the *administrator* to grant access to the basic > services provided by the SIP Proxy and the various advanced services > provided by the SIP Application Servers. > > > > I also explained that my motivation for this work is to address few > *Enterprise* use cases, which mainly include the Single-Sign On use case > where the user is authenticated once and as a result the user gets access > to a variety of SIP and non-SIP services, and a centralized authorization > use case where the administrator is able to authorize access to these > services from one network element. > > > > > > Jon suggested that there are several use cases that we should be looking > at, and he articulated these use cases as follows: > > > > But more to my point (and I suspect Adam's) there are several distinct us= e > cases for SIP that involve adding a secure attestation about the user to > SIP requests that will be consumed and trusted by some entity downstream. > This problem is probably generic to whether the meat of that assertion is > fetched from a network service or generated locally at a SIP entity - for > SIP Identity-like architectures, one might say the IdP-ish component of t= he > architecture (the "authentication service") is typically colocated with a > proxy server, for example. In some cases, the relying parties downstream > are in the same trust domain as the attester/user, and in some cases they > could be in a different trust domain. It may vary in the confidentiality = of > the assertion, or indeed in the confidentiality of the user's identity. > This encompasses interworking with external protocols like Jingle and > WebRTC, this encompasses preventing impersonation, this potentially > involves enterprise use cases like Cullen was talking about. > > > > > > Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdiff= erent trust > domains=E2=80=9D as follows: > > > > I believe he's referring to the kind of use cases addressed by RFC 4474 > and by the work currently going on in STIR -- ones in which some entity > asserts the identity of a party in the call for use by an entity in a > completely unrelated trust domain. > > There's also the matter of interdomain trait-based authorization > (independent of identity). The introduction section of RFC 4484 is a real= ly > good place to start if you're not familiar with the concept. > > > > > > > > At this point Adam, as SIPCORE chair, suggested that we continue this > discussion on the SIPCORE mailing list. So here we are=E2=80=A6 > > > > Regards, > > Rifaat > > > _______________________________________________ > sipcore mailing listsipcore@ietf.orghttps://www.ietf.org/mailman/listinfo= /sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --94eb2c1237dc6a2adf053125c99c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer,

I agree with your second and = third points below.

Regarding the first point, I a= gree with Robert, that calling it SIP Registrar might be even more confusin= g.


Robert,

Yes, the proxy would have an important role to play in the authNZ (authent= ication/authorization) story.
I like you suggestion of explicitly= separating the registrar function from the proxy function. I will do that = in the next version of the text.

Regards,
=C2=A0Rifaat




<= div class=3D"gmail_extra">
On Thu, Apr 21, 20= 16 at 10:30 AM, Robert Sparks <rjsparks@nostrum.com> wrot= e:
=20 =20 =20


On 4/21/16 7:46 AM, Christer Holmberg wrote:
=20 =20 =20

Hi,

=C2=A0

A few comments on the text:

=C2=A0

First, I don=E2=80=99t think we should say =E2=80=9Coutbound SIP proxy= =E2=80=9D. That may confuse people with RFC 5256, and I assume that is not what you are talking about. Why not simply call it =E2=80=9CSIP registrar=E2=80=9D?

 Because it's not acting only as a registrar, at least in that example. Routes (loaded with Service-Route I assume?) are forcing traffic through it. If it has a role to play in this auth/auth story when messages go through it in this role, it needs to have a named player, and registrar would be even more confusing. (Does it have such a role?)

It might be even more useful to show any proxies put on the path by Route establishing mechanisms (preloaded or provided by Service-Route) as separate from the registrar, even if the roles are combined in one box a given deployment.

=C2=A0

Second, when we talk about credentials, we must be clear on what kind of credentials we talk about.

=C2=A0

Third, it is good trying to come up with a set of goals, but it needs to be clear that for some use-cases only some goals may apply.

=C2=A0

Thanks!<= /p>

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

=C2=A0

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 20 April 2016 20:41
To: sipcore@ietf.org
Subject: [sipcore] SIP Authentication/Authorization Problem Statement

=C2=A0

All,

=C2=A0

A group of us decided to take a step back from discussing the SIP OAuth document, and instead decided to discuss the SIP Authentication/Authorization problem to allow the different parties to articulate where they are coming from and what problem they are trying to solve.

=C2=A0

I started this discussion with the following text as a starting point:

=C2=A0

The following is a simplified classic SIP deployment model:

=C2=A0

+--------+=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--------+=

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=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 UA=C2=A0=C2=A0 |-= ---------------------| Proxy=C2=A0 |----------------------| Server |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

+--------+=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0+--------+<= u>

=C2=A0

With this model, the endpoint i= s assigned an outbound SIP proxy and all SIP communications must go through that SIP proxy.

=C2=A0

The SIP Proxy plays 3 different roles:<= u>

1. Authentication Server (SIP Registrar)

2. Authorization Server<= span style=3D"font-size:10.5pt;color:#500050">

3. Service provider, e.g. basic calls, call forwarding, call transfer, etc.

=C2=A0

SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy.

=C2=A0

We would like to discuss the id= ea of =E2=80=9Coutsourcing=E2=80=9D the user authentication and = services authorization to separate network element(s):

=C2=A0

The first goal is to =E2=80=9Co= utsource=E2=80=9D the user authentication part to a separate=C2=A0IdP entity, t= o allow the SIP user to use his credentials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application Servers.

=C2=A0

The second goal is to =E2=80=9C= outsource=E2=80=9D the authorization part to a separate network element to allow the *administrator* to grant access to the basic services provided by the SIP Proxy and the various advanced services provided by the SIP Application Servers.

=C2=A0

I also explained that my motivation for this work is to address few *Enterprise* use cases, which mainly include the Single-Sign On use case where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP services, and a centralized authorization use case where the administrator is able to authorize access to these services from one network element.

=C2=A0

=C2=A0

Jon suggested that there are several use cases that we should be looking at, and he articulated these use cases as follows:

=C2=A0

But more to my point (and I sus= pect Adam's) there are several distinct use cases for SIP that involve adding a secure attestation about the user to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to whether the meat of that assertion is fetched from a network service or generated locally at a SIP entity - for SIP Identity-like architectures, one might say the IdP-ish component of the architecture (the "authentication service") is typically colocated with a proxy server, fo= r example. In some cases, the relying parties downstream are in the same trust domain as the attester/user, and in some cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality of the user's identity. This encompasses interworking with external protocols like Jingle and WebRTC, this encompasses preventing impersonation, this potentially involves enterprise use cases like Cullen was talking about.=C2=A0

=C2=A0

=C2=A0

Adam elaborated on Jon=E2=80=99s statement that talks about =E2=80=9Cdifferent trust domains= =E2=80=9D as follows:

=C2=A0

I belie= ve he's referring to the kind of use cases addressed by RFC 4474 and by the work currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use by an entity in a completely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (independent of identity). The introduction section of RFC 4484 is a really good place to start if you're not familiar with the concept.

=C2=A0

=C2=A0

=C2=A0

At this point Adam, as SIPCORE chair, suggested that we continue this discussion on the SIPCORE mailing list. So here we are=E2=80=A6

=C2=A0

Regards,

=C2=A0Rifaat



_______________________________________________
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


--94eb2c1237dc6a2adf053125c99c-- From nobody Sun Apr 24 06:09: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 89BF312B05A for ; Sun, 24 Apr 2016 06:09:55 -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 iQjRHdC1uVbe for ; Sun, 24 Apr 2016 06:09:53 -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 11C0512B006 for ; Sun, 24 Apr 2016 06:09:51 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-2a-571cc59d3945 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 01.C2.26920.D95CC175; Sun, 24 Apr 2016 15:09:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Sun, 24 Apr 2016 15:09:49 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , Robert Sparks Thread-Topic: [sipcore] SIP Authentication/Authorization Problem Statement Thread-Index: AQHRm9ppFPgsGhvqf0e0X/MXMqHQ+J+XWCoAgAHFSjQ= Date: Sun, 24 Apr 2016 13:09:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F77E26@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F71758@ESESSMB209.ericsson.se> <5718E414.9060403@nostrum.com>, 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_7594FB04B1934943A5C02806D1A2204B37F77E26ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7iu7cozLhBj/PmVvsfNHKZnFtTiOb xdcfm9gcmD12zrrL7rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZXy51cpW0HeDseLb3jds DYxb9jB2MXJySAiYSPx8+wTKFpO4cG89WxcjF4eQwBFGiUMT9rNAOEsYJaY86mXvYuTgYBOw kOj+pw3SICIQJvH2z0mwZmYBTYlHO/cygdjCAp4S52ctYoao8ZJ423qTHcK2kmiauIkNxGYR UJXoPrOOFcTmFfCV+P/zNivErl+MEquvfQUbyikQKHHp2EGwoYxA130/tYYJYpm4RNOXlawQ VwtILNlznhnCFpV4+fgfK0RNvsTCbU+ZIRYISpyc+YRlAqPILCTts5CUzUJSBhE3kPjy/jaU rS2xbOFrZghbX6L7/WkmZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQIj7uCW37o7 GFe/djzEKMDBqMTDu0BDJlyINbGsuDL3EKMEB7OSCG/xAaAQb0piZVVqUX58UWlOavEhRmkO FiVx3pzIf2FCAumJJanZqakFqUUwWSYOTqkGxuDiqFNT0p+olt/0PPZ605bGDy88z3MyK8pH yasbcM3l/OUodPsfY8N0y7N/i1we/roXdVxww5LlQX+Ejh14UZ7Dqv7Gp/L30xltGz+tWPzs nJEp5/0Vp1+nxV5ti17/ffu9iwee2V1WOCx9t9k7f76bSFJW1bcj0hP1+vWKLrotnCDD08o+ /6ISS3FGoqEWc1FxIgDfGJbNtAIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement 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, 24 Apr 2016 13:09:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F77E26ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We can call it something else, but I don't think we should call it "outboun= d proxy". Regards, Christer Sent from my Windows Phone ________________________________ From: Rifaat Shekh-Yusef Sent: =FD23/=FD04/=FD2016 15:07 To: Robert Sparks Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement Christer, I agree with your second and third points below. Regarding the first point, I agree with Robert, that calling it SIP Registr= ar might be even more confusing. Robert, Yes, the proxy would have an important role to play in the authNZ (authenti= cation/authorization) story. I like you suggestion of explicitly separating the registrar function from = the proxy function. I will do that in the next version of the text. Regards, Rifaat On Thu, Apr 21, 2016 at 10:30 AM, Robert Sparks > wrote: On 4/21/16 7:46 AM, Christer Holmberg wrote: Hi, A few comments on the text: First, I don=92t think we should say =93outbound SIP proxy=94. That may con= fuse people with RFC 5256, and I assume that is not what you are talking ab= out. Why not simply call it =93SIP registrar=94? Because it's not acting only as a registrar, at least in that example. Rout= es (loaded with Service-Route I assume?) are forcing traffic through it. If= it has a role to play in this auth/auth story when messages go through it = in this role, it needs to have a named player, and registrar would be even = more confusing. (Does it have such a role?) It might be even more useful to show any proxies put on the path by Route e= stablishing mechanisms (preloaded or provided by Service-Route) as separate= from the registrar, even if the roles are combined in one box a given depl= oyment. Second, when we talk about credentials, we must be clear on what kind of cr= edentials we talk about. Third, it is good trying to come up with a set of goals, but it needs to be= clear that for some use-cases only some goals may apply. Thanks! Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 20 April 2016 20:41 To: sipcore@ietf.org Subject: [sipcore] SIP Authentication/Authorization Problem Statement All, A group of us decided to take a step back from discussing the SIP OAuth doc= ument, and instead decided to discuss the SIP Authentication/Authorization = problem to allow the different parties to articulate where they are coming = from and what problem they are trying to solve. I started this discussion with the following text as a starting point: The following is a simplified classic SIP deployment model: +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned an outbound SIP proxy and all SIP= communications must go through that SIP proxy. The SIP Proxy plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, pre= sence, etc. Application Servers usually have their own authentication and a= uthorization mechanism that is separate from the one provided by the SIP pr= oxy. We would like to discuss the idea of =93outsourcing=94 the user authenticat= ion and services authorization to separate network element(s): The first goal is to =93outsource=94 the user authentication part to a sepa= rate IdP entity, to allow the SIP user to use his credentials with the IdP = to register with the SIP Proxy and get basic SIP services, and to get acces= s to the advanced services provided by the SIP Application Servers. The second goal is to =93outsource=94 the authorization part to a separate = network element to allow the *administrator* to grant access to the basic s= ervices provided by the SIP Proxy and the various advanced services provide= d by the SIP Application Servers. I also explained that my motivation for this work is to address few *Enterp= rise* use cases, which mainly include the Single-Sign On use case where the= user is authenticated once and as a result the user gets access to a varie= ty of SIP and non-SIP services, and a centralized authorization use case wh= ere the administrator is able to authorize access to these services from on= e network element. Jon suggested that there are several use cases that we should be looking at= , and he articulated these use cases as follows: But more to my point (and I suspect Adam's) there are several distinct use = cases for SIP that involve adding a secure attestation about the user to SI= P requests that will be consumed and trusted by some entity downstream. Thi= s problem is probably generic to whether the meat of that assertion is fetc= hed from a network service or generated locally at a SIP entity - for SIP I= dentity-like architectures, one might say the IdP-ish component of the arch= itecture (the "authentication service") is typically colocated with a proxy= server, for example. In some cases, the relying parties downstream are in = the same trust domain as the attester/user, and in some cases they could be= in a different trust domain. It may vary in the confidentiality of the ass= ertion, or indeed in the confidentiality of the user's identity. This encom= passes interworking with external protocols like Jingle and WebRTC, this en= compasses preventing impersonation, this potentially involves enterprise us= e cases like Cullen was talking about. Adam elaborated on Jon=92s statement that talks about =93different trust do= mains=94 as follows: I believe he's referring to the kind of use cases addressed by RFC 4474 and= by the work currently going on in STIR -- ones in which some entity assert= s the identity of a party in the call for use by an entity in a completely = unrelated trust domain. There's also the matter of interdomain trait-based authorization (independe= nt of identity). The introduction section of RFC 4484 is a really good plac= e to start if you're not familiar with the concept. At this point Adam, as SIPCORE chair, suggested that we continue this discu= ssion on the SIPCORE mailing list. So here we are=85 Regards, Rifaat _______________________________________________ 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 --_000_7594FB04B1934943A5C02806D1A2204B37F77E26ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We can call it something else, but I don't think we should call it "ou= tbound proxy".

Regards,

Christer

Sent from my Windows Phone
From: Rifaat Shekh-Yusef
Sent: =FD23= /=FD04/=FD2016 15:07
To: Robert Sparks
Cc: sipcore@ietf.org
Subject: Re: [= sipcore] SIP Authentication/Authorization Problem Statement

Christer,

I agree with your second and third points below.

Regarding the first point, I agree with Robert, that calling it SIP Re= gistrar might be even more confusing.


Robert,

Yes, the proxy would have an important role to play in the authNZ (aut= hentication/authorization) story.
I like you suggestion of explicitly separating the registrar function = from the proxy function. I will do that in the next version of the text.

Regards,
 Rifaat





On Thu, Apr 21, 2016 at 10:30 AM, Robert Sparks = <rjsparks@nost= rum.com> wrote:


On 4/21/16 7:46 AM, Christer Holmberg wrote:

Hi,

 

A few comments on the text:<= u>

 

First, I don=92t think we should sa= y =93outbound SIP proxy=94. That may confuse people with RFC 5256, and I as= sume that is not what you are talking about. Why not simply call it =93SIP registrar=94?

Because it's not acting only as a registrar, at least in that exampl= e. Routes (loaded with Service-Route I assume?) are forcing traffic through= it. If it has a role to play in this auth/auth story when messages go thro= ugh it in this role, it needs to have a named player, and registrar would be even more confusing. (Does it = have such a role?)

It might be even more useful to show any proxies put on the path by Route e= stablishing mechanisms (preloaded or provided by Service-Route) as separate= from the registrar, even if the roles are combined in one box a given depl= oyment.

 

Second, when we talk about credenti= als, we must be clear on what kind of credentials we talk about.

 

Third, it is good trying to come up= with a set of goals, but it needs to be clear that for some use-cases only= some goals may apply.

 

Thanks!

 

Regards,

 

Christer

 

 

<= span style=3D"font-size:11.0pt; font-family:"Calibri",sans-serif;= color:#1f497d"> 

From: sipcore [ma= ilto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 20 April 2016 20:41
To: sipcore@ie= tf.org
Subject: [sipcore] SIP Authentication/Authorization Problem Statemen= t

 

All,

 

A group of us decided to take a step back from= discussing the SIP OAuth document, and instead decided to discuss the SIP = Authentication/Authorization problem to allow the different parties to arti= culate where they are coming from and what problem they are trying to solve.

 

I started this discussion with the following t= ext as a starting point:

 

The following is = a simplified classic SIP deployment model:

 

+--------+= ;            &n= bsp;         +--------+&nbs= p;            &= nbsp;        +--------+

|  &nbs= p;     |        &nbs= p;            &= nbsp;| SIP    |       &nb= sp;            =   | SIP App|=

|   UA&= nbsp;  |----------------------| Proxy  |----------------------| S= erver |

|  &nbs= p;     |        = ;            &n= bsp; |        |    &= nbsp;           &nbs= p;     |        |

+--------+= ;            &n= bsp;         +--------+&nbs= p;             =         +--------+

 

With this model, = the endpoint is assigned an outbound SIP proxy and all SIP communications m= ust go through that SIP proxy.

 

The SIP Proxy pla= ys 3 different roles:

1. Authentication= Server (SIP Registrar)

2. Authorization = Server=

3. Service provid= er, e.g. basic calls, call forwarding, call transfer, etc.

 

SIP Application S= ervers provide advanced SIP services, e.g. conference, presence, etc. Appli= cation Servers usually have their own authentication and authorization mech= anism that is separate from the one provided by the SIP proxy.

 

We would like to = discuss the idea of =93outsourcing=94 the user authentication and services = authorization to separate network element(s):

 

The first goal is= to =93outsource=94 the user authentication part to a separate IdP ent= ity, to allow the SIP user to use his credentials with the IdP to register = with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application= Servers.<= /u>

 

The second goal i= s to =93outsource=94 the authorization part to a separate network element t= o allow the *administrator* to grant access to the basic services provided = by the SIP Proxy and the various advanced services provided by the SIP Application Servers.

 

I also explained that my motivation for this w= ork is to address few *Enterprise* use cases, which mainly include the Sing= le-Sign On use case where the user is authenticated once and as a result th= e user gets access to a variety of SIP and non-SIP services, and a centralized authorization use case where t= he administrator is able to authorize access to these services from one net= work element.=

<= /u> 

 

Jon suggested that there are several use cases= that we should be looking at, and he articulated these use cases as follow= s:

 

But more to my po= int (and I suspect Adam's) there are several distinct use cases for SIP tha= t involve adding a secure attestation about the user to SIP requests that w= ill be consumed and trusted by some entity downstream. This problem is probably generic to whether the meat of= that assertion is fetched from a network service or generated locally at a= SIP entity - for SIP Identity-like architectures, one might say the IdP-is= h component of the architecture (the "authentication service") is typically colocated with a pro= xy server, for example. In some cases, the relying parties downstream are i= n the same trust domain as the attester/user, and in some cases they could = be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality = of the user's identity. This encompasses interworking with external protoco= ls like Jingle and WebRTC, this encompasses preventing impersonation, this = potentially involves enterprise use cases like Cullen was talking about. 

 

 

Adam elaborated on Jon=92s statement that talk= s about =93different trust domains=94 as follows:

 

I believe he's re= ferring to the kind of use cases addressed by RFC 4474 and by the work curr= ently going on in STIR -- ones in which some entity asserts the identity of= a party in the call for use by an entity in a completely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (independe= nt of identity). The introduction section of RFC 4484 is a really good plac= e to start if you're not familiar with the concept.

 

 

<= /u> 

At this point Adam, as SIPCORE chair, suggeste= d that we continue this discussion on the SIPCORE mailing list. So here we = are=85=

 

Regards,

 Rifaat



_______________________________________________
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


--_000_7594FB04B1934943A5C02806D1A2204B37F77E26ESESSMB209erics_-- From nobody Wed Apr 27 05:11: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 9F2EC12D7E7 for ; Wed, 27 Apr 2016 05:11:41 -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 5K2yh6oiu92j for ; Wed, 27 Apr 2016 05:11:39 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002: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 8F0A012D7EF for ; Wed, 27 Apr 2016 05:11:38 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id g133so66049014ywb.2 for ; Wed, 27 Apr 2016 05:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=rkjpMD1y612Yc6J5tlAb4+D4Yz3UBLU7/4RqnpDYQQE=; b=ASutvMfBDRnEpeZqWzfme8z288eLjFaVwHEg8PZs3WlzqXrja5oT3ADCBwPkRRLLV3 EVes77RE9MSS7WBLWcd7E9org9zWVTfaCSKw1MUI81JqRKJUwMapY/bqDGHp0I/jhpjU XTXHW+GWhJJjqQDL3ynBVwT7PROPm31TuSvaJ6ofE0hNOXA73QGwQdjelakTNJ+RwrKA WkBorxxXt6K1COglwqnKCa63/XX487TDokrZa84tN5W5BUuD0KVgLWkzP7JzmeO4qDbW bNoEmLU9RWlDF/zxNL3SCO9ALgSpdU5P/HYXQx0uvEHbpQ9e0Pz+PhZ9ceVWbElJzKFA Y3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=rkjpMD1y612Yc6J5tlAb4+D4Yz3UBLU7/4RqnpDYQQE=; b=U6TrUvprKF7wOCVnuLy1+Mftr3a4imug06lHiL8rDjENyusTO694yu+Bs3BRjJKFKF 8IYyomOSO9sk/1DaymsWvwqrn5J/f8R/+3cPywBtOY1/92kjthjaLDnVONCHV/TPmQnJ +Qsbroy7+QndCV90dDmvCGb+nzFc7bfAVMnQa2PkeUCcnh64CsqNMVEDfA/t6BYTrzyl 2bhwNb+bMAlv2F2KrlsTOvtDeoj5Eyej/sv/3UdlYMUQZhOo2gMa2U3c6vu63oLJzzsa F0Wt/afHRwV7NlKGOO8YRfWdOhIC0TW4ugjZmfPQL8sozeAX4CSFM+D7wNkK5wnpUo11 SoZA== X-Gm-Message-State: AOPr4FULcUlwtKvmSsmJYEp2+UeS9zRy/v8B0PIDHE43811xGfLgGFbcgph6UGhhF1oj0cye+6bl4hRyIZhdVw== MIME-Version: 1.0 X-Received: by 10.159.38.40 with SMTP id 37mr4141930uag.8.1461759097743; Wed, 27 Apr 2016 05:11:37 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 27 Apr 2016 05:11:37 -0700 (PDT) Date: Wed, 27 Apr 2016 08:11:37 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a113e255ac4b5bf0531764ff3 Archived-At: Subject: [sipcore] SIP AuthNZ Problem Statement v2 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, 27 Apr 2016 12:11:41 -0000 --001a113e255ac4b5bf0531764ff3 Content-Type: text/plain; charset=UTF-8 All, The following is a new problem statement text that I think captures all the comments received so far. Please, take a look and let me know if you have any further comments. Regards, Rifaat --- Overview -------- The following is a simplified classic SIP deployment model: +--------+ | SIP | ,---------------------------| Registrar | | | +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned a dedicated SIP proxy/registrar and all SIP communications must go through that SIP proxy. The SIP Proxy/Registrar plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy. We would like to discuss the idea of "outsourcing" the user authentication and services authorization to separate network element(s): Authentication (AuthN) ---------------------- There are two types of authentications in a SIP network: user-to-server authentication and user-to-user authentication. These authentications could be in the context of one trust domain, or it could cross boundaries between different trust domains. We would like to explore the idea of "outsourcing" the user authentication part to a separate IdP entity, to allow the SIP user to use his non-SIP credentials, e.g. corporate credentials, with the IdP to register with the SIP registrar, get basic services from the SIP Proxy, and get access to the advanced services provided by the SIP Application Servers. We would also like to explore the idea of using the same "outsourcing" mechanism to address the user authentication when it crosses trust domain boundaries. Authorization (AuthZ) --------------------- We would like to explore the idea of "outsourcing" the authorization part to a separate network element to allow the administrator to grant access to the basic services provided by the SIP Proxy, and the various advanced services provided by the SIP Application Servers. In general, there are two authorization mechanisms that could be used in this case: 1. Self-contained token, which includes all the authorizations needed for the server providing the service to be able to make a decision to grant or deny the service request, and might include control over the level of service provided to the user. 2. Opaque token, which requires an introspection step, where the server providing the service would reach to the authorization server to get the details of the authorizations provided for that specific token. There are pros and cons to each approach that we need to discuss and make a decision on supporting one of these, or maybe both. Trust Relationships ------------------- An important aspect of this exercise is to properly define the trust relationship between the various network elements that would enable the new desired functionalities. Types of Clients ---------------- The solution must take into consideration the various types of SIP clients that might be involved and active in the system, e.g. softclient, hardphones, etc. The solution must also take into consideration the limitation on some of these clients that might impact the way assertions are obtained and handled. For example, the following client limitation would require an interim step to obtain an assertion: 1. UI Limitation: a hardphone with limited UI capability that only allows the user to interact with the phone through the phone's keypad. 2. Security Limitation: a client that is incapable of maintaining the security of the user's credentials or the assertion. In these use cases, we would need a way to get the assertion to the servers that will provide the service without requiring the client to get access to the assertion. --001a113e255ac4b5bf0531764ff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

The following is a new problem statement text that I think cap= tures all the comments received so far.
Please, take a look and let me know if you have any furth= er comments.

Regards,
= =C2=A0Rifaat


---

Overview
=
--------

The following is a simplified classi= c SIP deployment model:


=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =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 ,---------------= ------------| Registrar
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+
=
| =C2=A0 =C2=A0 =C2=A0 =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| SIP App|
| =C2=A0 UA =C2=A0 |----------------------| Proxy =C2=A0|----------= ------------| Server |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--------+


With th= is model, the endpoint is assigned a dedicated SIP proxy/registrar
and all SIP communications must go through that SIP proxy.

=
The SIP Proxy/Registrar plays 3 different roles:
1. Au= thentication Server (SIP Registrar)
2. Authorization Server
=
3. Service provider, e.g. basic calls, call forwarding, call transfer,= etc.

SIP Application Servers provide advanced SIP= services, e.g. conference,
presence, etc. Application Servers us= ually have their own authentication
and authorization mechanism t= hat is separate from the one provided by the
SIP proxy.

We would like to discuss the idea of "outsourcing"= ; the user authentication
and services authorization to separate = network element(s):


Authentication = (AuthN)
----------------------

There are= two types of authentications in a SIP network: user-to-server
au= thentication and user-to-user authentication. These authentications could
be in the context of one trust domain, or it could cross boundarie= s between
different trust domains.

We wo= uld like to explore the idea of "outsourcing" the user authentica= tion
part to a separate IdP entity, to allow the SIP user to use = his non-SIP
credentials, e.g. corporate credentials, with the IdP= to register with the
SIP registrar, get basic services from the = SIP Proxy, and get access to the
advanced services provided by th= e SIP Application Servers.

We would also like to e= xplore the idea of using the same "outsourcing"
mechani= sm to address the user authentication when it crosses trust domain
boundaries.


Authorization (AuthZ)=
---------------------

We would like to = explore the idea of "outsourcing" the authorization part
to a separate network element to allow the administrator to grant access = to
the basic services provided by the SIP Proxy, and the various = advanced
services provided by the SIP Application Servers.
<= div>
In general, there are two authorization mechanisms that = could be used in
this case:

1. Self-cont= ained token, which includes all the authorizations needed for
=C2= =A0 =C2=A0the server providing the service to be able to make a decision to= grant
=C2=A0 =C2=A0or deny the service request, and might includ= e control over the level of
=C2=A0 =C2=A0service provided to the = user.

2. Opaque token, which requires an introspec= tion step, where the server
=C2=A0 =C2=A0providing the service wo= uld reach to the authorization server to get the
=C2=A0 =C2=A0det= ails of the authorizations provided for that specific token.

=
There are pros and cons to each approach that we need to discuss= and make a
decision on supporting one of these, or maybe both.


Trust Relationships
------= -------------

An important aspect of this exercise= is to properly define the trust
relationship between the various= network elements that would enable the new
desired functionaliti= es.


Types of Clients
----= ------------

The solution must take into considera= tion the various types of SIP clients
that might be involved and = active in the system, e.g. softclient,
hardphones, etc.

The solution must also take into consideration the limitati= on on some of
these clients that might impact the way assertions = are obtained and
handled. For example, the following client limit= ation would require an
interim step to obtain an assertion:
=

1. UI Limitation: a hardphone with limited UI capabilit= y that only allows
=C2=A0 =C2=A0the user to interact with the pho= ne through the phone's keypad.

2. Security Lim= itation: a client that is incapable of maintaining the
=C2=A0 =C2= =A0security of the user's credentials or the assertion.

<= /div>
In these use cases, we would need a way to get the assertion to t= he servers
that will provide the service without requiring the cl= ient to get access to
the assertion.




--001a113e255ac4b5bf0531764ff3-- From nobody Wed Apr 27 07:24: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 8280D12D822 for ; Wed, 27 Apr 2016 07:24:38 -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 5yI6kEDouoR4 for ; Wed, 27 Apr 2016 07:24:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 AFC7612D7F5 for ; Wed, 27 Apr 2016 07:24:36 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by comcast with SMTP id vQOJaESZybFYYvQOJa3U6w; Wed, 27 Apr 2016 14:24:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461767075; bh=Tz4lvxYmvPrG/tD0bk923UNy4gOfpGp6WZcAWRngPLA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=XFXAGGdtR0kArzBvxidsC7tKltRU/HZG7djfLu+B0ZncR1iCUMQ6eifvoXhgkg4qN Og1zdNua24uqeCOoNqy1r4UvTkZv2xMC05E5IsZWPmCYb48jNxHsGLdnbhOKduAJc3 e9H+gKpyIkcSe2TvzNqxhqEikEwIs/Z71waIBbXq9Xiu2Hwn14PlJ1YXK81QMG2lXU s8Wxsu7lYn5cQWUSqfmepPUd9kvzUGMvBa6X7saDvxVmm96VQ7a+DFlGyrAmzFL1S/ nJH52ro2qphrYY1P1KuhZ48bZrNbjkfqrWoDzjNxFUi14cYv28cOwEtV2Xs6f7efRI L8f6AzM1cy3UA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id nSQb1s0053KdFy101SQb9D; Wed, 27 Apr 2016 14:24:35 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> Date: Wed, 27 Apr 2016 10:24:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.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 v2 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, 27 Apr 2016 14:24:38 -0000 Rifaat, This is starting to make more sense to me. But IMO it needs more work. The figure seems inadequate to describe the problem space. One can infer that the intent is to add another box to the picture, for the IdP. Also, should I assume there may be several IdPs and several SIP App Servers? Then there remains a question of what the relationship is of those boxes to the others. Presumably an App Server will need a trust relationship with at least one IdP. How will the user know which IdP to use to obtain authorization for a particular app server? And how will this work when multiple users are involved, and a call between them might involve app servers for each? Thanks, Paul On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: > All, > > The following is a new problem statement text that I think captures all > the comments received so far. > Please, take a look and let me know if you have any further comments. > > Regards, > Rifaat > > > --- > > > Overview > -------- > > The following is a simplified classic SIP deployment model: > > > +--------+ > | SIP | > ,---------------------------| Registrar > | | | > +--------+ +--------+ +--------+ > | | | SIP | | SIP App| > | UA |----------------------| Proxy |----------------------| Server | > | | | | | | > +--------+ +--------+ +--------+ > > > With this model, the endpoint is assigned a dedicated SIP proxy/registrar > and all SIP communications must go through that SIP proxy. > > The SIP Proxy/Registrar plays 3 different roles: > 1. Authentication Server (SIP Registrar) > 2. Authorization Server > 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. > > SIP Application Servers provide advanced SIP services, e.g. conference, > presence, etc. Application Servers usually have their own authentication > and authorization mechanism that is separate from the one provided by the > SIP proxy. > > We would like to discuss the idea of "outsourcing" the user authentication > and services authorization to separate network element(s): > > > Authentication (AuthN) > ---------------------- > > There are two types of authentications in a SIP network: user-to-server > authentication and user-to-user authentication. These authentications could > be in the context of one trust domain, or it could cross boundaries between > different trust domains. > > We would like to explore the idea of "outsourcing" the user authentication > part to a separate IdP entity, to allow the SIP user to use his non-SIP > credentials, e.g. corporate credentials, with the IdP to register with the > SIP registrar, get basic services from the SIP Proxy, and get access to the > advanced services provided by the SIP Application Servers. > > We would also like to explore the idea of using the same "outsourcing" > mechanism to address the user authentication when it crosses trust domain > boundaries. > > > Authorization (AuthZ) > --------------------- > > We would like to explore the idea of "outsourcing" the authorization part > to a separate network element to allow the administrator to grant access to > the basic services provided by the SIP Proxy, and the various advanced > services provided by the SIP Application Servers. > > In general, there are two authorization mechanisms that could be used in > this case: > > 1. Self-contained token, which includes all the authorizations needed for > the server providing the service to be able to make a decision to grant > or deny the service request, and might include control over the level of > service provided to the user. > > 2. Opaque token, which requires an introspection step, where the server > providing the service would reach to the authorization server to get the > details of the authorizations provided for that specific token. > > There are pros and cons to each approach that we need to discuss and make a > decision on supporting one of these, or maybe both. > > > Trust Relationships > ------------------- > > An important aspect of this exercise is to properly define the trust > relationship between the various network elements that would enable the new > desired functionalities. > > > Types of Clients > ---------------- > > The solution must take into consideration the various types of SIP clients > that might be involved and active in the system, e.g. softclient, > hardphones, etc. > > The solution must also take into consideration the limitation on some of > these clients that might impact the way assertions are obtained and > handled. For example, the following client limitation would require an > interim step to obtain an assertion: > > 1. UI Limitation: a hardphone with limited UI capability that only allows > the user to interact with the phone through the phone's keypad. > > 2. Security Limitation: a client that is incapable of maintaining the > security of the user's credentials or the assertion. > > In these use cases, we would need a way to get the assertion to the servers > that will provide the service without requiring the client to get access to > the assertion. > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Apr 27 07:35: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 D2A1F12D830 for ; Wed, 27 Apr 2016 07:35:31 -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 OEy0nJweps7O for ; Wed, 27 Apr 2016 07:35:30 -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 6A2C812D130 for ; Wed, 27 Apr 2016 07:35:30 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3REXWec014170; Wed, 27 Apr 2016 10:35:28 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22g55sayc4-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Apr 2016 10:35:28 -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, 27 Apr 2016 10:35:26 -0400 From: "Peterson, Jon" To: Paul Kyzivat Thread-Topic: [sipcore] SIP AuthNZ Problem Statement v2 Thread-Index: AQHRoJCMHxDsO7+cAkqd+IZ9GpeN+J+d4vLD Date: Wed, 27 Apr 2016 14:35:26 +0000 Message-ID: <2DA6E291-C88C-4D50-ADD8-10880868C987@neustar.biz> References: , <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> In-Reply-To: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-27_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-1603290000 definitions=main-1604270228 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 27 Apr 2016 14:35:31 -0000 Honestly I would rather take the term IdP out of this problem statement ent= irely, unless it is defined in some very neutral way - the issue is that we= all project our understandings of this term from various industry identity= architectures onto this problem. We should instead show a box for it, and = show what data we imagine goes in and out of it in the use cases that we ca= re about. Jon Peterson Neustar, Inc. Sent from my iPad > On Apr 27, 2016, at 10:24 AM, Paul Kyzivat wrote: >=20 > Rifaat, >=20 > This is starting to make more sense to me. But IMO it needs more work. >=20 > The figure seems inadequate to describe the problem space. One can infer = that the intent is to add another box to the picture, for the IdP. Also, sh= ould I assume there may be several IdPs and several SIP App Servers? >=20 > Then there remains a question of what the relationship is of those boxes = to the others. Presumably an App Server will need a trust relationship with= at least one IdP. How will the user know which IdP to use to obtain author= ization for a particular app server? >=20 > And how will this work when multiple users are involved, and a call betwe= en them might involve app servers for each? >=20 > Thanks, > Paul >=20 >> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >> All, >>=20 >> The following is a new problem statement text that I think captures all >> the comments received so far. >> Please, take a look and let me know if you have any further comments. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> --- >>=20 >>=20 >> Overview >> -------- >>=20 >> The following is a simplified classic SIP deployment model: >>=20 >>=20 >> +--------+ >> | SIP | >> ,---------------------------| Registrar >> | | | >> +--------+ +--------+ +-------= -+ >> | | | SIP | | SIP Ap= p| >> | UA |----------------------| Proxy |----------------------| Server= | >> | | | | | = | >> +--------+ +--------+ +-------= -+ >>=20 >>=20 >> With this model, the endpoint is assigned a dedicated SIP proxy/registra= r >> and all SIP communications must go through that SIP proxy. >>=20 >> The SIP Proxy/Registrar plays 3 different roles: >> 1. Authentication Server (SIP Registrar) >> 2. Authorization Server >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, e= tc. >>=20 >> SIP Application Servers provide advanced SIP services, e.g. conference, >> presence, etc. Application Servers usually have their own authentication >> and authorization mechanism that is separate from the one provided by th= e >> SIP proxy. >>=20 >> We would like to discuss the idea of "outsourcing" the user authenticati= on >> and services authorization to separate network element(s): >>=20 >>=20 >> Authentication (AuthN) >> ---------------------- >>=20 >> There are two types of authentications in a SIP network: user-to-server >> authentication and user-to-user authentication. These authentications co= uld >> be in the context of one trust domain, or it could cross boundaries betw= een >> different trust domains. >>=20 >> We would like to explore the idea of "outsourcing" the user authenticati= on >> part to a separate IdP entity, to allow the SIP user to use his non-SIP >> credentials, e.g. corporate credentials, with the IdP to register with t= he >> SIP registrar, get basic services from the SIP Proxy, and get access to = the >> advanced services provided by the SIP Application Servers. >>=20 >> We would also like to explore the idea of using the same "outsourcing" >> mechanism to address the user authentication when it crosses trust domai= n >> boundaries. >>=20 >>=20 >> Authorization (AuthZ) >> --------------------- >>=20 >> We would like to explore the idea of "outsourcing" the authorization par= t >> to a separate network element to allow the administrator to grant access= to >> the basic services provided by the SIP Proxy, and the various advanced >> services provided by the SIP Application Servers. >>=20 >> In general, there are two authorization mechanisms that could be used in >> this case: >>=20 >> 1. Self-contained token, which includes all the authorizations needed fo= r >> the server providing the service to be able to make a decision to gran= t >> or deny the service request, and might include control over the level = of >> service provided to the user. >>=20 >> 2. Opaque token, which requires an introspection step, where the server >> providing the service would reach to the authorization server to get t= he >> details of the authorizations provided for that specific token. >>=20 >> There are pros and cons to each approach that we need to discuss and mak= e a >> decision on supporting one of these, or maybe both. >>=20 >>=20 >> Trust Relationships >> ------------------- >>=20 >> An important aspect of this exercise is to properly define the trust >> relationship between the various network elements that would enable the = new >> desired functionalities. >>=20 >>=20 >> Types of Clients >> ---------------- >>=20 >> The solution must take into consideration the various types of SIP clien= ts >> that might be involved and active in the system, e.g. softclient, >> hardphones, etc. >>=20 >> The solution must also take into consideration the limitation on some of >> these clients that might impact the way assertions are obtained and >> handled. For example, the following client limitation would require an >> interim step to obtain an assertion: >>=20 >> 1. UI Limitation: a hardphone with limited UI capability that only allow= s >> the user to interact with the phone through the phone's keypad. >>=20 >> 2. Security Limitation: a client that is incapable of maintaining the >> security of the user's credentials or the assertion. >>=20 >> In these use cases, we would need a way to get the assertion to the serv= ers >> that will provide the service without requiring the client to get access= to >> the assertion. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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 Wed Apr 27 16: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 ACC0512D520 for ; Wed, 27 Apr 2016 16:28:06 -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 H9w2DMdKbgUh for ; Wed, 27 Apr 2016 16:28:04 -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 26E0C12D0F1 for ; Wed, 27 Apr 2016 16:28:04 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id m188so12477081vka.1 for ; Wed, 27 Apr 2016 16:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZnE8RNMYNrLhen7FjdM39LQI8fuF1Z61Ut1TnSdxubU=; b=VjBrF/ZT4MDzz5st25Abz7ACTCx4+Znt3w4JvCr5NGBztPVkf8LAWYlue0/yI772GW lfrG2JPTSd5H7XlmeRqpkouSW2Vr+00Y+JOpqRrWTN9u27A0a12GoFvsG5hOi5UksR80 jhBE1hKmLnl4cW9n2ALwMhmXwC3aLGzgJH/hKLoDjftzsbfx5ROGoq0wmAmMXVv6pmZJ qo4TRkZ24v/+kesg70PugMbqQdxhYT0qpODuEf5ZA5pEJZ5BEneoF17LCAxPm2Rhjxke 1qVZ1LmSfs1roGMUm0dlc9LbUKiN8erVVJbGj6H+AYWT+jHT7l6ffzUSKy5bFXYNBuzG Fr2g== 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:date :message-id:subject:from:to:cc; bh=ZnE8RNMYNrLhen7FjdM39LQI8fuF1Z61Ut1TnSdxubU=; b=hKhN9EpZkmlY0wTSrA7cUqhDkJMe/rn7GtxEqt3QvT/uq29qcCfXkEReUYMhIQciU1 GUitU3phtp+IK5DvP9qTHf113W/gAdMhi/XG6UH2UXgqG6g8kTCFnpOEV1M4Va7iBfPL etM7OdprQlmnnG86EP4XCdFYkM6vBVR3cxD16Uw1H05QR0xZpuP0A+HJyVV0a18UoVOK Buv8PVfNEAtOZ7pk5Qh07BywKse+KZY40vs4uk55ltEOn/yNiNg372cKzE3fK55mK1Mx chE+a3Os6hsMHjhdkwW3nMxPuKN8q4ApnNmMZX7miC32pQ9vOIbXahfHwiX+2QJ9C3nh bElw== X-Gm-Message-State: AOPr4FWa7KhduE1xwjH8t0NwNWP8CBx0mw95iZjg+0CshcPGgs4FdIepz7mSpOjdb4Decvwn+zLdIiwPspZLKw== MIME-Version: 1.0 X-Received: by 10.159.34.71 with SMTP id 65mr5783173uad.103.1461799683165; Wed, 27 Apr 2016 16:28:03 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 27 Apr 2016 16:28:03 -0700 (PDT) In-Reply-To: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> Date: Wed, 27 Apr 2016 19:28:03 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1137c968d912ca05317fc285 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 27 Apr 2016 23:28:06 -0000 --001a1137c968d912ca05317fc285 Content-Type: text/plain; charset=UTF-8 Paul, The provided figure was meant to capture the current state as a background information. But I agree that a figure that captures the new elements would be useful; I will add a new figure with the new network elements. Regarding the relationship between the network elements, I provided some text that states that we need to define that relationship. It seems to me that defining the relationships at this stage is a bit premature. Should not this be done when we start working on defining solutions to these problems? Regards, Rifaat On Wed, Apr 27, 2016 at 10:24 AM, Paul Kyzivat wrote: > Rifaat, > > This is starting to make more sense to me. But IMO it needs more work. > > The figure seems inadequate to describe the problem space. One can infer > that the intent is to add another box to the picture, for the IdP. Also, > should I assume there may be several IdPs and several SIP App Servers? > > Then there remains a question of what the relationship is of those boxes > to the others. Presumably an App Server will need a trust relationship with > at least one IdP. How will the user know which IdP to use to obtain > authorization for a particular app server? > > And how will this work when multiple users are involved, and a call > between them might involve app servers for each? > > Thanks, > Paul > > > On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: > >> All, >> >> The following is a new problem statement text that I think captures all >> the comments received so far. >> Please, take a look and let me know if you have any further comments. >> >> Regards, >> Rifaat >> >> >> --- >> >> >> Overview >> -------- >> >> The following is a simplified classic SIP deployment model: >> >> >> +--------+ >> | SIP | >> ,---------------------------| Registrar >> | | | >> +--------+ +--------+ +--------+ >> | | | SIP | | SIP App| >> | UA |----------------------| Proxy |----------------------| Server | >> | | | | | | >> +--------+ +--------+ +--------+ >> >> >> With this model, the endpoint is assigned a dedicated SIP proxy/registrar >> and all SIP communications must go through that SIP proxy. >> >> The SIP Proxy/Registrar plays 3 different roles: >> 1. Authentication Server (SIP Registrar) >> 2. Authorization Server >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >> etc. >> >> SIP Application Servers provide advanced SIP services, e.g. conference, >> presence, etc. Application Servers usually have their own authentication >> and authorization mechanism that is separate from the one provided by the >> SIP proxy. >> >> We would like to discuss the idea of "outsourcing" the user authentication >> and services authorization to separate network element(s): >> >> >> Authentication (AuthN) >> ---------------------- >> >> There are two types of authentications in a SIP network: user-to-server >> authentication and user-to-user authentication. These authentications >> could >> be in the context of one trust domain, or it could cross boundaries >> between >> different trust domains. >> >> We would like to explore the idea of "outsourcing" the user authentication >> part to a separate IdP entity, to allow the SIP user to use his non-SIP >> credentials, e.g. corporate credentials, with the IdP to register with the >> SIP registrar, get basic services from the SIP Proxy, and get access to >> the >> advanced services provided by the SIP Application Servers. >> >> We would also like to explore the idea of using the same "outsourcing" >> mechanism to address the user authentication when it crosses trust domain >> boundaries. >> >> >> Authorization (AuthZ) >> --------------------- >> >> We would like to explore the idea of "outsourcing" the authorization part >> to a separate network element to allow the administrator to grant access >> to >> the basic services provided by the SIP Proxy, and the various advanced >> services provided by the SIP Application Servers. >> >> In general, there are two authorization mechanisms that could be used in >> this case: >> >> 1. Self-contained token, which includes all the authorizations needed for >> the server providing the service to be able to make a decision to grant >> or deny the service request, and might include control over the level >> of >> service provided to the user. >> >> 2. Opaque token, which requires an introspection step, where the server >> providing the service would reach to the authorization server to get >> the >> details of the authorizations provided for that specific token. >> >> There are pros and cons to each approach that we need to discuss and make >> a >> decision on supporting one of these, or maybe both. >> >> >> Trust Relationships >> ------------------- >> >> An important aspect of this exercise is to properly define the trust >> relationship between the various network elements that would enable the >> new >> desired functionalities. >> >> >> Types of Clients >> ---------------- >> >> The solution must take into consideration the various types of SIP clients >> that might be involved and active in the system, e.g. softclient, >> hardphones, etc. >> >> The solution must also take into consideration the limitation on some of >> these clients that might impact the way assertions are obtained and >> handled. For example, the following client limitation would require an >> interim step to obtain an assertion: >> >> 1. UI Limitation: a hardphone with limited UI capability that only allows >> the user to interact with the phone through the phone's keypad. >> >> 2. Security Limitation: a client that is incapable of maintaining the >> security of the user's credentials or the assertion. >> >> In these use cases, we would need a way to get the assertion to the >> servers >> that will provide the service without requiring the client to get access >> to >> the assertion. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > --001a1137c968d912ca05317fc285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

The provided figure was meant to = capture the current state as a background information.
But I agre= e that a figure that captures the new elements would be useful; I will add = a new figure with the new network elements.

Regard= ing the relationship between the network elements, I provided some text tha= t states that we need to define that relationship.
It seems to me= that defining the relationships at this stage is a bit premature. Should n= ot this be done when we start working on defining solutions to these proble= ms?

Regards,
=C2=A0Rifaat

=



On Wed, Apr 27, 2016 at 10:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Rifaat,

This is starting to make more sense to me. But IMO it needs more work.

The figure seems inadequate to describe the problem space. One can infer th= at the intent is to add another box to the picture, for the IdP. Also, shou= ld I assume there may be several IdPs and several SIP App Servers?

Then there remains a question of what the relationship is of those boxes to= the others. Presumably an App Server will need a trust relationship with a= t least one IdP. How will the user know which IdP to use to obtain authoriz= ation for a particular app server?

And how will this work when multiple users are involved, and a call between= them might involve app servers for each?

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


On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote:
All,

The following is a new problem statement text that I think captures all
the comments received so far.
Please, take a look and let me know if you have any further comments.

Regards,
=C2=A0Rifaat


---


Overview
--------

The following is a simplified classic SIP deployment model:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 ,---------------------------| Registrar
=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
|=C2=A0 =C2=A0 =C2=A0 =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 | SIP App|
|=C2=A0 =C2=A0UA=C2=A0 =C2=A0|----------------------| Proxy=C2=A0 |--------= --------------| Server |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
+--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+


With this model, the endpoint is assigned a dedicated SIP proxy/registrar and all SIP communications must go through that SIP proxy.

The SIP Proxy/Registrar plays 3 different roles:
1. Authentication Server (SIP Registrar)
2. Authorization Server
3. Service provider, e.g. basic calls, call forwarding, call transfer, etc.=

SIP Application Servers provide advanced SIP services, e.g. conference,
presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy.

We would like to discuss the idea of "outsourcing" the user authe= ntication
and services authorization to separate network element(s):


Authentication (AuthN)
----------------------

There are two types of authentications in a SIP network: user-to-server
authentication and user-to-user authentication. These authentications could=
be in the context of one trust domain, or it could cross boundaries between=
different trust domains.

We would like to explore the idea of "outsourcing" the user authe= ntication
part to a separate IdP entity, to allow the SIP user to use his non-SIP
credentials, e.g. corporate credentials, with the IdP to register with the<= br> SIP registrar, get basic services from the SIP Proxy, and get access to the=
advanced services provided by the SIP Application Servers.

We would also like to explore the idea of using the same "outsourcing&= quot;
mechanism to address the user authentication when it crosses trust domain boundaries.


Authorization (AuthZ)
---------------------

We would like to explore the idea of "outsourcing" the authorizat= ion part
to a separate network element to allow the administrator to grant access to=
the basic services provided by the SIP Proxy, and the various advanced
services provided by the SIP Application Servers.

In general, there are two authorization mechanisms that could be used in this case:

1. Self-contained token, which includes all the authorizations needed for =C2=A0 =C2=A0the server providing the service to be able to make a decision= to grant
=C2=A0 =C2=A0or deny the service request, and might include control over th= e level of
=C2=A0 =C2=A0service provided to the user.

2. Opaque token, which requires an introspection step, where the server
=C2=A0 =C2=A0providing the service would reach to the authorization server = to get the
=C2=A0 =C2=A0details of the authorizations provided for that specific token= .

There are pros and cons to each approach that we need to discuss and make a=
decision on supporting one of these, or maybe both.


Trust Relationships
-------------------

An important aspect of this exercise is to properly define the trust
relationship between the various network elements that would enable the new=
desired functionalities.


Types of Clients
----------------

The solution must take into consideration the various types of SIP clients<= br> that might be involved and active in the system, e.g. softclient,
hardphones, etc.

The solution must also take into consideration the limitation on some of these clients that might impact the way assertions are obtained and
handled. For example, the following client limitation would require an
interim step to obtain an assertion:

1. UI Limitation: a hardphone with limited UI capability that only allows =C2=A0 =C2=A0the user to interact with the phone through the phone's ke= ypad.

2. Security Limitation: a client that is incapable of maintaining the
=C2=A0 =C2=A0security of the user's credentials or the assertion.

In these use cases, we would need a way to get the assertion to the servers=
that will provide the service without requiring the client to get access to=
the assertion.







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


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

--001a1137c968d912ca05317fc285-- From nobody Wed Apr 27 16:29: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 64E1912D0F1 for ; Wed, 27 Apr 2016 16:29:48 -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 R1KrDa2xPxgZ for ; Wed, 27 Apr 2016 16:29:45 -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 8C5AC12D51F for ; Wed, 27 Apr 2016 16:29:45 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id u23so12491946vkb.2 for ; Wed, 27 Apr 2016 16:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LzFLOXZiBlntc9KVNrrvLT4WwPn+7WRX1t2tXExOI/Q=; b=zwG7/pg5k0r3y6bPP8egLqY5UvSuq/K2SsIhq9pz7V0DAgJ0u88cz7ONNxpkl0Flzr BYR1A3w8zTzNrVW39nyShqNf5A2Wa6gqE98Zs4Adgx4jSLJXv6sNIVVVwSGecAxGSJNX SEBqTiqVU3DzyM0vh01GrcuqBb0X4svwA7l3piTad9zM8g+l9nsimuhqF2f9/CRHGBR2 IMXUvbKaIVDU2wlcM4Q09GZrWxUqoyZ20nuWXdT02dtWeDsfv4u6taSEcNd35w5SLRxb qhv4P36mtSohQLFbGBoPppIIsKe+YTq/M7UGx2PH9Q/xf9Lq6vM6NKBVUQNBHpBP+orS cknQ== 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:date :message-id:subject:from:to:cc; bh=LzFLOXZiBlntc9KVNrrvLT4WwPn+7WRX1t2tXExOI/Q=; b=P05fBmxN/cpuZIYVw58nj1EKuq5k8XcJ19Z4I4QCxavpn6SOz4K4E4Ef6TSPQITT3k 4iHjmWOWOPlxWdNVujovLwriN27pmZL/c874AoLUhA3JhNFbQozAxKs7xy1YFmLAx2Gx dnOsyLbB/2Q4Mn7WCdWgPOofjQTVMXHDusB99thUBnQ71O/aGBRFAphQgdgm64XjOII5 W5kNlQq7Si9u6BykxTG3MNCYI3BH9Mg4uJM3yLQitDNxD9I+zLXQJgGxCG6BFMVHpCjO WU/xt2BLwhVIz3zFqFjH/2kSYR3WGI2KKFjCalRGskGxJzrJzbuKiiBRSp6uBlRTZaSi buZQ== X-Gm-Message-State: AOPr4FXNotxFJfQsbZTUQIobdovDyXudKMEE/M6Ftec+8vb8r+RgkzSpDpl188S3pHi/Rd3T3mAxPbK7HcrFdQ== MIME-Version: 1.0 X-Received: by 10.159.53.67 with SMTP id o61mr5905054uao.83.1461799784628; Wed, 27 Apr 2016 16:29:44 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 27 Apr 2016 16:29:44 -0700 (PDT) In-Reply-To: <2DA6E291-C88C-4D50-ADD8-10880868C987@neustar.biz> References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> <2DA6E291-C88C-4D50-ADD8-10880868C987@neustar.biz> Date: Wed, 27 Apr 2016 19:29:44 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c03bb26e54bd605317fc830 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 27 Apr 2016 23:29:48 -0000 --94eb2c03bb26e54bd605317fc830 Content-Type: text/plain; charset=UTF-8 Jon, Do you have a "very neutral" definition to the term IdP? Regards, Rifaat On Wed, Apr 27, 2016 at 10:35 AM, Peterson, Jon wrote: > > Honestly I would rather take the term IdP out of this problem statement > entirely, unless it is defined in some very neutral way - the issue is that > we all project our understandings of this term from various industry > identity architectures onto this problem. We should instead show a box for > it, and show what data we imagine goes in and out of it in the use cases > that we care about. > > Jon Peterson > Neustar, Inc. > > Sent from my iPad > > > On Apr 27, 2016, at 10:24 AM, Paul Kyzivat > wrote: > > > > Rifaat, > > > > This is starting to make more sense to me. But IMO it needs more work. > > > > The figure seems inadequate to describe the problem space. One can infer > that the intent is to add another box to the picture, for the IdP. Also, > should I assume there may be several IdPs and several SIP App Servers? > > > > Then there remains a question of what the relationship is of those boxes > to the others. Presumably an App Server will need a trust relationship with > at least one IdP. How will the user know which IdP to use to obtain > authorization for a particular app server? > > > > And how will this work when multiple users are involved, and a call > between them might involve app servers for each? > > > > Thanks, > > Paul > > > >> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: > >> All, > >> > >> The following is a new problem statement text that I think captures all > >> the comments received so far. > >> Please, take a look and let me know if you have any further comments. > >> > >> Regards, > >> Rifaat > >> > >> > >> --- > >> > >> > >> Overview > >> -------- > >> > >> The following is a simplified classic SIP deployment model: > >> > >> > >> +--------+ > >> | SIP | > >> ,---------------------------| Registrar > >> | | | > >> +--------+ +--------+ > +--------+ > >> | | | SIP | | SIP > App| > >> | UA |----------------------| Proxy |----------------------| > Server | > >> | | | | | > | > >> +--------+ +--------+ > +--------+ > >> > >> > >> With this model, the endpoint is assigned a dedicated SIP > proxy/registrar > >> and all SIP communications must go through that SIP proxy. > >> > >> The SIP Proxy/Registrar plays 3 different roles: > >> 1. Authentication Server (SIP Registrar) > >> 2. Authorization Server > >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, > etc. > >> > >> SIP Application Servers provide advanced SIP services, e.g. conference, > >> presence, etc. Application Servers usually have their own authentication > >> and authorization mechanism that is separate from the one provided by > the > >> SIP proxy. > >> > >> We would like to discuss the idea of "outsourcing" the user > authentication > >> and services authorization to separate network element(s): > >> > >> > >> Authentication (AuthN) > >> ---------------------- > >> > >> There are two types of authentications in a SIP network: user-to-server > >> authentication and user-to-user authentication. These authentications > could > >> be in the context of one trust domain, or it could cross boundaries > between > >> different trust domains. > >> > >> We would like to explore the idea of "outsourcing" the user > authentication > >> part to a separate IdP entity, to allow the SIP user to use his non-SIP > >> credentials, e.g. corporate credentials, with the IdP to register with > the > >> SIP registrar, get basic services from the SIP Proxy, and get access to > the > >> advanced services provided by the SIP Application Servers. > >> > >> We would also like to explore the idea of using the same "outsourcing" > >> mechanism to address the user authentication when it crosses trust > domain > >> boundaries. > >> > >> > >> Authorization (AuthZ) > >> --------------------- > >> > >> We would like to explore the idea of "outsourcing" the authorization > part > >> to a separate network element to allow the administrator to grant > access to > >> the basic services provided by the SIP Proxy, and the various advanced > >> services provided by the SIP Application Servers. > >> > >> In general, there are two authorization mechanisms that could be used in > >> this case: > >> > >> 1. Self-contained token, which includes all the authorizations needed > for > >> the server providing the service to be able to make a decision to > grant > >> or deny the service request, and might include control over the level > of > >> service provided to the user. > >> > >> 2. Opaque token, which requires an introspection step, where the server > >> providing the service would reach to the authorization server to get > the > >> details of the authorizations provided for that specific token. > >> > >> There are pros and cons to each approach that we need to discuss and > make a > >> decision on supporting one of these, or maybe both. > >> > >> > >> Trust Relationships > >> ------------------- > >> > >> An important aspect of this exercise is to properly define the trust > >> relationship between the various network elements that would enable the > new > >> desired functionalities. > >> > >> > >> Types of Clients > >> ---------------- > >> > >> The solution must take into consideration the various types of SIP > clients > >> that might be involved and active in the system, e.g. softclient, > >> hardphones, etc. > >> > >> The solution must also take into consideration the limitation on some of > >> these clients that might impact the way assertions are obtained and > >> handled. For example, the following client limitation would require an > >> interim step to obtain an assertion: > >> > >> 1. UI Limitation: a hardphone with limited UI capability that only > allows > >> the user to interact with the phone through the phone's keypad. > >> > >> 2. Security Limitation: a client that is incapable of maintaining the > >> security of the user's credentials or the assertion. > >> > >> In these use cases, we would need a way to get the assertion to the > servers > >> that will provide the service without requiring the client to get > access to > >> the assertion. > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > --94eb2c03bb26e54bd605317fc830 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jon,

Do you have a "very neutral&q= uot; definition to the term IdP?

Regards,
=C2=A0Rifaat


On Wed, Apr 27, 2016 at 10:35 AM, Peterson, Jon <jon.peterson@neustar.biz> wrote:

Honestly I would rather take the term IdP out of this problem statement ent= irely, unless it is defined in some very neutral way - the issue is that we= all project our understandings of this term from various industry identity= architectures onto this problem. We should instead show a box for it, and = show what data we imagine goes in and out of it in the use cases that we ca= re about.

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Apr 27, 2016, at 10:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> Rifaat,
>
> This is starting to make more sense to me. But IMO it needs more work.=
>
> The figure seems inadequate to describe the problem space. One can inf= er that the intent is to add another box to the picture, for the IdP. Also,= should I assume there may be several IdPs and several SIP App Servers?
>
> Then there remains a question of what the relationship is of those box= es to the others. Presumably an App Server will need a trust relationship w= ith at least one IdP. How will the user know which IdP to use to obtain aut= horization for a particular app server?
>
> And how will this work when multiple users are involved, and a call be= tween them might involve app servers for each?
>
>=C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 Paul
>
>> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote:
>> All,
>>
>> The following is a new problem statement text that I think capture= s all
>> the comments received so far.
>> Please, take a look and let me know if you have any further commen= ts.
>>
>> Regards,
>> Rifaat
>>
>>
>> ---
>>
>>
>> Overview
>> --------
>>
>> The following is a simplified classic SIP deployment model:
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 ,---------------------------| Registrar
>>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
>> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>> |=C2=A0 =C2=A0 =C2=A0 =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 | SIP App|<= br> >> |=C2=A0 =C2=A0UA=C2=A0 =C2=A0|----------------------| Proxy=C2=A0 = |----------------------| Server |
>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>>
>>
>> With this model, the endpoint is assigned a dedicated SIP proxy/re= gistrar
>> and all SIP communications must go through that SIP proxy.
>>
>> The SIP Proxy/Registrar plays 3 different roles:
>> 1. Authentication Server (SIP Registrar)
>> 2. Authorization Server
>> 3. Service provider, e.g. basic calls, call forwarding, call trans= fer, etc.
>>
>> SIP Application Servers provide advanced SIP services, e.g. confer= ence,
>> presence, etc. Application Servers usually have their own authenti= cation
>> and authorization mechanism that is separate from the one provided= by the
>> SIP proxy.
>>
>> We would like to discuss the idea of "outsourcing" the u= ser authentication
>> and services authorization to separate network element(s):
>>
>>
>> Authentication (AuthN)
>> ----------------------
>>
>> There are two types of authentications in a SIP network: user-to-s= erver
>> authentication and user-to-user authentication. These authenticati= ons could
>> be in the context of one trust domain, or it could cross boundarie= s between
>> different trust domains.
>>
>> We would like to explore the idea of "outsourcing" the u= ser authentication
>> part to a separate IdP entity, to allow the SIP user to use his no= n-SIP
>> credentials, e.g. corporate credentials, with the IdP to register = with the
>> SIP registrar, get basic services from the SIP Proxy, and get acce= ss to the
>> advanced services provided by the SIP Application Servers.
>>
>> We would also like to explore the idea of using the same "out= sourcing"
>> mechanism to address the user authentication when it crosses trust= domain
>> boundaries.
>>
>>
>> Authorization (AuthZ)
>> ---------------------
>>
>> We would like to explore the idea of "outsourcing" the a= uthorization part
>> to a separate network element to allow the administrator to grant = access to
>> the basic services provided by the SIP Proxy, and the various adva= nced
>> services provided by the SIP Application Servers.
>>
>> In general, there are two authorization mechanisms that could be u= sed in
>> this case:
>>
>> 1. Self-contained token, which includes all the authorizations nee= ded for
>>=C2=A0 =C2=A0the server providing the service to be able to make a = decision to grant
>>=C2=A0 =C2=A0or deny the service request, and might include control= over the level of
>>=C2=A0 =C2=A0service provided to the user.
>>
>> 2. Opaque token, which requires an introspection step, where the s= erver
>>=C2=A0 =C2=A0providing the service would reach to the authorization= server to get the
>>=C2=A0 =C2=A0details of the authorizations provided for that specif= ic token.
>>
>> There are pros and cons to each approach that we need to discuss a= nd make a
>> decision on supporting one of these, or maybe both.
>>
>>
>> Trust Relationships
>> -------------------
>>
>> An important aspect of this exercise is to properly define the tru= st
>> relationship between the various network elements that would enabl= e the new
>> desired functionalities.
>>
>>
>> Types of Clients
>> ----------------
>>
>> The solution must take into consideration the various types of SIP= clients
>> that might be involved and active in the system, e.g. softclient,<= br> >> hardphones, etc.
>>
>> The solution must also take into consideration the limitation on s= ome of
>> these clients that might impact the way assertions are obtained an= d
>> handled. For example, the following client limitation would requir= e an
>> interim step to obtain an assertion:
>>
>> 1. UI Limitation: a hardphone with limited UI capability that only= allows
>>=C2=A0 =C2=A0the user to interact with the phone through the phone&= #39;s keypad.
>>
>> 2. Security Limitation: a client that is incapable of maintaining = the
>>=C2=A0 =C2=A0security of the user's credentials or the assertio= n.
>>
>> In these use cases, we would need a way to get the assertion to th= e servers
>> that will provide the service without requiring the client to get = access to
>> the assertion.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>
> _______________________________________________
> 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

--94eb2c03bb26e54bd605317fc830-- From nobody Wed Apr 27 17:52: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 D042212B040 for ; Wed, 27 Apr 2016 17:52:30 -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 riKQCJEXqtjG for ; Wed, 27 Apr 2016 17:52:29 -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 C018A12B05A for ; Wed, 27 Apr 2016 17:52:28 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id u23so14137259vkb.2 for ; Wed, 27 Apr 2016 17:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QQmVsdl+01egoRWK/wSa2m3OLX9DLw5GG/zhUbyVM6E=; b=aQmd6nX3pRdtU8bCW8qekYnjThdW7b6FCTe+DZ5rLNrYo3kxphXtv8qSdpXdOC22zs y+rfVKWXYGxiTQ9IzhL6iDwB03xmVM7RcRgRrultX9OAifmZ2wBDazechnMooUL36jrg a6k6024/f4gCiqdk3JaKiTptuT78dvXg1JLs+LUV71EqFK76D5wXe1fJe/WiN6SLtDA7 LkM2SibMfnFzZz3/rDQ8x6iiKSgZMEWcedNSl6AvQi1sn7S7DIejz2Nn6Ockz1dAFByi 25aLUQyxyQbtING4yQakv9taYrn4NLiv5uEqL4Ev38Jk1PyqyV1czyZnOkf6+DXUG2MA X4fg== 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:date :message-id:subject:from:to:cc; bh=QQmVsdl+01egoRWK/wSa2m3OLX9DLw5GG/zhUbyVM6E=; b=dNAhghL6eNwEumrM3tkSWHZ/BA5/RnvuteUAUylkDbYksM5fdzEniMMVJfF0w2C258 7nkxmSRDO3Ll8oYUUUkkmjW/PQMPDNZv7shtGPn8+hrzPMfhW10+OdIoYjusq2aRwToL 3LmPwuXVePk7WH53A1NDVejGmx8mvfZAcJ/emTe939bi363TnD4j9SURW37vnlncEQBD rTS3F6PMj29/DG/RlDEY9zS8+SLHP7WcwqZF7uCjRNWCxkVP7iKeXd1Y91pgn7t2DAME lqKZeI0ePPeW/4dfNKOhmAall0Lyi0tagauH6ZXA/cGDq8q3CGk3mA1UFrFYOLp/ODe2 skOw== X-Gm-Message-State: AOPr4FXLAz/kEeOxRJThS794k0DPwdXiQGujpFajo2V7hXxgcRArWI3F+do6kjeLxMneiK+gMCZyUykqB2Cljw== MIME-Version: 1.0 X-Received: by 10.176.69.235 with SMTP id u98mr5934302uau.131.1461804747899; Wed, 27 Apr 2016 17:52:27 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 27 Apr 2016 17:52:27 -0700 (PDT) In-Reply-To: References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> <2DA6E291-C88C-4D50-ADD8-10880868C987@neustar.biz> Date: Wed, 27 Apr 2016 20:52:27 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c11c4c2baca46053180f01e Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 28 Apr 2016 00:52:31 -0000 --94eb2c11c4c2baca46053180f01e Content-Type: text/plain; charset=UTF-8 Jon, How about the following definition? http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) Regards, Rifaat On Wed, Apr 27, 2016 at 7:29 PM, Rifaat Shekh-Yusef wrote: > Jon, > > Do you have a "very neutral" definition to the term IdP? > > Regards, > Rifaat > > > On Wed, Apr 27, 2016 at 10:35 AM, Peterson, Jon > wrote: > >> >> Honestly I would rather take the term IdP out of this problem statement >> entirely, unless it is defined in some very neutral way - the issue is that >> we all project our understandings of this term from various industry >> identity architectures onto this problem. We should instead show a box for >> it, and show what data we imagine goes in and out of it in the use cases >> that we care about. >> >> Jon Peterson >> Neustar, Inc. >> >> Sent from my iPad >> >> > On Apr 27, 2016, at 10:24 AM, Paul Kyzivat >> wrote: >> > >> > Rifaat, >> > >> > This is starting to make more sense to me. But IMO it needs more work. >> > >> > The figure seems inadequate to describe the problem space. One can >> infer that the intent is to add another box to the picture, for the IdP. >> Also, should I assume there may be several IdPs and several SIP App Servers? >> > >> > Then there remains a question of what the relationship is of those >> boxes to the others. Presumably an App Server will need a trust >> relationship with at least one IdP. How will the user know which IdP to use >> to obtain authorization for a particular app server? >> > >> > And how will this work when multiple users are involved, and a call >> between them might involve app servers for each? >> > >> > Thanks, >> > Paul >> > >> >> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >> >> All, >> >> >> >> The following is a new problem statement text that I think captures all >> >> the comments received so far. >> >> Please, take a look and let me know if you have any further comments. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> --- >> >> >> >> >> >> Overview >> >> -------- >> >> >> >> The following is a simplified classic SIP deployment model: >> >> >> >> >> >> +--------+ >> >> | SIP | >> >> ,---------------------------| Registrar >> >> | | | >> >> +--------+ +--------+ >> +--------+ >> >> | | | SIP | | SIP >> App| >> >> | UA |----------------------| Proxy |----------------------| >> Server | >> >> | | | | | >> | >> >> +--------+ +--------+ >> +--------+ >> >> >> >> >> >> With this model, the endpoint is assigned a dedicated SIP >> proxy/registrar >> >> and all SIP communications must go through that SIP proxy. >> >> >> >> The SIP Proxy/Registrar plays 3 different roles: >> >> 1. Authentication Server (SIP Registrar) >> >> 2. Authorization Server >> >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >> etc. >> >> >> >> SIP Application Servers provide advanced SIP services, e.g. conference, >> >> presence, etc. Application Servers usually have their own >> authentication >> >> and authorization mechanism that is separate from the one provided by >> the >> >> SIP proxy. >> >> >> >> We would like to discuss the idea of "outsourcing" the user >> authentication >> >> and services authorization to separate network element(s): >> >> >> >> >> >> Authentication (AuthN) >> >> ---------------------- >> >> >> >> There are two types of authentications in a SIP network: user-to-server >> >> authentication and user-to-user authentication. These authentications >> could >> >> be in the context of one trust domain, or it could cross boundaries >> between >> >> different trust domains. >> >> >> >> We would like to explore the idea of "outsourcing" the user >> authentication >> >> part to a separate IdP entity, to allow the SIP user to use his non-SIP >> >> credentials, e.g. corporate credentials, with the IdP to register with >> the >> >> SIP registrar, get basic services from the SIP Proxy, and get access >> to the >> >> advanced services provided by the SIP Application Servers. >> >> >> >> We would also like to explore the idea of using the same "outsourcing" >> >> mechanism to address the user authentication when it crosses trust >> domain >> >> boundaries. >> >> >> >> >> >> Authorization (AuthZ) >> >> --------------------- >> >> >> >> We would like to explore the idea of "outsourcing" the authorization >> part >> >> to a separate network element to allow the administrator to grant >> access to >> >> the basic services provided by the SIP Proxy, and the various advanced >> >> services provided by the SIP Application Servers. >> >> >> >> In general, there are two authorization mechanisms that could be used >> in >> >> this case: >> >> >> >> 1. Self-contained token, which includes all the authorizations needed >> for >> >> the server providing the service to be able to make a decision to >> grant >> >> or deny the service request, and might include control over the >> level of >> >> service provided to the user. >> >> >> >> 2. Opaque token, which requires an introspection step, where the server >> >> providing the service would reach to the authorization server to get >> the >> >> details of the authorizations provided for that specific token. >> >> >> >> There are pros and cons to each approach that we need to discuss and >> make a >> >> decision on supporting one of these, or maybe both. >> >> >> >> >> >> Trust Relationships >> >> ------------------- >> >> >> >> An important aspect of this exercise is to properly define the trust >> >> relationship between the various network elements that would enable >> the new >> >> desired functionalities. >> >> >> >> >> >> Types of Clients >> >> ---------------- >> >> >> >> The solution must take into consideration the various types of SIP >> clients >> >> that might be involved and active in the system, e.g. softclient, >> >> hardphones, etc. >> >> >> >> The solution must also take into consideration the limitation on some >> of >> >> these clients that might impact the way assertions are obtained and >> >> handled. For example, the following client limitation would require an >> >> interim step to obtain an assertion: >> >> >> >> 1. UI Limitation: a hardphone with limited UI capability that only >> allows >> >> the user to interact with the phone through the phone's keypad. >> >> >> >> 2. Security Limitation: a client that is incapable of maintaining the >> >> security of the user's credentials or the assertion. >> >> >> >> In these use cases, we would need a way to get the assertion to the >> servers >> >> that will provide the service without requiring the client to get >> access to >> >> the assertion. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > > --94eb2c11c4c2baca46053180f01e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jon,

How about the following definition= ?


Regards,
=C2=A0Rifaat

On Wed, Apr 27, 2016 at 7:29 PM, Rifaat Shekh-Y= usef <rifaat.ietf@gmail.com> wrote:
Jon,

Do you have a "= ;very neutral" definition to the term IdP?

Re= gards,
=C2=A0Rifaat


On Wed, Apr 27, 2016 at 10:35 AM, Peterson, Jon <<= a href=3D"mailto:jon.peterson@neustar.biz" target=3D"_blank">jon.peterson@n= eustar.biz> wrote:

Honestly I would rather take the term IdP out of this problem statement ent= irely, unless it is defined in some very neutral way - the issue is that we= all project our understandings of this term from various industry identity= architectures onto this problem. We should instead show a box for it, and = show what data we imagine goes in and out of it in the use cases that we ca= re about.

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Apr 27, 2016, at 10:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: >
> Rifaat,
>
> This is starting to make more sense to me. But IMO it needs more work.=
>
> The figure seems inadequate to describe the problem space. One can inf= er that the intent is to add another box to the picture, for the IdP. Also,= should I assume there may be several IdPs and several SIP App Servers?
>
> Then there remains a question of what the relationship is of those box= es to the others. Presumably an App Server will need a trust relationship w= ith at least one IdP. How will the user know which IdP to use to obtain aut= horization for a particular app server?
>
> And how will this work when multiple users are involved, and a call be= tween them might involve app servers for each?
>
>=C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 Paul
>
>> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote:
>> All,
>>
>> The following is a new problem statement text that I think capture= s all
>> the comments received so far.
>> Please, take a look and let me know if you have any further commen= ts.
>>
>> Regards,
>> Rifaat
>>
>>
>> ---
>>
>>
>> Overview
>> --------
>>
>> The following is a simplified classic SIP deployment model:
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 ,---------------------------| Registrar
>>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
>> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>> |=C2=A0 =C2=A0 =C2=A0 =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 | SIP App|<= br> >> |=C2=A0 =C2=A0UA=C2=A0 =C2=A0|----------------------| Proxy=C2=A0 = |----------------------| Server |
>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
>>
>>
>> With this model, the endpoint is assigned a dedicated SIP proxy/re= gistrar
>> and all SIP communications must go through that SIP proxy.
>>
>> The SIP Proxy/Registrar plays 3 different roles:
>> 1. Authentication Server (SIP Registrar)
>> 2. Authorization Server
>> 3. Service provider, e.g. basic calls, call forwarding, call trans= fer, etc.
>>
>> SIP Application Servers provide advanced SIP services, e.g. confer= ence,
>> presence, etc. Application Servers usually have their own authenti= cation
>> and authorization mechanism that is separate from the one provided= by the
>> SIP proxy.
>>
>> We would like to discuss the idea of "outsourcing" the u= ser authentication
>> and services authorization to separate network element(s):
>>
>>
>> Authentication (AuthN)
>> ----------------------
>>
>> There are two types of authentications in a SIP network: user-to-s= erver
>> authentication and user-to-user authentication. These authenticati= ons could
>> be in the context of one trust domain, or it could cross boundarie= s between
>> different trust domains.
>>
>> We would like to explore the idea of "outsourcing" the u= ser authentication
>> part to a separate IdP entity, to allow the SIP user to use his no= n-SIP
>> credentials, e.g. corporate credentials, with the IdP to register = with the
>> SIP registrar, get basic services from the SIP Proxy, and get acce= ss to the
>> advanced services provided by the SIP Application Servers.
>>
>> We would also like to explore the idea of using the same "out= sourcing"
>> mechanism to address the user authentication when it crosses trust= domain
>> boundaries.
>>
>>
>> Authorization (AuthZ)
>> ---------------------
>>
>> We would like to explore the idea of "outsourcing" the a= uthorization part
>> to a separate network element to allow the administrator to grant = access to
>> the basic services provided by the SIP Proxy, and the various adva= nced
>> services provided by the SIP Application Servers.
>>
>> In general, there are two authorization mechanisms that could be u= sed in
>> this case:
>>
>> 1. Self-contained token, which includes all the authorizations nee= ded for
>>=C2=A0 =C2=A0the server providing the service to be able to make a = decision to grant
>>=C2=A0 =C2=A0or deny the service request, and might include control= over the level of
>>=C2=A0 =C2=A0service provided to the user.
>>
>> 2. Opaque token, which requires an introspection step, where the s= erver
>>=C2=A0 =C2=A0providing the service would reach to the authorization= server to get the
>>=C2=A0 =C2=A0details of the authorizations provided for that specif= ic token.
>>
>> There are pros and cons to each approach that we need to discuss a= nd make a
>> decision on supporting one of these, or maybe both.
>>
>>
>> Trust Relationships
>> -------------------
>>
>> An important aspect of this exercise is to properly define the tru= st
>> relationship between the various network elements that would enabl= e the new
>> desired functionalities.
>>
>>
>> Types of Clients
>> ----------------
>>
>> The solution must take into consideration the various types of SIP= clients
>> that might be involved and active in the system, e.g. softclient,<= br> >> hardphones, etc.
>>
>> The solution must also take into consideration the limitation on s= ome of
>> these clients that might impact the way assertions are obtained an= d
>> handled. For example, the following client limitation would requir= e an
>> interim step to obtain an assertion:
>>
>> 1. UI Limitation: a hardphone with limited UI capability that only= allows
>>=C2=A0 =C2=A0the user to interact with the phone through the phone&= #39;s keypad.
>>
>> 2. Security Limitation: a client that is incapable of maintaining = the
>>=C2=A0 =C2=A0security of the user's credentials or the assertio= n.
>>
>> In these use cases, we would need a way to get the assertion to th= e servers
>> that will provide the service without requiring the client to get = access to
>> the assertion.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore<= br>
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


--94eb2c11c4c2baca46053180f01e-- From nobody Thu Apr 28 03:46: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 340BD12D652 for ; Thu, 28 Apr 2016 03:46:34 -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_H4=-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 O6irPLDXwnT5 for ; Thu, 28 Apr 2016 03:46:32 -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 39DEE12D0EB for ; Thu, 28 Apr 2016 03:46:31 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-9c-5721ea05ad67 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.D5.18043.50AE1275; Thu, 28 Apr 2016 12:46:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 12:45:27 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP AuthNZ Problem Statement v2 Thread-Index: AQHRoJCLaJvnfJ0ae0yaAsrb+9JJgZ+fRiQA Date: Thu, 28 Apr 2016 10:45:26 +0000 Message-ID: References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> In-Reply-To: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@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: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7nC7rK8Vwg9cHVCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj+7mvTAU/dSqarp9jb2Dcq9TFyMkhIWAi Ma3pLCuELSZx4d56ti5GLg4hgSOMElPWv2KFcJYwSny5d5axi5GDg03AQqL7nzZIg4hAoMTV JROYQWxhATOJVfefMkLEzSWO7L7PBmEbSbxoegtWwyKgKvHq+zEWEJtXwEqi9e8cFoj5bYwS 169NAiviFHCQWLR3HlgzI9BF30+tYQKxmQXEJW49mc8EcamAxJI955khbFGJl4//gX0gKqAn se/FebA7JQSUJKZtTYNo1ZFYsPsTG4RtLbHlUz/USG2JZQtfM0PcIyhxcuYTlgmM4rOQbJuF pH0WkvZZSNpnIWlfwMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw3g5u+W21g/Hgc8dD jAIcjEo8vAvyFMOFWBPLiitzDzFKcDArifAqvwQK8aYkVlalFuXHF5XmpBYfYpTmYFES5/UH SQmkJ5akZqemFqQWwWSZODilGhhrA5XtLddoGebOMzj3S6LmbZ2vdm2g1xbJU+rfxOZ8Lztn 8PtEU7BMiOPMV2/3BeTt4n2T0q28+KXnkWCD03beSmWWMxa0dTz4omB+6/nOXWYvb737ytUl YCif+qztxoYnc74a7KtdGO0QZnt95qlPNo/FzaxTl1s2xD4Ltjf+eU7sS0S+c7wSS3FGoqEW c1FxIgDxJJeLswIAAA== Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 28 Apr 2016 10:46:34 -0000 Hi, >Then there remains a question of what the relationship is of those boxes >to the others. Presumably an App Server will need a trust relationship >with at least one IdP. How will the user know which IdP to use to obtain >authorization for a particular app server? With web apps, you are redirected to the correct IdP (e.g. Facebook). So, unless the UA knows which IdP to use, I guess the SIP App Server could inform it. Regards, Christer >On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >> All, >> >> The following is a new problem statement text that I think captures all >> the comments received so far. >> Please, take a look and let me know if you have any further comments. >> >> Regards, >> Rifaat >> >> >> --- >> >> >> Overview >> -------- >> >> The following is a simplified classic SIP deployment model: >> >> >> +--------+ >> | SIP | >> ,---------------------------| Registrar >> | | | >> +--------+ +--------+ >>+--------+ >> | | | SIP | | SIP >>App| >> | UA |----------------------| Proxy |----------------------| >>Server | >> | | | | | >> | >> +--------+ +--------+ >>+--------+ >> >> >> With this model, the endpoint is assigned a dedicated SIP >>proxy/registrar >> and all SIP communications must go through that SIP proxy. >> >> The SIP Proxy/Registrar plays 3 different roles: >> 1. Authentication Server (SIP Registrar) >> 2. Authorization Server >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >>etc. >> >> SIP Application Servers provide advanced SIP services, e.g. conference, >> presence, etc. Application Servers usually have their own authentication >> and authorization mechanism that is separate from the one provided by >>the >> SIP proxy. >> >> We would like to discuss the idea of "outsourcing" the user >>authentication >> and services authorization to separate network element(s): >> >> >> Authentication (AuthN) >> ---------------------- >> >> There are two types of authentications in a SIP network: user-to-server >> authentication and user-to-user authentication. These authentications >>could >> be in the context of one trust domain, or it could cross boundaries >>between >> different trust domains. >> >> We would like to explore the idea of "outsourcing" the user >>authentication >> part to a separate IdP entity, to allow the SIP user to use his non-SIP >> credentials, e.g. corporate credentials, with the IdP to register with >>the >> SIP registrar, get basic services from the SIP Proxy, and get access to >>the >> advanced services provided by the SIP Application Servers. >> >> We would also like to explore the idea of using the same "outsourcing" >> mechanism to address the user authentication when it crosses trust >>domain >> boundaries. >> >> >> Authorization (AuthZ) >> --------------------- >> >> We would like to explore the idea of "outsourcing" the authorization >>part >> to a separate network element to allow the administrator to grant >>access to >> the basic services provided by the SIP Proxy, and the various advanced >> services provided by the SIP Application Servers. >> >> In general, there are two authorization mechanisms that could be used in >> this case: >> >> 1. Self-contained token, which includes all the authorizations needed >>for >> the server providing the service to be able to make a decision to >>grant >> or deny the service request, and might include control over the >>level of >> service provided to the user. >> >> 2. Opaque token, which requires an introspection step, where the server >> providing the service would reach to the authorization server to get >>the >> details of the authorizations provided for that specific token. >> >> There are pros and cons to each approach that we need to discuss and >>make a >> decision on supporting one of these, or maybe both. >> >> >> Trust Relationships >> ------------------- >> >> An important aspect of this exercise is to properly define the trust >> relationship between the various network elements that would enable the >>new >> desired functionalities. >> >> >> Types of Clients >> ---------------- >> >> The solution must take into consideration the various types of SIP >>clients >> that might be involved and active in the system, e.g. softclient, >> hardphones, etc. >> >> The solution must also take into consideration the limitation on some of >> these clients that might impact the way assertions are obtained and >> handled. For example, the following client limitation would require an >> interim step to obtain an assertion: >> >> 1. UI Limitation: a hardphone with limited UI capability that only >>allows >> the user to interact with the phone through the phone's keypad. >> >> 2. Security Limitation: a client that is incapable of maintaining the >> security of the user's credentials or the assertion. >> >> In these use cases, we would need a way to get the assertion to the >>servers >> that will provide the service without requiring the client to get >>access to >> the assertion. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Apr 28 07:17: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 A9D5312D6DA for ; Thu, 28 Apr 2016 07:17:32 -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 gWldk7wW9bK8 for ; Thu, 28 Apr 2016 07:17:30 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 B356212D7BD for ; Thu, 28 Apr 2016 07:17:30 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by comcast with SMTP id vmkxabMI0mXdbvml0a7Q3z; Thu, 28 Apr 2016 14:17:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461853050; bh=toy2mhQsctMmGjH6Y/OyCJQ3ShR78/Yve7CW4HF4bow=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AS4BpNRIatmSZp8/5xQEFAmh6nLIhFei7iXVtZdvjVzpcvnjXvSkFyM+kLmyW6cQD 1i397CR5u5K51232dw+wTPrhhz9j9rIKVs/MwhfL/aNksEK0L2RnUwlkRIo2/AuP6x earCRUv7/oMrRTSJ8x2lRkGnOrTQdCkNBxSpxj9UXWX7cxQfP/50IIQCQrD22mORDb /XC/Kcyt1VcborsNuYiTMDo32tbt2yIpUCVXepg1zQ1GIGJWStbZvLcvWzpruJ6cAN unmFTFOcaQZJZ5S1RLYqpH5PFTpYZZ9NARk3LORvOBBQ5o+YOVXf/s7hRi74KU0LI5 NLL9Kp+XDRisg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-07v.sys.comcast.net with comcast id nqHV1s00A3KdFy101qHVzr; Thu, 28 Apr 2016 14:17:29 +0000 To: Rifaat Shekh-Yusef References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> From: Paul Kyzivat Message-ID: <32f8beaa-d0ea-8cf2-e0a7-7e67acabe7af@alum.mit.edu> Date: Thu, 28 Apr 2016 10:17:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.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 v2 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, 28 Apr 2016 14:17:32 -0000 On 4/27/16 7:28 PM, Rifaat Shekh-Yusef wrote: > Paul, > > The provided figure was meant to capture the current state as a > background information. > But I agree that a figure that captures the new elements would be > useful; I will add a new figure with the new network elements. > > Regarding the relationship between the network elements, I provided some > text that states that we need to define that relationship. > It seems to me that defining the relationships at this stage is a bit > premature. Should not this be done when we start working on defining > solutions to these problems? Yes, some of this probably falls into the solution domain rather than the problem domain. But I think some of it may fall into the problem domain. I have the sense that there is an assumption that there is a single IdP and that any/all clients and app servers trust it. This *might* be appropriate is some enterprise deployments, but it doesn't scale well beyond that. Thanks, Paul > Regards, > Rifaat > > > > > On Wed, Apr 27, 2016 at 10:24 AM, Paul Kyzivat > wrote: > > Rifaat, > > This is starting to make more sense to me. But IMO it needs more work. > > The figure seems inadequate to describe the problem space. One can > infer that the intent is to add another box to the picture, for the > IdP. Also, should I assume there may be several IdPs and several SIP > App Servers? > > Then there remains a question of what the relationship is of those > boxes to the others. Presumably an App Server will need a trust > relationship with at least one IdP. How will the user know which IdP > to use to obtain authorization for a particular app server? > > And how will this work when multiple users are involved, and a call > between them might involve app servers for each? > > Thanks, > Paul > > > On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: > > All, > > The following is a new problem statement text that I think > captures all > the comments received so far. > Please, take a look and let me know if you have any further > comments. > > Regards, > Rifaat > > > --- > > > Overview > -------- > > The following is a simplified classic SIP deployment model: > > > +--------+ > | SIP | > ,---------------------------| Registrar > | | | > +--------+ +--------+ > +--------+ > | | | SIP | > | SIP App| > | UA |----------------------| Proxy > |----------------------| Server | > | | | | > | | > +--------+ +--------+ > +--------+ > > > With this model, the endpoint is assigned a dedicated SIP > proxy/registrar > and all SIP communications must go through that SIP proxy. > > The SIP Proxy/Registrar plays 3 different roles: > 1. Authentication Server (SIP Registrar) > 2. Authorization Server > 3. Service provider, e.g. basic calls, call forwarding, call > transfer, etc. > > SIP Application Servers provide advanced SIP services, e.g. > conference, > presence, etc. Application Servers usually have their own > authentication > and authorization mechanism that is separate from the one > provided by the > SIP proxy. > > We would like to discuss the idea of "outsourcing" the user > authentication > and services authorization to separate network element(s): > > > Authentication (AuthN) > ---------------------- > > There are two types of authentications in a SIP network: > user-to-server > authentication and user-to-user authentication. These > authentications could > be in the context of one trust domain, or it could cross > boundaries between > different trust domains. > > We would like to explore the idea of "outsourcing" the user > authentication > part to a separate IdP entity, to allow the SIP user to use his > non-SIP > credentials, e.g. corporate credentials, with the IdP to > register with the > SIP registrar, get basic services from the SIP Proxy, and get > access to the > advanced services provided by the SIP Application Servers. > > We would also like to explore the idea of using the same > "outsourcing" > mechanism to address the user authentication when it crosses > trust domain > boundaries. > > > Authorization (AuthZ) > --------------------- > > We would like to explore the idea of "outsourcing" the > authorization part > to a separate network element to allow the administrator to > grant access to > the basic services provided by the SIP Proxy, and the various > advanced > services provided by the SIP Application Servers. > > In general, there are two authorization mechanisms that could be > used in > this case: > > 1. Self-contained token, which includes all the authorizations > needed for > the server providing the service to be able to make a > decision to grant > or deny the service request, and might include control over > the level of > service provided to the user. > > 2. Opaque token, which requires an introspection step, where the > server > providing the service would reach to the authorization server > to get the > details of the authorizations provided for that specific token. > > There are pros and cons to each approach that we need to discuss > and make a > decision on supporting one of these, or maybe both. > > > Trust Relationships > ------------------- > > An important aspect of this exercise is to properly define the trust > relationship between the various network elements that would > enable the new > desired functionalities. > > > Types of Clients > ---------------- > > The solution must take into consideration the various types of > SIP clients > that might be involved and active in the system, e.g. softclient, > hardphones, etc. > > The solution must also take into consideration the limitation on > some of > these clients that might impact the way assertions are obtained and > handled. For example, the following client limitation would > require an > interim step to obtain an assertion: > > 1. UI Limitation: a hardphone with limited UI capability that > only allows > the user to interact with the phone through the phone's keypad. > > 2. Security Limitation: a client that is incapable of > maintaining the > security of the user's credentials or the assertion. > > In these use cases, we would need a way to get the assertion to > the servers > that will provide the service without requiring the client to > get access to > the assertion. > > > > > > > > _______________________________________________ > 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 Apr 28 07:21: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 BB8D012D160 for ; Thu, 28 Apr 2016 07:21:28 -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 EF7-XzZRiyEQ for ; Thu, 28 Apr 2016 07:21:27 -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 69EAB12D7C0 for ; Thu, 28 Apr 2016 07:21:26 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by comcast with SMTP id vmogaUdsUGhQ0vmonaToZO; Thu, 28 Apr 2016 14:21:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461853285; bh=rO0zMlZzps+rI+QpQFw5bUSNLwr++nrh5AxOfJ9EqwI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=t2idIYuMQ+k2mmbUQxfpj12pleBuLoPUmIw+Zx1pbyt9n5xNbMIR/WTm0uAc6zAtj nW3UWNkmA3eWGXOpEMV8lg+wtK1Q0bpmiQIN0hzAAaf6rpTGtiCpPe1KLaiVuqM7So aTPxumPRk8d2h/zwG4Dl39T+UKPfDiv5D6Pb9sV3sQJ6DwyetrA9oXhb0PUcq65SZf +6r3AuftpgoeiekAUdkJ6HcXd4hRINPDTBWUbeS2RvYrQz1iq1EOP2OrHMw/WEop4z +FG6N5VEZCit3N9QNJfyAg7bJiQv1UJUwhTQGIiAXOud7zyr2kyALxoRkuDQL+9aqz 89hZy+Sk9M2cw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-01v.sys.comcast.net with comcast id nqMR1s0063KdFy101qMRzs; Thu, 28 Apr 2016 14:21:25 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> From: Paul Kyzivat Message-ID: <3215af79-906b-7496-5f6e-2a69ddc6eb7f@alum.mit.edu> Date: Thu, 28 Apr 2016 10:21:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.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 v2 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, 28 Apr 2016 14:21:29 -0000 On 4/28/16 6:45 AM, Christer Holmberg wrote: > Hi, > >> Then there remains a question of what the relationship is of those boxes >> to the others. Presumably an App Server will need a trust relationship >> with at least one IdP. How will the user know which IdP to use to obtain >> authorization for a particular app server? > > With web apps, you are redirected to the correct IdP (e.g. Facebook). So, > unless the UA knows which IdP to use, I guess the SIP App Server could > inform it. In the web apps I encounter you are usually given a choice of IdPs that the app server can deal with, and you can choose one that you have a relationship with. That same model could work here if the user is interfacing through an app that has a web interface as well as sip. But it may present a problem in other cases, such as phones with limited UIs. That is why I think it needs to be explored. Thanks, Paul > Regards, > > Christer > > > >> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >>> All, >>> >>> The following is a new problem statement text that I think captures all >>> the comments received so far. >>> Please, take a look and let me know if you have any further comments. >>> >>> Regards, >>> Rifaat >>> >>> >>> --- >>> >>> >>> Overview >>> -------- >>> >>> The following is a simplified classic SIP deployment model: >>> >>> >>> +--------+ >>> | SIP | >>> ,---------------------------| Registrar >>> | | | >>> +--------+ +--------+ >>> +--------+ >>> | | | SIP | | SIP >>> App| >>> | UA |----------------------| Proxy |----------------------| >>> Server | >>> | | | | | >>> | >>> +--------+ +--------+ >>> +--------+ >>> >>> >>> With this model, the endpoint is assigned a dedicated SIP >>> proxy/registrar >>> and all SIP communications must go through that SIP proxy. >>> >>> The SIP Proxy/Registrar plays 3 different roles: >>> 1. Authentication Server (SIP Registrar) >>> 2. Authorization Server >>> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >>> etc. >>> >>> SIP Application Servers provide advanced SIP services, e.g. conference, >>> presence, etc. Application Servers usually have their own authentication >>> and authorization mechanism that is separate from the one provided by >>> the >>> SIP proxy. >>> >>> We would like to discuss the idea of "outsourcing" the user >>> authentication >>> and services authorization to separate network element(s): >>> >>> >>> Authentication (AuthN) >>> ---------------------- >>> >>> There are two types of authentications in a SIP network: user-to-server >>> authentication and user-to-user authentication. These authentications >>> could >>> be in the context of one trust domain, or it could cross boundaries >>> between >>> different trust domains. >>> >>> We would like to explore the idea of "outsourcing" the user >>> authentication >>> part to a separate IdP entity, to allow the SIP user to use his non-SIP >>> credentials, e.g. corporate credentials, with the IdP to register with >>> the >>> SIP registrar, get basic services from the SIP Proxy, and get access to >>> the >>> advanced services provided by the SIP Application Servers. >>> >>> We would also like to explore the idea of using the same "outsourcing" >>> mechanism to address the user authentication when it crosses trust >>> domain >>> boundaries. >>> >>> >>> Authorization (AuthZ) >>> --------------------- >>> >>> We would like to explore the idea of "outsourcing" the authorization >>> part >>> to a separate network element to allow the administrator to grant >>> access to >>> the basic services provided by the SIP Proxy, and the various advanced >>> services provided by the SIP Application Servers. >>> >>> In general, there are two authorization mechanisms that could be used in >>> this case: >>> >>> 1. Self-contained token, which includes all the authorizations needed >>> for >>> the server providing the service to be able to make a decision to >>> grant >>> or deny the service request, and might include control over the >>> level of >>> service provided to the user. >>> >>> 2. Opaque token, which requires an introspection step, where the server >>> providing the service would reach to the authorization server to get >>> the >>> details of the authorizations provided for that specific token. >>> >>> There are pros and cons to each approach that we need to discuss and >>> make a >>> decision on supporting one of these, or maybe both. >>> >>> >>> Trust Relationships >>> ------------------- >>> >>> An important aspect of this exercise is to properly define the trust >>> relationship between the various network elements that would enable the >>> new >>> desired functionalities. >>> >>> >>> Types of Clients >>> ---------------- >>> >>> The solution must take into consideration the various types of SIP >>> clients >>> that might be involved and active in the system, e.g. softclient, >>> hardphones, etc. >>> >>> The solution must also take into consideration the limitation on some of >>> these clients that might impact the way assertions are obtained and >>> handled. For example, the following client limitation would require an >>> interim step to obtain an assertion: >>> >>> 1. UI Limitation: a hardphone with limited UI capability that only >>> allows >>> the user to interact with the phone through the phone's keypad. >>> >>> 2. Security Limitation: a client that is incapable of maintaining the >>> security of the user's credentials or the assertion. >>> >>> In these use cases, we would need a way to get the assertion to the >>> servers >>> that will provide the service without requiring the client to get >>> access to >>> the assertion. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Apr 28 08:45: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 0C78C12D89E for ; Thu, 28 Apr 2016 08:45:21 -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 wNMnUB9XRitF for ; Thu, 28 Apr 2016 08:45:19 -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 01A7312D9AC for ; Thu, 28 Apr 2016 08:41:13 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-fe-57222f187584 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.F8.27088.81F22275; Thu, 28 Apr 2016 17:41:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 17:41:11 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP AuthNZ Problem Statement v2 Thread-Index: AQHRoJCLaJvnfJ0ae0yaAsrb+9JJgZ+fRiQAgAAJr4CAADfTJA== Date: Thu, 28 Apr 2016 15:41:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F89093@ESESSMB209.ericsson.se> References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> , <3215af79-906b-7496-5f6e-2a69ddc6eb7f@alum.mit.edu> In-Reply-To: <3215af79-906b-7496-5f6e-2a69ddc6eb7f@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F89093ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdXldCXyncYOljYYsVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4dXExc8GSBYwVlw6tYW5g3NfG2MXIySEh YCKxZPsWJghbTOLCvfVsXYxcHEICRxgltn68zwLhLGGUeHN0HWsXIwcHm4CFRPc/bZAGEYFA iatLJjCD2MICZhKHJr5ih4ibSxzZfZ8NwnaSuHNgKVicRUBV4uuCRywgNq+Ar8S/d+8YIea/ ZpR42nAVLMEp4CAxc+JlMJsR6KLvp9aAXccsIC7R9GUlK8SlAhJL9pxnhrBFJV4+/scKUZMv sX7OeiaIBYISJ2c+YZnAKDwLSfssJGWzkJRBxA0kvry/DWVrSyxb+JoZwtaX6H5/mglZfAEj +ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwCg6uOW3wQ7Gl88dDzEKcDAq8fAuyFMMF2JN LCuuzD3EKMHBrCTCu0NHKVyINyWxsiq1KD++qDQntfgQozQHi5I4r/9LoGqB9MSS1OzU1ILU IpgsEwenVAOjx+Z3M8UvpNqYeC/48X2Z2Qn1Q5ZzXVn33o+QjBfaKfzaa9MNz5uvf908bC5q IXQ8sf+oR41qXneWA+OkKrUq2Xnqz5nlOIOvcpwunLvhbrGc25QnbKFJTXfNcv+v8hO5XOi/ tb0oVr/nyKnYIyv8lv8/lsR0qHJDXY//ny75220Jlqy6azKVWIozEg21mIuKEwHHJObWngIA AA== Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 28 Apr 2016 15:45:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F89093ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, Also with SIP you can have a choice of IdPs, as long as the app server has = a relationship with them(in order to verify access tokens etc.). The app doesn't necessarily need to have a web interface. The user can e.g.= be requested to select IdP and/or provide credentials using the dial pad. = This is one of the use-cases in the draft. (In case of WebRTC, though, the app and the web interface are typically the= same thing, if it's an HTML5/JS app.) Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD28/=FD04/=FD2016 17:21 To: Christer Holmberg; sipcore@ietf.= org Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 On 4/28/16 6:45 AM, Christer Holmberg wrote: > Hi, > >> Then there remains a question of what the relationship is of those boxes >> to the others. Presumably an App Server will need a trust relationship >> with at least one IdP. How will the user know which IdP to use to obtain >> authorization for a particular app server? > > With web apps, you are redirected to the correct IdP (e.g. Facebook). So, > unless the UA knows which IdP to use, I guess the SIP App Server could > inform it. In the web apps I encounter you are usually given a choice of IdPs that the app server can deal with, and you can choose one that you have a relationship with. That same model could work here if the user is interfacing through an app that has a web interface as well as sip. But it may present a problem in other cases, such as phones with limited UIs. That is why I think it needs to be explored. Thanks, Paul > Regards, > > Christer > > > >> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >>> All, >>> >>> The following is a new problem statement text that I think captures all >>> the comments received so far. >>> Please, take a look and let me know if you have any further comments. >>> >>> Regards, >>> Rifaat >>> >>> >>> --- >>> >>> >>> Overview >>> -------- >>> >>> The following is a simplified classic SIP deployment model: >>> >>> >>> +--------+ >>> | SIP | >>> ,---------------------------| Registrar >>> | | | >>> +--------+ +--------+ >>> +--------+ >>> | | | SIP | | SIP >>> App| >>> | UA |----------------------| Proxy |----------------------| >>> Server | >>> | | | | | >>> | >>> +--------+ +--------+ >>> +--------+ >>> >>> >>> With this model, the endpoint is assigned a dedicated SIP >>> proxy/registrar >>> and all SIP communications must go through that SIP proxy. >>> >>> The SIP Proxy/Registrar plays 3 different roles: >>> 1. Authentication Server (SIP Registrar) >>> 2. Authorization Server >>> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >>> etc. >>> >>> SIP Application Servers provide advanced SIP services, e.g. conference, >>> presence, etc. Application Servers usually have their own authenticatio= n >>> and authorization mechanism that is separate from the one provided by >>> the >>> SIP proxy. >>> >>> We would like to discuss the idea of "outsourcing" the user >>> authentication >>> and services authorization to separate network element(s): >>> >>> >>> Authentication (AuthN) >>> ---------------------- >>> >>> There are two types of authentications in a SIP network: user-to-server >>> authentication and user-to-user authentication. These authentications >>> could >>> be in the context of one trust domain, or it could cross boundaries >>> between >>> different trust domains. >>> >>> We would like to explore the idea of "outsourcing" the user >>> authentication >>> part to a separate IdP entity, to allow the SIP user to use his non-SIP >>> credentials, e.g. corporate credentials, with the IdP to register with >>> the >>> SIP registrar, get basic services from the SIP Proxy, and get access to >>> the >>> advanced services provided by the SIP Application Servers. >>> >>> We would also like to explore the idea of using the same "outsourcing" >>> mechanism to address the user authentication when it crosses trust >>> domain >>> boundaries. >>> >>> >>> Authorization (AuthZ) >>> --------------------- >>> >>> We would like to explore the idea of "outsourcing" the authorization >>> part >>> to a separate network element to allow the administrator to grant >>> access to >>> the basic services provided by the SIP Proxy, and the various advanced >>> services provided by the SIP Application Servers. >>> >>> In general, there are two authorization mechanisms that could be used i= n >>> this case: >>> >>> 1. Self-contained token, which includes all the authorizations needed >>> for >>> the server providing the service to be able to make a decision to >>> grant >>> or deny the service request, and might include control over the >>> level of >>> service provided to the user. >>> >>> 2. Opaque token, which requires an introspection step, where the server >>> providing the service would reach to the authorization server to get >>> the >>> details of the authorizations provided for that specific token. >>> >>> There are pros and cons to each approach that we need to discuss and >>> make a >>> decision on supporting one of these, or maybe both. >>> >>> >>> Trust Relationships >>> ------------------- >>> >>> An important aspect of this exercise is to properly define the trust >>> relationship between the various network elements that would enable the >>> new >>> desired functionalities. >>> >>> >>> Types of Clients >>> ---------------- >>> >>> The solution must take into consideration the various types of SIP >>> clients >>> that might be involved and active in the system, e.g. softclient, >>> hardphones, etc. >>> >>> The solution must also take into consideration the limitation on some o= f >>> these clients that might impact the way assertions are obtained and >>> handled. For example, the following client limitation would require an >>> interim step to obtain an assertion: >>> >>> 1. UI Limitation: a hardphone with limited UI capability that only >>> allows >>> the user to interact with the phone through the phone's keypad. >>> >>> 2. Security Limitation: a client that is incapable of maintaining the >>> security of the user's credentials or the assertion. >>> >>> In these use cases, we would need a way to get the assertion to the >>> servers >>> that will provide the service without requiring the client to get >>> access to >>> the assertion. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > --_000_7594FB04B1934943A5C02806D1A2204B37F89093ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

Also with SIP you can have a choice of IdPs, as long as the app server has = a relationship with them(in order to verify access tokens etc.).

The app doesn't necessarily need to have a web interface. The user can e.g.= be requested to select IdP and/or provide credentials using the dial pad. = This is one of the use-cases in the draft.

(In case of WebRTC, though, the app and the web interface are typically the= same thing, if it's an HTML5/JS app.)

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD28= /=FD04/=FD2016 17:21
To: Christer Holmberg; sipcore@ietf.org
Subject: Re: [= sipcore] SIP AuthNZ Problem Statement v2

On 4/28/16 6:45 AM, Christer Holmberg wrote:
> Hi,
>
>> Then there remains a question of what the relationship is of those= boxes
>> to the others. Presumably an App Server will need a trust relation= ship
>> with at least one IdP. How will the user know which IdP to use to = obtain
>> authorization for a particular app server?
>
> With web apps, you are redirected to the correct IdP (e.g. Facebook). = So,
> unless the UA knows which IdP to use, I guess the SIP App Server could=
> inform it.

In the web apps I encounter you are usually given a choice of IdPs that the app server can deal with, and you can choose one that you have a
relationship with. That same model could work here if the user is
interfacing through an app that has a web interface as well as sip. But it may present a problem in other cases, such as phones with limited UIs.
That is why I think it needs to be explored.

        Thanks,
        Paul

> Regards,
>
> Christer
>
>
>
>> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote:
>>> All,
>>>
>>> The following is a new problem statement text that I think cap= tures all
>>> the comments received so far.
>>> Please, take a look and let me know if you have any further co= mments.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> ---
>>>
>>>
>>> Overview
>>> --------
>>>
>>> The following is a simplified classic SIP deployment model: >>>
>>>
>>>          &nb= sp;            =           +--------+ >>>          &nb= sp;            =           | SIP  &nb= sp; |
>>>     ,---------------------------| Registra= r
>>>     |      &= nbsp;           &nbs= p;        |     = ;   |
>>> +--------+       &n= bsp;            = ;  +--------+
>>> +--------+
>>> |        |   = ;            &n= bsp;      | SIP    |  &nb= sp;            =        | SIP
>>> App|
>>> |   UA   |----------------------| Proxy&nb= sp; |----------------------|
>>> Server |
>>> |        |   = ;            &n= bsp;      |      &nb= sp; |           &nbs= p;          |
>>> |
>>> +--------+       &n= bsp;            = ;  +--------+
>>> +--------+
>>>
>>>
>>> With this model, the endpoint is assigned a dedicated SIP
>>> proxy/registrar
>>> and all SIP communications must go through that SIP proxy.
>>>
>>> The SIP Proxy/Registrar plays 3 different roles:
>>> 1. Authentication Server (SIP Registrar)
>>> 2. Authorization Server
>>> 3. Service provider, e.g. basic calls, call forwarding, call t= ransfer,
>>> etc.
>>>
>>> SIP Application Servers provide advanced SIP services, e.g. co= nference,
>>> presence, etc. Application Servers usually have their own auth= entication
>>> and authorization mechanism that is separate from the one prov= ided by
>>> the
>>> SIP proxy.
>>>
>>> We would like to discuss the idea of "outsourcing" t= he user
>>> authentication
>>> and services authorization to separate network element(s):
>>>
>>>
>>> Authentication (AuthN)
>>> ----------------------
>>>
>>> There are two types of authentications in a SIP network: user-= to-server
>>> authentication and user-to-user authentication. These authenti= cations
>>> could
>>> be in the context of one trust domain, or it could cross bound= aries
>>> between
>>> different trust domains.
>>>
>>> We would like to explore the idea of "outsourcing" t= he user
>>> authentication
>>> part to a separate IdP entity, to allow the SIP user to use hi= s non-SIP
>>> credentials, e.g. corporate credentials, with the IdP to regis= ter with
>>> the
>>> SIP registrar, get basic services from the SIP Proxy, and get = access to
>>> the
>>> advanced services provided by the SIP Application Servers.
>>>
>>> We would also like to explore the idea of using the same "= ;outsourcing"
>>> mechanism to address the user authentication when it crosses t= rust
>>> domain
>>> boundaries.
>>>
>>>
>>> Authorization (AuthZ)
>>> ---------------------
>>>
>>> We would like to explore the idea of "outsourcing" t= he authorization
>>> part
>>> to a separate network element to allow the administrator to gr= ant
>>> access to
>>> the basic services provided by the SIP Proxy, and the various = advanced
>>> services provided by the SIP Application Servers.
>>>
>>> In general, there are two authorization mechanisms that could = be used in
>>> this case:
>>>
>>> 1. Self-contained token, which includes all the authorizations= needed
>>> for
>>>    the server providing the service to be able = to make a decision to
>>> grant
>>>    or deny the service request, and might inclu= de control over the
>>> level of
>>>    service provided to the user.
>>>
>>> 2. Opaque token, which requires an introspection step, where t= he server
>>>    providing the service would reach to the aut= horization server to get
>>> the
>>>    details of the authorizations provided for t= hat specific token.
>>>
>>> There are pros and cons to each approach that we need to discu= ss and
>>> make a
>>> decision on supporting one of these, or maybe both.
>>>
>>>
>>> Trust Relationships
>>> -------------------
>>>
>>> An important aspect of this exercise is to properly define the= trust
>>> relationship between the various network elements that would e= nable the
>>> new
>>> desired functionalities.
>>>
>>>
>>> Types of Clients
>>> ----------------
>>>
>>> The solution must take into consideration the various types of= SIP
>>> clients
>>> that might be involved and active in the system, e.g. softclie= nt,
>>> hardphones, etc.
>>>
>>> The solution must also take into consideration the limitation = on some of
>>> these clients that might impact the way assertions are obtaine= d and
>>> handled. For example, the following client limitation would re= quire an
>>> interim step to obtain an assertion:
>>>
>>> 1. UI Limitation: a hardphone with limited UI capability that = only
>>> allows
>>>    the user to interact with the phone through = the phone's keypad.
>>>
>>> 2. Security Limitation: a client that is incapable of maintain= ing the
>>>    security of the user's credentials or the as= sertion.
>>>
>>> In these use cases, we would need a way to get the assertion t= o the
>>> servers
>>> that will provide the service without requiring the client to = get
>>> access to
>>> the assertion.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/sipcore
>>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://= www.ietf.org/mailman/listinfo/sipcore
>
>

 --_000_7594FB04B1934943A5C02806D1A2204B37F89093ESESSMB209erics_-- From nobody Thu Apr 28 08:53: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 06C1D12D963 for ; Thu, 28 Apr 2016 08:53:38 -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 WK0TYyg22nRz for ; Thu, 28 Apr 2016 08:53:36 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 9BEC312DA15 for ; Thu, 28 Apr 2016 08:48:09 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by comcast with SMTP id voAAaflNmjuYRvoAiaiYIY; Thu, 28 Apr 2016 15:48:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461858488; bh=kCGYtsxOFkyoawTi5l/f831VjULd8nAZdiJZEMpQl+8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dbrUeHlAQ7t+leYNn3SN5q/ZGD73OUQjE8uxZeuX/ORVlBrJhLYIGCmaW2KOJJiSw Ll61nXeWgn9F18/wp88QrD1mLYzMOQmEeK1U/7YSgDo1uRmRdlSXMVyw/HKsY0deHc vGgoRfkeHK47IibW1LCpuuolpNCtZZNVqObUgoPmAEMqv5u4pDcHQq8jis8xuEMzEf vmiusNb1jN1EO7YmADZzN5a3cTDxqlP33rRLDMqEUWyhNZikq+vDNAA435G2lKsAC7 UUfHS3KkgfnRWozZJ19sf7EjREWDU282RXg18CVs4qNAJXrDv8GZecFfLGPV17b0Rr I0F0gFrW3QJWg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id nro81s00D3KdFy101ro8Y7; Thu, 28 Apr 2016 15:48:08 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <4bc0f174-0d52-c13b-d923-4ec4db1d4782@alum.mit.edu> <3215af79-906b-7496-5f6e-2a69ddc6eb7f@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F89093@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 28 Apr 2016 11:48:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F89093@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 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, 28 Apr 2016 15:53:38 -0000 On 4/28/16 11:41 AM, Christer Holmberg wrote: > Hi, > > Also with SIP you can have a choice of IdPs, as long as the app server > has a relationship with them(in order to verify access tokens etc.). > > The app doesn't necessarily need to have a web interface. The user can > e.g. be requested to select IdP and/or provide credentials using the > dial pad. This is one of the use-cases in the draft. > > (In case of WebRTC, though, the app and the web interface are typically > the same thing, if it's an HTML5/JS app.) I'm not saying there aren't solutions - only that it is something that needs to be carefully considered. So it needs to be in the scope of the work. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý28/ý04/ý2016 17:21 > To: Christer Holmberg ; > sipcore@ietf.org > Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2 > > On 4/28/16 6:45 AM, Christer Holmberg wrote: >> Hi, >> >>> Then there remains a question of what the relationship is of those boxes >>> to the others. Presumably an App Server will need a trust relationship >>> with at least one IdP. How will the user know which IdP to use to obtain >>> authorization for a particular app server? >> >> With web apps, you are redirected to the correct IdP (e.g. Facebook). So, >> unless the UA knows which IdP to use, I guess the SIP App Server could >> inform it. > > In the web apps I encounter you are usually given a choice of IdPs that > the app server can deal with, and you can choose one that you have a > relationship with. That same model could work here if the user is > interfacing through an app that has a web interface as well as sip. But > it may present a problem in other cases, such as phones with limited UIs. > > That is why I think it needs to be explored. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >> >>> On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote: >>>> All, >>>> >>>> The following is a new problem statement text that I think captures all >>>> the comments received so far. >>>> Please, take a look and let me know if you have any further comments. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> --- >>>> >>>> >>>> Overview >>>> -------- >>>> >>>> The following is a simplified classic SIP deployment model: >>>> >>>> >>>> +--------+ >>>> | SIP | >>>> ,---------------------------| Registrar >>>> | | | >>>> +--------+ +--------+ >>>> +--------+ >>>> | | | SIP | | SIP >>>> App| >>>> | UA |----------------------| Proxy |----------------------| >>>> Server | >>>> | | | | | >>>> | >>>> +--------+ +--------+ >>>> +--------+ >>>> >>>> >>>> With this model, the endpoint is assigned a dedicated SIP >>>> proxy/registrar >>>> and all SIP communications must go through that SIP proxy. >>>> >>>> The SIP Proxy/Registrar plays 3 different roles: >>>> 1. Authentication Server (SIP Registrar) >>>> 2. Authorization Server >>>> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >>>> etc. >>>> >>>> SIP Application Servers provide advanced SIP services, e.g. conference, >>>> presence, etc. Application Servers usually have their own authentication >>>> and authorization mechanism that is separate from the one provided by >>>> the >>>> SIP proxy. >>>> >>>> We would like to discuss the idea of "outsourcing" the user >>>> authentication >>>> and services authorization to separate network element(s): >>>> >>>> >>>> Authentication (AuthN) >>>> ---------------------- >>>> >>>> There are two types of authentications in a SIP network: user-to-server >>>> authentication and user-to-user authentication. These authentications >>>> could >>>> be in the context of one trust domain, or it could cross boundaries >>>> between >>>> different trust domains. >>>> >>>> We would like to explore the idea of "outsourcing" the user >>>> authentication >>>> part to a separate IdP entity, to allow the SIP user to use his non-SIP >>>> credentials, e.g. corporate credentials, with the IdP to register with >>>> the >>>> SIP registrar, get basic services from the SIP Proxy, and get access to >>>> the >>>> advanced services provided by the SIP Application Servers. >>>> >>>> We would also like to explore the idea of using the same "outsourcing" >>>> mechanism to address the user authentication when it crosses trust >>>> domain >>>> boundaries. >>>> >>>> >>>> Authorization (AuthZ) >>>> --------------------- >>>> >>>> We would like to explore the idea of "outsourcing" the authorization >>>> part >>>> to a separate network element to allow the administrator to grant >>>> access to >>>> the basic services provided by the SIP Proxy, and the various advanced >>>> services provided by the SIP Application Servers. >>>> >>>> In general, there are two authorization mechanisms that could be used in >>>> this case: >>>> >>>> 1. Self-contained token, which includes all the authorizations needed >>>> for >>>> the server providing the service to be able to make a decision to >>>> grant >>>> or deny the service request, and might include control over the >>>> level of >>>> service provided to the user. >>>> >>>> 2. Opaque token, which requires an introspection step, where the server >>>> providing the service would reach to the authorization server to get >>>> the >>>> details of the authorizations provided for that specific token. >>>> >>>> There are pros and cons to each approach that we need to discuss and >>>> make a >>>> decision on supporting one of these, or maybe both. >>>> >>>> >>>> Trust Relationships >>>> ------------------- >>>> >>>> An important aspect of this exercise is to properly define the trust >>>> relationship between the various network elements that would enable the >>>> new >>>> desired functionalities. >>>> >>>> >>>> Types of Clients >>>> ---------------- >>>> >>>> The solution must take into consideration the various types of SIP >>>> clients >>>> that might be involved and active in the system, e.g. softclient, >>>> hardphones, etc. >>>> >>>> The solution must also take into consideration the limitation on some of >>>> these clients that might impact the way assertions are obtained and >>>> handled. For example, the following client limitation would require an >>>> interim step to obtain an assertion: >>>> >>>> 1. UI Limitation: a hardphone with limited UI capability that only >>>> allows >>>> the user to interact with the phone through the phone's keypad. >>>> >>>> 2. Security Limitation: a client that is incapable of maintaining the >>>> security of the user's credentials or the assertion. >>>> >>>> In these use cases, we would need a way to get the assertion to the >>>> servers >>>> that will provide the service without requiring the client to get >>>> access to >>>> the assertion. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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: sipcore <sipcore-bounces@ietf.org> on behalf of Ri= faat Shekh-Yusef <rifaat.ietf@g= mail.com>
Date: Wednesday, April 20, 2016 at = 10:40 AM
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] SIP Authenticati= on/Authorization Problem Statement