From nobody Thu Oct 2 06:36:49 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8391A0369 for ; Thu, 2 Oct 2014 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 xpRdeH1G8-hN for ; Thu, 2 Oct 2014 06:36:44 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3384E1A0347 for ; Thu, 2 Oct 2014 06:36:44 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so2098445qcw.31 for ; Thu, 02 Oct 2014 06:36:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=2NVH7aHJrWyiRITtaOmaXmebydIw+xu1QTfiWbFqy+w=; b=H14xjR6fLVr9IQY+my4AajgGtrMSMNWKwVVQO5MXaE8F2gBo77S3LAlgQU3WFpxvz1 MFoEtjepmWuqSijllF2FvItlU5iNjtFqrti0vs4G8/hXRjRWkcxxVZpKqtE5i8otw9Th /psi2q6A+xSBE4j/OaywwXQj5D0Rbs81DoLd5P+RAZyLiXV/6UydL5L2ODdKBtyGwOnw q383gXWzfCbY6NnDnvLfaaZQfDlI1f0FkDF0Pz6HczC4irL+eqNXHcGmPkbD2P93X8WK SNZFmGtA+fK67VQaiCkqRthQ/daIMjeoyQzcWN4WcrlUub3BYw1f5fdZxGL1iqlSiym2 /NXA== X-Gm-Message-State: ALoCoQkC31I/FzaqyLbHKA7LDGjAA7b/ufXEleNTVml3WT8KsCtuR42xtYQALqXDQ5fYxKanW37+ X-Received: by 10.140.19.142 with SMTP id 14mr46004751qgh.28.1412257003349; Thu, 02 Oct 2014 06:36:43 -0700 (PDT) From: Brett Tate References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJFczc/sUgi56rfylPNQKUV9gkdwJ7RhT4AeyQ2iiahxiF4A== Date: Thu, 2 Oct 2014 09:36:41 -0400 Message-ID: <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> To: OKUMURA Shinji , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/48Fhh-sQVmrzASR2HLpiIolFF-Q Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:36:45 -0000 > I just come up with another approach. > > A referrer send REFER within an existing dialog. > And a notifier(referee) send NOTIFY within new dialog. > Of course Request URI of NOTIFY is a GRUU of a referrer. > > It seems to be a simple solution for an avoidance of dialog-reuse. > > I think this option(Required: subscription-newdialog?) is available > for not only REFER but also SUBSCRIBE. One of the obstacles to this approach is that it would likely require an update to RFC 6665. The NOTIFY is not really a dialog-creating method. RFC 6665 also significantly restricted what could create a subscription; I'm not sure that this approach would satisfy the RFC 6665 restriction. -brett From nobody Thu Oct 2 10:27:34 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968DC1A8F3C for ; Thu, 2 Oct 2014 10:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 e2CLHe3dKn-d for ; Thu, 2 Oct 2014 10:27:30 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140DE1A8A88 for ; Thu, 2 Oct 2014 10:27:29 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so2478897qcv.38 for ; Thu, 02 Oct 2014 10:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=duX+2Js0WjV77J8y0eYAi6tMPkrYk3Ixd0JbMIE/mlU=; b=QOoKdeXGp33qf9I5Rtko85ju6n1ufDa8QodUfp1i3BpEZG0OCARPpTkz1CZbRuhxNp xpnsZbQdklm/tjMLyQyKRVgTvD5VPSDNrY9UctvfQJd99yReYQylWEiSdUxfhp9FHyzO ZtgQnBoSHazo6SuTS4ysEwuhtU15voXW+SMCwae2Livpe5rP/HoUZnbp/U6JQt+anktr II6ccMO5zn5yydIFuTYat7Y9JX0329KEHwFxZPedu47hyW22i8Wz0l5EIDEZ0wTPotto hqZ2L9On7a/SQHjcrE2vFK7ABhknbcO07jjzR9GvfzK8t/ScON2d6oqxnkVCD8Km9l+l x2Kg== X-Gm-Message-State: ALoCoQkkloL07r3nnR5nJpBT45yu4VtJMhnvlC/n8t5Y08GmHizSsOPDSV8fjdauMXZOWRdwbfQ/ X-Received: by 10.224.103.66 with SMTP id j2mr319187qao.13.1412270849200; Thu, 02 Oct 2014 10:27:29 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/eZiEvG2gSj7vcS6CnwmXVc75Ycg== Date: Thu, 2 Oct 2014 13:27:27 -0400 Message-ID: <441422fd28bc1f6193bfb467472eb2f1@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/F7PHj6-vwVTG2oqyzBvvCaRNqKY Subject: [sipcore] draft-sparks-sipcore-refer-clarifications-04: comment X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:27:31 -0000 Hi, Section 3 indicates the following: "3. Use of GRUU is mandatory Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to implement and use as the local target in the subscription created by the REFER request." It is hard not to recommend adding the following text to the section. ;) "The mandate ensures that GRUU and the related patents are applicable to as many devices as possible. At least one Patent Holder states that its position with respect to licensing any patent claims contained in the disclosed patent would necessarily be infringed by implementation of the technology required by the relevant IETF specification, for the purpose of implementing such specification, is as follows: Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee." https://datatracker.ietf.org/ipr/1226/ https://datatracker.ietf.org/ipr/1832/ Cheers, Brett From nobody Fri Oct 3 01:41:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27261A0195 for ; Fri, 3 Oct 2014 01:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 S1joqJGLzSmm for ; Fri, 3 Oct 2014 01:41:05 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B741A0188 for ; Fri, 3 Oct 2014 01:41:04 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so2237410pde.28 for ; Fri, 03 Oct 2014 01:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=HR8D1m+yAe/4weXOKJ2Xh5P6z95R25yClq0I2dZteQM=; b=qVqlneHvLg575bCT8M7JOj1u/BjpAPotE3dZ+FfIJaiatGmJZcZ/4Zmjnwin45i1QI PC+kg23xlQza2PVY3n7E/vsybliQpEWyAKavbF/Y/P+tiw31U9G5LoBI/Hsls76eZt9Z XjN/jzWHYC6O/o/KVVH1AJ/7vdTpJ8FOpv3DJZXGapjpy9AxafeSITf1imblEdxhU6F+ zBVWeS4J5K3xx1LkBv89TrBjGf9hM0ESbqNnQFechLH5GB8p/kOgOKQvzjcewpsmT1cJ SuL8jf81FwNvlyw/An7M6IDHOPZxILF+YF3d+YXCNCAM4XkCSUbI4Ut56SpwzkgK9mNK ctdw== X-Received: by 10.66.145.35 with SMTP id sr3mr5494154pab.55.1412325664660; Fri, 03 Oct 2014 01:41:04 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id yh3sm5951666pbb.38.2014.10.03.01.41.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Oct 2014 01:41:03 -0700 (PDT) From: OKUMURA Shinji To: Robert Sparks , "sipcore@ietf.org" Date: Fri, 03 Oct 2014 17:40:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <540E1444.4020205@nostrum.com> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> Message-Id: <21CFDEE5BE1BABietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QNTbzUdwIYbx2YI0v4jLC-cxWus Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:41:06 -0000 Hi, As a general rule, REFER request may fork. But a referrer receives only one response(i.e. Refer-Events-At). Does this draft disallow a REFER request to be forked? Regards, Shinji >-------- Forwarded Message -------- Subject: New Version Notification for >draft-sparks-sipcore-refer-explicit-subscription-01.txt > Date: Mon, 08 Sep 2014 13:31:32 -0700 > From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org > To: Robert Sparks [a:mailto:rjsparks@nostrum.com], >Robert Sparks [a:mailto:rjsparks@nostrum.com] > > >A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt >has been successfully submitted by Robert Sparks and posted to the >IETF repository. > >Name: draft-sparks-sipcore-refer-explicit-subscription >Revision: 01 >Title: Explicit Subscriptions for the REFER Method >Document date: 2014-09-08 >Group: Individual Submission >Pages: 11 >URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore- >refer-explicit-subscription-01.txt]http://www.ietf.org/internet-drafts/draft- >sparks-sipcore-refer-explicit-subscription-01.txt >Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore- >refer-explicit-subscription/]https://datatracker.ietf.org/doc/draft-sparks- >sipcore-refer-explicit-subscription/ >Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer- >explicit-subscription-01]http://tools.ietf.org/html/draft-sparks-sipcore- >refer-explicit-subscription-01 >Diff: [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore- >refer-explicit-subscription-01]http://www.ietf.org/rfcdiff?url2=draft-sparks- >sipcore-refer-explicit-subscription-01 > >Abstract: > The SIP REFER request, as defined by RFC3515, triggers an implicit > SIP-Specific Event Notification framework subscription. Conflating > the start of the subscription with handling the REFER request makes > negotiating SUBSCRIBE extensions impossible, and complicates avoiding > SIP dialog sharing. This document defines an extension to REFER to > remove the implicit subscription and replace it with an explicit one. > > > > > >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. > >The IETF Secretariat From nobody Fri Oct 3 01:47:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F161ACFF5 for ; Fri, 3 Oct 2014 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 2kmzKDsk2n9i for ; Fri, 3 Oct 2014 01:47:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E01231ACFF3 for ; Fri, 3 Oct 2014 01:47:55 -0700 (PDT) Received: from 132-177-252-46.ip.sipit.net (132-177-252-46.ip.sipit.net [132.177.252.46] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s938lnxj064091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Fri, 3 Oct 2014 03:47:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <542E62B6.8010309@nostrum.com> Date: Fri, 03 Oct 2014 10:47:50 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: OKUMURA Shinji , "sipcore@ietf.org" References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> In-Reply-To: <21CFDEE5BE1BABietf.shinji@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/-yO_mwLxvsovWk1G7dm_fuuyGu4 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:47:57 -0000 On 10/3/14 10:40 AM, OKUMURA Shinji wrote: > Hi, > > As a general rule, REFER request may fork. > But a referrer receives only one response(i.e. Refer-Events-At). > Does this draft disallow a REFER request to be forked? No. If the REFER forks, it will get responses from each branch of the fork. The response from each branch will have its own information about whether the REFER was accepted on that branch, including its own Refer-Events-At URI. With the typical use of REFER specified to date (transfer), the refer will have a Target-Dialog header field and will likely be accepted at only one of the places it might have forked to. RjS > > Regards, > Shinji > >> -------- Forwarded Message -------- Subject: New Version Notification for >> draft-sparks-sipcore-refer-explicit-subscription-01.txt >> Date: Mon, 08 Sep 2014 13:31:32 -0700 >> From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org >> To: Robert Sparks [a:mailto:rjsparks@nostrum.com], >> Robert Sparks [a:mailto:rjsparks@nostrum.com] >> >> >> A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt >> has been successfully submitted by Robert Sparks and posted to the >> IETF repository. >> >> Name: draft-sparks-sipcore-refer-explicit-subscription >> Revision: 01 >> Title: Explicit Subscriptions for the REFER Method >> Document date: 2014-09-08 >> Group: Individual Submission >> Pages: 11 >> URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore- >> refer-explicit-subscription-01.txt]http://www.ietf.org/internet-drafts/draft- >> sparks-sipcore-refer-explicit-subscription-01.txt >> Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore- >> refer-explicit-subscription/]https://datatracker.ietf.org/doc/draft-sparks- >> sipcore-refer-explicit-subscription/ >> Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer- >> explicit-subscription-01]http://tools.ietf.org/html/draft-sparks-sipcore- >> refer-explicit-subscription-01 >> Diff: [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore- >> refer-explicit-subscription-01]http://www.ietf.org/rfcdiff?url2=draft-sparks- >> sipcore-refer-explicit-subscription-01 >> >> Abstract: >> The SIP REFER request, as defined by RFC3515, triggers an implicit >> SIP-Specific Event Notification framework subscription. Conflating >> the start of the subscription with handling the REFER request makes >> negotiating SUBSCRIBE extensions impossible, and complicates avoiding >> SIP dialog sharing. This document defines an extension to REFER to >> remove the implicit subscription and replace it with an explicit one. >> >> >> >> >> >> 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. >> >> The IETF Secretariat From nobody Fri Oct 3 02:35:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24C71AD002 for ; Fri, 3 Oct 2014 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 doS_qqCioBKD for ; Fri, 3 Oct 2014 02:35:54 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FDB1AD000 for ; Fri, 3 Oct 2014 02:35:54 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lj1so1263744pab.38 for ; Fri, 03 Oct 2014 02:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=M7zwDhQqpOvoxa0SYobANoPu29fkz49aOlPmMKt5H/w=; b=Xew6bBtnpIaXxnBORNST1baWOZvsUjSp4pLVneeSTVr02KaxwvEaxQ7JMTjQh0D7y5 Ftz1wf2+rRHLlOABDnzwRkvzStTzxVuYpypSEJu07wMO1fliORM5oD7yqn6XaL3Ra9Ik FHPG3R8PxJS7zbECvgdKmYqwsGZv0f0lbmsefALIjaXXuVqCODTVuhz3oFezbWOdUHmI 8CFCh95bJqg8YZvrhuCx5/iiV/YvmrqJA53JUdwOyLmWrkaCDrHVuRPdpptiIgxEwIaJ Tfj0Xz2kZqEEdDzOoR6w/Jlg2ROtPZ8uojJJqzQDbKeQBwxhcTG6BOBPnIyLcxWKyu69 bBtw== X-Received: by 10.67.5.228 with SMTP id cp4mr5694552pad.45.1412328953153; Fri, 03 Oct 2014 02:35:53 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id zf5sm6050980pbc.44.2014.10.03.02.35.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Oct 2014 02:35:52 -0700 (PDT) From: OKUMURA Shinji To: Brett Tate , sipcore@ietf.org Date: Fri, 03 Oct 2014 18:35:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> Message-Id: <3ECFDEED65D521ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zl0xpi8vm0GuGItPXpOd9KgQuSI Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:35:55 -0000 Hi, Brett. Thanks for your reply. >> I just come up with another approach. >> >> A referrer send REFER within an existing dialog. >> And a notifier(referee) send NOTIFY within new dialog. >> Of course Request URI of NOTIFY is a GRUU of a referrer. >> >> It seems to be a simple solution for an avoidance of dialog-reuse. >> >> I think this option(Required: subscription-newdialog?) is available >> for not only REFER but also SUBSCRIBE. > >One of the obstacles to this approach is that it would likely require an >update to RFC 6665. The NOTIFY is not really a dialog-creating method. RFC 6665 seems to say that a NOTIFY create a dialog, but a SUBSCRIBE does not create a dialog. Is my understanding wrong? >RFC 6665 also significantly restricted what could create a subscription; >I'm not sure that this approach would satisfy the RFC 6665 restriction. Yes, my approach could be contrary to something else. (i.e. section 4.4.1) Regards, Shinji From nobody Fri Oct 3 02:58:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0CC1AD01F for ; Fri, 3 Oct 2014 02:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 rIQGWlF-9AKK for ; Fri, 3 Oct 2014 02:58:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ABCD71AD01E for ; Fri, 3 Oct 2014 02:58:11 -0700 (PDT) Received: from 132-177-252-46.ip.sipit.net ([132.177.252.46]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s939w8Ph070645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Fri, 3 Oct 2014 04:58:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [132.177.252.46] claimed to be 132-177-252-46.ip.sipit.net Message-ID: <542E7331.8070408@nostrum.com> Date: Fri, 03 Oct 2014 11:58:09 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ggr_BEuiARTfJhgl1sHsYalqJWM Subject: [sipcore] SIPit 31 Summary X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:58:13 -0000 We had a great event at SIPit 31. The summary is available at RjS From nobody Fri Oct 3 05:13:10 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F7C1A0326 for ; Fri, 3 Oct 2014 05:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1OZnta2qKFzi for ; Fri, 3 Oct 2014 05:13:07 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809241A030C for ; Fri, 3 Oct 2014 05:13:07 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id e89so800449qgf.32 for ; Fri, 03 Oct 2014 05:13:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=vnIorE6FpKprYzq4Sx4Sbcd/d7ZlXlv/daH/zJ6IRY0=; b=k9U6dME6UhF6swBVi3uRU+ue8U/UriR8imUG5ooGdc2VR/3DkHCPf2H6DhGVHLxAkr 9awAcmayEzdrf6RdyM1MosdpkS4lhb3M1Sal2Fqm6dTsHXVb8jCY4kHi/pxiDd5LVXQi SmkoYASyQimGp7yPmZZ92xYqoJ9RrX1nbwrvrHz3BuaX7aGgIjySawzDVAVec1svomoM CM63v31/rDCt3Psa48Apt8iRWVEsWFF9FqfNqgyl8sc4Dx/GnlAd8yBRhon6YWH56At2 MwgrXUqfjAf631LQ7wNLBNJSkqvjgOSsXykxkKD05YykqNfu5vEBel0VyiYJnx8ix5uz LLBA== X-Gm-Message-State: ALoCoQnOO+dulN6nBwjN+sFhL01S+E+YTZS+s+y8ChsKOQy8vvSAxRAtxkaWjD7jPkLIH0e1rrCt X-Received: by 10.224.22.18 with SMTP id l18mr6624598qab.84.1412338385982; Fri, 03 Oct 2014 05:13:05 -0700 (PDT) From: Brett Tate References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> <3ECFDEED65D521ietf.shinji@gmail.com> In-Reply-To: <3ECFDEED65D521ietf.shinji@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJFczc/sUgi56rfylPNQKUV9gkdwJ7RhT4AeyQ2igB0tIoUAK7w3wbmmQZlfA= Date: Fri, 3 Oct 2014 08:13:04 -0400 Message-ID: <9af1e223d41bfbada012b21db729dcc3@mail.gmail.com> To: OKUMURA Shinji , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/wFE9qHy6GteFtic8-yCB0PcPSFg Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 12:13:09 -0000 > >> A referrer send REFER within an existing dialog. > >> And a notifier(referee) send NOTIFY within new dialog. > >> Of course Request URI of NOTIFY is a GRUU of a referrer. > >> > >> It seems to be a simple solution for an avoidance of dialog-reuse. > >> > >> I think this option(Required: subscription-newdialog?) is available > >> for not only REFER but also SUBSCRIBE. > > > >One of the obstacles to this approach is that it would likely require > >an update to RFC 6665. The NOTIFY is not really a dialog-creating method. > > RFC 6665 seems to say that a NOTIFY create a dialog, but a SUBSCRIBE does > not create a dialog. > > Is my understanding wrong? Section 4.1.2.1 indicates "SUBSCRIBE is a dialog-creating method, as described in [RFC3261]". The NOTIFY contains a To tag which is one of the items that allow it be matched to the SUBSCRIBE or REFER. Section 4.4.1: "NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header field "tag" parameter that matches the "From" header field "tag" parameter of the SUBSCRIBE request, and the same "Event" header field." From nobody Sun Oct 5 22:45:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355E21A1B38 for ; Sun, 5 Oct 2014 22:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GqcJrJ4KxFgi for ; Sun, 5 Oct 2014 22:44:55 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85291A1B35 for ; Sun, 5 Oct 2014 22:44:55 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so4662196pad.5 for ; Sun, 05 Oct 2014 22:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=xovNrGEKJLxFDvrVjBgAJl9jvPq/0AVAnc101oa3vE4=; b=oN96vXWzpW3mV0BoSqiVi9wwMd6jUcB0XdDN4H+P9fRRknD7pG6NGyxhe1wSTEYAUM Ql2YGLvS3563e7koVibq4JhkxIjh5an2wsbX1yLwp4Fi9hJDvOz4oHat5U8XM7xjwSR0 bY/lIz6rjXgVNxlQfLsBEQhd8foYgMuON0GQF8tlWG8dSJyvshasw7RREnel8j0989va zASg8tilF7Ap9YPoII1H4xozZU6SwAf+h63lT1H0cV6WxPS4F92JS6bOZe5Jyp4vnsIq 68SZ6SK2BFjAetvG6NU5ZKwqNd/GjkfQELgnzms4bp/W8eXHd9S40Zk/GHWySWCRSpH8 MbQQ== X-Received: by 10.70.9.129 with SMTP id z1mr16166987pda.37.1412574295408; Sun, 05 Oct 2014 22:44:55 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id fl15sm9958661pdb.92.2014.10.05.22.44.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Oct 2014 22:44:54 -0700 (PDT) From: OKUMURA Shinji To: Robert Sparks , "sipcore@ietf.org" Date: Mon, 06 Oct 2014 14:44:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <542E62B6.8010309@nostrum.com> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> Message-Id: <52CFE128A63254ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kyrDc4o5UMxzXekveCX_rLFoONk Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 05:44:57 -0000 Hello Robert, >On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >> Hi, >> >> As a general rule, REFER request may fork. >> But a referrer receives only one response(i.e. Refer-Events-At). >> Does this draft disallow a REFER request to be forked? >No. > >If the REFER forks, it will get responses from each branch of the fork. >The response from each branch will have its own information about whether >the REFER was accepted on that branch, including its own Refer-Events-At >URI. In accordance with the following, a successful response for REFER request is only one. RFC3261 17.1.2.1 Overview of the non-INVITE Transaction Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC. >With the typical use of REFER specified to date (transfer), the refer >will have >a Target-Dialog header field and will likely be accepted at only one of the >places it might have forked to. > >RjS Regards, Shinji From nobody Sun Oct 5 23:25:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F044E1A00B0 for ; Sun, 5 Oct 2014 23:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 tqLSbbyn4O6h for ; Sun, 5 Oct 2014 23:25:00 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87771A0636 for ; Sun, 5 Oct 2014 23:24:59 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so4813289pad.29 for ; Sun, 05 Oct 2014 23:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=apN0P5YvU9HotKF487csGw7l1Kn30CR1gKiyFHAbrR4=; b=06rMqMQR8ZNZ3pEZ+Do32JDGIRbmmTRiA5KpoFVEpYzEahYGVKsT9ZUA1FLGHVBN36 VgdNCNiAmEgM0KAoIOS0teGkVGkhR/kWtx4SMbFNqVRGuaUNbtusgGZX3kM56MqLA9RT kISRCgdF6hzVT5kuuY1VCY1lPdOMea4FWcK8NKNUsr4fwNgRyDteUvXj/5bXV6YrMcs1 C0nXTPCArH4dtJsxNj5qHwDup+hYMwrhA/lfpDi3CNeC/W1foqLMQX472gLwDX0gdi0v pIGkHP6R+e4lOhnvzzyB5G0dNFmDukrbT85j4rHa+HibTwyIt5j6goy25Y4wRjxp8jWB evHg== X-Received: by 10.67.23.136 with SMTP id ia8mr1238093pad.125.1412576699495; Sun, 05 Oct 2014 23:24:59 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id x15sm12249632pbt.91.2014.10.05.23.24.57 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Oct 2014 23:24:58 -0700 (PDT) From: OKUMURA Shinji To: Brett Tate , sipcore@ietf.org Date: Mon, 06 Oct 2014 15:24:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <9af1e223d41bfbada012b21db729dcc3@mail.gmail.com> References: <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> <3ECFDEED65D521ietf.shinji@gmail.com> <9af1e223d41bfbada012b21db729dcc3@mail.gmail.com> Message-Id: <5CCFE12E3F08F1ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/WC07P73cPper77eoAg9S1WKhBVw Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 06:25:05 -0000 Hi Brett, >> >> A referrer send REFER within an existing dialog. >> >> And a notifier(referee) send NOTIFY within new dialog. >> >> Of course Request URI of NOTIFY is a GRUU of a referrer. >> >> >> >> It seems to be a simple solution for an avoidance of dialog-reuse. >> >> >> >> I think this option(Required: subscription-newdialog?) is available >> >> for not only REFER but also SUBSCRIBE. >> > >> >One of the obstacles to this approach is that it would likely require >> >an update to RFC 6665. The NOTIFY is not really a dialog-creating method. >> >> RFC 6665 seems to say that a NOTIFY create a dialog, but a SUBSCRIBE does >> not create a dialog. >> >> Is my understanding wrong? > >Section 4.1.2.1 indicates "SUBSCRIBE is a dialog-creating method, as >described in [RFC3261]". > >The NOTIFY contains a To tag which is one of the items that allow it be >matched to the SUBSCRIBE or REFER. > >Section 4.4.1: > >"NOTIFY requests are matched to such SUBSCRIBE requests if they > contain the same "Call-ID", a "To" header field "tag" parameter that > matches the "From" header field "tag" parameter of the SUBSCRIBE > request, and the same "Event" header field." But then, Appendix B. Changes from RFC 3265 B.22. Rationalize Dialog Creation Section 4.4.1 has been updated to specify that dialogs should be created when the NOTIFY arrives. Previously, the dialog was established by the SUBSCRIBE 200 or by the NOTIFY transaction. This was unnecessarily complicated; the newer rules are easier to implement (and result in effectively the same behavior on the wire). For me, these descriptions are considerably ambiguous. Regards, Shinji From nobody Mon Oct 6 05:41:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561AB1A6EED for ; Mon, 6 Oct 2014 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 kk6mfeKM7Yep for ; Mon, 6 Oct 2014 05:41:39 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DD21A1BE0 for ; Mon, 6 Oct 2014 05:41:38 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so4259002lab.19 for ; Mon, 06 Oct 2014 05:41:37 -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 :content-type; bh=c2JEmrfgat5hM1GwTN29tHoC8AxeW7qSEe0HzYo2sN8=; b=w63FUWDn5/WYU0siC4HFP9ALusxntrMphtsBnzA2qd4BLjLPZVdZssFz8vvhzXF1aa dZr/e9Nbo/2bJxXU61qHZK7jwPFIF9hwaony3fdVstbg6vP5BMY8lkEpEf4ScxUDToPj rOlAuSX3awc8/An4D+Eh9VKJIlY9/Tenw+D518zwBJxrIlBSvFLoIjXggDMD3dUNciUk rBZrpml5IzauphwI2jpGbKvwHCC1yKZq4o3NBNxTDaeoq0gBHqCfNfmfSfPyTcyob9e3 nrdDfDT/oqfish80M3aXeVkmyPzkDQbPGo5JxehqMHoEbPqWSnSrIPX+RK1ftvfC1Grc +TpA== MIME-Version: 1.0 X-Received: by 10.152.4.98 with SMTP id j2mr8997236laj.77.1412599296911; Mon, 06 Oct 2014 05:41:36 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Mon, 6 Oct 2014 05:41:36 -0700 (PDT) In-Reply-To: References: <20141005234357.30858.31754.idtracker@ietfa.amsl.com> Date: Mon, 6 Oct 2014 08:41:36 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=089e0141ab444d6df80504c06712 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/En-U0leo_Ur95pADXl3m6dR_HvQ Subject: [sipcore] Fwd: FW: New Version Notification for draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 12:41:41 -0000 --089e0141ab444d6df80504c06712 Content-Type: text/plain; charset=ISO-8859-1 Hi, As part of the SIP Over IPv6 Task Group activities in the SIP Forum we created the following *Informational* draft which describes the impact on IPv4 SIP elements when interacting with IPv6 SIP elements. The draft was initially discussed on the DISPATCH mailing list, but after discussing this draft with Mary Barnes (co-chair of DISPATCH) and Paul Kyzivat (co-chair of SIPCore) it was decided that the SIPCore would the right place to discuss this. We would appreciate it if people review and provide feedback on this draft. Regards, Rifaat -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, October 05, 2014 7:44 PM To: Shekh-Yusef, Rifaat (Rifaat); Carl Klatsky; Gonzalo Salgueiro; Andrew Hutton; Olle E.Johansson; Olle E. Johansson; Carl Klatsky; Gonzalo Salgueiro; Shekh-Yusef, Rifaat (Rifaat); Andrew Hutton Subject: New Version Notification for draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt A new version of I-D, draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt has been successfully submitted by Carl Klatsky and posted to the IETF repository. Name: draft-klatsky-sipcore-ipv6-impact-ipv4 Revision: 00 Title: Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations Document date: 2014-10-05 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt Status: https://datatracker.ietf.org/doc/draft-klatsky-sipcore-ipv6-impact-ipv4/ Htmlized: http://tools.ietf.org/html/draft-klatsky-sipcore-ipv6-impact-ipv4-00 Abstract: This document captures potential impacts to IPv4 SIP implementations when interworking with IPv6 SIP implementations. Although some amount of interworking translation will occur at the network and application layers, an IPv4 SIP application may still encounter a SIP message with some IPv6 values in it, resulting in unforeseen error conditions. Such potential scenarios will be identified in this document so that SIP application developers can define solutions to handle these cases. Note, this document is not intended to be an exhaustive list, rather to provide an overview of some of the more commonly encountered potential scenarios. 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. The IETF Secretariat --089e0141ab444d6df80504c06712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

As part of the SIP Over IPv6 Task= Group activities in the SIP Forum we created the following Informationa= l draft which describes the impact on IPv4 SIP elements when interactin= g with IPv6 SIP elements.
The draft was ini= tially discussed on the DISPATCH mailing list, but after discussing this dr= aft with Mary Barnes (co-chair of DISPATCH) and Paul Kyzivat (co-chair of S= IPCore) it was decided that the SIPCore would the right place to discuss th= is.

We= would appreciate it if people review and provide feedback on this draft.

Regards= ,
=A0Rifaat




-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Sunday, October 05, 2014 7:44 PM
To: Shekh-Yusef, Rifaat (Rifaat); Carl Klatsky; Gonzalo Salgueiro; Andrew H= utton; Olle E.Johansson; Olle E. Johansson; Carl Klatsky; Gonzalo Salgueiro= ; Shekh-Yusef, Rifaat (Rifaat); Andrew Hutton
Subject: New Version Notification for draft-klatsky-sipcore-ipv6-impact-ipv= 4-00.txt


A new version of I-D, draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt
has been successfully submitted by Carl Klatsky and posted to the IETF repo= sitory.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-klatsky-sipcore-ipv6-impact-ipv4
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 Interoperability Impacts of IPv6 Interworking wit= h Existing IPv4 SIP Implementations
Document date:=A0 2014-10-05
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 10
URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www= .ietf.org/internet-drafts/draft-klatsky-sipcore-ipv6-impact-ipv4-00.txt=
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.i= etf.org/doc/draft-klatsky-sipcore-ipv6-impact-ipv4/
Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-klatsky-sipcore-ipv6-impact-ipv4-00


Abstract:
=A0 =A0This document captures potential impacts to IPv4 SIP implementations=
=A0 =A0when interworking with IPv6 SIP implementations.=A0 Although some =A0 =A0amount of interworking translation will occur at the network and
=A0 =A0application layers, an IPv4 SIP application may still encounter a SI= P
=A0 =A0message with some IPv6 values in it, resulting in unforeseen error =A0 =A0conditions.=A0 Such potential scenarios will be identified in this =A0 =A0document so that SIP application developers can define solutions to<= br> =A0 =A0handle these cases.=A0 Note, this document is not intended to be an<= br> =A0 =A0exhaustive list, rather to provide an overview of some of the more =A0 =A0commonly encountered potential scenarios.




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

The IETF Secretariat


--089e0141ab444d6df80504c06712-- From nobody Mon Oct 6 06:43:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2D91A6F61 for ; Mon, 6 Oct 2014 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=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 j677MQJV5Gf5 for ; Mon, 6 Oct 2014 06:43:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A32AE1A6F7D for ; Mon, 6 Oct 2014 06:43:14 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5A0F493C2A2; Mon, 6 Oct 2014 13:42:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" Date: Mon, 6 Oct 2014 15:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141006132714.9383.80392.idtracker@ietfa.amsl.com> To: SIPCORE X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/e282HF0dr9XcIHNzzLHW6SBXfms Cc: Olle E Johansson Subject: [sipcore] Fwd: New Version Notification for draft-johansson-sip-dual-stack-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:43:18 -0000 Hi! Just updated the version number to make this draft active again. During SIPit31 last week we confirmed the issues mentioned in the draft, = but also discovered a new issue.=20 This may not be directly SIP related but important for developers: We added a few IPv6 ULA networks to the SIPit LAN. It seemed like = multiple network addresses apart from one global and one link-local had = not been tested by the developers before. We noticed that = implementations had problems selecting candidates for ICE as well as = selecting source IP address. I added a SIP proxy on a ULA address and it = could not be reached. Aside from that, the proxy itself had issues = selecting source address (with a more than ten year old IPv6 = implementation). It made it very clear to participants that "one = interface, one address" does no longer apply. Cheers, /O Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-johansson-sip-dual-stack-03.txt > Date: 6 Oct 2014 15:27:14 GMT+2 > To: "Gonzalo Salgueiro" , Olle E. Johansson = , "Olle E. Johansson" , Gonzalo = Salgueiro >=20 >=20 > A new version of I-D, draft-johansson-sip-dual-stack-03.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Name: draft-johansson-sip-dual-stack > Revision: 03 > Title: Locating Session Initiation Protocol (SIP) = Servers in a Dual-Stack IP Network > Document date: 2014-10-06 > Group: Individual Submission > Pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stack-03.txt > Status: = https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/ > Htmlized: = http://tools.ietf.org/html/draft-johansson-sip-dual-stack-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-sip-dual-stack-03 >=20 > 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. The specification repeatedly states that the > implementation should look up IPv4 or IPv6 addresses. This is not a > suitable solution and one that can cause severely degraded user > experience dual-stack clients, as detailed in the Happy Eyeballs > specification. This document specifies amended procedures for dual- > stack SIP implementations so that they look up both IPv4 and IPv6 > addresses. This way, the SIP implementation can find the preferred > network path and protocol with an improved chance of successfully > reaching the desired service. This document also clarifies DNS SRV > usage for single-stack clients. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Mon Oct 6 07:21:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7461A0313 for ; Mon, 6 Oct 2014 07:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=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 TW3pvxUzNePa for ; Mon, 6 Oct 2014 07:21:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 72F841A0301 for ; Mon, 6 Oct 2014 07:20:58 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 378EA93C2A2; Mon, 6 Oct 2014 14:20:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" Date: Mon, 6 Oct 2014 16:20:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141006141617.3853.23017.idtracker@ietfa.amsl.com> To: SIPCORE X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/oRML_7e9r9SVxzmoIUwCt1yek3E Cc: Olle E Johansson Subject: [sipcore] Fwd: New Version Notification for draft-johansson-sipcore-dane-sip-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:21:01 -0000 Just a update of the name - no content changed - to keep it on track. Cheers, /O Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-johansson-sipcore-dane-sip-00.txt > Date: 6 Oct 2014 16:16:17 GMT+2 > To: Olle E. Johansson , "Olle E. Johansson" = >=20 >=20 > A new version of I-D, draft-johansson-sipcore-dane-sip-00.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Name: draft-johansson-sipcore-dane-sip > Revision: 00 > Title: TLS sessions in SIP using DNS-based = Authentication of Named Entities (DANE) TLSA records > Document date: 2014-10-06 > Group: Individual Submission > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-sipcore-dane-sip-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-johansson-sipcore-dane-sip/ > Htmlized: = http://tools.ietf.org/html/draft-johansson-sipcore-dane-sip-00 >=20 >=20 > Abstract: > Use of TLS in the SIP protocol is defined in multiple documents, > starting with RFC 3261. The actual verification that happens when > setting up a SIP TLS connection to a SIP server based on a SIP URI = is > described in detail in RFC 5922 - SIP Domain Certificates. >=20 > In this document, an alternative method is defined, using DNS-Based > Authentication of Named Entities (DANE). By looking up TLSA DNS > records and using DNSsec protection of the required queries, > including lookups for NAPTR and SRV records, a SIP Client can verify > the identity of the TLS SIP server in a different way, matching on > the SRV host name in the X.509 PKIX certificate instead of the SIP > domain. This provides more scalability in hosting solutions and = make > it easier to use standard CA certificates (if needed at all). >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Mon Oct 6 07:26:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAFE1A0300 for ; Mon, 6 Oct 2014 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 YvZTOxZQewOl for ; Mon, 6 Oct 2014 07:26:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3FAAD1A033E for ; Mon, 6 Oct 2014 07:26:06 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s96EQ2QQ059234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Mon, 6 Oct 2014 09:26:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5432A675.9020702@nostrum.com> Date: Mon, 06 Oct 2014 09:25:57 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: OKUMURA Shinji , "sipcore@ietf.org" References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> In-Reply-To: <52CFE128A63254ietf.shinji@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gmHBD96crppm_GhFrHwXoGMXXQw Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:26:08 -0000 On 10/6/14 12:44 AM, OKUMURA Shinji wrote: > Hello Robert, > >> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>> Hi, >>> >>> As a general rule, REFER request may fork. >>> But a referrer receives only one response(i.e. Refer-Events-At). >>> Does this draft disallow a REFER request to be forked? >> No. >> >> If the REFER forks, it will get responses from each branch of the fork. >> The response from each branch will have its own information about whether >> the REFER was accepted on that branch, including its own Refer-Events-At >> URI. > In accordance with the following, a successful response for REFER > request is only one. > > RFC3261 > 17.1.2.1 Overview of the non-INVITE Transaction > > Unlike an INVITE transaction, a non-INVITE transaction has no special > handling for the 2xx response. The result is that only a single 2xx > response to a non-INVITE is ever delivered to a UAC. Wow (slaps forehead) - very good catch. That's the whole reason the immediate NOTIFY in SIP Events exists. The consequences of that are going to require some time to think through. > > >> With the typical use of REFER specified to date (transfer), the refer >> will have >> a Target-Dialog header field and will likely be accepted at only one of the >> places it might have forked to. >> >> RjS > Regards, > Shinji From nobody Mon Oct 6 07:33:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292771A0300 for ; Mon, 6 Oct 2014 07:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=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 VMhUnlKK0unx for ; Mon, 6 Oct 2014 07:33:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6D1A0085 for ; Mon, 6 Oct 2014 07:33:25 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 88D3F93C2A2; Mon, 6 Oct 2014 14:32:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 6 Oct 2014 16:33:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23D2CD0C-99D1-4833-B884-A401170CEB91@edvina.net> References: <20141006132714.9383.80392.idtracker@ietfa.amsl.com> To: SIPCORE X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JxCO3ulpFvXNvaUKKCQBZFZWH-I Cc: Olle E Johansson Subject: Re: [sipcore] Fwd: New Version Notification for draft-johansson-sip-dual-stack-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:33:28 -0000 On 06 Oct 2014, at 15:43, Olle E. Johansson wrote: > Hi! > Just updated the version number to make this draft active again. Which was a stupid thing, since it's replaced by = draft-ietf-sipcore-dns-dual-stack-00. Life. /O >=20 > During SIPit31 last week we confirmed the issues mentioned in the = draft, but also discovered a new issue.=20 >=20 > This may not be directly SIP related but important for developers: >=20 > We added a few IPv6 ULA networks to the SIPit LAN. It seemed like = multiple network addresses apart from one global and one link-local had = not been tested by the developers before. We noticed that = implementations had problems selecting candidates for ICE as well as = selecting source IP address. I added a SIP proxy on a ULA address and it = could not be reached. Aside from that, the proxy itself had issues = selecting source address (with a more than ten year old IPv6 = implementation). It made it very clear to participants that "one = interface, one address" does no longer apply. >=20 > Cheers, > /O >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-johansson-sip-dual-stack-03.txt >> Date: 6 Oct 2014 15:27:14 GMT+2 >> To: "Gonzalo Salgueiro" , Olle E. Johansson = , "Olle E. Johansson" , Gonzalo = Salgueiro >>=20 >>=20 >> A new version of I-D, draft-johansson-sip-dual-stack-03.txt >> has been successfully submitted by Olle E. Johansson and posted to = the >> IETF repository. >>=20 >> Name: draft-johansson-sip-dual-stack >> Revision: 03 >> Title: Locating Session Initiation Protocol (SIP) = Servers in a Dual-Stack IP Network >> Document date: 2014-10-06 >> Group: Individual Submission >> Pages: 6 >> URL: = http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stack-03.txt >> Status: = https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/ >> Htmlized: = http://tools.ietf.org/html/draft-johansson-sip-dual-stack-03 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-sip-dual-stack-03 >>=20 >> 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. The specification repeatedly states that the >> implementation should look up IPv4 or IPv6 addresses. This is not a >> suitable solution and one that can cause severely degraded user >> experience dual-stack clients, as detailed in the Happy Eyeballs >> specification. This document specifies amended procedures for dual- >> stack SIP implementations so that they look up both IPv4 and IPv6 >> addresses. This way, the SIP implementation can find the preferred >> network path and protocol with an improved chance of successfully >> reaching the desired service. This document also clarifies DNS SRV >> usage for single-stack clients. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 6 07:59:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0265E1A6FC7 for ; Mon, 6 Oct 2014 07:59:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Z2IrWnZcN19t for ; Mon, 6 Oct 2014 07:59:34 -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 6FCC41A01A8 for ; Mon, 6 Oct 2014 07:59:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-d3-5432ae532717 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.CD.02247.35EA2345; Mon, 6 Oct 2014 16:59:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 16:59:31 +0200 From: Christer Holmberg To: Robert Sparks , OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 Thread-Index: AQHP4Sitk7syhy5dEkWF18PjbgOJz5wi/wqAgAAq55k= Date: Mon, 6 Oct 2014 14:59:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46A059@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com>,<5432A675.9020702@nostrum.com> In-Reply-To: <5432A675.9020702@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D46A059ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7wOqMQg5+vNSyW9K9hs7g2p5HN 4uuPTWwOzB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mg49nMJeMNWg4t3VM+wN jJ2aXYycHBICJhJTt39ghrDFJC7cW8/WxcjFISRwlFHizYIlTBDOYkaJhQ9uMHYxcnCwCVhI dP/TBmkQEaiUuLDyGhOILSyQKXFh0mwmiHiWxKMt91ggbCuJCV9fs4C0sgioSGxbGQAS5hXw lZjx7A/U+A+MEq1nv4LVcwpoS+z+PwVsDiPQQd9PrQGzmQXEJZq+rGSFOFRAYsme81BHi0q8 fPyPFaImX+Lx+24miAWCEidnPmGZwCg8C0n7LCRls5CUQcQNJL68vw1la0ssW/iaGcLWl+h+ f5oJWXwBI/sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCYOrjlt9UOxoPPHQ8xCnAwKvHw Juw3DBFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxqbbdN TCSOfZvVnD6r/sMl6WRJbRHB38kbQlaZTb6Qrj2Nx3Pq675XxX37ZRb+2fl6yjqRfWpcDmfT 5y6/fKgo5IyF6qQVywIM5H22H9lpuUGVtzx1wtkdj8Pn7/RbeYnhkwf/4b38PBc5rc5HM777 n2u5RqnXzzsqjF8ug+kv80W3aLW9TReUWIozEg21mIuKEwHkIUZuigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Ad2OSxZEb2EpBAdoDOL7iweO45Y Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:59:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D46A059ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, This of course does not apply to in-dialog REFERs, where forking does not o= ccur. Regards, Christer Sent from my Windows Phone ________________________________ From: Robert Sparks Sent: =FD06/=FD10/=FD2014 17:26 To: OKUMURA Shinji; sipcore@ietf.org Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-re= fer-explicit-subscription-01 On 10/6/14 12:44 AM, OKUMURA Shinji wrote: > Hello Robert, > >> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>> Hi, >>> >>> As a general rule, REFER request may fork. >>> But a referrer receives only one response(i.e. Refer-Events-At). >>> Does this draft disallow a REFER request to be forked? >> No. >> >> If the REFER forks, it will get responses from each branch of the fork. >> The response from each branch will have its own information about whethe= r >> the REFER was accepted on that branch, including its own Refer-Events-At >> URI. > In accordance with the following, a successful response for REFER > request is only one. > > RFC3261 > 17.1.2.1 Overview of the non-INVITE Transaction > > Unlike an INVITE transaction, a non-INVITE transaction has no special > handling for the 2xx response. The result is that only a single 2xx > response to a non-INVITE is ever delivered to a UAC. Wow (slaps forehead) - very good catch. That's the whole reason the immediate NOTIFY in SIP Events exists. The consequences of that are going to require some time to think through. > > >> With the typical use of REFER specified to date (transfer), the refer >> will have >> a Target-Dialog header field and will likely be accepted at only one of = the >> places it might have forked to. >> >> RjS > Regards, > Shinji _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D46A059ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

This of course does not apply to in-dialog REFERs, where forking does not o= ccur.

Regards,

Christer


Sent from my Windows Phone
From: Robert Sparks
Sent: =FD06= /=FD10/=FD2014 17:26
To: OKUMURA Shinji; sipcore@ietf.org
Subject: Re: [= sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-s= ubscription-01


On 10/6/14 12:44 AM, OKUMURA Shinji wrote:
> Hello Robert,
>
>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote:
>>> Hi,
>>>
>>> As a general rule, REFER request may fork.
>>> But a referrer receives only one response(i.e. Refer-Events-At= ).
>>> Does this draft disallow a REFER request to be forked?
>> No.
>>
>> If the REFER forks, it will get responses from each branch of the = fork.
>> The response from each branch will have its own information about = whether
>> the REFER was accepted on that branch, including its own Refer-Eve= nts-At
>> URI.
> In accordance with the following, a successful response for REFER
> request is only one.
>
> RFC3261
> 17.1.2.1 Overview of the non-INVITE Transaction
>
>     Unlike an INVITE transaction, a non-INVITE tra= nsaction has no special
>     handling for the 2xx response.  The resul= t is that only a single 2xx
>     response to a non-INVITE is ever delivered to = a UAC.
Wow (slaps forehead) - very good catch. That's the whole reason the
immediate NOTIFY
in SIP Events exists.

The consequences of that are going to require some time to think through.

>
>
>> With the typical use of REFER specified to date (transfer), the re= fer
>> will have
>> a Target-Dialog header field and will likely be accepted at only o= ne of the
>> places it might have forked to.
>>
>> RjS
> Regards,
> Shinji

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B1D46A059ESESSMB209erics_-- From nobody Mon Oct 6 10:49:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D821F1A872F for ; Mon, 6 Oct 2014 10:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 lviYxuvufbDT for ; Mon, 6 Oct 2014 10:49:56 -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 A97E11A872B for ; Mon, 6 Oct 2014 10:49:55 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-41-5432d641ebf9 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A3.5A.02247.146D2345; Mon, 6 Oct 2014 19:49:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 19:49:53 +0200 From: Christer Holmberg To: Robert Sparks , OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 Thread-Index: AQHP4Sitk7syhy5dEkWF18PjbgOJz5wi/wqAgABZp9A= Date: Mon, 6 Oct 2014 17:49:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46A643@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com> In-Reply-To: <5432A675.9020702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja7jNaMQg5bDRhZL+tewWVyb08hm 8fXHJjYHZo+ds+6yeyxZ8pPJY9bOJywBzFFcNimpOZllqUX6dglcGWsnvmUpmMtVsXDhDdYG xl6OLkZODgkBE4lfbW9YIGwxiQv31rN1MXJxCAkcZZRY1LSECcJZzCjRfWYmkMPBwSZgIdH9 TxukQUSgUuLCymtMILawQKbEhUmzmSDiWRKPttxjgbCtJBacm8MMYrMIqEi82nGFFcTmFfCV aLj0lQVi/gdGieYt58ESnALaErv/TwEbxAh00fdTa8BsZgFxiVtP5jNBXCogsWTPeWYIW1Ti 5eN/rBC2kkTjkiesEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQs YGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYPQe3/LbawXjwueMhRgEORiUe3oT9hiFC rIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxqcia/GO1d92u 3/j/jOXPtlPXoxMK78xYu+/rC9n9YmmSiQ+2+xr6H0/16K7gt2N5GvXZ3Kd2agtn6JaTEvtk /75ct64gny3ij0DRmwP5xiteZjnVHddq5Oh8b5cfUpY7Vf5L/cTzqf9P/f2ydcf7j82zeSd0 fGdTntk2rzlgwUo55q580XsSSizFGYmGWsxFxYkAjMDW7X8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/c50qVxvrECvRRSlMVC9nbwxtC78 Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:49:58 -0000 Hi, >>>> As a general rule, REFER request may fork. >>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>> Does this draft disallow a REFER request to be forked? >>> No. >>> >>> If the REFER forks, it will get responses from each branch of the fork. >>> The response from each branch will have its own information about=20 >>> whether the REFER was accepted on that branch, including its own=20 >>> Refer-Events-At URI. >> In accordance with the following, a successful response for REFER=20 >> request is only one. >> >> RFC3261 >> 17.1.2.1 Overview of the non-INVITE Transaction >> >> Unlike an INVITE transaction, a non-INVITE transaction has no specia= l >> handling for the 2xx response. The result is that only a single 2xx >> response to a non-INVITE is ever delivered to a UAC. >> > > Wow (slaps forehead) - very good catch. That's the whole reason the=20 > immediate NOTIFY in SIP Events exists. > > The consequences of that are going to require some time to think through. One option would to still send the immediate NOTIFY, but with the "Subscrip= tion-State" header field value set to "terminated". (But, as said earlier, for in-dialog REFERs such NOTIFY would not be needed= , as there is no forking.) Regards, Christer From nobody Mon Oct 6 12:00:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992F1A888D for ; Mon, 6 Oct 2014 12:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 3GuhryG-aDjY for ; Mon, 6 Oct 2014 12:00:15 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BC41A1A47 for ; Mon, 6 Oct 2014 12:00:13 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-06v.sys.comcast.net with comcast id zv011o00A5FMDhs01v0D7n; Mon, 06 Oct 2014 19:00:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id zv0B1o00n3Ge9ey01v0CSj; Mon, 06 Oct 2014 19:00:12 +0000 Message-ID: <5432E6BB.3010604@alum.mit.edu> Date: Mon, 06 Oct 2014 15:00:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com> In-Reply-To: <5432A675.9020702@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412622013; bh=c8YpPBoqwzOuj3Wy5+juopFbjn7LmmVC/Bkm7GwStbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=f7hJWS32pLx7H9bbks0uFchQvVJ776Wu8FTTiRMXthnmybQu8bW8R7M4fTvl7o2tO NPptozaOmV7wSOVzMUgCzW/uMcO/Q1QyPbcD8V1xHIInKhjQp8HLGI0rAo6F7hMi14 bSEaDR1kblPMl090KVuXvFvtiImuhzOsoQCLoWXbBHLzjJ75c7wwEMntBmagQtk6H8 I485UMmD26rYd/Dad4AOQlT0dfyqLW+5sZo8cYrWBym6ve0BmJy4TS0M1VdT9nVZVp XEhJX27ZZOmK4mtCviOGUhjB3XMjGRu5GkTcSXWGSo9WepFB+FOT1N/HHdZuGREbp7 LvVm9V2O7cuww== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/T8bJ8VlNXJ5hChZ37Hm05a_EH1U Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:00:16 -0000 On 10/6/14 10:25 AM, Robert Sparks wrote: > > On 10/6/14 12:44 AM, OKUMURA Shinji wrote: >> Hello Robert, >> >>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>>> Hi, >>>> >>>> As a general rule, REFER request may fork. >>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>> Does this draft disallow a REFER request to be forked? >>> No. >>> >>> If the REFER forks, it will get responses from each branch of the fork. >>> The response from each branch will have its own information about >>> whether >>> the REFER was accepted on that branch, including its own Refer-Events-At >>> URI. >> In accordance with the following, a successful response for REFER >> request is only one. >> >> RFC3261 >> 17.1.2.1 Overview of the non-INVITE Transaction >> >> Unlike an INVITE transaction, a non-INVITE transaction has no special >> handling for the 2xx response. The result is that only a single 2xx >> response to a non-INVITE is ever delivered to a UAC. > Wow (slaps forehead) - very good catch. That's the whole reason the > immediate NOTIFY > in SIP Events exists. > > The consequences of that are going to require some time to think through. One way to handle this is to: - allow multiple Refer-Events-At header fields in the response - make it the responsibility of the forking proxy to gather the responses from each fork and consolidate them into a single response. This isn't ideal. It requires the proxy to support the feature. And it means it must special case forking of REFER, since normally it can simply forward the first 2xx response it gets to a forked request. OTOH, I'll guess there is very little current use of out-of-dialog REFER. So there may not be many backward compatibility issues with that. Thanks, Paul From nobody Mon Oct 6 13:01:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503EF1A8982 for ; Mon, 6 Oct 2014 13:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 dmPyMQR0F5Gy for ; Mon, 6 Oct 2014 13:01:22 -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 E8CE11A8974 for ; Mon, 6 Oct 2014 13:01:20 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-dd-5432f50e79d1 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.17.24955.E05F2345; Mon, 6 Oct 2014 22:01:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 22:01:18 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 Thread-Index: AQHP4Sitk7syhy5dEkWF18PjbgOJz5wi/wqAgABMn4CAADKaTQ== Date: Mon, 6 Oct 2014 20:01:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com>,<5432E6BB.3010604@alum.mit.edu> In-Reply-To: <5432E6BB.3010604@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_7594FB04B1934943A5C02806D1A2204B1D46AB1AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjS7fV6MQg4bFehYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx4+cMtoJem4r/22waGH8YdTFyckgImEhc e/2UEcIWk7hwbz1bFyMXh5DAUUaJ9geNUM5iRol9G2+zdjFycLAJWEh0/9MGaRARCJS4umQC M4gtLJApcWHSbCaIeJbEoy33WCBsJ4nOS/NZQFpZBFQkHtw1BAnzCvhKrG+fwAgxfgKTxJft x9lBEpwCOhKHrvWAHcQIdND3U2vAZjILiEs0fVnJCnGogMSSPeeZIWxRiZeP/7FC1ORLLLl1 mwVigaDEyZlPWCYwCs9C0j4LSdksJGUQcQOJL+9vQ9naEssWvmaGsPUlut+fZkIWX8DIvopR tDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMHoObvmtuoPx8hvHQ4wCHIxKPLwJ+w1DhFgTy4or cw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo66+s2naFN5fr878uam0 dq/A8RvvJ5hd0tRgk3gbOHFyWPTt716XCtp1brXNfq31ykHsVfycjiep9qqT1sq4rFK4zR69 aN6R+LJLP6P7bt2ryZMw9bnTfnnTW2eFjPjuRRI5s1bzn0zbEidfk6u7Yqre/qbD5qt8Dl8Q MUpss5yxa8r/XfdOrFViKc5INNRiLipOBACJnRW4fwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9i9DXfGI4MdJgZET7O_prVs-Iwc Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:01:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D46AB1AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I don't think we shall assume support in forking proxy (why didn't we defin= e a Forking-Proxy-Require header field back in the days...). I suggested to use NOTIFY which indicates terminated. If that doesn't work, perhaps we should = disallow the mechanism in out-of-dialog REFERs. After all, the need for the= mechanism comes from in-dialog usage of REFER... Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD06/=FD10/=FD2014 22:00 To: sipcore@ietf.org Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-re= fer-explicit-subscription-01 On 10/6/14 10:25 AM, Robert Sparks wrote: > > On 10/6/14 12:44 AM, OKUMURA Shinji wrote: >> Hello Robert, >> >>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>>> Hi, >>>> >>>> As a general rule, REFER request may fork. >>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>> Does this draft disallow a REFER request to be forked? >>> No. >>> >>> If the REFER forks, it will get responses from each branch of the fork. >>> The response from each branch will have its own information about >>> whether >>> the REFER was accepted on that branch, including its own Refer-Events-A= t >>> URI. >> In accordance with the following, a successful response for REFER >> request is only one. >> >> RFC3261 >> 17.1.2.1 Overview of the non-INVITE Transaction >> >> Unlike an INVITE transaction, a non-INVITE transaction has no specia= l >> handling for the 2xx response. The result is that only a single 2xx >> response to a non-INVITE is ever delivered to a UAC. > Wow (slaps forehead) - very good catch. That's the whole reason the > immediate NOTIFY > in SIP Events exists. > > The consequences of that are going to require some time to think through. One way to handle this is to: - allow multiple Refer-Events-At header fields in the response - make it the responsibility of the forking proxy to gather the responses from each fork and consolidate them into a single response. This isn't ideal. It requires the proxy to support the feature. And it means it must special case forking of REFER, since normally it can simply forward the first 2xx response it gets to a forked request. OTOH, I'll guess there is very little current use of out-of-dialog REFER. So there may not be many backward compatibility issues with that. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D46AB1AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I don't think we shall assume support in forking proxy (why didn't we defin= e a Forking-Proxy-Require header field back in the days...).

I suggested to use
NOTIFY which indicates terminated. If that doesn't work, perhaps we should = disallow the mechanism in out-of-dialog REFERs. After all, the need for the= mechanism comes from in-dialog usage of REFER...

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD06= /=FD10/=FD2014 22:00
To: sipcore@ietf.org
Subject: Re: [= sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-s= ubscription-01

On 10/6/14 10:25 AM, Robert Sparks wrote:
>
> On 10/6/14 12:44 AM, OKUMURA Shinji wrote:
>> Hello Robert,
>>
>>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote:
>>>> Hi,
>>>>
>>>> As a general rule, REFER request may fork.
>>>> But a referrer receives only one response(i.e. Refer-Event= s-At).
>>>> Does this draft disallow a REFER request to be forked?
>>> No.
>>>
>>> If the REFER forks, it will get responses from each branch of = the fork.
>>> The response from each branch will have its own information ab= out
>>> whether
>>> the REFER was accepted on that branch, including its own Refer= -Events-At
>>> URI.
>> In accordance with the following, a successful response for REFER<= br> >> request is only one.
>>
>> RFC3261
>> 17.1.2.1 Overview of the non-INVITE Transaction
>>
>>     Unlike an INVITE transaction, a non-INVITE= transaction has no special
>>     handling for the 2xx response.  The r= esult is that only a single 2xx
>>     response to a non-INVITE is ever delivered= to a UAC.
> Wow (slaps forehead) - very good catch. That's the whole reason the > immediate NOTIFY
> in SIP Events exists.
>
> The consequences of that are going to require some time to think throu= gh.

One way to handle this is to:

- allow multiple Refer-Events-At header fields in the response
- make it the responsibility of the forking proxy to gather the
responses from each fork and consolidate them into a single response.

This isn't ideal. It requires the proxy to support the feature. And it
means it must special case forking of REFER, since normally it can
simply forward the first 2xx response it gets to a forked request.

OTOH, I'll guess there is very little current use of out-of-dialog
REFER. So there may not be many backward compatibility issues with that.
        Thanks,
        Paul

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B1D46AB1AESESSMB209erics_-- From nobody Mon Oct 6 16:01:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5E1A888F for ; Mon, 6 Oct 2014 16:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 BKxmKplGQkI4 for ; Mon, 6 Oct 2014 16:00:59 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03611A6FFA for ; Mon, 6 Oct 2014 16:00:58 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-12v.sys.comcast.net with comcast id zz0p1o0035Clt1L01z0yyt; Mon, 06 Oct 2014 23:00:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id zz0x1o00U3Ge9ey01z0xWU; Mon, 06 Oct 2014 23:00:58 +0000 Message-ID: <54331F29.2020007@alum.mit.edu> Date: Mon, 06 Oct 2014 19:00:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com>, <5432E6BB.3010604@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412636458; bh=dWpbi+0xTowT+B11Yxt9rmv3NfIvuQCSazFTBlChdVY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ut3h45rV93jFmBspgvYO4ya6GIcmf7XjvqOvHQ7erzMe4Fd+X8MYIz0RPBSV3yDXK DWoNCWuGhZyvMNy+eEbk4k2ALL1OlKXAdox6qD6XOVyt5/TugtpiIZzUTYnVyFx6OP WG8vAUzUeWyKW2JtswQdOxXEsiwPawG8Gw/vPxJvT/HcqTJ1VRVOnLYCvI1S7kd56z aQVi8roegalo0TFPeCDs1bIzMmZ73vAxZhzWM7rM77zRPXmP6nT0dOLp8lrbt68jCl VM+CIWNU1jXS7wUCfGBJFLZ7+qkDxqVXqQ0csySlF6TzOqJ0l3vanbkUqoRe/GQ7z4 ssU8afw3eC4Dg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lld-LVuQDfIreaCyN_WKIVKKqUA Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:01:00 -0000 On 10/6/14 4:01 PM, Christer Holmberg wrote: > Hi, > > I don't think we shall assume support in forking proxy (why didn't we > define a Forking-Proxy-Require header field back in the days...). > > I suggested to use > NOTIFY which indicates terminated. For an in-dialog refer, would that NOTIFY be in the existing dialog? In 3265 there is a new dialog usage for that, but a goal is to avoid that. So if it was in the dialog, then it would have to be in the INVITE dialog-usage, which would be a change. And for out-of-dialog refer, there is no dialog for the notify to travel in. Would that NOTIFY be out-of-dialog but non-dialog-establishing? That would be a bit weird. > If that doesn't work, perhaps we > should disallow the mechanism in out-of-dialog REFERs. After all, the > need for the mechanism comes from in-dialog usage of REFER... Perhaps that is possible. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý06/ý10/ý2014 22:00 > To: sipcore@ietf.org > Subject: Re: [sipcore] New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-01 > > On 10/6/14 10:25 AM, Robert Sparks wrote: >> >> On 10/6/14 12:44 AM, OKUMURA Shinji wrote: >>> Hello Robert, >>> >>>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>>>> Hi, >>>>> >>>>> As a general rule, REFER request may fork. >>>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>>> Does this draft disallow a REFER request to be forked? >>>> No. >>>> >>>> If the REFER forks, it will get responses from each branch of the fork. >>>> The response from each branch will have its own information about >>>> whether >>>> the REFER was accepted on that branch, including its own Refer-Events-At >>>> URI. >>> In accordance with the following, a successful response for REFER >>> request is only one. >>> >>> RFC3261 >>> 17.1.2.1 Overview of the non-INVITE Transaction >>> >>> Unlike an INVITE transaction, a non-INVITE transaction has no special >>> handling for the 2xx response. The result is that only a single 2xx >>> response to a non-INVITE is ever delivered to a UAC. >> Wow (slaps forehead) - very good catch. That's the whole reason the >> immediate NOTIFY >> in SIP Events exists. >> >> The consequences of that are going to require some time to think through. > > One way to handle this is to: > > - allow multiple Refer-Events-At header fields in the response > - make it the responsibility of the forking proxy to gather the > responses from each fork and consolidate them into a single response. > > This isn't ideal. It requires the proxy to support the feature. And it > means it must special case forking of REFER, since normally it can > simply forward the first 2xx response it gets to a forked request. > > OTOH, I'll guess there is very little current use of out-of-dialog > REFER. So there may not be many backward compatibility issues with that. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 6 19:30:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321F1A9117 for ; Mon, 6 Oct 2014 19:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_51=0.6, J_CHICKENPOX_71=0.6, SPF_PASS=-0.001] autolearn=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 3i7MXrBKoNK3 for ; Mon, 6 Oct 2014 19:29:58 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4239E1A9112 for ; Mon, 6 Oct 2014 19:29:58 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id y10so4198257pdj.23 for ; Mon, 06 Oct 2014 19:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=n1wgOUVR7qA6pKYOnLDRxIWdmaRfqa1Itp9qPfr860M=; b=koru5joTX7zcdB9vBFX9zQN3mvMqvpP0qfEQrUz7XVeE4N2q1+T1dv6P/jj157fcEu ACHTtvqqXpkNN6Q+JHh7soWp7acQZHkzHTOFmv0NGF8YccY89YsDNPifDAlOi/Wbx0T9 hN5S7IN7nzagkKkCILwodLTcmsLCi4Pv5aWMzAHLn7JAkF8IFHJAmbtzMRchmDAATdf9 C7Su1W60C2XjqgWIpychFKiTMgg2XF0ZWNiDR7uWFhieCWKLgNhFebt90lUY+7Kr38qr 55ATYrRCPZnDnsK6QXoltr7VmYF/s1BDoXEBQsASzRfp+muccmh9U73G+UTpkmn2f95h skwQ== X-Received: by 10.68.137.65 with SMTP id qg1mr725318pbb.116.1412648997959; Mon, 06 Oct 2014 19:29:57 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id fk10sm14767170pab.29.2014.10.06.19.29.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Oct 2014 19:29:57 -0700 (PDT) From: OKUMURA Shinji To: Brett Tate , sipcore@ietf.org Date: Tue, 07 Oct 2014 11:29:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> Message-Id: <7ECFE1D6928D51ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dC1F1_cQXb8Gx-b8cNNRqS91djQ Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 02:29:59 -0000 Hi, in the below sequence, subscriber notifier | | | SUBSCRIBE in dialog | |-------------------------------------->| dialog1 | callid:1, fromtag:a, totag:b | | | | 200 OK(SUBSCRIBE) | |<--------------------------------------| dialog1 | | | NOTIFY | |<--------------------------------------| dialog2 | callid:1, fromtag:c, totag:a | | | This NOTIFY seems to satisfy the RFC 6665 restriction(section 4.4.1). Does this NOTIFY act against accepted wisdom for SIP? >> I just come up with another approach. >> >> A referrer send REFER within an existing dialog. >> And a notifier(referee) send NOTIFY within new dialog. >> Of course Request URI of NOTIFY is a GRUU of a referrer. >> >> It seems to be a simple solution for an avoidance of dialog-reuse. >> >> I think this option(Required: subscription-newdialog?) is available >> for not only REFER but also SUBSCRIBE. > >One of the obstacles to this approach is that it would likely require an >update to RFC 6665. The NOTIFY is not really a dialog-creating method. >RFC 6665 also significantly restricted what could create a subscription; >I'm not sure that this approach would satisfy the RFC 6665 restriction. > >-brett From nobody Mon Oct 6 23:29:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610A11A1B39 for ; Mon, 6 Oct 2014 23:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 tmDPtwH4YdEB for ; Mon, 6 Oct 2014 23:29:56 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F951A014A for ; Mon, 6 Oct 2014 23:29:56 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb1so6688496pad.11 for ; Mon, 06 Oct 2014 23:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=Jb61GwrCUWrgWEm6TxXQuY6DQwRjpSyMYd9n7r8B5jE=; b=C0+W4XEqRgGQFttKiY99rjXs6YLskRKMOH/xRGscZD3/twxLW0SueykHySfMk2Cam9 SEo4tjzBaupwH+t5jg/bKmZvPq55PGsqWHY7BoKRzyf6YsHisJydeQKButMBmJmxBfvL r8C26nE783sAvJcIyb8PhnxIKkZX5J+FB/Z6tQcZ66BxrTOZzp8pfQHYJraS2lfRDA9z fzyujZ5cUv39di+wovDlZirGpHN87hcVh26enfOHvVZ7Tw1xhd5JQAIdXN5hThGwRseq QusfcYHK6+YB0RIyfcYFj3AAJqseBgYibfq6vtRV/xNXvapox+YF5LnLb3/GnZ9k59CE uDIA== X-Received: by 10.68.218.234 with SMTP id pj10mr1681514pbc.27.1412663396100; Mon, 06 Oct 2014 23:29:56 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id rb2sm15300324pab.5.2014.10.06.23.29.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Oct 2014 23:29:55 -0700 (PDT) From: OKUMURA Shinji To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Date: Tue, 07 Oct 2014 15:29:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Hb1YlUD4uNDX_Ytv6kCjApvzPkc Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 06:29:57 -0000 Hi, >I suggested to use >NOTIFY which indicates terminated. If that doesn't work, perhaps we >should disallow the mechanism in out-of-dialog REFERs. After all, >the need for the mechanism comes from in-dialog usage of REFER... Correct me if I'm wrong, would the NOTIFY transport a Refer-Events-At header? Regards, Shinji From nobody Tue Oct 7 03:29:40 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D383E1A1B7D for ; Tue, 7 Oct 2014 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_51=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 v5OUS2k12l5h for ; Tue, 7 Oct 2014 03:29:38 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D071A1B25 for ; Tue, 7 Oct 2014 03:29:37 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so4935014qgd.5 for ; Tue, 07 Oct 2014 03:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=Nju6WEl9NJL8zotnSyAG3ZEZGK9fcE88z6e80LxkCtQ=; b=fPfYSVtzCm8E6vw31494Sw5Osdmbbr9T0EOdt+xDAcU3la9MDWJntvAwwsPEmcu2te k2mTCPYUPzOlH1WH17rtNOxT0/GdjmkOjHFGQF9cIQM0UeIyU2/3Hs7rz26UYvHKYnhs 6GH8UJqthYZun7dEq/rZwVS2LLljwRYLlZSDazjUVi3qBilSugaa614w9mmTXVyTrs8U ajPsm60lKqs7KGpl5u896O5aax4LfSb+D7yW+GXVvtgwp2qCFTnrcqDy4XWoupeBJa2u z8+xMFrLr2ZiwPwTJWGl1Y6DhDrbcpGME2Iadtc8s6EQZk+OIu/r+kovyfykjNVTPG6b p97Q== X-Gm-Message-State: ALoCoQl8GM3qRE78f9UwY4xUGbHKCTdwxILgc2LV8VcZKmt8eZEsogUvQyBV+i63Vm5U7dPYJ6gv X-Received: by 10.140.19.142 with SMTP id 14mr34661701qgh.28.1412677776965; Tue, 07 Oct 2014 03:29:36 -0700 (PDT) From: Brett Tate References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> <09e19e6cf16416d0d7db7d969cde5fde@mail.gmail.com> <7ECFE1D6928D51ietf.shinji@gmail.com> In-Reply-To: <7ECFE1D6928D51ietf.shinji@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJFczc/sUgi56rfylPNQKUV9gkdwJ7RhT4AeyQ2igB0tIoUAK3X9THmmpwc6A= Date: Tue, 7 Oct 2014 06:29:36 -0400 Message-ID: <7842a70266cc3d3aa5bf3da6360e6a11@mail.gmail.com> To: OKUMURA Shinji , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/TBHSvENtYEIr7lXOE2C5d1Rh8DA Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:29:39 -0000 > subscriber notifier > | | > | SUBSCRIBE in dialog | > |-------------------------------------->| dialog1 > | callid:1, fromtag:a, totag:b | > | | > | 200 OK(SUBSCRIBE) | > |<--------------------------------------| dialog1 > | | > | NOTIFY | > |<--------------------------------------| dialog2 > | callid:1, fromtag:c, totag:a | > | | > > This NOTIFY seems to satisfy the RFC 6665 restriction(section 4.4.1). > Does this NOTIFY act against accepted wisdom for SIP? RFC 6665 section 4.2.1.2: "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY request immediately to communicate the current resource state to the subscriber. This NOTIFY request is sent on the same dialog as created by the SUBSCRIBE response." RFC 6665 section 4.4.3: "Upon receipt of this SUBSCRIBE request, the notifier (or notifiers, if the SUBSCRIBE request was forked) will send a NOTIFY request containing resource state in the same dialog." From nobody Tue Oct 7 03:56:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18D91ACD6F for ; Tue, 7 Oct 2014 03:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Wc6fbE6ngSmv for ; Tue, 7 Oct 2014 03:56:16 -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 C506C1A9150 for ; Tue, 7 Oct 2014 03:56:15 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-74-5433c6cd4653 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.69.21432.DC6C3345; Tue, 7 Oct 2014 12:56:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 12:56:13 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 Thread-Index: AQHP4Sitk7syhy5dEkWF18PjbgOJz5wi/wqAgABMn4CAADKaTYAAEKuAgADo4LA= Date: Tue, 7 Oct 2014 10:56:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46C2F2@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com>,<5432E6BB.3010604@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D46AB1A@ESESSMB209.ericsson.se> <54331F29.2020007@alum.mit.edu> In-Reply-To: <54331F29.2020007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje7ZY8YhBrcnaFis2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGx+PvmQquSlSs7ZnB1sB4SbiLkZNDQsBE Ys/V5SwQtpjEhXvr2boYuTiEBI4ySuzeMo0FwlnMKDG/YTlzFyMHB5uAhUT3P22QBhGBQImr SyYwg9jCApkSFybNZoKIZ0k82nKPBcL2k9i4oRUsziKgInH86k1GEJtXwFdiyvujzBDzvzFJ nNi9FWwQp4COxIG3bawgNiPQRd9PrQFrZhYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwphK0pc nb4cqt5A4tz2jewQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uT ctONjPRSizKTi4vz8/TyUks2MQIj5eCW3wY7GF8+dzzEKMDBqMTDq+BpHCLEmlhWXJl7iFGa g0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhglGJh+3RMW+7fr3KUjqQLTdE8m mCnMPT/H7NLKpm9te1ZJPnB+vFpD+K9l9ny73itf/nc1Pdg9z+SertcsNqmARbqtnLwaCTPV HkS6x1f99d59RsOLd1sny68jnK77VkU/vb1hhdLUT/ckb/5vSl572aD+in1mxJeJHj/f7Xq8 Yd5t7YnO7Tk+SizFGYmGWsxFxYkABnthunUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/67lOwixY4joiqlWMv3vx-UI-7bU Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:56:18 -0000 Hi, >> I don't think we shall assume support in forking proxy (why didn't we=20 >> define a Forking-Proxy-Require header field back in the days...). >> >> I suggested to use >> NOTIFY which indicates terminated. > > For an in-dialog refer, would that NOTIFY be in the existing dialog? In > 3265 there is a new dialog usage for that, but a goal is to avoid that.=20 > So if it was in the dialog, then it would have to be in the INVITE dialog= -usage, which would be a change. The NOTIFY would only be sent in the out-of-dialog case. For in-dialog ther= e is no need for the NOTIFY. > And for out-of-dialog refer, there is no dialog for the notify to travel = in. Would that NOTIFY be out-of-dialog but non-dialog-establishing? That wo= uld be a bit weird. Correct, when I think about it... Regards, Christer > From: Paul Kyzivat > Sent: =FD06/=FD10/=FD2014 22:00 > To: sipcore@ietf.org > Subject: Re: [sipcore] New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-01 > > On 10/6/14 10:25 AM, Robert Sparks wrote: >> >> On 10/6/14 12:44 AM, OKUMURA Shinji wrote: >>> Hello Robert, >>> >>>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote: >>>>> Hi, >>>>> >>>>> As a general rule, REFER request may fork. >>>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>>> Does this draft disallow a REFER request to be forked? >>>> No. >>>> >>>> If the REFER forks, it will get responses from each branch of the fork= . >>>> The response from each branch will have its own information about=20 >>>> whether the REFER was accepted on that branch, including its own=20 >>>> Refer-Events-At URI. >>> In accordance with the following, a successful response for REFER=20 >>> request is only one. >>> >>> RFC3261 >>> 17.1.2.1 Overview of the non-INVITE Transaction >>> >>> Unlike an INVITE transaction, a non-INVITE transaction has no speci= al >>> handling for the 2xx response. The result is that only a single 2x= x >>> response to a non-INVITE is ever delivered to a UAC. >> Wow (slaps forehead) - very good catch. That's the whole reason the=20 >> immediate NOTIFY in SIP Events exists. >> >> The consequences of that are going to require some time to think through= . > > One way to handle this is to: > > - allow multiple Refer-Events-At header fields in the response > - make it the responsibility of the forking proxy to gather the=20 > responses from each fork and consolidate them into a single response. > > This isn't ideal. It requires the proxy to support the feature. And it=20 > means it must special case forking of REFER, since normally it can=20 > simply forward the first 2xx response it gets to a forked request. > > OTOH, I'll guess there is very little current use of out-of-dialog=20 > REFER. So there may not be many backward compatibility issues with that. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Oct 7 04:07:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254E31A1B9E for ; Tue, 7 Oct 2014 04:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 i_BQg1fU3zsH for ; Tue, 7 Oct 2014 04:06:57 -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 62B4A1A9155 for ; Tue, 7 Oct 2014 04:06:57 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-fd-5433c94ff9f6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.4A.24955.F49C3345; Tue, 7 Oct 2014 13:06:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 13:06:54 +0200 From: Christer Holmberg To: Robert Sparks , OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 Thread-Index: AQHP4Sitk7syhy5dEkWF18PjbgOJz5wi/wqAgAF7ywA= Date: Tue, 7 Oct 2014 11:06:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46C34E@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <21CFDEE5BE1BABietf.shinji@gmail.com> <542E62B6.8010309@nostrum.com> <52CFE128A63254ietf.shinji@gmail.com> <5432A675.9020702@nostrum.com> In-Reply-To: <5432A675.9020702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja7/SeMQg+/zFSyW9K9hs7g2p5HN 4uuPTWwOzB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mppu/GQpWMRdsejfGpYG xjccXYwcHBICJhJTZxp2MXICmWISF+6tZ+ti5OIQEjjKKHHy/FE2kISQwGJGiQ/ddSD1bAIW Et3/tEHCIgKVEhdWXmMCsYUFMiUuTJrNBBHPkni05R4LhG0lcaPjPtgYFgEViXOnX4LV8Ar4 Svzdu48VYtcHRonmLedZQRKcAtoSu/9PAStiBDro+6k1YDazgLjErSfzmSAOFZBYsuc8M4Qt KvHy8T9WCFtR4ur05VD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0 LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGDkHt/xW3cF4+Y3jIUYBDkYlHl4FT+MQ IdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Nt6UzzzzR2/ xatNqvNnhVY3fLswrT8qbO7ymi+PNk3etMpvIfMPBgO9q6pWc9if+0Qe0zoo9ufzhYf+C4Qu vM234GmNO2eu5fCTSTHjpGV/36nnP2+bT5kt+aNuz105v59LNfvjzta5qz0000u9xTvnY3Hz KeU5LaoqAaxZK6PlEqcFrV2dqsRSnJFoqMVcVJwIAE080x99AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0EshEH2Ix4cCycqVrF25oaYiyTU Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:07:00 -0000 Hi, >>>> As a general rule, REFER request may fork. >>>> But a referrer receives only one response(i.e. Refer-Events-At). >>>> Does this draft disallow a REFER request to be forked? >>> No. >>> >>> If the REFER forks, it will get responses from each branch of the fork. >>> The response from each branch will have its own information about=20 >>> whether the REFER was accepted on that branch, including its own=20 >>> Refer-Events-At URI. >> In accordance with the following, a successful response for REFER=20 >> request is only one. >> >> RFC3261 >> 17.1.2.1 Overview of the non-INVITE Transaction >> >> Unlike an INVITE transaction, a non-INVITE transaction has no specia= l >> handling for the 2xx response. The result is that only a single 2xx >> response to a non-INVITE is ever delivered to a UAC. >Wow (slaps forehead) - very good catch. That's the whole reason the immedi= ate NOTIFY in SIP Events exists. > >The consequences of that are going to require some time to think through. I was checking RFC 4488, because you have the same issue there if the immed= iate NOTIFY is not sent. RFC 4488 "solves" the problem with the following statement: "The "Refer-Sub" header field set to "false" MAY be used by the REFER- Issuer only when the REFER-Issuer can be certain that the REFER request will not be forked." So, perhaps we could do the same. Regards. Christer From nobody Tue Oct 7 13:46:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618261A885F for ; Tue, 7 Oct 2014 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 ocLoQ4Hg-h0B for ; Tue, 7 Oct 2014 13:46:25 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E841A874E for ; Tue, 7 Oct 2014 13:46:24 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so7224208lab.33 for ; Tue, 07 Oct 2014 13:46:23 -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:content-type; bh=K+iOeZdI0IEr3rcR4jZitDLnRl5RtTxYTEZRUcGHmNw=; b=X/fMRY3xhrd//uoaXeWnLTJ8LE2xkoNBY8VFZMdW7XQvyYusVBsUd9XUmSXhOA+WmJ 0oRuwnf1BhSnRNneElYwTp8pCWbwBY8W57A647dQKz2SK1NG7OMp+cghJHCZygxN3v/M lLt7YWNC0/SyvvBd/2PreKkzQOfdGY7xAHYbGY1SvPETHu/n7kNKzqAW5n/psyvhSb2+ Uwwofr8Y/fmRNpSFg4id0r20i5myYC15Bo4fdCfkQ088HE0ZJVWBFE0m2IzUuYzy/nfM HF2pMr2fRhPaC3AY8hbW/y/D9ei3XpxrDtZ1HMDUaYZrL5Po6OugA0NNoGyxiyJ9eRRx Oe5Q== MIME-Version: 1.0 X-Received: by 10.112.135.230 with SMTP id pv6mr5682959lbb.105.1412714782926; Tue, 07 Oct 2014 13:46:22 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Tue, 7 Oct 2014 13:46:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> Date: Tue, 7 Oct 2014 16:46:22 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0117716fce2ddb0504db4a94 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_42XIXNh8m3ITeTRLIgasIal5BM Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:46:30 -0000 --089e0117716fce2ddb0504db4a94 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, I am not clear on the flow of messages in your case. Can you please provide a high level diagram that describes that flow? Also, the token that is returned by the WAF to the SIP endpoint; is it an access token, as per OAuth 2.0, or a user token (ID Token), as per OpenID? Thanks, Rifaat On Thu, Sep 25, 2014 at 11:34 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >What I am proposing is something along the lines of OpenID, which > extends the OAuth to >authenticate the *user*. > > >In this case, the mapping between OAuth and SIP would be something like > the following: > > > > > >OAuth SIP > > > > --------------------------------------------------------------------------- > > >Resource Owner End User > > >Resource Server SIP Proxy or SIP Application Server > > >Client SIP UA > > >Authorization Server Authorization Server > > > > > >Do you see a problem with this model? > > > > As I indicated earlier, this is a little different mapping than the one > done by 3GPP. > > > > *OAuth role IMS role* > > > > Resource Owner IMS subscriber > > Client WWSF > > Authorization Server WAF > > Resource Server IMS network > > > > (copied text) > > > > WWSF (WebRTC Web Server Function) > > - Acts as web server, from where the user downloads the IMS > access application. > > WAF (WebRTC Authorisation Function) > > - Acts as the authorization server (the "facebook"), and issues > the authorization tokens. > > > > (The WWSF and WAF can, but does not have to, be located in the same domain > as the IMS provider.) > > > > I guess the important thing to note here is that the IMS core network > (including the registrar/S-CSCF and HSS) does not act as Authorization > Server, but rather as the Resource Server. > > > > In fact, the IMS core network itself does not even need to support > OAuth2.0. Instead the WAF performs mapping and verification between "legacy > IMS credentials" and "web credentials" (e.g. OAuth2.0). The detailed > procedures for that mapping/verification is not specified in the current > 3GPP release. > > > > Regards, > > > > Christer > > > > > > > --089e0117716fce2ddb0504db4a94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,

I am not clear on the flow= of messages in your case. 
Can you please provide a high le= vel diagram that describes that flow?

Also, the to= ken that is returned by the WAF to the SIP endpoint; is it an access token,= as per OAuth 2.0, or a user token (ID Token), as per OpenID?
Thanks,
 Rifaat



On Thu, = Sep 25, 2014 at 11:34 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi,<= /p>

 

>What I am p= roposing is something along the lines of OpenID, which extends the OAuth to >authenticate the *user*.=

>In this cas= e, the mapping between OAuth and SIP would be something like the following:=

>&nbs= p;

>OAuth  = ;                     &nb= sp;            SIP

>-----------= ----------------------------------------------------------------<= /u>

>Resource Ow= ner                    En= d User

>Resource Se= rver                    S= IP Proxy or SIP Application Server

>Client &nbs= p;                     &n= bsp;             SIP UA

>Authorizati= on Server             Authorization Server=

>&nbs= p;

>Do you see = a problem with this model?

 

As I indicated earlier, t= his is a little different mapping than the one done by 3GPP.<= /span>

 

OAuth role  =             &nb= sp;            =           IMS role

 

Resource Owner  = ;            &n= bsp;            IMS = subscriber

Client   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      WWSF

Authorization Server = ;            &n= bsp;      WAF

Resource Server &nbs= p;            &= nbsp;           &nbs= p; IMS network

 

(copied text)

 

WWSF (WebRTC Web Server Function)

-&nb= sp;         Acts as web server, from where the user downloads the = IMS access application.

WAF (WebRTC Authorisation Function)

-&nb= sp;         Acts as the authorization server (the “facebook&= rdquo;), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be loca= ted in the same domain as the IMS provider.)

 

I guess the important thing to note here is that the= IMS core network (including the registrar/S-CSCF and HSS) does not act as = Authorization Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even n= eed to support OAuth2.0. Instead the WAF performs mapping and verification = between “legacy IMS credentials” and “web credentials&rdq= uo; (e.g. OAuth2.0). The detailed procedures for that mapping/verification is not specified in the current 3GPP release.

 

Regards,

 

Christer

 

 

 


--089e0117716fce2ddb0504db4a94-- From nobody Tue Oct 7 16:01:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1FA1A8A4F for ; Tue, 7 Oct 2014 16:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.067 X-Spam-Level: X-Spam-Status: No, score=-99.067 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 v6A4JaSR2Elz for ; Tue, 7 Oct 2014 16:01:48 -0700 (PDT) Received: from mx0a-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 547461A86F9 for ; Tue, 7 Oct 2014 16:01:48 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s97MoCNK010230; Tue, 7 Oct 2014 19:01:44 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1pvnq90ed5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Oct 2014 19:01:43 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Tue, 7 Oct 2014 19:01:41 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLmZYbTlD+FuE+zMNKWASQKqZvhvfeAgAAwjgCADcUOgIABvEuAgAAP2QCADliiAIACroIAgAMzZQCAH5scAA== Date: Tue, 7 Oct 2014 23:01:41 +0000 Message-ID: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.128.186] Content-Type: multipart/alternative; boundary="_000_D059A86A134723jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7584 signatures=670543 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=9.76996261670138e-15 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410070214 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/5kR5NzlCeQpbdw_QOuMhwkJ-rCE Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 23:01:55 -0000 --_000_D059A86A134723jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know I've owed you a response to this one for a while... Still just tryin= g to understand the requirements. I suspect that application services in the enterprise, the ones that you wo= rry about maintaining ACLs, don't get to avoid having "a separate user dire= ctory" so easily. A classic voicemail service, for example, needs to keep v= oicemails for Alice separate from Bob - that's why typically it authenticat= es who Alice and Bob are. Such a service must have effectively a "directory= " of separate users that effectively implies ACLs. Now if, as you say: > The application server needs the following pieces of information about ea= ch user: > 1. ID and credentials > 2. User profile to control the level of service provided to the user. What is your app server using that ID and credentials for, if not to compar= e to something that is effectively an ACL - like, to prevent Alice from get= ting Bob's voicemail? My point earlier was that if all you care about is sh= owing that someone is Alice or Bob (or just that they're an authenticated u= ser and it doesn't matter who), then a solution to the requirements could l= ook very similar to RFC4474 or STIR: you just need authentication, not auth= orization, and calling it authorization is just confusing the issue. But, there's a different approach here, one where a service doesn't need to= know IDs or credentials or anything about users. This is an approach where= I just get a token from an authorization service, and hand that token to t= he app service, and the app service uses that token *instead of* my ID or c= redentials or any personal profile about me. I can imagine a very odd voice= mail service that, rather than putting messages into buckets for Alice and = Bob, put them all into one generic bucket - and then an outside authorizati= on service kept track of the fact that messages 2, 17, and 109 are for Alic= e. When Alice requests access to her voicemail from the authorization servi= ce, it gives her a token that proves to the voicemail service that she is a= llowed to access only messages 2, 17, and 109, and she can only do it in th= e next five minutes, say, to prevent capture and replay. The voicemail serv= ice then has no idea who she is or who those messages are for, it just poni= es them up. If *that* is what you said above, at least I would understand w= hy you want to use OAuth - it would be a terrible architecture (the authZ s= ervice keeps track of those messages how exactly?), but at least this is wh= at OAuth is for. The architectures make more sense with third parties. A third approach would be problems we looked at as "trait-based" authorizat= ion problems. The classic example is where for some service, perhaps it mat= ters whether Alice is in the Engineering department or the Finance departme= nt, rather than who Alice is exactly. Maybe those're the sort of elements y= ou mean by "user profile." We did a whole requirements process years ago on= "trait-based" authorization mechanisms intended to satisfy cases like this= : see RFC4484. You'll note it shows architectures where a SIP endpoints poi= nt by-reference to HTTP objects that contain authorization policy elements = like such "traits." There are a bunch of solutions for that space, too, but= if that's what you want, then my question for you would be, do you have an= y requirements beyond what's defined in RFC4484 Sec. 5? Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Wednesday, September 17, 2014 at 6:22 AM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon > wrote: Format snags aside, I copied that text from a different editor. The format seems ok here: http://www.ietf.org/mail-archive/web/sipcore/current/msg06258.html So, it might be something on your side? I have a bit of difficulty even differentiating the issues listed below: su= rely the reason why enterprises assign multiple identities per user is to a= uthorize access to different services separately. Sorry, I do not get that. Why would the enterprise be required to create multiple identities to allow= access to different services separately? in other words, why cannot the en= terprise create one identity and still be able to control the user's access= to different services provided by different servers? This is an issue that could be resolved with an access control list per ser= vice and a trusted identity broker in the enterprise vouching for user iden= tities to these services. But that means that each server that provides a service must maintain a sep= arate user directory, which is exactly what I am trying to avoid. But to convince ourselves that one approach to this is better than another,= we need to look at a level of detail below these issue descriptions. Again= , in order to access a voicemail service in an enterprise, say, what does t= he voicemail service need to know about the user? Like, for regular access to the voicemail for "jon@enterprise," surely all = the voicemail service needs to know is that the entity authoritative for th= e @enterprise issued me the name "jon." Maybe the "admin" account gets to a= ccess all the voicemails, if need be. The application server needs the following pieces of information about each= user: 1. ID and credentials 2. User profile to control the level of service provided to the user. You cannot assume that all users will get the same level of service. There are a variety of mechanisms that suffice to prove simple identities l= ike that to a service. Can you elaborate? Are you assuming that the service still have a separate user directory? If, however, I as "jon" needed for a third-party transcription service to a= ccess a subset of the messages in my voicemail box, and I wanted the permis= sions for that access to expire as soon as the messages had been transcribe= d, then there is a much narrower set of mechanisms that could provide that = capability. You keep going back to the OAuth 2.0 model and try to impose it on SIP, whi= ch would work in some use cases. What I am proposing is something along the lines of OpenID, which extends t= he OAuth to authenticate the *user*. In this case, the mapping between OAuth and SIP would be something like the= following: OAuth SIP --------------------------------------------------------------------------- Resource Owner End User Resource Server SIP Proxy or SIP Application Server Client SIP UA Authorization Server Authorization Server Do you see a problem with this model? But it sounds to me, from this issues list, like your requirements are more= along the former lines than the latter. Actually, it is both. Here is an example of a use case that fits with the OAuth 2.0 model: An Application Server that provides Mobile Clients with access to SIP servi= ces. The Mobile Client uses a proprietary protocol to communicate with the Appli= cation Server that registers and gets service from the SIP network on behal= f of the user that is using the Mobile Client. The communication channels between the players in this case are as follows = (hopefully the format is ok this time): [Mobile Client] <-----------> [Application Server] <-----------> [SIP Pro= xy] /\ /\ | | | \/ ------------------------> [Authorization Server] In this case, the mapping between OAuth and SIP would be something like the= following: OAuth SIP --------------------------------------------------------------------------- Resource Owner End User Resource Server SIP Proxy Client Application Server (providing se= rvice to the mobile client) Authorization Server Authorization Server Regards, Rifaat Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Saturday, September 13, 2014 at 12:32 PM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon > wrote: I understand that OAuth can be altered from its basic flows to provide toke= ns for OpenID, and IdP could be bound to OAuth, and while this is all very = interesting it doesn't change much about the requirements discussion I thin= k we need to have: the one about what kinds of use cases we want to satisfy= and who the relying parties are in those cases. Once we understand that, w= e will understand what tools are applicable to these use cases - preferably= , not tools that need to be twisted into a different shape to be applicable= . Well, OpenID extends the OAuth 2.0 Framework to authenticate the user; why = do you think it is "twisting" OAuth into a different shape? It would helpful, in the enterprise SSO case, for us to understand what kin= ds of application servers a user might need to access, and what exactly tho= se application servers need to know about the user in order to accomplish t= heir function. Below is a description for some enterprise issues, that hopefully will be a= ddressed by a new authorization framework: * Multiple Identities One of the major issues in the enterprise is the need= for a user to obtain multiple uncorrelated identities associated with diff= erent products to get access to the various services provided by the enterp= rise. For example, in the enterprise the user will be provided with differe= nt identities to: o Login his device (PC, laptop, mobile, ...) to the netwo= rk. o Register to the SIP network and get basic SIP services. o Access his = Voice Mail. o Host a conference. o etc Typically, these identities belong t= o different administrative domains and realms. Instead of these multiple id= entities, ideally the enterprise would like to create and maintain only one= identity for the user and then allow the user access to all SIP and non-SI= P services using that one identity. * Authorization of Access to Services A= nother issue in the enterprise is the need to control and authorize a user = access to services. Because application servers have their own user directo= ry, the control of access to services is spread over a multitude of servers= in the network. Ideally, the enterprise would like to manage the access to= services using one centralized entity and for the various entities that pr= ovide the service to become the enforcement points. * Assignment of Service= s In the enterprise, different users might be assigned to different servers= providing a specific service; e.g. Voice Mail Box for different users migh= t be hosted by different servers, and the user need to know his assigned se= rver to be able to get access to this service. * Application Servers To be = able to provide service, the application server needs a list of users allow= ed to get services. The application server needs the following pieces of in= formation about each user: 1. User ID and Credentials 2. Profile to control= the level of service provided to the user. If one application server provi= des different services using different protocols, the application server mi= ght need to maintain different identities associated with these protocols; = e.g. an application server that provides presence service using SIP, and IM= service using XMPP. Ideally, an authorization framework would: 1. Off load= the application server from the need to manage the user credentials and au= thenticating the user. 2. Off load the application server from the need to = maintain the users and their profiles to control the level of service provi= ded to the user. 3. Allow the assignment of a user to a specific applicatio= n server. * OAuth/OpenID Model With the OAuth/OpenID framework, the user ID= and credentials will be handled by the authorization server, and the appli= cation server assignment and the level of service associated with the user = will be provided in the scope of the token associated with the user. When t= he application server receives a request from a user it will have all the d= etails that would allow the application server to validate the request to m= ake sure it is coming from the right authorization server, and to act upon = the request because it has the scope associated with the user, without the = need to contact the authorization server. * Relying Party Regarding the Rel= ying Party question: I think that when the user is being authenticated, tha= t the Relying Party would be the SIP Client that would be given a user toke= n (ID Token in OpenID lingo) to access services on behalf of the end user. = So, the mapping would be something like this: +------------------------+---= --------------------------+ | OAuth | SIP | +------------------------+-----= ------------------------+ | Resource Owner | End User | | Resource Server |= SIP Proxy or SIP App Server | | Client | SIP UA (Relying Party) | | Author= ization Server | Authorization Server | +------------------------+---------= --------------------+ Regards, Rifaat Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, September 4, 2014 at 8:31 AM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon > wrote: While I would echo Paul's thoughts below about the plausibility of service providers using this model to authorize recording, I also agree that third-party recording is an excellent example of a service architecture that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain constraints, and coordinate the association between the third party and the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs. I agree with that. Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think you need OAuth for that. If you assume that there is one server that provides all the services, then= you are right. But that is not the case all the time. I think that Dale articulated that c= learly in the following response: http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html I do understand that OAuth 2.0 is used in the wild for SSO, though I sympathize with Matt that the base flow shown in RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. I agree that the OAuth 2.0 "as is" does not address the SSO requirements. The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is exten= ding the framework to authenticate and provide a *user* specific token. Since Matt mentioned OpenID few times, I looked at the OpenID specification= . What they are doing there is that they defined a new token, called ID Token= , that is associated with the *user*; which is exactly what the SIP OAuth p= roposal is doing. http://openid.net/specs/openid-connect-core-1_0.html#IDToken My plan is to use the same terminology, ID Token, in the next version of th= e SIP OAuth document to clarify that, and to differentiate it from the acce= ss token. I think, though, we might usefully break uses cases here down by who the intended relying party is: - The user's own SIP service provider (my enterprise, my carrier, my OTT provider) - A third party that a user wants to authorize for a service (recording service... But anything else?) I would also append some use cases where the relying party: - Someone with no association with the user (caller ID sorts of cases) This last is where I've argued things like IdP might be relevant. EKR has a nice description for binding IdP to OAuth in his WebRTC Security = Architecture document here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 We could use the same idea for SIP. Regards, Rifaat Are there any other high-level buckets of use cases here? Jon Peterson Neustar, Inc. On 8/25/14, 11:44 AM, "Paul Kyzivat" > wrote: >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> Hi Matt, >> >> The use case and the solution provided assumes that the VoIP Provider >> makes the decision on when and what to record. >> While this is a valid use case, there are other use cases that allow the >> user to decide on when and what to record; take a look at RFC6341 for >> more info. >> http://datatracker.ietf.org/doc/rfc6341/ > >SIPREC supports numerous topologies. >It would support the one that Matt outlines as well as end-user >controlled ones. > >I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added >revenue market, that they are loath to do. The most likely justification >I can imagine that they don't want to legal consequences of doing >recording. > > Thanks, > Paul > >> For these use cases, where the user is in control, you need to away to >> authenticate and control which users are allowed to record and the level >> of service provided for that specific user. >> This is where the solutions provided in section 3 or section 4 of the >> SIP OAuth proposal come into play. >> Obviously, in this case the authorization server is different from >> authorization server used to establish the trust relationship between >> the VoIP Provider and the CRS Provider. >> In this case, the authorization server must authenticate the user and >> provide his UA with an access token or a code that controls the user's >> access to the service. >> >> Regards, >> Rifaat >> >> >> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >> >> wrote: >> >> Included is the use case I spoke of before. My apologies for the >>delay. >> >> This is written as though it could be included in >> [draft-yusef-sipcore-sip-oauth] at section 6. >> >> >> 6. Examples >> >> 6.1. Example: Call Recording Service >> >> This example illustrates the use of SIP OAuth between three >> parties: A hosted VoIP service provider, a Call Recording Service >> provider, and a phone system end-user. In this example: >> - The phone system end-user is a customer of both the hosted VoIP >> provider and the Call Recording Service provider >> - The hosted VoIP service provider is a standard provider of hosted >> business-class VoIP telephone service using SIP >> - The Call Recording Service provider is a distinct entity from the >> hosted VoIP provider >> >> The Call Recording Service provides to customers both the call >> recording abilities and management of call recordings >> (configuration, sharing and distribution, retention, etc.). This >> service can accept and record RTP traffic, associate all RTP streams >> with a single call together, and store and catalog the recorded data >> for future searching and retrieval. The service also offers a web >> interface where customers may view and retrieve stored calls. >> Stored calls may range from simple person-to-person voice calls to >> multi-party conferences with a multitude of audio and video >> streams. In this example, customers are billed based on the amount >> of data they store, although other models are certainly possible. >> >> 6.1.1. OAuth 2.0 Roles >> >> In this example, each party assumes the following OAuth 2.0 roles as >> defined in [RFC6749] Section 1.1: >> - The end-user assumes the role of resource owner >> - The hosted VoIP service provider assumes the role of client >> - The Call Recording Service provider assumes the role of resource >> server as well as the role of authorization server >> >> 6.1.2. Description >> >> There are two parts to the example: Initial configuration and >> real-time recording authorization. >> >> Each section includes a simplified flow diagram for the purpose of >> describing the corresponding portion of the example. For the sake >> of brevity, certain parts of the OAuth dialog have been eliminated. >> Implements should refer to [RFC6749] for details on OAuth. >> >> 6.1.2.1 Initial Configuration >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | Web Browser | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | HTTP 1 | | >> | (Configure CRS) | | >> |------------------->| | >> | | | >> | HTTP 2 | | >> | (OAuth Redirect | | >> | to CRS Website) | | >> |<-------------------| | >> | | | >> | HTTP 3 | | >> | (Authorize SIP from VoIP provider | >> |----------------------------------------->| >> | | | >> | HTTP 4 | | >> | (OAuth Redirect back to VoIP portal) | >> |<-----------------------------------------| >> | | | >> | HTTP 5 | | >> |------------------->| | >> | | HTTP 6 | >> | | (Request Access and | >> | | refresh tokens) | >> | |-------------------->| >> | | | >> >> Some time after having signed up for both services, but prior to >> attempting to record any calls, the end-user logs into the web >> portal of the hosted VoIP provider with a web browser and configures >> their call recording service (HTTP 1). This configuration includes >> providing a URI where the call recording service may be reached, >> along with a set of API credentials, provided by the call recording >> service, which will allow the client to initiate an OAuth exchange. >> The end-user also configures the conditions under which call >> recordings should take place. For example, the end-user may request >> to record every multi-party (conference) call, or every call >> involving a specific set of users. The end-user may also specify >> other restrictions, such as restricting codec negotiation to G.711u >> for audio and H.264 for video in order to record the RTP streams. >> Once the end-user saves the configuration, the hosted VoIP provider >> web portal redirects the end-user's web browser to the call >> recording service website and a standard HTTP OAuth dialog begins >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >> access (i.e. send SIP and RTP traffic to) the call recording >> service, for the purpose of recording calls, so long as the >> configured conditions are met (HTTP 3). The result of this >> interaction is that the hosted VoIP provider ends up receiving an >> OAuth access token and refresh token from the call recording service >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's >> hosted VoIP account database. >> >> 6.1.2.2 Real-time Recording Authorization >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | SIP Phone | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | SIP INVITE 1 | | >> |------------------->| | >> | | SIP INVITE 2 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 401 Unauthorized | >> | |<---------------------| >> | | | >> | | SIP INVITE 3 | >> | | (with refresh token) | >> | |--------------------->| >> | | | >> | | SIP 200 1 | >> | | (new access token) | >> | |<---------------------| >> | | | >> | | SIP INVITE 4 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 200 2 | >> | |<---------------------| >> | | | >> >> Independently of and after the initial configuration phase, the >> end-user makes a telephone call using the hosted VoIP provider (SIP >> INVITE 1). When this call takes place, the hosted VoIP provider >> looks to see whether it believes this call should be recorded. If >> so, at this point it would branch the call session to the call >> recording service, using SIP OAuth to pass the previously provided >> access token for authorization (SIP INVITE 2). Once the access >> token is validated by the call recording service (perhaps after >> first providing a new access token based on receipt of a valid >> refresh token), the call recording service will check the rights >> that were previously authorized and examine the SIP to determine >> whether it can accept the call. If so, it completes the >> establishment of the session and begins receiving and recording the >> RTP stream(s) (SIP 200 OK). The call recording service provider >> could also deny the request, either because the tokens are invalid >> or because the content of >> the SIP invite does not match the previously authorized >> conditions, in which case a SIP 403 would be returned by the call >> recording service provider and the call would not be recorded - >> however, the initial call branch would continue without >>interruption. >> >> Note: >> [RFC6749] specifies that when a client uses a refresh token to >> request a new access token, the response is HTTP 200 with the new >> access token and optionally a new refresh token included in the >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >> which contains the new token(s). However, this could be confusing >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> which is not what is happening in this case. Should SIP 200 be used >> for consistency, or should another mechanism be used? >> >> 6.1.3. Justification >> >> 6.1.3.1. Hosted VoIP Service Provider >> >> In this example, the hosted VoIP service provider can allow their >> customers to enable call recording in their VoIP service by >> selecting from any of a number of supported call recording service >> providers. This allows the hosted VoIP service provider to offer >> this feature to customers without requiring that the hosted VoIP >> service provider implement and support this feature themselves. >> >> 6.1.3.2. Call Recording Service Provider >> >> In this example, the Call Recording Service provider can focus on >> value and innovation in the area of recording calls and managing >> recorded calls without having to build a full-featured telephony >> offering. >> >> 6.1.3.3. Customer >> >> In this example, the customer has more flexibility in choosing a >> complete solution that meets all of the customer needs. The >> customer does not have to settle for a substandard call recording >> service offering in order to obtain other features they seek in a >> hosted VoIP provider, and vice versa. >> >> 6.1.4. Variants >> >> A simple variant of this example is one wherein one of the services >> (either the VoIP service or the call recording service) is managed >> directly by the end-user, but the other is not. For example, the >> end-user may wish to make use of an external hosted VoIP service >> provider, but may have business or legal reasons that forbid the >> end-user from allowing a third party to store and manage recorded >> calls. The end-user could choose to set up their own call recording >> service as described in this example, and use SIP OAuth to >> facilitate interaction between the hosted VoIP service and the >> end-user's own call recording service. >> >> 6.2. Other SIP OAuth examples >> >> Many other SIP-based services could leverage SIP OAuth to provide >> value-added service to an end-user of a hosted VoIP service >> provider. Some examples of these types of services are listed >>below. >> >> Voicemail service provider: The end-user configures their hosted >> VoIP service provider to manage voicemail through a separate >> voicemail service provider, which chooses whether to store voicemail >> based on existing quotas, Caller ID, etc. >> >> Conferencing service provider: A conferencing service may wish to >> bill customers in a more granular fashion, for example, based on the >> number of participants and attendees in a conference, the duration >> of conference, whether video was also included, which codecs were >> being used, etc. instead of a flat monthly rate. SIP OAuth would >> facilitate metered authorization for a client's use of the service, >> instead of all-or-nothing access. >> >> Call center service provider: A third party may provide ring groups >> or call queues for a hosted VoIP provider along with detailed >> reports and dashboards. The end-user uses OAuth over SIP to control >> who can log into which queues or ring groups, etc. >> >> >> >> -- >> Matt Ryan >> code slinger | zoomulus.com >> ietf at mvryan dot org >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_D059A86A134723jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <16D85952C4D8434CBB1673A7C951F889@neustar.biz> Content-Transfer-Encoding: quoted-printable

I know I've owed you a response to this one for a while... Still just = trying to understand the requirements.

I suspect that application services in the enterprise, the ones that y= ou worry about maintaining ACLs, don't get to avoid having "a separate= user directory" so easily. A classic voicemail service, for example, = needs to keep voicemails for Alice separate from Bob - that's why typically it authenticates who Alice and Bob are. Su= ch a service must have effectively a "directory" of separate user= s that effectively implies ACLs.

Now if, as you say:

> The application server needs the following pieces of information = about each user:
> 1. ID and credentials
> 2. User profile to control the level of service provided to the u= ser.

What is your app server using that ID and credentials for, if not to c= ompare to something that is effectively an ACL - like, to prevent Alice fro= m getting Bob's voicemail? My point earlier was that if all you care about = is showing that someone is Alice or Bob (or just that they're an authenticated user and it doesn't matter w= ho), then a solution to the requirements could look very similar to RFC4474= or STIR: you just need authentication, not authorization, and calling it a= uthorization is just confusing the issue.

But, there's a different approach here, one where a service doesn't ne= ed to know IDs or credentials or anything about users. This is an approach = where I just get a token from an authorization service, and hand that token= to the app service, and the app service uses that token *instead of* my ID or credentials or any personal = profile about me. I can imagine a very odd voicemail service that, rather t= han putting messages into buckets for Alice and Bob, put them all into one = generic bucket - and then an outside authorization service kept track of the fact that messages 2, 17, and 109 = are for Alice. When Alice requests access to her voicemail from the authori= zation service, it gives her a token that proves to the voicemail service t= hat she is allowed to access only messages 2, 17, and 109, and she can only do it in the next five minutes, = say, to prevent capture and replay. The voicemail service then has no idea = who she is or who those messages are for, it just ponies them up. If *that*= is what you said above, at least I would understand why you want to use OAuth - it would be a terrible arch= itecture (the authZ service keeps track of those messages how exactly?), bu= t at least this is what OAuth is for. The architectures make more sense wit= h third parties.

A third approach would be problems we looked at as "trait-based&q= uot; authorization problems. The classic example is where for some service,= perhaps it matters whether Alice is in the Engineering department or the F= inance department, rather than who Alice is exactly. Maybe those're the sort of elements you mean by "user profil= e." We did a whole requirements process years ago on "trait-based= " authorization mechanisms intended to satisfy cases like this: see RF= C4484. You'll note it shows architectures where a SIP endpoints point by-reference to HTTP objects that contain authorization po= licy elements like such "traits." There are a bunch of solutions = for that space, too, but if that's what you want, then my question for you = would be, do you have any requirements beyond what's defined in RFC4484 Sec. 5?

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Wednesday, September 17, 2014= at 6:22 AM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] A SIP OAuth = use case



On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:

Format snags aside,

I copied that text from a different editor.
The format seems ok here:

So, it might be something on your side?

 
I have a bit of difficulty even differentiating the issues listed belo= w: surely the reason why enterprises assign multiple identities per user is= to authorize access to different services separately.

Sorry, I do not get that. 
Why would the enterprise be required to create multiple identities to = allow access to different services separately? in other words, why cannot t= he enterprise create one identity and still be able to control the user's a= ccess to different services provided by different servers?

 
This is an issue that could be resolved with an access control list pe= r service and a trusted identity broker in the enterprise vouching for user= identities to these services.

But that means that each server that provides a service must maintain = a separate user directory, which is exactly what I am trying to avoid.

 
But to convince ourselves that one approach to this is better than ano= ther, we need to look at a level of detail below these issue descriptions. = Again, in order to access a voicemail service in an enterprise, say, what d= oes the voicemail service need to know about the user?

Like, for regular access to the voicemail for "jon@enterprise,&qu= ot; surely all the voicemail service needs to know is that the entity autho= ritative for the @enterprise issued me the name "jon." Maybe the = "admin" account gets to access all the voicemails, if need be.

The application server needs the following pieces of information about= each user:
1. ID and credentials
2. User profile to control the level of service provided to the user.<= /div>

You cannot assume that all users will get the same level of service.

 
There are a variety of mechanisms that suffice to prove simple identit= ies like that to a service.

Can you elaborate?
Are you assuming that the service still have a separate user directory= ?

 
If, however, I as "jon" needed for a third-party transcripti= on service to access a subset of the messages in my voicemail box, and I wa= nted the permissions for that access to expire as soon as the messages had = been transcribed, then there is a much narrower set of mechanisms that could provide that capability.

You keep going back to the OAuth 2.0 model and try to impose it on SIP= , which would work in some use cases.

What I am proposing is something along the lines of OpenID, which exte= nds the OAuth to authenticate the *user*.
In this case, the mapping between OAuth and SIP would be something lik= e the following:

OAuth                   &= nbsp;                SIP
----------------------------------------------------------------------= -----
Resource Owner                =     End User
Resource Server                = ;     SIP Proxy or SIP Application Server
Client                   =                   SIP UA
Authorization Server               =  Authorization Server

Do you see a problem with this model?

 
But it sounds to me, from this issues list, like your requirements are= more along the former lines than the latter. 


Actually, it is both.

Here is an example of a use case that fits with the OAuth 2.0 model:

An Application Server that provides Mobile Clients with access to SIP = services.
The Mobile Client uses a proprietary protocol to communicate with the = Application Server that registers and gets service from the SIP network on = behalf of the user that is using the Mobile Client.

The communication channels between the players in this case are as fol= lows (hopefully the format is ok this time):

[Mobile Client]  <----------->  [Application Server] &= lt;-----------> [SIP Proxy]
          /\         &nbs= p;                     &n= bsp;         /\
           |        =                     &nbs= p;            |
           |        =                     &nbs= p;           \/
           ------------------------> = [Authorization Server]


In this case, the mapping between OAuth and SIP would be something lik= e the following:

OAuth                   &= nbsp;                SIP
----------------------------------------------------------------------= -----
Resource Owner                =     End User
Resource Server                = ;     SIP Proxy
Client                   =                   Application = Server (providing service to the mobile client)
Authorization Server               =  Authorization Server


Regards,
 Rifaat



 
Jon Peterson
Neustar, Inc.




On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussion I= think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.


Well, OpenID extends the OAuth 2.0 Framework to authenticate the user;= why do you think it is "twisting" OAuth into a different shape?<= /div>


 
It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.


Below is a description for some enterprise issues, that hopefully will= be addressed by a new authorization framework:


* Multiple Identitie= s One of the major issues in the enterprise is the need for a user to obtai= n multiple uncorrelated identities associated with different products to get access to the various services p= rovided by the enterprise. For example, in the enterprise the user will be = provided with different identities to: o Login his device (PC, laptop, mobi= le, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o = Host a conference. o etc Typically, these identities belong to different ad= ministrative domains and realms. Instead of these multiple identities, idea= lly the enterprise would like to create and maintain only one identity for the user and then allow the user= access to all SIP and non-SIP services using that one identity. * Authoriz= ation of Access to Services Another issue in the enterprise is the need to = control and authorize a user access to services. Because application servers have their own user directory, th= e control of access to services is spread over a multitude of servers in th= e network. Ideally, the enterprise would like to manage the access to servi= ces using one centralized entity and for the various entities that provide the service to become the enforc= ement points. * Assignment of Services In the enterprise, different users m= ight be assigned to different servers providing a specific service; e.g. Vo= ice Mail Box for different users might be hosted by different servers, and the user need to know his assign= ed server to be able to get access to this service. * Application Servers T= o be able to provide service, the application server needs a list of users = allowed to get services. The application server needs the following pieces of information about each user: 1. User = ID and Credentials 2. Profile to control the level of service provided to t= he user. If one application server provides different services using differ= ent protocols, the application server might need to maintain different identities associated with these protocol= s; e.g. an application server that provides presence service using SIP, and= IM service using XMPP. Ideally, an authorization framework would: 1. Off l= oad the application server from the need to manage the user credentials and authenticating the user. 2. Of= f load the application server from the need to maintain the users and their= profiles to control the level of service provided to the user. 3. Allow th= e assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, = the user ID and credentials will be handled by the authorization server, an= d the application server assignment and the level of service associated wit= h the user will be provided in the scope of the token associated with the user. When the application server r= eceives a request from a user it will have all the details that would allow= the application server to validate the request to make sure it is coming f= rom the right authorization server, and to act upon the request because it has the scope associated with the u= ser, without the need to contact the authorization server. * Relying Party = Regarding the Relying Party question: I think that when the user is being a= uthenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in Open= ID lingo) to access services on behalf of the end user. So, the mapping wou= ld be something like this: +------------------------+--------------= ---------------+ | OAuth | SIP | +------------------------+----= -------------------------+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Ser= ver | | Client | SIP UA (Relying Party) | | Authorization Server | Authoriz= ation Server | +------------------------+--------------------------= ---+


Regards,
 Rifaat





 
Jon Peterson
Neustar, Inc.





On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of service<= br> providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

 
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think<= br> you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

 
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

 
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OTT provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
 Rifaat


 
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My
>impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing
>recording.
>
>       Thanks,
>       Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>   Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>     Included is the use case I spoke of before.&nbs= p; My apologies for the
>>delay.
>>
>>     This is written as though it could be included = in
>>     [draft-yusef-sipcore-sip-oauth] at section 6. >>
>>
>>     6. Examples
>>
>>     6.1. Example: Call Recording Service
>>
>>     This example illustrates the use of SIP OAuth b= etween three
>>     parties:  A hosted VoIP service provider, = a Call Recording Service
>>     provider, and a phone system end-user.  In= this example:
>>     - The phone system end-user is a customer of bo= th the hosted VoIP
>>     provider and the Call Recording Service provide= r
>>     - The hosted VoIP service provider is a standar= d provider of hosted
>>     business-class VoIP telephone service using SIP=
>>     - The Call Recording Service provider is a dist= inct entity from the
>>     hosted VoIP provider
>>
>>     The Call Recording Service provides to customer= s both the call
>>     recording abilities and management of call reco= rdings
>>     (configuration, sharing and distribution, reten= tion, etc.).  This
>>     service can accept and record RTP traffic, asso= ciate all RTP streams
>>     with a single call together, and store and cata= log the recorded data
>>     for future searching and retrieval.  The s= ervice also offers a web
>>     interface where customers may view and retrieve= stored calls.
>>     Stored calls may range from simple person-to-pe= rson voice calls to
>>     multi-party conferences with a multitude of aud= io and video
>>     streams.  In this example, customers are b= illed based on the amount
>>     of data they store, although other models are c= ertainly possible.
>>
>>     6.1.1. OAuth 2.0 Roles
>>
>>     In this example, each party assumes the followi= ng OAuth 2.0 roles as
>>     defined in [RFC6749] Section 1.1:
>>     - The end-user assumes the role of resource own= er
>>     - The hosted VoIP service provider assumes the = role of client
>>     - The Call Recording Service provider assumes t= he role of resource
>>     server as well as the role of authorization ser= ver
>>
>>     6.1.2. Description
>>
>>     There are two parts to the example:  Initi= al configuration and
>>     real-time recording authorization.
>>
>>     Each section includes a simplified flow diagram= for the purpose of
>>     describing the corresponding portion of the exa= mple.  For the sake
>>     of brevity, certain parts of the OAuth dialog h= ave been eliminated.
>>     Implements should refer to [RFC6749] for detail= s on OAuth.
>>
>>     6.1.2.1 Initial Configuration
>>
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>        |  End-User   |  &n= bsp;  | VoIP Provider |     | CRS Provider |
>>        | Web Browser |     |&nb= sp;   Website    |     |      =         |
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 1&nbs= p;            |        &n= bsp;            |
>>               | (Configure= CRS)    |               =      |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 2&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect    |               =      |
>>               |  to C= RS Website)   |              &= nbsp;      |
>>               |<-------= ------------|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 3&nbs= p;            |        &n= bsp;            |
>>               | (Authorize= SIP from VoIP provider        |
>>               |-----------= ------------------------------>|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 4&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect back to VoIP portal)     |
>>               |<-------= ----------------------------------|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 5&nbs= p;            |        &n= bsp;            |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 | HTTP 6  &= nbsp;           |
>>               |  &nbs= p;                 | (Request Acces= s and |
>>               |  &nbs= p;                 |  refresh = tokens)    |
>>               |  &nbs= p;                 |---------------= ----->|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>
>>     Some time after having signed up for both servi= ces, but prior to
>>     attempting to record any calls, the end-user lo= gs into the web
>>     portal of the hosted VoIP provider with a web b= rowser and configures
>>     their call recording service (HTTP 1).  Th= is configuration includes
>>     providing a URI where the call recording servic= e may be reached,
>>     along with a set of API credentials, provided b= y the call recording
>>     service, which will allow the client to initiat= e an OAuth exchange.
>>     The end-user also configures the conditions und= er which call
>>     recordings should take place.  For example= , the end-user may request
>>     to record every multi-party (conference) call, = or every call
>>     involving a specific set of users.  The en= d-user may also specify
>>     other restrictions, such as restricting codec n= egotiation to G.711u
>>     for audio and H.264 for video in order to recor= d the RTP streams.
>>     Once the end-user saves the configuration, the = hosted VoIP provider
>>     web portal redirects the end-user's web browser= to the call
>>     recording service website and a standard HTTP O= Auth dialog begins
>>     (HTTP 2).  The end-user authorizes the hos= ted VoIP provider to
>>     access (i.e. send SIP and RTP traffic to) the c= all recording
>>     service, for the purpose of recording calls, so= long as the
>>     configured conditions are met (HTTP 3).  T= he result of this
>>     interaction is that the hosted VoIP provider en= ds up receiving an
>>     OAuth access token and refresh token from the c= all recording service
>>     (HTTP 4, HTTP 5, HTTP 6).  These tokens ar= e saved in the end-user's
>>     hosted VoIP account database.
>>
>>     6.1.2.2 Real-time Recording Authorization
>>
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>        |  End-User   |  &n= bsp;  | VoIP Provider |      | CRS Provider |
>>        |  SIP Phone  |    =  |    Website    |      |  &nb= sp;           |
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>               |  &nbs= p;                 |    &= nbsp;                 |
>>               | SIP INVITE= 1       |            &nb= sp;         |
>>               |-----------= -------->|                 =     |
>>               |  &nbs= p;                 | SIP INVITE 2&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 401 Unauth= orized |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 3&n= bsp;        |
>>               |  &nbs= p;                 | (with refresh = token) |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 1 = ;           |
>>               |  &nbs= p;                 | (new access to= ken)   |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 4&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 2 = ;           |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>
>>     Independently of and after the initial configur= ation phase, the
>>     end-user makes a telephone call using the hoste= d VoIP provider (SIP
>>     INVITE 1).  When this call takes place, th= e hosted VoIP provider
>>     looks to see whether it believes this call shou= ld be recorded.  If
>>     so, at this point it would branch the call sess= ion to the call
>>     recording service, using SIP OAuth to pass the = previously provided
>>     access token for authorization (SIP INVITE 2).&= nbsp; Once the access
>>     token is validated by the call recording servic= e (perhaps after
>>     first providing a new access token based on rec= eipt of a valid
>>     refresh token), the call recording service will= check the rights
>>     that were previously authorized and examine the= SIP to determine
>>     whether it can accept the call.  If so, it= completes the
>>     establishment of the session and begins receivi= ng and recording the
>>     RTP stream(s) (SIP 200 OK).  The call reco= rding service provider
>>     could also deny the request, either because the= tokens are invalid
>>     or because the content of
>>       the SIP invite does not match the previo= usly authorized
>>     conditions, in which case a SIP 403 would be re= turned by the call
>>     recording service provider and the call would n= ot be recorded -
>>     however, the initial call branch would continue= without
>>interruption.
>>
>>     Note:
>>     [RFC6749] specifies that when a client uses a r= efresh token to
>>     request a new access token, the response is HTT= P 200 with the new
>>     access token and optionally a new refresh token= included in the
>>     payload.  In this example, a SIP 200 respo= nse (SIP 200 1) is sent
>>     which contains the new token(s).  However,= this could be confusing
>>     as SIP 200 is generally viewed as the acceptanc= e of the INVITE,
>>     which is not what is happening in this case.&nb= sp; Should SIP 200 be used
>>     for consistency, or should another mechanism be= used?
>>
>>     6.1.3. Justification
>>
>>     6.1.3.1. Hosted VoIP Service Provider
>>
>>     In this example, the hosted VoIP service provid= er can allow their
>>     customers to enable call recording in their VoI= P service by
>>     selecting from any of a number of supported cal= l recording service
>>     providers.  This allows the hosted VoIP se= rvice provider to offer
>>     this feature to customers without requiring tha= t the hosted VoIP
>>     service provider implement and support this fea= ture themselves.
>>
>>     6.1.3.2. Call Recording Service Provider
>>
>>     In this example, the Call Recording Service pro= vider can focus on
>>     value and innovation in the area of recording c= alls and managing
>>     recorded calls without having to build a full-f= eatured telephony
>>     offering.
>>
>>     6.1.3.3. Customer
>>
>>     In this example, the customer has more flexibil= ity in choosing a
>>     complete solution that meets all of the custome= r needs.  The
>>     customer does not have to settle for a substand= ard call recording
>>     service offering in order to obtain other featu= res they seek in a
>>     hosted VoIP provider, and vice versa.
>>
>>     6.1.4. Variants
>>
>>     A simple variant of this example is one wherein= one of the services
>>     (either the VoIP service or the call recording = service) is managed
>>     directly by the end-user, but the other is not.=   For example, the
>>     end-user may wish to make use of an external ho= sted VoIP service
>>     provider, but may have business or legal reason= s that forbid the
>>     end-user from allowing a third party to store a= nd manage recorded
>>     calls.  The end-user could choose to set u= p their own call recording
>>     service as described in this example, and use S= IP OAuth to
>>     facilitate interaction between the hosted VoIP = service and the
>>     end-user's own call recording service.
>>
>>     6.2. Other SIP OAuth examples
>>
>>     Many other SIP-based services could leverage SI= P OAuth to provide
>>     value-added service to an end-user of a hosted = VoIP service
>>     provider.  Some examples of these types of= services are listed
>>below.
>>
>>     Voicemail service provider:  The end-user = configures their hosted
>>     VoIP service provider to manage voicemail throu= gh a separate
>>     voicemail service provider, which chooses wheth= er to store voicemail
>>     based on existing quotas, Caller ID, etc.
>>
>>     Conferencing service provider:  A conferen= cing service may wish to
>>     bill customers in a more granular fashion, for = example, based on the
>>     number of participants and attendees in a confe= rence, the duration
>>     of conference, whether video was also included,= which codecs were
>>     being used, etc. instead of a flat monthly rate= .  SIP OAuth would
>>     facilitate metered authorization for a client's= use of the service,
>>     instead of all-or-nothing access.
>>
>>     Call center service provider:  A third par= ty may provide ring groups
>>     or call queues for a hosted VoIP provider along= with detailed
>>     reports and dashboards.  The end-user uses= OAuth over SIP to control
>>     who can log into which queues or ring groups, e= tc.
>>
>>
>>
>>     --
>>     Matt Ryan
>>     code slinger | zoomulus.com <http://zoomulus.com>
>>     ietf at mvryan dot org
>>
>>
>>
>>
>>     _______________________________________________=
>>     sipcore mailing list
>>     sipcore@ietf.org <mailto:sipcore@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

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



--_000_D059A86A134723jonpetersonneustarbiz_-- From nobody Wed Oct 8 13:30:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321821A0298 for ; Wed, 8 Oct 2014 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=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 1c0ZzLkm_yh1 for ; Wed, 8 Oct 2014 13:29:57 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4322F1A026C for ; Wed, 8 Oct 2014 13:29:56 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so9140596lab.21 for ; Wed, 08 Oct 2014 13:29:54 -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:content-type; bh=6l772UY1WtySjAtdY/5PWRtqDYzoR98S7hSlzM0sLo8=; b=HJdcAA+2H8i3voDCWEWuYndaU7dp5cWQ7APKtgbwKwEVh78Yg86nnxauV0/HU7+bUk JrHMv5kCUMR2Wu1BXujNhfYWQ75vp8gXUiIR3W3WIfun8a0nZ5rtuY9pum622bIo/uuE bGb1vMEdJ2DCUENKPhhqph6rXEGhLWAtqKUv5+m+jUCmfexlRcavW/JajJG5H5e3OnVA qEph5uI9SCBP7Jam9GGy29CubQ/bbRQ9CG7AI0tCmVUCc+R+Owd62QH29f8+0iK04HQw oLbuAaaYVO+OpIap9qxiBIZBXkSoXrLQ6DByLWBvNM6roG0/EwYT2Ct8C7dtvGsDhUch xCKA== MIME-Version: 1.0 X-Received: by 10.152.8.9 with SMTP id n9mr14002675laa.2.1412800194392; Wed, 08 Oct 2014 13:29:54 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Wed, 8 Oct 2014 13:29:54 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> Date: Wed, 8 Oct 2014 16:29:54 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a11c36748b9b4b00504ef2d25 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6E6GBiPnP1fjaX1_Y-KrmcGwY6c Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:30:04 -0000 --001a11c36748b9b4b00504ef2d25 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the detailed response Jon. Please, see my reply inline... Regards, Rifaat On Tue, Oct 7, 2014 at 7:01 PM, Peterson, Jon wrote: > > I know I've owed you a response to this one for a while... Still just > trying to understand the requirements. > > I suspect that application services in the enterprise, the ones that you > worry about maintaining ACLs, don't get to avoid having "a separate user > directory" so easily. A classic voicemail service, for example, needs to > keep voicemails for Alice separate from Bob - that's why typically it > authenticates who Alice and Bob are. > I obviously agree that the service must keep separate boxes for their users and it must authenticate the user to allow access to a specific box, but I am not sure that the authentication must be done by the voicemail server itself. The authentication could be done by an Authorization Server and as a result the SIP endpoint would be given an ID Token, as per OpenID, which proves the identity of the end user. The SIP endpoint will be able to use the ID Token to get access to the user's box. The voicemail server will be able to identify the user and verify the validity of the ID Token because the token has the signature of an Authorization Server that the voicemail server trusts. > Such a service must have effectively a "directory" of separate users that > effectively implies ACLs. > > The ID Token could also have a scope that controls the services and level of service provided to the user. > Now if, as you say: > > > The application server needs the following pieces of information about > each user: > > 1. ID and credentials > > 2. User profile to control the level of service provided to the user. > > What is your app server using that ID and credentials for, if not to > compare to something that is effectively an ACL - like, to prevent Alice > from getting Bob's voicemail? My point earlier was that if all you care > about is showing that someone is Alice or Bob (or just that they're an > authenticated user and it doesn't matter who), then a solution to the > requirements could look very similar to RFC4474 or STIR: you just need > authentication, not authorization, and calling it authorization is just > confusing the issue. > > I care about both, authentication and authorization, and my argument is that an ID Token could be used to provide the needed user authentication, and the scope associated with the ID Token could be used to provide the authorization to control access to services for that specific user. > But, there's a different approach here, one where a service doesn't need > to know IDs or credentials or anything about users. > In this specific case, the service obviously needs to know the user ID, but it does not have to know the user's credentials to authorize access to the voicemail box. > This is an approach where I just get a token from an authorization > service, and hand that token to the app service, and the app service uses > that token *instead of* my ID or credentials or any personal profile about > me. > As I mentioned above, the ID Token proves your identity and has a scope that controls your access to services. > I can imagine a very odd voicemail service that, rather than putting > messages into buckets for Alice and Bob, put them all into one generic > bucket - and then an outside authorization service kept track of the fact > that messages 2, 17, and 109 are for Alice. When Alice requests access to > her voicemail from the authorization service, it gives her a token that > proves to the voicemail service that she is allowed to access only messages > 2, 17, and 109, and she can only do it in the next five minutes, say, to > prevent capture and replay. The voicemail service then has no idea who she > is or who those messages are for, it just ponies them up. If *that* is what > you said above, at least I would understand why you want to use OAuth - it > would be a terrible architecture (the authZ service keeps track of those > messages how exactly?), but at least this is what OAuth is for. The > architectures make more sense with third parties. > > That obviously does not make sense for a voicemail service, But, let's take a look at a different example; an adhoc conference server: I can imagine an adhoc conference server that accepts requests to allocate a focus to a user based on the ID Token provided in the incoming request. The ID Token proves the identity of the user and provides a scope to control the level of service provided to the user. The conference server will be able to verify the validity of the ID Token because the token has the signature of an Authorization Server that the conference server trusts. In this specific case, do you see a need for the conference server to maintain a user directory? In any case, I am not trying to completely get rid of user directory from all services, but mainly to get rid of the need to maintain separate user identities and credentials per service. Ideally, I would like the user to have one identity and be able to use that identity to authenticate and get access to all services in the enterprise. A third approach would be problems we looked at as "trait-based" > authorization problems. The classic example is where for some service, > perhaps it matters whether Alice is in the Engineering department or the > Finance department, rather than who Alice is exactly. Maybe those're the > sort of elements you mean by "user profile." We did a whole requirements > process years ago on "trait-based" authorization mechanisms intended to > satisfy cases like this: see RFC4484. You'll note it shows architectures > where a SIP endpoints point by-reference to HTTP objects that contain > authorization policy elements like such "traits." There are a bunch of > solutions for that space, too, but if that's what you want, then my > question for you would be, do you have any requirements beyond what's > defined in RFC4484 Sec. 5? > > I have never read RFC4484 before; I will take a look. Regards, Rifaat > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Wednesday, September 17, 2014 at 6:22 AM > > To: Jon Peterson > Cc: Paul Kyzivat , "sipcore@ietf.org" < > sipcore@ietf.org> > Subject: Re: [sipcore] A SIP OAuth use case > > > > On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon > wrote: > >> >> Format snags aside, >> > > I copied that text from a different editor. > The format seems ok here: > http://www.ietf.org/mail-archive/web/sipcore/current/msg06258.html > > So, it might be something on your side? > > > >> I have a bit of difficulty even differentiating the issues listed >> below: surely the reason why enterprises assign multiple identities per >> user is to authorize access to different services separately. >> > > Sorry, I do not get that. > Why would the enterprise be required to create multiple identities to > allow access to different services separately? in other words, why cannot > the enterprise create one identity and still be able to control the user's > access to different services provided by different servers? > > > >> This is an issue that could be resolved with an access control list per >> service and a trusted identity broker in the enterprise vouching for user >> identities to these services. >> > > But that means that each server that provides a service must maintain a > separate user directory, which is exactly what I am trying to avoid. > > > >> But to convince ourselves that one approach to this is better than >> another, we need to look at a level of detail below these issue >> descriptions. Again, in order to access a voicemail service in an >> enterprise, say, what does the voicemail service need to know about the >> user? >> >> Like, for regular access to the voicemail for "jon@enterprise," surely >> all the voicemail service needs to know is that the entity authoritative >> for the @enterprise issued me the name "jon." Maybe the "admin" account >> gets to access all the voicemails, if need be. >> > > The application server needs the following pieces of information about > each user: > 1. ID and credentials > 2. User profile to control the level of service provided to the user. > > You cannot assume that all users will get the same level of service. > > > >> There are a variety of mechanisms that suffice to prove simple >> identities like that to a service. >> > > Can you elaborate? > Are you assuming that the service still have a separate user directory? > > > >> If, however, I as "jon" needed for a third-party transcription service >> to access a subset of the messages in my voicemail box, and I wanted the >> permissions for that access to expire as soon as the messages had been >> transcribed, then there is a much narrower set of mechanisms that could >> provide that capability. >> > > You keep going back to the OAuth 2.0 model and try to impose it on SIP, > which would work in some use cases. > > What I am proposing is something along the lines of OpenID, which > extends the OAuth to authenticate the *user*. > In this case, the mapping between OAuth and SIP would be something like > the following: > > OAuth SIP > --------------------------------------------------------------------------- > Resource Owner End User > Resource Server SIP Proxy or SIP Application Server > Client SIP UA > Authorization Server Authorization Server > > Do you see a problem with this model? > > > >> But it sounds to me, from this issues list, like your requirements are >> more along the former lines than the latter. >> >> > Actually, it is both. > > Here is an example of a use case that fits with the OAuth 2.0 model: > > An Application Server that provides Mobile Clients with access to SIP > services. > The Mobile Client uses a proprietary protocol to communicate with the > Application Server that registers and gets service from the SIP network on > behalf of the user that is using the Mobile Client. > > The communication channels between the players in this case are as > follows (hopefully the format is ok this time): > > [Mobile Client] <-----------> [Application Server] <-----------> [SIP > Proxy] > /\ /\ > | | > | \/ > ------------------------> [Authorization Server] > > > In this case, the mapping between OAuth and SIP would be something like > the following: > > OAuth SIP > --------------------------------------------------------------------------- > Resource Owner End User > Resource Server SIP Proxy > Client Application Server (providing > service to the mobile client) > Authorization Server Authorization Server > > > Regards, > Rifaat > > > > > >> Jon Peterson >> Neustar, Inc. >> >> From: Rifaat Shekh-Yusef >> Date: Saturday, September 13, 2014 at 12:32 PM >> >> To: Jon Peterson >> Cc: Paul Kyzivat , "sipcore@ietf.org" < >> sipcore@ietf.org> >> Subject: Re: [sipcore] A SIP OAuth use case >> >> >> >> On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon >> wrote: >> >>> >>> I understand that OAuth can be altered from its basic flows to provide >>> tokens for OpenID, and IdP could be bound to OAuth, and while this is all >>> very interesting it doesn't change much about the requirements discussion I >>> think we need to have: the one about what kinds of use cases we want to >>> satisfy and who the relying parties are in those cases. Once we understand >>> that, we will understand what tools are applicable to these use cases - >>> preferably, not tools that need to be twisted into a different shape to be >>> applicable. >>> >>> >> Well, OpenID extends the OAuth 2.0 Framework to authenticate the user; >> why do you think it is "twisting" OAuth into a different shape? >> >> >> >> >>> It would helpful, in the enterprise SSO case, for us to understand >>> what kinds of application servers a user might need to access, and what >>> exactly those application servers need to know about the user in order to >>> accomplish their function. >>> >>> >> Below is a description for some enterprise issues, that hopefully will >> be addressed by a new authorization framework: >> >> >> * Multiple Identities One of the major issues in the enterprise is the >> need for a user to obtain multiple uncorrelated identities associated with >> different products to get access to the various services provided by the >> enterprise. For example, in the enterprise the user will be provided with >> different identities to: o Login his device (PC, laptop, mobile, ...) to >> the network. o Register to the SIP network and get basic SIP services. o >> Access his Voice Mail. o Host a conference. o etc Typically, these >> identities belong to different administrative domains and realms. Instead >> of these multiple identities, ideally the enterprise would like to create >> and maintain only one identity for the user and then allow the user access >> to all SIP and non-SIP services using that one identity. * Authorization of >> Access to Services Another issue in the enterprise is the need to control >> and authorize a user access to services. Because application servers have >> their own user directory, the control of access to services is spread over >> a multitude of servers in the network. Ideally, the enterprise would like >> to manage the access to services using one centralized entity and for the >> various entities that provide the service to become the enforcement points. >> * Assignment of Services In the enterprise, different users might be >> assigned to different servers providing a specific service; e.g. Voice Mail >> Box for different users might be hosted by different servers, and the user >> need to know his assigned server to be able to get access to this service. >> * Application Servers To be able to provide service, the application server >> needs a list of users allowed to get services. The application server needs >> the following pieces of information about each user: 1. User ID and >> Credentials 2. Profile to control the level of service provided to the >> user. If one application server provides different services using different >> protocols, the application server might need to maintain different >> identities associated with these protocols; e.g. an application server that >> provides presence service using SIP, and IM service using XMPP. Ideally, an >> authorization framework would: 1. Off load the application server from the >> need to manage the user credentials and authenticating the user. 2. Off >> load the application server from the need to maintain the users and their >> profiles to control the level of service provided to the user. 3. Allow the >> assignment of a user to a specific application server. * OAuth/OpenID Model >> With the OAuth/OpenID framework, the user ID and credentials will be >> handled by the authorization server, and the application server assignment >> and the level of service associated with the user will be provided in the >> scope of the token associated with the user. When the application server >> receives a request from a user it will have all the details that would >> allow the application server to validate the request to make sure it is >> coming from the right authorization server, and to act upon the request >> because it has the scope associated with the user, without the need to >> contact the authorization server. * Relying Party Regarding the Relying >> Party question: I think that when the user is being authenticated, that the >> Relying Party would be the SIP Client that would be given a user token (ID >> Token in OpenID lingo) to access services on behalf of the end user. So, >> the mapping would be something like this: >> +------------------------+-----------------------------+ | OAuth | SIP | >> +------------------------+-----------------------------+ | Resource Owner | >> End User | | Resource Server | SIP Proxy or SIP App Server | | Client | SIP >> UA (Relying Party) | | Authorization Server | Authorization Server | >> +------------------------+-----------------------------+ >> >> >> Regards, >> Rifaat >> >> >> >> >> >> >> >>> Jon Peterson >>> Neustar, Inc. >>> >>> From: Rifaat Shekh-Yusef >>> Date: Thursday, September 4, 2014 at 8:31 AM >>> To: Jon Peterson >>> Cc: Paul Kyzivat , "sipcore@ietf.org" < >>> sipcore@ietf.org> >>> Subject: Re: [sipcore] A SIP OAuth use case >>> >>> >>> >>> >>> On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon >>> wrote: >>> >>>> >>>> While I would echo Paul's thoughts below about the plausibility of >>>> service >>>> providers using this model to authorize recording, I also agree that >>>> third-party recording is an excellent example of a service architecture >>>> that requires an authorization mechanism like OAuth. An end user needs >>>> to >>>> authorize a third party to participate in the session under certain >>>> constraints, and coordinate the association between the third party and >>>> the VoIP service. This example also (rightly, in my opinion) conducts >>>> the >>>> majority of the flow in HTTP where it belongs. >>>> >>>> >>> I agree with that. >>> >>> >>> >>>> Many of the use cases under discussion in this thread, though, are of >>>> the >>>> form where there are really only two involved parties: an end user and a >>>> service provider. If you are my service provider, then in traditional >>>> SIP >>>> I share a secret with you that I use to REGISTER my devices. I don't >>>> think >>>> you need OAuth for that. >>> >>> >>> If you assume that there is one server that provides all the services, >>> then you are right. >>> But that is not the case all the time. I think that Dale articulated >>> that clearly in the following response: >>> http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html >>> >>> >>> >>>> I do understand that OAuth 2.0 is used in the >>>> wild for SSO, though I sympathize with Matt that the base flow shown in >>>> RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. >>>> >>>> >>> I agree that the OAuth 2.0 "as is" does not address the SSO >>> requirements. >>> The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is >>> extending the framework to authenticate and provide a *user* specific token. >>> >>> Since Matt mentioned OpenID few times, I looked at the OpenID >>> specification. >>> What they are doing there is that they defined a new token, called ID >>> Token, that is associated with the *user*; which is exactly what the SIP >>> OAuth proposal is doing. >>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken >>> >>> My plan is to use the same terminology, ID Token, in the next version >>> of the SIP OAuth document to clarify that, and to differentiate it from the >>> access token. >>> >>> >>> >>>> I think, though, we might usefully break uses cases here down by who the >>>> intended relying party is: >>>> >>>> - The user's own SIP service provider (my enterprise, my carrier, my OTT >>>> provider) >>>> - A third party that a user wants to authorize for a service (recording >>>> service... But anything else?) >>>> >>>> I would also append some use cases where the relying party: >>>> >>>> - Someone with no association with the user (caller ID sorts of cases) >>>> >>>> This last is where I've argued things like IdP might be relevant. >>>> >>>> >>> EKR has a nice description for binding IdP to OAuth in his WebRTC >>> Security Architecture document here: >>> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 >>> >>> We could use the same idea for SIP. >>> >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>>> Are there any other high-level buckets of use cases here? >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 8/25/14, 11:44 AM, "Paul Kyzivat" wrote: >>>> >>>> >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >>>> >> Hi Matt, >>>> >> >>>> >> The use case and the solution provided assumes that the VoIP Provider >>>> >> makes the decision on when and what to record. >>>> >> While this is a valid use case, there are other use cases that allow >>>> the >>>> >> user to decide on when and what to record; take a look at RFC6341 for >>>> >> more info. >>>> >> http://datatracker.ietf.org/doc/rfc6341/ >>>> > >>>> >SIPREC supports numerous topologies. >>>> >It would support the one that Matt outlines as well as end-user >>>> >controlled ones. >>>> > >>>> >I found Matt's use case interesting. I think it would be nice if such >>>> >services were available in that form. But I have difficulty imagining >>>> >any of the VoIP providers I'm aware of supporting this model. My >>>> >impression is that this means that they are giving up a value added >>>> >revenue market, that they are loath to do. The most likely >>>> justification >>>> >I can imagine that they don't want to legal consequences of doing >>>> >recording. >>>> > >>>> > Thanks, >>>> > Paul >>>> > >>>> >> For these use cases, where the user is in control, you need to away >>>> to >>>> >> authenticate and control which users are allowed to record and the >>>> level >>>> >> of service provided for that specific user. >>>> >> This is where the solutions provided in section 3 or section 4 of the >>>> >> SIP OAuth proposal come into play. >>>> >> Obviously, in this case the authorization server is different from >>>> >> authorization server used to establish the trust relationship between >>>> >> the VoIP Provider and the CRS Provider. >>>> >> In this case, the authorization server must authenticate the user and >>>> >> provide his UA with an access token or a code that controls the >>>> user's >>>> >> access to the service. >>>> >> >>>> >> Regards, >>>> >> Rifaat >>>> >> >>>> >> >>>> >> >>>> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >>> >> > wrote: >>>> >> >>>> >> Included is the use case I spoke of before. My apologies for the >>>> >>delay. >>>> >> >>>> >> This is written as though it could be included in >>>> >> [draft-yusef-sipcore-sip-oauth] at section 6. >>>> >> >>>> >> >>>> >> 6. Examples >>>> >> >>>> >> 6.1. Example: Call Recording Service >>>> >> >>>> >> This example illustrates the use of SIP OAuth between three >>>> >> parties: A hosted VoIP service provider, a Call Recording >>>> Service >>>> >> provider, and a phone system end-user. In this example: >>>> >> - The phone system end-user is a customer of both the hosted VoIP >>>> >> provider and the Call Recording Service provider >>>> >> - The hosted VoIP service provider is a standard provider of >>>> hosted >>>> >> business-class VoIP telephone service using SIP >>>> >> - The Call Recording Service provider is a distinct entity from >>>> the >>>> >> hosted VoIP provider >>>> >> >>>> >> The Call Recording Service provides to customers both the call >>>> >> recording abilities and management of call recordings >>>> >> (configuration, sharing and distribution, retention, etc.). This >>>> >> service can accept and record RTP traffic, associate all RTP >>>> streams >>>> >> with a single call together, and store and catalog the recorded >>>> data >>>> >> for future searching and retrieval. The service also offers a >>>> web >>>> >> interface where customers may view and retrieve stored calls. >>>> >> Stored calls may range from simple person-to-person voice calls >>>> to >>>> >> multi-party conferences with a multitude of audio and video >>>> >> streams. In this example, customers are billed based on the >>>> amount >>>> >> of data they store, although other models are certainly possible. >>>> >> >>>> >> 6.1.1. OAuth 2.0 Roles >>>> >> >>>> >> In this example, each party assumes the following OAuth 2.0 >>>> roles as >>>> >> defined in [RFC6749] Section 1.1: >>>> >> - The end-user assumes the role of resource owner >>>> >> - The hosted VoIP service provider assumes the role of client >>>> >> - The Call Recording Service provider assumes the role of >>>> resource >>>> >> server as well as the role of authorization server >>>> >> >>>> >> 6.1.2. Description >>>> >> >>>> >> There are two parts to the example: Initial configuration and >>>> >> real-time recording authorization. >>>> >> >>>> >> Each section includes a simplified flow diagram for the purpose >>>> of >>>> >> describing the corresponding portion of the example. For the >>>> sake >>>> >> of brevity, certain parts of the OAuth dialog have been >>>> eliminated. >>>> >> Implements should refer to [RFC6749] for details on OAuth. >>>> >> >>>> >> 6.1.2.1 Initial Configuration >>>> >> >>>> >> +-------------+ +---------------+ +--------------+ >>>> >> | End-User | | VoIP Provider | | CRS Provider | >>>> >> | Web Browser | | Website | | | >>>> >> +-------------+ +---------------+ +--------------+ >>>> >> | | | >>>> >> | HTTP 1 | | >>>> >> | (Configure CRS) | | >>>> >> |------------------->| | >>>> >> | | | >>>> >> | HTTP 2 | | >>>> >> | (OAuth Redirect | | >>>> >> | to CRS Website) | | >>>> >> |<-------------------| | >>>> >> | | | >>>> >> | HTTP 3 | | >>>> >> | (Authorize SIP from VoIP provider | >>>> >> |----------------------------------------->| >>>> >> | | | >>>> >> | HTTP 4 | | >>>> >> | (OAuth Redirect back to VoIP portal) | >>>> >> |<-----------------------------------------| >>>> >> | | | >>>> >> | HTTP 5 | | >>>> >> |------------------->| | >>>> >> | | HTTP 6 | >>>> >> | | (Request Access and | >>>> >> | | refresh tokens) | >>>> >> | |-------------------->| >>>> >> | | | >>>> >> >>>> >> Some time after having signed up for both services, but prior to >>>> >> attempting to record any calls, the end-user logs into the web >>>> >> portal of the hosted VoIP provider with a web browser and >>>> configures >>>> >> their call recording service (HTTP 1). This configuration >>>> includes >>>> >> providing a URI where the call recording service may be reached, >>>> >> along with a set of API credentials, provided by the call >>>> recording >>>> >> service, which will allow the client to initiate an OAuth >>>> exchange. >>>> >> The end-user also configures the conditions under which call >>>> >> recordings should take place. For example, the end-user may >>>> request >>>> >> to record every multi-party (conference) call, or every call >>>> >> involving a specific set of users. The end-user may also specify >>>> >> other restrictions, such as restricting codec negotiation to >>>> G.711u >>>> >> for audio and H.264 for video in order to record the RTP streams. >>>> >> Once the end-user saves the configuration, the hosted VoIP >>>> provider >>>> >> web portal redirects the end-user's web browser to the call >>>> >> recording service website and a standard HTTP OAuth dialog begins >>>> >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >>>> >> access (i.e. send SIP and RTP traffic to) the call recording >>>> >> service, for the purpose of recording calls, so long as the >>>> >> configured conditions are met (HTTP 3). The result of this >>>> >> interaction is that the hosted VoIP provider ends up receiving an >>>> >> OAuth access token and refresh token from the call recording >>>> service >>>> >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the >>>> end-user's >>>> >> hosted VoIP account database. >>>> >> >>>> >> 6.1.2.2 Real-time Recording Authorization >>>> >> >>>> >> +-------------+ +---------------+ +--------------+ >>>> >> | End-User | | VoIP Provider | | CRS Provider | >>>> >> | SIP Phone | | Website | | | >>>> >> +-------------+ +---------------+ +--------------+ >>>> >> | | | >>>> >> | SIP INVITE 1 | | >>>> >> |------------------->| | >>>> >> | | SIP INVITE 2 | >>>> >> | | (with access token) | >>>> >> | |--------------------->| >>>> >> | | | >>>> >> | | SIP 401 Unauthorized | >>>> >> | |<---------------------| >>>> >> | | | >>>> >> | | SIP INVITE 3 | >>>> >> | | (with refresh token) | >>>> >> | |--------------------->| >>>> >> | | | >>>> >> | | SIP 200 1 | >>>> >> | | (new access token) | >>>> >> | |<---------------------| >>>> >> | | | >>>> >> | | SIP INVITE 4 | >>>> >> | | (with access token) | >>>> >> | |--------------------->| >>>> >> | | | >>>> >> | | SIP 200 2 | >>>> >> | |<---------------------| >>>> >> | | | >>>> >> >>>> >> Independently of and after the initial configuration phase, the >>>> >> end-user makes a telephone call using the hosted VoIP provider >>>> (SIP >>>> >> INVITE 1). When this call takes place, the hosted VoIP provider >>>> >> looks to see whether it believes this call should be recorded. >>>> If >>>> >> so, at this point it would branch the call session to the call >>>> >> recording service, using SIP OAuth to pass the previously >>>> provided >>>> >> access token for authorization (SIP INVITE 2). Once the access >>>> >> token is validated by the call recording service (perhaps after >>>> >> first providing a new access token based on receipt of a valid >>>> >> refresh token), the call recording service will check the rights >>>> >> that were previously authorized and examine the SIP to determine >>>> >> whether it can accept the call. If so, it completes the >>>> >> establishment of the session and begins receiving and recording >>>> the >>>> >> RTP stream(s) (SIP 200 OK). The call recording service provider >>>> >> could also deny the request, either because the tokens are >>>> invalid >>>> >> or because the content of >>>> >> the SIP invite does not match the previously authorized >>>> >> conditions, in which case a SIP 403 would be returned by the call >>>> >> recording service provider and the call would not be recorded - >>>> >> however, the initial call branch would continue without >>>> >>interruption. >>>> >> >>>> >> Note: >>>> >> [RFC6749] specifies that when a client uses a refresh token to >>>> >> request a new access token, the response is HTTP 200 with the new >>>> >> access token and optionally a new refresh token included in the >>>> >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >>>> >> which contains the new token(s). However, this could be >>>> confusing >>>> >> as SIP 200 is generally viewed as the acceptance of the INVITE, >>>> >> which is not what is happening in this case. Should SIP 200 be >>>> used >>>> >> for consistency, or should another mechanism be used? >>>> >> >>>> >> 6.1.3. Justification >>>> >> >>>> >> 6.1.3.1. Hosted VoIP Service Provider >>>> >> >>>> >> In this example, the hosted VoIP service provider can allow their >>>> >> customers to enable call recording in their VoIP service by >>>> >> selecting from any of a number of supported call recording >>>> service >>>> >> providers. This allows the hosted VoIP service provider to offer >>>> >> this feature to customers without requiring that the hosted VoIP >>>> >> service provider implement and support this feature themselves. >>>> >> >>>> >> 6.1.3.2. Call Recording Service Provider >>>> >> >>>> >> In this example, the Call Recording Service provider can focus on >>>> >> value and innovation in the area of recording calls and managing >>>> >> recorded calls without having to build a full-featured telephony >>>> >> offering. >>>> >> >>>> >> 6.1.3.3. Customer >>>> >> >>>> >> In this example, the customer has more flexibility in choosing a >>>> >> complete solution that meets all of the customer needs. The >>>> >> customer does not have to settle for a substandard call recording >>>> >> service offering in order to obtain other features they seek in a >>>> >> hosted VoIP provider, and vice versa. >>>> >> >>>> >> 6.1.4. Variants >>>> >> >>>> >> A simple variant of this example is one wherein one of the >>>> services >>>> >> (either the VoIP service or the call recording service) is >>>> managed >>>> >> directly by the end-user, but the other is not. For example, the >>>> >> end-user may wish to make use of an external hosted VoIP service >>>> >> provider, but may have business or legal reasons that forbid the >>>> >> end-user from allowing a third party to store and manage recorded >>>> >> calls. The end-user could choose to set up their own call >>>> recording >>>> >> service as described in this example, and use SIP OAuth to >>>> >> facilitate interaction between the hosted VoIP service and the >>>> >> end-user's own call recording service. >>>> >> >>>> >> 6.2. Other SIP OAuth examples >>>> >> >>>> >> Many other SIP-based services could leverage SIP OAuth to provide >>>> >> value-added service to an end-user of a hosted VoIP service >>>> >> provider. Some examples of these types of services are listed >>>> >>below. >>>> >> >>>> >> Voicemail service provider: The end-user configures their hosted >>>> >> VoIP service provider to manage voicemail through a separate >>>> >> voicemail service provider, which chooses whether to store >>>> voicemail >>>> >> based on existing quotas, Caller ID, etc. >>>> >> >>>> >> Conferencing service provider: A conferencing service may wish >>>> to >>>> >> bill customers in a more granular fashion, for example, based on >>>> the >>>> >> number of participants and attendees in a conference, the >>>> duration >>>> >> of conference, whether video was also included, which codecs were >>>> >> being used, etc. instead of a flat monthly rate. SIP OAuth would >>>> >> facilitate metered authorization for a client's use of the >>>> service, >>>> >> instead of all-or-nothing access. >>>> >> >>>> >> Call center service provider: A third party may provide ring >>>> groups >>>> >> or call queues for a hosted VoIP provider along with detailed >>>> >> reports and dashboards. The end-user uses OAuth over SIP to >>>> control >>>> >> who can log into which queues or ring groups, etc. >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Matt Ryan >>>> >> code slinger | zoomulus.com >>>> >> ietf at mvryan dot org >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> sipcore mailing list >>>> >> sipcore@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> sipcore mailing list >>>> >> sipcore@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >>>> > >>>> >_______________________________________________ >>>> >sipcore mailing list >>>> >sipcore@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> >> > --001a11c36748b9b4b00504ef2d25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed response Jon.
Please, see my r= eply inline...

Regards,
=A0Rifaat
<= div>

On = Tue, Oct 7, 2014 at 7:01 PM, Peterson, Jon <jon.peterson@neustar.bi= z> wrote:

I know I've owed you a response to this one for a while... Still j= ust trying to understand the requirements.

I suspect that application services in the enterprise, the ones that y= ou worry about maintaining ACLs, don't get to avoid having "a sepa= rate user directory" so easily. A classic voicemail service, for examp= le, needs to keep voicemails for Alice separate from Bob - that's why typically it authenticates who Alice and Bob are= .

I obviously agree that the s= ervice must keep separate boxes for their users and it must authenticate th= e user to allow access to a specific box, but I am not sure that the authen= tication must be done by the voicemail server itself.=A0
The auth= entication could be done by an Authorization Server and as a result the SIP= endpoint would be given an ID Token, as per OpenID, which proves the ident= ity of the end user. The SIP endpoint will be able to use the ID Token to g= et access to the user's box. The voicemail server will be able to ident= ify the user and verify the validity of the ID Token because the token has = the signature of an Authorization Server that the voicemail server trusts.<= /div>

=A0
Now if, as you say:

> The application server needs the following pieces of information = about each user:
> 1. ID and credentials
> 2. User profile to control the level of service provided to the u= ser.

What is your app server using that ID and credentials for, if n= ot to compare to something that is effectively an ACL - like, to prevent Al= ice from getting Bob's voicemail? My point earlier was that if all you = care about is showing that someone is Alice or Bob (or just that they're an authenticated user and it doesn't = matter who), then a solution to the requirements could look very similar to= RFC4474 or STIR: you just need authentication, not authorization, and call= ing it authorization is just confusing the issue.


I care about both, au= thentication and authorization, and my argument is that an ID Token could b= e used to provide the needed user authentication, and the scope associated = with the ID Token could be used to provide the authorization to control acc= ess to services for that specific user.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
But, there's a different approach here, one where a service doesn&= #39;t need to know IDs or credentials or anything about users.
=

In this specific case, the service obvious= ly needs to know the user ID, but it does not have to know the user's c= redentials to authorize access to the voicemail box.

=A0
This is an approa= ch where I just get a token from an authorization service, and hand that to= ken to the app service, and the app service uses that token *instead of* my ID or credentials or any personal = profile about me.

As I mention= ed above, the ID Token proves your identity and has a scope that controls y= our access to services.

=A0
=
I can imagine a very odd voicemail service tha= t, rather than putting messages into buckets for Alice and Bob, put them al= l into one generic bucket - and then an outside authorization service kept track of the fact that messages 2, 17, and 109 = are for Alice. When Alice requests access to her voicemail from the authori= zation service, it gives her a token that proves to the voicemail service t= hat she is allowed to access only messages 2, 17, and 109, and she can only do it in the next five minutes, = say, to prevent capture and replay. The voicemail service then has no idea = who she is or who those messages are for, it just ponies them up. If *that*= is what you said above, at least I would understand why you want to use OAuth - it would be a terrible arch= itecture (the authZ service keeps track of those messages how exactly?), bu= t at least this is what OAuth is for. The architectures make more sense wit= h third parties.


That obviously does n= ot make sense for a voicemail service,

But, le= t's take a look at a different example; an adhoc conference server:
I can imagine an adhoc conference server that accepts requests to al= locate a focus to a user based on the ID Token provided in the incoming req= uest. The ID Token proves the identity of the user and provides a scope to = control the level of service provided to the user. The conference server wi= ll be able to verify the validity of the ID Token because the token has the= signature of an Authorization Server that the conference server trusts.
In this specific case, do you see a need for the conference server = to maintain a user directory?

In any case, I am no= t trying to completely get rid of user directory from all services, but mai= nly to get rid of the need to maintain separate user identities and credent= ials per service.
Ideally, I would like the user to have one iden= tity and be able to use that identity to authenticate and get access to all= services in the enterprise.


A third approach would be problems we looked at as "trait-based&q= uot; authorization problems. The classic example is where for some service,= perhaps it matters whether Alice is in the Engineering department or the F= inance department, rather than who Alice is exactly. Maybe those're the sort of elements you mean by "user pr= ofile." We did a whole requirements process years ago on "trait-b= ased" authorization mechanisms intended to satisfy cases like this: se= e RFC4484. You'll note it shows architectures where a SIP endpoints point by-reference to HTTP objects that contain authorization po= licy elements like such "traits." There are a bunch of solutions = for that space, too, but if that's what you want, then my question for = you would be, do you have any requirements beyond what's defined in RFC4484 Sec. 5?


I have never read RFC= 4484 before; I will take a look.

Regards,
=A0Rifaat



=A0
Jon Peterson
Neustar, Inc.




On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon <= span dir=3D"ltr"> <jon.peter= son@neustar.biz> wrote:

Format snags aside,

I copied that text from a different editor.
The format seems ok here:

So, it might be something on your side?

=A0
I have a bit of difficulty even differentiating the issues listed belo= w: surely the reason why enterprises assign multiple identities per user is= to authorize access to different services separately.

Sorry, I do not get that.=A0
Why would the enterprise be required to create multiple identities to = allow access to different services separately? in other words, why cannot t= he enterprise create one identity and still be able to control the user'= ;s access to different services provided by different servers?

=A0
This is an issue that could be resolved with an access control list pe= r service and a trusted identity broker in the enterprise vouching for user= identities to these services.

But that means that each server that provides a service must maintain = a separate user directory, which is exactly what I am trying to avoid.

=A0
But to convince ourselves that one approach to this is better than ano= ther, we need to look at a level of detail below these issue descriptions. = Again, in order to access a voicemail service in an enterprise, say, what d= oes the voicemail service need to know about the user?

Like, for regular access to the voicemail for "jon@enterprise,&qu= ot; surely all the voicemail service needs to know is that the entity autho= ritative for the @enterprise issued me the name "jon." Maybe the = "admin" account gets to access all the voicemails, if need be.

The application server needs the following pieces of information about= each user:
1. ID and credentials
2. User profile to control the level of service provided to the user.<= /div>

You cannot assume that all users will get the same level of service.

=A0
There are a variety of mechanisms that suffice to prove simple identit= ies like that to a service.

Can you elaborate?
Are you assuming that the service still have a separate user directory= ?

=A0
If, however, I as "jon" needed for a third-party transcripti= on service to access a subset of the messages in my voicemail box, and I wa= nted the permissions for that access to expire as soon as the messages had = been transcribed, then there is a much narrower set of mechanisms that could provide that capability.

You keep going back to the OAuth 2.0 model and try to impose it on SIP= , which would work in some use cases.

What I am proposing is something along the lines of OpenID, which exte= nds the OAuth to authenticate the *user*.
In this case, the mapping between OAuth and SIP would be something lik= e the following:

OAuth =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0SIP
----------------------------------------------------------------------= -----
Resource Owner =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 End User
Resource Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIP Proxy or S= IP Application Server
Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 SIP UA
Authorization Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Authorization Serv= er

Do you see a problem with this model?

=A0
But it sounds to me, from this issues list, like your requirements are= more along the former lines than the latter.=A0


Actually, it is both.

Here is an example of a use case that fits with the OAuth 2.0 model:

An Application Server that provides Mobile Clients with access to SIP = services.
The Mobile Client uses a proprietary protocol to communicate with the = Application Server that registers and gets service from the SIP network on = behalf of the user that is using the Mobile Client.

The communication channels between the players in this case are as fol= lows (hopefully the format is ok this time):

[Mobile Client] =A0<-----------> =A0[Application Server] <---= --------> [SIP Proxy]
=A0 =A0 =A0 =A0 =A0 /\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /\
=A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \/
=A0 =A0 =A0 =A0 =A0 =A0------------------------> [Authorization Ser= ver]


In this case, the mapping between OAuth and SIP would be something lik= e the following:

OAuth =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0SIP
----------------------------------------------------------------------= -----
Resource Owner =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 End User
Resource Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIP Proxy
Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Application Server (providing service to the mobile client)
Authorization Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Authorization Serv= er


Regards,
=A0Rifaat



=A0
Jon Peterson
Neustar, Inc.




On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussi= on I think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.


Well, OpenID extends the OAuth 2.0 Framework to authenticate the user;= why do you think it is "twisting" OAuth into a different shape?<= /div>


=A0
It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.


Below is a description for some enterprise issues, that hopefully will= be addressed by a new authorization framework:


* Multiple Identities On= e of the major issues in the enterprise is the need for a user to obtain mu= ltiple uncorrelated identities associated with different products to get access to the various services p= rovided by the enterprise. For example, in the enterprise the user will be = provided with different identities to: o Login his device (PC, laptop, mobi= le, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o = Host a conference. o etc Typically, these identities belong to different ad= ministrative domains and realms. Instead of these multiple identities, idea= lly the enterprise would like to create and maintain only one identity for the user and then allow the user= access to all SIP and non-SIP services using that one identity. * Authoriz= ation of Access to Services Another issue in the enterprise is the need to = control and authorize a user access to services. Because application servers have their own user directory, th= e control of access to services is spread over a multitude of servers in th= e network. Ideally, the enterprise would like to manage the access to servi= ces using one centralized entity and for the various entities that provide the service to become the enforc= ement points. * Assignment of Services In the enterprise, different users m= ight be assigned to different servers providing a specific service; e.g. Vo= ice Mail Box for different users might be hosted by different servers, and the user need to know his assign= ed server to be able to get access to this service. * Application Servers T= o be able to provide service, the application server needs a list of users = allowed to get services. The application server needs the following pieces of information about each user: 1. User = ID and Credentials 2. Profile to control the level of service provided to t= he user. If one application server provides different services using differ= ent protocols, the application server might need to maintain different identities associated with these protocol= s; e.g. an application server that provides presence service using SIP, and= IM service using XMPP. Ideally, an authorization framework would: 1. Off l= oad the application server from the need to manage the user credentials and authenticating the user. 2. Of= f load the application server from the need to maintain the users and their= profiles to control the level of service provided to the user. 3. Allow th= e assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, = the user ID and credentials will be handled by the authorization server, an= d the application server assignment and the level of service associated wit= h the user will be provided in the scope of the token associated with the user. When the application server r= eceives a request from a user it will have all the details that would allow= the application server to validate the request to make sure it is coming f= rom the right authorization server, and to act upon the request because it has the scope associated with the u= ser, without the need to contact the authorization server. * Relying Party = Regarding the Relying Party question: I think that when the user is being a= uthenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in Open= ID lingo) to access services on behalf of the end user. So, the mapping wou= ld be something like this: +------------------------+----------------------= -------+ | OAuth | SIP | +------------------------+------------------------= -----+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Ser= ver | | Client | SIP UA (Relying Party) | | Authorization Server | Authoriz= ation Server | +------------------------+-----------------------------+


Regards,
=A0Rifaat





=A0
Jon Peterson
Neustar, Inc.





On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of serv= ice
providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

=A0
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't th= ink
you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

=A0
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

=A0
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OT= T
provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
=A0Rifaat


=A0
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if su= ch
>services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing >recording.
>
>=A0 =A0 =A0 =A0Thanks,
>=A0 =A0 =A0 =A0Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>=A0 =A0Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>=A0 =A0 =A0Included is the use case I spoke of before.=A0 My apolog= ies for the
>>delay.
>>
>>=A0 =A0 =A0This is written as though it could be included in
>>=A0 =A0 =A0[draft-yusef-sipcore-sip-oauth] at section 6.
>>
>>
>>=A0 =A0 =A06. Examples
>>
>>=A0 =A0 =A06.1. Example: Call Recording Service
>>
>>=A0 =A0 =A0This example illustrates the use of SIP OAuth between th= ree
>>=A0 =A0 =A0parties:=A0 A hosted VoIP service provider, a Call Recor= ding Service
>>=A0 =A0 =A0provider, and a phone system end-user.=A0 In this exampl= e:
>>=A0 =A0 =A0- The phone system end-user is a customer of both the ho= sted VoIP
>>=A0 =A0 =A0provider and the Call Recording Service provider
>>=A0 =A0 =A0- The hosted VoIP service provider is a standard provide= r of hosted
>>=A0 =A0 =A0business-class VoIP telephone service using SIP
>>=A0 =A0 =A0- The Call Recording Service provider is a distinct enti= ty from the
>>=A0 =A0 =A0hosted VoIP provider
>>
>>=A0 =A0 =A0The Call Recording Service provides to customers both th= e call
>>=A0 =A0 =A0recording abilities and management of call recordings >>=A0 =A0 =A0(configuration, sharing and distribution, retention, etc= .).=A0 This
>>=A0 =A0 =A0service can accept and record RTP traffic, associate all= RTP streams
>>=A0 =A0 =A0with a single call together, and store and catalog the r= ecorded data
>>=A0 =A0 =A0for future searching and retrieval.=A0 The service also = offers a web
>>=A0 =A0 =A0interface where customers may view and retrieve stored c= alls.
>>=A0 =A0 =A0Stored calls may range from simple person-to-person voic= e calls to
>>=A0 =A0 =A0multi-party conferences with a multitude of audio and vi= deo
>>=A0 =A0 =A0streams.=A0 In this example, customers are billed based = on the amount
>>=A0 =A0 =A0of data they store, although other models are certainly = possible.
>>
>>=A0 =A0 =A06.1.1. OAuth 2.0 Roles
>>
>>=A0 =A0 =A0In this example, each party assumes the following OAuth = 2.0 roles as
>>=A0 =A0 =A0defined in [RFC6749] Section 1.1:
>>=A0 =A0 =A0- The end-user assumes the role of resource owner
>>=A0 =A0 =A0- The hosted VoIP service provider assumes the role of c= lient
>>=A0 =A0 =A0- The Call Recording Service provider assumes the role o= f resource
>>=A0 =A0 =A0server as well as the role of authorization server
>>
>>=A0 =A0 =A06.1.2. Description
>>
>>=A0 =A0 =A0There are two parts to the example:=A0 Initial configura= tion and
>>=A0 =A0 =A0real-time recording authorization.
>>
>>=A0 =A0 =A0Each section includes a simplified flow diagram for the = purpose of
>>=A0 =A0 =A0describing the corresponding portion of the example.=A0 = For the sake
>>=A0 =A0 =A0of brevity, certain parts of the OAuth dialog have been = eliminated.
>>=A0 =A0 =A0Implements should refer to [RFC6749] for details on OAut= h.
>>
>>=A0 =A0 =A06.1.2.1 Initial Configuration
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0| CRS Provider |
>>=A0 =A0 =A0 =A0 | Web Browser |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |= =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 1=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Configure CRS)=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 2=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 to CRS Website)=A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 3=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Authorize SIP from VoIP provider= =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-----------------------------------= ------>|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 4=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect back to VoIP porta= l)=A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------------------= ----------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 5=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | HTTP 6=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (Request Access and |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 refresh tokens)=A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |-------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>
>>=A0 =A0 =A0Some time after having signed up for both services, but = prior to
>>=A0 =A0 =A0attempting to record any calls, the end-user logs into t= he web
>>=A0 =A0 =A0portal of the hosted VoIP provider with a web browser an= d configures
>>=A0 =A0 =A0their call recording service (HTTP 1).=A0 This configura= tion includes
>>=A0 =A0 =A0providing a URI where the call recording service may be = reached,
>>=A0 =A0 =A0along with a set of API credentials, provided by the cal= l recording
>>=A0 =A0 =A0service, which will allow the client to initiate an OAut= h exchange.
>>=A0 =A0 =A0The end-user also configures the conditions under which = call
>>=A0 =A0 =A0recordings should take place.=A0 For example, the end-us= er may request
>>=A0 =A0 =A0to record every multi-party (conference) call, or every = call
>>=A0 =A0 =A0involving a specific set of users.=A0 The end-user may a= lso specify
>>=A0 =A0 =A0other restrictions, such as restricting codec negotiatio= n to G.711u
>>=A0 =A0 =A0for audio and H.264 for video in order to record the RTP= streams.
>>=A0 =A0 =A0Once the end-user saves the configuration, the hosted Vo= IP provider
>>=A0 =A0 =A0web portal redirects the end-user's web browser to t= he call
>>=A0 =A0 =A0recording service website and a standard HTTP OAuth dial= og begins
>>=A0 =A0 =A0(HTTP 2).=A0 The end-user authorizes the hosted VoIP pro= vider to
>>=A0 =A0 =A0access (i.e. send SIP and RTP traffic to) the call recor= ding
>>=A0 =A0 =A0service, for the purpose of recording calls, so long as = the
>>=A0 =A0 =A0configured conditions are met (HTTP 3).=A0 The result of= this
>>=A0 =A0 =A0interaction is that the hosted VoIP provider ends up rec= eiving an
>>=A0 =A0 =A0OAuth access token and refresh token from the call recor= ding service
>>=A0 =A0 =A0(HTTP 4, HTTP 5, HTTP 6).=A0 These tokens are saved in t= he end-user's
>>=A0 =A0 =A0hosted VoIP account database.
>>
>>=A0 =A0 =A06.1.2.2 Real-time Recording Authorization
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0 | CRS Provider |
>>=A0 =A0 =A0 =A0 |=A0 SIP Phone=A0 |=A0 =A0 =A0|=A0 =A0 Website=A0 = =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| SIP INVITE 1=A0 =A0 =A0 =A0|=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 2=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 401 Unauthorized |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 3=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with refresh token) |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 1=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (new access token)=A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 4=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 2=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>>=A0 =A0 =A0Independently of and after the initial configuration pha= se, the
>>=A0 =A0 =A0end-user makes a telephone call using the hosted VoIP pr= ovider (SIP
>>=A0 =A0 =A0INVITE 1).=A0 When this call takes place, the hosted VoI= P provider
>>=A0 =A0 =A0looks to see whether it believes this call should be rec= orded.=A0 If
>>=A0 =A0 =A0so, at this point it would branch the call session to th= e call
>>=A0 =A0 =A0recording service, using SIP OAuth to pass the previousl= y provided
>>=A0 =A0 =A0access token for authorization (SIP INVITE 2).=A0 Once t= he access
>>=A0 =A0 =A0token is validated by the call recording service (perhap= s after
>>=A0 =A0 =A0first providing a new access token based on receipt of a= valid
>>=A0 =A0 =A0refresh token), the call recording service will check th= e rights
>>=A0 =A0 =A0that were previously authorized and examine the SIP to d= etermine
>>=A0 =A0 =A0whether it can accept the call.=A0 If so, it completes t= he
>>=A0 =A0 =A0establishment of the session and begins receiving and re= cording the
>>=A0 =A0 =A0RTP stream(s) (SIP 200 OK).=A0 The call recording servic= e provider
>>=A0 =A0 =A0could also deny the request, either because the tokens a= re invalid
>>=A0 =A0 =A0or because the content of
>>=A0 =A0 =A0 =A0the SIP invite does not match the previously authori= zed
>>=A0 =A0 =A0conditions, in which case a SIP 403 would be returned by= the call
>>=A0 =A0 =A0recording service provider and the call would not be rec= orded -
>>=A0 =A0 =A0however, the initial call branch would continue without<= br> >>interruption.
>>
>>=A0 =A0 =A0Note:
>>=A0 =A0 =A0[RFC6749] specifies that when a client uses a refresh to= ken to
>>=A0 =A0 =A0request a new access token, the response is HTTP 200 wit= h the new
>>=A0 =A0 =A0access token and optionally a new refresh token included= in the
>>=A0 =A0 =A0payload.=A0 In this example, a SIP 200 response (SIP 200= 1) is sent
>>=A0 =A0 =A0which contains the new token(s).=A0 However, this could = be confusing
>>=A0 =A0 =A0as SIP 200 is generally viewed as the acceptance of the = INVITE,
>>=A0 =A0 =A0which is not what is happening in this case.=A0 Should S= IP 200 be used
>>=A0 =A0 =A0for consistency, or should another mechanism be used? >>
>>=A0 =A0 =A06.1.3. Justification
>>
>>=A0 =A0 =A06.1.3.1. Hosted VoIP Service Provider
>>
>>=A0 =A0 =A0In this example, the hosted VoIP service provider can al= low their
>>=A0 =A0 =A0customers to enable call recording in their VoIP service= by
>>=A0 =A0 =A0selecting from any of a number of supported call recordi= ng service
>>=A0 =A0 =A0providers.=A0 This allows the hosted VoIP service provid= er to offer
>>=A0 =A0 =A0this feature to customers without requiring that the hos= ted VoIP
>>=A0 =A0 =A0service provider implement and support this feature them= selves.
>>
>>=A0 =A0 =A06.1.3.2. Call Recording Service Provider
>>
>>=A0 =A0 =A0In this example, the Call Recording Service provider can= focus on
>>=A0 =A0 =A0value and innovation in the area of recording calls and = managing
>>=A0 =A0 =A0recorded calls without having to build a full-featured t= elephony
>>=A0 =A0 =A0offering.
>>
>>=A0 =A0 =A06.1.3.3. Customer
>>
>>=A0 =A0 =A0In this example, the customer has more flexibility in ch= oosing a
>>=A0 =A0 =A0complete solution that meets all of the customer needs.= =A0 The
>>=A0 =A0 =A0customer does not have to settle for a substandard call = recording
>>=A0 =A0 =A0service offering in order to obtain other features they = seek in a
>>=A0 =A0 =A0hosted VoIP provider, and vice versa.
>>
>>=A0 =A0 =A06.1.4. Variants
>>
>>=A0 =A0 =A0A simple variant of this example is one wherein one of t= he services
>>=A0 =A0 =A0(either the VoIP service or the call recording service) = is managed
>>=A0 =A0 =A0directly by the end-user, but the other is not.=A0 For e= xample, the
>>=A0 =A0 =A0end-user may wish to make use of an external hosted VoIP= service
>>=A0 =A0 =A0provider, but may have business or legal reasons that fo= rbid the
>>=A0 =A0 =A0end-user from allowing a third party to store and manage= recorded
>>=A0 =A0 =A0calls.=A0 The end-user could choose to set up their own = call recording
>>=A0 =A0 =A0service as described in this example, and use SIP OAuth = to
>>=A0 =A0 =A0facilitate interaction between the hosted VoIP service a= nd the
>>=A0 =A0 =A0end-user's own call recording service.
>>
>>=A0 =A0 =A06.2. Other SIP OAuth examples
>>
>>=A0 =A0 =A0Many other SIP-based services could leverage SIP OAuth t= o provide
>>=A0 =A0 =A0value-added service to an end-user of a hosted VoIP serv= ice
>>=A0 =A0 =A0provider.=A0 Some examples of these types of services ar= e listed
>>below.
>>
>>=A0 =A0 =A0Voicemail service provider:=A0 The end-user configures t= heir hosted
>>=A0 =A0 =A0VoIP service provider to manage voicemail through a sepa= rate
>>=A0 =A0 =A0voicemail service provider, which chooses whether to sto= re voicemail
>>=A0 =A0 =A0based on existing quotas, Caller ID, etc.
>>
>>=A0 =A0 =A0Conferencing service provider:=A0 A conferencing service= may wish to
>>=A0 =A0 =A0bill customers in a more granular fashion, for example, = based on the
>>=A0 =A0 =A0number of participants and attendees in a conference, th= e duration
>>=A0 =A0 =A0of conference, whether video was also included, which co= decs were
>>=A0 =A0 =A0being used, etc. instead of a flat monthly rate.=A0 SIP = OAuth would
>>=A0 =A0 =A0facilitate metered authorization for a client's use = of the service,
>>=A0 =A0 =A0instead of all-or-nothing access.
>>
>>=A0 =A0 =A0Call center service provider:=A0 A third party may provi= de ring groups
>>=A0 =A0 =A0or call queues for a hosted VoIP provider along with det= ailed
>>=A0 =A0 =A0reports and dashboards.=A0 The end-user uses OAuth over = SIP to control
>>=A0 =A0 =A0who can log into which queues or ring groups, etc.
>>
>>
>>
>>=A0 =A0 =A0--
>>=A0 =A0 =A0Matt Ryan
>>=A0 =A0 =A0code slinger | zoomulus.com <http://zoomulus.com>
>>=A0 =A0 =A0ietf at mvryan dot org
>>
>>
>>
>>
>>=A0 =A0 =A0_______________________________________________
>>=A0 =A0 =A0sipcore mailing list
>>=A0 =A0 =A0si= pcore@ietf.org <mailto:sipcore@ietf.org>
>>=A0 =A0 =A0https://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<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

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




--001a11c36748b9b4b00504ef2d25-- From nobody Wed Oct 8 16:19:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC33A1A86EB for ; Wed, 8 Oct 2014 16:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.866 X-Spam-Level: X-Spam-Status: No, score=-100.866 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 KnpQ-_Kc__Zs for ; Wed, 8 Oct 2014 16:19:23 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56AE11A7033 for ; Wed, 8 Oct 2014 16:18:56 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s98NIdGT004384; Wed, 8 Oct 2014 19:18:53 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1pw9648pqn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Oct 2014 19:18:53 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 8 Oct 2014 19:18:52 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLmZYbTlD+FuE+zMNKWASQKqZvhvfeAgAAwjgCADcUOgIABvEuAgAAP2QCADliiAIACroIAgAMzZQCAH5scAIAB3UgA//+52YA= Date: Wed, 8 Oct 2014 23:18:51 +0000 Message-ID: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.128.186] Content-Type: multipart/alternative; boundary="_000_D05B134B134812jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7585 signatures=670543 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410080210 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_aun-PboQBy4bzixZeKFMlJUSHw Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 23:19:25 -0000 --_000_D05B134B134812jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The authentication could be done by an Authorization Server and as a resu= lt the SIP endpoint would be given an ID Token, as per > OpenID, which proves the identity of the end user. The SIP endpoint will = be able to use the ID Token to get access to the user's > box. The voicemail server will be able to identify the user and verify th= e validity of the ID Token because the token has the > signature of an Authorization Server that the voicemail server trusts. Right, this is the authentication property that mechanisms like RFC4474, or= STIR, and to some extend RTCWeb IdP provide. A trusted service gives a chu= nk of signed material to an endpoint, which the endpoint embeds in SIP requ= ests, and that application services would be able to identify the user and = verify that the identity has been checked by the trusted service. > The ID Token could also have a scope that controls the services and level= of service provided to the user. This "scope" is the part that I need to understand better - whether that re= duces to something like the RFC4484 requirements, or if you have something = different in mind, per your statement below as well. Without that, I don't = get what you need beyond authentication. > I care about both, authentication and authorization, and my argument is t= hat an ID Token could be used to provide the needed > user authentication, and the scope associated with the ID Token could be = used to provide the authorization to control access to > services for that specific user. Jon Peterson Neustar, Inc. --_000_D05B134B134812jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <5D1EB0C42B4C634CA91A16075E98311E@neustar.biz> Content-Transfer-Encoding: quoted-printable

> The authentication could be done by an Authorization Server and a= s a result the SIP endpoint would be given an ID Token, as per
> OpenID, which proves the identity of the end user. The SIP endpoi= nt will be able to use the ID Token to get access to the user's 
> box. The voicemail server will be able to identify the user and v= erify the validity of the ID Token because the token has the 
> signature of an Authorization Server that the voicemail server tr= usts.

Right, this is the authentication property that mechanisms like RFC447= 4, or STIR, and to some extend RTCWeb IdP provide. A trusted service gives = a chunk of signed material to an endpoint, which the endpoint embeds in SIP= requests, and that application services would be able to identify the user and verify that the identity h= as been checked by the trusted service.

> The ID Token could also have a scope that controls the services a= nd level of service provided to the user.

This "scope" is the part that I need to understand better - = whether that reduces to something like the RFC4484 requirements, or if you = have something different in mind, per your statement below as well. Without= that, I don't get what you need beyond authentication.

> I care about both, authentication and authorization, and my argum= ent is that an ID Token could be used to provide the needed
> user authentication, and the scope associated with the ID Token c= ould be used to provide the authorization to control access to
> services for that specific user.

Jon Peterson
Neustar, Inc.
--_000_D05B134B134812jonpetersonneustarbiz_-- From nobody Thu Oct 9 12:28:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AED41A6ED8 for ; Thu, 9 Oct 2014 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 33YHCYDyyqCa for ; Thu, 9 Oct 2014 12:28:05 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F42A1A1BEC for ; Thu, 9 Oct 2014 12:28:04 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so1897959lab.19 for ; Thu, 09 Oct 2014 12:28:03 -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:content-type; bh=H86BbuVvujRP9l8biDBF2gq8U2Q2XhqQqkqc2WB/hxE=; b=e/+mF/ioqfnuPR9K3Urnm+n7QYny/3twOzgOYzckalipxVqEbbkSpq/2jScxAbmbuk K7OIzlo2ZJzK5KoyiNMESfRVVxwAnGyC2ji3hKmacebFQrxkc7bt1N0tlNZCg4rQ7T5n udkz02pe/ksbmMkgHP37tRZ0+/k9BJclmO4B3gfMtl+3cg30vKHAleD6m1PeYupsvHxD eHgUrMBu0Nyak1uhWnHcod9HKvhgTRUsD0suFW5nmATP5H7yIA96gIk2k3BNmc2/Q1N1 DM96E0ms5tHIYbH8TKWDy6TVkB91SGQCRJHVyN4ma0sYJMIHR1+LT2JLfs0d9J/DJH9K qwtA== MIME-Version: 1.0 X-Received: by 10.112.135.230 with SMTP id pv6mr12480225lbb.105.1412882883400; Thu, 09 Oct 2014 12:28:03 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Thu, 9 Oct 2014 12:28:03 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> Date: Thu, 9 Oct 2014 15:28:03 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=089e0117716f5fd7650505026e47 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VnMhhro7_0SxgA38xElXXnMTvjc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 19:28:07 -0000 --089e0117716f5fd7650505026e47 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 8, 2014 at 7:18 PM, Peterson, Jon wrote: > > > The authentication could be done by an Authorization Server and as > a result the SIP endpoint would be given an ID Token, as per > > OpenID, which proves the identity of the end user. The SIP endpoint > will be able to use the ID Token to get access to the user's > > box. The voicemail server will be able to identify the user and verify > the validity of the ID Token because the token has the > > signature of an Authorization Server that the voicemail server trusts. > > Right, this is the authentication property that mechanisms like RFC4474, > or STIR, and to some extend RTCWeb IdP provide. > I need to educate myself more about RFC4474/STIR and RTCWeb IdP. > A trusted service gives a chunk of signed material to an endpoint, which > the endpoint embeds in SIP requests, and that application services would be > able to identify the user and verify that the identity has been checked by > the trusted service. > Exactly. OpenID adds Authentication to the OAuth 2.0 Authorization Framework by introducing the ID Token structure to authenticate the end user. > > > The ID Token could also have a scope that controls the services and > level of service provided to the user. > > This "scope" is the part that I need to understand better - whether that > reduces to something like the RFC4484 requirements, or if you have > something different in mind, per your statement below as well. Without > that, I don't get what you need beyond authentication. > I briefly looked at RFC4484, section 5 (requirements), and it seems like a reasonable approach. I think that the framework should be flexible enough to allow different scopes and claims to be associated with the user, but leave the content as implementation detail. Now if I to use RFC4484 terminology, and if I understood RFC4484 correctly, then the combination of an Assertion that proves the identity of the user, and the Traits that are associated with the Assertion, should allow the system to provide the user with only one identity and allow that user access to a variety of SIP *and* non-SIP services in the network. Correct? Regards, Rifaat > > > I care about both, authentication and authorization, and my argument > is that an ID Token could be used to provide the needed > > user authentication, and the scope associated with the ID Token could > be used to provide the authorization to control access to > > services for that specific user. > > Jon Peterson > Neustar, Inc. > --089e0117716f5fd7650505026e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 8, 2014 at 7:18 PM, Peterson, Jon <jon.peterson@neu= star.biz> wrote:

> The authentication could be done by an Authorization Server and a= s a result the SIP endpoint would be given an ID Token, as per
> OpenID, which proves the identity of the end user. The SIP endpoi= nt will be able to use the ID Token to get access to the user's=A0
> box. The voicemail server will be able to identify the user and v= erify the validity of the ID Token because the token has the=A0
> signature of an Authorization Server that the voicemail server tr= usts.

Right, this is the authentication property that mechanisms like= RFC4474, or STIR, and to some extend RTCWeb IdP provide.

I need to educate myself more about RFC4474/STIR= and RTCWeb IdP.
=A0

=A0
A trusted service gives a chunk of signed material t= o an endpoint, which the endpoint embeds in SIP requests, and that applicat= ion services would be able to identify the user and verify that the identity h= as been checked by the trusted service.

Exactly.
OpenID adds Authentication to the OAuth 2.0 Aut= horization Framework by introducing the ID Token structure to authenticate = the end user.

=A0

> The ID Token could also have a scope that controls the services a= nd level of service provided to the user.

This "scope" is the part that I need to understand be= tter - whether that reduces to something like the RFC4484 requirements, or = if you have something different in mind, per your statement below as well. = Without that, I don't get what you need beyond authentication.

I briefly looked at RFC4484, section 5 = (requirements), and it seems like a reasonable approach.
I th= ink that the framework should be flexible enough to allow different scopes = and claims to be associated with the user, but leave the content as impleme= ntation detail.

Now if I to use RFC4484 terminolog= y, and if I understood RFC4484 correctly, then the combination of an Assert= ion that proves the identity of the user, and the Traits that are associate= d with the=A0Assertion, should allow the system to provide the user with=A0= only one identity and allow that user access to a variety of SIP and= non-SIP services in the network. Correct?

Regards= ,
=A0Rifaat


=A0
=

> I care about both, authentication and authorization, and my argum= ent is that an ID Token could be used to provide the needed
> user authentication, and the scope associated with the ID Token c= ould be used to provide the authorization to control access to
> services for that specific user.

Jon Peterson
Neustar, Inc.

--089e0117716f5fd7650505026e47-- From nobody Thu Oct 9 13:38:37 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECD01A8771 for ; Thu, 9 Oct 2014 13:38:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 TGL1-y5QGLve for ; Thu, 9 Oct 2014 13:38:33 -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 ACC761A8770 for ; Thu, 9 Oct 2014 13:38:31 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-9e-5436f245f116 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.36.04387.542F6345; Thu, 9 Oct 2014 22:38:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 22:38:29 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLkDukB9S5lmka5p3A9Sdf1J5vhWWKAgAAwjgCADjpnAIABRvKAgACFNgCADeNFAIADI96AgAK+CQCADNdi4IATE0cAgAM98SA= Date: Thu, 9 Oct 2014 20:38:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4716FE@ESESSMB209.ericsson.se> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4716FEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rtftk1mIwQpZizMNlhY7X7SyWXz9 sYnNgdlj56y77B5Llvxk8tjR8Jw5gDmKyyYlNSezLLVI3y6BK6Pl9Gb2gv/9jBV/jy5nbWC8 V9/FyMkhIWAisW3dKyYIW0ziwr31bF2MXBxCAkcZJT6deQnlLGaUeNfziLmLkYODTcBCovuf NkiDiICeRPvfhWDNzALhEn2bellAbGEBbYmf564xQtToSPxp/MkGYZdJfHj0jB3EZhFQkbjS Pxesl1fAV+L38qVMELu6WSX+rtoG1swpECix5fsRsCJGoOu+n1oDtUxc4taT+VBXC0gs2XOe GcIWlXj5+B8rhK0ksWL7JUaI+nyJ+ycPsEAsE5Q4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5P bBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYgwe3/Lba wXjwueMhRgEORiUe3gQVsxAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAoICsnXb7oQpB2sqOmbkMrr8fn2zOWsk4V53nr82v6m71Vu3q2t8keiz0red+T PeajD/fulEf3Ps03/FO9bvHDtU9Cai2/6X+Jny0kmcEuKxC3Qb1XsuHOg20u7+2/XNj4/5eN zcyvbW2WavuXplTs1xAI5j7H+ynd+lVU76ukF56bWFesaGRUYinOSDTUYi4qTgQAB+kTYaIC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/eJPcGUOxpwMRtm6_l9b8oLAyp84 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 20:38:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4716FEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >I am not clear on the flow of messages in your case. >Can you please provide a high level diagram that describes that flow? The user contacts the WWSF, and uses normal web credentials (e.g. username = + password) to request an access token from the WWSF/WAF, using HTTP. The u= ser then sends then includes the access token in the SIP REGISTER request. So, as far as the flow is concerned, I guess the main difference from your = draft is that the user does not retrieve the access token using SIP, but us= ing HTTP. >Also, the token that is returned by the WAF to the SIP endpoint; is it >an= access token, as per OAuth 2.0, or a user token (ID Token), as per >OpenID= ? An access token. Regards, Christer Hi, >What I am proposing is something along the lines of OpenID, which extends = the OAuth to >authenticate the *user*. >In this case, the mapping between OAuth and SIP would be something like th= e following: > >OAuth SIP >--------------------------------------------------------------------------= - >Resource Owner End User >Resource Server SIP Proxy or SIP Application Server >Client SIP UA >Authorization Server Authorization Server > >Do you see a problem with this model? As I indicated earlier, this is a little different mapping than the one don= e by 3GPP. OAuth role IMS role Resource Owner IMS subscriber Client WWSF Authorization Server WAF Resource Server IMS network (copied text) WWSF (WebRTC Web Server Function) - Acts as web server, from where the user downloads the IMS access= application. WAF (WebRTC Authorisation Function) - Acts as the authorization server (the "facebook"), and issues th= e authorization tokens. (The WWSF and WAF can, but does not have to, be located in the same domain = as the IMS provider.) I guess the important thing to note here is that the IMS core network (incl= uding the registrar/S-CSCF and HSS) does not act as Authorization Server, b= ut rather as the Resource Server. In fact, the IMS core network itself does not even need to support OAuth2.0= . Instead the WAF performs mapping and verification between "legacy IMS cre= dentials" and "web credentials" (e.g. OAuth2.0). The detailed procedures fo= r that mapping/verification is not specified in the current 3GPP release. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4716FEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

>I am not cl= ear on the flow of messages in your case. 

>Can you ple= ase provide a high level diagram that describes that flow?

 

The user contacts the WWS= F, and uses normal web credentials (e.g. username + password) to reques= t an access token from the WWSF/WAF, using HTTP. The user then sends then includes the access token in the SIP REGISTER request.

 <= /p>

So, as far as the flow is= concerned, I guess the main difference from your draft is that the user do= es not retrieve the access token using SIP, but using HTTP.

 <= /p>

>Also, the t= oken that is returned by the WAF to the SIP endpoint; is it >an access token, as per OAuth 2.0,= or a user token (ID Token), as per >OpenID?

 

An access token.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

Hi,

 

>What I am proposing is so= mething along the lines of OpenID, which extends the OAuth to >authenticate the *user*.

>In this case, the mapping= between OAuth and SIP would be something like the following:

> 

>OAuth      = ;                     &nb= sp;        SIP

>-------------------------= --------------------------------------------------

>Resource Owner   &nb= sp;                End User

>Resource Server   &n= bsp;                SIP Proxy or SI= P Application Server

>Client     &nbs= p;                     &n= bsp;         SIP UA

>Authorization Server &nbs= p;           Authorization Server

> 

>Do you see a problem with= this model?

 

As I indicated earlier, this is a littl= e different mapping than the one done by 3GPP.

 

OAuth role    &n= bsp;            = ;            &n= bsp;       IMS role

 

Resource Owner    &= nbsp;           &nbs= p;          IMS subscriber

Client     &nb= sp;            =             &nb= sp;            =     WWSF

Authorization Server   &= nbsp;           &nbs= p;    WAF

Resource Server    =             &nb= sp;           IMS network=

 

(copied text)

 

WWSF (WebRTC Web Server Function)

-      &nb= sp;   Acts as web server, from where the user downloads th= e IMS access application.

WAF (WebRTC Authorisation Function)

-      &nb= sp;   Acts as the authorization server (the “faceboo= k”), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be located in the sam= e domain as the IMS provider.)

 

I guess the important thing to note here is that the IMS core netw= ork (including the registrar/S-CSCF and HSS) does not act as Authorization = Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even need to support= OAuth2.0. Instead the WAF performs mapping and verification between “= ;legacy IMS credentials” and “web credentials” (e.g. OAuth2.0). The detailed procedures for that mapping/verification is = not specified in the current 3GPP release.

 

Regards,

 

Christer

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4716FEESESSMB209erics_-- From nobody Fri Oct 10 06:26:35 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F581ACE02 for ; Fri, 10 Oct 2014 06:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 gR-l5ToBmlIM for ; Fri, 10 Oct 2014 06:26:28 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681C61ACDFE for ; Fri, 10 Oct 2014 06:26:28 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so3011721lbv.26 for ; Fri, 10 Oct 2014 06:26:26 -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:content-type; bh=Me6yb3QiXG8b2SiL0Mnz3f/6YNf2UvIN4FRDp1AZVrw=; b=t7QlzrlhBx45hRFo16gur55cfPLgxGBaCZ8RBEUxjSN5Y1KRHnShEYbg2j5eQSY7qg VPzEkzLzh+cHwPcpnEdGQQJ1jn+LZhzd5tKY6oRboBVhSIp2VsTqLWibXvDStF4b7gAJ jtqbexvue8YfFPE8ATq6FlWvwlBIXVj68ADAvtYCHo0mjWiJBxbSGuaA7nUuqEPTtGDy 3awQZFvQvZAD7uvfiRgi2Tl9IHraN8cYFU+1DKL5xMaAH/VqHYoDRXIfLRCLnPmn9OJF 3nfnrlk14PM2LOP7pct8TBAuniZJBvHNChIls3Ch1tHNgy9PgG4C2ZkNnCqU6bSIzn05 6eoQ== MIME-Version: 1.0 X-Received: by 10.152.36.67 with SMTP id o3mr4893371laj.45.1412947586751; Fri, 10 Oct 2014 06:26:26 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Fri, 10 Oct 2014 06:26:26 -0700 (PDT) Date: Fri, 10 Oct 2014 09:26:26 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b78efea2f40505117e3a Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QnOUy0NdmA8pBW3F9P_PKdAz8mo Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 13:26:33 -0000 --089e0158b78efea2f40505117e3a Content-Type: text/plain; charset=ISO-8859-1 Hi, During the IETF conference in London and as a response to my presentation of the update to the SIP Digest, there was interest in the room for exploring better schemes than the existing Digest scheme. I have just submitted an draft that describes a new proposal for an authentication scheme that is based on the PBKDF2 function, to replace the Digest scheme used by SIP today. I would really appreciate it if people review it and provide comments. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Fri, Oct 10, 2014 at 9:19 AM Subject: New Version Notification for draft-yusef-sipcore-key-derivation-00.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-key-derivation Revision: 00 Title: Key-Derivation Authentication Scheme Document date: 2014-10-10 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/ Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00 Abstract: This document defines a Key-Derivation Authentication Scheme, based on the PBKDF2 Key Derivation Function (KDF), that could be used with the challenge-response authentication framework used by SIP to authenticate the user. The scheme allows two parties to establish a mutually authenticated communication channel based on a shared password, without ever sending the password on the wire. 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. The IETF Secretariat --089e0158b78efea2f40505117e3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

During the IETF conferen= ce in London and as a response to my presentation of the update to the SIP = Digest, there was interest in the room for exploring better schemes than th= e existing Digest scheme.

I have just submitted an= draft that describes a new proposal for an authentication scheme that is b= ased on the PBKDF2 function, to replace the Digest scheme used by SIP today= .

I would really appreciate it if people review it= and provide comments.

Regards,
=A0Rifaa= t




---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Oct 10, 2014 = at 9:19 AM
Subject: New Version Notification for draft-yusef-sipcore-key= -derivation-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcore-key-derivation
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 Key-Derivation Authentication Scheme
Document date:=A0 2014-10-10
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 8
URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.ietf.= org/doc/draft-yusef-sipcore-key-derivation/
Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-yusef-sipcore-key-derivation-00


Abstract:
=A0 =A0This document defines a Key-Derivation Authentication Scheme, based<= br> =A0 =A0on the PBKDF2 Key Derivation Function (KDF), that could be used with=
=A0 =A0the challenge-response authentication framework used by SIP to
=A0 =A0authenticate the user.

=A0 =A0The scheme allows two parties to establish a mutually authenticated<= br> =A0 =A0communication channel based on a shared password, without ever
=A0 =A0sending the password on the wire.





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

The IETF Secretariat


--089e0158b78efea2f40505117e3a-- From nobody Fri Oct 10 10:21:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966491A6FB8 for ; Fri, 10 Oct 2014 10:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 exB1-xi-aLL1 for ; Fri, 10 Oct 2014 10:21:23 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9158B1A88F2 for ; Fri, 10 Oct 2014 10:21:20 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so3641318lab.15 for ; Fri, 10 Oct 2014 10:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GInnMd6jv9NDAs2mC1Hr8deU8VMgpdKPdZXop5+n2Pk=; b=rW8ZYpBbW23s8Vrs0VhWnTJ0RYuqh+qpziLUAx9SiIasWE+B3Vu16o6ih/K/x8q2yp IHm6hsMHnvrbbXIQPjfjJI1+FBI9aJqUJ+rafup1EyJLcz04EgXmidCxstsEyxEO4QcI D/iBTcFfL3jiY/wOvGL7lULZaPOGyp6Rsid+ycqhALytvmhN+x3Fom4+JcNroZ7JDRki 6ZG3zqpFyDg/nRjMeXVOayx/NxMuKojc6VEGEMsyMeW17zd2ekjGpFRM4NQ73nAT/bcB fKbvUwqx7KZq8RoXXmwOqrZ+PINetdSaBg6oxWmj305JYjtoMsvMwLu/rxbSJL2meui7 5TUg== MIME-Version: 1.0 X-Received: by 10.152.36.67 with SMTP id o3mr6394425laj.45.1412961678813; Fri, 10 Oct 2014 10:21:18 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Fri, 10 Oct 2014 10:21:18 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4716FE@ESESSMB209.ericsson.se> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4716FE@ESESSMB209.ericsson.se> Date: Fri, 10 Oct 2014 13:21:18 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158b78ef2708e050514c696 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/nz0-chwP8Hq3wUVAJWAVtLeLoUc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:21:26 -0000 --089e0158b78ef2708e050514c696 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 9, 2014 at 4:38 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >I am not clear on the flow of messages in your case. > > >Can you please provide a high level diagram that describes that flow? > > > > The user contacts the WWSF, and uses normal web credentials (e.g. username > + password) to request an access token from the WWSF/WAF, using HTTP. > This is the part I am still trying to understand. Can you please elaborate on this? > The user then sends then includes the access token in the SIP REGISTER > request. > > > > So, as far as the flow is concerned, I guess the main difference from your > draft is that the user does not retrieve the access token using SIP, but > using HTTP. > > > In my draft, the only case that the endpoint uses SIP to get a token is when the endpoint is getting the token from the registrar (using the Resources Owner Password Credentials grant); otherwise, the endpoint uses HTTP. > >Also, the token that is returned by the WAF to the SIP endpoint; is it > >an access token, as per OAuth 2.0, or a user token (ID Token), as per > > OpenID? > > > > An access token. > > > > Regards, > > > > Christer > > > > Hi, > > > > >What I am proposing is something along the lines of OpenID, which > extends the OAuth to >authenticate the *user*. > > >In this case, the mapping between OAuth and SIP would be something like > the following: > > > > > >OAuth SIP > > > > --------------------------------------------------------------------------- > > >Resource Owner End User > > >Resource Server SIP Proxy or SIP Application Server > > >Client SIP UA > > >Authorization Server Authorization Server > > > > > >Do you see a problem with this model? > > > > As I indicated earlier, this is a little different mapping than the one > done by 3GPP. > > > > *OAuth role IMS role* > > > > Resource Owner IMS subscriber > > Client WWSF > > Authorization Server WAF > > Resource Server IMS network > > > > (copied text) > > > > WWSF (WebRTC Web Server Function) > > - Acts as web server, from where the user downloads the IMS > access application. > > WAF (WebRTC Authorisation Function) > > - Acts as the authorization server (the "facebook"), and issues > the authorization tokens. > > > > (The WWSF and WAF can, but does not have to, be located in the same domain > as the IMS provider.) > > > > I guess the important thing to note here is that the IMS core network > (including the registrar/S-CSCF and HSS) does not act as Authorization > Server, but rather as the Resource Server. > > > > In fact, the IMS core network itself does not even need to support > OAuth2.0. Instead the WAF performs mapping and verification between "legacy > IMS credentials" and "web credentials" (e.g. OAuth2.0). The detailed > procedures for that mapping/verification is not specified in the current > 3GPP release. > > > > Regards, > > > > Christer > > > > > > > > > --089e0158b78ef2708e050514c696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 9, 2014 at 4:38 PM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,<= /p>

 

>I am not cl= ear on the flow of messages in your case. 

>Can you ple= ase provide a high level diagram that describes that flow?

 

The user contacts the WWS= F, and uses normal web credentials (e.g. username + password) to request an= access token from the WWSF/WAF, using HTTP.

<= /div>

This is the part I am still trying to= understand. Can you please elaborate on this?

&nb= sp;

The user then sends then includes the access token in the SIP REGISTER request.

 

So, as far as the flow is= concerned, I guess the main difference from your draft is that the user do= es not retrieve the access token using SIP, but using HTTP.

 

<= /div>

In my draft, the on= ly case that the endpoint uses SIP to get a token is when the endpoint is g= etting the token from the registrar (using the Resources Owner Password Cre= dentials grant); otherwise, the endpoint uses HTTP.

 

>Also, the t= oken that is returned by the WAF to the SIP endpoint; is it >an access token, as per OAuth 2.0,= or a user token (ID Token), as per >OpenID?

 

An access token.

 

Regards,

 

Christer

 

Hi,<= /p>

 

>What I am p= roposing is something along the lines of OpenID, which extends the OAuth to >authenticate the *user*.=

>In this cas= e, the mapping between OAuth and SIP would be something like the following:=

> 

>OAuth  = ;                     &nb= sp;            SIP

>-----------= ----------------------------------------------------------------<= /u>

>Resource Ow= ner                    En= d User

>Resource Se= rver                    S= IP Proxy or SIP Application Server

>Client &nbs= p;                     &n= bsp;             SIP UA

>Authorizati= on Server             Authorization Server=

> 

>Do you see = a problem with this model?

 

As I indicated earlier, t= his is a little different mapping than the one done by 3GPP.<= u>

 

OAuth role  =             &nb= sp;            =           IMS role<= u>

 

Resource Owner  = ;            &n= bsp;            IMS = subscriber

Client   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      WWSF

Authorization Server = ;            &n= bsp;      WAF

Resource Server &nbs= p;            &= nbsp;           &nbs= p; IMS network

 

(copied text)

 

WWSF (WebRTC Web Server Function)

-      &nb= sp;   Acts as web server, from where the user downloads th= e IMS access application.

WAF (WebRTC Authorisation Function)

-      &nb= sp;   Acts as the authorization server (the “faceboo= k”), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be loca= ted in the same domain as the IMS provider.)

 

I guess the important thing to note here is that the= IMS core network (including the registrar/S-CSCF and HSS) does not act as = Authorization Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even n= eed to support OAuth2.0. Instead the WAF performs mapping and verification = between “legacy IMS credentials” and “web credentials&rdq= uo; (e.g. OAuth2.0). The detailed procedures for that mapping/verification is = not specified in the current 3GPP release.

 

Regards,

 

Christer=

 

 

 

 


--089e0158b78ef2708e050514c696-- From nobody Fri Oct 10 10:38:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2491A9029 for ; Fri, 10 Oct 2014 10:38:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 D2JqgMicp2hY for ; Fri, 10 Oct 2014 10:38:10 -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 543B01A9031 for ; Fri, 10 Oct 2014 10:38:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-ad-5438197fc3ea Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.0D.04387.F7918345; Fri, 10 Oct 2014 19:38:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 19:38:06 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLkDukB9S5lmka5p3A9Sdf1J5vhWWKAgAAwjgCADjpnAIABRvKAgACFNgCADeNFAIADI96AgAK+CQCADNdi4IATE0cAgAM98SCAAT/CAIAAJA7w Date: Fri, 10 Oct 2014 17:38:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D475248@ESESSMB209.ericsson.se> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4716FE@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D475248ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvjW69pEWIwZwbKhZnGiwtdr5oZbP4 +mMTmwOzx85Zd9k9liz5yeSxo+E5cwBzFJdNSmpOZllqkb5dAlfG768PWAqe7GOsaNwxg7WB cf9Kxi5GTg4JAROJOyevsEPYYhIX7q1n62Lk4hASOMooMeXPf0YIZwmjxPs/DaxdjBwcbAIW Et3/tEEaRAT0JNr/LmQCsZkFwiX6NvWygNjCAtoSP89dY4So0ZH40/iTDcJuYpTY1BIBYrMI qEp83jwFrIZXwFdi3//PTBC7prFJ/L/UBzaIUyBQ4sW2nawgNiPQdd9PrYFaJi5x68l8Joir BSSW7DnPDGGLSrx8/I8VwlaSaFzyhBWiPl/i1qYD7BDLBCVOznzCMoFRdBaSUbOQlM1CUgYR 15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG 4cEtv612MB587niIUYCDUYmHd4GteYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamB0S6zuiejUiNffe3trxPSrTW++r11oErDmqaHMG4PJS4o2rZn7xMn2 GL+HlrOe+qVJhofuH3LI4hDVffrkiMk/k+6IOek5hm1xzO1/emxYX2xtu7l73lrRv1LbxA+9 bs17nLpub0Ae62Kn+0Z993m9NrVVli6T8G35HhE6VS16/rGNRXMPMp1QYinOSDTUYi4qTgQA fOLO2aQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/l0kMmYDJOT7ND2wQUJ0T5XQDmiI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:38:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D475248ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >I am not clear on the flow of messages in your case. >Can you please provide a high level diagram that describes that flow? The user contacts the WWSF, and uses normal web credentials (e.g. username = + password) to request an access token from the WWSF/WAF, using HTTP. This is the part I am still trying to understand. Can you please elaborate = on this? The user (acting as the OA2 resource owner) downloads the IMS webpage from = the WWSF (acting as the OA2 client), using HTTP. The WWSF requests an acces= s token from the WAF (acting as the OA2 authorization server), which mainta= ins the mapping between the users's web credentials and IMS credentials (ho= w that mapping is managed is outside the scope of the current 3GPP release)= . That access token is then provided to the user, which includes it in the SI= P REGISTER, in order to get access to the IMS network service (acting as th= e OA2 resource server). Regards, Christer The user then sends then includes the access token in the SIP REGISTER requ= est. So, as far as the flow is concerned, I guess the main difference from your = draft is that the user does not retrieve the access token using SIP, but us= ing HTTP. In my draft, the only case that the endpoint uses SIP to get a token is whe= n the endpoint is getting the token from the registrar (using the Resources= Owner Password Credentials grant); otherwise, the endpoint uses HTTP. >Also, the token that is returned by the WAF to the SIP endpoint; is it >an= access token, as per OAuth 2.0, or a user token (ID Token), as per >OpenID= ? An access token. Regards, Christer Hi, >What I am proposing is something along the lines of OpenID, which extends = the OAuth to >authenticate the *user*. >In this case, the mapping between OAuth and SIP would be something like th= e following: > >OAuth SIP >--------------------------------------------------------------------------= - >Resource Owner End User >Resource Server SIP Proxy or SIP Application Server >Client SIP UA >Authorization Server Authorization Server > >Do you see a problem with this model? As I indicated earlier, this is a little different mapping than the one don= e by 3GPP. OAuth role IMS role Resource Owner IMS subscriber Client WWSF Authorization Server WAF Resource Server IMS network (copied text) WWSF (WebRTC Web Server Function) - Acts as web server, from where the user downloads the IMS access= application. WAF (WebRTC Authorisation Function) - Acts as the authorization server (the "facebook"), and issues th= e authorization tokens. (The WWSF and WAF can, but does not have to, be located in the same domain = as the IMS provider.) I guess the important thing to note here is that the IMS core network (incl= uding the registrar/S-CSCF and HSS) does not act as Authorization Server, b= ut rather as the Resource Server. In fact, the IMS core network itself does not even need to support OAuth2.0= . Instead the WAF performs mapping and verification between "legacy IMS cre= dentials" and "web credentials" (e.g. OAuth2.0). The detailed procedures fo= r that mapping/verification is not specified in the current 3GPP release. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D475248ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I am not clear on the flo= w of messages in your case. 

>Can you please provide a = high level diagram that describes that flow?

 

The user contacts the WWSF, and uses no= rmal web credentials (e.g. username + password) to request an access token from the WWSF/WAF, using HTTP.

 

This is the part I am still trying to understand. Ca= n you please elaborate on this?

 

The user (acting as the O= A2 resource owner) downloads the IMS webpage from the WWSF (acting as the O= A2 client), using HTTP. The WWSF requests an access token from the WAF (acting as the OA2 authorization server), which maintains the= mapping between the users’s web credentials and IMS credentials (how= that mapping is managed is outside the scope of the current 3GPP release).=

 <= /p>

That access token is then= provided to the user, which includes it in the SIP REGISTER, in order to g= et access to the IMS network service (acting as the OA2 resource server).

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

 

The user then sends then includes the a= ccess token in the SIP REGISTER request.

 

So, as far as the flow is concerned, I = guess the main difference from your draft is that the user does not retrieve the access token using SIP, but using HTTP.<= /o:p>

 

 

In my draft, the only case that the endpoint uses SI= P to get a token is when the endpoint is getting the token from the registr= ar (using the Resources Owner Password Credentials grant); otherwise, the e= ndpoint uses HTTP.

 

 

>Also, the token that is r= eturned by the WAF to the SIP endpoint; is it >an access token, as per OAuth 2.0,= or a user token (ID Token), as per >OpenID?

 

An access token.

 

Regards,

 

Christer

 

Hi,

 

>What I am proposing is so= mething along the lines of OpenID, which extends the OAuth to >authenticate the *user*.

>In this case, the mapping= between OAuth and SIP would be something like the following:

> 

>OAuth      = ;                     &nb= sp;        SIP

>-------------------------= --------------------------------------------------

>Resource Owner   &nb= sp;                End User

>Resource Server   &n= bsp;                SIP Proxy or SI= P Application Server

>Client     &nbs= p;                     &n= bsp;         SIP UA

>Authorization Server &nbs= p;           Authorization Server

> 

>Do you see a problem with= this model?

 

As I indicated earlier, this is a littl= e different mapping than the one done by 3GPP.

 

OAuth role    &n= bsp;            = ;            &n= bsp;       IMS role

 

Resource Owner    &= nbsp;           &nbs= p;          IMS subscriber

Client     &nb= sp;            =             &nb= sp;            =     WWSF

Authorization Server   &= nbsp;           &nbs= p;    WAF

Resource Server    =             &nb= sp;           IMS network=

 

(copied text)

 

WWSF (WebRTC Web Server Function)

-      &nb= sp;   Acts as web server, from where the user downloads th= e IMS access application.

WAF (WebRTC Authorisation Function)

-      &nb= sp;   Acts as the authorization server (the “faceboo= k”), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be located in the sam= e domain as the IMS provider.)

 

I guess the important thing to note here is that the IMS core netw= ork (including the registrar/S-CSCF and HSS) does not act as Authorization = Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even need to support= OAuth2.0. Instead the WAF performs mapping and verification between “= ;legacy IMS credentials” and “web credentials” (e.g. OAuth2.0). The detailed procedures for that mapping/verification is = not specified in the current 3GPP release.

 

Regards,

 

Christer

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D475248ESESSMB209erics_-- From nobody Fri Oct 10 11:48:40 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D51ACD5D for ; Fri, 10 Oct 2014 11:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 9Uk9hYFzq5GS for ; Fri, 10 Oct 2014 11:48:36 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDBD1ACD2D for ; Fri, 10 Oct 2014 11:48:36 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with comcast id 1WoB1p0042TL4Rh01WoclT; Fri, 10 Oct 2014 18:48:36 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-17v.sys.comcast.net with comcast id 1Wob1p00F1KKtkw01WobRz; Fri, 10 Oct 2014 18:48:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9AImYtT016995; Fri, 10 Oct 2014 14:48:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9AImYvC016994; Fri, 10 Oct 2014 14:48:34 -0400 Date: Fri, 10 Oct 2014 14:48:34 -0400 Message-Id: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412966916; bh=VOqCMZSStmNhbVR6MYZV2bFTBQq+gMvxB1K8kSPXiYQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=JnnsGNu6T6q0qVcj6D2bdqHxwHm2DmTmMg1YV5iFUpBoba1gPm2BvCYuV5POIk/4D XbAehecXw2gxd0xCwBPvgetFOBZdo78GIaY5Zb/N/L2lqVzjhmouqk9U/SFw50I6sd /yGVVuPbdath0d7l9PaIiLpxJm1rucgVJQ/fFlDNGJqW/XTj8GbLDNSyXL+ZRBDw27 et1NLU6RXoAZPN6v+BWbgJykeCVRKTtIEdyHwSi9yovLfFPYFHuq9NH9RIR9NEQB99 NiB8RU0egqJt1J1EnpIF4bbRmLotMWYrQvTz+zT2i3CwFtMmhVgpOlgJxVPiIx4T1i d4G2YSxcLbVPw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/qpeaQWrgRUW9bwmhWXPkC7LtHE8 Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:48:39 -0000 > Name: draft-yusef-sipcore-key-derivation It's an interesting proposal. The most important thing is that I'd like to see a section that describes the motivation, that is, why this is method better than the current digest scheme. (Laying out the case is something that could progress before tidying the technical presentation.) There are a bunch of parameters to this algorithm, and it would be helpful to know what are the considerations that drive the choice of parameter values. This is especially true for the iteration-count; the NIST document proposes a range of 1,000 to 10,000,000, but the computation power that a typical phone can apply to the problem is limited. (Also, is the master-key recomputed just once when the phone is reconfigured with a new password, or with every message? For that matter, how does the phone obtain the salt and iteration count when it is configured?) Given the large number of parameters, it would be helpful to have a small number of particular choices/combinations that are proposed for use. I see: - nonce length - the hash function used in the KDF - the salt length - the iteration count - the length of the generated master key Looking at the diagram on page 4, it appears that message 2 (Challenge) contains "pop" which is computed as "HMAC-SHA256(master-key, digest-string + nonce)". Message 3 (Response) contains "pop" which is also shown being computed as "HMAC-SHA256(master-key, digest-string + nonce)", which the server is supposed to verify, even though it appears that that value was transmitted in the clear in message 2. I'm pretty sure that the issue is that the first "digest-string" is the digest string of message 1 (the original request), whereas the second one is the digest string of message 3. But the notation should make that clear. For that matter, the notation should make clear which bulleted items are computations, which are tests, which data items are retrieved from local memory, which are random numbers constructed at the moment, etc. Message 4 contains "token", but there is no definition of that. Indeed, if this scheme is meant only to provide mutual agreement on a cryptographically stronger key to be input to digest authentication, there isn't any "token", is there? Dale From nobody Sat Oct 11 03:57:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4081A02E9 for ; Sat, 11 Oct 2014 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 Jq8ikYIM3XCp for ; Sat, 11 Oct 2014 03:57:43 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682CE1A02DF for ; Sat, 11 Oct 2014 03:57:43 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so4473702lab.20 for ; Sat, 11 Oct 2014 03:57: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:content-type; bh=cT3sOsNlbmf2AxtqCi/K8FXz3GRH6IGCThQBdURJQeU=; b=IbUkSxB02WS8kHewIU7W3tPS5ztUtLJs/OueiaD6Y28B4y7JiCEV9W7Pl3krhGQm7s Uw/zoGWApShVq+65IxO9zW7juzPPSYUoyx5pPRE1XFFYms+Ml6IQn6DJZj8yy4BxMlse u4oXyV7BIhnXj6K/kzv4iB9vPFEP6xB5JxWXhmFwpS0W4RAxQor56vxqdftNuwdcr6rB k+DjUPRjYZBohWQqVC5okY4dQED7okZnDIbQh3gw9trVnPdI2tHozC0N3xnPwdFiqHB5 ttLfdoj++/rZBQF2z1l8ALBs++2HIx2aDCRTrgdar0wsJzkKoPyMqI+sV+dd7Ensuhmx yYsg== MIME-Version: 1.0 X-Received: by 10.112.180.137 with SMTP id do9mr10529666lbc.63.1413025061727; Sat, 11 Oct 2014 03:57:41 -0700 (PDT) Received: by 10.114.230.37 with HTTP; Sat, 11 Oct 2014 03:57:41 -0700 (PDT) In-Reply-To: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> Date: Sat, 11 Oct 2014 06:57:41 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c25c3edcf3a1050523885b Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hlzqjZeGqWPs5vEHDMewB-CmxdI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 10:57:46 -0000 --001a11c25c3edcf3a1050523885b Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Thanks for a thorough review and great feedback, as always. Please, see my reply inline... Regards, Rifaat On Fri, Oct 10, 2014 at 2:48 PM, Dale R. Worley wrote: > > Name: draft-yusef-sipcore-key-derivation > > It's an interesting proposal. The most important thing is that I'd > like to see a section that describes the motivation, that is, why this > is method better than the current digest scheme. (Laying out the case > is something that could progress before tidying the technical > presentation.) > > Agree. Will add a new section to the next version of the draft. > There are a bunch of parameters to this algorithm, and it would be > helpful to know what are the considerations that drive the choice of > parameter values. This is especially true for the iteration-count; > the NIST document proposes a range of 1,000 to 10,000,000, but the > computation power that a typical phone can apply to the problem is > limited. Agree. > (Also, is the master-key recomputed just once when the phone > is reconfigured with a new password, or with every message? Yeah, there are few options here: I was thinking of creating a new master-key every time the phone refreshes registrations. Other options is to tie it to some timer, or the number of times that the master-key was used. There is a need for some discussion around this. > For that > matter, how does the phone obtain the salt and iteration count when it > is configured?) > > The phone obtains these from the Challenge request. > Given the large number of parameters, it would be helpful to have a > small number of particular choices/combinations that are proposed for > use. > > I see: > > - nonce length > - the hash function used in the KDF > - the salt length > - the iteration count > - the length of the generated master key > > Ok. > Looking at the diagram on page 4, it appears that message 2 > (Challenge) contains "pop" which is computed as > "HMAC-SHA256(master-key, digest-string + nonce)". Message 3 > (Response) contains "pop" which is also shown being computed as > "HMAC-SHA256(master-key, digest-string + nonce)", which the server is > supposed to verify, even though it appears that that value was > transmitted in the clear in message 2. I'm pretty sure that the issue > is that the first "digest-string" is the digest string of message 1 > (the original request), No, this is the pop for the Challenge sent by the server. The idea is that the server uses the master-key to compute the pop over the Challenge to prove to the client that it is in possession of the master-key. When the client receives the Challenge, it will be able to create the master-key based on the Challenge and then locally compute the same pop over the Challenge to compare it to the pop received in the challenge. The client then creates a pop for the Response to prove to the server that it is in possession of the password/master-key, and sends it to the server. When the server receives the response, it will be able to locally compute the pop of the response and compare it to the pop received from the client. I will try to clarify this in the next version of the draft. > whereas the second one is the digest string of > message 3. But the notation should make that clear. For that matter, > the notation should make clear which bulleted items are computations, > which are tests, which data items are retrieved from local memory, > which are random numbers constructed at the moment, etc. > > Agree. > Message 4 contains "token", but there is no definition of that. > Indeed, if this scheme is meant only to provide mutual agreement on a > cryptographically stronger key to be input to digest authentication, > there isn't any "token", is there? > > Yes, you are right; no tokens here. Copy & paste mistake. Regards, Rifaat > Dale > --001a11c25c3edcf3a1050523885b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks for a thorough review a= nd great feedback, as always.
Please, see my reply inline...

Regards,
=A0Rifaat

=

On Fri, Oct 1= 0, 2014 at 2:48 PM, Dale R. Worley <worley@ariadne.com> wro= te:
> Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcor= e-key-derivation

It's an interesting proposal.=A0 The most important thing is that I'= ;d
like to see a section that describes the motivation, that is, why this
is method better than the current digest scheme.=A0 (Laying out the case is something that could progress before tidying the technical
presentation.)

Agree. Will add a new section to the next version of = the draft.

=A0
There are a bunch of parameters to this algorithm, and it would be
helpful to know what are the considerations that drive the choice of
parameter values.=A0 This is especially true for the iteration-count;
the NIST document proposes a range of 1,000 to 10,000,000, but the
computation power that a typical phone can apply to the problem is
limited.=A0

Agree.

=A0
(Also, is the master-key recomputed just on= ce when the phone
is reconfigured with a new password, or with every message?=A0

Yeah, there are few options here:
I was= thinking of creating a new master-key every time the phone refreshes regis= trations.
Other options is to tie it to some timer, or the number= of times that the master-key was used.=A0
There is a need = for some discussion around this.

=A0
For that
matter, how does the phone obtain the salt and iteration count when it
is configured?)


The phone obtains these from the Chall= enge request.


=A0
Given the large number of parameters, it would be helpful to have a
small number of particular choices/combinations that are proposed for
use.

I see:

- nonce length
- the hash function used in the KDF
- the salt length
- the iteration count
- the length of the generated master key


Ok.

=A0
=
Looking at the diagram on page 4, it appears that message 2
(Challenge) contains "pop" which is computed as
"HMAC-SHA256(master-key, digest-string + nonce)".=A0 Message 3 (Response) contains "pop" which is also shown being computed as "HMAC-SHA256(master-key, digest-string + nonce)", which the serve= r is
supposed to verify, even though it appears that that value was
transmitted in the clear in message 2.=A0 I'm pretty sure that the issu= e
is that the first "digest-string" is the digest string of message= 1
(the original request),

No, this is the po= p for the Challenge sent by the server.

The idea i= s that the server uses the master-key to compute the pop over the Challenge= to prove to the client that it is in possession of the master-key. When th= e client receives the Challenge, it will be able to create the master-key b= ased on the Challenge and then locally compute the same pop over the Challe= nge to compare it to the pop received in the challenge.

The client then creates a pop for the Response to prove to the server= that it is in possession of the password/master-key, and sends it to the s= erver. When the server receives the response, it will be able to locally co= mpute the pop of the response and compare it to the pop received from the c= lient.

I will try to clarify this in the next vers= ion of the draft.

=A0
wherea= s the second one is the digest string of
message 3.=A0 But the notation should make that clear.=A0 For that matter,<= br> the notation should make clear which bulleted items are computations,
which are tests, which data items are retrieved from local memory,
which are random numbers constructed at the moment, etc.


Agree.


=A0
Message 4 contains "token", but there is no definition of that. Indeed, if this scheme is meant only to provide mutual agreement on a
cryptographically stronger key to be input to digest authentication,
there isn't any "token", is there?


Yes, you are right; no tokens here. Copy & paste mista= ke.


Regards,
=A0Rifaat


=A0
Dale

--001a11c25c3edcf3a1050523885b-- From nobody Mon Oct 13 08:43:53 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F921A1A75 for ; Mon, 13 Oct 2014 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Gpp1ywYuqMQX for ; Mon, 13 Oct 2014 08:43:50 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4C71A1A66 for ; Mon, 13 Oct 2014 08:43:50 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-11v.sys.comcast.net with comcast id 2fhd1p0024xDoy801fjp01; Mon, 13 Oct 2014 15:43:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id 2fjp1p0043Ge9ey01fjpnh; Mon, 13 Oct 2014 15:43:49 +0000 Message-ID: <543BF334.5020106@alum.mit.edu> Date: Mon, 13 Oct 2014 11:43:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413215029; bh=fjXqEhQ4sfRPPRivROJzOnl1s/oxOr+S/Eu6nqX+2To=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JFD05KBJ7dgiKSXybWi93Jnmoa2dOeno3m+CW0VhIipx0YIoJRV2NlPui3UoiUBMl AyXXJjoFVXDnyeMYIbuoC+c2DuclXYI0BorADWxDBUuSqwrZHZ+38neh9u7UW5moC0 gjb8ScxVA4x0l/i9rPBBVyAAYjbt0otc5LeqilzQhA9Bzy4FqF9dAAi8cAeK24py+e CofnBKRPape600/K1JPJyPOHtGin08NNm4R8d+/iDHsUgYsXkCIzUz90uhJjr8Nynl UqhFppUh5420MrgZlJVc3Uq7IHFWBJVXM4ozLky6RoLmy8KkAyW1GSv4Mw53cBplnT FPSiGPqgFi2MQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7U1aPZp915E-MgciClGXA9cGMVw Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:43:51 -0000 Rifaat, Thanks for taking a crack at this. I have a lot of questions. Is it your plan to use the existing sip authentication headers with a new auth-scheme? (IMO that is the preferred path unless there are reasons it won't work.) If so, it would be very helpful to show the call flows using those terms. You show an initial-request, then a response, then an confirmation. IIUC the challenge will be carried in the sip response to the initial-request. Verification of the pop from the server will require the digest-string from the initial request - not the response. Is that what you want? Then the "response" will be carried in a new sip request, that has a different digest-string. I don't think the existing text is consistent with this usage. Note that RFC4474 hasn't been a great success. Part of the trouble is that the digest-string includes stuff that often is disturbed in existing deployments. STIR is proposing to reduce what is included in the digest. That might be the right thing to use here, or it might not be enough. Needs consideration. Thanks, Paul On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote: > Hi, > > During the IETF conference in London and as a response to my > presentation of the update to the SIP Digest, there was interest in the > room for exploring better schemes than the existing Digest scheme. > > I have just submitted an draft that describes a new proposal for an > authentication scheme that is based on the PBKDF2 function, to replace > the Digest scheme used by SIP today. > > I would really appreciate it if people review it and provide comments. > > Regards, > Rifaat > > > > > ---------- Forwarded message ---------- > From: ** > > Date: Fri, Oct 10, 2014 at 9:19 AM > Subject: New Version Notification for > draft-yusef-sipcore-key-derivation-00.txt > To: Rifaat Shekh-Yusef > > > > > A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-key-derivation > Revision: 00 > Title: Key-Derivation Authentication Scheme > Document date: 2014-10-10 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt > Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/ > Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00 > > > Abstract: > This document defines a Key-Derivation Authentication Scheme, based > on the PBKDF2 Key Derivation Function (KDF), that could be used with > the challenge-response authentication framework used by SIP to > authenticate the user. > > The scheme allows two parties to establish a mutually authenticated > communication channel based on a shared password, without ever > sending the password on the wire. > > > > > > 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 > . > > The IETF Secretariat > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Oct 13 10:24:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2661A1B9B for ; Mon, 13 Oct 2014 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 1DrN_K4AHkS1 for ; Mon, 13 Oct 2014 10:24:16 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC1D1A1B92 for ; Mon, 13 Oct 2014 10:24:08 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so6848287lbi.27 for ; Mon, 13 Oct 2014 10:24:07 -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:content-type; bh=zzWQKe7uXt8UWzdIOxOF8pWOqH35gaGW8xIQLhRsbeU=; b=PlHOiqoKyVZBoUAlow/RBkoqbbp9NQQDIaV5tKX2y+OvwT8+ejJy7BLKV9G6ideK7B ldsRhspDpRdADy/3K5Tq/EToRj96f1iPxxbvvGmkS+2uagRnJCQRNxvHzgjWM6UjtvIe cP8hzUEQMCiLBiMvHg8JUTZak8AVPu15buUz9VfFLqT+b7c5esvCQIuRlFjLRULLPRFX unyeTOuQj7c01JVkvr/tZfkMgVkNYK4J18bn4AnMPodJoaKByMo/mBU3Yu0fXTI2nt1r tPR0vEf0K6EJgqn75/qmTCMliAOjVHA+359O/hlGhjeahvhUHVAeOF7/CPnPTpCJ4DXL WqPg== MIME-Version: 1.0 X-Received: by 10.152.2.38 with SMTP id 6mr4574265lar.49.1413221047397; Mon, 13 Oct 2014 10:24:07 -0700 (PDT) Received: by 10.25.31.11 with HTTP; Mon, 13 Oct 2014 10:24:07 -0700 (PDT) In-Reply-To: <543BF334.5020106@alum.mit.edu> References: <543BF334.5020106@alum.mit.edu> Date: Mon, 13 Oct 2014 13:24:07 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e013c6b9284f3600505512a4d Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dydLPWyoHoPNAZlVy1tLqXDgBQE Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:24:18 -0000 --089e013c6b9284f3600505512a4d Content-Type: text/plain; charset=ISO-8859-1 Thanks Paul, Please, see my reply inline... Regards, Rifaat On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat wrote: > Rifaat, > > Thanks for taking a crack at this. I have a lot of questions. > > Is it your plan to use the existing sip authentication headers with a new > auth-scheme? (IMO that is the preferred path unless there are reasons it > won't work.) Definitely Yes. > If so, it would be very helpful to show the call flows using those terms. > Ok. > > You show an initial-request, then a response, then an confirmation. IIUC > the challenge will be carried in the sip response to the initial-request. > Verification of the pop from the server will require the digest-string from > the initial request - not the response. Is that what you want? No. I want the client to validate the pop (the digest-string of the Challenge) sent by the server in the Challenge to prove to the client it is in possession of the master-key, and later for the server to validate the pop (the digest-string of the Response) sent by the client in the Response to prove to the server that it is in possession of the password/master-key. I will clarify this point. > Then the "response" will be carried in a new sip request, that has a > different digest-string. I don't think the existing text is consistent with > this usage. > > Note that RFC4474 hasn't been a great success. Part of the trouble is that > the digest-string includes stuff that often is disturbed in existing > deployments. STIR is proposing to reduce what is included in the digest. > That might be the right thing to use here, or it might not be enough. Needs > consideration. > Ok. I will take a look at STIR. Regards, Rifaat > > Thanks, > Paul > > On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote: > >> Hi, >> >> During the IETF conference in London and as a response to my >> presentation of the update to the SIP Digest, there was interest in the >> room for exploring better schemes than the existing Digest scheme. >> >> I have just submitted an draft that describes a new proposal for an >> authentication scheme that is based on the PBKDF2 function, to replace >> the Digest scheme used by SIP today. >> >> I would really appreciate it if people review it and provide comments. >> >> Regards, >> Rifaat >> >> >> >> >> ---------- Forwarded message ---------- >> From: ** > >> Date: Fri, Oct 10, 2014 at 9:19 AM >> Subject: New Version Notification for >> draft-yusef-sipcore-key-derivation-00.txt >> To: Rifaat Shekh-Yusef > > >> >> >> >> A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt >> has been successfully submitted by Rifaat Shekh-Yusef and posted to the >> IETF repository. >> >> Name: draft-yusef-sipcore-key-derivation >> Revision: 00 >> Title: Key-Derivation Authentication Scheme >> Document date: 2014-10-10 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-yusef-sipcore- >> key-derivation-00.txt >> Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-key- >> derivation/ >> Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-key- >> derivation-00 >> >> >> Abstract: >> This document defines a Key-Derivation Authentication Scheme, based >> on the PBKDF2 Key Derivation Function (KDF), that could be used with >> the challenge-response authentication framework used by SIP to >> authenticate the user. >> >> The scheme allows two parties to establish a mutually authenticated >> communication channel based on a shared password, without ever >> sending the password on the wire. >> >> >> >> >> >> 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 >> . >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> 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 > --089e013c6b9284f3600505512a4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Paul,

Please, see my reply inlin= e...

Regards,
=A0Rifaat



On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
Rifaat,

Thanks for taking a crack at this. I have a lot of questions.

Is it your plan to use the existing sip authentication headers with a new a= uth-scheme? (IMO that is the preferred path unless there are reasons it won= 't work.)

Definitely Yes.
= =A0
If so, it would be very helpful to show the c= all flows using those terms.

Ok.
<= div>
=A0

You show an initial-request, then a response, then an confirmation. IIUC th= e challenge will be carried in the sip response to the initial-request. Ver= ification of the pop from the server will require the digest-string from th= e initial request - not the response. Is that what you want?
<= div>
No. I want the client to validate the pop (the digest-st= ring of the Challenge) sent by the server in the Challenge to prove to the = client it is in possession of the master-key, and later for the server to v= alidate the pop=A0(the digest-string of the Response)=A0sent by the client= =A0in the Response to prove to the server that it is in possession of the p= assword/master-key.

I will clarify this point.

=A0
Then the "respons= e" will be carried in a new sip request, that has a different digest-s= tring. I don't think the existing text is consistent with this usage.
Note that RFC4474 hasn't been a great success. Part of the trouble is t= hat the digest-string includes stuff that often is disturbed in existing de= ployments. STIR is proposing to reduce what is included in the digest. That= might be the right thing to use here, or it might not be enough. Needs con= sideration.

Ok. I will take a look at S= TIR.

Regards,
=A0Rifaat

=A0

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

On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote:
Hi,

During the IETF conference in London and as a response to my
presentation of the update to the SIP Digest, there was interest in the
room for exploring better schemes than the existing Digest scheme.

I have just submitted an draft that describes a new proposal for an
authentication scheme that is based on the PBKDF2 function, to replace
the Digest scheme used by SIP today.

I would really appreciate it if people review it and provide comments.

Regards,
=A0 Rifaat




---------- Forwarded message ----------
 From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Fri, Oct 10, 2014 at 9:19 AM
Subject: New Version Notification for
draft-yusef-sipcore-key-derivation-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
<mailto:rifaa= t.ietf@gmail.com>>



A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcore-key-derivation
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 Key-Derivation Authentication Scheme
Document date:=A0 2014-10-10
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 8
URL:
http://www.ietf.org/internet-drafts= /draft-yusef-sipcore-key-derivation-00.txt
Status: https://datatracker.ietf.org/doc/dra= ft-yusef-sipcore-key-derivation/
Htmlized: http://tools.ietf.org/html/draft-yusef= -sipcore-key-derivation-00


Abstract:
=A0 =A0 This document defines a Key-Derivation Authentication Scheme, based=
=A0 =A0 on the PBKDF2 Key Derivation Function (KDF), that could be used wit= h
=A0 =A0 the challenge-response authentication framework used by SIP to
=A0 =A0 authenticate the user.

=A0 =A0 The scheme allows two parties to establish a mutually authenticated=
=A0 =A0 communication channel based on a shared password, without ever
=A0 =A0 sending the password on the wire.





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

The IETF Secretariat




_______________________________________________
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

--089e013c6b9284f3600505512a4d-- From nobody Mon Oct 13 11:15:37 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B8D1A1B6F for ; Mon, 13 Oct 2014 11:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 UlddEQfMSgxN for ; Mon, 13 Oct 2014 11:15:30 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A761A0305 for ; Mon, 13 Oct 2014 11:15:30 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-07v.sys.comcast.net with comcast id 2iFT1p00A58ss0Y01iFWtX; Mon, 13 Oct 2014 18:15:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 2iFV1p0083Ge9ey01iFV6p; Mon, 13 Oct 2014 18:15:29 +0000 Message-ID: <543C16C1.5010007@alum.mit.edu> Date: Mon, 13 Oct 2014 14:15:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <543BF334.5020106@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413224130; bh=4Ja6vZAomuExWKzqfwtVeJqzF4XrSAgwLhxvY8a4riM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rLYvRHOMdHdyY4hIO1uL0LcoyAkszf+z9tclt3g5KZw+8M8YVOv1JulpOatLwKQ8T evgWnq+6yzWJ5ojkPaLiw+nb8eWnlNbnvggd84fzru+ROPoS8CqYjG40EQF6nkFNo1 hmayb2sRGC4FLu78wV1ZHwQr5AoB/jWXkTQ91iPYFDaE1rrMUc3aNvV490fgnQg/dn T06dVj9q3bXap9yDvXTxAYY/58bfmZKtJKwa3CATW2wNtnnVw3DWUboOlx81P8K69P YKnWwVUmi876QZ/+2dvt4ekhm9eZn/hdGaPNelrk5eptUgTHApP+TRvMaS0npZV2e6 FV6MJ0YYfiTtw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/CI8YCcahvK2CADWz2J5VRQNqmb0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:15:32 -0000 On 10/13/14 1:24 PM, Rifaat Shekh-Yusef wrote: > Thanks Paul, > > Please, see my reply inline... > > Regards, > Rifaat > > > > On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat > wrote: > > Rifaat, > > Thanks for taking a crack at this. I have a lot of questions. > > Is it your plan to use the existing sip authentication headers with > a new auth-scheme? (IMO that is the preferred path unless there are > reasons it won't work.) > > > Definitely Yes. > > If so, it would be very helpful to show the call flows using those > terms. > > > Ok. > > > You show an initial-request, then a response, then an confirmation. > IIUC the challenge will be carried in the sip response to the > initial-request. Verification of the pop from the server will > require the digest-string from the initial request - not the > response. Is that what you want? > > > No. I want the client to validate the pop (the digest-string of the > Challenge) sent by the server in the Challenge to prove to the client it > is in possession of the master-key, and later for the server to validate > the pop (the digest-string of the Response) sent by the client in the > Response to prove to the server that it is in possession of the > password/master-key. Then this will require creating a digest-string over a response. RFC4474 only defines it for a request, though all the fields it contains are also present in a response, so it is straightforward to define. > I will clarify this point. > > > Then the "response" will be carried in a new sip request, that has a > different digest-string. I don't think the existing text is > consistent with this usage. > > Note that RFC4474 hasn't been a great success. Part of the trouble > is that the digest-string includes stuff that often is disturbed in > existing deployments. STIR is proposing to reduce what is included > in the digest. That might be the right thing to use here, or it > might not be enough. Needs consideration. > > > Ok. I will take a look at STIR. > > Regards, > Rifaat > > > Thanks, > Paul > > On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote: > > Hi, > > During the IETF conference in London and as a response to my > presentation of the update to the SIP Digest, there was interest > in the > room for exploring better schemes than the existing Digest scheme. > > I have just submitted an draft that describes a new proposal for an > authentication scheme that is based on the PBKDF2 function, to > replace > the Digest scheme used by SIP today. > > I would really appreciate it if people review it and provide > comments. > > Regards, > Rifaat > > > > > ---------- Forwarded message ---------- > From: ** > >> > Date: Fri, Oct 10, 2014 at 9:19 AM > Subject: New Version Notification for > draft-yusef-sipcore-key-__derivation-00.txt > To: Rifaat Shekh-Yusef > >__> > > > > A new version of I-D, draft-yusef-sipcore-key-__derivation-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted > to the > IETF repository. > > Name: draft-yusef-sipcore-key-__derivation > Revision: 00 > Title: Key-Derivation Authentication Scheme > Document date: 2014-10-10 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-__drafts/draft-yusef-sipcore-__key-derivation-00.txt > > Status: > https://datatracker.ietf.org/__doc/draft-yusef-sipcore-key-__derivation/ > > Htmlized: > http://tools.ietf.org/html/__draft-yusef-sipcore-key-__derivation-00 > > > > Abstract: > This document defines a Key-Derivation Authentication > Scheme, based > on the PBKDF2 Key Derivation Function (KDF), that could be > used with > the challenge-response authentication framework used by SIP to > authenticate the user. > > The scheme allows two parties to establish a mutually > authenticated > communication channel based on a shared password, without ever > sending the password on the wire. > > > > > > 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 > . > > The IETF Secretariat > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From nobody Mon Oct 13 11:42:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5D91A1BC4 for ; Mon, 13 Oct 2014 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mAsGbPqncGyi for ; Mon, 13 Oct 2014 11:42:16 -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 77BF21A1BAA for ; Mon, 13 Oct 2014 11:42:15 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-a4-543c1d059613 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.B1.04081.50D1C345; Mon, 13 Oct 2014 20:42:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 13 Oct 2014 20:42:12 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) Thread-Index: AQHP5I3YRbUevllD/EGWaQ0vVy5SGZwuYSnw Date: Mon, 13 Oct 2014 18:42:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47A590@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47A590ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjS6rrE2IwcOf0hY7X7SyWXz9sYnN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4fqaDteBYSMW3P/eYGhgnenUxcnJICJhI HN7Vygphi0lcuLeerYuRi0NI4CijxJ/Pp5kgnCWMEi/6jwA5HBxsAhYS3f+0QRpEBMIlduy+ CNYsLJAo0dHyiAUiniSxbkozO4RtJDHp2AlGkFYWAVWJS8t0QcK8Ar4Sz6bfASsREgiQuHJn MZjNKRAo8bv1FTOIzQh0z/dTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf1D3K0ms2H6J EaI+X+L4yePMELsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI 4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbVwS2/DXYwvnzueIhRgINRiYf3wU+r ECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLg+1Ov31uvV dWLWuxg/CYopaZ2vWvHq54vwrobK5s8r/nOYXmLwNxYqUq7LPVlbwiC3dueGcNVyscri6Gkn SyqkkoR/bEzbZXp2Hkswy6dT4guNa/K9n6wuTjde908yVUSO89Mn1vzICotfjntqxPY+u7ym nuXG9HXzU8WDbYUmM/2bPiuUSYmlOCPRUIu5qDgRAFlYOaOLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/-A1kest31e_XNTA8OEdeHuVBhDM Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:42:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47A590ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rifaat, What do you mean by "uniquely generated" (for the nonce value)? Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 10 October 2014 16:26 To: sipcore@ietf.org Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to replac= e Digest scheme) Hi, During the IETF conference in London and as a response to my presentation o= f the update to the SIP Digest, there was interest in the room for explorin= g better schemes than the existing Digest scheme. I have just submitted an draft that describes a new proposal for an authent= ication scheme that is based on the PBKDF2 function, to replace the Digest = scheme used by SIP today. I would really appreciate it if people review it and provide comments. Regards, Rifaat ---------- Forwarded message ---------- From: > Date: Fri, Oct 10, 2014 at 9:19 AM Subject: New Version Notification for draft-yusef-sipcore-key-derivation-00= .txt To: Rifaat Shekh-Yusef = > A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-key-derivation Revision: 00 Title: Key-Derivation Authentication Scheme Document date: 2014-10-10 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key= -derivation-00.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-de= rivation/ Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-key-derivati= on-00 Abstract: This document defines a Key-Derivation Authentication Scheme, based on the PBKDF2 Key Derivation Function (KDF), that could be used with the challenge-response authentication framework used by SIP to authenticate the user. The scheme allows two parties to establish a mutually authenticated communication channel based on a shared password, without ever sending the password on the wire. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7594FB04B1934943A5C02806D1A2204B1D47A590ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 10 October 2014 16:26
To: sipcore@ietf.org
Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to= replace Digest scheme)

 

Hi,

 

During the IETF conference in London and as a respon= se to my presentation of the update to the SIP Digest, there was interest i= n the room for exploring better schemes than the existing Digest scheme.

 

I have just submitted an draft that describes a new = proposal for an authentication scheme that is based on the PBKDF2 function,= to replace the Digest scheme used by SIP today.

 

I would really appreciate it if people review it and= provide comments.

 

Regards,

 Rifaat

 

 

 

 

---------- Forwarded = message ----------
From: <internet-drafts@ietf.= org>
Date: Fri, Oct 10, 2014 at 9:19 AM
Subject: New Version Notification for draft-yusef-sipcore-key-derivation-00= .txt
To: Rifaat Shekh-Yusef <rifaat.= ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-sipcore-key-deriv= ation
Revision:       00
Title:          Key-Derivation Authentication Sche= me
Document date:  2014-10-10
Group:          Individual Submission
Pages:          8
URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.t= xt
Status:         https://da= tatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/
Htmlized:       http://tools.ietf.o= rg/html/draft-yusef-sipcore-key-derivation-00


Abstract:
   This document defines a Key-Derivation Authentication Scheme, = based
   on the PBKDF2 Key Derivation Function (KDF), that could be use= d with
   the challenge-response authentication framework used by SIP to=
   authenticate the user.

   The scheme allows two parties to establish a mutually authenti= cated
   communication channel based on a shared password, without ever=
   sending the password on the wire.





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

The IETF Secretariat

 

--_000_7594FB04B1934943A5C02806D1A2204B1D47A590ESESSMB209erics_-- From nobody Mon Oct 13 11:58:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC821A0347 for ; Mon, 13 Oct 2014 11:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 yGB7LKblL0YV for ; Mon, 13 Oct 2014 11:58:55 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0991A1A01B0 for ; Mon, 13 Oct 2014 11:58:54 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so7292069lab.1 for ; Mon, 13 Oct 2014 11:58:53 -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:content-type; bh=bgX/Q4GrCvGh6650Kpdgs+OfHsQvzk325ccVkrdXabY=; b=GWaYU9eL5rj3HPw7wF9cj5biXmF7TYLTWVXdtmqr9+FhuVUR0VZQMiApbDIzOGm5rv 9AG+xWgYTCa2DrBmrXe+rqnGwFbPfB9BaISOCFQbYD7CHz8XvXWJHUS3CLrUrLJveTUK TfOkFC59gp3lXOGYQJSAmqm7i16Z78YGeqOxdYCulUQbg7bEqYbFP63oqRDMPKJV2t+W Tau9482FIpHtuByDx9qqZfE5FTHXDfcjkAyYEc98wydAJMnazUiZqM6KE6SCj9pE9+Rv 1FoFBY9Kr2RzHcWEbClmFN4MRGt+GEHqRGqzcWVSfxtcc4vbaQKCpJHxpmT8iHR8dTxI 90Gw== MIME-Version: 1.0 X-Received: by 10.152.20.199 with SMTP id p7mr364780lae.49.1413226733216; Mon, 13 Oct 2014 11:58:53 -0700 (PDT) Received: by 10.25.31.11 with HTTP; Mon, 13 Oct 2014 11:58:53 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47A590@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47A590@ESESSMB209.ericsson.se> Date: Mon, 13 Oct 2014 14:58:53 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0141a5206baa430505527d97 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6nVizxM3gTT2eoDeSwgox1awFIc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:58:58 -0000 --089e0141a5206baa430505527d97 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, It means that the client/server must generate a new unique nonce for each request/response. A good example would be a time-stamp that includes micro or even nano seconds. I will add more text around this. Regards, Rifaat On Mon, Oct 13, 2014 at 2:42 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Rifaat, > > > > What do you mean by "uniquely generated" (for the nonce value)? > > > > Regards, > > > > Christer > > > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Rifaat > Shekh-Yusef > *Sent:* 10 October 2014 16:26 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Key-Derivation Authentication Scheme proposal (to > replace Digest scheme) > > > > Hi, > > > > During the IETF conference in London and as a response to my presentation > of the update to the SIP Digest, there was interest in the room for > exploring better schemes than the existing Digest scheme. > > > > I have just submitted an draft that describes a new proposal for an > authentication scheme that is based on the PBKDF2 function, to replace the > Digest scheme used by SIP today. > > > > I would really appreciate it if people review it and provide comments. > > > > Regards, > > Rifaat > > > > > > > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Oct 10, 2014 at 9:19 AM > Subject: New Version Notification for > draft-yusef-sipcore-key-derivation-00.txt > To: Rifaat Shekh-Yusef > > > > A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-key-derivation > Revision: 00 > Title: Key-Derivation Authentication Scheme > Document date: 2014-10-10 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/ > Htmlized: > http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00 > > > Abstract: > This document defines a Key-Derivation Authentication Scheme, based > on the PBKDF2 Key Derivation Function (KDF), that could be used with > the challenge-response authentication framework used by SIP to > authenticate the user. > > The scheme allows two parties to establish a mutually authenticated > communication channel based on a shared password, without ever > sending the password on the wire. > > > > > > 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. > > The IETF Secretariat > > > --089e0141a5206baa430505527d97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,

It means that the client/s= erver must generate a new unique nonce for each request/response.
A good example would be a time-stamp that includes micro or even nano seco= nds.

I will add more text around this.
<= br>
Regards,
 Rifaat



O= n Mon, Oct 13, 2014 at 2:42 PM, Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:

Hi Rifaat,<= /span>

 

What do you mean by &ldqu= o;uniquely generated” (for the nonce value)?

 

Regards,

 

Christer

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 10 October 2014 16:26
To: sipcore@ie= tf.org
Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to= replace Digest scheme)

 

Hi,

 

During the IETF conference in London and as a respon= se to my presentation of the update to the SIP Digest, there was interest i= n the room for exploring better schemes than the existing Digest scheme.=

 

I have just submitted an draft that describes a new = proposal for an authentication scheme that is based on the PBKDF2 function,= to replace the Digest scheme used by SIP today.

 

I would really appreciate it if people review it and= provide comments.

 

Regards,

 Rifaat

 

 

 

 

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Fri, Oct 10, 2014 at 9:19 AM
Subject: New Version Notification for draft-yusef-sipcore-key-derivation-00= .txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-sipcore-key-deriv= ation
Revision:       00
Title:          Key-Derivation Authentication Sche= me
Document date:  2014-10-10
Group:          Individual Submission
Pages:          8
URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.t= xt
Status:         https://da= tatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/
Htmlized:       http://tools.ietf.o= rg/html/draft-yusef-sipcore-key-derivation-00


Abstract:
   This document defines a Key-Derivation Authentication Scheme, = based
   on the PBKDF2 Key Derivation Function (KDF), that could be use= d with
   the challenge-response authentication framework used by SIP to=
   authenticate the user.

   The scheme allows two parties to establish a mutually authenti= cated
   communication channel based on a shared password, without ever=
   sending the password on the wire.





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

The IETF Secretariat

 


--089e0141a5206baa430505527d97-- From nobody Mon Oct 13 11:59:15 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193711A0301 for ; Mon, 13 Oct 2014 11:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 bMOJsrrrcYFX for ; Mon, 13 Oct 2014 11:59:10 -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 004511A0351 for ; Mon, 13 Oct 2014 11:59:07 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-aa-543c20f927e9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.D2.04081.9F02C345; Mon, 13 Oct 2014 20:59:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Mon, 13 Oct 2014 20:59:05 +0200 From: Christer Holmberg To: Paul Kyzivat , Rifaat Shekh-Yusef Thread-Topic: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) Thread-Index: AQHP5I3YRbUevllD/EGWaQ0vVy5SGZwuDlIAgAAcB4CAAA5agIAAKoFQ Date: Mon, 13 Oct 2014 18:59:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47A60B@ESESSMB209.ericsson.se> References: <543BF334.5020106@alum.mit.edu> <543C16C1.5010007@alum.mit.edu> In-Reply-To: <543C16C1.5010007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje4vBZsQgwf32SxWbDjAarHzRSub xdcfm9gcmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZby585q54KtxRdOilywN jG9Uuxg5OSQETCR+757CBmGLSVy4tx7I5uIQEjjKKDH5z1J2CGcJo8SU5TNYuhg5ONgELCS6 /2mDmCICYRLX3imD9DILaEo82rmXCcQWFkiU6Gh5xAJiiwgkSayb0swOYbtJPJo9mxHEZhFQ lZi2cSdYDa+Ar8Tzm9+YIFbdZpQ4+3gD2CBOAR2Jt6tmgDUwAh33/dQaJohl4hK3nsxngjha QGLJnvPMELaoxMvH/1ghbCWJFdsvMULU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYEwd3PLbYAfjy+eOhxgF OBiVeHgf/LQKEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jMLb7Hes3DqpUlNmzT+zuRWO19cJc8x+5Jdp9jDXSIrxsAbf/RdyjX1HCy+sne68auq0B/sm X54wW2HR5Zx/rX3yM4P6l8cY72t63cXzcD6z9IPHrZMDd/za9b7rqumduSbWnnsrZhVVnT+V c+vu31Luj+xnPHOVZ6asDjqx8tHxwIy3Uy3W9rMrsRRnJBpqMRcVJwIAbPvhhooCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/v5Prmc1sIRwiyeYxOnqOuA_Sa_w Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:59:13 -0000 Hi, A minor editorial comment, related to Paul's request for some flows:=20 I think it would be useful to separate between "SIP response" and "challeng= e response". Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 13 October 2014 21:15 To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to re= place Digest scheme) On 10/13/14 1:24 PM, Rifaat Shekh-Yusef wrote: > Thanks Paul, > > Please, see my reply inline... > > Regards, > Rifaat > > > > On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat > wrote: > > Rifaat, > > Thanks for taking a crack at this. I have a lot of questions. > > Is it your plan to use the existing sip authentication headers with > a new auth-scheme? (IMO that is the preferred path unless there are > reasons it won't work.) > > > Definitely Yes. > > If so, it would be very helpful to show the call flows using those > terms. > > > Ok. > > > You show an initial-request, then a response, then an confirmation. > IIUC the challenge will be carried in the sip response to the > initial-request. Verification of the pop from the server will > require the digest-string from the initial request - not the > response. Is that what you want? > > > No. I want the client to validate the pop (the digest-string of the > Challenge) sent by the server in the Challenge to prove to the client=20 > it is in possession of the master-key, and later for the server to=20 > validate the pop (the digest-string of the Response) sent by the=20 > client in the Response to prove to the server that it is in possession=20 > of the password/master-key. Then this will require creating a digest-string over a response. RFC4474 on= ly defines it for a request, though all the fields it contains are also pre= sent in a response, so it is straightforward to define. > I will clarify this point. > > > Then the "response" will be carried in a new sip request, that has a > different digest-string. I don't think the existing text is > consistent with this usage. > > Note that RFC4474 hasn't been a great success. Part of the trouble > is that the digest-string includes stuff that often is disturbed in > existing deployments. STIR is proposing to reduce what is included > in the digest. That might be the right thing to use here, or it > might not be enough. Needs consideration. > > > Ok. I will take a look at STIR. > > Regards, > Rifaat > > > Thanks, > Paul > > On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote: > > Hi, > > During the IETF conference in London and as a response to my > presentation of the update to the SIP Digest, there was interest > in the > room for exploring better schemes than the existing Digest scheme= . > > I have just submitted an draft that describes a new proposal for = an > authentication scheme that is based on the PBKDF2 function, to > replace > the Digest scheme used by SIP today. > > I would really appreciate it if people review it and provide > comments. > > Regards, > Rifaat > > > > > ---------- Forwarded message ---------- > From: ** > >> > Date: Fri, Oct 10, 2014 at 9:19 AM > Subject: New Version Notification for > draft-yusef-sipcore-key-__derivation-00.txt > To: Rifaat Shekh-Yusef > >__> > > > > A new version of I-D, draft-yusef-sipcore-key-__derivation-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted > to the > IETF repository. > > Name: draft-yusef-sipcore-key-__derivation > Revision: 00 > Title: Key-Derivation Authentication Scheme > Document date: 2014-10-10 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-__drafts/draft-yusef-sipcore-__key-d= erivation-00.txt > > Status: > https://datatracker.ietf.org/__doc/draft-yusef-sipcore-key-__deri= vation/ > > Htmlized: > http://tools.ietf.org/html/__draft-yusef-sipcore-key-__derivation= -00 > =20 > > > > Abstract: > This document defines a Key-Derivation Authentication > Scheme, based > on the PBKDF2 Key Derivation Function (KDF), that could be > used with > the challenge-response authentication framework used by SIP = to > authenticate the user. > > The scheme allows two parties to establish a mutually > authenticated > communication channel based on a shared password, without ev= er > sending the password on the wire. > > > > > > 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 > . > > The IETF Secretariat > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 13 13:43:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46441A0033 for ; Mon, 13 Oct 2014 13:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 y6hJIiPSzI_M for ; Mon, 13 Oct 2014 13:43:44 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B68A1A001B for ; Mon, 13 Oct 2014 13:43:43 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-06v.sys.comcast.net with comcast id 2kiA1p0082XD5SV01kjj0C; Mon, 13 Oct 2014 20:43:43 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-20v.sys.comcast.net with comcast id 2kji1p0091KKtkw01kjiKn; Mon, 13 Oct 2014 20:43: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 s9DKhfOs014188; Mon, 13 Oct 2014 16:43:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9DKhfek014186; Mon, 13 Oct 2014 16:43:41 -0400 Date: Mon, 13 Oct 2014 16:43:41 -0400 Message-Id: <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413233023; bh=O348cgo0C+M2vQZ5xPmerNvYA6xz7BF184hQOyV855o=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=TkcRILdzMWU9oFgxJcl4MyPPCXVIo7EtuX36GsC4qwE0QNofVherOVLG22pWpSZko jz3fkO46josno7y6Z9bL0ZFJW5QZRRkiX4ot8fhzluGAwUYC/qB/+edVFjlHj0+LlN Pav1W4kg/n2uoFs0D4Tx9dQikp6ORJ+IC7ld3aWF3Qet1cF4W7/xtjRgFkbur+SM9M JZTjH0QRI7RYJudsEuyFMEWNmZhOY2wbW5KhQDMSkt9OrvlJepTSxZrtUiZYdp6Fsx JXIoyqWCzwneqjugXjaeFcKqttZmxhRCHGNK6THC8c/8PEFvcwkkW/WypNxyDsvbeq kq9DC+E4lb7GA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Rtus5M7KSEo8OeT1PtNMlVhdHl0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:43:46 -0000 > From: Rifaat Shekh-Yusef > > Name: draft-yusef-sipcore-key-derivation > > (Also, is the master-key recomputed just once when the phone > > is reconfigured with a new password, or with every message? > > Yeah, there are few options here: > I was thinking of creating a new master-key every time the phone refreshes > registrations. > Other options is to tie it to some timer, or the number of times that the > master-key was used. > There is a need for some discussion around this. As the processing is shown in the draft, the phone doesn't get to choose when to calculate a master key, it must do so whenever the parameters presented in the challenge change. > > For that > > matter, how does the phone obtain the salt and iteration count when it > > is configured?) > > > The phone obtains these from the Challenge request. There are a number of inputs to the generic key-derivation function. This one is presumably configured into the phone by whatever means are now used for configuring passwords into the phone: - password These are presented by the UAS in the 401/407 challenge: - the identity of the HMAC hash algorithm - salt - key-size - iteration-count The phone has to do a lot of computation to produce the master key from these data. The advantage that is gained is that the master key is more resistant to a dictionary attack because of the additional entropy provided by the salt, and the master key is cryptographically random, providing less opportunity to attack the hash that computes the message digest. But at least in this form, the last four data items could vary on a request-by-request basis, which is probably computationally infeasible for the phone to deal with. At the least, you'd want the phone to cache the results of one master key computation and hope that the parameters don't change from request to request. Given that phones are now generally configured by automated means, I'm wondering if it would not be equally effective to have some process in the configuration system compute a master key using the NIST method and then deliver the master key to the phone by the existing configuration mechanisms. Dale From nobody Mon Oct 13 20:55:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD301A6F6E for ; Mon, 13 Oct 2014 20:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 VmrY5_YA2dKu for ; Mon, 13 Oct 2014 20:55:15 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFD61A6F67 for ; Mon, 13 Oct 2014 20:55:13 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with comcast id 2rud1p0025E3ZMc01rvDv7; Tue, 14 Oct 2014 03:55:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id 2rvC1p00R3Ge9ey01rvCA0; Tue, 14 Oct 2014 03:55:13 +0000 Message-ID: <543C9EA0.8010603@alum.mit.edu> Date: Mon, 13 Oct 2014 23:55:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> In-Reply-To: <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413258913; bh=y8KRTAha0mUBDbSkwqpvwapoMGuNfA9WX4o4XbGvpQc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZgadhiD9vYGZoI23nP1QcpwCznOlI0frsuaUfdWLghK6RADOcUUPqBcHRGes8UbGc 1/vP9NVXVYWL6vOB/oMtHdaSO0OZY3Ds07/P6UNezCE02z/6olcKHFh4mAdc+UEngq oliDx45DYFWaNrxEKVuabbK+aDVpK2eOOGH2AOmZJ6KTq+A4RCcc0XYV3j2aVauL2G 0DZy5PKLRrqfzrZH330Yp8nCKmAlQzmmyPBnMAR4jLU9IZpaXE5KzFFlYSVSlIceEt 3qp96Zf5Rue505h24LxlffuRhJ2CRVRpJ0NOMoLE2ksLdi70hc9p2anE8sQanP9MoC 3rC2mG8Y6zQ9g== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/y_ZsJfGSo_O6dVr4XgG0811Siw0 Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 03:55:16 -0000 On 10/13/14 4:43 PM, Dale R. Worley wrote: > Given that phones are now generally configured by automated means, I'm > wondering if it would not be equally effective to have some process in > the configuration system compute a master key using the NIST method > and then deliver the master key to the phone by the existing > configuration mechanisms. That puts the master key on the wire. To make it safe you would have to encrypt it. Thanks, Paul From nobody Tue Oct 14 05:28:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB71A874D for ; Tue, 14 Oct 2014 05:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 4Qpd-PsLp7Xr for ; Tue, 14 Oct 2014 05:28:20 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3405A1A8762 for ; Tue, 14 Oct 2014 05:28:20 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so8487797lab.16 for ; Tue, 14 Oct 2014 05:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OrFISJaDL7zk8PazciiPdwmyf3kLN6KDMBaRoEDKdn4=; b=nXP5/A/otojwq3yXNM/z+h5aA9KlocXq+9qYO3592Y63wV1SZYzLSnLz3gXrpJelDh UjHGWZIt3J8yAcrTNLOy6cJ8q9lyCBOtgcA0U62ZTcAPPS6wa9xpyENNvhE6ip95rFdY PrhCMNp1t2c1ssdRCO3dYHi/OmJQY0KduKd0YMh149YXpkS8kC8H+YlWM+MG/exPyBmx /+hkzDxdIbzsd4CVfhXoovwh4RHGhT2HjWKIS2E4JQY5iWEz9kbPs78uymcNOoiFGdbx +pe45JVzSo85n47n2C/SFL+qaeYl8NDAaod9t8j28gz3C54kw6Zx+LraC0Ze2UgCrAdd sgRw== MIME-Version: 1.0 X-Received: by 10.112.140.74 with SMTP id re10mr5075755lbb.40.1413289698527; Tue, 14 Oct 2014 05:28:18 -0700 (PDT) Received: by 10.25.31.11 with HTTP; Tue, 14 Oct 2014 05:28:18 -0700 (PDT) In-Reply-To: <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> Date: Tue, 14 Oct 2014 08:28:18 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c341e072113e050561262a Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Y-yE79B-W4dU-vfvJ_yWNm49Snw Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:28:24 -0000 --001a11c341e072113e050561262a Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, The master-key is tied to the password selected by the user and it changes only when the user changes his password. If we want to be able to change keys on the fly, e.g. during registration refresh, then a new key must be created that is derived from the master-key, e.g user-key, which will be used to calculate the pop. This means that the master-key will only be used to create user-keys, which will be updated every once in a while. This will complicate things a bit, but is doable. I will try to capture the idea in the new version of the draft so we could discuss this. Regards, Rifaat On Mon, Oct 13, 2014 at 4:43 PM, Dale R. Worley wrote: > > From: Rifaat Shekh-Yusef > > > > Name: draft-yusef-sipcore-key-derivation > > > > (Also, is the master-key recomputed just once when the phone > > > is reconfigured with a new password, or with every message? > > > > Yeah, there are few options here: > > I was thinking of creating a new master-key every time the phone > refreshes > > registrations. > > Other options is to tie it to some timer, or the number of times that the > > master-key was used. > > There is a need for some discussion around this. > > As the processing is shown in the draft, the phone doesn't get to > choose when to calculate a master key, it must do so whenever the > parameters presented in the challenge change. > > > > For that > > > matter, how does the phone obtain the salt and iteration count when it > > > is configured?) > > > > > The phone obtains these from the Challenge request. > > There are a number of inputs to the generic key-derivation function. > This one is presumably configured into the phone by whatever means are > now used for configuring passwords into the phone: > - password > > These are presented by the UAS in the 401/407 challenge: > - the identity of the HMAC hash algorithm > - salt > - key-size > - iteration-count > > The phone has to do a lot of computation to produce the master key > from these data. The advantage that is gained is that the master key > is more resistant to a dictionary attack because of the additional > entropy provided by the salt, and the master key is cryptographically > random, providing less opportunity to attack the hash that computes > the message digest. > > But at least in this form, the last four data items could vary on a > request-by-request basis, which is probably computationally infeasible > for the phone to deal with. At the least, you'd want the phone to > cache the results of one master key computation and hope that the > parameters don't change from request to request. > > Given that phones are now generally configured by automated means, I'm > wondering if it would not be equally effective to have some process in > the configuration system compute a master key using the NIST method > and then deliver the master key to the phone by the existing > configuration mechanisms. > > Dale > --001a11c341e072113e050561262a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

The master-key is t= ied to the password selected by the user and it changes only when the user = changes his password.=A0
If we want to be able to change keys on = the fly, e.g. during registration refresh, then a new key must be created t= hat is derived from the master-key, e.g user-key, which will be used to cal= culate the pop.
This means that the master-key will only be u= sed to create user-keys, which will be updated every once in a while.
=
This will complicate things a bit, but is doable. I will try to captur= e the idea in the new version of the draft so we could discuss this.

Regards,
=A0Rifaat


On Mon, Oct 13, 2014= at 4:43 PM, Dale R. Worley <worley@ariadne.com> wrote:
=
> From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>

> > Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcore-key-derivation
> > (Also, is the master-key recomputed just once when the phone
> > is reconfigured with a new password, or with every message?
>
> Yeah, there are few options here:
> I was thinking of creating a new master-key every time the phone refre= shes
> registrations.
> Other options is to tie it to some timer, or the number of times that = the
> master-key was used.
> There is a need for some discussion around this.

As the processing is shown in the draft, the phone doesn't get t= o
choose when to calculate a master key, it must do so whenever the
parameters presented in the challenge change.

> > For that
> > matter, how does the phone obtain the salt and iteration count wh= en it
> > is configured?)
> >
> The phone obtains these from the Challenge request.

There are a number of inputs to the generic key-derivation function.=
This one is presumably configured into the phone by whatever means are
now used for configuring passwords into the phone:
- password

These are presented by the UAS in the 401/407 challenge:
- the identity of the HMAC hash algorithm
- salt
- key-size
- iteration-count

The phone has to do a lot of computation to produce the master key
from these data.=A0 The advantage that is gained is that the master key
is more resistant to a dictionary attack because of the additional
entropy provided by the salt, and the master key is cryptographically
random, providing less opportunity to attack the hash that computes
the message digest.

But at least in this form, the last four data items could vary on a
request-by-request basis, which is probably computationally infeasible
for the phone to deal with.=A0 At the least, you'd want the phone to cache the results of one master key computation and hope that the
parameters don't change from request to request.

Given that phones are now generally configured by automated means, I'm<= br> wondering if it would not be equally effective to have some process in
the configuration system compute a master key using the NIST method
and then deliver the master key to the phone by the existing
configuration mechanisms.

Dale

--001a11c341e072113e050561262a-- From nobody Tue Oct 14 13:26:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727191ACEA3 for ; Tue, 14 Oct 2014 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 XOZ3CY7rGVVD for ; Tue, 14 Oct 2014 13:26:12 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B2C1A90F8 for ; Tue, 14 Oct 2014 13:26:12 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-11v.sys.comcast.net with comcast id 38R41p0082PT3Qt018SBhk; Tue, 14 Oct 2014 20:26:11 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-14v.sys.comcast.net with comcast id 38SA1p0071KKtkw018SAzK; Tue, 14 Oct 2014 20:26: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 s9EKQ9Vf005731; Tue, 14 Oct 2014 16:26:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9EKQ9WL005723; Tue, 14 Oct 2014 16:26:09 -0400 Date: Tue, 14 Oct 2014 16:26:09 -0400 Message-Id: <201410142026.s9EKQ9WL005723@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D47A60B@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <543BF334.5020106@alum.mit.edu> <543C16C1.5010007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D47A60B@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413318371; bh=VS+CKxx+9A2iyJiUhelRD7TWs1QIUtfnChVHwC4VGz4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=NuvzojPTcKGaQCaugLncwuHCoN7XlT220xhibvdWBaId69c1X1+rHMuAsUlGDbWob r2EArt5i8hXNYyP4Ms1HfdAw3yuavQTMzeAnrby3MIj/vL6SLmrHXEUMLFwadVZNCZ MgcKQB4ny8nqsKkqNmIyufEwZep2nOHdOgKx8o6a2wcyrA9+R8ktrjmxCSVXIUrgCk G4Jjo84cVK3UCc7W1WVL4/E+sVcrD2t52Qw3oiOXQDWaTUOxy7BSTUYKsGFi87jmYw kUZB2VquepdMT89yifjMNU4YMnyW/8JB6sRVam0upeeN394bStrEetye3RcFnEkSUE abxkaNEJZ9qWg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/faoU9RfXJ2EjQZPiY3ms6IjkXB8 Cc: sipcore@ietf.org, rifaat.ietf@gmail.com Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:26:13 -0000 > From: Christer Holmberg > I think it would be useful to separate between "SIP response" and > "challenge response". Yes. I was losing track of that myself. Dale From nobody Tue Oct 14 13:31:27 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A11ACF88 for ; Tue, 14 Oct 2014 13:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 QujuK2BUsOhg for ; Tue, 14 Oct 2014 13:31:25 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF061A0067 for ; Tue, 14 Oct 2014 13:31:25 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-07v.sys.comcast.net with comcast id 38Ww1p0022N9P4d018XQCg; Tue, 14 Oct 2014 20:31:24 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-13v.sys.comcast.net with comcast id 38XP1p00V1KKtkw018XQKR; Tue, 14 Oct 2014 20:31:24 +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 s9EKVNDN006309; Tue, 14 Oct 2014 16:31:23 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9EKVNpk006308; Tue, 14 Oct 2014 16:31:23 -0400 Date: Tue, 14 Oct 2014 16:31:23 -0400 Message-Id: <201410142031.s9EKVNpk006308@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: <7594FB04B1934943A5C02806D1A2204B1D47A590@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413318684; bh=ZZJ9nNUGjuSg7i9KLzm+lI9TqAkfYqPMoQvTk5sM9VM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=KmIjnk/kZSO+2jIZkysAC4CXOMaX+lEe5eJGQIrTG+e1p3gSzifjqqz3FU79bllQK x097/PpZEMqMorQmN64wcGFoAQ1NXCke1bkDX/tB/c+Flg7Mmfv/PPaicZx63ewY6e q96p1mX/vWO/7MXRjjAuppmlM7ArdXOf3A5+hQQ+A+1ll/HtuuRh3EobEAjSt146b6 0+sUYbL38459FlXkRH0QvnRziGPSzRiB7OcQGd0iWOj1Uabm4fLxdshE/IeaH90+Mz zEJ7oPEJW4uOOfefKw7XFZON735blVnzALtdtknpEkRZCv6WhepiIJwYvnjmseNYwf /2TFnbeDBLPFg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/cAgAoeHk56RkFP2IowWXCr6_3E0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:31:26 -0000 > From: Rifaat Shekh-Yusef > It means that the client/server must generate a new unique nonce for each > request/response. > A good example would be a time-stamp that includes micro or even nano > seconds. I don't think you want to say it that way. (1) It assumes that the device knows what time it is. (2) It assumes that there is only one message sent during a micro- or nano-second. As written, a sequence number would suffice. (You'd need some way of initializing the sequence number on bootup to ensure you didn't start counting from zero each time.) But that raises the question, does the nonce have to be pseudo-random, or perhaps even cryptographically random? My guess is that you want the nonce to be pseudo-random (to prevent exploitation of regularities in the nonces) but don't need crypto-random (predictability is not a problem). So hashing a sequence number with some sort of per-device identifier would suffice. Dale From nobody Tue Oct 14 13:36:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970C31A90F8 for ; Tue, 14 Oct 2014 13:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 sbq0V7Do2FI7 for ; Tue, 14 Oct 2014 13:36:13 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30141ACF18 for ; Tue, 14 Oct 2014 13:36:11 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-03v.sys.comcast.net with comcast id 38Yl1p00356HXL0018cBkT; Tue, 14 Oct 2014 20:36:11 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-12v.sys.comcast.net with comcast id 38cA1p00H1KKtkw018cBXg; Tue, 14 Oct 2014 20:36: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 s9EKa7j8006853; Tue, 14 Oct 2014 16:36:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9EKa71b006852; Tue, 14 Oct 2014 16:36:07 -0400 Date: Tue, 14 Oct 2014 16:36:07 -0400 Message-Id: <201410142036.s9EKa71b006852@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <543C9EA0.8010603@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> <543C9EA0.8010603@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413318971; bh=oKHMBvKXJqXLZxofXEVpxyjM1MG0oZ6/uF3LSQIrmC8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QD89FEWu9pHPBd2ymyGmpdh7Cu4GzBgA2D+WmJwTb5Bg5CbyhcKtGiE20x+jxImGd 5d+A6BQ+76O/jsxQF+wwpQUNU2UtEeV0bp4M1fo6U9XUPwzozrp8+c8Tad/qNibZhI c6vyFKbOqFZ2DDZGt7p7C+2m8FF+15gA1ouEq/XuVALmGF/J+xWUH8WwVi9IXg//6e DNuJ76iksZscpMWJv5gwkJh5OjlClO6iWSW9fvZ0DCzRvmO5+2lt89uW7T66mEAqiW QoZYEk08XiGktWQmgDHcHQzcwxNowUNT5ccIhP7s/2CB6tmLS76zpQ4D7LbZeMHrxL h43/RrKwug1eQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/N1oXXfiv_JPoJNLL77KRtvrmSsg Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:36:14 -0000 > From: Paul Kyzivat > > > Given that phones are now generally configured by automated means, I'm > > wondering if it would not be equally effective to have some process in > > the configuration system compute a master key using the NIST method > > and then deliver the master key to the phone by the existing > > configuration mechanisms. > > That puts the master key on the wire. To make it safe you would have to > encrypt it. You're stating that a requirement is that the master key does not pass on the wire in plaintext. My understanding is that most phones these days (at least in enterprise settings) obtain their passwords via some sort of configuration system that runs at boot time -- the password is *not* entered by the user into the user interface. And the password passes over the wire in plaintext. (Or it might as well be in plaintext, if we allow the attacker to modify traffic, because the phone has no prior secret identifier.) If we really want key secrecy, we'll need more specifications than are now described in the draft, and they will have to include how the phone is configured. Dale From nobody Tue Oct 14 13:42:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4091ACE82 for ; Tue, 14 Oct 2014 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 1dvdIHoCo6nT for ; Tue, 14 Oct 2014 13:42:13 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810FB1A000B for ; Tue, 14 Oct 2014 13:42:13 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-05v.sys.comcast.net with comcast id 38i41p0042Ka2Q5018iCVu; Tue, 14 Oct 2014 20:42:12 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-11v.sys.comcast.net with comcast id 38iC1p0051KKtkw018iCxp; Tue, 14 Oct 2014 20:42:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9EKgBFW007578; Tue, 14 Oct 2014 16:42:11 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9EKgBOD007577; Tue, 14 Oct 2014 16:42:11 -0400 Date: Tue, 14 Oct 2014 16:42:11 -0400 Message-Id: <201410142042.s9EKgBOD007577@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: <201410101848.s9AImYvC016994@hobgoblin.ariadne.com> <201410132043.s9DKhfek014186@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413319332; bh=AQkJs8InJ8KCb/HqwPXylGYS/jhEnbPGdPbSOXSrC5I=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=tUhXwTu58pGpYlJ27CCxtC+PBAWGuyMbhusbrZQn6Gy+Mj9HX+lYgFm6T8x9roTsW SoVUPxDtbkdjZpxbM+iIBJQ8csUNhXXO5XSbPLTAlkkH76t2PDsnZZ2yR2d1PPFkTT rCwo30fSKwWXoOv0sXubVyRz4ObnjdNSv5tEGx0ZC+LWzPN4B9IeBAjJbileZ/9KTU ZhB7rKIKl2eUyDdDdJV6K3WRT/GzZswRP2+46qzXs5WhNELaj7gObs3IVigDsFTy6r RNjVaTD2gVrXn5yUTMz0hsI6ltZurahodsboMBlGfB3Aq2HzYX+mh22IIP8VyAKPqw xeo2zYzTGAzrA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EG1spW1RHllHapKKuvVq06pPdrY Cc: sipcore@ietf.org Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme) draft-yusef-sipcore-key-derivation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:42:14 -0000 > From: Rifaat Shekh-Yusef I think this discussion splits into two parts: > The master-key is tied to the password selected by the user and it changes > only when the user changes his password. As shown in the draft, the master-key depends on the KDF, salt, key-size, and iteration-count. All four of those are presented in the challenge by the UAS. If the master-key "changes only when the user changes his password", then there must be a requirement that the UAS (and every UAS in that authentication realm) must always use the same values for those parameters (until the password changes). > If we want to be able to change keys on the fly, e.g. during registration > refresh, then a new key must be created that is derived from the > master-key, e.g user-key, which will be used to calculate the pop. > This means that the master-key will only be used to create user-keys, which > will be updated every once in a while. > This will complicate things a bit, but is doable. I will try to capture the > idea in the new version of the draft so we could discuss this. The NIST document demands that the master-key is only used to generate shorter-lived keys, although we don't necessarily have to follow that. As far as I can tell, the -00 doesn't discuss "changing keys on the fly". What are the motivations for that? Dale From nobody Tue Oct 14 17:08:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC821A0086 for ; Tue, 14 Oct 2014 17:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 g0C1gyyWPICQ for ; Tue, 14 Oct 2014 17:08:08 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AB01A006D for ; Tue, 14 Oct 2014 17:08:07 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so136594lab.12 for ; Tue, 14 Oct 2014 17:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AZUw2ltfCTvJs+7Wgz2frXDoiiGVCET8Yvi6Yp22MDY=; b=WdT+cgyV9EmAqDXLpIuky4orXoPT5cAU84gEdy8xcFnYwxi/AJ2FQ+6szBZScJUbtC 24z5gfd4PTCiS3F7YiT0T44VtS6Ktylg2p/st5dezoE8tPq/1wTlIStWNQ/tio6yuqYi oXM46pfYESo6TW4O1O1vQ+3AO3qYpOOEVQ/O0+8MDvw/GrmhF+b96FoYD8A3/mc6LYMk FgYb0qe7oWrZFfiihAJ8iEDCtD9D7K0IsDIg2PA97D+vttAeNjb5VjUCDTgYLHds8xcN xqDBb0H3k3jJlLR0VSm8+zIDY58yib9r2XQ+EOGoJ6oe0N/NcMhy38/UwV6mr4yOizdu g9Mw== MIME-Version: 1.0 X-Received: by 10.152.161.231 with SMTP id xv7mr8684167lab.43.1413331686093; Tue, 14 Oct 2014 17:08:06 -0700 (PDT) Received: by 10.25.31.11 with HTTP; Tue, 14 Oct 2014 17:08:06 -0700 (PDT) In-Reply-To: <20141014234445.25684.33702.idtracker@ietfa.amsl.com> References: <20141014234445.25684.33702.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 20:08:06 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a113461d21976ab05056aed3c Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7a5kSDdwddqoYFOIHjcKnpfJYu0 Subject: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 00:08:14 -0000 --001a113461d21976ab05056aed3c Content-Type: text/plain; charset=ISO-8859-1 Hi, I have just submitted version -01 of the SIP OAuth proposal. This new version update the first 3 sections, and tries to clarify the token that is associated with the user, using the OpenID terminology (ID Token). Reviews and comments are much appreciated. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Tue, Oct 14, 2014 at 7:44 PM Subject: New Version Notification for draft-yusef-sipcore-sip-oauth-01.txt To: Victor Pascual , Rifaat Shekh-Yusef < rifaat.ietf@gmail.com> A new version of I-D, draft-yusef-sipcore-sip-oauth-01.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-sip-oauth Revision: 01 Title: The Session Initiation Protocol (SIP) OAuth Document date: 2014-10-14 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-yusef-sipcore-sip-oauth-01.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-oauth/ Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore-sip-oauth-01 Abstract: This document defines an authorization framework for SIP that is based on the OAuth 2.0 framework, and adds a simple identity layer on top of that, based on the OpenID Connect Core 1.0, to enable Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User. 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. The IETF Secretariat --001a113461d21976ab05056aed3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have just submitted ve= rsion -01 of the SIP OAuth proposal.
This new version update the = first 3 sections, and tries to clarify the token that is associated with th= e user, using the OpenID terminology (ID Token).

R= eviews and comments are much appreciated.

Regards,=
=A0Rifaat





---------- Forwarded message ----= ------
From: <internet-drafts@ietf.org><= /span>
Date: Tue, Oct 14, 2014 at 7:44 PM
Subject: New Version Notifi= cation for draft-yusef-sipcore-sip-oauth-01.txt
To: Victor Pascual <<= a href=3D"mailto:victor.pascual@quobis.com">victor.pascual@quobis.com&g= t;, Rifaat Shekh-Yusef <rifaat.= ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-sip-oauth-01.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcore-sip-oauth
Revision:=A0 =A0 =A0 =A001
Title:=A0 =A0 =A0 =A0 =A0 The Session Initiation Protocol (SIP) OAuth
Document date:=A0 2014-10-14
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 22
URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-yusef-sipcore-sip-oauth-01.txt
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.ietf.org/d= oc/draft-yusef-sipcore-sip-oauth/
Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-yus= ef-sipcore-sip-oauth-01
Diff:=A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcd= iff?url2=3Ddraft-yusef-sipcore-sip-oauth-01

Abstract:
=A0 =A0This document defines an authorization framework for SIP that is
=A0 =A0based on the OAuth 2.0 framework, and adds a simple identity layer o= n
=A0 =A0top of that, based on the OpenID Connect Core 1.0, to enable Clients=
=A0 =A0to verify the identity of the End-User based on the authentication =A0 =A0performed by an Authorization Server, as well as to obtain basic
=A0 =A0profile information about the End-User.





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

The IETF Secretariat


--001a113461d21976ab05056aed3c-- From nobody Wed Oct 15 13:13:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481A41A8895 for ; Wed, 15 Oct 2014 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 6GKchuNh4yFt for ; Wed, 15 Oct 2014 13:13:10 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1DCE71A893E for ; Wed, 15 Oct 2014 13:13:07 -0700 (PDT) Received: (qmail 13622 invoked by uid 0); 15 Oct 2014 20:13:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Oct 2014 20:13:06 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 3eD11p0091MNPNq01eD4cs; Wed, 15 Oct 2014 20:13:04 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=doUQZJtgAAAA:8 a=9bOKTyGbAAAA:8 a=M0OflfRGAAAA:8 a=ll-iCDY8AAAA:8 a=hea1mOaGJMCzGTMmGbgA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=5eIJMYd8ObsA:10 a=yDlVmugRoooA:10 a=GBsgy2rA9acA:10 a=0CJEY8SJ_7AA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=Yo_weSMKip8A:10 a=vRAbILRZcFsA:10 a=N3zA0ylTc-fSNlXY1MkA:9 a=tg8yzmqARRgiNWYa:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=w19MAODG12V9eUNfJUkkBkZXTEXWUqWvG1+fUBCQau4=; b=QePj9xCN/dZqVBw3zVc2fM0FfLdF5Wng/qulxEamFJrWTANtSb7o2qS61SfYHsO41YCMaSpiQFQZdEwGb2W8cDcr5HFOh4NKs+sFsMH1eSje4SWVa2EH8G6BjNzEBogQ; Received: from [72.66.64.164] (port=54703 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeUwP-0001VT-Kx; Wed, 15 Oct 2014 14:13:01 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 16:12:56 -0400 From: Richard Shockey To: , , Message-ID: Thread-Topic: ATIS and SIP Forum Network to Network Interface work in progress documents Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3496234381_875618" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/69VvRchxRMo3aGYYajnWe8JybDQ Subject: [sipcore] ATIS and SIP Forum Network to Network Interface work in progress documents X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:13:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3496234381_875618 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable As some of you know the SIP Forum and ATIS have been cooperating for the past year on a series of profile documents for SIP to facilitate all IP interconnection among service providers. The Task Force has agreed to make a snapshot of the documents available to the larger carrier and SIP community to invite informed technical comments. These are still a =B3work in progress=B2 . For those of you in the United States this work has taken on a larger significance since it has the attention of the United States Federal Communications Commission as was called out in a recent speech by Commissio= n Chairman Tom Wheeler. https://apps.fcc.gov/edocs_public/attachmatch/DOC-329767A1.pdf ****** The IP-Network to Network Interface (NNI) Joint Task Force , a cooperative effort between the ATIS and the SIP Forum, is seeking public comment on two draft documents: =20 1. IP Interconnection Profile. The IP-NNI Profile Specification defines a reference architectureand specifications for both the protocol an= d media as it appears =B3on-the-wire=B2 at interconnect points. The specifications reference commonly used IETF, 3GPP, and other related industry specifications and identify protocol extensions and capability information needed for all-IP telephony peering. 2. IP Interconnection Routing Report. The IP-NNI Routing Technical Report documents mechanisms for identifying the preferred IP interconnectio= n point for a given TN. This report presents multiple views of current IP interconnection mechanisms based on aggregate PSTN constructs, interim solutions based on all-IP routing using a per-TN registry, and a consideration of hybrid approaches across both mechanisms during the transition to all-IP. =20 Members of the IETF SIP Community may access the document directly here. http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,153/I= t emid,261/ Members of ATIS may also Access the documents at: http://access.atis.org/apps/org/workgroup/ipnni/download.php/18837/latest(f= o r ATIS members) or http://access.atis.org/apps/group_public/document.php?document_id=3D18837&wg_= a bbrev=3Dipnni (public access). =20 Providing Feedback: Written input, technical feedback only, is requested b= y October 29, 2014. However, in light of the short timeframe, input will be accepted until December 1, 2014. Submit comments to the Task Force via its mailing list. To do this, individuals must first be registered as a SIP Forum Participant Member (Free) here:http://www.sipforum.org/component/option,com_advanced_registration/tas= k ,register/.=20 When completed, subscription to the NNI Task Force mailing list can be performed at: http://sipforum.org/mailman/listinfo/nni. =20 For further information on the IP Network to Network Interface (NNI) Joint Task Force and these above-referenced documents, please contact me or Jim McEachern, Senior Technical Consultant, ATIS jmceachern@atis.org or me at the contact information listed below. =20 =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us Www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 --B_3496234381_875618 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable



The Task Fo= rce has agreed to make a snapshot of the documents available to the larger c= arrier and SIP community to invite informed technical comments.  These = are still a “work in progress” .


For those of you in the United States= this work has taken on a larger significance since it has the attention of = the United States Federal Communications Commission as was called out in a r= ecent speech by Commission Chairman Tom Wheeler.




The IP-Network to Ne= twork Interface (NNI) Joint Task Force, a cooperative effort between the= ATIS and the SIP Forum, is seeking public comment on two draft documents:

 

1.      IP Interconnection Profile.  The IP-NNI Profile Specification defines a refere= nce architectureand specifications for both the protocol and media as= it appears “on-the-wire” at interconnect points.  The spec= ifications reference commonly used IETF, 3GPP, and other related industry sp= ecifications and identify protocol extensions and capability information nee= ded for all-IP telephony peering.

2.=   &n= bsp;   IP Interconnection= Routing Report.  The IP-NNI Routing Tech= nical Report documents mechanisms for identifying the preferred IP interconn= ection point for a given TN. This report presents multiple views of current = IP interconnection mechanisms based on aggregate PSTN constructs, interim so= lutions based on all-IP routing using a per-TN registry, and a consideration= of hybrid approaches across both mechanisms during the transition to all-IP= . 



 

Members of the IETF SIP Community may access the document directly here.=



http://www.sipforum.org/component= /option,com_docman/task,cat_view/gid,153/Itemid,261/


Members of ATIS may also Access the documents at: http://access.atis.org/apps/org/workgroup/ipnni/download.ph= p/18837/latest(for ATIS members) or

http://access.atis.org/apps/group_public/document.php?document_id=3D18837&a= mp;wg_abbrev=3Dipnni (public access).

 

Providing Feedback:&nbs= p; Written input, technical feedback only, is requested by = October 29, 2014. However, in light of the short timeframe, input will be ac= cepted until December 1, 2014.  Submit comments to the Task Force via i= ts mailing list. To do this, individuals must first be registered as a SIP F= orum Participant Member (Free) 


here:http://www.sipforum.org/component/option,com_advanced_regi= stration/task,register/. 


&nbs= p;When completed, subscri= ption to the NNI Task Force mailing list can be performed at: http://sipf= orum.org/mailman/listinfo/nni= .

&n= bsp;

For further information on the IP Network to Network Interface (NNI= ) Joint Task Force and these above-referenced documents, please contact me o= r Jim McEachern, Senior Technical Consultant, ATIS jmceachern@atis.org or me a= t the contact information listed below.

 

— 

Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org<= /font>
richard<at&g= t;shockey.us
Sk= ype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

--B_3496234381_875618-- From nobody Tue Oct 21 09:23:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA371A8928 for ; Tue, 21 Oct 2014 09:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dh1ntz9w_Ev0 for ; Tue, 21 Oct 2014 09:23:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1D7271A893A for ; Tue, 21 Oct 2014 09:23:15 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LGNE8w074554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Oct 2014 11:23:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5446886D.6040903@nostrum.com> Date: Tue, 21 Oct 2014 11:23:09 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/5Vw22xLU9z-1wD90-qxiTmacucY Subject: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:23:24 -0000 As Shinji pointed out, the whole reason we have immediate NOTIFY in subscription dialogs is that only one of the 200 OKs to a forked SUBSCRIBE will ever make it back to the subscriber. Trying to carry any information, like the proposed Refer-Events-At, in the response to a REFER that might fork is going to have the same problem. A big "Thank You" to everyone who brainstormed possible ways we might do things differently. (I'll summarize and expand on what was discussed before the message is over). After kicking this around for awhile, I think the right thing to do with this realization is acknowledge the limitation in the mechanism, rather than try to change the mechanism to avoid it. My proposal will be to add text to the draft noting that if a REFER forks, and is accepted by more than one recipient, the UA sending the REFER will only learn the Refer-Events-At URI from one of those recipients, and which one is out of its control. So, the extension should only be used when that's ok for the application sending the REFER. That is, either there is enough information to know that the REFER will only be accepted in one place (as is the case if it is sent in-dialog, or Target-Dialog is provided in an out-of-dialog request), or the application doesn't care about tracking the resulting state if the request is accepted in more than one place. If things would go wrong if the REFER were accepted in more than one place and the referrer didn't learn about each of them, then the application must not use this extension (falling back into a 6665-subscription creating REFER instead). I know that as engineers, we find this kind of shortcoming distateful. But, pragmatically, there isn't a strong demand for solving the general problem. If I'm wrong about that, and we decide we must figure out how to get information back from every place a forked REFER is accepted, I see three basic paths to choose from (based on the recent conversations, and some really old ones - remember HERFP - this is like that, only harder). Again, this is talking only about cases where the REFER might fork - we'll deal with in-dialog or other non-forking cases separately. 1) Modify proxy behavior to aggregate the responses. As pointed out on the list already, this really a non-starter - it means the proxy will have to hold the first 200 in case others arrive, forcing it into the bad places of long non-invite transactions as detailed in RFC4320 and RFC4321. 2) Send an out-of-dialog request from each accepting endpoint back in the other direction. We'd have to work through making sure the request would get back to the right place (probably using GRUUs). We'd have to choose or define a method (NOTIFY has been suggested, and the "must be in a dialog" problems with that pointed out. INFO has the same problem. We could abuse MESSAGE, but it's probably better just to define a new method if we decide to go down this path. 3) Solve the problem with dialogs. Probably by starting with a new INVITE that negotiates no (or baseline held) media. Wherever that INVITE is accepted, you end up with separate dialogs. A separate REFER could then be sent within each dialog, and would be guaranteed to be accepted in only one place. This would mean defining behavior for that INVITE (probably involving a Require extension), and detailing when that INVITE dialog would shut down. Does anyone see any other class of alternatives? Again, my recommendation is that we don't pursue _any_ of them, and go with the recognize-and-restrict approach I suggest at the beginning of this message. RjS From nobody Tue Oct 21 09:57:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E91A8AF2 for ; Tue, 21 Oct 2014 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 KjH0jiccWEBN for ; Tue, 21 Oct 2014 09:57:13 -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 B1B691A8AEB for ; Tue, 21 Oct 2014 09:56:43 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-1c-544690492157 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.52.24955.94096445; Tue, 21 Oct 2014 18:56:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 18:56:41 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests Thread-Index: AQHP7UtclselDM3oiUWI0Y0VbF6igpw6wxhQ Date: Tue, 21 Oct 2014 16:56:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BFAF4@ESESSMB209.ericsson.se> References: <5446886D.6040903@nostrum.com> In-Reply-To: <5446886D.6040903@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja7nBLcQg7v/rS2uzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJVxa/E6loJlyhUzTp9gbmDcKdPFyMkhIWAi 0T1zChOELSZx4d56ti5GLg4hgaOMEt9mr4NyljBKLOjZzNLFyMHBJmAh0f1PG6RBRCBQYuGk JSwgtrBAosSO1rnsEPEkifnHT7JC2EYSe7sbwOIsAqoS5+fNAVvGK+Ar0TPpBVhcSEBL4sqq c2D1nALaEsvXLWcEsRmBDvp+ag1YPbOAuMStJ/OhDhWQWLLnPDOELSrx8vE/VghbSWLF9kuM EPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKyXWpSZXFycn6eXl1qyiREYJwe3/FbdwXj5jeMhRgEORiUeXoV9riFCrIllxZW5hxilOViU xHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRuuDfTN5fqg8L115bYGJ/bqX3l1Xr JUyiXS/e3mjg+XD19PdH+/+r3fvxdS+38kOLT0VZP6dc3ca44E2en9mlk/PvvpggubnhjVLN I/v96X/z/duKmc3WPPd+ZrPjo8jEvfrsT1wOftTw4nzfM1PC7d+nT80Jf0rmNL13LXVIN/m0 enLJM46QZ0osxRmJhlrMRcWJAFmDyht0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dEtoqRGpM3cxNirNX0GCUMnClt4 Subject: Re: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:57:15 -0000 Hi, +1 for "don't pursue _any_ of them". Nothing prevents people from doing 3), but it's nothing we need to describe= or mandate. I think it would be restrictive, as there is no guarantee that= a REFER and INVITE would get forked to the same destinations, and we would= never reach a destination that supports REFER, but does not support INVITE= . Regards, Christer=20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 21 October 2014 19:23 To: sipcore@ietf.org Subject: [sipcore] Dealing with the possibility of accepting multiple forke= d REFER requests As Shinji pointed out, the whole reason we have immediate NOTIFY in subscri= ption dialogs is that only one of the 200 OKs to a forked SUBSCRIBE will ev= er make it back to the subscriber. Trying to carry any information, like th= e proposed Refer-Events-At, in the response to a REFER that might fork is g= oing to have the same problem. A big "Thank You" to everyone who brainstormed possible ways we might do th= ings differently. (I'll summarize and expand on what was discussed before t= he message is over). After kicking this around for awhile, I think the right thing to do with th= is realization is acknowledge the limitation in the mechanism, rather than = try to change the mechanism to avoid it. My proposal will be to add text to the draft noting that if a REFER forks, = and is accepted by more than one recipient, the UA sending the REFER will o= nly learn the Refer-Events-At URI from one of those recipients, and which o= ne is out of its control. So, the extension should only be used when that's= ok for the application sending the REFER. That is, either there is enough = information to know that the REFER will only be accepted in one place (as i= s the case if it is sent in-dialog, or Target-Dialog is provided in an out-= of-dialog request), or the application doesn't care about tracking the resu= lting state if the request is accepted in more than one place. If things wo= uld go wrong if the REFER were accepted in more than one place and the refe= rrer didn't learn about each of them, then the application must not use thi= s extension (falling back into a 6665-subscription creating REFER instead). I know that as engineers, we find this kind of shortcoming distateful. But, pragmatically, there isn't a strong demand for solving the general pro= blem. If I'm wrong about that, and we decide we must figure out how to get inform= ation back from every place a forked REFER is accepted, I see three basic p= aths to choose from (based on the recent conversations, and some really old= ones - remember HERFP - this is like that, only harder). Again, this is ta= lking only about cases where the REFER might fork - we'll deal with in-dial= og or other non-forking cases separately. 1) Modify proxy behavior to aggregate the responses. As pointed out on the = list already, this really a non-starter - it means the proxy will have to h= old the first 200 in case others arrive, forcing it into the bad places of = long non-invite transactions as detailed in RFC4320 and RFC4321. 2) Send an out-of-dialog request from each accepting endpoint back in the o= ther direction. We'd have to work through making sure the request would ge= t back to the right place (probably using GRUUs). We'd have to choose or de= fine a method (NOTIFY has been suggested, and the "must be in a dialog" problems with that pointed out. INFO has the same problem. We could abuse M= ESSAGE, but it's probably better just to define a new method if we decide t= o go down this path. 3) Solve the problem with dialogs. Probably by starting with a new INVITE t= hat negotiates no (or baseline held) media. Wherever that INVITE is accept= ed, you end up with separate dialogs. A separate REFER could then be sent = within each dialog, and would be guaranteed to be accepted in only one plac= e. This would mean defining behavior for that INVITE (probably involving a = Require extension), and detailing when that INVITE dialog would shut down. Does anyone see any other class of alternatives? Again, my recommendation is that we don't pursue _any_ of them, and go with= the recognize-and-restrict approach I suggest at the beginning of this mes= sage. RjS _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Oct 21 10:00:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F491A8720 for ; Tue, 21 Oct 2014 10:00:16 -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 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 bMhaa3V3ITkf for ; Tue, 21 Oct 2014 10:00:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DEB1A1A8AE2 for ; Tue, 21 Oct 2014 10:00:05 -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.14.9/8.14.7) with ESMTP id s9LH012e085864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 12:00:02 -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 Message-ID: <54469111.7020103@nostrum.com> Date: Tue, 21 Oct 2014 12:00:01 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: OKUMURA Shinji , sipcore@ietf.org References: <7ECFBBA7034CE9ietf.shinji@gmail.com> In-Reply-To: <7ECFBBA7034CE9ietf.shinji@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_xGQE5rocCr3Jv50IAmv1Zaxp5I Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:00:16 -0000 [as participant] On 8/19/14 07:13, OKUMURA Shinji wrote: > If the 6665 compliant UAS supports REFER, then > 1) In a dialog created by INVITE, a local Contact of the UAS MUST be GRUU. This is actually a clarification for RFC 6665, not REFER. I still owe the WG a draft clarifying exactly this point, and apologize for being rather deeply behind on coming up with this. > 2) If the UAS supports a scenario for a transfer, then it SHOULD support tdialog. This is a good point; I believe it should be couched in terms of pointing out that both referers and referees compliant with 6665 are bound by section 6.5 of RFC 6665, and that the appropriate mechanism for REFER is RFC 4538. (RFC 6665 implies that it expects event packages to call this out explicitly, so I think that including it in the clarifications document would be good form) > 3) When the UAS receives REFER within the dialog, if referer supports tdialog, > then the UAS MAY respond by 3xx "Extension Required" with "Required: tdialog" and "Contact: GRUUofReferee", > else the UAS MAY accept the REFER. It looks like you're trying to add behavior to RFC6665 referees to force pre-RFC6665 referers that support tdialog (but have elected not to use it) to use it. I'm not sure this adds much value -- the prospect that a client would know how to do this but decide not to seem kind of slim -- but I don't really see any harm. > 4) When the UAS receives REFER out of the dialog, UAS MAY accept the REFER. I'm not sure this needs to be said. I think it's reasonable to assume that it would accept the REFER, subject to its local policy. Adding words to reiterate obvious behavior makes the document longer, and therefore worse. > 1) If a UAS's local Contact inside an existing dialog is gruu, then the 6665 compliant UAC MUST use REFER out of dialog. There's been a lot of discussion around this wording, and the desire seems to be to leave the door open for the explicit subscription mechanism that Robert is also working on. The resulting text is the first sentence of section 4. It basically says the same thing as you're proposing, except that it doesn't need to be updated by the explicit subscription mechanism. > 2) If the UAC supports a scenario for a transfer, then it SHOULD support tdialog. This is covered by (2), above. > 3) If a UAS does not support both of gruu and tdialog, then the 6665 compliant UAC MAY use REFER within dialog. I think this is covered adequately in the final paragraph of section 4. > 4) If a UAC received 3xx "Extension Required" response for REFER that contains "Required: tdialog", > then UAS MAY send REFER out of dialog. The REFER request SHOULD contain "Targer-Dialog" header. This seems to be trying to impose requirements on legacy, already deployed clients. I'm not sure how it provides any value without the use of a time machine. /a From nobody Tue Oct 21 10:04:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581F71A8AB0 for ; Tue, 21 Oct 2014 10:04:40 -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 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 gki3qbQZmEyG for ; Tue, 21 Oct 2014 10:04:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 20E4C1A894C for ; Tue, 21 Oct 2014 10:04:35 -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.14.9/8.14.7) with ESMTP id s9LH4XZo086249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 12:04:34 -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 Message-ID: <54469221.60204@nostrum.com> Date: Tue, 21 Oct 2014 12:04:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Robert Sparks , "sipcore@ietf.org" References: <5446886D.6040903@nostrum.com> In-Reply-To: <5446886D.6040903@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/IJengrJf4TjJaCPfwlb8ZybmK8M Subject: Re: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:04:41 -0000 On 10/21/14 11:23, Robert Sparks wrote: > I know that as engineers, we find this kind of shortcoming distateful. > But, pragmatically, there isn't a strong demand for solving the > general problem. Agreed on both counts. > Again, my recommendation is that we don't pursue _any_ of them, and > go with the recognize-and-restrict approach I suggest at the beginning > of this message. I agree with this approach. All three proposals are more complicated than the root problem we're trying to solve (unwanted NOTIFY messages); and, in fact, (2) is basically a proposal to send NOTIFY messages as part of an attempt to not send NOTIFY messages. So, to be clear: I agree that we should document and accept the limitation imposed by forking in this scenario, but not add any mechanism to mitigate it. /a From nobody Tue Oct 21 10:20:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70E81A1AFC for ; Tue, 21 Oct 2014 10:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 gb1pwQ3Ijofa for ; Tue, 21 Oct 2014 10:20:53 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28711A1AF5 for ; Tue, 21 Oct 2014 10:20:51 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-02v.sys.comcast.net with comcast id 5tLZ1p00757bBgG01tLqin; Tue, 21 Oct 2014 17:20:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id 5tLq1p0083Ge9ey01tLqAl; Tue, 21 Oct 2014 17:20:50 +0000 Message-ID: <544695F2.8050203@alum.mit.edu> Date: Tue, 21 Oct 2014 13:20:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5446886D.6040903@nostrum.com> In-Reply-To: <5446886D.6040903@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413912050; bh=AfIYOot6xAMWttzN+IHmqV4cnKBaoD8Mn5TVAWI9lFE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=klE+wpL0+Rcwjh/B3I7zCC57S7E9wDbRgi3B5tdOT7y+WEtw02z3rjB5RaUhIFE6F AIKVlilxKNujzDFvWbFqg4dOqDgJPHfxK4s7klZr1PCFf1JrkbJktF3VZUsi5Abxe5 T6rL/HW/+HC+UUZ3I2F+tPg6fIuSjAAU/fcrgcDQQJADCqtTAuuaBLITf/KDIjkzwi zDRs7fZBQbbjSvqsNwn/aN2ixJOFVNraeZF5le9If5QcHDegCx+QzHAZcEqtVrenvt FNn0sKGsbM16m8umLhSVdlPLtIVYhcqTqU1j3glvJZdPyviOSXxsMckMIF7sZXzJQA puR2P8dpMAmOg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_nKChZnuaw5NcI_tm0IHiaY5QTk Subject: Re: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:20:54 -0000 [as individual] On 10/21/14 12:23 PM, Robert Sparks wrote: > Again, my recommendation is that we don't pursue _any_ of them, and > go with the recognize-and-restrict approach I suggest at the beginning > of this message. I agree. I'll also mention that one of the reasons people want this solution is that they want a solution that doesn't require the use of GRUUs. So solutions that themselves require GRUU are non-starters. Thanks, Paul From nobody Tue Oct 21 11:12:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74541A8779 for ; Tue, 21 Oct 2014 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 xn5IG-dSaF69 for ; Tue, 21 Oct 2014 11:11:59 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE041A87A8 for ; Tue, 21 Oct 2014 11:08:49 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id 5u7E1p00552QWKC01u8oAX; Tue, 21 Oct 2014 18:08:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id 5u8o1p0023Ge9ey01u8oyN; Tue, 21 Oct 2014 18:08:48 +0000 Message-ID: <5446A130.9010602@alum.mit.edu> Date: Tue, 21 Oct 2014 14:08:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7ECFBBA7034CE9ietf.shinji@gmail.com> <54469111.7020103@nostrum.com> In-Reply-To: <54469111.7020103@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413914928; bh=3Aqbo2wm2Vyq3XfdQXI4am41KydpoVX8370Se4CI1Oo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fnFxzRErjLQqcUmmg6N82+yEzusfAEmXbMHJeA+lDDIlw5EV8b4vV8H39f742Gker pdo55vLP5qe/pyeC8bJNX9Y6WH0KodohRhyJtECycyWm94d85yyVivMU+3hUlu+6OW gB5ZHOwI54UxXWenxQXXG/o/XebAC6vk2G29U6KUTGFA6+4TKj3IyVrfdHCmNkT5EV 1rJVO6AaWOHox/F0EscSIfqVdjrfc3vgJpcqDIvmXMKYEnwKsHSGs5Zq7d1CZS3A3n l2wY/dazbJVLJMAjAzQupBliBp6pOLsRMysGDWcJenp6ESCey1T2bgm1oebtDWTWbw QKj2snGA5thDw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/WeC3x7rEFQPlwxltdtjWEf1rUvs Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:12:01 -0000 I'd like some clarity on what "must use a gruu" means. Does this mean the contact must have a "gr" parameter, or only that it must be globally routable? (Note that 3261 has always required contact URIs to be globally routable.) The key difference is that with a "gr" parameter the other end can verify that the uri has been asserted to be globally routable. Thanks, Paul On 10/21/14 1:00 PM, Adam Roach wrote: > [as participant] > > On 8/19/14 07:13, OKUMURA Shinji wrote: >> If the 6665 compliant UAS supports REFER, then >> 1) In a dialog created by INVITE, a local Contact of the UAS MUST be >> GRUU. > > This is actually a clarification for RFC 6665, not REFER. I still owe > the WG a draft clarifying exactly this point, and apologize for being > rather deeply behind on coming up with this. > >> 2) If the UAS supports a scenario for a transfer, then it SHOULD >> support tdialog. > > This is a good point; I believe it should be couched in terms of > pointing out that both referers and referees compliant with 6665 are > bound by section 6.5 of RFC 6665, and that the appropriate mechanism for > REFER is RFC 4538. (RFC 6665 implies that it expects event packages to > call this out explicitly, so I think that including it in the > clarifications document would be good form) > >> 3) When the UAS receives REFER within the dialog, if referer >> supports tdialog, >> then the UAS MAY respond by 3xx "Extension Required" with >> "Required: tdialog" and "Contact: GRUUofReferee", >> else the UAS MAY accept the REFER. > > It looks like you're trying to add behavior to RFC6665 referees to force > pre-RFC6665 referers that support tdialog (but have elected not to use > it) to use it. I'm not sure this adds much value -- the prospect that a > client would know how to do this but decide not to seem kind of slim -- > but I don't really see any harm. > >> 4) When the UAS receives REFER out of the dialog, UAS MAY accept the >> REFER. > > I'm not sure this needs to be said. I think it's reasonable to assume > that it would accept the REFER, subject to its local policy. Adding > words to reiterate obvious behavior makes the document longer, and > therefore worse. > >> 1) If a UAS's local Contact inside an existing dialog is gruu, then >> the 6665 compliant UAC MUST use REFER out of dialog. > > There's been a lot of discussion around this wording, and the desire > seems to be to leave the door open for the explicit subscription > mechanism that Robert is also working on. The resulting text is the > first sentence of section 4. It basically says the same thing as you're > proposing, except that it doesn't need to be updated by the explicit > subscription mechanism. > >> 2) If the UAC supports a scenario for a transfer, then it SHOULD >> support tdialog. > > This is covered by (2), above. > >> 3) If a UAS does not support both of gruu and tdialog, then the 6665 >> compliant UAC MAY use REFER within dialog. > > I think this is covered adequately in the final paragraph of section 4. > >> 4) If a UAC received 3xx "Extension Required" response for REFER >> that contains "Required: tdialog", >> then UAS MAY send REFER out of dialog. The REFER request SHOULD >> contain "Targer-Dialog" header. > > This seems to be trying to impose requirements on legacy, already > deployed clients. I'm not sure how it provides any value without the use > of a time machine. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Oct 21 12:52:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAED61A3B9E for ; Tue, 21 Oct 2014 12:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 j2uZ1BidnjX7 for ; Tue, 21 Oct 2014 12:52:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C66151A1BE4 for ; Tue, 21 Oct 2014 12:52:36 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LJqZ0O004018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Oct 2014 14:52:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5446B97F.5010508@nostrum.com> Date: Tue, 21 Oct 2014 14:52:31 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20141021192636.17296.13012.idtracker@ietfa.amsl.com> In-Reply-To: <20141021192636.17296.13012.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141021192636.17296.13012.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020500090004050602070209" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dQWDsS6WkkbsWzkVA5l155e7YGo Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:52:42 -0000 This is a multi-part message in MIME format. --------------020500090004050602070209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit fyi -------- Forwarded Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-02.txt Date: Tue, 21 Oct 2014 12:26:36 -0700 From: internet-drafts@ietf.org To: Robert Sparks , Robert Sparks A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-02.txt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-explicit-subscription Revision: 02 Title: Explicit Subscriptions for the REFER Method Document date: 2014-10-21 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-02.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ Htmlized: http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-02 Abstract: The Session Initiation Protocol (SIP) REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines extensions to REFER to remove the implicit subscription and, if desired, replace it with an explicit one. 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. The IETF Secretariat --------------020500090004050602070209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit fyi


-------- Forwarded Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-02.txt
Date: Tue, 21 Oct 2014 12:26:36 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjsparks@nostrum.com>, Robert Sparks <rjsparks@nostrum.com> 


A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-02.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	02
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-10-21
Group:		Individual Submission
Pages:		13
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-02.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-02

Abstract:
   The Session Initiation Protocol (SIP) REFER request, as defined by
   RFC3515, triggers an implicit SIP-Specific Event Notification
   framework subscription.  Conflating the start of the subscription
   with handling the REFER request makes negotiating SUBSCRIBE
   extensions impossible, and complicates avoiding SIP dialog sharing.
   This document defines extensions to REFER to remove the implicit
   subscription and, if desired, replace it with an explicit one.

                                                                                  


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.

The IETF Secretariat


--------------020500090004050602070209-- From nobody Thu Oct 23 01:31:35 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B41A892C for ; Thu, 23 Oct 2014 01:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.2 X-Spam-Level: *** X-Spam-Status: No, score=3.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FSL_HELO_FAKE=2.5, SPF_PASS=-0.001] autolearn=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 mKuqTGVdo5fo for ; Thu, 23 Oct 2014 01:31:29 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2991A6F4C for ; Thu, 23 Oct 2014 01:31:29 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so665445pad.8 for ; Thu, 23 Oct 2014 01:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=4aEW6RCKdHZF8pIBLHEc+zuXq+e3RmOSbdtZ+/xOpcg=; b=R+jD/21z1TjrgCFQhctczJn9w8sue1l6NCC3NGtPvukqsJt5M2nx1v977yba3/mx7i GEUiMeuzgf0PlkoubVb0cGwFhJcuxtTs/iPZjYZbx8kQmKwNxkyMkHtvAYZgaSYW15jv FAuQeXgiYU7m/LqHyz0jJVnSMS9j+eQBZNuHvUnRN1+bA++DurmeCxJUMNnzQ2DcAq+l VXfUgyh6Ve/X7F1KF7PsS6pJVYuIA5si01xKqPuq9kEKolM8i2oyfc83Jk+VC+g5ofWa NV7jMH+MFxA+JUYMHkCQ1J0bgsT6hSAoUHEqyIq9BMLEdMj+okhaM7yidyGPyrq/jCW0 8y1A== X-Received: by 10.70.36.202 with SMTP id s10mr3319439pdj.101.1414053089157; Thu, 23 Oct 2014 01:31:29 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id wr8sm985822pbc.52.2014.10.23.01.31.27 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Oct 2014 01:31:28 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Thu, 23 Oct 2014 17:31:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <5446886D.6040903@nostrum.com> References: <5446886D.6040903@nostrum.com> Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/yzYFPsSwBFoXo2dHZJt_MO1W6Bw Subject: Re: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:31:30 -0000 Hi, thank you for an attentive summary. I agree your recognize-and-restrict approach. Shinji >As Shinji pointed out, the whole reason we have immediate NOTIFY in >subscription >dialogs is that only one of the 200 OKs to a forked SUBSCRIBE will ever >make it >back to the subscriber. Trying to carry any information, like the proposed >Refer-Events-At, in the response to a REFER that might fork is going to >have >the same problem. > >A big "Thank You" to everyone who brainstormed possible ways we might do >things >differently. (I'll summarize and expand on what was discussed before the >message >is over). > >After kicking this around for awhile, I think the right thing to do with >this >realization is acknowledge the limitation in the mechanism, rather than try >to change the mechanism to avoid it. > >My proposal will be to add text to the draft noting that if a REFER >forks, and >is accepted by more than one recipient, the UA sending the REFER will >only learn >the Refer-Events-At URI from one of those recipients, and which one is >out of its >control. So, the extension should only be used when that's ok for the >application >sending the REFER. That is, either there is enough information to know >that the >REFER will only be accepted in one place (as is the case if it is sent >in-dialog, >or Target-Dialog is provided in an out-of-dialog request), or the >application >doesn't care about tracking the resulting state if the request is accepted >in more than one place. If things would go wrong if the REFER were accepted >in more than one place and the referrer didn't learn about each of them, >then >the application must not use this extension (falling back into a >6665-subscription >creating REFER instead). > >I know that as engineers, we find this kind of shortcoming distateful. >But, pragmatically, there isn't a strong demand for solving the general >problem. > >If I'm wrong about that, and we decide we must figure out how to get >information >back from every place a forked REFER is accepted, I see three basic paths >to choose from (based on the recent conversations, and some really old >ones - >remember HERFP - this is like that, only harder). Again, this is talking >only >about cases where the REFER might fork - we'll deal with in-dialog or other >non-forking cases separately. > >1) Modify proxy behavior to aggregate the responses. As pointed out on >the list >already, this really a non-starter - it means the proxy will have to hold >the first 200 in case others arrive, forcing it into the bad places of long >non-invite transactions as detailed in RFC4320 and RFC4321. > >2) Send an out-of-dialog request from each accepting endpoint back in the >other direction. We'd have to work through making sure the request would >get back to the right place (probably using GRUUs). We'd have to choose >or define a method (NOTIFY has been suggested, and the "must be in a dialog" >problems with that pointed out. INFO has the same problem. We could abuse >MESSAGE, but it's probably better just to define a new method if we decide >to go down this path. > >3) Solve the problem with dialogs. Probably by starting with a new INVITE >that negotiates no (or baseline held) media. Wherever that INVITE is >accepted, you end up with separate dialogs. A separate REFER could then >be sent within each dialog, and would be guaranteed to be accepted in only >one place. This would mean defining behavior for that INVITE (probably >involving a Require extension), and detailing when that INVITE dialog >would shut down. > >Does anyone see any other class of alternatives? > >Again, my recommendation is that we don't pursue _any_ of them, and >go with the recognize-and-restrict approach I suggest at the beginning >of this message. > >RjS From nobody Thu Oct 23 11:24:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE421A87BB for ; Thu, 23 Oct 2014 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 GoTti1e7Cx47 for ; Thu, 23 Oct 2014 11:24:10 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DBD1A0262 for ; Thu, 23 Oct 2014 11:24:10 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with comcast id 6iPf1p0045AAYLo01iQ9TE; Thu, 23 Oct 2014 18:24:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id 6iQ81p00P3Ge9ey01iQ92p; Thu, 23 Oct 2014 18:24:09 +0000 Message-ID: <544947C8.7090006@alum.mit.edu> Date: Thu, 23 Oct 2014 14:24:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20141021192636.17296.13012.idtracker@ietfa.amsl.com> <5446B97F.5010508@nostrum.com> In-Reply-To: <5446B97F.5010508@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414088649; bh=AexNShLQ/jbmAg3VnSJxgKDT2SuZZmJ7joMCViDxPgg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JKvEQe1m9RV3GjT+kPjrg/y76UZEG5UzRSgV3I8UbNER5uYIqVeYhn2bxpmAEXHgk Mql3d19gTPgLzydp+XBOYtRs0hPkGqjty6R4TNBUwrilqZkpgLfeiTwopDRMwVYAT1 QBy+rvEmOgYNCQYnT9khUaIBV7nrtOjCkNWt63vcPt+QJm2hFgNxvw7wrmPAelQpLz 3QK+TDD57fcKndP5Hmq7oKHaht6AKev/Y1+t30rCo54kSMdK5Psm1jy1fqAFrw8egy lsJsq3ahzwjX+4IoaNxdGoeU1J4Eu7pBSF3ABZid8bWS3kRbfXpWZMnqnTLs8ArS1u sEYeu0SnwbAOQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ewCScERAdcvldjmR0D_nMtef_Z4 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:24:12 -0000 This update seems good. I have one comment on section 4.3: Using a *GRUU* doesn't make the URI hard to guess. Using a *temporary GRUU* does. Thanks, Paul On 10/21/14 3:52 PM, Robert Sparks wrote: > fyi > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-02.txt > Date: Tue, 21 Oct 2014 12:26:36 -0700 > From: internet-drafts@ietf.org > To: Robert Sparks , Robert Sparks > > > > > A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-02.txt > has been successfully submitted by Robert Sparks and posted to the > IETF repository. > > Name: draft-sparks-sipcore-refer-explicit-subscription > Revision: 02 > Title: Explicit Subscriptions for the REFER Method > Document date: 2014-10-21 > Group: Individual Submission > Pages: 13 > URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-02.txt > Status:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ > Htmlized:http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-02 > Diff:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-02 > > Abstract: > The Session Initiation Protocol (SIP) REFER request, as defined by > RFC3515, triggers an implicit SIP-Specific Event Notification > framework subscription. Conflating the start of the subscription > with handling the REFER request makes negotiating SUBSCRIBE > extensions impossible, and complicates avoiding SIP dialog sharing. > This document defines extensions to REFER to remove the implicit > subscription and, if desired, replace it with an explicit one. > > > > > 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. > > The IETF Secretariat > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Oct 23 12:01:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CA91ACE39 for ; Thu, 23 Oct 2014 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 IA1e28C_r_BZ for ; Thu, 23 Oct 2014 12:01:25 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0E11A1B0B for ; Thu, 23 Oct 2014 12:01:12 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-08v.sys.comcast.net with comcast id 6j1A1p0054s37d401j1CLj; Thu, 23 Oct 2014 19:01:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id 6j1B1p00A3Ge9ey01j1BMl; Thu, 23 Oct 2014 19:01:11 +0000 Message-ID: <54495077.8090502@alum.mit.edu> Date: Thu, 23 Oct 2014 15:01:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414090872; bh=Z18poxfdlrWS8KTZILoaLeaCzjUWj2OTLW/hVRA1ZFo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tfu7oxuFPcVwpNt3sr2QCjH9L3XGSaosgFNDRKCSlcrVmVFvAXo/7i2lwpbkwoFfr qvEPVqvELflz6pcVUTJAMLJ8a1xjtVLiPXI91BGmPxmt77icsKkQd7IPWO9mrQPGDD 5ZSsNLaY6aHlg4k4NCsD8IfXO1VdgzmRVPlAXur/GWjl9GeXdNYjifaS6ou+1UDDqz 0Jv6l6a0VripTiufJ7rs37Gp7qeAmFnglTABFbcu6bRsgCr8ZnAsuE/xdEQIFXNut8 3Kqil2QRY7u7hSVV9iiGFkBpegKauo4yooLPaB1AtjILpbZfpCtxOWtQsaaLA+WO3/ 7+z0bWY45xLDQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3UOehCKRTafwwrSIP6MQbu9gnq0 Subject: [sipcore] Agenda Items for SIPCORE at IETF91 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:01:31 -0000 Now is the time to speak up if you want time on the SIPCORE agenda for the upcoming meeting. Please provide a rough outline of what you want to cover and how long you think you need to do so. We have a one-hour session on Thursday, Nov 13. Thanks, Paul From nobody Sun Oct 26 22:58:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E21A899A; Sun, 26 Oct 2014 22:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 E4SLt02gJbBt; Sun, 26 Oct 2014 22:58:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000B1A8997; Sun, 26 Oct 2014 22:58:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027055847.11522.93702.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 22:58:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Ylk8UdEy8MqHK7BludS25QP8YTA Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 05:58:50 -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 Working Group of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Filename : draft-ietf-sipcore-dns-dual-stack-01.txt Pages : 7 Date : 2014-10-26 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 supplements the DNS procedures described in RFC 3263 for dual-stack SIP implementations and ensures that they properly align to the optimizations detailed by Happy Eyeballs. 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: http://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 03:34:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B921A8A81 for ; Mon, 27 Oct 2014 03:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ZXTiM-JGQTAr for ; Mon, 27 Oct 2014 03:34:22 -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 CA61F1A00B9 for ; Mon, 27 Oct 2014 03:34:21 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-e3-544e1fab634b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DC.6A.24955.BAF1E445; Mon, 27 Oct 2014 11:34:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 11:34:19 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new: draft-holmberg-sipcore-auth-id-00 Thread-Index: Ac/x0Q7ntDA1xteHSdGOS23Vmv2yqg== Date: Mon, 27 Oct 2014 10:34:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CC977ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje4aeb8Qg7fb2Cy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLfP9zEVTJSsuHIhr4FxmVgXIyeHhICJxPR/U1ggbDGJC/fW s3UxcnEICRxhlDi3dg8rhLOEUWJyVytQFQcHm4CFRPc/bZAGEQFNieXftrKD2MICphLt35uY IeJWEgsf9zFC2HoSC28uB1vAIqAq8WHyfFYQm1fAV2Lm/u1gNYxAi7+fWsMEYjMLiEvcejKf CeIgAYkle84zQ9iiEi8f/2OFsBUl2p82MELU50u86OxkhJgpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQT IzAiDm75rbqD8fIbx0OMAhyMSjy8H2p8Q4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA6PF55MyPw2WGDe6zpx6xU9nxlbBuxmiMU2bcvZPifi8qHPPsd4L l9b8bOjw89wuvHWz7NSjB6eaG7X1B6yXqV1+n+XSfJ6rR02ljQ8z+p0Jdb9rnszXuOZGk9Du h6/Uw/qlb9h/usP5983tFCnPnV5hxjdSai4tUf4nUalwJ2618I3k/17esj1KLMUZiYZazEXF iQBOHTP4aQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VtueDxPcblN2FyBWzegJ0MHutjY Subject: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:34:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CC977ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new draft, draft-holmberg-sipcore-auth-id-00. The draft defines a new Authorization header field parameter, which can car= ry a string value identifying an authorization server, based on a requireme= nt from 3GPP (the mechanism is general, though). The mechanism can be used together with the mechanism defined in draft-yuse= f-sipcore-sip-oauth-01. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4CC977ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new draft, draft-holmberg-sip= core-auth-id-00.

 

The draft defines a new Authorization header field p= arameter, which can carry a string value identifying an authorization serve= r, based on a requirement from 3GPP (the mechanism is general, though).

 

The mechanism can be used together with the mechanis= m defined in draft-yusef-sipcore-sip-oauth-01.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4CC977ESESSMB209erics_-- From nobody Mon Oct 27 07:02:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971861A8ACA for ; Mon, 27 Oct 2014 07:02:40 -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 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 XNfMKHHY2zOT for ; Mon, 27 Oct 2014 07:02:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5FB811ACD27 for ; Mon, 27 Oct 2014 07:02:00 -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.14.9/8.14.7) with ESMTP id s9RE1vbx014614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 09:01:58 -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 Message-ID: <544E5055.8040901@nostrum.com> Date: Mon, 27 Oct 2014 09:01:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Kyzivat , sipcore@ietf.org References: <7ECFBBA7034CE9ietf.shinji@gmail.com> <54469111.7020103@nostrum.com> <5446A130.9010602@alum.mit.edu> In-Reply-To: <5446A130.9010602@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/C5_lPfFPZebXeiySHXvENyaNr7k Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:02:40 -0000 On 10/21/14 13:08, Paul Kyzivat wrote: > I'd like some clarity on what "must use a gruu" means. > Does this mean the contact must have a "gr" parameter, or only that it > must be globally routable? (Note that 3261 has always required contact > URIs to be globally routable.) The key difference is that with a "gr" > parameter the other end can verify that the uri has been asserted to > be globally routable. I'm using GRUU as a shorthand for "the mechanism described in RFC5627" because it's easier to type. I think applying the term "GRUU" to other kinds of URIs, regardless of their routing properties, is going to muddy the waters, and make it nearly impossible to talk about the RFC5627 mechanism. In any case, the global routability of Contacts hasn't been true in a formal sense since the introduction of RFC3327, and hasn't been true in a practical sense since the introduction of NATs. We can't rely on it being true; and, in fact, it's going to be false in the vast majority of cases unless RFC5627 is employed. /a From nobody Mon Oct 27 07:17:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1C1ACD9B for ; Mon, 27 Oct 2014 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7QrB-tEzuyNE for ; Mon, 27 Oct 2014 07:17:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 276101ACD31 for ; Mon, 27 Oct 2014 07:16:19 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9REGIaR015826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 27 Oct 2014 09:16:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <544E53AD.40501@nostrum.com> Date: Mon, 27 Oct 2014 09:16:13 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20141027141311.22375.35723.idtracker@ietfa.amsl.com> In-Reply-To: <20141027141311.22375.35723.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027141311.22375.35723.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000202080101050504010604" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/2yEIRiJh1TVSfd236-AUeSechF0 Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:17:04 -0000 This is a multi-part message in MIME format. --------------000202080101050504010604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit -------- Forwarded Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-clarifications-05.txt Date: Mon, 27 Oct 2014 07:13:11 -0700 From: internet-drafts@ietf.org To: Adam Roach , Adam Roach , Robert Sparks , Robert Sparks A new version of I-D, draft-sparks-sipcore-refer-clarifications-05.txt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-clarifications Revision: 05 Title: Clarifications for the use of REFER with RFC6665 Document date: 2014-10-27 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-05.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/ Htmlized: http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-05 Abstract: An accepted SIP REFER method creates an implicit subscription using the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. 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. The IETF Secretariat --------------000202080101050504010604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


-------- Forwarded Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-clarifications-05.txt
Date: Mon, 27 Oct 2014 07:13:11 -0700
From: internet-drafts@ietf.org
To: Adam Roach <adam@nostrum.com>, Adam Roach <adam@nostrum.com>, Robert Sparks <rjsparks@nostrum.com>, Robert Sparks <rjsparks@nostrum.com> 


A new version of I-D, draft-sparks-sipcore-refer-clarifications-05.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-refer-clarifications
Revision:	05
Title:		Clarifications for the use of REFER with RFC6665
Document date:	2014-10-27
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-05.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-05

Abstract:
   An accepted SIP REFER method creates an implicit subscription using
   the SIP-Specific Event Notification Framework.  That framework was
   revised by RFC6665.  This document highlights the implications of the
   requirement changes in RFC6665, and updates the definition of the
   REFER method, RFC3515, to clarify and disambiguate the impact of
   those changes.

                                                                                  


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.

The IETF Secretariat


--------------000202080101050504010604-- From nobody Mon Oct 27 07:46:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463C01ACDD6 for ; Mon, 27 Oct 2014 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 S0ry3o3eCaxC for ; Mon, 27 Oct 2014 07:45:41 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0471A87E8 for ; Mon, 27 Oct 2014 07:45:32 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-03v.sys.comcast.net with comcast id 8El71p00353iAfU01ElYuF; Mon, 27 Oct 2014 14:45:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id 8ElX1p00S3Ge9ey01ElXqd; Mon, 27 Oct 2014 14:45:32 +0000 Message-ID: <544E5A8B.3080009@alum.mit.edu> Date: Mon, 27 Oct 2014 10:45:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Roach , sipcore@ietf.org References: <7ECFBBA7034CE9ietf.shinji@gmail.com> <54469111.7020103@nostrum.com> <5446A130.9010602@alum.mit.edu> <544E5055.8040901@nostrum.com> In-Reply-To: <544E5055.8040901@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414421132; bh=+46WQM2EK5nIf4RLuUXrRY3p74SRsH+4VsQsf8rCnK0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qFmglNIyvjyMiyJZGTiES8DZCVxrSH4B/GoKD+xOzBRhVFBeqFL84TRBMGx5v47/6 Rz+2wVBSoLcbRas7SYAi2hJ4NZe9c5War7FQN4+wp82A0/IgrQkvUczEJ7UjxO7TAg q8EYt/PVIh1iGcuv1iXuxcjVNfNK91X6dTfIq99job95H2odyf433Pxr5XLXuJlWP6 1GZEpjq+rHbdGrYxMTtGj5Yj7ivX/elO6CgjYDK1JZQZs1zkjFvSVlq3NmAEksODyW gN4lBDvx/3vbwP6Hw0aOH0ETYREZ4uNYWKovxf+6+bcqub1Y+HIgiaROeDGInkc09h MBb8MjAO0CmKg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Nml5xw3WRgNlvWr1SMIkZqTLG-M Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:45:42 -0000 On 10/27/14 10:01 AM, Adam Roach wrote: > On 10/21/14 13:08, Paul Kyzivat wrote: >> I'd like some clarity on what "must use a gruu" means. >> Does this mean the contact must have a "gr" parameter, or only that it >> must be globally routable? (Note that 3261 has always required contact >> URIs to be globally routable.) The key difference is that with a "gr" >> parameter the other end can verify that the uri has been asserted to >> be globally routable. > > I'm using GRUU as a shorthand for "the mechanism described in RFC5627" > because it's easier to type. I think applying the term "GRUU" to other > kinds of URIs, regardless of their routing properties, is going to muddy > the waters, and make it nearly impossible to talk about the RFC5627 > mechanism. > > In any case, the global routability of Contacts hasn't been true in a > formal sense since the introduction of RFC3327, and hasn't been true in > a practical sense since the introduction of NATs. We can't rely on it > being true; and, in fact, it's going to be false in the vast majority of > cases unless RFC5627 is employed. My concern is not with generic user endpoints, but with servers managed by enterprises or service providers. For instance a conference focus. These may have well known URIs, but they don't get them via registration. RFC5627 does cover these - they are called self-made GRUUs. It does call for these to be marked with a "gr" parameter. So then in practice, the requirement is that the contact have a "gr" parameter, and conform to RFC5627 for use of that. Thanks, Paul From nobody Mon Oct 27 14:15:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EEF1ACE30 for ; Mon, 27 Oct 2014 14:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 Fm_F6LBZa-sr for ; Mon, 27 Oct 2014 14:15:34 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271681AD53A for ; Mon, 27 Oct 2014 14:15:34 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-01v.sys.comcast.net with comcast id 8MFJ1p0044vw8ds01MFZVd; Mon, 27 Oct 2014 21:15:33 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-04v.sys.comcast.net with comcast id 8MFY1p00E1KKtkw01MFYKx; Mon, 27 Oct 2014 21:15:33 +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 s9RLFV2Z004632; Mon, 27 Oct 2014 17:15:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9RLFV0j004631; Mon, 27 Oct 2014 17:15:31 -0400 Date: Mon, 27 Oct 2014 17:15:31 -0400 Message-Id: <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414444533; bh=VfWsuJWTatsRlE8gNqLaTmtDc+Gl3QRToNTgn+DxBF4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=LyYoEcKiPGwBdOpTw2FEm+Lsd7k0nlzXu6SPHce1DQ9EqChexiYVSrfzmi1WmtVpY TNwWDRqyFnknO2glc/v+6NRcIQDXxRE5EiS9MaSftDk0Kc6078PAxt5OLqujdZxig6 N9UeN+kVvB9qCwcAijkkXPWBUcgB8TMogCHbL6kzCOHCPKjBibGgaDaN1Zoq9LXFGI t/a7aJjzePikjPbcFMUQ1Ydi+UR46wimarPsKxXqBep9Rz8KVB/XBWMWBnRtOoige3 Hxu2TSp7uIsYfaddmi891Gj3QyEJuAZs8CW3eLcV3M1KkBT99BGQ/X3leJ3J69aTHi PC0nUz0PNbN+w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FhMiDqMHFayd5KQbPyq1tVPmyJI Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:15:38 -0000 > From: Christer Holmberg > > I've submitted a new draft, draft-holmberg-sipcore-auth-id-00. It would help if the Abstract was rewritten so that one did not need to know the meanings of "eP-CSCF", "WAF", and "S-CSCF" to understand what the mechanism can do. > The draft defines a new Authorization header field parameter, which > can carry a string value identifying an authorization server, based > on a requirement from 3GPP (the mechanism is general, though). The text says that the "authorization-entity" parameter carries "a string value which represents the identity of an authorization server". You might want to expand on that. I'm guessing it means that any entity that wants to verify the authorization of the REGISTER request should present the request contents to the specified authorization server. Dale From nobody Tue Oct 28 01:29:28 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD21B1A1A36 for ; Tue, 28 Oct 2014 01:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 7hDUJwvSgts9 for ; Tue, 28 Oct 2014 01:28:43 -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 F0AAB1A1A17 for ; Tue, 28 Oct 2014 01:28:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-87-544f53b8301f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5B.9D.04387.8B35F445; Tue, 28 Oct 2014 09:28:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 09:28:40 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 Thread-Index: Ac/x0Q7ntDA1xteHSdGOS23Vmv2yqgAWhenxABdeweA= Date: Tue, 28 Oct 2014 08:28:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> In-Reply-To: <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7OYP8QgyU7+S2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHzeg9LwWuuip1/57A3MN7k6GLk5JAQMJFY uu88I4QtJnHh3nq2LkYuDiGBI4wSxyfMZIVwljBKdN2fDJTh4GATsJDo/qcNYooIaEp0LMgB 6WUGMh/t3MsEYgsLOEt0zZzADmKLCLhIXJv5kxnCtpJYuruRBcRmEVCV6Nv5GKyGV8BX4t+7 biaIVc1Aq5Z8ZwKZzyngIDG/RwGkhhHotu+n1jBB7BKXuPVkPhPEzQISS/acZ4awRSVePv7H CtIqIaAosbxfDqJcR2LB7k9sELa2xLKFr5kh1gpKnJz5hGUCo9gsJFNnIWmZhaRlFpKWBYws qxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+fglt9WOxgPPnc8xCjAwajEw7uBzT9EiDWx rLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw9ut86gpLKlNYoD7l q1pUdJjX7v6w3g5N7Q+/EvL9vXY08fxIvtK98CDr4YdXlL5sWmtX//D6Pj8vG7nCI5HKfW6l /xeu5K77812wa/7GR7WGKYJhy7vyTF/fW59zbaZ/lRxj/5KQA/cPRDl/11n20jgt8LDix3vx m84/XDTlrMlZg5urSpcnK7EUZyQaajEXFScCALvEV2l9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/uq7A53VAFIOR7QByC2tF_Blnfwc Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 08:28:44 -0000 Hi, >> I've submitted a new draft, draft-holmberg-sipcore-auth-id-00. > > It would help if the Abstract was rewritten so that one did not need to k= now the meanings of "eP-CSCF", "WAF", and "S-CSCF" to understand what the m= echanism can do. I had very limited time to write the draft, so that's the reason it ended u= p in this way. But, I DO agree with you, and that will be fixed in the next= version :) >> The draft defines a new Authorization header field parameter, which=20 >> can carry a string value identifying an authorization server, based on=20 >> a requirement from 3GPP (the mechanism is general, though). > > The text says that the "authorization-entity" parameter carries "a string= value which represents the identity of an authorization server". You migh= t want to expand > on that. I'm guessing it means that any entity that wants to verify the = authorization of the REGISTER request should present the request contents t= o the specified=20 > authorization server. I am not sure I understand what you mean by "present the request contents t= o the specified authorization server". The identity is obtained from the au= thorization server (or, the eP-CSCF knows it by configuration). The identit= y is then provided to the S-CSCF (SIP registrar), which can use the informa= tion for policy decisions. Regards, Christer From nobody Tue Oct 28 08:20:18 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14181A8AB8 for ; Tue, 28 Oct 2014 08:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 nwglKVlk0JT6 for ; Tue, 28 Oct 2014 08:20:05 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EA01A8AAD for ; Tue, 28 Oct 2014 08:20:05 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-04v.sys.comcast.net with comcast id 8fKj1p0055FMDhs01fL4Yu; Tue, 28 Oct 2014 15:20:04 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-19v.sys.comcast.net with comcast id 8fL31p00Q1KKtkw01fL4b6; Tue, 28 Oct 2014 15:20:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9SFK3dY007234; Tue, 28 Oct 2014 11:20:03 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9SFK2gC007233; Tue, 28 Oct 2014 11:20:02 -0400 Date: Tue, 28 Oct 2014 11:20:02 -0400 Message-Id: <201410281520.s9SFK2gC007233@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414509604; bh=PIhgabzERcLNtjKowZWVrvcYKR/BF/l8RYTyiewgXg4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QZLWLyWS5rwRlnvf6Ca7i42UFEBzn6S98IMi7x9ixZebuLhztuFnB3zaHtwfLr9ew 81a5DoX8dIEKFnIagFt6HhfnlNkQe+M0N+AvwPkfX01mHjhL7/5FlqPBeBXhDe018D kuuPkwsLb7fA7NIYQt6heOIImTJ3nOcQGn0EmO0LpWZWeYbVjFjOmXczxdZoFiIw0E R2gXV7LXBPM69wlo81ERpZoUuZLl/oghF+axQA3cYIbYAXqPnaJIo+DHhNC/T7Byj7 HfbrvWCWpJMhxsXFbBjSXkiTjHoNKBKi91Xwdz5USZQ+cap4jni8wtpG3HQz7ev53F up7vymxy13J+w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sp9aEpmaZIi_I-dlCkkH_OJ2Ndw Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:20:07 -0000 > From: Christer Holmberg > >> The draft defines a new Authorization header field parameter, which > >> can carry a string value identifying an authorization server, based on > >> a requirement from 3GPP (the mechanism is general, though). > > > > The text says that the "authorization-entity" parameter carries "a > > string value which represents the identity of an authorization > > server". You might want to expand on that. I'm guessing it means > > that any entity that wants to verify the authorization of the > > REGISTER request should present the request contents to the > > specified authorization server. > > I am not sure I understand what you mean by "present the request > contents to the specified authorization server". The identity is > obtained from the authorization server (or, the eP-CSCF knows it by > configuration). The identity is then provided to the S-CSCF (SIP > registrar), which can use the information for policy decisions. The general idea is this: Suppose the reader has no idea how IMS does things. Within the SIP authorization model(s) presented in the RFCs, what is the function of "authorization-entity"? I assume that you intend to extend the set of SIP authorization models; it's necessary to describe, at least in outline, what the new authorization model is and how "authorization-entity" is used in it so people can tell whether they want to use it in their SIP implementations and how they would do so. As this draft is currently written, it seems to be "IMS needs this, so we'll write that down and call it an RFC". It needs considerable clarification. Dale From nobody Tue Oct 28 08:58:24 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C81A8F41 for ; Tue, 28 Oct 2014 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 4LFrlVOzm9vd for ; Tue, 28 Oct 2014 08:58:21 -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 57A461A8BC4 for ; Tue, 28 Oct 2014 08:57:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-01-544fbcfe9776 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.48.04387.EFCBF445; Tue, 28 Oct 2014 16:57:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 16:57:50 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 Thread-Index: Ac/x0Q7ntDA1xteHSdGOS23Vmv2yqgAWhenxABdeweAADoG8kwAA+RFA Date: Tue, 28 Oct 2014 15:57:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D1148@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> <201410281520.s9SFK2gC007233@hobgoblin.ariadne.com> In-Reply-To: <201410281520.s9SFK2gC007233@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje6/Pf4hBrcnq1h8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PdkjdMBb0iFSdfH2VpYFwk0MXIySEhYCLx oOMpO4QtJnHh3nq2LkYuDiGBI4wSFya+ZoZwljBKvHn8BCjDwcEmYCHR/U8bxBQR0JToWJAD 0ssMZD7auZcJxBYWcJbomjkBbKaIgIvEtZk/mSFsN4nZJ5+BTWERUJWY8DodJMwr4Cvxe+Y6 qE1/GSUm9nUwgtRwCjhIbNvECFLDCHTa91NrmCBWiUvcejKfCeJkAYkle84zQ9iiEi8f/2OF sJUkFt3+DFWvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYyi xanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBkXNwy2+rHYwHnzseYhTgYFTi4d3A5h8ixJpYVlyZ e4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYm7U/ldQY5vrlKMXVcH7o CC7rvTS7OPBNp3m2lv6DOVK62vkPSjff/VKwOy/4z42Z7jN0M5b+ddqg3avlcWNy0JyHac+f PnQ/Oa/Z9/yj/GbuV19Cu7gquvx/3Lg8q5ZjdnSs4usK5ql7MmpMtwXuDeSPvmy7Qc3my1nG QxPPCk/a/7z6nVeOEktxRqKhFnNRcSIA71qfUH0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/I0oCCUl562j5e4w2V0Tfje2Cawo Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:58:22 -0000 Hi, >>>> The draft defines a new Authorization header field parameter, which=20 >>>> can carry a string value identifying an authorization server, based=20 >>>> on a requirement from 3GPP (the mechanism is general, though). >>> >>> The text says that the "authorization-entity" parameter carries "a=20 >>> string value which represents the identity of an authorization=20 >>> server". You might want to expand on that. I'm guessing it means=20 >>> that any entity that wants to verify the authorization of the=20 >>> REGISTER request should present the request contents to the=20 >>> specified authorization server. >>=20 >> I am not sure I understand what you mean by "present the request=20 >> contents to the specified authorization server". The identity is=20 >> obtained from the authorization server (or, the eP-CSCF knows it by=20 >> configuration). The identity is then provided to the S-CSCF (SIP=20 >> registrar), which can use the information for policy decisions. > > The general idea is this: Suppose the reader has no idea how IMS does th= ings. Within the SIP authorization=20 > model(s) presented in the RFCs, what is the function of "authorization-en= tity"?=20 The function is to provide the authorization server identity to the S-CSCF = (registrar). The S-CSCF MAY use that information when authorizing a user. F= or example, it can check whether the authorization server is authorized to = provide IMS credentials to the user. 3GPP does not mandate the usage of the information, and does not specify th= e policy procedures how it's used. 3GPP only requires the information to be= conveyed to the S-CSCF. > I assume that you intend to extend the set of SIP authorization models; i= t's necessary to describe, at least in outline, what the new authorization = model is and how=20 > "authorization-entity" is used in it so people can tell whether they want= to use it in their SIP implementations and how they would do so. The way the IMS core authorizes users as such is not changed.=20 The information is there so that IMS can use the information to check wheth= er the authorization server is used, but that authorization server may serv= e multiple users.=20 > As this draft is currently written, it seems to be "IMS needs this, so we= 'll write that down and call it an RFC". It needs considerable clarificati= on. As always, we need to decide whether there is any interest for this outside= 3GPP. But, I am happy to provide more information/clarification. Regards, Christer From nobody Tue Oct 28 14:12:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B421ACFC4 for ; Tue, 28 Oct 2014 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 kg7-wDktdVYt for ; Tue, 28 Oct 2014 14:12:21 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7161ACFC3 for ; Tue, 28 Oct 2014 14:12:21 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-04v.sys.comcast.net with comcast id 8lC61p0034ueUHc01lCLwe; Tue, 28 Oct 2014 21:12:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 8lCK1p00A3Ge9ey01lCK40; Tue, 28 Oct 2014 21:12:19 +0000 Message-ID: <545006B3.4000505@alum.mit.edu> Date: Tue, 28 Oct 2014 17:12:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <54495077.8090502@alum.mit.edu> In-Reply-To: <54495077.8090502@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414530740; bh=lSeHYFWtHvxSGbNs/Cq4MyXPJ4vazAb4hpmVzmruS+s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iVFT0RKLXaZERZ6d8zTCc+t1lZnh5bXwQaffC/tVWXbo33l8Xpf3dWapAO6XKG1el 3W570z7aggCTekm4LUOgZrju80BS0a3Qbx0uhsfS7dcp/5CBymBrn+iGnBqz7NmY8Q Be4w5iWEwEAd6m6yR4F5ls4RXk1Eauyg9LeOFpYsGyx4AwsLueOrs/GxNwNC9YHrKZ FhUanFo0afgDy0qPH5PKCnbXxfbToiXiOBXEFdHkn3TJv7cz78d3d11H8+zXBxi+0P HzxgWgOQbqE+Sov9o1Uk+rglDZ7UcLFMtRkOtkkC3yFkGZqSXJhgBWxTdz3u6FNV8z loygnqtQxQbeA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Xgul4aIjxgrdYIl09f0sqZcsrpU Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:12:23 -0000 I have now heard from three people with requests for agenda time. Based on those requests, I've posted a *preliminary* agenda, at: http://www.ietf.org/proceedings/91/agenda/agenda-91-sipcore We only have a one hour slot, and there are requests for more time that that. For now I have assigned Robert his minimum requested time for the two REFER drafts. I consider them the highest priority, and if need be we will let them run longer. For now I simply divided the remaining time among the other requests. But I don't expect it to stay that one. One of those is back for the 2nd time, with updates responding to comments in Toronto. It most likely will have priority over the others. The other two are new. Rifaat's key derivation draft has had some list discussion. Christer's is newer, and has had just a little bit of list discussion. It is probably counterproductive to give each draft too little time. So I'll be watching which ones have the most list discussion between now and the meeting, and will juggle the times accordingly. Thanks, Paul On 10/23/14 3:01 PM, Paul Kyzivat wrote: > Now is the time to speak up if you want time on the SIPCORE agenda for > the upcoming meeting. Please provide a rough outline of what you want to > cover and how long you think you need to do so. > > We have a one-hour session on Thursday, Nov 13. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Oct 29 00:11:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8FA1A1AED for ; Wed, 29 Oct 2014 00:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hv41NrlckqY8 for ; Wed, 29 Oct 2014 00:11:31 -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 3F5381A03A7 for ; Wed, 29 Oct 2014 00:11:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-e1-545093214607 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.AF.04387.12390545; Wed, 29 Oct 2014 08:11:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:11:28 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Agenda Items for SIPCORE at IETF91 Thread-Index: AQHP7vPIg+brXp67R0mMBY8XfSdd6JxF+QuAgAC1OBA= Date: Wed, 29 Oct 2014 07:11:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D26FE@ESESSMB209.ericsson.se> References: <54495077.8090502@alum.mit.edu> <545006B3.4000505@alum.mit.edu> In-Reply-To: <545006B3.4000505@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja7i5IAQg2t9QhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxbz9bwXKJiqdrzRsYTwh3MXJySAiYSLSf 3c4IYYtJXLi3nq2LkYtDSOAIo0R3710mCGcJo8TKr3dZuxg5ONgELCS6/2mDNIgIBEpcXTKB GcQWFrCU2NoE0gwSt5KYMPceK4zdee8GWJxFQFXi6c3PYHFeAV+Jli3T2UFsIQFviYsHH4Id wSmgI/Fq4SKwmYxAB30/tYYJxGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/gd2moSAosTyfjmI ch2JBbs/sUHY2hLLFr5mhlgrKHFy5hOWCYyis5BMnYWkZRaSlllIWhYwsqxiFC1OLS7OTTcy 0kstykwuLs7P08tLLdnECIyQg1t+W+1gPPjc8RCjAAejEg9vwYSAECHWxLLiytxDjNIcLEri vAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDhnt0PW+xeeGfobHMPvF/y7dor7qLUD 3/GlqYltDNum8XnfyNw4c+LVU7z7ZZ/8ajgxxynz9gtmzRsTjm1fxZvXUmy5PPDZxx8u8T5H E1vfB7Xtvr+Dr7/8poFFT3p29Bwus708v+Omuv9bLH9QvqeEbelp9qpZU+Vv6DG7nbTO2jvP QnuKUKcSS3FGoqEWc1FxIgBp+N73cQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HEhPJSb7haemGqUGsbDMLNn8FVw Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 07:11:38 -0000 Hi, Some comments on the pre-agenda: First, as I think 10 (or shorter) minute slots at f2f meetings are not very= useful, I am willing to give up my slot (Authorization server identity), a= nd let you allocate that time to something else. However, I'd like to have = some off-line/list discussions on whether people think the solution could b= e of general interest, or whether it's only of interest to 3GPP. Second, while I do agree that Robert's draft has highest priority, do we re= ally need f2f time for Explicit Subscriptions for REFER? Are there any open= issues (we discussed the forking issue, but based on the input from people= I believe we came to a conclusion on how to move forward)? Can't we just c= all for adoption of the draft on the list? Third, 5 minutes for Clarifications on use of REFER is just enough for Hadr= iel to give his break-the-ice-joke-that-nobody-but-himself-understands :) A= nd, as there has actually been quite a bit of discussions on that draft, I'= d like the chairs to allocate more time for it. But, also in this case I th= ink we should ask for adoption on the list. =20 Thanks! Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 28. lokakuuta 2014 23:12 To: sipcore@ietf.org Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 I have now heard from three people with requests for agenda time. Based on those requests, I've posted a *preliminary* agenda, at: http://www.ietf.org/proceedings/91/agenda/agenda-91-sipcore We only have a one hour slot, and there are requests for more time that tha= t. For now I have assigned Robert his minimum requested time for the two RE= FER drafts. I consider them the highest priority, and if need be we will le= t them run longer. For now I simply divided the remaining time among the other requests.=20 But I don't expect it to stay that one. One of those is back for the 2nd ti= me, with updates responding to comments in Toronto. It most likely will hav= e priority over the others. The other two are new. Rifaat's key derivation draft has had some list disc= ussion. Christer's is newer, and has had just a little bit of list discussi= on. It is probably counterproductive to give each draft too little time. So I'l= l be watching which ones have the most list discussion between now and the = meeting, and will juggle the times accordingly. Thanks, Paul On 10/23/14 3:01 PM, Paul Kyzivat wrote: > Now is the time to speak up if you want time on the SIPCORE agenda for=20 > the upcoming meeting. Please provide a rough outline of what you want=20 > to cover and how long you think you need to do so. > > We have a one-hour session on Thursday, Nov 13. > > Thanks, > Paul > > _______________________________________________ > 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 Oct 29 12:04:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B54E1A885E for ; Wed, 29 Oct 2014 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 mQQSGaJX66s7 for ; Wed, 29 Oct 2014 12:04:19 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035E71A1A7C for ; Wed, 29 Oct 2014 12:04:18 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-01v.sys.comcast.net with comcast id 973j1p00B56HXL00174Jfo; Wed, 29 Oct 2014 19:04:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id 974H1p00Q3Ge9ey0174JWs; Wed, 29 Oct 2014 19:04:18 +0000 Message-ID: <54513A31.1080903@alum.mit.edu> Date: Wed, 29 Oct 2014 15:04:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <54495077.8090502@alum.mit.edu> <545006B3.4000505@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4D26FE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D26FE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414609458; bh=DRS+WbgW4ZLw3ZRV8A10mgvSBtZrH4i6FpciYJ93aKM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j2AXYP8bsEKx+2mpbOM7tXFBS93awD6YgD7VwXSkOkQ54Cispv+r/r47sat10cjJk vKYFVSeO5pdiiEm298TxHY10YBVdFovclaSkRhoqJyvHQmRWxnchAvZ1bsdu44hAtp 5ktmpWd2M2V9Q6R5/bbbpCwGyh+nL7kUptRGrGYSnNry/5IFYl705NQPbvU48Uz9r4 ZybMu5Eb4GmA45G9f3n8U+4tics8O0tzGRyGXgrZ93syR7EmB8YsoIXH454KHulq9U v5y03YloctXTYSGyfmd+xgy12itXgHKmQfANoRHnsHma5bn02i0FoNQ5rNMragw9gc sRS5R1jRXOCig== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/azutVqu25Evf1MB83g_0ca3Gqks Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:04:24 -0000 On 10/29/14 3:11 AM, Christer Holmberg wrote: > Hi, > > Some comments on the pre-agenda: > > First, as I think 10 (or shorter) minute slots at f2f meetings are not very useful, I agree. I was intending to fix that after some discussion. > I am willing to give up my slot (Authorization server identity), and let you allocate that time to something else. Thank you! > However, I'd like to have some off-line/list discussions on whether people think the solution could be of general interest, or whether it's only of interest to 3GPP. I haven't had time to review it yet. And now, if its not going to be on the agenda, I may not get to it until after the meeting. You may have better luck getting attention *after* the meeting. (Realistically that probably means early next year.) > Second, while I do agree that Robert's draft has highest priority, do we really need f2f time for Explicit Subscriptions for REFER? Are there any open issues (we discussed the forking issue, but based on the input from people I believe we came to a conclusion on how to move forward)? Can't we just call for adoption of the draft on the list? > Third, 5 minutes for Clarifications on use of REFER is just enough for Hadriel to give his break-the-ice-joke-that-nobody-but-himself-understands :) And, as there has actually been quite a bit of discussions on that draft, I'd like the chairs to allocate more time for it. But, also in this case I think we should ask for adoption on the list. Robert asked for at least 20 minutes, preferably 30, for both. The split between them was a swag by me. Thanks, Paul > Thanks! > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 28. lokakuuta 2014 23:12 > To: sipcore@ietf.org > Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 > > I have now heard from three people with requests for agenda time. > Based on those requests, I've posted a *preliminary* agenda, at: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-sipcore > > We only have a one hour slot, and there are requests for more time that that. For now I have assigned Robert his minimum requested time for the two REFER drafts. I consider them the highest priority, and if need be we will let them run longer. > > For now I simply divided the remaining time among the other requests. > But I don't expect it to stay that one. One of those is back for the 2nd time, with updates responding to comments in Toronto. It most likely will have priority over the others. > > The other two are new. Rifaat's key derivation draft has had some list discussion. Christer's is newer, and has had just a little bit of list discussion. > > It is probably counterproductive to give each draft too little time. So I'll be watching which ones have the most list discussion between now and the meeting, and will juggle the times accordingly. > > Thanks, > Paul > > On 10/23/14 3:01 PM, Paul Kyzivat wrote: >> Now is the time to speak up if you want time on the SIPCORE agenda for >> the upcoming meeting. Please provide a rough outline of what you want >> to cover and how long you think you need to do so. >> >> We have a one-hour session on Thursday, Nov 13. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Oct 29 14:35:54 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96531A90B5 for ; Wed, 29 Oct 2014 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 rLtqE2XdNm1z for ; Wed, 29 Oct 2014 14:35:51 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749DA1A90B1 for ; Wed, 29 Oct 2014 14:35:51 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-01v.sys.comcast.net with comcast id 99bc1p0022VvR6D019bqvD; Wed, 29 Oct 2014 21:35:50 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-19v.sys.comcast.net with comcast id 99bp1p00D1KKtkw019bqyD; Wed, 29 Oct 2014 21:35: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 s9TLZmsI018273; Wed, 29 Oct 2014 17:35:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9TLZmm1018272; Wed, 29 Oct 2014 17:35:48 -0400 Date: Wed, 29 Oct 2014 17:35:48 -0400 Message-Id: <201410292135.s9TLZmm1018272@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D4D1148@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> <201410281520.s9SFK2gC007233@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4D1148@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414618550; bh=fQynsBX3/a7WrxbvNMKC/vO9xz0gwQHsO/5HANgzWnU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=pTHXc/FkAgYsXitrvEGM11u98j1vZ7NmAaR87ZVg0WRB3LT1uNCQS3VwkpKfohQnD 8DJeQdPTIq3BMSnSkN5UtpSzoGWK3iwJ/06tOK9EZ0xWxhQfP3avyguSgoIYRiEEA6 N+bM4WlSQSIO6G7F4EhA8KUucFSpoLrLkDiogjk6SrcpMkWeJOUEl+rHv/U2Hbf4yW Eu19Hzu2ZHVVi281yMT6rQ2qH05z34LdGsn8BG5Vnnz42F/o+FdI4tqNPt2bGIj0Dk aQlZoIBt/GAf45j9hebeGBSg4ZkaDLACz0Q+gf9Yd7zf753QhVlSXM9cZuGZ+MIXUm 4jI26d9vaotpA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/aMgb7iGRH6hqPiX-wZDonofhqOE Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:35:53 -0000 > From: Christer Holmberg > The function is to provide the authorization server identity to the > S-CSCF (registrar). The S-CSCF MAY use that information when > authorizing a user. For example, it can check whether the > authorization server is authorized to provide IMS credentials to the > user. When you say "provide the authorization server identity", so you mean "provide the identity of the authorization server"? And does that mean that registrar/S-CSCF will use that as an input to its authorization check (as basically a string, much like the username and realm) or is it the DNS name of an authorization server that the registrar is supposed to query to check the validity of the credentials? I think that you mean the former rather than the latter. In that case, in what way does authorization-entity differ from the username and realm? > > I assume that you intend to extend the set of SIP authorization > > models; it's necessary to describe, at least in outline, what the > > new authorization model is and how "authorization-entity" is used > > in it so people can tell whether they want to use it in their SIP > > implementations and how they would do so. > > The way the IMS core authorizes users as such is not changed. OK, but is the way that IMS core authorizes users different from the usual SIP digest model? If so, documenting that authorization method could be useful for broader SIP usage. > As always, we need to decide whether there is any interest for this > outside 3GPP. But, I am happy to provide more > information/clarification. Granted. But to determine that, people outside of 3GPP need to know what the mechanism does, and that's not very clear yet. Dale From nobody Thu Oct 30 11:43:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870011A1A96 for ; Thu, 30 Oct 2014 11:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 VUGVaITpmFPz for ; Thu, 30 Oct 2014 11:43:31 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDE31A1A94 for ; Thu, 30 Oct 2014 11:43:31 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-05v.sys.comcast.net with comcast id 9Wik1p0014ueUHc01WjWAP; Thu, 30 Oct 2014 18:43:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 9WjU1p00K3Ge9ey01WjUWP; Thu, 30 Oct 2014 18:43:30 +0000 Message-ID: <545286D0.2090303@alum.mit.edu> Date: Thu, 30 Oct 2014 14:43:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org, "Vijay K. Gurbani" References: <5398A125.60202@alum.mit.edu> <5398C111.7000700@bell-labs.com> In-Reply-To: <5398C111.7000700@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414694610; bh=xOyT/AHk+fWfnc2rP5uJVSpxIuruUUG7j+B9Pz7YRVE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=osEJ73/z2nfgC5Ic7whKOrcdmJ6V9lNEDgXCeK8+nauMeP21YJkZY2WbRsCipfr70 mpc3KTl129iTSGXKCZJclo8f6eVB5wWYyjRzssSf3q2iCWRi1+j07fYkVPo3pNb9rW FWiZ6Pl8pPkM6zFfuaT/nAA6wMNseM1ItD+qgtwfnPjNbWXkjmyG9eangKwInUjm5o Huo5u/oDzmYomBLYuri0thmFC8SFSLN7vJFS9eibxJdUKpwaeha6YKEtKnKmEBYJRE Omr5g9p2Qp6GNQMdj7hcxJiPsBxGxSMyMkYVebDcrrk3SOOtsKJZ7Nx2jU2YSxcHW4 idkdscuvcfDqw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/x27z7buWWxQp7rdDtm-LjkK-WPs Subject: Re: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:43:32 -0000 I've been negligent in pushing this draft along. There has been no action since Toronto, except that the draft was just refreshed to keep it from expiring. I don't currently have it on the agenda for the Honolulu meeting because there has been no action and no request from the authors. I would like to get this one wrapped up. Thanks, Paul IIUC the following action is still pending. On 6/11/14 4:50 PM, Vijay K. Gurbani wrote: > On 06/11/2014 01:34 PM, Paul Kyzivat wrote: >> SIPCORE people, > [...] >> Also, Ollie & Vijay - there is a TODO in the Introduction for the two of >> you to sync up on relationship to 6157. We need to clear that up. > > ACK. Will do. > > Thanks, > > - vijay From nobody Thu Oct 30 12:05:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE41A1AFD for ; Thu, 30 Oct 2014 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9tyUmhZAUPAJ for ; Thu, 30 Oct 2014 12:04:58 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1CA1A1AF7 for ; Thu, 30 Oct 2014 12:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1399; q=dns/txt; s=iport; t=1414695896; x=1415905496; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Uik7jqM+fGXt3Xh4I3HyghvM6kgQztTOnJhZR+HBaf0=; b=QRXxTOZoln2sD/sBhsZDvihMZr0JGknsW4YIkeq0f1R3OTL6xB4JIKb8 OKUTjOJaxCvzuNTm8e8Np0R22g7bwgC0CDwQsFAH6OD6X1xCHWAdKBxy3 D9hKPfKkW/3bzn72wocMrwrxE8bNp9ks22C7Cc3B2YDk8n3mjXrKS7iAW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFALmKUlStJA2H/2dsb2JhbABcDoMAVFgEzREKhnlUAoEkFgEBAQEBfYQCAQEBAwEBAQE3NAQHBQsCAQgOCh4QJwslAgQOBYg4CQ3KPgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkDUnMweDLYEeBZIQi2CWRIM4QGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,288,1413244800"; d="scan'208";a="91866169" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 30 Oct 2014 19:04:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9UJ4uXT007750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 19:04:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 14:04:56 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack Thread-Index: AQHP9HFtbWnw6fvAbEu+cyhzOqQnhJxJU7UA Date: Thu, 30 Oct 2014 19:04:55 +0000 Message-ID: <077814DF-836A-4E74-A9DF-FE9F84C8C4CD@cisco.com> References: <5398A125.60202@alum.mit.edu> <5398C111.7000700@bell-labs.com> <545286D0.2090303@alum.mit.edu> In-Reply-To: <545286D0.2090303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.152] Content-Type: text/plain; charset="us-ascii" Content-ID: <9495D1128A28FA44A20864925F2B16A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/8LMasX94K_QdfUu4byB8z5Gx2As Cc: SIPCORE WG Subject: Re: [sipcore] Finishing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:05:02 -0000 Hi Paul -=20 I concur. The recent inactivity is our fault (day job, etc) but we intend t= o accelerate this effort as we move into the new year. We recently reached= out to Vijay to collaborate on the only remaining open issue in the draft.= Once that has been settled we will send an updated version that I hope we= can consider for WGLC. Thanks, Gonzalo > On Oct 30, 2014, at 2:43 PM, Paul Kyzivat wrote: >=20 > I've been negligent in pushing this draft along. There has been no action= since Toronto, except that the draft was just refreshed to keep it from ex= piring. >=20 > I don't currently have it on the agenda for the Honolulu meeting because = there has been no action and no request from the authors. >=20 > I would like to get this one wrapped up. >=20 > Thanks, > Paul >=20 > IIUC the following action is still pending. >=20 > On 6/11/14 4:50 PM, Vijay K. Gurbani wrote: >> On 06/11/2014 01:34 PM, Paul Kyzivat wrote: >>> SIPCORE people, >> [...] >>> Also, Ollie & Vijay - there is a TODO in the Introduction for the two o= f >>> you to sync up on relationship to 6157. We need to clear that up. >>=20 >> ACK. Will do. >>=20 >> Thanks, >>=20 >> - vijay >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore